Re: [DISCUSS] 1.x EOL

[Romain Manni-Bucau]

2017-06-19 16:04 GMT+02:00 Jonathan Gallimore 
:

> Firstly, I note the page Romain started - thank you for listening to my
> feedback. I'd be happy to test instructions and contribute to that page. I
> suspect some DBCP(2) settings are different so we should call those out.
> I'll also try and help build it out into a step by step guide.
>

Hmm, database pool can need there own thread but current doc basically says
"read the pool doc" cause each time we copied it, we ended up messing more
than solving in term of user experience so I'm not sure we should do this
exercise. That said +1 to add a point saying it should be validated. Tomcat
pool being the default we shouldn't be too much affected in "prod".


>
> Secondly, I have been thinking about the EOL. I personally really dislike
> the term 'End of life' for an Open Source project / branch. The branch will
> ultimately live on while there are committers / contributors whether
> individual or organizations that are prepared to provide patches. The
> OpenEJB Eclipse Plugin could be thought of as "End Of Life", but if someone
> showed up on the mailing list wanting to use it with the latest version of
> Eclipse, and it didn't work (which I expect is the case), or found a bug,
> truthfully, I would be simply delighted to update it - so in that regard it
> isn't EOL.
>

Agree but think not using EOL would be misleading. What we want is to:

1. show 1.x is not more active
2. 1.x is no more maintained (and once again this is not linked to our only
will in term of OS ecosystem)
3. you should migrate to 7

I'm fine detailling it in the announce but not sure if using a more
accurate term (EOS - end of support ?) wouldn't be more misleading :s


>
> Similarly, if someone / an organization wanted to contribute and maintain
> 1.7.x, then there shouldn't really be any blocker to them doing so, and
> therefore it also wouldn't be EOL.
>

Well the OS side is a blocker. This means 1.x needs to live with a tons of
fork which should be ack by tomee project before being an option.


>
> I do, however, appreciate that there is a desire for people to migrate to
> the latest version, as there is more activity there in terms of later specs
> and new functionality, and I also appreciate the issue where dependencies
> 1.7.x uses may not be updated any more.
>
> I'd like to make the suggestion that we give an honest statement about each
> version available, in order to help facilitate decision making. As to what
> "honest statement" means... well I think we'd need to discuss and agree the
> specific statements. Off the top of my head, it could be something like:
>
> Pre-1.7.x: No longer being updated within the community.
> 1.7.x: Stable, certified, supports Java EE 6 Web Profile. Receives security
> fixes, occasional feature updates and backports, and bug fixes. Last
> commit: -MM-dd, last release: -MM-dd. N.B. some dependencies (e.g.
> ) no longer receive updates. Consider upgrading to 7.0, see the
> migration guide here: http://tomee.apache.org/
> 7.x: Stable, GA, supports Java EE 7 Web Profile. Actively developed,
> receives security fixes, numerous feature updates and bug fixes. Last
> commit: -MM-dd, last release: -MM-dd
> 8.x: In progress, not yet GA, supports Java EE 8 Web Profile. Consider this
> to be ahead of "bleeding edge". Last commit: -MM-dd, last release:
> -MM-dd
>
>
Hmm, this looks really awesome and close to what we should go with IMHO but
experience shows it is not as reliable as it is written to. Maybe we should
rephrase it more in a way saying "maintained as best effort allows and when
some companies want, will be EOL [next year]" - "EOL" and "next year" to
replace by this thread outcome indeed.

What I want to avoid here is the understanding 1.7 will get backports or
security fixes systematically which never have been the case - not blaming
since I'm a lot responsible of it but just trying to be realistic with our
resources.


> Thoughts?
>
> Jon
>
> On Mon, Jun 19, 2017 at 2:42 PM, Andy Gumbrecht 
> wrote:
>
> > -1
> >
> > I would welcome an EOL announcement at the end of the year (with a years
> > notice), but not right now. That's too much pressure. So to make that
> > clear, I would announce EOL on the 1st Jan.18 and EOL is then 1st Jan
> 2019
> > - That gives everyone plenty of time to create detailed documentation on
> > the site that targets everyone, and then plenty of time to migrate.
> >
> > We could make a pre-EOL announcement that details the above plan. An
> > announcement of the planned announcement so to say - That would enable
> > contribution and discussion regarding the EOL effort by the community
> > rather than being a snap decision.
> >
> > Andy.
> >
> > On 18 June 2017 at 20:36, Romain Manni-Bucau 
> > wrote:
> >
> > > http://tomee.apache.org/developer/migration/tomee-1-to-7.html intends
> to
> > > solve that issue, we can add 

Re: [DISCUSS] 1.x EOL

[Jonathan Gallimore]

Firstly, I note the page Romain started - thank you for listening to my
feedback. I'd be happy to test instructions and contribute to that page. I
suspect some DBCP(2) settings are different so we should call those out.
I'll also try and help build it out into a step by step guide.

Secondly, I have been thinking about the EOL. I personally really dislike
the term 'End of life' for an Open Source project / branch. The branch will
ultimately live on while there are committers / contributors whether
individual or organizations that are prepared to provide patches. The
OpenEJB Eclipse Plugin could be thought of as "End Of Life", but if someone
showed up on the mailing list wanting to use it with the latest version of
Eclipse, and it didn't work (which I expect is the case), or found a bug,
truthfully, I would be simply delighted to update it - so in that regard it
isn't EOL.

Similarly, if someone / an organization wanted to contribute and maintain
1.7.x, then there shouldn't really be any blocker to them doing so, and
therefore it also wouldn't be EOL.

I do, however, appreciate that there is a desire for people to migrate to
the latest version, as there is more activity there in terms of later specs
and new functionality, and I also appreciate the issue where dependencies
1.7.x uses may not be updated any more.

I'd like to make the suggestion that we give an honest statement about each
version available, in order to help facilitate decision making. As to what
"honest statement" means... well I think we'd need to discuss and agree the
specific statements. Off the top of my head, it could be something like:

Pre-1.7.x: No longer being updated within the community.
1.7.x: Stable, certified, supports Java EE 6 Web Profile. Receives security
fixes, occasional feature updates and backports, and bug fixes. Last
commit: -MM-dd, last release: -MM-dd. N.B. some dependencies (e.g.
) no longer receive updates. Consider upgrading to 7.0, see the
migration guide here: http://tomee.apache.org/
7.x: Stable, GA, supports Java EE 7 Web Profile. Actively developed,
receives security fixes, numerous feature updates and bug fixes. Last
commit: -MM-dd, last release: -MM-dd
8.x: In progress, not yet GA, supports Java EE 8 Web Profile. Consider this
to be ahead of "bleeding edge". Last commit: -MM-dd, last release:
-MM-dd

Thoughts?

Jon

On Mon, Jun 19, 2017 at 2:42 PM, Andy Gumbrecht 
wrote:

> -1
>
> I would welcome an EOL announcement at the end of the year (with a years
> notice), but not right now. That's too much pressure. So to make that
> clear, I would announce EOL on the 1st Jan.18 and EOL is then 1st Jan 2019
> - That gives everyone plenty of time to create detailed documentation on
> the site that targets everyone, and then plenty of time to migrate.
>
> We could make a pre-EOL announcement that details the above plan. An
> announcement of the planned announcement so to say - That would enable
> contribution and discussion regarding the EOL effort by the community
> rather than being a snap decision.
>
> Andy.
>
> On 18 June 2017 at 20:36, Romain Manni-Bucau 
> wrote:
>
> > http://tomee.apache.org/developer/migration/tomee-1-to-7.html intends to
> > solve that issue, we can add any point we hit/encounter
> >
> > what else would be a blocker to make 1 EOL in June 2018?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  > rmannibucau> |
> > LinkedIn  | JavaEE Factory
> > 
> >
> > 2017-06-18 20:17 GMT+02:00 Romain Manni-Bucau :
> >
> > >
> > >
> > > 2017-06-18 19:50 GMT+02:00 Mark Struberg :
> > >
> > >> regarding migration.
> > >> There are 3 different main use cases afaict.
> > >> 1.) TomEE standalone server, quite like Tomcat. Using 7.x instead
> 1.7.x
> > >> should be a no-brainer without any need to change something within
> your
> > >> application
> > >>
> > >> 2.) tomee-maven-plugin: change the groupId from org.apache.openejb to
> > >> org.apache.tomee. Done
> > >>
> > >
> > >
> > >
> > >
> > >> 3.) openejb-core for unit tests. This gets a bit trickier as the
> various
> > >> spec APIs from EE7 (tomee) and EE6 (your application) might clash.
> This
> > can
> > >> be solved with an exclude setting in the maven-surefire-plugin
> > >>
> > >
> > > Hmm, just means we upgrade API or you think to something else?
> > >
> > > I'll start a page
> > >
> > >
> > >> LieGrue,strub
> > >>
> > >>
> > >> On Sunday, 18 June 2017, 18:51, Romain Manni-Bucau <
> > >> rmannibu...@gmail.com> wrote:
> > >>
> > >>
> > >>  2017-06-18 18:42 GMT+02:00 Jonathan Gallimore <
> > jgallim...@tomitribe.com
> > >> >:
> > >>
> > >> > Thanks for the feedback. I think 

Re: [DISCUSS] 1.x EOL

[Romain Manni-Bucau]

I read it as:

1. we need 1 year of delay before it is actually EOL - which was the
proposal
2. we need doc - which has been done for the known part

Concretely I don't see how much it is different from the original plan
(which needs to be translated by 1 month now) until there is a *string*
commitment we'll get 0.1 FTE on 1 year working on that topic so on my side
I'd say better to do it earlier instead of delaying it against the fact we
don't maintain it.

Don't forget we'll surely move master on TomEE 8 soon and I don't see
current activity maintaining so much versions - last 6 years proved me
being right :(.



Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-06-19 15:42 GMT+02:00 Andy Gumbrecht :

> -1
>
> I would welcome an EOL announcement at the end of the year (with a years
> notice), but not right now. That's too much pressure. So to make that
> clear, I would announce EOL on the 1st Jan.18 and EOL is then 1st Jan 2019
> - That gives everyone plenty of time to create detailed documentation on
> the site that targets everyone, and then plenty of time to migrate.
>
> We could make a pre-EOL announcement that details the above plan. An
> announcement of the planned announcement so to say - That would enable
> contribution and discussion regarding the EOL effort by the community
> rather than being a snap decision.
>
> Andy.
>
> On 18 June 2017 at 20:36, Romain Manni-Bucau 
> wrote:
>
> > http://tomee.apache.org/developer/migration/tomee-1-to-7.html intends to
> > solve that issue, we can add any point we hit/encounter
> >
> > what else would be a blocker to make 1 EOL in June 2018?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  > rmannibucau> |
> > LinkedIn  | JavaEE Factory
> > 
> >
> > 2017-06-18 20:17 GMT+02:00 Romain Manni-Bucau :
> >
> > >
> > >
> > > 2017-06-18 19:50 GMT+02:00 Mark Struberg :
> > >
> > >> regarding migration.
> > >> There are 3 different main use cases afaict.
> > >> 1.) TomEE standalone server, quite like Tomcat. Using 7.x instead
> 1.7.x
> > >> should be a no-brainer without any need to change something within
> your
> > >> application
> > >>
> > >> 2.) tomee-maven-plugin: change the groupId from org.apache.openejb to
> > >> org.apache.tomee. Done
> > >>
> > >
> > >
> > >
> > >
> > >> 3.) openejb-core for unit tests. This gets a bit trickier as the
> various
> > >> spec APIs from EE7 (tomee) and EE6 (your application) might clash.
> This
> > can
> > >> be solved with an exclude setting in the maven-surefire-plugin
> > >>
> > >
> > > Hmm, just means we upgrade API or you think to something else?
> > >
> > > I'll start a page
> > >
> > >
> > >> LieGrue,strub
> > >>
> > >>
> > >> On Sunday, 18 June 2017, 18:51, Romain Manni-Bucau <
> > >> rmannibu...@gmail.com> wrote:
> > >>
> > >>
> > >>  2017-06-18 18:42 GMT+02:00 Jonathan Gallimore <
> > jgallim...@tomitribe.com
> > >> >:
> > >>
> > >> > Thanks for the feedback. I think at least some sort of migration
> guide
> > >> is
> > >> > needed as some settings have changed. It would be nice for people to
> > >> find
> > >> > out the easy way. Happy to discuss in another thread, but we should
> > >> agree
> > >> > when this will appear.
> > >> >
> > >>
> > >> Which settings are you thinking about?
> > >>
> > >>
> > >> >
> > >> > I also think some visibility on what the EOL statement will actually
> > >> say (I
> > >> > guess it would be a paragraph or two) would help community
> discussion.
> > >> >
> > >>
> > >> No more expectation from the core community (releases etc). So
> > evolutions
> > >> as best effort (no guarantee).
> > >>
> > >>
> > >> >
> > >> > I suspect you won't agree, but I think an EOL is a major
> > announcement. A
> > >> > reminder is good if the thread has gone quiet, but I think lazy
> > >> concensus
> > >> > is less good, unless several reminders have been sent. You have
> > stated a
> > >> > deadline of today, a Sunday - I think some folks may miss that and
> be
> > >> too
> > >> > late. I think mid week would be better to reduce the scope of
> "missing
> > >> it".
> > >> > If we got to mid week, and had a couple more reminders, the lazy
> > >> concensus
> > >> > view would seem more reasonable.
> > >> >
> > >> > Wouldn't you prefer to make the EOL statement with a few more +1's?
> > >> >
> > >>
> > >> Sure, now i used past releases as prevision of this topic activity
> > >> 

Re: The EE8 Roadmap

[Andy Gumbrecht]

+1 for TomEE 8, when it's time - I'm sure that was what we agreed when we
made the move to TomEE 7, the major version stays inline with the EE
version. Makes it pretty clear.

Andy.

On 18 June 2017 at 18:08, Romain Manni-Bucau  wrote:

> mvc too is under radar, think cxf is a good fit but myfaces can be good too
> since we have web experts here
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | JavaEE Factory
> 
>
> 2017-06-18 18:07 GMT+02:00 John D. Ament :
>
> > I think it would be great to start a project in any form for the security
> > spec.
> >
> > John
> >
> > On Sun, Jun 18, 2017 at 11:35 AM Mark Struberg  >
> > wrote:
> >
> > > Or a subproject somewhere if we create it from scratch and don't take
> > over
> > > any existing sources where the IP is not 100% guaranteed to be clear.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > > > Am 18.06.2017 um 16:01 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > >
> > > > first step would probably be to create an incubator project to impl
> the
> > > spec
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn  | JavaEE Factory
> > > > 
> > > >
> > > > 2017-06-18 13:17 GMT+02:00 Mark Struberg  >:
> > > >
> > > >> Well, that would be way cool!
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>> Am 18.06.2017 um 11:54 schrieb Rudy De Busscher <
> > rdebussc...@gmail.com
> > > >:
> > > >>>
> > > >>> Great news
> > > >>>
> > > >>> What are the plans for the Security API?  It will also be included
> in
> > > the
> > > >>> Web Profile.
> > > >>>
> > > >>> I can help with the implementation if you like.
> > > >>>
> > > >>> Best regards
> > > >>> Rudy
> > > >>>
> > > >>>
> > > >>> On 17 June 2017 at 21:57, Mark Struberg  >
> > > >> wrote:
> > > >>>
> > >  FYI, With help from Romain, Reinhard Sandtner, Gerhard Petracek
> and
> > > John
> > >  Ament,  Apache OpenWebBeans now passes the CDI-2.0 TCK!
> > > 
> > >  The next step is to do a bit more testing, release the missing
> > > Geronimo
> > >  spec APIs and then we are good to go for rolling TomEE-8.0.0 ^^
> > > 
> > >  LieGrue,
> > >  strub
> > > 
> > > 
> > > 
> > > > Am 05.06.2017 um 12:59 schrieb Jean-Louis Monteiro <
> > >  jlmonte...@tomitribe.com>:
> > > >
> > > > Wow, great status Mark.
> > > > Thanks a lot.
> > > >
> > > > Yes, agree, TomEE 8.x seems to be the de facto choice based on
> what
> > > the
> > > > community decided last time.
> > > > Even though the time is missing I'd like to help somehow and join
> > the
> > > > effort.
> > > >
> > > > I'll shoot when I have some time.
> > > >
> > > > Cheers.
> > > >
> > > >
> > > >
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com
> > > >
> > > > On Fri, Jun 2, 2017 at 8:55 PM, Romain Manni-Bucau <
> > >  rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > >> 2017-06-02 20:27 GMT+02:00 Mark Struberg
> >  > > >:
> > > >>
> > > >>> Hi folks!
> > > >>>
> > > >>> Behind the scene there was a lot of work done towards EE8.
> > > >>> Not directly in TomEE, but in most parts which are needed
> > > >>>
> > > >>> * Tomcat 9 for Servlet 4.0 - While the final API is not yet
> ready
> > > we
> > > >>> already have many public Milestone builds
> > > >>>
> > > >>> * OpenWebBeans-2.0.x for CDI 2.0 - We already implemented most
> of
> > > the
> > >  new
> > > >>> features and are down to 35 failing TCK tests (out of 1300).
> > Might
> > > >> take
> > > >> us
> > > >>> 2 more weeks to finish, but we are already very close
> > > >>>
> > > >>> * BVal - Matt Benson is working like wild for implementing the
> > new
> > > >> spec
> > > >>> changes. Once OWB is finished Romain and I will join the effort
> > > with
> > >  more
> > > >>> power. Others are welcome to help of course!
> > > >>>
> > > >>> * Johnzon for JSON-P 1.1 and JSON-B 1.0: 1.1.1 is currently
> being
> > > >>> released. Works like a charm!
> > > >>>
> > > >>> * MyFaces - gonna need to check the latest status, but I think
> > Leo
> > > >> has
> > > 

Re: [DISCUSS] 1.x EOL

[Andy Gumbrecht]

-1

I would welcome an EOL announcement at the end of the year (with a years
notice), but not right now. That's too much pressure. So to make that
clear, I would announce EOL on the 1st Jan.18 and EOL is then 1st Jan 2019
- That gives everyone plenty of time to create detailed documentation on
the site that targets everyone, and then plenty of time to migrate.

We could make a pre-EOL announcement that details the above plan. An
announcement of the planned announcement so to say - That would enable
contribution and discussion regarding the EOL effort by the community
rather than being a snap decision.

Andy.

On 18 June 2017 at 20:36, Romain Manni-Bucau  wrote:

> http://tomee.apache.org/developer/migration/tomee-1-to-7.html intends to
> solve that issue, we can add any point we hit/encounter
>
> what else would be a blocker to make 1 EOL in June 2018?
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | JavaEE Factory
> 
>
> 2017-06-18 20:17 GMT+02:00 Romain Manni-Bucau :
>
> >
> >
> > 2017-06-18 19:50 GMT+02:00 Mark Struberg :
> >
> >> regarding migration.
> >> There are 3 different main use cases afaict.
> >> 1.) TomEE standalone server, quite like Tomcat. Using 7.x instead 1.7.x
> >> should be a no-brainer without any need to change something within your
> >> application
> >>
> >> 2.) tomee-maven-plugin: change the groupId from org.apache.openejb to
> >> org.apache.tomee. Done
> >>
> >
> >
> >
> >
> >> 3.) openejb-core for unit tests. This gets a bit trickier as the various
> >> spec APIs from EE7 (tomee) and EE6 (your application) might clash. This
> can
> >> be solved with an exclude setting in the maven-surefire-plugin
> >>
> >
> > Hmm, just means we upgrade API or you think to something else?
> >
> > I'll start a page
> >
> >
> >> LieGrue,strub
> >>
> >>
> >> On Sunday, 18 June 2017, 18:51, Romain Manni-Bucau <
> >> rmannibu...@gmail.com> wrote:
> >>
> >>
> >>  2017-06-18 18:42 GMT+02:00 Jonathan Gallimore <
> jgallim...@tomitribe.com
> >> >:
> >>
> >> > Thanks for the feedback. I think at least some sort of migration guide
> >> is
> >> > needed as some settings have changed. It would be nice for people to
> >> find
> >> > out the easy way. Happy to discuss in another thread, but we should
> >> agree
> >> > when this will appear.
> >> >
> >>
> >> Which settings are you thinking about?
> >>
> >>
> >> >
> >> > I also think some visibility on what the EOL statement will actually
> >> say (I
> >> > guess it would be a paragraph or two) would help community discussion.
> >> >
> >>
> >> No more expectation from the core community (releases etc). So
> evolutions
> >> as best effort (no guarantee).
> >>
> >>
> >> >
> >> > I suspect you won't agree, but I think an EOL is a major
> announcement. A
> >> > reminder is good if the thread has gone quiet, but I think lazy
> >> concensus
> >> > is less good, unless several reminders have been sent. You have
> stated a
> >> > deadline of today, a Sunday - I think some folks may miss that and be
> >> too
> >> > late. I think mid week would be better to reduce the scope of "missing
> >> it".
> >> > If we got to mid week, and had a couple more reminders, the lazy
> >> concensus
> >> > view would seem more reasonable.
> >> >
> >> > Wouldn't you prefer to make the EOL statement with a few more +1's?
> >> >
> >>
> >> Sure, now i used past releases as prevision of this topic activity
> >> plannification and even with 5 reminders i wouldnt have got more so
> >> preferring to move forward now. However as said  I'm happy to discuss
> each
> >> points and delay what was just a proposal.
> >>
> >>
> >> >
> >> > Jon
> >> >
> >> > On 18 Jun 2017 5:06 pm, "Romain Manni-Bucau" 
> >> > wrote:
> >> >
> >> > > 2017-06-18 17:36 GMT+02:00 Jonathan Gallimore <
> >> > > jonathan.gallim...@gmail.com>
> >> > > :
> >> > >
> >> > > > On 18 Jun 2017 3:11 pm, "Romain Manni-Bucau" <
> rmannibu...@gmail.com
> >> >
> >> > > > wrote:
> >> > > >
> >> > > > @Jon: please propose a policy then (same as rejecting a release,
> >> "no"
> >> > is
> >> > > > valid only if an alternative is proposed or a string blocker is
> >> found
> >> > > ;)).
> >> > > >
> >> > > >
> >> > > > I feel I stated my concerns pretty clearly. I didn't just reply -1
> >> and
> >> > > walk
> >> > > > away, which is what your comment above is suggesting I did.
> >> > > >
> >> > >
> >> > > Ok then understand it as i dont read it as an exit path for the
> >> project.
> >> > >
> >> > >
> >> > > >
> >> > > > But, allow me to rephrase anyway - beyond a "drop dead" date, what
> >> > > exactly
> >> > > > is your policy?
> >> > > >
> >> > > > How many releases do you see in 

Re: CompManagedBean & @DatasourceDefinition - TOMEE-2053

[Romain Manni-Bucau]

big fingers :(

thanks for the catch, should be fixed. Build in progress at
https://ci.apache.org/builders/tomee-trunk-ubuntu/builds/777


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-06-19 9:20 GMT+02:00 Svetlin Zarev :

> Hi,
>
> The DataSourcePojo.java is missing from master, and the arquilian tests
> fail to compile. May you add it:
> https://github.com/apache/tomee/pull/74/commits/
> 26ee7018df455c3a5b46c6a0b87adb38feeab34f#diff-
> c89f954c712eb9ab263f8acf8d75586f
> ?
>
> Kind regadrs,
> Svetlin
>
> 2017-06-17 11:13 GMT+03:00 Romain Manni-Bucau :
>
> > You rock Svetlin, applied, thanks a lot!
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  > rmannibucau> |
> > LinkedIn  | JavaEE Factory
> > 
> >
> > 2017-06-17 7:56 GMT+02:00 Svetlin Zarev  >:
> >
> > > Hi,
> > >
> > > Here it is: https://github.com/apache/tomee/pull/74
> > >
> > > Kind regards,
> > > Svetlin
> > >
> > >
> > > 2017-06-16 23:44 GMT+03:00 Svetlin Zarev  > com
> > > >:
> > >
> > > > The test fails, because the @DataSourceDefinition is used on a POJO -
> > > i.e.
> > > > it's not a JndiConsumer, hence the ConvertDataSourceDefinitions
> > deployer
> > > > cannot know that such definition exists. I'll have to check the spec
> if
> > > it
> > > > mentions which classes can be annotated with @DataSourceDefinition,
> but
> > > > either way it would be easy to fix. I'll take a look tomorrow :)
> > > >
> > > > Kind regards,
> > > > Svetlin
> > > >
> > > > 2017-06-16 22:37 GMT+03:00 Romain Manni-Bucau  >:
> > > >
> > > >> Trunk seems to have an issue with this in the test
> > > >> XADataSourceDefinitionTest
> > > >>
> > > >> Want to have a look?
> > > >>
> > > >>
> > > >> Romain Manni-Bucau
> > > >> @rmannibucau  |  Blog
> > > >>  | Old Blog
> > > >>  | Github <
> > > >> https://github.com/rmannibucau> |
> > > >> LinkedIn  | JavaEE Factory
> > > >> 
> > > >>
> > > >> 2017-06-16 20:46 GMT+02:00 Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > > >>
> > > >> > applied, thanks!
> > > >> >
> > > >> >
> > > >> > Romain Manni-Bucau
> > > >> > @rmannibucau  |  Blog
> > > >> >  | Old Blog
> > > >> >  | Github
> > > >> >  | LinkedIn
> > > >> >  | JavaEE Factory
> > > >> > 
> > > >> >
> > > >> > 2017-06-16 20:33 GMT+02:00 Svetlin Zarev
> > >  > > >> om>
> > > >> > :
> > > >> >
> > > >> >> I've fixed the license headers. Here is the PR:
> > > >> >> https://github.com/apache/tomee/pull/73
> > > >> >>
> > > >> >> I didn't check JMS, only WepProfile specs.
> > > >> >>
> > > >> >> 2017-06-16 21:01 GMT+03:00 Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > >> >>
> > > >> >> > This looks good, while the merge deployer still makes available
> > the
> > > >> >> > resource to comp it works :)
> > > >> >> >
> > > >> >> > Think you need to fix details on your PR like headers etc but
> > looks
> > > >> ok
> > > >> >> to
> > > >> >> > merge once the build pass.
> > > >> >> >
> > > >> >> > Side note: by curiosity, did you check jms resource as well? it
> > > >> should
> > > >> >> be
> > > >> >> > close ot datasources.
> > > >> >> >
> > > >> >> >
> > > >> >> > Romain Manni-Bucau
> > > >> >> > @rmannibucau  |  Blog
> > > >> >> >  | Old Blog
> > > >> >> >  | Github <
> https://github.com/
> > > >> >> > rmannibucau> |
> > > >> >> > LinkedIn  | JavaEE
> > > Factory
> > > >> >> > 
> > > >> >> >
> > > >> >> > 2017-06-16 19:56 GMT+02:00 Svetlin Zarev
> > > >>  > > >> >> om
> > > >> >> > >:
> > > >> >> >
> > > >> >> > > I'm back with tests:) :
> > > >> >> > > https://github.com/apache/tomee/compare/master...
> > > >> >> > > SvetlinZarev:ds_def?expand=1
> > > >> >> > >
> > > >> >> > > Unless I misunderstood you, it seems that DS 

Re: CompManagedBean & @DatasourceDefinition - TOMEE-2053

[Svetlin Zarev]

Hi,

The DataSourcePojo.java is missing from master, and the arquilian tests
fail to compile. May you add it:
https://github.com/apache/tomee/pull/74/commits/26ee7018df455c3a5b46c6a0b87adb38feeab34f#diff-c89f954c712eb9ab263f8acf8d75586f
?

Kind regadrs,
Svetlin

2017-06-17 11:13 GMT+03:00 Romain Manni-Bucau :

> You rock Svetlin, applied, thanks a lot!
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | JavaEE Factory
> 
>
> 2017-06-17 7:56 GMT+02:00 Svetlin Zarev :
>
> > Hi,
> >
> > Here it is: https://github.com/apache/tomee/pull/74
> >
> > Kind regards,
> > Svetlin
> >
> >
> > 2017-06-16 23:44 GMT+03:00 Svetlin Zarev  com
> > >:
> >
> > > The test fails, because the @DataSourceDefinition is used on a POJO -
> > i.e.
> > > it's not a JndiConsumer, hence the ConvertDataSourceDefinitions
> deployer
> > > cannot know that such definition exists. I'll have to check the spec if
> > it
> > > mentions which classes can be annotated with @DataSourceDefinition, but
> > > either way it would be easy to fix. I'll take a look tomorrow :)
> > >
> > > Kind regards,
> > > Svetlin
> > >
> > > 2017-06-16 22:37 GMT+03:00 Romain Manni-Bucau :
> > >
> > >> Trunk seems to have an issue with this in the test
> > >> XADataSourceDefinitionTest
> > >>
> > >> Want to have a look?
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau  |  Blog
> > >>  | Old Blog
> > >>  | Github <
> > >> https://github.com/rmannibucau> |
> > >> LinkedIn  | JavaEE Factory
> > >> 
> > >>
> > >> 2017-06-16 20:46 GMT+02:00 Romain Manni-Bucau  >:
> > >>
> > >> > applied, thanks!
> > >> >
> > >> >
> > >> > Romain Manni-Bucau
> > >> > @rmannibucau  |  Blog
> > >> >  | Old Blog
> > >> >  | Github
> > >> >  | LinkedIn
> > >> >  | JavaEE Factory
> > >> > 
> > >> >
> > >> > 2017-06-16 20:33 GMT+02:00 Svetlin Zarev
> >  > >> om>
> > >> > :
> > >> >
> > >> >> I've fixed the license headers. Here is the PR:
> > >> >> https://github.com/apache/tomee/pull/73
> > >> >>
> > >> >> I didn't check JMS, only WepProfile specs.
> > >> >>
> > >> >> 2017-06-16 21:01 GMT+03:00 Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >> >>
> > >> >> > This looks good, while the merge deployer still makes available
> the
> > >> >> > resource to comp it works :)
> > >> >> >
> > >> >> > Think you need to fix details on your PR like headers etc but
> looks
> > >> ok
> > >> >> to
> > >> >> > merge once the build pass.
> > >> >> >
> > >> >> > Side note: by curiosity, did you check jms resource as well? it
> > >> should
> > >> >> be
> > >> >> > close ot datasources.
> > >> >> >
> > >> >> >
> > >> >> > Romain Manni-Bucau
> > >> >> > @rmannibucau  |  Blog
> > >> >> >  | Old Blog
> > >> >> >  | Github  > >> >> > rmannibucau> |
> > >> >> > LinkedIn  | JavaEE
> > Factory
> > >> >> > 
> > >> >> >
> > >> >> > 2017-06-16 19:56 GMT+02:00 Svetlin Zarev
> > >>  > >> >> om
> > >> >> > >:
> > >> >> >
> > >> >> > > I'm back with tests:) :
> > >> >> > > https://github.com/apache/tomee/compare/master...
> > >> >> > > SvetlinZarev:ds_def?expand=1
> > >> >> > >
> > >> >> > > Unless I misunderstood you, it seems that DS injection in
> servlet
> > >> >> works
> > >> >> > > after the fix and does not before it (well, it injects it, but
> > with
> > >> >> wrong
> > >> >> > > config).
> > >> >> > > The reason it works is that the ConvertDataSourceDefinitions
> > >> deployer
> > >> >> > only
> > >> >> > > processes the DataSource definitions by converting them to
> > Resource
> > >> >> > objects
> > >> >> > > which are not associated with specific component, and since the
> > >> >> > > CompManagedBean does not have its own, unique definitions, if
> we
> > >> >> exclude
> > >> >> > it
> > >> >> > > from processing in that specific deployer we won't lose
> anything,
> > >> >> because
> > >> >> > > data sources with the same IDs ( and with correct config !)
> will
> > be
> > >> >> > pulled
> > >> >> > > from the JndiConsumers