[ctomc]

Enrique Ruiz wrote:

Tomaz, you found a workaround, but not a solution to the problem.

I have the same problem with Spring 3.2 apps. The problem is a Servlet compliant WAR cannot be deployed in JBoss 7.1, I think it is related to the new ClassLoader architecture.

Regards

Yes,

there is a bug in Spring that does not load classes properly.

and dont use servlet complaint & spring in same sentence as Spring is everything but.

In short, you want to use EE stuff, but don't let servlet container/app server provide it for you.

My "fix" is not a workaround but a proper way to use EE infrastructure(JPA is part of it) with Spring.

with my "fix" you let app server take care of JPA(as it is meant to be in any EE env) and from there on Spring can use it in any way it wants.

btw, this is the issue in spring's jira that will enable what you want to work https://jira.springsource.org/browse/SPR-10354

--

tomaz

[eruiz]

I don't agree, and I think you're wrong.

An application packed in .war that follows Servlet spec is a web app servlet compliant, indepently which libs it includes (Spring, Log4J, etc).

You know Spring is a lib and it delegates the class loading in the application server that contains it, so any class loading problem is responsibility of the app server.

On the other way I had the same problem with JSF (no Spring in that case), we use MyFaces and JBoss includes Mojarra, so JBoss loads Mojarra and our MyFaces classes aren't found. Who is the responsible in that case? Of course, JBoss and its ClassLoader architecture. Note we have solved the problem with JSF just disabling Mojarra in web.xml ... so, imho it's clear JBoss is the source of the problem.

[nickarls]

Many things require server integration and it is always possible to bundle a lib that confuses the routines. Application Servers are certified so that they work correctly when they're allowed to do the work they should.

[ctomc]

Enrique Ruiz wrote:

I don't agree, and I think you're wrong.

An application packed in .war that follows Servlet spec is a web app servlet compliant, indepently which libs it includes (Spring, Log4J, etc).

You know Spring is a lib and it delegates the class loading in the application server that contains it, so any class loading problem is responsibility of the app server.

On the other way I had the same problem with JSF (no Spring in that case), we use MyFaces and JBoss includes Mojarra, so JBoss loads Mojarra and our MyFaces classes aren't found. Who is the responsible in that case? Of course, JBoss and its ClassLoader architecture. Note we have solved the problem with JSF just disabling Mojarra in web.xml ... so, imho it's clear JBoss is the source of the problem.

There are many ways application (or library) can do class loading and in some cases does not even need to delegate it to application server in which they run.

Said that, I can asure you that if you load a class from your application and try to read annotations from it, it will work the same way in AS7 or in your standalone application.

I wrote application that does just that and it works on jboss 5,6 and 7. This works very simple if your annotated classess(entites) are part of deployed application.

Only case where It gets bit different for AS7 is when you have annotated classes packed as jboss module instead in your deployment (war,ear,ejb-jar).

Also that can be simply fixed by adding jandex index to your module.

Trick with Spring is that it does few other things than just vanilla classloading, this is reason why there are issues with this.

Or on short, spring tries to do some optimizations so annotations scanning can be faster, but that optimizations dont work properly with AS7 yet.

Given jira issue I linked in previous post, they are considering fixing that.

hope this explains my point of view.

--

tomaz

[eruiz]

Tomaz, what is the goal of doing class loading without delegating it to app server? Note the unique way to do that is by implementing your own ClassLoader ... I'm not know any lib (including Spring) that do that.

You argument seems right, but you should provide Spring docs that demonstrate what you are assuring, a simple issue is not sufficient to demonstrate what you said.

Anyway, neither it is a ClassLoader problem nor it is a Spring problem, Nicklas are right in a certain sense, the JEE 6 spec says:

EE.8.2.3 Library Conflicts

If an application includes a bundled version of a library, and the same library exists as an installed library, the instance of the library bundled with the application should be used in preference to any installed version of the library. This allows an application to bundle exactly the version of a library it requires without being influenced by any installed libraries. Note that if the library is also a required component of the Java EE platform version on which the application is being deployed, the platform version may (and typically will) take precedence.

Note JPA and JSF are required components, so they must be loaded by the app server and applications must be developed taking this rule in account (just as we do with Servlet API), that is, applications must be developed using JPA and JSF API but they must not assume any implementation because it will be provided by app server.

--

Enrique

[shailu777]

Hi All,

We have been facing similar experience with Spring 3.2 / JPA2 application. The JPA implementation is Hibernate 4. The entity manager is bootstrapped using Spring and we are using Hibernate from our application and not from the JBoss server. Spring correctly scans the jar files containing persistence files ( in our case its NOT named persistence.xml) and entities and hands the jar files to the Hibernate entity manager scanner so that it can look for entities. The jar urls begin with prefix "vfs". However the hibernate default scanner org.hibernate.ejb.packaging.NativeScanner fails to recognize the vfs files and ignores the jar files containing entities. So the culprit seems to be the hibernate in this case. I can say this because Spring has vfs related handling from 3 onwards. The solution seems to use org.jboss.as.jpa.hibernate.HibernateAnnotationScanner via hibernate.ejb.resource_scanner property. This however means including jboss dependencies in your applications. I have read that there is another jboss project "Jipijapa" specially addressing the ORM integration with application server.