JBoss AS 5.0 CR1 released
Jun 30th, 2008 by sharps
Just saw an internal email announcing the availabliity of JBoss AS 5.0.0 CR1, the bits are available on SourceForge, and the release notes are here. Have fun and if you have feedback – head over to the JBoss forums.
Just downloaded it and ran it up with a -javaagent and it does not work. Amazingly this back to the future platform now hides classes defined on the system classloader by agents. Any chance we can get some docs to revert to normal classloader contracts?
William
I have managed to come up with a workaround after painstakingly trying different library deployment options. I would have expected that a pretty standard setup for a JBoss 4.2 installation would have been easily to migrate to this new stack. Now apparently I have to deploy some jars in /lib/endorsed that need to see this agent class and the others in /server/default/lib/ that can se the /lib/endorsed classes but not the agent class. I am completely baffled and the online docs do not seem to be updated since Jan 2008.
I will publish a blog entry detailing the required steps. Maybe by then I will have a better understanding of the classloader system when I plugged in our Java classes insight extension (http://blog.jinspired.com/?p=56).
Anyway congrats on the release.
William
Please, do post a link with your findings. We certainly need to work on documenting the new classloaders.
William,
can you please post your problem here:
– http://www.jboss.com/index.html?module=bb&op=viewforum&f=208
And I’ll see what can be done.
William, here’s a quick note from Adrian Brock :
NOTE: If -javaagent didn’t work, the AOP tests would fail and javaagent classloading is done by the JDK not by JBoss.
[ejort@warjort bin]$ export JAVA_OPTS=”-noverify
-javaagent:/home/ejort/temp/javarebel-1.1.1/javarebel.jar”; ./run.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /home/ejort/jboss-head/build/output/jboss-5.0.0.CR2
JAVA: /home/ejort/downloads/jdk1.5.0_09/bin/java
JAVA_OPTS: -Dprogram.name=run.sh -server -noverify
-javaagent:/home/ejort/temp/javarebel-1.1.1/javarebel.jar
-Djava.net.preferIPv4Stack=true
CLASSPATH: /home/ejort/jboss-head/build/output/jboss-5.0.0.CR2/bin/run.jar:/home/ejort/downloads/jdk1.5.0_09/lib/tools.jar
=========================================================================
##########################################################
ZeroTurnaround JavaRebel 1.1.1 (c) Copyright Webmedia, Ltd, 2007. All rights reserved.
You are running JavaRebel evaluation license.
You have 21 days until the license expires.
You will see this notification until you obtain a full license for your installation.
Visit http://www.javarebel.com for instructions on obtaining a full license. If you wish to continue your evaluation please e-mail to support@javarebel.com.
If you think you should not see this message contact support@javarebel.com or check that you have your license file in the same directory as the JAR file.
##########################################################
It is not the javaagent that is the problem. Both the javaagent and it native class (Agent) are indeed loaded. I can see this from the system.out. The problem is visibility or the lack of it which was not a problem before or with any other server apart from OSGi base ones which always present problems for instrumentation agents without special packaging and system properties being defined. This has worked with nearly every version of JBoss that supported Java 5 until now.
I will post the steps I took on the forum and explain the class loader behavior I am seeing. Thanks for the fast responses.
Sorry to hijack this blog but we might as well continue….
Here is the output I see when adding “-Xrunjdbinsight -javaagent:/Applications/JXInsight/lib/aspectj/aspectjweaver.jar” to the run.conf and deploying the following libraries into server/default/lib/.
jxinsight-core.jar
jxinsight-ext-aj.jar
jxinsight-ext-aj-complete-probes.jar
Our native profiling agent class has been defined and loaded. The classloader passed into the JNI call to define the class is null.
****** native sys output ********
[jxiagent] jvm load
[jxiagent] enabling garbage collection events (g=t). To disable specify -Xrunjdbinsight:g=f
[jxiagent] enabling thread blocking events (b=t). To disable specify -Xrunjdbinsight:b=f
[jxiagent] enabling thread waiting events (w=t). To disable specify -Xrunjdbinsight:w=f
[jxiagent] disabling memory allocation events (a=f). To enable specify -Xrunjdbinsight:a=t
[jxiagent] enabling JXInsight class extensions (x=t). To disable specify -Xrunjdbinsight:x=f
[jxiagent] enabling JVM metrics counters (m=t). To disable specify -Xrunjdbinsight:m=f
[jxiagent] loading agent class
[jxiagent] registering natives
[jxiagent] build number 1119
***** java system.out ********
[jxiagent] development-only edition
[jxiagent] license key is: ………..
[jxiagent] license validated
We now have our javaagent fronting aspectj being loaded.
[jxinsight] JXInsight AspectJ (load-time) Weaver Loaded
[jxinsight] configuration file [jxinsight.aspectj.filters.config] was not found in directory /Applications/jboss-5.0.0.CR1/bin
16:31:40,361 INFO [ServerImpl] Starting JBoss (Microcontainer)…
16:31:40,365 INFO [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.CR1 (build: SVNTag=JBoss_5_0_0_CR1 date=200806301254)
…..
The ProviderFactory class cannot see the Agent class which I assume is loaded in the boot classloader and should be accessible to all classes.
java.lang.NoClassDefFoundError: com/jinspired/jdbinsight/bootsys/Agent
at com.jinspired.jxinsight.server.probes.ProviderFactory.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at com.jinspired.jxinsight.probes.Probes.(Unknown Source)
at com.jinspired.jxinsight.server.probes.ext.aspectj.Probe$Context.(Unknown Source)
Can you please document any restrictions the new classloader architecture places on visibility? It would be great to have a diagram mapping the filesystem layout with the actual classloader delegation hierarchy.
Thanks, William
William, thanks for taking time to kick the tires and we appreciate your feedback.
- Rich
William Louth wrote:
”
The problem is visibility or the lack of it which was not a problem before or with any other server apart from OSGi base ones which always present problems for instrumentation agents without special packaging and system properties being defined.
”
What are the OSGI issues?
The JBoss5 classloader IS based on OSGi principles,
but it is not running in full OSGi mode by default.
i.e. we load all classes from the JRE bootstrap classloaders
(unlike OSGi which just loads java.* and javax.* if you don’t configure it
otherwise).
The bootstrap classes should be visible from all classloaders
(unless you explicitly create a classloader with parent=null).
The JBoss classloader hierarchy is “relatively” simple in default configuration.
1) JRE “ClassPath” – normal java
2) which is the parent of the JBoss Bootstrap classloader ($JBOSS_HOME/lib bootstrap jars)
3) which is the parent of the “DefaultDomain” that all other classloaders use
to make themselves into “peers”.
All these use standard parent first classloading rules.
In terms of semantics nothing has changed in the “out-of-the-box” rules
since JBoss4, it should be fully backwards compatible.
This turns out to be a bug in a classloader optimization in JBoss5
http://jira.jboss.com/jira/browse/JBCL-17
[...] AS 5.0.0 CR1 is out : http://blog.softwhere.org/archives/213 [...]