Before I roll out the version with externalized rules 0.11, here's one more bugfix release - SwanLoom 0.10.6.

• Datasource migration corner cases fixed - those like, driver module exists, but the driver resource doens't; or the jar exists but module.xml not; etc.
• Security migrator communication with other migrators improved - through getSecurityRealm( String name )
• JAXB classes can now use BeanValidation 1.1 through Hibernate Validator 5
• -Ddebug profile added

Download and try: https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/migr/as/AsMigrator/0.10.6/AsMigrator-0.10.6.jar

Wiki: https://github.com/OndraZizka/jboss-migration/wiki

Externalized rules were identified as the key feature of a migration tool.

The reason is that not everyone willing to contribute config migration rules for a new source server may be skilled Java programmer.

Hence, these rules should be definable in easily editable simple files.

I've decided to give it a try started working on MIGR-24  Externalize the logic (rules) of migrating data .

The logic of config migration is more complex than simple reporting, so the Spring-based rules as used in a related project, WindUp, are not appropriate.

I've abandoned the idea of bending some different-purpose framework and rather designed a proprietary descriptor format, which reflects the needs of the logic, 1:1.

It is a mix of XML definitions, JAXB 2.0 beans, Expression Language, and XSLT 2.0.

This is an example of the main descriptor, which refers to JAXB classes written in Groovy, and annotated with further metadata annotations like @Property.

<?xml version="1.0" encoding="UTF-8"?>
<migration>

    <migrator name="mail">

        <jaxbBean file="TestJaxbBean.groovy"/>

        <xmlQuery id="mailServices"
            pathMask="${srcServer.dir}/server/${srcServer.profile}/deploy/mail-service.xml"
            jaxbBean="TestJaxbBean"
            xpath="/server/mbean[@code='org.jboss.mail.MailService']"
            subjectLabel="Mail Service config"
        />

        <forEach query="mailServices">
            <action type="cli" script="/subsystem=mail/service=foo:add(name=bar,boo=baz)">
                <filter>
                    //! "smtp.nosuchhost.nosuchdomain.com".equals( it.getSmtpHost() )
                    it.getSmtpHost() != "smtp.nosuchhost.nosuchdomain.com"
                </filter>
            </action>
        </forEach>

        <action type="manual">
            <warning>MailService beans migration is not yet supported.</warning>
            <forEach query="mailServices">
                <filter>
                    //! "smtp.nosuchhost.nosuchdomain.com".equals( it.getSmtpHost() )
                    it.getSmtpHost() != "smtp.nosuchhost.nosuchdomain.com"
                </filter>
                <warning>  MailService will be skipped - JNDI name: ${it.getJndiName()}, MBean name: ${ms.getMbeanName()}</warning>
            </forEach>
        </action>

    </migrator>

</migration>

• XML definitions: Handled by custom processor. See below for syntax.
• JAXB 2.0 beans: Written in Groovy 2.1, handled by EclipseLink MOXy 2.5 
  • Allows you to read XML or JSON configuration directly into a Java object of simply annotated class.
• Expression Language: Handled by JUEL 2.2 
  • Allows you to refer to the parts of read configuration using EL, e.g. ${datasources[0].connection.userName}.
• XSLT 2.0: Handled by Saxon 9.5. 
  • Allows you to transform source server XML config files into target server's config files using XSLT templates.

More information is available at project's wiki page Migrator Definition Rules.

The processor of it is under development. If you want to chime in and discuss the format, let me know.

A new site focusing on migration to JBoss EAP 6 was released:

www.jboss.org/migration

Also covered by this blog which is btw currently on the top of Planet Fedora.

And SwanLoom, the JBoss EAP configuration migration tool, is featured on it as "early access".

When trying to deploy app with context root "/" to JBoss AS 7 / EAP 6 in default configuration, you will encounter the following.

06:46:17,324 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.web.deployment.default-host./ROOT: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./ROOT: Failed to start service
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09-icedtea]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09-icedtea]
    at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
Caused by: java.lang.IllegalStateException: JBAS018038: Root contexts can not be deployed when the virtual host configuration has the welcome root enabled, disable it and redeploy
    at org.jboss.as.web.deployment.WebContextInjector.inject(WebContextInjector.java:57)
    at org.jboss.as.web.deployment.WebContextInjector.inject(WebContextInjector.java:38)
    at org.jboss.msc.inject.CastingInjector.inject(CastingInjector.java:55) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
    at org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1549) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
    at org.jboss.msc.service.ServiceControllerImpl.access$1900(ServiceControllerImpl.java:49) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1780) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1741) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
    ... 3 more

This is because AS has the root context occupied by default welcome page.

BTW, I would suggest to switch that off automatically when deploying anything with root context ("/"), and switch it off when it's undeployed... anyway:

Solution

Though Management API or CLI:

For AS 7:

/profile=default/subsystem=web/virtual-server=default-host:write-attribute(name=enable-welcome-root,value=false)

For EAP 6.1:

/subsystem=web/virtual-server=default-host/:write-attribute(name=enable-welcome-root,value=false)

You should get:

{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

Alternative way, for both:

Shut down the AS and switch it to "false" in standalone.xml.

<subsystem xmlns="urn:jboss:domain:web:1.2" default-virtual-server="default-host" native="false">
    <virtual-server name="default-host" enable-welcome-root="false">
    ...

In case you have an older Java 6 application and want to switch to Java 7 code with goodies like diamond operator and multi-type exceptions:

touch .openshift/markers/java7
git add .openshift/markers/java7

Also make sure you don't have it ignored in .gitignore like I had.

Then in pom.xml

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.0</version>
    <configuration>
        <source>1.7</source>
        <target>1.7</target>
    </configuration>
</plugin>

Then git push, and you're done.

My friends are writing a web app. Java EE 6 (JBoss EAP 6.0.1), JPA/Hibernate.

DTOs

On other colleague's advice, they don't use collections in Entities at all. Instead, they query for lists of entities and build up DTOs with collections, using multiple calls.

What do you think about this approach? Is it justifiable? Or is it rather about lack of experience with Hibernate?

I personally do mixed approach. I use @OneToMany collections whereever needed, even bi-di.

But I try to avoid @ManyToMany, and if there's need for it, I rather create an entity between, or don't map the other side.

Bottom-up

Also, since they don't have UI yet, they started creating the service / DAO layers.

They have kind of complete set of CRUDs for all entities.

But in my experience, this leads to a lot of unused code, and what they will really need when building UI won't be there.

Plus, there's a danger of view layer programmers won't ask for the right methods;

instead, they will use existing ones and code the rest in Java code, what will lead to a highly inefficient DB usage.

Isn't it better to start coding after you have at least some UI and use cases?

Hibernate is great, as far as you exactly know what you can do.

Whenever you do a mistake in mapping or HQL, it gives you a cold shower in a form of either:

• a cryptic exception from the deepness of some 3rd party library,
• or a NPE, or ArrayIndexOutOfBoundsException or similar, again coming from the deep,
• or an error from the JDBC driver (which fortunatelly, unlike Hibernate, detects the error and doesn't continue to the DB),
• or you end up with an invalid SQL query.

It's great Hibernate is on track and adding awesome features constantly, but IMO user friendliness should also be kept in mind.

For example: New user doesn't know the rules of thumb and instead of

AND wubTags MEMBER OF wuSimilar.tags

might try

AND wubTags IN wuSimilar.tags

which ends up with SQL syntax exception near "))". Huh? "))"? The query doesn't even contain a single parenthesis.

What happens is that Hibernate translates this to

(worktag2_.id in (.))

Ok, it's a development scenario, so you know when started happening and can figure out, but still - this really seems like something very easy (and cheap) to handle.

Recenly I posted about $subj being worked on.

So, time has passed, and Roman Jakubco and me pushed it to a state when it can be considered alpha.

We are about to write some docs and smoketests, and then release.

We are looking for some sample AS 5 configs for testing purposes.

If you can provide any, please let me know.