JBoss-5.0 GA and JBoss-5.0.1 GA incompatible?
by Jaikiran Pai
While working on a unrelated issue, i noticed that the serialVersionUID
of org.jboss.security.SimplePrincipal (in jbosssx.jar) has changed
between JBossAS5.0 GA and the current 5.0 branch. The 5.0 branch uses
2.0.2.SP6 version of jbosssx.jar whereas JBossAS5.0 GA uses 2.0.2.SP3.
Between these versions, the serialVersionUID of the SimplePrincipal
class has changed from
private static final long serialVersionUID = 1L; // In 2.0.2.SP3
to
private static final long serialVersionUID = 7701951188631723261L; // In
2.0.2.SP6
As a result JBossAS-5.0 GA clients (ex: servlets on JBossAS-5.0 GA) fail
against JBossAS-5.0.1.GA server (current 5.0 branch) when doing the
following:
import org.jboss.security.client.SecurityClient;
import org.jboss.security.client.SecurityClientFactory;
// psuedo code - do login
SecurityClient securityClient =
SecurityClientFactory.getSecurityClient();
securityClient.setSimple("jai", "pass");
securityClient.login();
// lookup bean hosted on 5.0.1 GA
Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory");
props.put(Context.PROVIDER_URL,"jnp://localhost:1199");
Context ctx = new InitialContext(props);
MySecureBean bean = (MySecureBean) ctx.lookup("MySecureBean");
System.out.println("Got bean");
bean.doSomethingSecure("jai", 2);
12:33:51,261 ERROR [STDERR] Caused by: java.io.InvalidClassException:
org.jboss.security.SimplePrincipal; local class incompatible: stream
classdesc serialVersionUID = 1, local class serialVersionUID =
7701951188631723261
12:33:51,261 ERROR [STDERR] at
java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546)
12:33:51,261 ERROR [STDERR] at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
12:33:51,261 ERROR [STDERR] at
java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
12:33:51,261 ERROR [STDERR] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
12:33:51,261 ERROR [STDERR] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
12:33:51,261 ERROR [STDERR] at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
12:33:51,261 ERROR [STDERR] at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
12:33:51,261 ERROR [STDERR] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
12:33:51,261 ERROR [STDERR] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
... // trimmed most of the unrelevant logs
12:33:51,264 ERROR [STDERR] at
org.jboss.ejb3.proxy.handler.ProxyInvocationHandlerBase.invoke(ProxyInvocationHandlerBase.java:261)
12:33:51,264 ERROR [STDERR] at
org.jboss.ejb3.proxy.handler.session.SessionSpecProxyInvocationHandlerBase.invoke(SessionSpecProxyInvocationHandlerBase.java:101)
12:33:51,264 ERROR [STDERR] at $Proxy95.doSomething(Unknown Source)
12:33:51,264 ERROR [STDERR] at
org.myapp.servlet.SimpleServlet.doPost(SimpleServlet.java:40)
The other way (5.0.1 GA clients against 5.0 GA server) fails too. From
SVN logs, it appears that the serialVersionUID change was meant for
compatibility with external tools like JBoss Tools. Any way to make
5.0.1.GA and 5.0 GA compatible?
On a related note, in the component-matrix for Branch_5_x is see that
the jbosssx package is still at 2.0.2.SP3:
<version.org.jboss.security>2.0.2.SP3</version.org.jboss.security>
It's only upgraded to 2.0.2.SP6 in 5.0 branch.
regards,
-Jaikiran
16 years, 9 months
Dependencies, class in multiple jar files, JBAS-1796, JBAS-6444
by Jesper Pedersen
Hi.
I was going over the dependencies for the JBJCA project and needed a tool to
get an overview of dependencies between jar files, if a class is located in
multiple jar files and an overview of what each jar file requires and
provides.
So I hacked something together; currently called Tattletale - based on
javassist.jar of course.
I have attached the report for the application server to the issue
https://jira.jboss.org/jira/browse/JBAS-1796
as it could provide some information about the separation of the jar files.
If you take a look at the 'Dependencies' report
under "common-httpclient.jar" - you'll see
https://jira.jboss.org/jira/browse/JBAS-6444
just to give you an idea.
The index.html file will provide the starting point for the various reports.
If you think this tool would be useful I'll commit the code somewhere in
repository.
Feedback is of course welcomed, but remember it is very early beta ;)
Best regards,
Jesper
16 years, 9 months
Easymock upgrade
by Brian Stansberry
There's a way old release of easymock in trunk/component-matrix/pom.xml:
<dependency>
<groupId>easymock</groupId>
<artifactId>easymock</artifactId>
<version>1.1</version>
</dependency>
<dependency>
<groupId>easymock</groupId>
<artifactId>easymockclassextension</artifactId>
<version>1.1</version>
</dependency>
AFAICT, neither is used anywhere. The AS and testsuite build without
them and a search for "easymock" didn't turn up anything.
I want to replace that with org.easymock:easymock v 2.4 and get rid of
the easymockclassextension since it's unused. If anyone has any
objection, please speak up.
I'd do the same on Branch_5_x.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
16 years, 9 months
Apache XML Security in JBAS
by Anil Saldhana
Currently all the branches of JBAS5 are using Apache XML Security 1.3.0
which was released in Nov 2005. The latest is 1.4.2 which does include
JSR-105 (XML Signature support) etc. I think JBossWS may be the only
user of this library.
Any objections to upgrading this for 5.1 and trunk?
On a broader note, can we please update all the 3rd party libraries to
their most recent versions as much as possible?
16 years, 9 months
Use cases for manipulating AS classpath
by Max Rydahl Andersen
Hi guys,
Can you give me a usecase where it is useful to add jars to the AS
classpath (JBOSS_CLASSPATH/RUN_CLASSPATH in the run.sh scripts) and not
just add them into lib folder ?
Asking since it is a constant "battle" in the tooling between users who
want full control and those who just want the server startup to *always*
work.
Before we go add a bunch of complex code to handle this I would like to
know of a use case that merits that users can set the classpath at
startup time instead
of just adding it into lib.
The usecases I have come up with I'm not sure if they are valid:
1) allows me to put stuff on the global classpath of the server without
manipulating a possibly read-only lib directory
2) Needed if you want to enhance the run.jar and other classes for
profiling/debugging purposes
3) Allows you to try a patch on run.jar without changing the possible
read-only AS directory
Anything else ?
Are those 3 usecases *valid* or is there better ways of doing that ?
From a tooling users perspective I believe (though not yet confirmed)
that bullet 1 is the reason why they want it - thus I would like to know if
doing point 1 is semantically equal to putting that jar in the lib dir
of the server or the config. Or are there some (user perceived) difference ?
/max
16 years, 9 months
Why is AS6 failing in hudson?
by Scott Stark
I can't see why the last few AS 6 runs are failing. This one looks fine,
but its marked as failed?
http://hudson.qa.jboss.com/hudson/job/JBoss-AS-6.0.x/139/
The console output shows the smoke tests are passing, but the end of the
console output indicates the run is failed.
...
smoke-tests-raw:
[echo]
[echo] junit.timeout: 300000
[echo] jbosstest.iterationcount: 10
[echo] jbosstest.threadcount: 5
[echo] jbosstest.beancount: 5
[echo]
[mkdir] Created dir:
/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-6.0.x/JBossAS_6_0/testsuite/output/log
[junit] Running org.jboss.test.aop.test.AOPUnitTestCase
[junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 18.803 sec
[junit] Running org.jboss.test.classloader.test.ScopingUnitTestCase
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 15.919 sec
[junit] Running org.jboss.test.cts.test.BmpUnitTestCase
[junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 22.303 sec
[junit] Running org.jboss.test.cts.test.CmpUnitTestCase
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 6.26 sec
[junit] Running org.jboss.test.cts.test.CtsCmp2OptionDUnitTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 18.127 sec
[junit] Running org.jboss.test.cts.test.CtsCmp2UnitTestCase
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 5.524 sec
[junit] Running org.jboss.test.cts.test.IndependentJarsUnitTestCase
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.358 sec
[junit] Running org.jboss.test.cts.test.MDBUnitTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.65 sec
[junit] Running
org.jboss.test.cts.test.StatelessSessionBrokenCreateUnitTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.176 sec
[junit] Running org.jboss.test.cts.test.StatelessSessionUnitTestCase
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 29.881 sec
[junit] Running org.jboss.test.ejb3.test.SimpleSessionUnitTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.602 sec
[junit] Running
org.jboss.test.jbossmessaging.test.JBossMessagingJoramUnitTestCase
[junit] Tests run: 198, Failures: 0, Errors: 0, Time elapsed: 43.418 sec
[junit] Running
org.jboss.test.jca.test.BaseConnectionManagerUnitTestCase
[junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 29.323 sec
[junit] Running org.jboss.test.jca.test.PoolingUnitTestCase
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.924 sec
[junit] Running org.jboss.test.jca.test.XADSUnitTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.886 sec
[junit] Running org.jboss.test.jmsra.test.RaJMSSessionUnitTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.03 sec
[junit] Running org.jboss.test.jmsra.test.RaQueueUnitTestCase
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 8.737 sec
[junit] Running org.jboss.test.jmsra.test.RaSyncRecUnitTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.999 sec
[junit] Running org.jboss.test.jmsra.test.RaTopicUnitTestCase
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 7.069 sec
[junit] Running org.jboss.test.naming.test.SimpleUnitTestCase
[junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 6.071 sec
[junit] Running org.jboss.test.tm.test.TransactionManagerUnitTestCase
[junit] Tests run: 28, Failures: 0, Errors: 0, Time elapsed: 0.934 sec
[junit] Running org.jboss.test.web.test.WebIntegrationUnitTestCase
[junit] Tests run: 37, Failures: 0, Errors: 0, Time elapsed: 22.091 sec
[junit] Running org.jboss.test.xml.DDValidatorUnitTestCase
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 26.165 sec
[server:stop] Shutting down server: all
[server:stop] shutdownTimeout will be=45
BUILD SUCCESSFUL
...
Build was marked for publishing on https://hudson.jboss.org/hudson/
Email was triggered for: Failure
There are 1 triggered emails.
Sending email for trigger: Failure
Sending e-mails to: builds(a)lists.jboss.org
finished: FAILURE
16 years, 9 months
JBoss5 on Debian: call for testers
by Philipp Huebner
Hello,
I'm writing on behalf of the Debian pkg-jboss group.
JBoss 5 is being packaged by us with the overall goal to get it into
Debian. There is still much work to do, especially in the build process,
packaging more components of JBoss separately, and getting those already
packaged separately working with JBoss 5.
But our first priority is to get it working in a usable way, and I
believe we have reached a usable status now.
The profiles "default", "minimal", "web" and "standard" seem to be
working ("all" isn't yet), but we would like to find people who want to
use JBoss on Debian and are able to test it.
So far we've been developing on Debian unstable, would be interesting if
someone tests it on Debian testing and reports back to us.
Packages are available from [1].
The ones I am talking about are jbossas5, libjbossas5-java and
jbossas5-doc, all in version 5.0.0~GA-0.5.
At the moment, you also need the temporary package jbossas5-libs (0.4-1)
for the others to work.
Further information can be found on [2].
Please let any discussion concerning this take place on the
pkg-jboss-maintainer list [3], hosted on alioth [4].
Feedback, testing and help is welcome and much appreciated.
[1] deb http://pkg-jboss.alioth.debian.org unstable/all/
[2] https://wiki.debian.org/JBossPackaging
[3] https://alioth.debian.org/mail/?group_id=30355
[4] https://alioth.debian.org/projects/pkg-jboss
Regards,
Philipp Hübner
16 years, 9 months
Ongoing VFS testing on Branch_5_0
by Dimitris Andreadis
Ales has moved some components in Branch_5_0 to snapshot releases to perform VFS testing on
hudson before tagging the actual releases.
Please refrain from making changes in Branch_5_0.
Modified: branches/Branch_5_0/component-matrix/pom.xml
===================================================================
--- branches/Branch_5_0/component-matrix/pom.xml 2009-02-03 16:58:20 UTC (rev 83818)
+++ branches/Branch_5_0/component-matrix/pom.xml 2009-02-03 17:01:06 UTC (rev 83819)
@@ -59,12 +59,12 @@
<version.org.jboss.ejb3.security.client>1.0.0</version.org.jboss.ejb3.security.client>
<version.org.jboss.jpa>1.0.0-Beta6</version.org.jboss.jpa>
<version.org.jboss.reflect>2.0.2.GA</version.org.jboss.reflect>
- <version.org.jboss.vfs>2.0.0.GA</version.org.jboss.vfs>
+ <version.org.jboss.vfs>2.2.0-SNAPSHOT</version.org.jboss.vfs>
<version.org.jboss.mdr>2.0.1.GA</version.org.jboss.mdr>
<version.org.jboss.man>2.0.0.GA</version.org.jboss.man>
- <version.org.jboss.microcontainer>2.0.2.GA</version.org.jboss.microcontainer>
- <version.org.jboss.cl>2.0.1.GA</version.org.jboss.cl>
- <version.org.jboss.deployers>2.0.3.GA</version.org.jboss.deployers>
+ <version.org.jboss.microcontainer>2.2.0-SNAPSHOT</version.org.jboss.microcontainer>
+ <version.org.jboss.cl>2.0.2.GA</version.org.jboss.cl>
+ <version.org.jboss.deployers>2.2.0-SNAPSHOT</version.org.jboss.deployers>
<version.org.jboss.cache.core>3.0.2.GA</version.org.jboss.cache.core>
<version.org.jboss.cache.pojo>3.0.0.GA</version.org.jboss.cache.pojo>
<version.org.jboss.cluster.client>1.1.1.GA</version.org.jboss.cluster.client>
@@ -85,7 +85,7 @@
<version.streambuffer>2.1.1</version.streambuffer>
<version.sun.jaxb>2.1.9</version.sun.jaxb>
<version.xdoclet>1.2.3</version.xdoclet>
- <version.seam.integration>5.0.0.GA</version.seam.integration>
+ <version.seam.integration>5.2.0-SNAPSHOT</version.seam.integration>
</properties>
16 years, 9 months
