tomcat-dev mailing list archives

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.kolinko@gmail.com>
>
>> 2010/8/3 Lohner Roland <loczaj@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org