On Thu, Dec 30, 2021 at 03:16:51PM -0500, Michael B Allen wrote:
> On Thu, Dec 30, 2021 at 10:57 AM Christopher Schultz
> wrote:
> >
> > You mean like ServletContext.getRealPath?
>
> Honestly I'm not sure how I feel about getRealPath. On the one hand, I
> don't think it's reasonable to just
On Thu, Dec 30, 2021 at 10:57 AM Christopher Schultz
wrote:
>
> You mean like ServletContext.getRealPath?
Honestly I'm not sure how I feel about getRealPath. On the one hand, I
don't think it's reasonable to just pretend that applications only
exist in the vacuum of space. There are many
Michael,
On 12/29/21 14:54, Michael B Allen wrote:
On Wed, Dec 29, 2021 at 2:07 PM Mark Thomas wrote:
One of the advantages of moving to Eclipse is that everyone involved in
the spec, not just the spec lead, has an equal say in what goes into the
spec.
That sounds like design by committee
On 12/29/2021 2:54 PM, Michael B Allen wrote:
On Wed, Dec 29, 2021 at 2:07 PM Mark Thomas wrote:
One of the advantages of moving to Eclipse is that everyone involved in
the spec, not just the spec lead, has an equal say in what goes into the
spec.
That sounds like design by committee which
On Wed, Dec 29, 2021 at 2:07 PM Mark Thomas wrote:
> One of the advantages of moving to Eclipse is that everyone involved in
> the spec, not just the spec lead, has an equal say in what goes into the
> spec.
That sounds like design by committee which is my concern. IMO the only
way to design a
On 29/12/2021 15:55, Michael B Allen wrote:
On Tue, Dec 28, 2021 at 10:52 AM Mark Thomas wrote:
Actually it seems the migration tool behind this feature:
https://github.com/apache/tomcat-jakartaee-migration
is a better and more general solution. If it's just re-writing package
names,
On Tue, Dec 28, 2021 at 10:52 AM Mark Thomas wrote:
>
> On 28/12/2021 14:58, Michael B Allen wrote:
> > On Tue, Dec 28, 2021 at 3:29 AM Johan Compagner
> > wrote:
> >>
> >> Will that really work?
> >
> > No.
> >
> > Clearly I'm not paying attention because after reading surprisingly
> > little
On 28/12/2021 14:58, Michael B Allen wrote:
On Tue, Dec 28, 2021 at 3:29 AM Johan Compagner wrote:
Will that really work?
No.
Clearly I'm not paying attention because after reading surprisingly
little information about this fundamental incompatibility and
downloading and trying Tomcat 10,
i think the whole point was that they had to break with the "javax" naming
because oracle doesn't allow that outside it stuff.
not sure if Tomcat 10 would be allowed to just have both classes/interfaces
for compatibility
Also this would be a big hurdle moving forwards (and not sure if everything
On Tue, Dec 28, 2021 at 3:29 AM Johan Compagner wrote:
>
> Will that really work?
No.
Clearly I'm not paying attention because after reading surprisingly
little information about this fundamental incompatibility and
downloading and trying Tomcat 10, there is no way to use a
javax.servlet
Will that really work?
tomcat 10 internally really expects jakarta.xxx now right?
so if you have a class MyServlet extends javax.Servlet
i don't think tomcat 10 will do anything with that (if that is not
converted first through the migration tool)
I have a feeling that you really can't mix, but
yeap, also take note libs that depend on the new namespace and taglibs
On Tue, Dec 28, 2021 at 8:35 AM Michael B Allen wrote:
>
> Hello Tomcat Users,
>
> Does anyone have a sense of how many people are using the jakarta.servlet API?
>
> I have a product that includes some classes that use
Hello Tomcat Users,
Does anyone have a sense of how many people are using the jakarta.servlet API?
I have a product that includes some classes that use javax.servlet and
I'm trying to figure out how to support people who want to use
jakarta.servlet. I plan to install Tomcat 10 momentarily but I
13 matches
Mail list logo
