as7-master-testsuite-ip6 - Build # 5780 - Failure!
by ci-builds＠redhat.com
as7-master-testsuite-ip6 - Build # 5780 - Failure:
Check console output at to view the results.
Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/5780
Internal: http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...
Test summary:
1 tests failed.
FAILED: org.jboss.as.test.integration.osgi.stilts.StompletTestCase.org.jboss.as.test.integration.osgi.stilts.StompletTestCase
Error Message:
java.lang.Exception: {"JBAS014671: Failed services" => {"jboss.deployment.unit.stomplet-server-provider.Activate" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.stomplet-server-provider.Activate: JBAS011968: Cannot start bundle: stomplet-server-provider:0.0.0 Caused by: org.osgi.framework.BundleException: JBOSGI011254: Cannot start bundle: stilts-stomplet-server-bundle:0.1.26 Caused by: java.lang.NullPointerException"}}
12 years
A strategy for mapping a directed dependency graph with transitives and cycles onto a DAG
by David M. Lloyd
The problem: MSC services must form a DAG. However, in several cases,
the dependency information we are given is potentially cyclic and may
also include transitive dependency information.
Currently we deal with cyclic dependencies by using a two-phase
resolution strategy, however this strategy can only ever encompass one
level of dependencies and cannot accommodate transitive dependencies at all.
This problem has come up in the following contexts:
1) EJB JNDI resolution where EJB A injects EJB B, but B in turn depends
on EJB C: A does not receive a dependency on C though it should have.
2) Module dependency resolution where a dependency has an export from
another module. In this case the transitive dependency is also lost.
The Two-Phase Solution
----------------------
The two-phase solution works like this:
+---------+ +---------+
| Item A | | Item B |
| (Create)| | (Create)|
| | | |
+---------+ +-+-------+
^ ^ ^
| +--------+ |
| | |
+---+--+--+ +-----+---+
| Item A | | Item B |
| (Start) | | (Start) |
| | | |
+---------+ +---------+
In this example A has a dependency on B. In the create phase, we
ascertain what the dependencies are for a given item. In the start
phase we establish dependencies on all of the create-phase services of
our dependencies.
The problem with this solution has been outlined above.
The Three-Phase Solution
------------------------
Superficially, it would seem that the problems associated with the
two-phase solution can be resolved by the use of three phases. The
initial phase would encapsulate the list of dependencies; the second
phase would depend on the immediate dependencies and would encapsulate
the set of immediate dependencies plus their immediate dependencies; and
the third phase would come up only when all these dependencies are up.
For cases where there is no concept of transitivity, this may suffice.
However it is the case in AS now where both the modules/class-path use
case and the JNDI @Resource case do indeed include the concept of
transitivity.
The N-Phase Solution
--------------------
The only way to ensure that some arbitrary set of transitive
dependencies is available is by using a self-configuring N-phase
mechanism. The way this works is as follows.
1. We create a Create-phase service as today, which encodes as part of
its value the set of immediate dependencies. This would include the
following behavior (pseudo-code):
void start() {
dependencies = immediate declared deps of this service
if (dependencies is not empty) {
create child service "resolver1";
for each (d in dependencies) {
add create phase of d to "resolver1" as dependency
}
} else {
create child service "start";
}
}
2. Each resolver service has the following behavior:
void start() {
dependencies = set of all injected create-phase services
if (dependencies is not empty) {
create child service "resolver" + (n + 1);
for each (d in dependencies) {
for each (t in d.dependencies) {
add create phase of t to "resolver" + (n + 1);
}
}
} else {
create child service "start";
}
}
This way, we retain the exact service structure we have today. From an
outside perspective the *create/*start services act just as they always
have, except they accommodate transitive dependencies correctly by way
of the "private" resolver dependencies.
This solution also has the advantage that it only creates as many
services as necessary to resolve all transitive dependencies.
Optimization
------------
Because the transitive closure of services can be pretty hefty *and* may
contain cycles, a good optimization would be to maintain a set of
create-phase services that we've already depended on which we pass from
resolver to resolver to ensure that we don't bother with redundant or
cyclic dependencies.
Not Solved
----------
This solution does not address the problem where a dependency actually
fails to start. Assuming there is no @DependsOn to establish a direct
acyclic dependency, the service will still start, but any attempt to use
a failed dependency will in turn result in a failure just like today.
--
- DML
12 years
Logging Subsystem Changes
by James Perkins
Hello All,
There have been a few notable changes (pending changes) in the logging
subsystem that I should probably make known to every one.
The most notable is probably the way the logging.properties file is
used. The file will be overwritten each time a change to the logging
subsystem is made. It also writes out fully resolved values, e.g. any
expressions like ${jboss.root.level:INFO} are not written out. This
means that changes to expressions on the XML configuration will be not
used until the logging subsystem kicks in.
Not writing out expression could be an issue with paths more than
anything. This could be an issue if you copy a configuration (from
production to dev for example) and expect ${jboss.server.log.dir} to be
resolved. Since the full path is written out, it's likely on initial
boot without any changes the log will be written to the production
directory and file.
I can't think of a solid way to fix this issue. Writing out the
expression to the logging.properties file wouldn't always work as the
system property may not be set yet.
There will no longer be a boot.log. On the initial boot of a fresh
install the console is the only stream written to until the logging
subsystem kicks in which will then write to the server.log as usual.
Since the host controller and process controller don't use the logging
subsystem, the configuration is as it always has been in the
logging.properties file of the $JBOSS_HOME/domain/configuration.
Of course if you don't want to use the logging subsystem, then it can be
disabled and the logging.properties will be the configuration used for
logging.
We've introduced logging profiles. A logging profile is like a separate
logging subsystem, in a sense at least. All the same operations are on a
logging profile. It can be used to define a different logging
configuration for a deployment. They can be applied to a deployment by
adding a Logging-Profile entry to the MANIFEST.MF for the deployment.
log4j appenders can be set-up via a custom-handler. Just define the
appenders properties as you would any other custom-handler and it will
be wrapped in a handler. The one caveat is it requires the logging
subsystem to be used. Since the logging.properties file is always
written, appenders will also be written requiring the logging subsystem
to use it's appender -> handler.
There has been a PR submitted to finally allow for expressions on most
of the attributes.
Yet to have a PR submitted due to an open PR for STDIO and a new release
of STDIO is removing the requirement to use JBoss Log Manager on a
standalone server. This would allow a user to use log4j or logback as
their log manager to control logging for the server if they'd prefer.
--
James R. Perkins
JBoss by Red Hat
12 years
OSGI Module Dependency Problems [Re: as7-master-testsuite-ip6 - Build # 5740 - Failure!]
by Stuart Douglas
Hi Thomas,
So it turns out that the 2 second wait in the ServiceModuleLoader that
we removed was actually covering up another bug in the way module
dependencies are handled.
Basically the problem is that even though a module load service has a
dependency on all its dependent modules, the module can actually be
loaded prematurely if its contents are exported by another module.
e.g. we have A,B,C where A has a dependency on B, and B has a dependency
on C with export=true.
If B's ModuleSpecService comes up first, then module A can be loaded,
however there is no guarantee that C's ModuleSpecService will have
started yet. Unfortunately we can't automatically handle this situation
properly with some kind of transitive service dependency mechanism,
because circular dependencies are allowed and quite common between
modules, and and sort of pure service based approach runs into circular
dependencies quite quickly.
I have worked around this for EE deployments, basically by simply adding
a dependency on every ModuleSpecService in the deployment to each module
load service, not ideal, but short of adding back the 2 second delay I
can't really think of a better solution, and the 2 second delay caused
other problems anyway.
OSGI still seems to have problems however, as can be seen in the recent
spate of OSGI related intermittent failures, and I am not really sure
how best to solve them. Do you have any ideas? If not, do you want to
meet up on IRC and talk about it?
Stuart
ci-builds(a)redhat.com wrote:
> as7-master-testsuite-ip6 - Build # 5740 - Failure:
>
> Check console output at to view the results.
>
> Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/5740
> Internal: http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...
>
> Test summary:
>
> 1 tests failed.
> FAILED: org.jboss.as.test.integration.osgi.cdi.ManagedBeansTestCase.org.jboss.as.test.integration.osgi.cdi.ManagedBeansTestCase
>
> Error Message:
> Cannot deploy: complex.ear
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12 years
error in opening zip file: faces-config.xml
by Frank Langelage
After today's update of my local JBossAS 7 with sources from github
(Fast-forwarded master to b72f8b72a6d3f1d24309582bb45ad45485c7e3fb) I
see this in my server.log while my web-app is deploying:
20:58:39,613 SEVERE
[javax.enterprise.resource.webcontainer.jsf.config#processClasspath]
Unable to process annotations for url,
vfs:/content/web-pel2e-langfr-sb2000-ipc.war/WEB-INF/lib/richfaces-core-impl.jar/META-INF/faces-config.xml.
Reason: java.util.zip.ZipException: error in opening zip file
20:58:39,615 SEVERE
[javax.enterprise.resource.webcontainer.jsf.config#processClasspath] :
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.6.0_37]
at java.util.zip.ZipFile.<init>(ZipFile.java:127) [rt.jar:1.6.0_37]
at java.util.jar.JarFile.<init>(JarFile.java:135) [rt.jar:1.6.0_37]
at
sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:67)
[rt.jar:1.6.0_37]
at
sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:214)
[rt.jar:1.6.0_37]
at java.security.AccessController.doPrivileged(Native Method)
[rt.jar:1.6.0_37]
at
sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:198)
[rt.jar:1.6.0_37]
at
sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:50)
[rt.jar:1.6.0_37]
at
sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:70)
[rt.jar:1.6.0_37]
at
sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
[rt.jar:1.6.0_37]
at
sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:71)
[rt.jar:1.6.0_37]
at
com.sun.faces.config.JavaClassScanningAnnotationScanner.processClasspath(JavaClassScanningAnnotationScanner.java:166)
[jsf-impl-2.1.13-jbossorg-1.jar:]
at
com.sun.faces.config.JavaClassScanningAnnotationScanner.getAnnotatedClasses(JavaClassScanningAnnotationScanner.java:125)
[jsf-impl-2.1.13-jbossorg-1.jar:]
at
com.sun.faces.config.DelegatingAnnotationProvider.getAnnotatedClasses(DelegatingAnnotationProvider.java:85)
[jsf-impl-2.1.13-jbossorg-1.jar:]
at
com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:845)
[jsf-impl-2.1.13-jbossorg-1.jar:]
at
com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:797)
[jsf-impl-2.1.13-jbossorg-1.jar:]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[rt.jar:1.6.0_37]
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
[rt.jar:1.6.0_37]
at
com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:352)
[jsf-impl-2.1.13-jbossorg-1.jar:]
at
com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:223)
[jsf-impl-2.1.13-jbossorg-1.jar:]
at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339)
[jbossweb-7.2.0.Alpha5.jar:7.2.0.Alpha5]
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.0.Alpha5.jar:7.2.0.Alpha5]
at
org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156)
[jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at
org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60)
[jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at
org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93)
[jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
[rt.jar:1.6.0_37]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[rt.jar:1.6.0_37]
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
[rt.jar:1.6.0_37]
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[rt.jar:1.6.0_37]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[rt.jar:1.6.0_37]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
The same for some other libs included in my war:
20:58:39,634 SEVERE
[javax.enterprise.resource.webcontainer.jsf.config#processClasspath]
Unable to process annotations for url,
vfs:/content/web-pel2e-langfr-sb2000-ipc.war/WEB-INF/lib/openfaces.jar/META-INF/faces-config.xml.
Reason: java.util.zip.ZipException: error in opening zip file
20:58:39,763 SEVERE
[javax.enterprise.resource.webcontainer.jsf.config#processClasspath]
Unable to process annotations for url,
vfs:/content/web-pel2e-langfr-sb2000-ipc.war/WEB-INF/lib/richfaces-components-ui.jar/META-INF/faces-config.xml.
Reason: java.util.zip.ZipException: error in opening zip file
12 years
as7-master-testsuite-ip6 - Build # 5692 - Failure!
by ci-builds＠redhat.com
as7-master-testsuite-ip6 - Build # 5692 - Failure:
Check console output at to view the results.
Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/5692
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.deployment.BundleReplaceTestCase.testBundleReplace
Error Message:
java.util.concurrent.ExecutionException: java.io.IOException: <html><head><title>JBoss Web/7.2.0.Alpha3 - 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:169) 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:169) 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.Alpha3 logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.2.0.Alpha3</h3></body></html>
12 years