I'm violating loader constraints!

[wpfeiffe]

My session bean which worked fine in JBoss 2.4.4 Tomcat 4.0.1 returns a serialized class (SecuritySession). In JBoss 3.0.0-Tomcat 4.0.3, I get the following using the same ear file:

java.lang.LinkageError: Class org/arbfile/util/j2ee/security/SecuritySession violates loader constraints.

Any ideas on where to start debugging this? I'd be happy to try to isolate the problemto post more info if I knew where to start looking.

Thanks,

Bill Pfeiffer

[adrian.brock]

From the javadocs

"Subclasses of LinkageError indicate that a class has some dependency on another class; however, the latter class has incompatibly changed after the compilation of the former class"

Regards,
Adrian

[wpfeiffe]

I recompile my entire source every time. The code is compiled once and then the appropriate j2ee jar files are put together from the resultant classes. I have used the same 3rd party library jar files for a very long time. Given that that is the case, would you have an idea of how the message you quoted from the docs could point me in a particular direction?

This same ear file works fine under 2.4.4 and 2.4.6.

Thanks for your reponse,

Bill Pfeiffer

[adrian.brock]

Are you compiling over the same classes you are
deploying over?

It looks like a class you are referencing has changed
radically between compilation and deployment.
It probably is not one of your classes.

Regards,
Adrian

[ricardotemporal]

I trying to upgrade

from jboss2.2.2_tomcat3.2.2
to jboss3.0.0_tomcat4.0.3

Then I got this error, and after search in forums (java.sun.com) and some tries, I found a solution.

create methods of the EJB Home interface must be declared public.

I don't know if all other methods also need it, so I will declare public for all.

[tthiele]

???
any methods in an interface must be declared public.

I rather guess the environment is corrupt. Check whether
old jar-files of your application is scattered over the lib
directories of jboss. Note that there are a number other dirs
that appear in the classpath (tmp, db, ...). If the classloader
finds old classes in these places first you get such weired errors.

Tilo

[tthiele]

you folks are nice tricky, but your approaches have some restrictions.
Recent weeks I meditated a lot about this subject because I'm realizing a J2EE project using JBoss/Tomcat.

The point is, that these services have (in my case) the properties:
1. They exist only once in the system
2. They access local files (containing settigs e.g.)
3. They create Threads which must work synchronized.

If you locate these services locally in the web tier (tomcat)
your application is not scalable because you violate (1.).
That means you only can run a unique Tomcat. Acceptable for small
applications, not acceptable for 'real world' applications.

On the other hand you can't locate them in a bean. (2.) and (3.)
violate EJB restrictions.

My solution was to use MBeans. They are really great and JBoss
has made the right approach to provide an appropriate media to
solve these proplems.

Unfortunately my clients urged me to provide an port to other
systems like JRun or Webspere. And is a problem because they are
poor concerning this issue.

I think it is nessesary to put this services in a new war which
contains these unique central services (including a management
console). It seems I must reinvent the JMX-wheel.

[tthiele]

you folks are nice tricky, but your approaches have some restrictions.
Recent weeks I meditated a lot about this subject because I'm realizing a J2EE project using JBoss/Tomcat.

The point is, that these services have (in my case) the properties:
1. They exist only once in the system
2. They access local files (containing settigs e.g.)
3. They create Threads which must work synchronized.

If you locate these services locally in the web tier (tomcat)
your application is not scalable because you violate (1.).
That means you only can run a unique Tomcat. Acceptable for small
applications, not acceptable for 'real world' applications.

On the other hand you can't locate them in a bean. (2.) and (3.)
violate EJB restrictions.

My solution was to use MBeans. They are really great and JBoss
has made the right approach to provide an appropriate media to
solve these proplems.

Unfortunately my clients urged me to provide an port to other
systems like JRun or Webspere. And is a problem because they are
poor concerning this issue.

I think it is nessesary to put this services in a new war which
contains these unique central services (including a management
console). It seems I must reinvent the JMX-wheel.

[russf]

doing a recursive find of *.jar dated since my project start from the server directory, and deleting all results fixed this for me.
--r.

[jkrause]

I also get this error when frequently updating my jars in my project. I use ANT to ftp the jars over to the server every time I update. I've split the EJBs into separate jars and the web/jsp files into their own jar. If I make an change to the web jar, I can upload it and everything is fine. However if I update something in an EJB jar and upload it I get this error when web tries to load the bean.

So whenever I get the violating loader constraints error I restart jboss and the web is able to load the EJB just fine and use it. So its something in my program that causes the violating loader constraints when an EJB is still in memory and I update its JAR file on the server. I used to be able to update EJB classes live and have them auto-reload without violating loader constraints, but I've add or changed something that I haven't figured out what yet and not it doesn't work.

[nznl]

I had this exact problem and, although I don't fully understand the problem, I have a workaround.

I was using beans (entity or session) that extended classes that were deployed to jboss in separate jars i.e.

a extends b

a.class in a.jar and b.class in b.jar

when I put both classes in one jar, the problem disappeared. The super class did not have to be an ejb, just a class.

FYI - I'm using xdoclet to build & deploy my beans so
switching over was simply a case of a new build.xml file.

I'd love to hear about a solution since I have some nice logical divisions of code by separating the jars.

Anyone?

[erik777]

I have this problem, and don't have a solution. I cannot combine JARs as one person did, because one JAR, the security JAR, is, in effect, an independent application that serves other applications.

The security JAR creates a serializable class, which gets passed back to an application JAR, which gets passed to the web tier. I get this error when a JSP (servlet error) tries to access the properties on the serialized class. This is necessary, as it is used to determine the output to the client. One example is a CRUD class that contains the access a user has to a given module, thus impacting what menu options are available among other things.

This worked in JBoss 2.4.0_Tomcat 3.2.3, but fails in jboss-3.0.0_tomcat-4.0.3.

[erik777]

The workaround I found on the web, and works for me, but is a royal pain, is:

- Shutdown JBoss
- Delete everything in %JBOSS_HOME%\catalina\work
- Restart JBoss

I do this EVERY time I deploy one of my JARs. I tried putting in a batch file that erases all the files in the work folder, but this only seems to work some of the time. I would really like to know the DOS command to delete all the folders with the files. I suspect the folders being there may create confusion.

Of course, what we really need is a way for JBoss to delete the corresponding context folders in catalina\work whenever the JAR is redeployed. Is this feature in discussion?