as7-master-testsuite-ip6 - Build # 4573 - Failure!
by ci-builds＠redhat.com
as7-master-testsuite-ip6 - Build # 4573 - Failure:
Check console output at to view the results.
Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/4573
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.ejb3.descriptor.disable.DisableClusteredTestCase(SYNC-tcp).startContainers
Error Message:
Cannot deploy: not-creating-cluster-dd.jar
REGRESSION: org.jboss.as.test.clustering.cluster.ejb3.descriptor.disable.DisableClusteredTestCase(SYNC-tcp).testStatefulBean
Error Message:
Failed to create proxy
REGRESSION: org.jboss.as.test.clustering.cluster.ejb3.descriptor.disable.DisableClusteredTestCase(SYNC-tcp).testStatelessBean
Error Message:
null
REGRESSION: org.jboss.as.test.clustering.cluster.ejb3.descriptor.disable.DisableClusteredTestCase(SYNC-tcp).stopAndUndeploy
Error Message:
Deployment with name deployment-1 could not be undeployed. Container container-1 must be still running.
12 years, 12 months
New Pull Request Reviewer
by Jason Greene
In order to keep up with the high pull request volume, and improve our overall timezone coverage, Jaikiran Pai has agreed to take on the additional role as an AS7+ pull request reviewer. As many of you have seen, Jaikiran already lends a hand in our review process by providing valuable feedback on the various pending pull requests. This combined with his community work, and code submissions has demonstrated a broad knowledge of the code base. Since Jaikiran works from India, we will have additional coverage in APAC and morning EMEA hours.
I am hopeful this will shorten the overall patch review time.
Thanks Jaikiran!
12 years, 12 months
Guidelines for managing management API versions of subsystems
by Jaikiran Pai
Was just looking at some of the PRs and noticed that after a recent
change to Jacorb subsystem [1] we decided to bump the micro version of
that subsystem's management API [2]. What are the general guidelines
when it comes to bumping the management version of a subsystem? As far
as xsd changes are concerned, for EJB3, I've been making sure that the
version is bumped whenever there's a semantic change from a previous
released version. But I haven't so far touched the management version of
the EJB3 subsystem - in fact I had almost forgotten we had that. As a
specific example, I introduced a "default-security-domain" management
attribute for the EJB3 subsystem recently. Does this warrant a
management version bump?
[1] https://github.com/jbossas/jboss-as/pull/3175/files
[2] https://github.com/jbossas/jboss-as/pull/3197/files
-Jaikiran
12 years, 12 months
Netty upgrade for AS7
by Jeff Mesnil
Hi guys,
This is of interest for infinispan, web & messaging subsystem and the test suite.
As a part of upgrading HornetQ to 2.3.O.BETA1 in AS7[1], we also need to upgrade its dependency to Netty 3.4.5.Final[2].
Inside AS7, the Web subsystem also depends on Netty. Guys, is it ok for you to upgrade to 3.4.5?
Unfortunately, to move from Netty 3.2.x to Netty 3.4.x, we must also change its groupId from org.jboss.netty to io.netty.
If I do that, I can no longer build AS7 test suite because of bad dependencies which requires Netty 3.2.x:
+-org.jboss.as:jboss-as-testsuite:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-build:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-core-model-test:7.2.0.Alpha1-SNAPSHOT
+-org.jboss.as:jboss-as-model-test:7.2.0.Alpha1-SNAPSHOT
+-org.sonatype.aether:aether-connector-asynchttpclient:1.13.1
+-com.ning:async-http-client:1.6.5
+-org.jboss.netty:netty:3.2.5.Final
and
+-org.jboss.as:jboss-as-testsuite:7.2.0.Alpha1-SNAPSHOT
+-org.projectodd.stilts:stilts-stomp-client:0.1.26
+-org.projectodd.stilts:stilts-stomp-api:0.1.26
+-org.jboss.netty:netty:3.2.1.Final
Since only the test suite depends on Netty 3.2.x, in my PR, I have 2 versions of Netty:
* io.netty Netty 3.4.5.Final => used by AS7 codebase
* org.jboss.netty Netty 3.2.x => used by AS7 test suite
This is ugly but this works...
However, I'd like to reconcile these 2 versions and upgrade everything to 3.4.5.Final
I have submitted patches for Stilts[3] and Aether connector[4] to upgrade their dependencies to Netty 3.4.x (groupId=io.netty).
Until they release new versions of their components, we are stuck with Netty 3.2.x.
Another question is about the recent upgrade to Infinispan 5.2.0.BETA1[5]. When I look at this version's POM[6], it depends on
Netty 3.4.6.Final. Shouldn't have Netty been updated at the same time than Infinispan?
If that's not required to upgrade a component dependencies when the component is upgraded, I could postpone Netty 3.4.x upgrade.
However some HornetQ bugs requires this version (e.g. for WebSockets support[7]). I really want to keep the AS7 dependencies in
sync with the deps of HornetQ that is integrated.
wdyt?
jeff
[1] https://issues.jboss.org/browse/AS7-5683
[2] https://issues.jboss.org/browse/AS7-5402
[3] https://github.com/projectodd/stilts/pull/8
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=391233
[5] https://github.com/jbossas/jboss-as/commit/7107c3abcd6220f71380b3602398ed...
[6] https://github.com/infinispan/infinispan/blob/5.2.0.Beta1/parent/pom.xml#...
[7] https://issues.jboss.org/browse/HORNETQ-819
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
12 years, 12 months
MSC NPE [Re: as7-master-testsuite-ip6 - Build # 4546 - Failure!]
by Stuart Douglas
This is a new one:
> [0m[31m17:16:17,648 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 52) JBAS014612: Operation ("add") failed - address: ([("subsystem" => "transactions")]): java.lang.NullPointerException
> at org.jboss.msc.service.OptionalDependency.getController(OptionalDependency.java:377) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:606) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:634) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:634) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:588) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:562) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:982) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.txn.subsystem.TransactionSubsystemAdd.performObjectStoreBoottime(TransactionSubsystemAdd.java:289)
> at org.jboss.as.txn.subsystem.TransactionSubsystemAdd.performBoottime(TransactionSubsystemAdd.java:179)
> at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performRuntime(AbstractBoottimeAddStepHandler.java:57) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:50) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:414) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:296) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:216) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:313) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
It looks like in
org.jboss.msc.service.OptionalDependency#getController() dependent is
neither volatile nor read in a synchronized block, so may appear to be
null if read from another thread.
I have created an issue: https://issues.jboss.org/browse/MSC-121
Stuart
ci-builds(a)redhat.com wrote:
> as7-master-testsuite-ip6 - Build # 4546 - Failure:
>
> Check console output at to view the results.
>
> Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/4546
> Internal: http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...
>
> Test summary:
>
> 2 tests failed.
> REGRESSION: org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase(SYNC-tcp).testStartContainersAndDeploymentsForGracefulUndeployFailover
>
> Error Message:
> Cannot deploy: distributable.war
>
> REGRESSION: org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
>
> Error Message:
> Invalid use of BasicClientConnManager: connection still allocated. Make sure to release the connection before allocating another one.
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12 years, 12 months
as7-master-testsuite-ip6 - Build # 4489 - Failure!
by ci-builds＠redhat.com
as7-master-testsuite-ip6 - Build # 4489 - Failure:
Check console output at to view the results.
Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/4489
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.testSimpleBundleWithJarExtension
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:97) org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) org.jboss.as.naming.InitialContext.lookup(InitialContext.java:120) org.jboss.as.naming.NamingContext.lookup(NamingContext.java:215) 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>
13 years
ExternalContextMBean replacement?
by Brian Stansberry
I've heard a few times of people looking for a replacement of the
functionality provided by the old ExternalContextMBean in AS v < 7.
1) Are there any workarounds or alternate approaches that can provide a
similar thing? David Lloyd mentioned "maybe via @Startup @Singleton with
a bind statement or something...". I'm not sure if bind() does the
trick, since AIUI what's needed is a new subcontext, not a binding in an
existing context.
2) If not, what would it take to allow binding a reference to an
external context into the server JNDI tree? I had a very brief look at
this, and it seems context's are actually MSC services that follow a
particular service naming pattern. Is some sort of SPI to solidify that
contract an option?
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
13 years
