-
1. Re: Unable to deploy WAR project with Netty
jaikiran Nov 7, 2011 1:25 AM (in response to ccarter_den)Please post the entire exception stacktrace. Also where exactly is the netty.jar located in the .war?
-
2. Re: Unable to deploy WAR project with Netty
ccarter_den Nov 7, 2011 1:38 AM (in response to jaikiran)Here's what it's doing on the 7.0.2 AS with Netty included in WEB-INF/lib (we have numerous other jars in there too):
22:29:58,443 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) Starting deployment of "dems-api.war"
22:29:58,443 INFO [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Replacement of deployment "dems-api.war" by deployment "dems-api.war" was rolled back with failure message {"Failed services" => {"jboss.deployment.unit.\"dems-api.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"dems-api.war\".PARSE: Failed to process phase PARSE of deployment \"dems-api.war\""}}
22:29:58,964 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."dems-api.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."dems-api.war".PARSE: Failed to process phase PARSE of deployment "dems-api.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.7.0-b214]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.7.0-b214]
at java.lang.Thread.run(Thread.java:722) [:1.7.0-b214]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse POJO xml ["/Users/user/Documents/Java/jboss/standalone/deployments/dems-api.war/WEB-INF/lib/netty-3.2.4.Final.jar/META-INF/jboss-beans.xml"]
at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:130)
at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptors(KernelDeploymentParsingProcessor.java:104)
at org.jboss.as.pojo.KernelDeploymentParsingProcessor.deploy(KernelDeploymentParsingProcessor.java:76)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
... 5 more
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[17,1]
Message: Unexpected element '{urn:jboss:bean-deployer:2.0}deployment'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:98)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)
at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:123)
... 8 more
22:29:58,966 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) Service status report
Services which failed to start:
service jboss.deployment.unit."dems-api.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."dems-api.war".PARSE: Failed to process phase PARSE of deployment "dems-api.war"
Deploying the exact same war to 7.0.1 works without error.
-
3. Re: Unable to deploy WAR project with Netty
jaikiran Nov 7, 2011 1:54 AM (in response to ccarter_den)Try removing the POJO subsystem from your standalone.xml since I don't think you are using it anyway:
<subsystem xmlns="urn:jboss:domain:pojo:1.0"/>
-
4. Re: Unable to deploy WAR project with Netty
alesj Nov 7, 2011 4:22 AM (in response to jaikiran)Hmmm, imo we either need to make sure libs don't pack *jboss-beans.xml or we could be more lenient with the namespace.
@Jaikiran: do you perhaps know how to turn off the namespace validation?
-
5. Re: Unable to deploy WAR project with Netty
alesj Nov 7, 2011 4:25 AM (in response to alesj)Hmmm, imo we either need to make sure libs don't pack *jboss-beans.xml or we could be more lenient with the namespace.
@Jaikiran: do you perhaps know how to turn off the namespace validation?
I mean, a user could disable the namespace validation in standalone.xml, inside pojo subsystem settings.
Since we mostly support old XML schema, we could just issue a warning alongside exception if validation is turned off;
sort of "though luck, the feature is not supported (yet) in new pojo module". :-)
-
6. Re: Unable to deploy WAR project with Netty
jaikiran Nov 7, 2011 5:24 AM (in response to alesj)Ales Justin wrote:
Hmmm, imo we either need to make sure libs don't pack *jboss-beans.xml or we could be more lenient with the namespace.
@Jaikiran: do you perhaps know how to turn off the namespace validation?
I mean, a user could disable the namespace validation in standalone.xml, inside pojo subsystem settings.
Since we mostly support old XML schema, we could just issue a warning alongside exception if validation is turned off;
sort of "though luck, the feature is not supported (yet) in new pojo module". :-)
It's not exactly validation. But yeah, I see what you mean. If the jboss-beans.xml is using a different namespace than urn:jboss:pojo:7.0, for an element, then the parsing (not validation) of that element should totally be skipped. For example, here it's using the legacy urn:jboss:bean-deployer:2.0. I think we could do this in KernelDeploymentXmlDescriptorParser#readElement:
while (reader.hasNext()) { switch (reader.nextTag()) { case COMMENT: break; case END_ELEMENT: return; case START_ELEMENT: // Jaikiran : Skip unknow namespaces if (!NAMESPACE.equals(reader.getNamespaceURI())) { // log a WARN and "move" to next element logger.warn("Skipping element " + reader.getName() + " due to unsupported namespace " + reader.getNamespaceURI()); reader.discardRemainder(); break; } switch (Element.of(reader.getName())) { case BEAN: beansConfigs.add(parseBean(reader)); break; case UNKNOWN: throw unexpectedElement(reader); } break; }
Note: I haven't tested it.
-
7. Re: Unable to deploy WAR project with Netty
alesj Nov 7, 2011 6:46 AM (in response to jaikiran)If the jboss-beans.xml is using a different namespace than urn:jboss:pojo:7.0, for an element, then the parsing (not validation) of that element should totally be skipped.
No, I don't wanna skip it.
I just don't wanna validate it -- since pojo schema is 95% of bean-deployer schema.
Hence most of the stuff should just work.
If it doesn't, the user should already know why it doesn't, since he disabled the check.
(we could still pit some warning -- to not surprise those who just use this, and weren't around when validation was disabled)
-
8. Re: Unable to deploy WAR project with Netty
ccarter_den Nov 7, 2011 10:49 AM (in response to jaikiran)I'm fairly new to JBoss and the JEE world in general - what are the implications of disabling the POJO subsystem? What does it do?
-
9. Re: Unable to deploy WAR project with Netty
alesj Nov 7, 2011 10:53 AM (in response to ccarter_den)what are the implications of disabling the POJO subsystem? What does it do?
It's a support for legacy Microcontainer (JBossAS5/6 kernel) bean / service deployments.
* http://java.dzone.com/articles/a-look-inside-jboss-microconta
-
10. Re: Unable to deploy WAR project with Netty
alesj Nov 7, 2011 10:55 AM (in response to alesj)what are the implications of disabling the POJO subsystem? What does it do?
It's a support for legacy Microcontainer (JBossAS5/6 kernel) bean / service deployments.
* http://java.dzone.com/articles/a-look-inside-jboss-microconta
If you know that nobody depends on this -- which is probably 99,9999% true, since this was just recently added -- then you can simply disable the pojo subsystem.
* depends in this case means: are there any *jboss-beans.xml files present in any deployment
-
11. Re: Unable to deploy WAR project with Netty
ccarter_den Nov 7, 2011 11:13 AM (in response to jaikiran)FYI, this appears to have worked. So, comparing the configs from 7.0.1 to 7.0.2, it appears this subsystem was added to 7.0.2?
-
12. Re: Unable to deploy WAR project with Netty
jaikiran Nov 7, 2011 10:47 PM (in response to ccarter_den)Chris Carter wrote:
it appears this subsystem was added to 7.0.2?
Yes