Sorry guys, I have revise my predication. The sitemap still works but the log output (with the version from 2001-09-02) is written in different logfiles. The exceptions for example are written in another WEB-INF/logs dir. If someone is interested, I could deliver the different log files for two projects. JOERN_HEID -----Ursprüngliche Nachricht----- Von: Jörn Heid [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 7. September 2001 14:24 An: [EMAIL PROTECTED] Betreff: General question about virtual hosts and C2 - State With the hint of Leo Sutic and the new LogKit (thanks to Giacomo Pati) it now works for me (two projects for now). I will test it now for further problems and post it here if I find some. Thanks guys. JOERN_HEID -----Ursprüngliche Nachricht----- Von: Berin Loritsch [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 6. September 2001 17:44 An: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Betreff: Re: General question about virtual hosts and C2 Giacomo Pati wrote: > > Quoting Berin Loritsch <[EMAIL PROTECTED]>: > > > Leo Sutic wrote: > > > > > > Jörn, > > > > > > the crux is the compilation of the sitemap. The sitemap compiles to > > > org.apache.cocoon.www.sitemap_xmap for *all* webapps. Since the > > sitemap > > > class is loaded using the same classloader as cocoon (since you put > > the libs > > > in the Resin lib directory), the same class gets loaded for different > > > webapps. > > > > Actually, you are also experiencing issues with the classloader (for > > instance, > > the cross polination of log events. I will post this issue on the > > Avalon-dev > > list. Hopefully, with Giacomo's LogKitManager this can be dealt with. > > Cocoon > > does not do anything special with the LogKit Hierarchy to force > > different > > roots or default loggers for different contexts. This could also be > > taken > > care of with a classloader solution I proposed a while ago. > > > > TO THE AVALON TEAM: > > > > LogKit is cross-polinating log events to log targets that belong in > > another > > web context. The change in configuration is that LogKit is now loaded > > in a > > base ClassLoader, and not in the unique ClassLoaders that are used for > > web > > apps. The result is that the Heirarchy object is shared between all > > contexts. > > We need a way to enforce all Contexts to be separate. > > The main problem IMHO is the deployment of the needed jar for cocoon (and the > cocoon.jar itself) in the root lib/ of resin/tomcat instead of using the > complete war file. LogKit is only one aspect that may raise a problem. I can > imaging other part of the cocoon system would suffer of it as well. True, but Avalon components need to use ContextClassLoaders if they can to ensure the proper instance is loaded--helping with things like this. Xalan and possibly Xerces also have been advised and incorporated those changes. That enables these libraries to be loaded from the $JAVA_HOME/jre/lib/ext directory without classloader repercussions. The reason I posted this to both lists is so we can handle the LogKit issue. > > Giacomo > > > > > > > > > > > So, for each webapp/cocoon.xconf > > > > > > change > > > > > > <!-- The ProgamGenerator builts programs from a XML document written > > in > > > a MarkupLanguage. > > > auto-reload: > > > root-package: persistent code repository. > > > preload: --> > > > <program-generator> > > > <parameter name="auto-reload" value="true"/> > > > <parameter name="root-package" value="org.apache.cocoon.www"/> > > > ^^^^^^^^^^^^^^^^^^^^^ > > > <parameter name="preload" value="true"/> > > > </program-generator> > > > > > > this into something unique for each webapp. Hopefully it works. In > > Tomcat > > > you just get a load of exceptions. > > > > > > /LS > > > > > > > -----Original Message----- > > > > From: Jörn Heid [mailto:[EMAIL PROTECTED]] > > > > Sent: den 6 september 2001 11:38 > > > > To: Cocoon-Dev > > > > Subject: General question about virtual hosts and C2 > > > > > > > > > > > > The main question: Can Cocoon 2 only run as a webapp (with a > > context)? > > > > > > > > I'm using Resin with several virtual hosts. To make this easier > > > > to configure > > > > I put all the required cocoon libs to the lib dir of resin. > > > > The projects are sepated into different directories but not inside > > the > > > > webapp dir of resin: > > > > d:\www\PROJECT1\public > > > > d:\www\PROJECT2\public and so on. > > > > Each directory has it's own WEB-INF and server.xml in it. > > > > The projects have their own hostnames (virtual hosts), but no > > /cocoon (or > > > > what ever) context. > > > > > > > > With this configuration (C2b2) it seems that the (different) > > pipelines are > > > > mixed sometimes. When requesting pages from project1 some(!) log > > > > entries are > > > > written in the log files of project2. > > > > > > > > So my question is if Cocoon 2 only works with a context (quite > > > > difficult as > > > > you need to use the rewrite engine of apache) or *should* it work > > for my > > > > configuration? > > > > > > > > When running just one virtual host it all works fine. > > > > > > > > JOERN_HEID > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, email: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
