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
>
>
