Re: ClassFileTransformer in Tomcat 10 common classloader

2021-12-29 Thread Richard Huntrods

On 28.12.21 00:36, Chew Kok Hoor wrote:


We're using the old javax.servlet namespace for compatibility reasons.

 Some of our jar files are re-used by different web-apps, therefore we
placed them in the common classloader.

 Is it possible to convert them dynamically, just like how we do it for
servlets in the per app WEB-INF folder, by using the following in the
context file:




I have a similar situation. I run two sites on different servers. Today
I upgraded to TC 9.0.56 on both without incident. (I do the upgrades
manually from the tar.gz files).

However, in keeping up with where things are going, I also run a
development copy of the latest 10 (currently 10.0.14). Initially I ran
the offline converter, but as my main applications are still running in
production under 9.0.x, I don't really want to convert them from
javax.servlet to jakarta.servlet just yet.

My overall deployments are quite simple. I don't modify much on a stock
download of tomcat - just server.xml (to add HTTPS support for my certs)
and web.xml (to force HTTPS). Maybe 10 lines different in both files.

My libraries for the applications are now stored in webapps rather than
the common library area, but ALL my stuff still run javax.servlet.

I found that by adding the single line "  " after the  in the main
conf/context.xml file, everything auto-converts and runs perfectly.

Frankly, for my purposes, this has to be the simplest solution.

Cheers,

-R


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: ClassFileTransformer in Tomcat 10 common classloader

2021-12-28 Thread Olaf Kock


On 28.12.21 00:36, Chew Kok Hoor wrote:
> We're using the old javax.servlet namespace for compatibility reasons.
>
> Some of our jar files are re-used by different web-apps, therefore we
> placed them in the common classloader.
>
> Is it possible to convert them dynamically, just like how we do it for
> servlets in the per app WEB-INF folder, by using the following in the
> context file:
>
> 

On top of what's already discussed:

You're not giving any indication that you need jakarta-ee at all, so if
you use javax.servlet: Just do it, and deploy on Tomcat 9 - that's a
very good choice that won't go away any time soon. If there's no need
for Tomcat 10, save yourself the hassle - at least for now.

Later on, you might want to divide your webapps into two groups: Those
that don't require any compatibility handling, because they're fully
migrated (or automatically migratable) to jakarta-ee, and those that
don't. Easy setup with a reverse proxy sending the traffic to either of
the two (or multiple) backends.

Olaf




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: ClassFileTransformer in Tomcat 10 common classloader

2021-12-27 Thread Chew Kok Hoor
Sure Chris, thanks for advice!

Have a great day!

Regards,
Kok Hoor

On Tue, Dec 28, 2021 at 8:23 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Kok Hoor,
>
> On 12/27/21 19:08, Chew Kok Hoor wrote:
> >  Thanks for prompt response. We have like maybe 50 webapps, and they
> are
> > common (except that they have different database connection or maybe some
> > html file changes). Which is why we prefer sharing libraries for ease of
> > deployment and updates.
>
> See, I see this in the exact opposite way: deployment seems easier (to
> me) if everything is self-contained. I suppose "update shared libraries,
> bounce Tomcat" is pretty easy, but so should "update individual
> application dependencies, bounce individual application".
>
> I value being able to update each application separately, too, in case
> of incompatibility, etc.
>
> >  But I do agree, sharing libraries have their own shortcomings. Just
> > wondering if there are any workarounds at the moment for shared jar
> files.
>
> You should take a look at the offline web app conversion tool:
> https://tomcat.apache.org/download-migration.cgi
>
> You could probably take your web application, copy all of the shared
> libraries into it, run the offline converter, then copy the resulting
> (converted) libraries into your shared directory.
>
> -chris
>
> > On Tue, Dec 28, 2021 at 8:05 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Kok Hoor,
> >>
> >> On 12/27/21 18:36, Chew Kok Hoor wrote:
> >>> Hi,
> >>>
> >>>   We're using the old javax.servlet namespace for compatibility
> >> reasons.
> >>>
> >>>   Some of our jar files are re-used by different web-apps,
> therefore
> >> we
> >>> placed them in the common classloader.
> >>>
> >>>   Is it possible to convert them dynamically, just like how we do
> it
> >> for
> >>> servlets in the per app WEB-INF folder, by using the following in the
> >>> context file:
> >>>
> >>> 
> >>
> >> Any reason not to simply *stop* using the shared ClassLoader and instead
> >> bundle everything with each web application?
> >>
> >> How many web apps are running in the same container? How many libraries
> >> are you sharing?
> >>
> >> I've never seen a good argument for sharing libraries like this. RAM is
> >> cheap and plentiful, and code is very small.
> >>
> >> -chris
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: ClassFileTransformer in Tomcat 10 common classloader

2021-12-27 Thread Christopher Schultz

Kok Hoor,

On 12/27/21 19:08, Chew Kok Hoor wrote:

 Thanks for prompt response. We have like maybe 50 webapps, and they are
common (except that they have different database connection or maybe some
html file changes). Which is why we prefer sharing libraries for ease of
deployment and updates.


See, I see this in the exact opposite way: deployment seems easier (to 
me) if everything is self-contained. I suppose "update shared libraries, 
bounce Tomcat" is pretty easy, but so should "update individual 
application dependencies, bounce individual application".


I value being able to update each application separately, too, in case 
of incompatibility, etc.



 But I do agree, sharing libraries have their own shortcomings. Just
wondering if there are any workarounds at the moment for shared jar files.


You should take a look at the offline web app conversion tool:
https://tomcat.apache.org/download-migration.cgi

You could probably take your web application, copy all of the shared 
libraries into it, run the offline converter, then copy the resulting 
(converted) libraries into your shared directory.


-chris


On Tue, Dec 28, 2021 at 8:05 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Kok Hoor,

On 12/27/21 18:36, Chew Kok Hoor wrote:

Hi,

  We're using the old javax.servlet namespace for compatibility

reasons.


  Some of our jar files are re-used by different web-apps, therefore

we

placed them in the common classloader.

  Is it possible to convert them dynamically, just like how we do it

for

servlets in the per app WEB-INF folder, by using the following in the
context file:




Any reason not to simply *stop* using the shared ClassLoader and instead
bundle everything with each web application?

How many web apps are running in the same container? How many libraries
are you sharing?

I've never seen a good argument for sharing libraries like this. RAM is
cheap and plentiful, and code is very small.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: ClassFileTransformer in Tomcat 10 common classloader

2021-12-27 Thread Chew Kok Hoor
Hi Chris,

Thanks for prompt response. We have like maybe 50 webapps, and they are
common (except that they have different database connection or maybe some
html file changes). Which is why we prefer sharing libraries for ease of
deployment and updates.

But I do agree, sharing libraries have their own shortcomings. Just
wondering if there are any workarounds at the moment for shared jar files.

Thanks.

Regards,
Kok Hoor


On Tue, Dec 28, 2021 at 8:05 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Kok Hoor,
>
> On 12/27/21 18:36, Chew Kok Hoor wrote:
> > Hi,
> >
> >  We're using the old javax.servlet namespace for compatibility
> reasons.
> >
> >  Some of our jar files are re-used by different web-apps, therefore
> we
> > placed them in the common classloader.
> >
> >  Is it possible to convert them dynamically, just like how we do it
> for
> > servlets in the per app WEB-INF folder, by using the following in the
> > context file:
> >
> > 
>
> Any reason not to simply *stop* using the shared ClassLoader and instead
> bundle everything with each web application?
>
> How many web apps are running in the same container? How many libraries
> are you sharing?
>
> I've never seen a good argument for sharing libraries like this. RAM is
> cheap and plentiful, and code is very small.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: ClassFileTransformer in Tomcat 10 common classloader

2021-12-27 Thread Christopher Schultz

Kok Hoor,

On 12/27/21 18:36, Chew Kok Hoor wrote:

Hi,

 We're using the old javax.servlet namespace for compatibility reasons.

 Some of our jar files are re-used by different web-apps, therefore we
placed them in the common classloader.

 Is it possible to convert them dynamically, just like how we do it for
servlets in the per app WEB-INF folder, by using the following in the
context file:




Any reason not to simply *stop* using the shared ClassLoader and instead 
bundle everything with each web application?


How many web apps are running in the same container? How many libraries 
are you sharing?


I've never seen a good argument for sharing libraries like this. RAM is 
cheap and plentiful, and code is very small.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



ClassFileTransformer in Tomcat 10 common classloader

2021-12-27 Thread Chew Kok Hoor
Hi,

We're using the old javax.servlet namespace for compatibility reasons.

Some of our jar files are re-used by different web-apps, therefore we
placed them in the common classloader.

Is it possible to convert them dynamically, just like how we do it for
servlets in the per app WEB-INF folder, by using the following in the
context file:



Thanks.

Regards,
Kok Hoor