Re: Remove of Useless Maven Projects

[Mark Struberg]

Integration is always a split effort. No matter whether you put it into tomcat 
or owb it will be 'wrong' for half the people ;)

If we put the integration into tomcat they'd still need to download and add the 
necessary other modules from owb. What if they want the JSF integration as 
well? -> download that exact module (in the right version!) from OWB site. etc.

LieGrue,
strub




> Am 01.07.2020 um 14:00 schrieb Gurkan Erdogdu :
> 
> Not fighting, just for the benefits of the both tomcat and owb, this is
> duplicate effort both in owb and tomcat.
> 
> if you feel the best to stay in owb, no problem but I thought that if it is
> in tomcat, it is natural to download via tomcat, no need to have
> configration,  more community, and do more innovation with more users
> 
> And also I am not sure that tomcat community will accept that proposal :)
> 
> 
> 
> On 1 Jul 2020 Wed at 14:53 Romain Manni-Bucau  wrote:
> 
>> This module has some users - don't know if tomcat-owb has, maybe Rémy you
>> have some insights?  - but these last years we got most users moving to
>> tomee or meecrowave cause it is better integrated, ready to run and has
>> modern flavors (embedded vs standalone tomcat) enabling modern deployments
>> (thinking strongly to k8s + CDS).
>> Only remaining case is bare metal tomcat where tomee takes most users these
>> days because it is well tooled - maven, gradle and testing. So at the end
>> this module is mainly for historical advanced users.
>> Concretely this module has ~300 downloads/month (to compare to the 20k of
>> owb-impl module).
>> 
>> In any case, I don't think Tomcat will not promote CDI and any CDI/OWB
>> support will likely be redirected here at some point so moving is an
>> useless indirection.
>> Also why Tomcat is so popular is that it is a servlet container (a bit more
>> but just to share the idea), so it is used by everyone, if you get more you
>> will get the exact same issue than with a full EE container: "it is too
>> much for me, let's grab something else".
>> Microprofile proves that: it does not even need a servlet layer at all
>> theoretically.
>> In that regard TomEE would be a better home but it is not the goal of the
>> project to do this light integration today - and we have a few alternative
>> at apache.
>> It is also highly consistent with meecrowave to have @owb. While we
>> maintain meecrowave we maintain this module sounds like a very fair
>> assumption.
>> 
>> @Gurkan Erdogdu  can you clarify why you fight so
>> strongly to drop that module we own since years and not jetty one for
>> example? I totally fail to see the point.
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le mer. 1 juil. 2020 à 13:03, Gurkan Erdogdu  a
>> écrit :
>> 
>>> All other specs at the moment consumes or will consume CDI core. Even if
>>> not, it must be. CDI is somebit different from other specs (especially I
>> am
>>> talking about the injection part) and now your observation may not be
>> true
>>> anymore. (As you said CDI consumes servlet but not the other way).
>>> 
>>> I am not agree with that when Tomcat embeds CDI , it also support EJB,
>>> Security etc. No, it is not .
>>> 
>>> Who currently uses our tomcat7 module? Do you know its popularity? I
>>> suspect that is large enough community on this. I started to wrote this
>>> tomcat7 module years years ago because, CDI is not in the same state as
>> it
>>> is currently.
>>> 
>>> But within Tomcat, it can reach and develop further community. One can
>> use
>>> Tomcat without external configration and update (like owb did) and on top
>>> of that they can extend Tomcat naturally. With single download of Tomcat,
>>> you also get fantastic CDI platform.
>>> 
>>> I think this is really a great idea.
>>> 
>>> Gurkan
>>> 
>>> On 1 Jul 2020 Wed at 13:35 Mark Struberg 
>>> wrote:
>>> 
 As long as Tomcat doesn't release the integration as part of their core
 build we can stop the whole discussion!
 
 -1 on dropping webbeans-tomcat7
 
 
 Once there is a good alternative in the main build in tomcat we can
 discuss this again.
 
 LieGrue,
 strub
 
 
 
> Am 01.07.2020 um 12:01 schrieb Romain Manni-Bucau <
>>> rmannibu...@gmail.com
> :
> 
> Le mer. 1 juil. 2020 à 11:52, Gurkan Erdogdu <
>> cgurkanerdo...@gmail.com
 
 a
> écrit :
> 
>> CDI is the core spec for all other Jakarta EE specifications. I
>> really
 dont
>> know why Tomcat does not include it naturally. I think the home
>> for such natural integration will be Tomcat. But, not under the
>>> modules,
>> but integrated into the Tomcat core and 

Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

Not fighting, just for the benefits of the both tomcat and owb, this is
duplicate effort both in owb and tomcat.

if you feel the best to stay in owb, no problem but I thought that if it is
in tomcat, it is natural to download via tomcat, no need to have
configration,  more community, and do more innovation with more users

And also I am not sure that tomcat community will accept that proposal :)



On 1 Jul 2020 Wed at 14:53 Romain Manni-Bucau  wrote:

> This module has some users - don't know if tomcat-owb has, maybe Rémy you
> have some insights?  - but these last years we got most users moving to
> tomee or meecrowave cause it is better integrated, ready to run and has
> modern flavors (embedded vs standalone tomcat) enabling modern deployments
> (thinking strongly to k8s + CDS).
> Only remaining case is bare metal tomcat where tomee takes most users these
> days because it is well tooled - maven, gradle and testing. So at the end
> this module is mainly for historical advanced users.
> Concretely this module has ~300 downloads/month (to compare to the 20k of
> owb-impl module).
>
> In any case, I don't think Tomcat will not promote CDI and any CDI/OWB
> support will likely be redirected here at some point so moving is an
> useless indirection.
> Also why Tomcat is so popular is that it is a servlet container (a bit more
> but just to share the idea), so it is used by everyone, if you get more you
> will get the exact same issue than with a full EE container: "it is too
> much for me, let's grab something else".
> Microprofile proves that: it does not even need a servlet layer at all
> theoretically.
> In that regard TomEE would be a better home but it is not the goal of the
> project to do this light integration today - and we have a few alternative
> at apache.
> It is also highly consistent with meecrowave to have @owb. While we
> maintain meecrowave we maintain this module sounds like a very fair
> assumption.
>
> @Gurkan Erdogdu  can you clarify why you fight so
> strongly to drop that module we own since years and not jetty one for
> example? I totally fail to see the point.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 1 juil. 2020 à 13:03, Gurkan Erdogdu  a
> écrit :
>
> > All other specs at the moment consumes or will consume CDI core. Even if
> > not, it must be. CDI is somebit different from other specs (especially I
> am
> > talking about the injection part) and now your observation may not be
> true
> > anymore. (As you said CDI consumes servlet but not the other way).
> >
> > I am not agree with that when Tomcat embeds CDI , it also support EJB,
> > Security etc. No, it is not .
> >
> > Who currently uses our tomcat7 module? Do you know its popularity? I
> > suspect that is large enough community on this. I started to wrote this
> > tomcat7 module years years ago because, CDI is not in the same state as
> it
> > is currently.
> >
> > But within Tomcat, it can reach and develop further community. One can
> use
> > Tomcat without external configration and update (like owb did) and on top
> > of that they can extend Tomcat naturally. With single download of Tomcat,
> > you also get fantastic CDI platform.
> >
> >  I think this is really a great idea.
> >
> > Gurkan
> >
> > On 1 Jul 2020 Wed at 13:35 Mark Struberg 
> > wrote:
> >
> > > As long as Tomcat doesn't release the integration as part of their core
> > > build we can stop the whole discussion!
> > >
> > > -1 on dropping webbeans-tomcat7
> > >
> > >
> > > Once there is a good alternative in the main build in tomcat we can
> > > discuss this again.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > > > Am 01.07.2020 um 12:01 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > >
> > > > Le mer. 1 juil. 2020 à 11:52, Gurkan Erdogdu <
> cgurkanerdo...@gmail.com
> > >
> > > a
> > > > écrit :
> > > >
> > > >> CDI is the core spec for all other Jakarta EE specifications. I
> really
> > > dont
> > > >> know why Tomcat does not include it naturally. I think the home
> > > >> for such natural integration will be Tomcat. But, not under the
> > modules,
> > > >> but integrated into the Tomcat core and release monthyl with Tomcat
> > > release
> > > >>
> > > >
> > > > Nop, EE always built each spec independently of the IoC - which is
> > wrong
> > > I
> > > > agree but it is what has been done and why you have at least 5
> > concurrent
> > > > IoC in EE.
> > > > If we follow your reasoning, tomcat should also include EJB, JAXRS,
> > > > javax.security etc, not sure it would be sane and you just move the
> > issue
> > > > which is that once you trivially integrated servlet+cdi you must
> > > integrate

Re: Remove of Useless Maven Projects

[Romain Manni-Bucau]

This module has some users - don't know if tomcat-owb has, maybe Rémy you
have some insights?  - but these last years we got most users moving to
tomee or meecrowave cause it is better integrated, ready to run and has
modern flavors (embedded vs standalone tomcat) enabling modern deployments
(thinking strongly to k8s + CDS).
Only remaining case is bare metal tomcat where tomee takes most users these
days because it is well tooled - maven, gradle and testing. So at the end
this module is mainly for historical advanced users.
Concretely this module has ~300 downloads/month (to compare to the 20k of
owb-impl module).

In any case, I don't think Tomcat will not promote CDI and any CDI/OWB
support will likely be redirected here at some point so moving is an
useless indirection.
Also why Tomcat is so popular is that it is a servlet container (a bit more
but just to share the idea), so it is used by everyone, if you get more you
will get the exact same issue than with a full EE container: "it is too
much for me, let's grab something else".
Microprofile proves that: it does not even need a servlet layer at all
theoretically.
In that regard TomEE would be a better home but it is not the goal of the
project to do this light integration today - and we have a few alternative
at apache.
It is also highly consistent with meecrowave to have @owb. While we
maintain meecrowave we maintain this module sounds like a very fair
assumption.

@Gurkan Erdogdu  can you clarify why you fight so
strongly to drop that module we own since years and not jetty one for
example? I totally fail to see the point.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 1 juil. 2020 à 13:03, Gurkan Erdogdu  a
écrit :

> All other specs at the moment consumes or will consume CDI core. Even if
> not, it must be. CDI is somebit different from other specs (especially I am
> talking about the injection part) and now your observation may not be true
> anymore. (As you said CDI consumes servlet but not the other way).
>
> I am not agree with that when Tomcat embeds CDI , it also support EJB,
> Security etc. No, it is not .
>
> Who currently uses our tomcat7 module? Do you know its popularity? I
> suspect that is large enough community on this. I started to wrote this
> tomcat7 module years years ago because, CDI is not in the same state as it
> is currently.
>
> But within Tomcat, it can reach and develop further community. One can use
> Tomcat without external configration and update (like owb did) and on top
> of that they can extend Tomcat naturally. With single download of Tomcat,
> you also get fantastic CDI platform.
>
>  I think this is really a great idea.
>
> Gurkan
>
> On 1 Jul 2020 Wed at 13:35 Mark Struberg 
> wrote:
>
> > As long as Tomcat doesn't release the integration as part of their core
> > build we can stop the whole discussion!
> >
> > -1 on dropping webbeans-tomcat7
> >
> >
> > Once there is a good alternative in the main build in tomcat we can
> > discuss this again.
> >
> > LieGrue,
> > strub
> >
> >
> >
> > > Am 01.07.2020 um 12:01 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > Le mer. 1 juil. 2020 à 11:52, Gurkan Erdogdu  >
> > a
> > > écrit :
> > >
> > >> CDI is the core spec for all other Jakarta EE specifications. I really
> > dont
> > >> know why Tomcat does not include it naturally. I think the home
> > >> for such natural integration will be Tomcat. But, not under the
> modules,
> > >> but integrated into the Tomcat core and release monthyl with Tomcat
> > release
> > >>
> > >
> > > Nop, EE always built each spec independently of the IoC - which is
> wrong
> > I
> > > agree but it is what has been done and why you have at least 5
> concurrent
> > > IoC in EE.
> > > If we follow your reasoning, tomcat should also include EJB, JAXRS,
> > > javax.security etc, not sure it would be sane and you just move the
> issue
> > > which is that once you trivially integrated servlet+cdi you must
> > integrate
> > > servlet+cdi+security, then +jaxrs etc (Pareto law applies well there).
> > > So at the end, CDI is based on servlet spec - since it is spec-ed like
> > that
> > > cause servlet spec rejected CDI integration at that time - then CDI is
> > > built on top on tomcat and not the opposite and in terms of build
> > > dependency, OWB consumes servlet spec, not the opposite so strictly
> > > speaking it is more logical to keep it in OWB.
> > > Lastly you still ignore that we integrate with jetty too and if we keep
> > > jetty we must keep tomcat for consistency of our deliveries and user
> > facing
> > > artifacts so IMHO there is no need to only do half of the discussion
> > which
> > > can only lead to half a 

Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

All other specs at the moment consumes or will consume CDI core. Even if
not, it must be. CDI is somebit different from other specs (especially I am
talking about the injection part) and now your observation may not be true
anymore. (As you said CDI consumes servlet but not the other way).

I am not agree with that when Tomcat embeds CDI , it also support EJB,
Security etc. No, it is not .

Who currently uses our tomcat7 module? Do you know its popularity? I
suspect that is large enough community on this. I started to wrote this
tomcat7 module years years ago because, CDI is not in the same state as it
is currently.

But within Tomcat, it can reach and develop further community. One can use
Tomcat without external configration and update (like owb did) and on top
of that they can extend Tomcat naturally. With single download of Tomcat,
you also get fantastic CDI platform.

 I think this is really a great idea.

Gurkan

On 1 Jul 2020 Wed at 13:35 Mark Struberg  wrote:

> As long as Tomcat doesn't release the integration as part of their core
> build we can stop the whole discussion!
>
> -1 on dropping webbeans-tomcat7
>
>
> Once there is a good alternative in the main build in tomcat we can
> discuss this again.
>
> LieGrue,
> strub
>
>
>
> > Am 01.07.2020 um 12:01 schrieb Romain Manni-Bucau  >:
> >
> > Le mer. 1 juil. 2020 à 11:52, Gurkan Erdogdu 
> a
> > écrit :
> >
> >> CDI is the core spec for all other Jakarta EE specifications. I really
> dont
> >> know why Tomcat does not include it naturally. I think the home
> >> for such natural integration will be Tomcat. But, not under the modules,
> >> but integrated into the Tomcat core and release monthyl with Tomcat
> release
> >>
> >
> > Nop, EE always built each spec independently of the IoC - which is wrong
> I
> > agree but it is what has been done and why you have at least 5 concurrent
> > IoC in EE.
> > If we follow your reasoning, tomcat should also include EJB, JAXRS,
> > javax.security etc, not sure it would be sane and you just move the issue
> > which is that once you trivially integrated servlet+cdi you must
> integrate
> > servlet+cdi+security, then +jaxrs etc (Pareto law applies well there).
> > So at the end, CDI is based on servlet spec - since it is spec-ed like
> that
> > cause servlet spec rejected CDI integration at that time - then CDI is
> > built on top on tomcat and not the opposite and in terms of build
> > dependency, OWB consumes servlet spec, not the opposite so strictly
> > speaking it is more logical to keep it in OWB.
> > Lastly you still ignore that we integrate with jetty too and if we keep
> > jetty we must keep tomcat for consistency of our deliveries and user
> facing
> > artifacts so IMHO there is no need to only do half of the discussion
> which
> > can only lead to half a decision which means it would not be applicable
> at
> > the end IMHO.
> >
> >
> >>
> >> Remy,
> >> Is it possible to open a discussion in tomcat dev list to discuss more
> on
> >> this topic?
> >>
> >> Gurkan
> >>
> >> On 1 Jul 2020 Wed at 12:45 Romain Manni-Bucau 
> >> wrote:
> >>
> >>> Hmm, sounds close to what we deliver (
> >>> http://openwebbeans.apache.org/owbsetup_tomcat.html ).
> >>> I agree we Gurkan we should be able to converge but today I don't see
> why
> >>> Tomcat is a saner home, factually it is worse since it is not ready to
> >> use
> >>> for end user compared to owb distro and fact it is in tomcat/modules is
> >> not
> >>> that encouraging to me (and I assume tomcat will not release it in its
> >>> monthly release, right?).
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >>> https://github.com/rmannibucau> |
> >>> LinkedIn  | Book
> >>> <
> >>>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> 
> >>>
> >>>
> >>> Le mer. 1 juil. 2020 à 11:27, Gurkan Erdogdu  >
> >> a
> >>> écrit :
> >>>
>  Thanks Remy.
>  Is it possible to merge these 2 efforts to single one under Tomcat
> >>> coebase?
>  I dont see any reason to maintain two different implementation with
> the
>  same aim
> 
> 
> 
>  On 1 Jul 2020 Wed at 11:14 Rémy Maucherat  wrote:
> 
> > On Tue, Jun 30, 2020 at 10:35 AM Gurkan Erdogdu <
>  cgurkanerdo...@gmail.com>
> > wrote:
> >
> >> Sorry but not understand why both Tomcat and OWB doing the same
> >> think
> > with
> >> nearly same classes
> >>
> >> @Remy
> >> Just wonder why did you introduce such a module in tomcat modules?
> >> Do
>  you
> >> have any specific purpose?
> >>
> >
> > The idea is to provide a different packaging, with specific easy to
>  follow
> > instructions that allow adding CDI support to the Tomcat container.
> >
> > Rémy
> >
>  --
>  Gurkan Erdogdu
>  

Re: Remove of Useless Maven Projects

[Mark Struberg]

As long as Tomcat doesn't release the integration as part of their core build 
we can stop the whole discussion!

-1 on dropping webbeans-tomcat7 


Once there is a good alternative in the main build in tomcat we can discuss 
this again.

LieGrue,
strub



> Am 01.07.2020 um 12:01 schrieb Romain Manni-Bucau :
> 
> Le mer. 1 juil. 2020 à 11:52, Gurkan Erdogdu  a
> écrit :
> 
>> CDI is the core spec for all other Jakarta EE specifications. I really dont
>> know why Tomcat does not include it naturally. I think the home
>> for such natural integration will be Tomcat. But, not under the modules,
>> but integrated into the Tomcat core and release monthyl with Tomcat release
>> 
> 
> Nop, EE always built each spec independently of the IoC - which is wrong I
> agree but it is what has been done and why you have at least 5 concurrent
> IoC in EE.
> If we follow your reasoning, tomcat should also include EJB, JAXRS,
> javax.security etc, not sure it would be sane and you just move the issue
> which is that once you trivially integrated servlet+cdi you must integrate
> servlet+cdi+security, then +jaxrs etc (Pareto law applies well there).
> So at the end, CDI is based on servlet spec - since it is spec-ed like that
> cause servlet spec rejected CDI integration at that time - then CDI is
> built on top on tomcat and not the opposite and in terms of build
> dependency, OWB consumes servlet spec, not the opposite so strictly
> speaking it is more logical to keep it in OWB.
> Lastly you still ignore that we integrate with jetty too and if we keep
> jetty we must keep tomcat for consistency of our deliveries and user facing
> artifacts so IMHO there is no need to only do half of the discussion which
> can only lead to half a decision which means it would not be applicable at
> the end IMHO.
> 
> 
>> 
>> Remy,
>> Is it possible to open a discussion in tomcat dev list to discuss more on
>> this topic?
>> 
>> Gurkan
>> 
>> On 1 Jul 2020 Wed at 12:45 Romain Manni-Bucau 
>> wrote:
>> 
>>> Hmm, sounds close to what we deliver (
>>> http://openwebbeans.apache.org/owbsetup_tomcat.html ).
>>> I agree we Gurkan we should be able to converge but today I don't see why
>>> Tomcat is a saner home, factually it is worse since it is not ready to
>> use
>>> for end user compared to owb distro and fact it is in tomcat/modules is
>> not
>>> that encouraging to me (and I assume tomcat will not release it in its
>>> monthly release, right?).
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>>> 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
 
>>> 
>>> 
>>> Le mer. 1 juil. 2020 à 11:27, Gurkan Erdogdu 
>> a
>>> écrit :
>>> 
 Thanks Remy.
 Is it possible to merge these 2 efforts to single one under Tomcat
>>> coebase?
 I dont see any reason to maintain two different implementation with the
 same aim
 
 
 
 On 1 Jul 2020 Wed at 11:14 Rémy Maucherat  wrote:
 
> On Tue, Jun 30, 2020 at 10:35 AM Gurkan Erdogdu <
 cgurkanerdo...@gmail.com>
> wrote:
> 
>> Sorry but not understand why both Tomcat and OWB doing the same
>> think
> with
>> nearly same classes
>> 
>> @Remy
>> Just wonder why did you introduce such a module in tomcat modules?
>> Do
 you
>> have any specific purpose?
>> 
> 
> The idea is to provide a different packaging, with specific easy to
 follow
> instructions that allow adding CDI support to the Tomcat container.
> 
> Rémy
> 
 --
 Gurkan Erdogdu
 http://gurkanerdogdu.blogspot.com
 
>>> 
>> --
>> Gurkan Erdogdu
>> http://gurkanerdogdu.blogspot.com
>> 

Re: Remove of Useless Maven Projects

[Romain Manni-Bucau]

Le mer. 1 juil. 2020 à 11:52, Gurkan Erdogdu  a
écrit :

> CDI is the core spec for all other Jakarta EE specifications. I really dont
> know why Tomcat does not include it naturally. I think the home
> for such natural integration will be Tomcat. But, not under the modules,
> but integrated into the Tomcat core and release monthyl with Tomcat release
>

Nop, EE always built each spec independently of the IoC - which is wrong I
agree but it is what has been done and why you have at least 5 concurrent
IoC in EE.
If we follow your reasoning, tomcat should also include EJB, JAXRS,
javax.security etc, not sure it would be sane and you just move the issue
which is that once you trivially integrated servlet+cdi you must integrate
servlet+cdi+security, then +jaxrs etc (Pareto law applies well there).
So at the end, CDI is based on servlet spec - since it is spec-ed like that
cause servlet spec rejected CDI integration at that time - then CDI is
built on top on tomcat and not the opposite and in terms of build
dependency, OWB consumes servlet spec, not the opposite so strictly
speaking it is more logical to keep it in OWB.
Lastly you still ignore that we integrate with jetty too and if we keep
jetty we must keep tomcat for consistency of our deliveries and user facing
artifacts so IMHO there is no need to only do half of the discussion which
can only lead to half a decision which means it would not be applicable at
the end IMHO.


>
> Remy,
> Is it possible to open a discussion in tomcat dev list to discuss more on
> this topic?
>
> Gurkan
>
> On 1 Jul 2020 Wed at 12:45 Romain Manni-Bucau 
> wrote:
>
> > Hmm, sounds close to what we deliver (
> > http://openwebbeans.apache.org/owbsetup_tomcat.html ).
> > I agree we Gurkan we should be able to converge but today I don't see why
> > Tomcat is a saner home, factually it is worse since it is not ready to
> use
> > for end user compared to owb distro and fact it is in tomcat/modules is
> not
> > that encouraging to me (and I assume tomcat will not release it in its
> > monthly release, right?).
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 1 juil. 2020 à 11:27, Gurkan Erdogdu 
> a
> > écrit :
> >
> > > Thanks Remy.
> > > Is it possible to merge these 2 efforts to single one under Tomcat
> > coebase?
> > > I dont see any reason to maintain two different implementation with the
> > > same aim
> > >
> > >
> > >
> > > On 1 Jul 2020 Wed at 11:14 Rémy Maucherat  wrote:
> > >
> > > > On Tue, Jun 30, 2020 at 10:35 AM Gurkan Erdogdu <
> > > cgurkanerdo...@gmail.com>
> > > > wrote:
> > > >
> > > > > Sorry but not understand why both Tomcat and OWB doing the same
> think
> > > > with
> > > > > nearly same classes
> > > > >
> > > > > @Remy
> > > > > Just wonder why did you introduce such a module in tomcat modules?
> Do
> > > you
> > > > > have any specific purpose?
> > > > >
> > > >
> > > > The idea is to provide a different packaging, with specific easy to
> > > follow
> > > > instructions that allow adding CDI support to the Tomcat container.
> > > >
> > > > Rémy
> > > >
> > > --
> > > Gurkan Erdogdu
> > > http://gurkanerdogdu.blogspot.com
> > >
> >
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>

Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

CDI is the core spec for all other Jakarta EE specifications. I really dont
know why Tomcat does not include it naturally. I think the home
for such natural integration will be Tomcat. But, not under the modules,
but integrated into the Tomcat core and release monthyl with Tomcat release

Remy,
Is it possible to open a discussion in tomcat dev list to discuss more on
this topic?

Gurkan

On 1 Jul 2020 Wed at 12:45 Romain Manni-Bucau  wrote:

> Hmm, sounds close to what we deliver (
> http://openwebbeans.apache.org/owbsetup_tomcat.html ).
> I agree we Gurkan we should be able to converge but today I don't see why
> Tomcat is a saner home, factually it is worse since it is not ready to use
> for end user compared to owb distro and fact it is in tomcat/modules is not
> that encouraging to me (and I assume tomcat will not release it in its
> monthly release, right?).
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 1 juil. 2020 à 11:27, Gurkan Erdogdu  a
> écrit :
>
> > Thanks Remy.
> > Is it possible to merge these 2 efforts to single one under Tomcat
> coebase?
> > I dont see any reason to maintain two different implementation with the
> > same aim
> >
> >
> >
> > On 1 Jul 2020 Wed at 11:14 Rémy Maucherat  wrote:
> >
> > > On Tue, Jun 30, 2020 at 10:35 AM Gurkan Erdogdu <
> > cgurkanerdo...@gmail.com>
> > > wrote:
> > >
> > > > Sorry but not understand why both Tomcat and OWB doing the same think
> > > with
> > > > nearly same classes
> > > >
> > > > @Remy
> > > > Just wonder why did you introduce such a module in tomcat modules? Do
> > you
> > > > have any specific purpose?
> > > >
> > >
> > > The idea is to provide a different packaging, with specific easy to
> > follow
> > > instructions that allow adding CDI support to the Tomcat container.
> > >
> > > Rémy
> > >
> > --
> > Gurkan Erdogdu
> > http://gurkanerdogdu.blogspot.com
> >
>
-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Remove of Useless Maven Projects

[Romain Manni-Bucau]

Hmm, sounds close to what we deliver (
http://openwebbeans.apache.org/owbsetup_tomcat.html ).
I agree we Gurkan we should be able to converge but today I don't see why
Tomcat is a saner home, factually it is worse since it is not ready to use
for end user compared to owb distro and fact it is in tomcat/modules is not
that encouraging to me (and I assume tomcat will not release it in its
monthly release, right?).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 1 juil. 2020 à 11:27, Gurkan Erdogdu  a
écrit :

> Thanks Remy.
> Is it possible to merge these 2 efforts to single one under Tomcat coebase?
> I dont see any reason to maintain two different implementation with the
> same aim
>
>
>
> On 1 Jul 2020 Wed at 11:14 Rémy Maucherat  wrote:
>
> > On Tue, Jun 30, 2020 at 10:35 AM Gurkan Erdogdu <
> cgurkanerdo...@gmail.com>
> > wrote:
> >
> > > Sorry but not understand why both Tomcat and OWB doing the same think
> > with
> > > nearly same classes
> > >
> > > @Remy
> > > Just wonder why did you introduce such a module in tomcat modules? Do
> you
> > > have any specific purpose?
> > >
> >
> > The idea is to provide a different packaging, with specific easy to
> follow
> > instructions that allow adding CDI support to the Tomcat container.
> >
> > Rémy
> >
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>

Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

Thanks Remy.
Is it possible to merge these 2 efforts to single one under Tomcat coebase?
I dont see any reason to maintain two different implementation with the
same aim



On 1 Jul 2020 Wed at 11:14 Rémy Maucherat  wrote:

> On Tue, Jun 30, 2020 at 10:35 AM Gurkan Erdogdu 
> wrote:
>
> > Sorry but not understand why both Tomcat and OWB doing the same think
> with
> > nearly same classes
> >
> > @Remy
> > Just wonder why did you introduce such a module in tomcat modules? Do you
> > have any specific purpose?
> >
>
> The idea is to provide a different packaging, with specific easy to follow
> instructions that allow adding CDI support to the Tomcat container.
>
> Rémy
>
-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Remove of Useless Maven Projects

[Rémy Maucherat]

On Tue, Jun 30, 2020 at 10:35 AM Gurkan Erdogdu 
wrote:

> Sorry but not understand why both Tomcat and OWB doing the same think with
> nearly same classes
>
> @Remy
> Just wonder why did you introduce such a module in tomcat modules? Do you
> have any specific purpose?
>

The idea is to provide a different packaging, with specific easy to follow
instructions that allow adding CDI support to the Tomcat container.

Rémy

Re: Remove of Useless Maven Projects

[Romain Manni-Bucau]

Le mar. 30 juin 2020 à 13:06, Mark Struberg  a
écrit :

> Oh shees, yes was on a different track in my head. I think the CDI spec
> doesn't mention websockets at all. Probably that's why we don't integrate
> with it.
> I remember that we once had the discussion and the outcome was that it
> might be too expensive to do it every time. And people can use
> CDI.current() anyway IF they need it. At least that was what I remember
> from the discussions we had in the CDI EG. Not sure if there have been
> discussions on the EE umbrella level.
>

The spec document (~ PDF) is empty but javadoc mentions that EE context
looks up in EE context - which means what we want I guess.
That said, realisticly it does not sound crazy to say the websocket
components have at least injections even if they are not beans as JAXRS,
Servlet, JSF and all EE components.
In terms of cost it is likely less costly than for servlet components cause
a connection lasts way longer than for webapps, likely something to enhance
but I'm not sure today the usage of this module. From my small window I saw
only custom integrations and rarely so deep integrations so not sure it is
worth it.


>
> LieGrue,
> strub
>
> > Am 30.06.2020 um 10:23 schrieb Romain Manni-Bucau  >:
> >
> > Hmm, I'm not following, spoke of websockets, not async requests and as an
> > user I expect a tomcat-owb integration module to make both working
> together
> > otherwise it is pointless to have an integration module not integrating
> > technologies.
> > Now the spec mentions it is supported in an EE world - we are not there
> but
> > I guess we should be consistent with it in such a module:
> >
> https://jakarta.ee/specifications/websocket/1.1/apidocs/javax/websocket/server/ServerEndpointConfig.Configurator.html#getEndpointInstance-java.lang.Class-
> >
> > I suspect tomcat could use by itself the instance manager to avoid this
> > integration need but then it would leak the "release" call - it must be
> > compensated by another mechanism since the websocket spec does not give
> it.
> >
> > Anyway, we can open a new thread on the impl, didn't intend to hijack
> this
> > one.
> >
> > Le mar. 30 juin 2020 à 09:59, Mark Struberg 
> a
> > écrit :
> >
> >> It means we support @RequestScoped and ApplicationScoped beans in Async
> >> Requests and events as required by the spec.
> >>
> >> The rest is afaik not portable.
> >>
> >> Happy to be proven wrong ;)
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 30.06.2020 um 09:39 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> If does support means you can write websocket code, sure.
> >>> If it means "works with cdi beans" then I think we miss this class:
> >>>
> >>
> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/websocket/JavaEEDefaultServerEnpointConfigurator.java
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >> https://github.com/rmannibucau> |
> >>> LinkedIn  | Book
> >>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>>
> >>>
> >>> Le mar. 30 juin 2020 à 09:29, Mark Struberg  >
> >> a
> >>> écrit :
> >>>
>  our tomcat integration does support websockets afair.
> 
>  LieGrue,
>  strub
> 
> > Am 30.06.2020 um 08:20 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> > :
> >
> > @Gurkan Erdogdu   the first reason to keep
>  tomcat
> > module is that we release it whereas o.a.tomcat:tomcat-owb does not
> >> exist
> > for end users today ("you can build from source" is not an option
> IMHO
>  and
> > justifies to fork in most cases). The main difference in terms of
> code
> >> is
> > the fact tomcat integration provides a valve for the principal
> whereas
> >> we
> > only use a filter but I guess it is enough since valve will prevent
> to
> > position the filter - = capture of the principal - in the filter
> chain
>  and
> > can therefore break apps even if it is tempting to make it always win
> >> (we
> > shouldn't use a thread local but we don't have much options there).
> >> Both
> > impl miss websocket integration - tomee has it - so it looks like
> > tomcat-owb is a fork of our module today, not much so release point
> is
> >> a
> > blocker for me.
> >
> > With jakarta I guess we can maybe ask tomcat+jetty to get an official
> > servlet components injections and drop all specific code.
> >
> > Last point about the consistency for jetty AND tomcat is also key for
> >> me,
> > there is no reason to favor jetty and not tomcat.
> >
> > +1 to drop the version from the module though, it does not make sense
> > anymore - was for 6 -> 7 move IIRC.
> >
> > Romain Manni-Bucau
> 

Re: Remove of Useless Maven Projects

[Mark Struberg]

Oh shees, yes was on a different track in my head. I think the CDI spec doesn't 
mention websockets at all. Probably that's why we don't integrate with it.
I remember that we once had the discussion and the outcome was that it might be 
too expensive to do it every time. And people can use CDI.current() anyway IF 
they need it. At least that was what I remember from the discussions we had in 
the CDI EG. Not sure if there have been discussions on the EE umbrella level.

LieGrue,
strub

> Am 30.06.2020 um 10:23 schrieb Romain Manni-Bucau :
> 
> Hmm, I'm not following, spoke of websockets, not async requests and as an
> user I expect a tomcat-owb integration module to make both working together
> otherwise it is pointless to have an integration module not integrating
> technologies.
> Now the spec mentions it is supported in an EE world - we are not there but
> I guess we should be consistent with it in such a module:
> https://jakarta.ee/specifications/websocket/1.1/apidocs/javax/websocket/server/ServerEndpointConfig.Configurator.html#getEndpointInstance-java.lang.Class-
> 
> I suspect tomcat could use by itself the instance manager to avoid this
> integration need but then it would leak the "release" call - it must be
> compensated by another mechanism since the websocket spec does not give it.
> 
> Anyway, we can open a new thread on the impl, didn't intend to hijack this
> one.
> 
> Le mar. 30 juin 2020 à 09:59, Mark Struberg  a
> écrit :
> 
>> It means we support @RequestScoped and ApplicationScoped beans in Async
>> Requests and events as required by the spec.
>> 
>> The rest is afaik not portable.
>> 
>> Happy to be proven wrong ;)
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 30.06.2020 um 09:39 schrieb Romain Manni-Bucau >> :
>>> 
>>> If does support means you can write websocket code, sure.
>>> If it means "works with cdi beans" then I think we miss this class:
>>> 
>> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/websocket/JavaEEDefaultServerEnpointConfigurator.java
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
>>> Le mar. 30 juin 2020 à 09:29, Mark Struberg 
>> a
>>> écrit :
>>> 
 our tomcat integration does support websockets afair.
 
 LieGrue,
 strub
 
> Am 30.06.2020 um 08:20 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
> :
> 
> @Gurkan Erdogdu   the first reason to keep
 tomcat
> module is that we release it whereas o.a.tomcat:tomcat-owb does not
>> exist
> for end users today ("you can build from source" is not an option IMHO
 and
> justifies to fork in most cases). The main difference in terms of code
>> is
> the fact tomcat integration provides a valve for the principal whereas
>> we
> only use a filter but I guess it is enough since valve will prevent to
> position the filter - = capture of the principal - in the filter chain
 and
> can therefore break apps even if it is tempting to make it always win
>> (we
> shouldn't use a thread local but we don't have much options there).
>> Both
> impl miss websocket integration - tomee has it - so it looks like
> tomcat-owb is a fork of our module today, not much so release point is
>> a
> blocker for me.
> 
> With jakarta I guess we can maybe ask tomcat+jetty to get an official
> servlet components injections and drop all specific code.
> 
> Last point about the consistency for jetty AND tomcat is also key for
>> me,
> there is no reason to favor jetty and not tomcat.
> 
> +1 to drop the version from the module though, it does not make sense
> anymore - was for 6 -> 7 move IIRC.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
 https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
> 
> 
> 
> Le mar. 30 juin 2020 à 00:34, Gurkan Erdogdu >> 
 a
> écrit :
> 
>> Hi Remy
>> 
>>> I would think you should keep "tomcat7" too, it's not really the same
>> idea
>>> as modules/owb.
>>> 
>> I have looked at both implementations and both are the same purpose,
>> injection into  Servlet related classes and get the current Principal
 from
>> the request. In Tomcat/OWB module, its integration is more natural
>> than
 the
>> Tomcat7 module.
>> What is the benefit of using Tomcat7 

Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

Sorry but not understand why both Tomcat and OWB doing the same think with
nearly same classes

@Remy
Just wonder why did you introduce such a module in tomcat modules? Do you
have any specific purpose?



On 30 Jun 2020 Tue at 11:24 Romain Manni-Bucau 
wrote:

> Hmm, I'm not following, spoke of websockets, not async requests and as an
> user I expect a tomcat-owb integration module to make both working together
> otherwise it is pointless to have an integration module not integrating
> technologies.
> Now the spec mentions it is supported in an EE world - we are not there but
> I guess we should be consistent with it in such a module:
>
> https://jakarta.ee/specifications/websocket/1.1/apidocs/javax/websocket/server/ServerEndpointConfig.Configurator.html#getEndpointInstance-java.lang.Class-
>
> I suspect tomcat could use by itself the instance manager to avoid this
> integration need but then it would leak the "release" call - it must be
> compensated by another mechanism since the websocket spec does not give it.
>
> Anyway, we can open a new thread on the impl, didn't intend to hijack this
> one.
>
> Le mar. 30 juin 2020 à 09:59, Mark Struberg  a
> écrit :
>
> > It means we support @RequestScoped and ApplicationScoped beans in Async
> > Requests and events as required by the spec.
> >
> > The rest is afaik not portable.
> >
> > Happy to be proven wrong ;)
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 30.06.2020 um 09:39 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > If does support means you can write websocket code, sure.
> > > If it means "works with cdi beans" then I think we miss this class:
> > >
> >
> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/websocket/JavaEEDefaultServerEnpointConfigurator.java
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mar. 30 juin 2020 à 09:29, Mark Struberg  >
> > a
> > > écrit :
> > >
> > >> our tomcat integration does support websockets afair.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>> Am 30.06.2020 um 08:20 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > >>> :
> > >>>
> > >>> @Gurkan Erdogdu   the first reason to keep
> > >> tomcat
> > >>> module is that we release it whereas o.a.tomcat:tomcat-owb does not
> > exist
> > >>> for end users today ("you can build from source" is not an option
> IMHO
> > >> and
> > >>> justifies to fork in most cases). The main difference in terms of
> code
> > is
> > >>> the fact tomcat integration provides a valve for the principal
> whereas
> > we
> > >>> only use a filter but I guess it is enough since valve will prevent
> to
> > >>> position the filter - = capture of the principal - in the filter
> chain
> > >> and
> > >>> can therefore break apps even if it is tempting to make it always win
> > (we
> > >>> shouldn't use a thread local but we don't have much options there).
> > Both
> > >>> impl miss websocket integration - tomee has it - so it looks like
> > >>> tomcat-owb is a fork of our module today, not much so release point
> is
> > a
> > >>> blocker for me.
> > >>>
> > >>> With jakarta I guess we can maybe ask tomcat+jetty to get an official
> > >>> servlet components injections and drop all specific code.
> > >>>
> > >>> Last point about the consistency for jetty AND tomcat is also key for
> > me,
> > >>> there is no reason to favor jetty and not tomcat.
> > >>>
> > >>> +1 to drop the version from the module though, it does not make sense
> > >>> anymore - was for 6 -> 7 move IIRC.
> > >>>
> > >>> Romain Manni-Bucau
> > >>> @rmannibucau  |  Blog
> > >>>  | Old Blog
> > >>>  | Github <
> > >> https://github.com/rmannibucau> |
> > >>> LinkedIn  | Book
> > >>> <
> > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >>>
> > >>>
> > >>>
> > >>> Le mar. 30 juin 2020 à 00:34, Gurkan Erdogdu <
> cgurkanerdo...@gmail.com
> > >
> > >> a
> > >>> écrit :
> > >>>
> >  Hi Remy
> > 
> > > I would think you should keep "tomcat7" too, it's not really the
> same
> >  idea
> > > as modules/owb.
> > >
> >  I have looked at both implementations and both are the same purpose,
> >  injection into  Servlet related classes and get the current
> Principal
> > >> from
> >  the request. In Tomcat/OWB module, its integration is more natural
> > than
> > >> the
> >  Tomcat7 module.
> >  What is the benefit of using Tomcat7 in OWB?
> >  Regards.
> >  Gurkan
> > 

Re: Remove of Useless Maven Projects

[Romain Manni-Bucau]

Hmm, I'm not following, spoke of websockets, not async requests and as an
user I expect a tomcat-owb integration module to make both working together
otherwise it is pointless to have an integration module not integrating
technologies.
Now the spec mentions it is supported in an EE world - we are not there but
I guess we should be consistent with it in such a module:
https://jakarta.ee/specifications/websocket/1.1/apidocs/javax/websocket/server/ServerEndpointConfig.Configurator.html#getEndpointInstance-java.lang.Class-

I suspect tomcat could use by itself the instance manager to avoid this
integration need but then it would leak the "release" call - it must be
compensated by another mechanism since the websocket spec does not give it.

Anyway, we can open a new thread on the impl, didn't intend to hijack this
one.

Le mar. 30 juin 2020 à 09:59, Mark Struberg  a
écrit :

> It means we support @RequestScoped and ApplicationScoped beans in Async
> Requests and events as required by the spec.
>
> The rest is afaik not portable.
>
> Happy to be proven wrong ;)
>
> LieGrue,
> strub
>
>
> > Am 30.06.2020 um 09:39 schrieb Romain Manni-Bucau  >:
> >
> > If does support means you can write websocket code, sure.
> > If it means "works with cdi beans" then I think we miss this class:
> >
> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/websocket/JavaEEDefaultServerEnpointConfigurator.java
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 30 juin 2020 à 09:29, Mark Struberg 
> a
> > écrit :
> >
> >> our tomcat integration does support websockets afair.
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 30.06.2020 um 08:20 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> @Gurkan Erdogdu   the first reason to keep
> >> tomcat
> >>> module is that we release it whereas o.a.tomcat:tomcat-owb does not
> exist
> >>> for end users today ("you can build from source" is not an option IMHO
> >> and
> >>> justifies to fork in most cases). The main difference in terms of code
> is
> >>> the fact tomcat integration provides a valve for the principal whereas
> we
> >>> only use a filter but I guess it is enough since valve will prevent to
> >>> position the filter - = capture of the principal - in the filter chain
> >> and
> >>> can therefore break apps even if it is tempting to make it always win
> (we
> >>> shouldn't use a thread local but we don't have much options there).
> Both
> >>> impl miss websocket integration - tomee has it - so it looks like
> >>> tomcat-owb is a fork of our module today, not much so release point is
> a
> >>> blocker for me.
> >>>
> >>> With jakarta I guess we can maybe ask tomcat+jetty to get an official
> >>> servlet components injections and drop all specific code.
> >>>
> >>> Last point about the consistency for jetty AND tomcat is also key for
> me,
> >>> there is no reason to favor jetty and not tomcat.
> >>>
> >>> +1 to drop the version from the module though, it does not make sense
> >>> anymore - was for 6 -> 7 move IIRC.
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >> https://github.com/rmannibucau> |
> >>> LinkedIn  | Book
> >>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>>
> >>>
> >>> Le mar. 30 juin 2020 à 00:34, Gurkan Erdogdu  >
> >> a
> >>> écrit :
> >>>
>  Hi Remy
> 
> > I would think you should keep "tomcat7" too, it's not really the same
>  idea
> > as modules/owb.
> >
>  I have looked at both implementations and both are the same purpose,
>  injection into  Servlet related classes and get the current Principal
> >> from
>  the request. In Tomcat/OWB module, its integration is more natural
> than
> >> the
>  Tomcat7 module.
>  What is the benefit of using Tomcat7 in OWB?
>  Regards.
>  Gurkan
> 
> 
>  On Tue, Jun 30, 2020 at 12:33 AM Rémy Maucherat 
> >> wrote:
> 
> > On Mon, Jun 29, 2020 at 1:54 PM Romain Manni-Bucau <
>  rmannibu...@gmail.com>
> > wrote:
> >
> >> +1 to drop jms module, never saw any usage of it
> >> -0.5 for tomcat7, rational being that if we want to do it, we should
>  (at
> >> the same time) 1. ensure tomcat module is at least 1-1 (not the
> case I
> >> think) + released properly and not just a sandbox and 2. drop jetty
> >> integration too (which can be envisioned since we worked to
> integrate
>  

Re: Remove of Useless Maven Projects

[Mark Struberg]

It means we support @RequestScoped and ApplicationScoped beans in Async 
Requests and events as required by the spec. 

The rest is afaik not portable.

Happy to be proven wrong ;)

LieGrue,
strub


> Am 30.06.2020 um 09:39 schrieb Romain Manni-Bucau :
> 
> If does support means you can write websocket code, sure.
> If it means "works with cdi beans" then I think we miss this class:
> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/websocket/JavaEEDefaultServerEnpointConfigurator.java
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mar. 30 juin 2020 à 09:29, Mark Struberg  a
> écrit :
> 
>> our tomcat integration does support websockets afair.
>> 
>> LieGrue,
>> strub
>> 
>>> Am 30.06.2020 um 08:20 schrieb Romain Manni-Bucau >> :
>>> 
>>> @Gurkan Erdogdu   the first reason to keep
>> tomcat
>>> module is that we release it whereas o.a.tomcat:tomcat-owb does not exist
>>> for end users today ("you can build from source" is not an option IMHO
>> and
>>> justifies to fork in most cases). The main difference in terms of code is
>>> the fact tomcat integration provides a valve for the principal whereas we
>>> only use a filter but I guess it is enough since valve will prevent to
>>> position the filter - = capture of the principal - in the filter chain
>> and
>>> can therefore break apps even if it is tempting to make it always win (we
>>> shouldn't use a thread local but we don't have much options there). Both
>>> impl miss websocket integration - tomee has it - so it looks like
>>> tomcat-owb is a fork of our module today, not much so release point is a
>>> blocker for me.
>>> 
>>> With jakarta I guess we can maybe ask tomcat+jetty to get an official
>>> servlet components injections and drop all specific code.
>>> 
>>> Last point about the consistency for jetty AND tomcat is also key for me,
>>> there is no reason to favor jetty and not tomcat.
>>> 
>>> +1 to drop the version from the module though, it does not make sense
>>> anymore - was for 6 -> 7 move IIRC.
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
>>> Le mar. 30 juin 2020 à 00:34, Gurkan Erdogdu 
>> a
>>> écrit :
>>> 
 Hi Remy
 
> I would think you should keep "tomcat7" too, it's not really the same
 idea
> as modules/owb.
> 
 I have looked at both implementations and both are the same purpose,
 injection into  Servlet related classes and get the current Principal
>> from
 the request. In Tomcat/OWB module, its integration is more natural than
>> the
 Tomcat7 module.
 What is the benefit of using Tomcat7 in OWB?
 Regards.
 Gurkan
 
 
 On Tue, Jun 30, 2020 at 12:33 AM Rémy Maucherat 
>> wrote:
 
> On Mon, Jun 29, 2020 at 1:54 PM Romain Manni-Bucau <
 rmannibu...@gmail.com>
> wrote:
> 
>> +1 to drop jms module, never saw any usage of it
>> -0.5 for tomcat7, rational being that if we want to do it, we should
 (at
>> the same time) 1. ensure tomcat module is at least 1-1 (not the case I
>> think) + released properly and not just a sandbox and 2. drop jetty
>> integration too (which can be envisioned since we worked to integrate
 OWB
>> in jetty itself) but dropping tomcat7 module without these two
 conditions
>> looks like an user regression to me.
>> 
> 
> I would think you should keep "tomcat7" too, it's not really the same
 idea
> as modules/owb. The main problem is using a version number in the
>> module
> name, that creates confusion in the long run and gives the impression
>> it
 is
> outdated. Tomcat 7 will be eoled "soon", for example.
> 
> Rémy
> 
> 
>> 
>> I guess ee modules can move to tomee too - any other consumer - with
 the
>> relevant adaptations to our codebase?
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> 
> 
 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le lun. 29 juin 2020 à 13:38, Gurkan Erdogdu <
>> 

Re: Remove of Useless Maven Projects

[Romain Manni-Bucau]

If does support means you can write websocket code, sure.
If it means "works with cdi beans" then I think we miss this class:
https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/websocket/JavaEEDefaultServerEnpointConfigurator.java

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 30 juin 2020 à 09:29, Mark Struberg  a
écrit :

> our tomcat integration does support websockets afair.
>
> LieGrue,
> strub
>
> > Am 30.06.2020 um 08:20 schrieb Romain Manni-Bucau  >:
> >
> > @Gurkan Erdogdu   the first reason to keep
> tomcat
> > module is that we release it whereas o.a.tomcat:tomcat-owb does not exist
> > for end users today ("you can build from source" is not an option IMHO
> and
> > justifies to fork in most cases). The main difference in terms of code is
> > the fact tomcat integration provides a valve for the principal whereas we
> > only use a filter but I guess it is enough since valve will prevent to
> > position the filter - = capture of the principal - in the filter chain
> and
> > can therefore break apps even if it is tempting to make it always win (we
> > shouldn't use a thread local but we don't have much options there). Both
> > impl miss websocket integration - tomee has it - so it looks like
> > tomcat-owb is a fork of our module today, not much so release point is a
> > blocker for me.
> >
> > With jakarta I guess we can maybe ask tomcat+jetty to get an official
> > servlet components injections and drop all specific code.
> >
> > Last point about the consistency for jetty AND tomcat is also key for me,
> > there is no reason to favor jetty and not tomcat.
> >
> > +1 to drop the version from the module though, it does not make sense
> > anymore - was for 6 -> 7 move IIRC.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 30 juin 2020 à 00:34, Gurkan Erdogdu 
> a
> > écrit :
> >
> >> Hi Remy
> >>
> >>> I would think you should keep "tomcat7" too, it's not really the same
> >> idea
> >>> as modules/owb.
> >>>
> >> I have looked at both implementations and both are the same purpose,
> >> injection into  Servlet related classes and get the current Principal
> from
> >> the request. In Tomcat/OWB module, its integration is more natural than
> the
> >> Tomcat7 module.
> >> What is the benefit of using Tomcat7 in OWB?
> >> Regards.
> >> Gurkan
> >>
> >>
> >> On Tue, Jun 30, 2020 at 12:33 AM Rémy Maucherat 
> wrote:
> >>
> >>> On Mon, Jun 29, 2020 at 1:54 PM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >>> wrote:
> >>>
>  +1 to drop jms module, never saw any usage of it
>  -0.5 for tomcat7, rational being that if we want to do it, we should
> >> (at
>  the same time) 1. ensure tomcat module is at least 1-1 (not the case I
>  think) + released properly and not just a sandbox and 2. drop jetty
>  integration too (which can be envisioned since we worked to integrate
> >> OWB
>  in jetty itself) but dropping tomcat7 module without these two
> >> conditions
>  looks like an user regression to me.
> 
> >>>
> >>> I would think you should keep "tomcat7" too, it's not really the same
> >> idea
> >>> as modules/owb. The main problem is using a version number in the
> module
> >>> name, that creates confusion in the long run and gives the impression
> it
> >> is
> >>> outdated. Tomcat 7 will be eoled "soon", for example.
> >>>
> >>> Rémy
> >>>
> >>>
> 
>  I guess ee modules can move to tomee too - any other consumer - with
> >> the
>  relevant adaptations to our codebase?
> 
>  Romain Manni-Bucau
>  @rmannibucau  |  Blog
>   | Old Blog
>   | Github <
>  https://github.com/rmannibucau> |
>  LinkedIn  | Book
>  <
> 
> >>>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> 
> 
>  Le lun. 29 juin 2020 à 13:38, Gurkan Erdogdu <
> cgurkanerdo...@gmail.com
> >>>
> >>> a
>  écrit :
> 
> > Hi folks
> > I would like to discuss to remove the following modules from the OWB
> >>> code
> > base.
> >
> >   - webbeans-jms : We introduced this module years ago for JMS but
>  frankly
> >   never see any usage. Also, it was not 

Re: Remove of Useless Maven Projects

[Mark Struberg]

our tomcat integration does support websockets afair.

LieGrue,
strub

> Am 30.06.2020 um 08:20 schrieb Romain Manni-Bucau :
> 
> @Gurkan Erdogdu   the first reason to keep tomcat
> module is that we release it whereas o.a.tomcat:tomcat-owb does not exist
> for end users today ("you can build from source" is not an option IMHO and
> justifies to fork in most cases). The main difference in terms of code is
> the fact tomcat integration provides a valve for the principal whereas we
> only use a filter but I guess it is enough since valve will prevent to
> position the filter - = capture of the principal - in the filter chain and
> can therefore break apps even if it is tempting to make it always win (we
> shouldn't use a thread local but we don't have much options there). Both
> impl miss websocket integration - tomee has it - so it looks like
> tomcat-owb is a fork of our module today, not much so release point is a
> blocker for me.
> 
> With jakarta I guess we can maybe ask tomcat+jetty to get an official
> servlet components injections and drop all specific code.
> 
> Last point about the consistency for jetty AND tomcat is also key for me,
> there is no reason to favor jetty and not tomcat.
> 
> +1 to drop the version from the module though, it does not make sense
> anymore - was for 6 -> 7 move IIRC.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mar. 30 juin 2020 à 00:34, Gurkan Erdogdu  a
> écrit :
> 
>> Hi Remy
>> 
>>> I would think you should keep "tomcat7" too, it's not really the same
>> idea
>>> as modules/owb.
>>> 
>> I have looked at both implementations and both are the same purpose,
>> injection into  Servlet related classes and get the current Principal from
>> the request. In Tomcat/OWB module, its integration is more natural than the
>> Tomcat7 module.
>> What is the benefit of using Tomcat7 in OWB?
>> Regards.
>> Gurkan
>> 
>> 
>> On Tue, Jun 30, 2020 at 12:33 AM Rémy Maucherat  wrote:
>> 
>>> On Mon, Jun 29, 2020 at 1:54 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>>> wrote:
>>> 
 +1 to drop jms module, never saw any usage of it
 -0.5 for tomcat7, rational being that if we want to do it, we should
>> (at
 the same time) 1. ensure tomcat module is at least 1-1 (not the case I
 think) + released properly and not just a sandbox and 2. drop jetty
 integration too (which can be envisioned since we worked to integrate
>> OWB
 in jetty itself) but dropping tomcat7 module without these two
>> conditions
 looks like an user regression to me.
 
>>> 
>>> I would think you should keep "tomcat7" too, it's not really the same
>> idea
>>> as modules/owb. The main problem is using a version number in the module
>>> name, that creates confusion in the long run and gives the impression it
>> is
>>> outdated. Tomcat 7 will be eoled "soon", for example.
>>> 
>>> Rémy
>>> 
>>> 
 
 I guess ee modules can move to tomee too - any other consumer - with
>> the
 relevant adaptations to our codebase?
 
 Romain Manni-Bucau
 @rmannibucau  |  Blog
  | Old Blog
  | Github <
 https://github.com/rmannibucau> |
 LinkedIn  | Book
 <
 
>>> 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
> 
 
 
 Le lun. 29 juin 2020 à 13:38, Gurkan Erdogdu >> 
>>> a
 écrit :
 
> Hi folks
> I would like to discuss to remove the following modules from the OWB
>>> code
> base.
> 
>   - webbeans-jms : We introduced this module years ago for JMS but
 frankly
>   never see any usage. Also, it was not completed.
>   - webbeans-tomcat7 : We introduced this modules for Tomcat7
 integration
>   but now it is useless and Tomcat already includes this integration
 with
>   more natural way (
>   https://github.com/apache/tomcat/tree/master/modules/owb)
> 
> WDYT? Any objection?
> Regards.
> Gurkan
> 
 
>>> 
>> 
>> 
>> --
>> Gurkan Erdogdu
>> http://gurkanerdogdu.blogspot.com
>> 

Re: Remove of Useless Maven Projects

[Romain Manni-Bucau]

@Gurkan Erdogdu   the first reason to keep tomcat
module is that we release it whereas o.a.tomcat:tomcat-owb does not exist
for end users today ("you can build from source" is not an option IMHO and
justifies to fork in most cases). The main difference in terms of code is
the fact tomcat integration provides a valve for the principal whereas we
only use a filter but I guess it is enough since valve will prevent to
position the filter - = capture of the principal - in the filter chain and
can therefore break apps even if it is tempting to make it always win (we
shouldn't use a thread local but we don't have much options there). Both
impl miss websocket integration - tomee has it - so it looks like
tomcat-owb is a fork of our module today, not much so release point is a
blocker for me.

With jakarta I guess we can maybe ask tomcat+jetty to get an official
servlet components injections and drop all specific code.

 Last point about the consistency for jetty AND tomcat is also key for me,
there is no reason to favor jetty and not tomcat.

+1 to drop the version from the module though, it does not make sense
anymore - was for 6 -> 7 move IIRC.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 30 juin 2020 à 00:34, Gurkan Erdogdu  a
écrit :

> Hi Remy
>
> > I would think you should keep "tomcat7" too, it's not really the same
> idea
> > as modules/owb.
> >
> I have looked at both implementations and both are the same purpose,
> injection into  Servlet related classes and get the current Principal from
> the request. In Tomcat/OWB module, its integration is more natural than the
> Tomcat7 module.
> What is the benefit of using Tomcat7 in OWB?
> Regards.
> Gurkan
>
>
> On Tue, Jun 30, 2020 at 12:33 AM Rémy Maucherat  wrote:
>
> > On Mon, Jun 29, 2020 at 1:54 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > +1 to drop jms module, never saw any usage of it
> > > -0.5 for tomcat7, rational being that if we want to do it, we should
> (at
> > > the same time) 1. ensure tomcat module is at least 1-1 (not the case I
> > > think) + released properly and not just a sandbox and 2. drop jetty
> > > integration too (which can be envisioned since we worked to integrate
> OWB
> > > in jetty itself) but dropping tomcat7 module without these two
> conditions
> > > looks like an user regression to me.
> > >
> >
> > I would think you should keep "tomcat7" too, it's not really the same
> idea
> > as modules/owb. The main problem is using a version number in the module
> > name, that creates confusion in the long run and gives the impression it
> is
> > outdated. Tomcat 7 will be eoled "soon", for example.
> >
> > Rémy
> >
> >
> > >
> > > I guess ee modules can move to tomee too - any other consumer - with
> the
> > > relevant adaptations to our codebase?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 29 juin 2020 à 13:38, Gurkan Erdogdu  >
> > a
> > > écrit :
> > >
> > > > Hi folks
> > > > I would like to discuss to remove the following modules from the OWB
> > code
> > > > base.
> > > >
> > > >- webbeans-jms : We introduced this module years ago for JMS but
> > > frankly
> > > >never see any usage. Also, it was not completed.
> > > >- webbeans-tomcat7 : We introduced this modules for Tomcat7
> > > integration
> > > >but now it is useless and Tomcat already includes this integration
> > > with
> > > >more natural way (
> > > >https://github.com/apache/tomcat/tree/master/modules/owb)
> > > >
> > > > WDYT? Any objection?
> > > > Regards.
> > > > Gurkan
> > > >
> > >
> >
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>

Re: Remove of Useless Maven Projects

[Mark Struberg]

> creates confusion in the long run and gives the impression it is
> outdated. Tomcat 7 will be eoled "soon", for example.

Good point. We once had a 'tomcat' module which was for tomcat6. Tomcat7 
introduced a new API which we utilised. Thus the name.
That API still exists. The only thing which kept us from renaming it back to 
tomcat is that we didn't want to change the maven groupId/artifactId tupple.

I'd say we are very supportive of having a single point where the latest and 
greatest version of that plugin exists. I personally don't care much where that 
is. We are all a big family after all. The only real requirement is that it is 
well maintained and regularly released.
This is similar to the tomcat maven integration which sadly is an outdated 
pain. Once it was extremely good, but without proper releases - as part of the 
standard release cycle - it became increasingly problematic. And that's what I 
fear if we solely have the integration on tomcat side for owb too.

It would need to be part of the core. And tomcat would finally need to get a 
proper build system ;)
There is also the technical aspect with the integration. 
I suspect that tomcat provides an SPI which is really generic. Wheras the OWB 
side of the integration is usind the webbeans-web module as base plus a few 
internal tricks. We could see the webbeans-web module as SPI which is _rather_ 
stable, but was not strictly handled as SPI by us.
The question therefore is which part of the integration is more fluent and 
likely to change more often? tomcats SPI or the OWB side?
We should put the integration on the side which is more likely to change in the 
future.

LieGrue,
strub



> Am 29.06.2020 um 23:33 schrieb Rémy Maucherat :
> 
> On Mon, Jun 29, 2020 at 1:54 PM Romain Manni-Bucau  >
> wrote:
> 
>> +1 to drop jms module, never saw any usage of it
>> -0.5 for tomcat7, rational being that if we want to do it, we should (at
>> the same time) 1. ensure tomcat module is at least 1-1 (not the case I
>> think) + released properly and not just a sandbox and 2. drop jetty
>> integration too (which can be envisioned since we worked to integrate OWB
>> in jetty itself) but dropping tomcat7 module without these two conditions
>> looks like an user regression to me.
>> 
> 
> I would think you should keep "tomcat7" too, it's not really the same idea
> as modules/owb. The main problem is using a version number in the module
> name, that creates confusion in the long run and gives the impression it is
> outdated. Tomcat 7 will be eoled "soon", for example.
> 
> Rémy
> 
> 
>> 
>> I guess ee modules can move to tomee too - any other consumer - with the
>> relevant adaptations to our codebase?
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le lun. 29 juin 2020 à 13:38, Gurkan Erdogdu  a
>> écrit :
>> 
>>> Hi folks
>>> I would like to discuss to remove the following modules from the OWB code
>>> base.
>>> 
>>>   - webbeans-jms : We introduced this module years ago for JMS but
>> frankly
>>>   never see any usage. Also, it was not completed.
>>>   - webbeans-tomcat7 : We introduced this modules for Tomcat7
>> integration
>>>   but now it is useless and Tomcat already includes this integration
>> with
>>>   more natural way (
>>>   https://github.com/apache/tomcat/tree/master/modules/owb)
>>> 
>>> WDYT? Any objection?
>>> Regards.
>>> Gurkan

Re: Remove of Useless Maven Projects

[Gurkan Erdogdu]

Hi Remy

> I would think you should keep "tomcat7" too, it's not really the same idea
> as modules/owb.
>
I have looked at both implementations and both are the same purpose,
injection into  Servlet related classes and get the current Principal from
the request. In Tomcat/OWB module, its integration is more natural than the
Tomcat7 module.
What is the benefit of using Tomcat7 in OWB?
Regards.
Gurkan


On Tue, Jun 30, 2020 at 12:33 AM Rémy Maucherat  wrote:

> On Mon, Jun 29, 2020 at 1:54 PM Romain Manni-Bucau 
> wrote:
>
> > +1 to drop jms module, never saw any usage of it
> > -0.5 for tomcat7, rational being that if we want to do it, we should (at
> > the same time) 1. ensure tomcat module is at least 1-1 (not the case I
> > think) + released properly and not just a sandbox and 2. drop jetty
> > integration too (which can be envisioned since we worked to integrate OWB
> > in jetty itself) but dropping tomcat7 module without these two conditions
> > looks like an user regression to me.
> >
>
> I would think you should keep "tomcat7" too, it's not really the same idea
> as modules/owb. The main problem is using a version number in the module
> name, that creates confusion in the long run and gives the impression it is
> outdated. Tomcat 7 will be eoled "soon", for example.
>
> Rémy
>
>
> >
> > I guess ee modules can move to tomee too - any other consumer - with the
> > relevant adaptations to our codebase?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 29 juin 2020 à 13:38, Gurkan Erdogdu 
> a
> > écrit :
> >
> > > Hi folks
> > > I would like to discuss to remove the following modules from the OWB
> code
> > > base.
> > >
> > >- webbeans-jms : We introduced this module years ago for JMS but
> > frankly
> > >never see any usage. Also, it was not completed.
> > >- webbeans-tomcat7 : We introduced this modules for Tomcat7
> > integration
> > >but now it is useless and Tomcat already includes this integration
> > with
> > >more natural way (
> > >https://github.com/apache/tomcat/tree/master/modules/owb)
> > >
> > > WDYT? Any objection?
> > > Regards.
> > > Gurkan
> > >
> >
>


-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Remove of Useless Maven Projects

[Rémy Maucherat]

On Mon, Jun 29, 2020 at 1:54 PM Romain Manni-Bucau 
wrote:

> +1 to drop jms module, never saw any usage of it
> -0.5 for tomcat7, rational being that if we want to do it, we should (at
> the same time) 1. ensure tomcat module is at least 1-1 (not the case I
> think) + released properly and not just a sandbox and 2. drop jetty
> integration too (which can be envisioned since we worked to integrate OWB
> in jetty itself) but dropping tomcat7 module without these two conditions
> looks like an user regression to me.
>

I would think you should keep "tomcat7" too, it's not really the same idea
as modules/owb. The main problem is using a version number in the module
name, that creates confusion in the long run and gives the impression it is
outdated. Tomcat 7 will be eoled "soon", for example.

Rémy


>
> I guess ee modules can move to tomee too - any other consumer - with the
> relevant adaptations to our codebase?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 29 juin 2020 à 13:38, Gurkan Erdogdu  a
> écrit :
>
> > Hi folks
> > I would like to discuss to remove the following modules from the OWB code
> > base.
> >
> >- webbeans-jms : We introduced this module years ago for JMS but
> frankly
> >never see any usage. Also, it was not completed.
> >- webbeans-tomcat7 : We introduced this modules for Tomcat7
> integration
> >but now it is useless and Tomcat already includes this integration
> with
> >more natural way (
> >https://github.com/apache/tomcat/tree/master/modules/owb)
> >
> > WDYT? Any objection?
> > Regards.
> > Gurkan
> >
>

Re: Remove of Useless Maven Projects

[Thomas Andraschko]

+1 for jms
-0.25 for tomcat

What is superior in our module?


Mark Struberg  schrieb am Mo., 29. Juni 2020,
18:48:

> +1 to drop jpms
> -1 to drop tomcat7. It is still used a lot. I'm not sure about the status
> of the integration directly in tomcat. The initial code was not really
> superior to ours. And ours still runs perfectly fine on tomcat9 (and
> tomcat10 with jakartaEE)
>
> LieGrue,
> strub
>
>
> > Am 29.06.2020 um 13:54 schrieb Romain Manni-Bucau  >:
> >
> > +1 to drop jms module, never saw any usage of it
> > -0.5 for tomcat7, rational being that if we want to do it, we should (at
> > the same time) 1. ensure tomcat module is at least 1-1 (not the case I
> > think) + released properly and not just a sandbox and 2. drop jetty
> > integration too (which can be envisioned since we worked to integrate OWB
> > in jetty itself) but dropping tomcat7 module without these two conditions
> > looks like an user regression to me.
> >
> > I guess ee modules can move to tomee too - any other consumer - with the
> > relevant adaptations to our codebase?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le lun. 29 juin 2020 à 13:38, Gurkan Erdogdu 
> a
> > écrit :
> >
> >> Hi folks
> >> I would like to discuss to remove the following modules from the OWB
> code
> >> base.
> >>
> >>   - webbeans-jms : We introduced this module years ago for JMS but
> frankly
> >>   never see any usage. Also, it was not completed.
> >>   - webbeans-tomcat7 : We introduced this modules for Tomcat7
> integration
> >>   but now it is useless and Tomcat already includes this integration
> with
> >>   more natural way (
> >>   https://github.com/apache/tomcat/tree/master/modules/owb)
> >>
> >> WDYT? Any objection?
> >> Regards.
> >> Gurkan
> >>
>
>

Re: Remove of Useless Maven Projects

[Mark Struberg]

+1 to drop jpms
-1 to drop tomcat7. It is still used a lot. I'm not sure about the status of 
the integration directly in tomcat. The initial code was not really superior to 
ours. And ours still runs perfectly fine on tomcat9 (and tomcat10 with 
jakartaEE)

LieGrue,
strub


> Am 29.06.2020 um 13:54 schrieb Romain Manni-Bucau :
> 
> +1 to drop jms module, never saw any usage of it
> -0.5 for tomcat7, rational being that if we want to do it, we should (at
> the same time) 1. ensure tomcat module is at least 1-1 (not the case I
> think) + released properly and not just a sandbox and 2. drop jetty
> integration too (which can be envisioned since we worked to integrate OWB
> in jetty itself) but dropping tomcat7 module without these two conditions
> looks like an user regression to me.
> 
> I guess ee modules can move to tomee too - any other consumer - with the
> relevant adaptations to our codebase?
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le lun. 29 juin 2020 à 13:38, Gurkan Erdogdu  a
> écrit :
> 
>> Hi folks
>> I would like to discuss to remove the following modules from the OWB code
>> base.
>> 
>>   - webbeans-jms : We introduced this module years ago for JMS but frankly
>>   never see any usage. Also, it was not completed.
>>   - webbeans-tomcat7 : We introduced this modules for Tomcat7 integration
>>   but now it is useless and Tomcat already includes this integration with
>>   more natural way (
>>   https://github.com/apache/tomcat/tree/master/modules/owb)
>> 
>> WDYT? Any objection?
>> Regards.
>> Gurkan
>> 

Re: Remove of Useless Maven Projects

[Romain Manni-Bucau]

+1 to drop jms module, never saw any usage of it
-0.5 for tomcat7, rational being that if we want to do it, we should (at
the same time) 1. ensure tomcat module is at least 1-1 (not the case I
think) + released properly and not just a sandbox and 2. drop jetty
integration too (which can be envisioned since we worked to integrate OWB
in jetty itself) but dropping tomcat7 module without these two conditions
looks like an user regression to me.

I guess ee modules can move to tomee too - any other consumer - with the
relevant adaptations to our codebase?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 29 juin 2020 à 13:38, Gurkan Erdogdu  a
écrit :

> Hi folks
> I would like to discuss to remove the following modules from the OWB code
> base.
>
>- webbeans-jms : We introduced this module years ago for JMS but frankly
>never see any usage. Also, it was not completed.
>- webbeans-tomcat7 : We introduced this modules for Tomcat7 integration
>but now it is useless and Tomcat already includes this integration with
>more natural way (
>https://github.com/apache/tomcat/tree/master/modules/owb)
>
> WDYT? Any objection?
> Regards.
> Gurkan
>