Dear Mark, Rainer, Konstantin, Sylvain,
Thank you for your answers. (and for Tomcat ;-)
Regards, R.
2010/8/5 Sylvain Laurent <sylvain.laur...@m4x.org>
>
> I see 2 options for your case :
>
> - either use JRebel which allows to reload classes even in jars that would be
> the common or shared classloaded (I use it all the times, it's fabulous and
> pays for itself very quickly)
> - or try JBoss which has a Unified Class Loader, and as far as I understood
> it, it tries to share classes between applications while allowing reloads (I
> never used it in this way though)
>
> Regards,
> Sylvain
>
> On 5 août 2010, at 12:57, Lohner Roland wrote:
>
> > Dear Mark, Rainer, Konstantin,
> >
> > Thank you for your fast and detailed answers.
> >
> > You are right, the proposal is erroneous. However my intention was not to
> > give an excellent implementation solving the problem, but to start a
> > conversation about it and to provide a 0th approach, which can be reworked,
> > refined by developers who have detailed insight in the Tomcat system
> > architecture.
> >
> > You suggested the usage of the common or the shared class loader. Putting
> > all interfaces, and _all the classes they need_, into a separate JAR and
> > putting this JAR into ${catalina.base}/lib would really solve the problem.
> > But this solution has a serious disadvantage.
> >
> > The disadvantage appears in development time. The common and the shared
> > class loaders – as far as I know – are not reloadable. This means if any of
> > the classes loaded by them changes the whole Tomcat server and so even all
> > another independent web applications must be restarted for the changes to
> > take effect. The number of shared interfaces and their dependent classes can
> > be remarkable. When these types change, a full restart is needed instead of
> > some web application reloads, which is supported by widely applied
> > development tools like Web Tools Platform (WTP) Project. The full restart
> > means extra overheat increasing the turnaround time of development cycles.
> >
> > An another, only minor problem is that the deployment of the application
> > fallen to pieces must be done manually (increasing turnaround delay again).
> > WTP for example does not support the deployment of jar files in arbitrary
> > folders but only deployment of war files to a ‘webapps like’ folder.
> >
> > Turnaround time of development cycles is a significant factor in the costs
> > of a software solution. Accordingly, the possibility of using shared classes
> > in a reloadable (and by development tools supported) way would be valuable
> > in Tomcat.
> >
> > Regards,
> > Roland
> >
> >
> > 2010/8/3 Konstantin Kolinko <knst.koli...@gmail.com>
> >
> >> 2010/8/3 Lohner Roland <loc...@gmail.com>:
> >>> Dear Developers,
> >>>
> >>> I am writing about a proposal for a new feature in Tomcat.
> >>>
> >>
> >> (...)
> >>
> >>> so the only solution at the
> >>> moment is to use a J2EE container and deploy an enterprise module which
> >>> causes unnecessary overheat.
> >>
> >> I think the following should work:
> >>
> >> 1. Separate the interfaces, and _all the classes they need_,
> >> into a separate JAR.
> >> 2. Put the JAR into ${catalina.base}/lib.
> >> 3. _Remove_ all those shared classes from web applications!
> >> (Because otherwise classes loaded from web applications have priority
> >> over the shared ones, as explained in
> >> http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
> >> )
> >>
> >> 4. If you need some shared service, place it into JNDI
> >> (GlobalNamingResources element in server.xml).
> >> You can also add a Listener to server.xml to preload some classes or
> >> instantiate any static object.
> >>
> >> 5. Restart Tomcat.
> >>
> >>>
> >>> A less elaborate, hackish, but basically working implementation of this
> >>> special web application class loader is attached to this email.
> >>
> >> The attachment was removed by mailing list software.
> >> Maybe if you rename it to *.txt it will be allowed, but it is just a guess.
> >> Anyway, if it works how you describe it it seeks for trouble. A web
> >> application and be unloaded (stopped, reloaded) at any time. Since
> >> that moment any classes loaded by its classloader should not be
> >> accesses any more. Thus, no other web applications should keep
> >> references to them.
> >>
> >>
> >> Best regards,
> >> Konstantin Kolinko
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
