Skip navigation
2013

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.

TL;DR: You can't. At least not using the CDI standard. Maybe not even in Weld, not sure. But here's what you can do:

 

Sometimes you might want to create an app which is tolerant to unsatisfied CDI dependencies.

For example, you might want to have optional secondary MailSession which could be used as a fallback.

Basically, any time you want to have something optional and not bother having an extra option like "enableFoo = false".

 

So instead of getting an exception from the deepness of your application server, you would like to detect in your app whether the CDI dep was satisfied or not. Ideally, by having it set to null.

For example:

 

@Inject(nullOnFailure=true) FooBean foo;

 

Well, there's no such feature in CDI.

But there's something you can use:

 

class Bar {

    @Inject Instance<FooBean> foo;

    public doSomething(){
        if( foo.isUnsatisfied() ){
             log.error("Foo was not found!")
             return;
        }
    }

}

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?

<?xml version='1.0' encoding='UTF-8'?>
<server xmlns="urn:jboss:domain:1.3"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        urn:jboss:domain:1.3    http://www.jboss.org/schema/jbossas/jboss-as-config_1_3.xsd
        urn:jboss:domain:datasources:1.1    http://www.jboss.org/schema/jbossas/jboss-as-datasources_1_1.xsd
        urn:jboss:domain:logging:1.1        http://www.jboss.org/schema/jbossas/jboss-as-logging_1_1.xsd
        urn:jboss:domain:configadmin:1.0    http://www.jboss.org/schema/jbossas/jboss-as-configadmin_1_0.xsd
        urn:jboss:domain:datasources:1.1    http://www.jboss.org/schema/jbossas/jboss-as-datasources_1_1.xsd
        urn:jboss:domain:deployment-scanner:1.1 http://www.jboss.org/schema/jbossas/jboss-as-deployment-scanner_1_1.xsd
        urn:jboss:domain:ee:1.1             http://www.jboss.org/schema/jbossas/jboss-as-ee_1_1.xsd
        urn:jboss:domain:ejb3:1.3           http://www.jboss.org/schema/jbossas/jboss-as-ejb3_1_3.xsd
        urn:jboss:domain:infinispan:1.3     http://www.jboss.org/schema/jbossas/jboss-as-infinispan_1_3.xsd
        urn:jboss:domain:jaxrs:1.0          http://www.jboss.org/schema/jbossas/jboss-as-jaxrs_1_0.xsd
        urn:jboss:domain:jca:1.1            http://www.jboss.org/schema/jbossas/jboss-as-jca_1_1.xsd
        urn:jboss:domain:jdr:1.0            http://www.jboss.org/schema/jbossas/jboss-as-jdr_1_0.xsd
        urn:jboss:domain:jmx:1.1            http://www.jboss.org/schema/jbossas/jboss-as-jmx_1_1.xsd
        urn:jboss:domain:jpa:1.0            http://www.jboss.org/schema/jbossas/jboss-jpa_1_0.xsd
        urn:jboss:domain:mail:1.0           http://www.jboss.org/schema/jbossas/jboss-as-mail_1_0.xsd
        urn:jboss:domain:naming:1.2         http://www.jboss.org/schema/jbossas/jboss-as-naming_1_2.xsd
        urn:jboss:domain:osgi:1.2           http://www.jboss.org/schema/jbossas/jboss-as-osgi_1_2.xsd
        urn:jboss:domain:pojo:1.0           http://www.jboss.org/schema/jbossas/jboss-as-pojo_1_0.xsd
        urn:jboss:domain:remoting:1.1       http://www.jboss.org/schema/jbossas/jboss-as-remoting_1_1.xsd
        urn:jboss:domain:resource-adapters:1.0 http://www.jboss.org/schema/jbossas/jboss-as-resource-adapters_1_0.xsd
        urn:jboss:domain:sar:1.0            http://www.jboss.org/schema/jbossas/jboss-as-sar_1_0.xsd
        urn:jboss:domain:security:1.2       http://www.jboss.org/schema/jbossas/jboss-as-security_1_2.xsd
        urn:jboss:domain:threads:1.1        http://www.jboss.org/schema/jbossas/jboss-as-threads_1_1.xsd
        urn:jboss:domain:transactions:1.2   http://www.jboss.org/schema/jbossas/jboss-as-transactions_1_2.xsd
        urn:jboss:domain:web:1.2            http://www.jboss.org/schema/jbossas/jboss-as-web_1_2.xsd
        urn:jboss:domain:webservices:1.1    http://www.jboss.org/schema/jbossas/jboss-as-webservices_1_1.xsd
        urn:jboss:domain:weld:1.0           http://www.jboss.org/schema/jbossas/jboss-as-weld_1_0.xsd
    "
>

 

Transactions XSD is missing at the server for some reason.