I thought so, but try renaming a .war file, and redeploying it, we had Smith.war and John.war, and whenever Smith deployed his war, all his classes would replace the ones that John had deployed before...
The only solution we found was to split tomcat and jboss, and smith and john now have each one a local tomcat that connects to the JBOSS server using jndi.. itīs not the best.. but at least we donīt keep getting collision with the jsps Lucas ----- Original Message ----- From: "Jim Barrows" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Friday, August 20, 2004 2:19 PM Subject: RE: Deploying Struts ??? > -----Original Message----- > From: Lucas Gonzalez Pearson [mailto:[EMAIL PROTECTED] > Sent: Friday, August 20, 2004 10:15 AM > To: Struts Users Mailing List > Subject: Re: Deploying Struts ??? > > > If you deploy two different war to a jboss server, the one > that is deployed > the latest will be used. > I am experiencing this problem. Maybe Jboss classloader is > does not support > hierarchies? It's possible. from http://java.sun.com/developer/technicalArticles/Servlets/servletapi2.3/ I found this: Class Loaders Here's a small change with a big impact: In API 2.3, a servlet container (a.k.a. the server) will ensure that classes in a Web application not be allowed to see the server's implementation classes. In other words, the class loaders should be kept separate. That doesn't sound like much, but it eliminates the possibility of a collision between Web application classes and server classes. That had become a serious problem because of XML parser conflicts. Each server needs an XML parser to parse web.xml files, and many Web applications these days also use an XML parser to handle reading, manipulation, and writing of XML data. If the parsers supported different DOM or SAX versions, that could cause an irreparable conflict. The separation of class scope solves this issue nicely. Which would indirectly support Jboss not being client, It's Serlvet 2.3 though... so maybe not. My understanding is that all web apps should have different class loaders. > > > ----- Original Message ----- > From: "Jim Barrows" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > Sent: Friday, August 20, 2004 12:54 PM > Subject: RE: Deploying Struts ??? > > > > > > -----Original Message----- > > From: Lykins Don H Contr AFSAC/ITS [mailto:[EMAIL PROTECTED] > > Sent: Friday, August 20, 2004 8:47 AM > > To: 'Struts Users Mailing List' > > Subject: RE: Deploying Struts ??? > > > > > > What are you referring to as a "classpath loader"?? > > Sorry.. class loader. > > > > > Won't this cause conflicts if each project has their own WAR > > with struts inside? > > Nope, not at all. > > > What happens if they use different versions of Struts in each > > WAR file? > > > Doesn't matter, since each war in essence has it's own class > loader, and > will load classes from the local war. > > If you really want to understand what's going on, I would > highly recommend > reading the J2EE spec yourself. I'm pretty much at the end of > what I know > about class loading withing a J2EE environment, and only know > this because > my boss wanted to do this and assigned me the task of doing it. After > several weeks of pouring over documents and specs, I realized > what I've just > told you. You can, but with any jar file that has to read or write to > anything in the webapp, you cannot do it if the class is loaded from > anyplace but the war. > > > > > > > > > > -----Original Message----- > > From: Jim Barrows [mailto:[EMAIL PROTECTED] > > Sent: Friday, August 20, 2004 11:43 AM > > To: Struts Users Mailing List > > Subject: RE: Deploying Struts ??? > > > > > > > > > > > -----Original Message----- > > > From: Lykins Don H Contr AFSAC/ITS > [mailto:[EMAIL PROTECTED] > > > Sent: Friday, August 20, 2004 8:25 AM > > > To: 'Struts Users Mailing List' > > > Subject: RE: Deploying Struts ??? > > > > > > > > > so how do you suggest we deploy struts? > > > each developer bundle struts in their own WAR files? > > > > Yes. Only way to do it. It's a classpath loader, and the way > > it gets defined by the J2EE spec on how things get loaded and > > from where. > > > > Believe me I've tried and tried and tried.. and it always > > comes back to the spec. Unfortunately, the spec is right... > > there could be worse issues if they did it differently. > > > > > > > > > > > > -----Original Message----- > > > From: Jim Barrows [mailto:[EMAIL PROTECTED] > > > Sent: Friday, August 20, 2004 11:12 AM > > > To: Struts Users Mailing List > > > Subject: RE: Deploying Struts ??? > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Lykins Don H Contr AFSAC/ITS > > [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, August 20, 2004 7:57 AM > > > > To: '[EMAIL PROTECTED]' > > > > Subject: Deploying Struts ??? > > > > > > > > > > > > Looking for pointers on how to best deploy struts based, JSP > > > > applications. > > > > I am using JDeveloper 10G which ships with Struts source... > > > > deploying to Jrun. > > > > > > > > Scenario: > > > > I am one of 2 programmers, each developing a separate JSP , > > > > but sharing a common database > > > > > > > > When each JSP is developed and deployed a unique and separate > > > > WAR file is created and deployed to our app server. > > > > -- but it seems duplicative -- as each WAR contains all the > > > > struts code as well...??? > > > > > > > > any way to share the Struts source so we don't duplicate? > > > > May Still want to deploy each jsp app in separate WAR files, > > > > but find someway to deploy struts centrally??? > > > > > > Most containers hava container wide library you can put > > > common libraries in... however you don't want to do this with > > > struts because you will have serious issues with finding the > > > struts-config.xml files. > > > > > > > > > > > > > > > > > > > Don Lykins > > > > AFSAC > > > > 937-257-4295 x4539 > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
