as7-master-testsuite-ip6 - Build # 4689 - Failure!
by ci-builds＠redhat.com
as7-master-testsuite-ip6 - Build # 4689 - Failure:
Check console output at to view the results.
Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/4689
Internal: http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...
Test summary:
4 tests failed.
REGRESSION: org.jboss.as.test.clustering.cluster.web.DistributionWebFailoverTestCase(SYNC-tcp).testStartContainersAndDeployments
Error Message:
Cannot deploy: distributable.war
REGRESSION: org.jboss.as.test.clustering.cluster.web.DistributionWebFailoverTestCase(SYNC-tcp).testGracefulSimpleFailover
Error Message:
Provider for type class java.net.URL returned a null value: org.jboss.arquillian.container.test.impl.enricher.resource.URLResourceProvider@727db937
REGRESSION: org.jboss.as.test.clustering.cluster.web.DistributionWebFailoverTestCase(SYNC-tcp).testStartContainersAndDeploymentsForUndeployFailover
Error Message:
Cannot deploy: distributable.war
REGRESSION: org.jboss.as.test.clustering.cluster.web.DistributionWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
Error Message:
Provider for type class java.net.URL returned a null value: org.jboss.arquillian.container.test.impl.enricher.resource.URLResourceProvider@3739491b
11 years, 6 months
Javadoc - private modules vs. non-private deps - what to include (again)?
by Ondrej Zizka
Hi all,
the AS public API javadoc is generated by scripts which follow the logic
discussed earlier. In short, these are the rules for inclusion:
* All modules NOT marked with <property name="jboss.api"
value="private"/>
* Their <dependencies> which are NOT marked with <property
name="jboss.api" value="private"/>
* "unsupported" is treated the same as "private"
* All this is merged using union. I.e. if something is marked as
private, but exposed as a non-private dependency of a non-private
module, it's included.
Is the last point ok? It leads to various jars included which would make
more sense if not included.
See https://issues.jboss.org/browse/JBPAPP-10099
Perhaps a module marked private should override exposed deps?
Thanks,
Ondra
11 years, 6 months
as7-master-testsuite-ip6 - Build # 4627 - Failure!
by ci-builds＠redhat.com
as7-master-testsuite-ip6 - Build # 4627 - Failure:
Check console output at to view the results.
Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/4627
Internal: http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...
Test summary:
1 tests failed.
REGRESSION: org.jboss.as.test.integration.osgi.webapp.WebAppTestCase.testWarStructureDeployment
Error Message:
java.util.concurrent.ExecutionException: java.io.IOException: <html><head><title>JBoss Web/7.2.0.Alpha2 - JBWEB000064: Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>JBWEB000065: HTTP Status 500 - No resources</h1><HR size="1" noshade="noshade"><p><b>JBWEB000309: type</b> JBWEB000066: Exception report</p><p><b>JBWEB000068: message</b> <u>No resources</u></p><p><b>JBWEB000069: description</b> <u>JBWEB000145: The server encountered an internal error that prevented it from fulfilling this request.</u></p><p><b>JBWEB000070: exception</b> <pre>javax.servlet.ServletException: No resources org.apache.catalina.servlets.DefaultServlet.init(DefaultServlet.java:278) javax.servlet.GenericServlet.init(GenericServlet.java:242) org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:165) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:652) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:919) java.lang.Thread.run(Thread.java:662) </pre></p><p><b>JBWEB000071: root cause</b> <pre>javax.naming.NameNotFoundException: comp/Resources -- service jboss.naming.context.java.comp.Resources org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:103) org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) org.jboss.as.naming.InitialContext.lookup(InitialContext.java:120) org.jboss.as.naming.NamingContext.lookup(NamingContext.java:182) org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178) javax.naming.InitialContext.lookup(InitialContext.java:392) org.apache.catalina.servlets.DefaultServlet.init(DefaultServlet.java:273) javax.servlet.GenericServlet.init(GenericServlet.java:242) org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:165) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:652) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:919) java.lang.Thread.run(Thread.java:662) </pre></p><p><b>JBWEB000072: note</b> <u>JBWEB000073: The full stack trace of the root cause is available in the JBoss Web/7.2.0.Alpha2 logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.2.0.Alpha2</h3></body></html>
11 years, 6 months
AS7 Naming behaviour change for Context#list and JNDI View
by Eduardo Martins
Just a quick alert to all devs working on AS7 or AS7 extensions, with respect to some changes in the Naming module behaviour.
Till now Context#list operations and JNDI View's management operation where doing "plain" JNDI lookups to generate results, and this was problematic in many ways (e.g. AS7-2217 and AS7-5347). From now on lookups will only be done for entries which do not use ManagedReferenceFactory as a mean to return the lookup value, and for these special entries the Naming module will now return safe default values, Object.class for list operations, and the String "?" as the value printed in JNDI View.
Now, along with these behaviour changes, 3 new extensions of the ManagedReferenceFactory interface are introduced:
org.jboss.as.naming.ContextListManagedReferenceFactory - a ManagedReferenceFactory, which provides a proper type for Context#list operations results
org.jboss.as.naming.JndiViewManagedReferenceFactory - a ManagedReferenceFactory, which provides a proper (and does it safely) String view of the binding's value
org.jboss.as.naming.ContextListAndJndiViewManagedReferenceFactory - a combination of the two previous ones
By implementing these, instead of the raw ManagedReferenceFactory, AS7 Naming module will provide more detailed and proper results, so if you are responsible for some factory, or perhaps start seeing Object.class and/or "?" from bindings you are responsible, please consider the upgrade to the new extensions.
I already upgraded the main ones, see https://github.com/jbossas/jboss-as/pull/3137/files
-- E
11 years, 6 months
