tomcat-sso
by Dimitris Andreadis
It's been a few runs now that the tomcat-sso configuration doesn't start
properly:
tomcat-sso-tests:
[echo] creating tomcat-sso config
[copy] Copying 374 files to /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.GA/server/tomcat-sso
[copy] Copied 73 empty directories to 2 empty directories under /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.GA/server/tomcat-sso
[echo] Overwriting config descriptors
[copy] Copying 4 files to /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.GA/server/tomcat-sso
[server:start] Starting server "tomcat-sso", with command (start timeout is 120 seconds ):
[server:start] /qa/tools/opt/jdk1.5.0_15/bin/java -cp /qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.GA/bin/run.jar:/qa/tools/opt/jdk1.5.0_15/lib/tools.jar -Xmx128m -XX:MaxPermSize=512m -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.GA/lib/endorsed org.jboss.Main -c tomcat-sso -b 10.18.94.175 -u 227.43.0.134
[server:start] Failed to start server "tomcat-sso" before timeout. Destroying the process.
>From the log, I can't tell what's wrong:
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
Whoever is changing the tomcat configs can you please make sure the
tomcat testsuite configs are in synch?
Cheers
/D
15 years, 10 months
Classloading and partial deployments
by Mladen Turk
Hi,
Have some weired idea and would like to hear if someone
already faced something similar.
It's not directly related neither to AS nor Tomcat
but both of them have the conceptually similar application
classloaders where you put some component .jar in
some (usually) lib/ folder and it gets loaded and
hopefully unloaded on undeployment.
Now, the handy feature I need would be similar to Operating
System "Move on reboot" or "Reboot required" functionality.
In essence, like with some native installations there are two
major issues. Depending on what you are installing it might
just go on, or it might require OS reboot. Installation might
just be done for current user or it might require elevated
security.
So the first thing, if for example, my .war or .ear needs to
install something to core AS or to the catalina.home/ext
is the option to tell the deployer to unpack something in
a different location, and mark the "OS" (in this case my
container) to reboot. This requires delegating this
to the parent classloader or even to the
sun.misc.Launcher$ExtClassLoader
The second thing is undeployment or uninstall where some
part of what was installed can be physically deleted only on
reboot (probably either by some cleanup task on shutdown or
by some cleanup on startup)
This probably breaks a whole bunch of specs and has potential
security implications, but given "admin" security credentials
it can be done without impacting "user" security.
Dunno how Adrian did it for MC, but I suppose it just
sweeps trough some given .jar list on deployment and loads
those classes.
My idea was to write down the generic .jar pre-loader
that would get loaded instead real .jar, figure out the
required parent classloader, use own action mechanism
for physical deployment (unpacking native libraries
from .jar for example) and do an actual classloading.
On undeploy pre-loader would get notified (dunno how yet)
and install shutdown hook so that everything gets
cleaned up "on reboot".
Next thing are partial deployments, where pre-loader
would need to figure out if the previous package is already
installed (redeployment without reboot) in which case
the versioning of the components would either allow
to continue doing nothing or refuse to load until
reboot is done. The second is common behavior now if a
package contains native library references cause they
are all referenced in system classloader regardless of
actual classloader used (and that is what I wish to
resolve basically; packing java and native code inside
archive and make everything plug-and-play). There is
Java Module API JSR-227 (for Java7 thought)
and it defines the native libraries as resource concept,
but since (according to the spec) it'll forward the
System.loadLibrary() to the defining class loader of
the calling class the issue will still remain.
Does this make any sense?
Need some theory on how for example I could write
a code that would get notified when my .jar get
loaded and unloaded by defining classloader.
Since there's no module classloading API (has to be generic)
I can use (eg. a simple URLClassLoader) I suppose
I'll need some voodoo for that :)
Regards
--
^(TM)
15 years, 10 months
obtain server connection vs jboss-logging
by Aleksandar Kostadinov
Hallo,
Hope I use the right list.
I'm creating a connection to JBoss AS as part of JBASM-3. See below for
code and exception. I can workaround it by setting
"org.jboss.logging.Logger.pluginClass" to "logging.JDK14LoggerPlugin".
But as server manager could be running in any environment I guess
blindly setting this system property is not desirable.
Any other ways I can fix that? Actually the code works but the exception
is visible to the user.
Code like:
ctx=new InitialContext(properties);
MBeanServerConnection connection = (MBeanServerConnection)
ctx.lookup("jmx/rmi/RMIAdaptor");
connection.invoke("jboss.system/type/Server", "shutdown",null,null);
*outputs* an exception:
[server:stop] Shutting down server: profileservice
[server:stop] java.lang.NoClassDefFoundError: org/apache/log4j/Priority
[server:stop] at java.lang.Class.getDeclaredConstructors0(Native Method)
[server:stop] at
java.lang.Class.privateGetDeclaredConstructors(Class.java:235
7)
[server:stop] at java.lang.Class.getConstructor0(Class.java:2671)
[server:stop] at java.lang.Class.newInstance0(Class.java:321)
[server:stop] at java.lang.Class.newInstance(Class.java:303)
[server:stop] at
org.jboss.logging.Logger.getDelegatePlugin(Logger.java:312)
[server:stop] at org.jboss.logging.Logger.<init>(Logger.java:78)
[server:stop] at org.jboss.logging.Logger.getLogger(Logger.java:291)
[server:stop] at
org.jnp.interfaces.NamingContext.<clinit>(NamingContext.java:
162)
[server:stop] at
org.jnp.interfaces.NamingContextFactory.getInitialContext(Nam
ingContextFactory.java:55)
...
Thanks much,
Aleksandar
15 years, 11 months
Error in org.jboss.test.naming.test.SimpleUnitTestCase
by Brian Stansberry
Is anyone seeing failures in SimpleUnitTestCase.testHttpInvoker? I ran
the smoke-tests before committing an upgrade to JBC and JGroups but got
the failure below. Hard to imagine it has anything to do w/ a
JBC/JGroups upgrade...
<testcase classname="org.jboss.test.naming.test.SimpleUnitTestCase"
name="testHttpInvoker" time="0.022">
<error message="Failed to retrieve Naming interface for provider
http://localhost:8080/invoker/JNDIFactory"
type="javax.naming.NamingException">javax.naming.NamingException: Failed
to retrieve Naming interface for provider
http://localhost:8080/invoker/JNDIFactory [Root exception is
java.io.FileNotFoundException: http://localhost:8080/invoker/JNDIFactory]
at
org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:84)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
at
org.jboss.test.naming.test.SimpleUnitTestCase.testHttpInvoker(SimpleUnitTestCase.java:323)
Caused by: java.io.FileNotFoundException:
http://localhost:8080/invoker/JNDIFactory
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1225)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1219)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:906)
at
org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:133)
at
org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:80)
Caused by: java.io.FileNotFoundException:
http://localhost:8080/invoker/JNDIFactory
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1168)
at
sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:1923)
at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:573)
at java.net.URLConnection.getContentLength(URLConnection.java:468)
at
org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:128)
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
15 years, 11 months
Snapshot dependencies
by Dimitris Andreadis
Why AOP is bringing in those SNAPSHOT dependencies?
[INFO] +- org.jboss.aop:jboss-aop-asintegration-core:jar:2.0.0.CR18:compile
[INFO] | \- org.jboss.jbossas:jboss-as-system-jmx:jar:5.0.0-SNAPSHOT:compile (version
managed from 5.0.0.CR2)
[INFO] | +- org.jboss.jbossas:jboss-as-main:jar:5.0.0-SNAPSHOT:compile
[INFO] | | \- urbanophile:java-getopt:jar:1.0.9:compile
[INFO] | \- org.jboss.jbossas:jboss-as-system:jar:5.0.0-SNAPSHOT:compile
[INFO] | \- org.jboss.jbossas:jboss-as-bootstrap:jar:5.0.0-SNAPSHOT:compile
[INFO] +- org.jboss.aop:jboss-aop-asintegration-jmx:jar:2.0.0.CR18:compile
[INFO] | +- org.jboss.jbossas:jboss-as-j2se:jar:5.0.0-SNAPSHOT:compile
[INFO] | \- org.jboss.jbossas:jboss-as-jmx:jar:5.0.0-SNAPSHOT:compile
[INFO] | +- org.jboss.jbossas:jboss-as-j2se:test-jar:tests:5.0.0-SNAPSHOT:compile
[INFO] | \- org.jboss.jbossas:jboss-as-mbeans:jar:5.0.0-SNAPSHOT:compile
15 years, 11 months
Re: [jboss-cvs] JBossAS SVN: r79353 - trunk/server/src/main/org/jboss/deployment.
by Adrian Brock
This is wrong, read the forum thread.
On Fri, 2008-10-10 at 11:28 -0400, jboss-cvs-commits(a)lists.jboss.org
wrote:
> Author: alesj
> Date: 2008-10-10 11:28:22 -0400 (Fri, 10 Oct 2008)
> New Revision: 79353
>
> Modified:
> trunk/server/src/main/org/jboss/deployment/LegacyWebXmlLessDeployer.java
> Log:
> Use setOutput - single class.
>
> Modified: trunk/server/src/main/org/jboss/deployment/LegacyWebXmlLessDeployer.java
> ===================================================================
> --- trunk/server/src/main/org/jboss/deployment/LegacyWebXmlLessDeployer.java 2008-10-10 15:13:13 UTC (rev 79352)
> +++ trunk/server/src/main/org/jboss/deployment/LegacyWebXmlLessDeployer.java 2008-10-10 15:28:22 UTC (rev 79353)
> @@ -41,7 +41,7 @@
> {
> addInput(WebMetaData.class);
> addInput(JBossWebMetaData.class);
> - addOutput(JBossWebMetaData.class);
> + setOutput(JBossWebMetaData.class);
> setStage(DeploymentStages.POST_PARSE);
> }
>
>
> _______________________________________________
> jboss-cvs-commits mailing list
> jboss-cvs-commits(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-cvs-commits
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 11 months
Failing smoke test
by Kabir Khan
The following test that is part of the AS smoke tests always fails for
me locally. I am on OS X
[junit] Running org.jboss.test.naming.test.SimpleUnitTestCase
[junit] Tests run: 10, Failures: 0, Errors: 2, Time elapsed:
11.26 sec
[junit] Test org.jboss.test.naming.test.SimpleUnitTestCase FAILED
15 years, 11 months
Deployment chains
by Adrian Brock
I'm currently working on tidying up the deployers in JBoss5
as part of that I'm adding some JMX operations so
you can query the deployer chains.
The initial simple list (it doesn't look very good without the css
which you get from the jmx console:-) is attached.
A quick scan of this shows some funny things or at least
some misunderstanding of the relative ordering parameter.
The relative order parameter only applies when the deployers
have similar input/outputs. It's there for when you have multiple
"filter"s. i.e. a deployer that has the same input/output type
and you need to control the order in which the filters run
(you should try to design away such a requirement if possible).
e.g. VFSClassLoaderClassPathDeployer is a filter
it inputs and outputs ClassLoadingMetaData.
So does the ClassLoadingDefaultDeployer.
1) Webservices
org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPreJSE
org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPostJSE
Currently the ordering of these is pretty weak.
i.e. there is no guarantee the PRE will run before the POST,
except that the relative order of PRE is -1 compared with Tomcat
and the POST must run after Tomcat.
This is very brittle to changes in the Tomcat Deployer which
might move it earlier in the chain due to changes in its requirements.
i.e. The TomcatDeployer takes some additional metadata beyond
JBossWebMetaData.
Shouldn't the PRE deployer also output JBossWebMetaData
to show it modifies or process it and therefore MUST run before Tomcat?
2) AOP ClassLoading
A similar criticism applies for the AOPClassLoaderDeployer
This has no chain definition at all? Only a relative order based
on the main classloader deployer.
Again this is brittle to a refactoring of how the classloader deployer
works.
3) SEAM
org.jboss.seam.integration.microcontainer.deployers.SeamWebUrlIntegrationDeployer
doesn't specify any output.
But I don't know where the source is for that?
My guess is that this should really be in Describe and specify an
output of ClassLoadingMetadata since that is where
classloading dependencies should be constructed.
4) WEB CLUSTERING
org.jboss.web.tomcat.service.deployers.ClusteringDependencyDeployer
I don't know what this is doing in Describe since it is not
establing a deployment dependency. Instead it is modifying the
JBossWebMetaData.
I'd guess this should be after the merge of annotations into that
metadata? Although I don't think there is such an annotation
currently? :-)
5+) There could be others. Like I said this is just a quick scan.
TODO
I'm going to be adding some other queries so you can display individual
metadata chains for an attachment type and graphs so can see
where attachments may have orginated from other attachments.
Additionally you'll also be able to see deployers that were used
for an individual deployment (including by subdeployment/component).
Any other ideas?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 11 months
