[abhi0123]

jaikiran pai wrote:

As a workaround, try adding this jboss-web.xml to your .war/WEB-INF folder:

<?xml version="1.0"?>

<!DOCTYPE jboss-web PUBLIC
        -//JBoss//DTD Web Application 5.0//EN
        http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd>


<jboss-web>

            <resource-env-ref>
                <resource-env-ref-name>applicationParameterManager</resource-env-ref-name>
                <jndi-name>dummyJNDIName</jndi-name>
                <ignore-dependency/>
            </resource-env-ref>

</jboss-web>

Let us know if that gets you past this issue.

According to the dtd http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd, "ignore-dependency" is not a valid child element of " resource-env-ref". I believe I need to use the xsd and then make a change in the JBOSS_HOME/server/<servername>/deployers/metadata-deployer-jboss-beans.xml. http://community.jboss.org/thread/160804

After doing the above:

java.lang.ClassCastException: org.hibernate.ejb.HibernatePersistence cannot be cast to javax.persistence.spi.PersistenceProvider

[abhi0123]

Abhijit Sarkar wrote:

After doing the above:

java.lang.ClassCastException: org.hibernate.ejb.HibernatePersistence cannot be cast to javax.persistence.spi.PersistenceProvider

I figured that this is because of a conflict between the web application library and the JBoss ones. What I could not figure is how to load the web app library first. And yes, I read the following posts but those don't seem to work for JBoss 6.0.0.Final:

http://community.jboss.org/wiki/classloadingconfiguration

http://phytodata.wordpress.com/2010/10/21/demystifying-the-jboss5-jboss-classloading-xml-file/

[jaikiran]

Classloading a separate issue. To avoid confusion, please create a separate thread to discuss that issue.

[shep]

I actually tried this suggestion,  I'm am having the same sort of issues with classes using the @Resource annotation.  The first problem is "<ignore-dependency/>" is not supported under the <resource-env-ref> tag.  The second problem is I get this error after adding references....

"  Deployment "com.vocollecthealthcare.yosemite.device.OperatorDatastore" is in error due to the following reason(s): ** NOT FOUND Depends on 'com.vocollecthealthcare.yosemite.device.OperatorDatastore' ** "

I didn't use dummyJNDIName as you indicated, I used 'com.vocollecthealthcare.yosemite.device.OperatorDatastore'  as my jndi name.

here is a link to a discussion I started that I think is the same issue.  Also has more details on my implementation.

http://community.jboss.org/message/612809#612809

any help would be great.  I also have spring in the mix along with jersey.

[amberjboss1999]

Sorry to hijack this thread. But it seems like the post had the EXACT same problem as mine; due to servlet container picking up @Resource annotation that are meant to be @Repository and/or @Service for Spring to DI.

I also followed this example and constructed jboss-classloading.xml under WEB-INF/ for war, and  under META-INF for ear, without success:

EAR:

<classloading xmlns="urn:jboss:classloading:1.0"

          domain="myEAR.ear"

          export-all="NON_EMPTY"

          import-all="true"

          parent-first="false" />

WAR:

<classloading xmlns="urn:jboss:classloading:1.0"

          domain="myWAR.war"

          parent-domain="myEAR.ear"

          export-all="NON_EMPTY"

          import-all="true" />

Short of using a different version of Jboss ( AS 7), does anyone has any solution that works?

[amberjboss1999]

I think a lot of developers would probably appreciate the solution. This is simply solved by not using @Resource, instead you can use @Autowired, and/or with combination of @Qualifier, with the point being taking component scanning of @Resource out of the equation.

[abhi0123]

I don't know why you think developers would like using @Qualifier. @Qualifier with @Autowired is discouraged in Spring documentation, usage of @Resource is encouraged instead.

"If you intend to express annotation-driven injection by name, do not primarily use @Autowired, even if is technically capable of referring to a bean name through @Qualifier values. Instead, use the JSR-250 @Resource annotation, which is semantically defined to identify a specific target component by its unique name, with the declared type being irrelevant for the matching process."

http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/beans.html

[abhi0123]

Amber Crawford wrote:

know. I read the documentation and which is why originally I had the same problem as you. Until and unless Jboss raises this as a defect, or you change the component scanning hierarchy (which is not well documented), do you have a SOLUTION, I don't assume you have one yet. But if you did, I'd rather you being constructive, and post a SOLUTION.

Here're 2 things that need to be pointed out:

1. In case you're ignorant of the fact, which going by the tone of your post is a distinct possibility, writing in upper case in a forum means yelling. If you didn't get a solution, move on.

2. I didn't see a reference to the Spring documentation in your post and I am not in the business of reading minds. It is one thing working around a problem and it is another thing trying to make a discouraged solution look like a smart idea and when questioned, respond with ranting.

[amberjboss1999]

I don't believe I was yelling by uppercasing a word that you apparently don't have idea what the meaning of the word is.  I aim to solve a problem and as I stated before, I've tried other recommended route by Jboss but even they didn't have correct documentation to back up the solution.

So may I ask what the point is when posting on this forum, if not trying to get a solution?  It seems to me you are not problem solving oriented? The solution I proposed may not be sementically ieal, but it allows you to move on and continue development When I asked if you ever found the solution, and by the way you replied, you didn't. Try to contribute something constructive instead of ranting and complaining.

[abhi0123]

OK, you're the greatest thing that happened to the world since Thomas Edison. Let's move on.