Andrew, Can you add some information to our JpaTicketRegistry about how to configure JBoss, JPA, and CAS? I don't use JBoss so I would not be qualified to write this documentation :-)
Thanks Scott On Tue, May 12, 2009 at 5:35 AM, Andrew Tillinghast <[email protected]>wrote: > Going back through the JBoss 5.X documentation I found the fix for > the persistence problem, simply remove all the persistence related jars from > the client lib directory and instead add the jbossall-client.jar. > jbossall-client.jar > is actually an empty jar that just defines a classpath reference back to the > JBoss jars. > > -Andrew > > On May 12, 2009, at 10:09 AM, Andrew Tillinghast wrote: > > > Thanks to Bruno pointing me in the right direction I've gotten a little > somewhere on this, I can now get CAS 3.3.2 up and running on JBoss 5.x in > the default or standard context. I still have the persistence error when > bringing it up in the all context, which of course has to be the context we > need to run it in. Haven't addressed the JpaTickets yet, going to take it a > piece at a time. I'll post my ear file and directions in a wiki when I've > got it all wrapped up. > > -Andrew > > On May 11, 2009, at 3:34 PM, Bruno Melloni wrote: > > Andrew, I am quite confused by your situation. If it wasn’t possible to > use in your apps the version of libraries that you need, people would flee > jBoss like the plague. > > You might need to add the persistence jar(s) of the version you need for > CAS inside the isolated EAR (probably in the WAR’s WEB-INF/lib folder). I > may be wrong, but I don’t think that you are ‘forced’ to rely on jBoss for > the persistence jar. > > My (admittedly limited) understanding is that when you run in an isolated > EAR you are using a separate classloader, and that classloader will look for > classes **first** in the local app and only if it does not find them it > will go to the jBoss libraries. And of course… by being isolated, no other > application will see those classes that have a different version than the > one provided by jBoss. > > > b. > > ------------------------------ > *From:* Andrew Tillinghast > [mailto:[email protected]<[email protected]> > ] > *Sent:* Monday, May 11, 2009 1:49 PM > *To:* [email protected] > *Subject:* Re: [cas-user] CAS 3.3.2 and JBoss 5.0.1 with JpaTicketReistry > connecting to MS-SQL > > The errors I'm getting are all persistence errors, I think the issue is > that Persistence can't be "isolated" because the persistence depends on > jboss. > > -Andrew > > On May 11, 2009, at 2:31 PM, Bruno Melloni wrote: > > > I only suggested dropping back to the 4.x version for testing purposes. > Isolation should be resolvable through configuration/packaging on 5.0 and > from past experience I know that the jBoss guys are very interested in not > causing conflicts. > > b. > ------------------------------ > *From:* Andrew Tillinghast > [mailto:[email protected]<[email protected]> > ] > *Sent:* Monday, May 11, 2009 1:24 PM > *To:* [email protected] > *Subject:* Re: [cas-user] CAS 3.3.2 and JBoss 5.0.1 with JpaTicketReistry > connecting to MS-SQL > > The CAS.war I'm using runs just fine on Tomcat 6. I'd keep it there but for > our environment I also need to get Coldfusion running and that doesn't > support tomcat (officially anyways) I might drop back to jboss 4.3 just > wanted to go with latest "stable" builds on everything now rather then > later. > > -Andrew > > On May 11, 2009, at 2:14 PM, Bruno Melloni wrote: > > > > That is strange. My understanding is that jBoss will respect isolation if > you configure your EAR that way. > > A couple tests that you should try: > > 1) Try deploying as a WAR on Tomcat 6. If it doesn’t work there, the > problem is something else. > > 2) Try deploying on jBoss 4.2/4.3 as an EAR. If it doesn’t work there – > with the isolation – then either the isolation is incorrect, or the build > has problems (which you should have caught on step (1). I know with > certainty that in 4.3 (which is nothing but 4.2 plus extra toys) CAS works. > I run 4.3 on Java 6, using CAS 3.3.1. > > If the above does not help… you might need some help from either Scott or > the jBoss forum, depending on the cause of the problem (I am just a CAS user > and not terribly knowledgeable about CAS). Like with CAS, the jBoss forum > is (quietly) monitored by jBoss staff, and you should be able to get some > answers… even if it might take a few days. > > Good luck. > > bruno > ------------------------------ > *From:* Andrew Tillinghast > [mailto:[email protected]<[email protected]> > ] > *Sent:* Monday, May 11, 2009 12:54 PM > *To:* [email protected] > *Subject:* Re: [cas-user] CAS 3.3.2 and JBoss 5.0.1 with JpaTicketReistry > connecting to MS-SQL > > > Thanks for the information on deploying CAS as an EAR, I've done some > experimentation with just trying to get the packaged > "cas-server-webapp-3.3.2.war" > from the modules directory to deploy. I'm using the pre-packaged so that I > know my POM and settings aren't the breaking point. Even with using > the isolation settings in jboss-app.xml the deploy still fails, I suppose to > some extent that's a failure of the isolation in JBoss. Anyways it seems the > key issue is javax.persistence, cas-server-core uses persistence-api 1.0 > and JBoss uses 2.0.0.Beta1, Should I be able to change the dependancy in the > server-core pom.xml and have it work? If I do the change in the pom, I can > change my pom to use the snapshot so as not to rebuild from the repository > correct? > > -Andrew > > On May 7, 2009, at 11:36 AM, Bruno Melloni wrote: > > > > > jBoss classloader strategy is very powerful if you understand it... but it > can bite you since it does not necessarily follow the JEE standard. > > Instead of deploying your WAR file... try encapsulating the WAR in an EAR > and use a META-INF/jboss-app.xml to enforce isolation. The content would > be something like this: > > <?xml version="1.0" encoding="UTF-8"?> > <jboss-app> > <loader-repository> > com.yourcompany.cas:archive=cas.ear > <loader-repository-config> > java2ParentDelegation=false > </loader-repository-config> > </loader-repository> > </jboss-app> > > I use that approach on jBoss 4.3 to avoid CAS-jBoss classloader problems. > > -----Original Message----- > From: Marvin Addison > [mailto:[email protected]<[email protected]> > ] > Sent: Thursday, May 07, 2009 8:27 AM > To: [email protected] > Subject: Re: [cas-user] CAS 3.3.2 and JBoss 5.0.1 with JpaTicketReistry > connecting to MS-SQL > > > > > That got me farther, but new error: > > > > 21:46:15,229 ERROR [AbstractKernelController] Error installing to Start: > > name=persistence.unit:unitName=#CasPersistence state=Create > > java.lang.ClassCastException: org.hibernate.ejb.HibernatePersistence cannot > > be cast to javax.persistence.spi.PersistenceProvider > > > This is almost certainly a classloader problem since > org.hibernate.ejb.HibernatePersistence clearly implements > javax.persistence.spi.PersistenceProvider, > > http://docs.jboss.org/hibernate/stable/entitymanager/api/org/hibernate/ejb/HibernatePersistence.html > . > Recall that in Java a class must assignment compatible _and_ sourced > from the same classloader in order for a cast to succeed; a > ClassCastException will be thrown if both conditions are not met. > > > > > Is anyone out there using Jboss 5.0.1 with CAS 3.3.2 ? > > Thankfully, no. We run CAS 3.0.6 in production on JBoss 4.0.4, but > we're moving to Tomcat 6 in the near future. JBoss is simply too > complex for our needs with respect to CAS. Complicating that, JBoss > 5.0 is new and dramatically different. I've looked at a lot of JBoss > 4.x stack traces over the past few years, but what you cited is > completely foreign to me. The new JBoss microkernel/microcontainer is > just a totally new beast. > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > -- > > > > You are currently subscribed to [email protected] as: > [email protected] > > > > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > > You are currently subscribed to [email protected] as: > [email protected] > > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > > You are currently subscribed to [email protected] as: > [email protected] > > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > > You are currently subscribed to [email protected] as: > [email protected] > > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > > You are currently subscribed to [email protected] as: > [email protected] > > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
