May or may not be related, but... http://www.mail-archive.com/[EMAIL PROTECTED]/msg08398.html
-- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx ----- Original Message ----- From: "Lucas Gonzalez Pearson" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Friday, August 20, 2004 1:29 PM Subject: Re: Deploying Struts ??? > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
