seam v2.0beta takes ages to start on WebSphere v6.1.0.9

[titou09]

seam v2.0beta takes ages to start on WebSphere v6.1.0.9
I use seam 2.0 beta, JSF 1.2 RI + facelets, and seam takes ages to start (1.5h+). In the log4j traces I see those messages related to a problem with a DTD validation

...
DEBUG [core.Events ] - Processing event:org.jboss.seam.preSetVariable.org.jboss.seam.ui.entityConverterStore.component
DEBUG [seam.Component ] - instantiating Seam component: org.jboss.seam.core.events
DEBUG [seam.Component ] - initializing new instance of: org.jboss.seam.core.events
DEBUG [seam.Component ] - done initializing: org.jboss.seam.core.events
DEBUG [seam.Component ] - instantiating Seam component: org.jboss.seam.core.events
DEBUG [seam.Component ] - initializing new instance of: org.jboss.seam.core.events
DEBUG [seam.Component ] - done initializing: org.jboss.seam.core.events
DEBUG [core.Events ] - Processing event:org.jboss.seam.postSetVariable.org.jboss.seam.ui.entityConverterStore.component
DEBUG [util.DTDEntityResolver] - trying to resolve system-id [http://java.sun.com/dtd/ejb-jar_2_0.dtd]
WARN [init.Initialization ] - Couldn't parse META-INF/ejb-jar.xml for component types Operation timed out: connect:could be due to invalid address Nested exception: Operation timed out: connect:could be due to invalid address
DEBUG [util.DTDEntityResolver] - trying to resolve system-id [http://java.sun.com/dtd/ejb-jar_2_0.dtd]
WARN [init.Initialization ] - Couldn't parse META-INF/ejb-jar.xml for component types Operation timed out: connect:could be due to invalid address Nested exception: Operation timed out: connect:could be due to invalid address
DEBUG [util.DTDEntityResolver] - trying to resolve system-id [http://java.sun.com/dtd/ejb-jar_2_0.dtd]
WARN [init.Initialization ] - Couldn't parse META-INF/ejb-jar.xml for component types Operation timed out: connect:could be due to invalid address Nested exception: Operation timed out: connect:could be due to invalid address
INFO [seam.Component ] - Component: org.jboss.seam.ui.graphicImage.graphicImageResource, scope: APPLICATION, type: JAVA_BEAN, class: org.jboss.seam.ui.graphicImage.GraphicImageResource
DEBUG [seam.Component ] - instantiating Seam component: org.jboss.seam.core.events
...

It seems it's trying to validate something against the ejb-jar_2_0.dtd file.
It does this for most of the classes present in jboss-seam.jar and jboss-seam-ui.jar.
Where does this come from? is there something missing in my classpath? is it related to seam or to WebSphere? is there a way to disable this validation? will I win to the lottery next saturday?
That makes a lot of questions indeed...
Any help appreciated

[pmuir]

Given there is a dtd available at that address, I can't see why there is a problem there. And util.DTDEntityResolver is nothing from Seam. Sorry to not be more help, maybe Michael Yuan knows more.

[michael.yuan]

Hmm, what is the example app you are trying to run? Is your server connected to the Internet?

[titou09]

Pete, this is org.jboss.seam.util.DTDEntityResolver.....

Michael, yes it is ...but behind a proxy...and it does not appear to be configured correctly (at least the properties in the JVM are not correctly set)
BUT. Even if it was correctly configured, I don't want to have seam connect hundreds of time on the internet to validate.....what exactly?
Is there a way to not let seam do that validation?

I'm not using EJB3 but plain POJOs and there are no EJB in the application. There is only 2 seam "user" components. The ear is a clone of the "registration" sample (ie without the persistent stuff) and I'm trying to make seam 2.0 + facelets to work on WAS v6.1

[michael.yuan]

Since you are not using EJB, the app should be packaged in a WAR and WAS should not try to validate the ejb-jar.xml. Perhaps you can try the JPA example and see if it works in WAS? (I had some problems before, but your mileage may vary)

I am not exactly sure why seam is connecting to java.sun.com to validate the DTD -- it used to do that on jboss as well but we fixed it so that it validates locally. I am not sure what changed for WAS to cause this remote validation behavior to re-emerge.

[pmuir]

Oops. Ok, I think this is because we started parsing ejb-jar.xml in Seam2, which, if it has a dtd in it, we will attempt to resolve. I've pinged Norman.

[titou09]

Michael, the app is packaged in the classic ear/war way, if the proxy is correctly configured, it works.
However, as Pete stated it, this parsing stuff is new with seam2 and I don't think this is aceptable that, on startup, the application makes hundreds of call on internet to validate all the ejb-jar.xml files it finds (present on the classpath?). On production, our servers are even not allowed to do that!
I'll wait for the status on this. If you think this is a WAS problem, just tell me with the relevant information. As you know Michael I have an acces to IBM to open PMRs if needed.
Thx for your help and analysis and also for that great product

[michael.yuan]

Hi titou09,

While we (well, Norman :)) are fixing this issue, could you share your app with me? I am interesting in seeing working WebSphere apps for Seam2. Thanks a lot.

cheers
Michael

[norman.richards]

I've fixed this problem in CVS. Please reopen the related JIRA issue if there are any other related issues.

http://jira.jboss.com/jira/browse/JBSEAM-1646

[titou09]

Thx. I'll test it when the next (beta?) release will be out.
Michael, I've sent you a minimal ear file to test seam 2.0beta on was v6.1.0.9