Re: Need help on setting up log4j.xml

[Romain Manni-Bucau]

2016-06-03 14:05 GMT+02:00 Dignesh :

> I have placed the xml in the same classloader of log4j.jar (lib directory),
> still i dont see any log getting generated.
>
> What is the system property that needs to added to point the log4j location
> ?
>
>
>
-Dlog4j.configuration=...

you can also activate log4j.debug to know what happen

Note that if you want to use it with tomee you will likely need
-Dopenejb.log.factory=log4j.


>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Need-help-on-setting-up-log4j-xml-tp4678735p4678737.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Need help on setting up log4j.xml

[Romain Manni-Bucau]

Hi

Either set the system property to init the location of log4j or put the xml
in lib dir too (in the same classloader as log4j)
Le 3 juin 2016 14:18, "Dignesh"  a écrit :

> Hello,
> I have created custom log4j.xml file and placed in the conf directory.I
> dont
> see any file with logging getting generated. I have placed log4j.jar in the
> lib folder as well
>
> Can any one please help me where I am going wrong.Is there any other
> configuration setting where i am missing ?
>
> Attached is the log4j.xml which I have placed in the conf folder.
>
>
> log4j.xml
> 
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Need-help-on-setting-up-log4j-xml-tp4678735.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: [ANNOUNCE] Apache TomEE 7.0.0

[Romain Manni-Bucau]

@Ihsan: this should sync up soon I guess, official tag is on our main repo:
https://git1-us-west.apache.org/repos/asf?p=tomee.git;a=summary


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-30 21:52 GMT+02:00 Ihsan Ecemis :

>
> Many thanks to everyone who is involved with this, can’t wait to upgrade
> my servers to 7.0.0
>
> By the way, are you planning to tag the release on Github?  I couldn’t see
> the release here:  https://github.com/apache/tomee/releases <
> https://github.com/apache/tomee/releases>
>
>
> > On May 29, 2016, at 10:50 AM, Romain Manni-Bucau 
> wrote:
> >
> > The Apache Team Team is pleased to announce the availability of Apache
> TomEE
> > 7.0.0
> >
> > When downloading, please verify signatures using the KEYS file available
> at:
> > http://www.apache.org/dist/tomee
> >
> > Maven artifacts are also available in the central Maven repository.
> >
> >
> > The Apache TomEE Team
>
>

[ANNOUNCE] Apache TomEE 7.0.0

[Romain Manni-Bucau]

The Apache Team Team is pleased to announce the availability of Apache TomEE
 7.0.0

When downloading, please verify signatures using the KEYS file available at:
http://www.apache.org/dist/tomee

Maven artifacts are also available in the central Maven repository.


The Apache TomEE Team

[RESULT][VOTE] Apache TomEE 7.0.0

[Romain Manni-Bucau]

And here is my +1

Therefore vote passed with:
* +1 (non-binding) from Vicente Rossello, Juan Llado
* +1 (binding) from Mark, JL and me
* no -1

Will follow with the release process likely beginning of next week.

Thanks for all the ones who votes!



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-27 18:30 GMT+02:00 Jean-Louis Monteiro :

> Reviewed quickly the tentacle report.
> Downloaded the sources from the staging repo and ran a build.
>
> Got some failures with timings and the multicast module failing.
> Looks like it does not work under mac. I have seen a system property to
> skip them. Might appear as blocker but they aren't cause I don't think they
> are useful (system out instead of asserts for most of the cases). They have
> been always failing with anyone complaining.
>
> I might drop them at some point fix them when I have a bit of time.
>
> So here is my +1
>
> Thanks Romain
>
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, May 27, 2016 at 10:46 AM, Jonathan Gallimore <
> jgallim...@tomitribe.com> wrote:
>
> > Thanks Romain, I'll take a look tonight.
> >
> > Jon
> >
> > On Thu, May 26, 2016 at 2:30 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > for the one using tentacle to check notice/license files: i uploaded it
> > > there http://home.apache.org/~rmannibucau/orgapachetomee-1097/
> (skipped
> > > binaries/exploded folders cause my network connection doesn't allow
> that
> > > ATM)
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2016-05-24 12:32 GMT+02:00 Romain Manni-Bucau :
> > >
> > > > @Jon: no cause we didn't change any dependencies outside asf
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <http://rmannibucau.wordpress.com> | Github
> > > > <https://github.com/rmannibucau> | LinkedIn
> > > > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2016-05-24 11:57 GMT+02:00 Mark Struberg  >:
> > > >
> > > >> I did a run over dependencies and couldn't find anything.
> > > >>
> > > >>
> > > >> So here is my
> > > >>
> > > >>
> > > >> +1
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> > On Monday, 23 May 2016, 23:48, Romain Manni-Bucau <
> > > >> rmannibu...@gmail.com> wrote:
> > > >> > > Le 23 mai 2016 23:42, "Jean-Louis Monteiro"
> > > >> >  a
> > > >> > écrit :
> > > >> >>
> > > >> >>  So what is the status regarding the LICENSE and NOTICE?
> > > >> >
> > > >> > Nothing patrticular.
> > > >> >
> > > >> >>  Don't want to spend time checking the release if there is still
> > > >> pending
> > > >> >>  tasks to do.
> > > >> >>
> > > >> >>  We have agreed that the documentation needs to be clear
> regarding
> > > the
> > > >> >>  status of this release (not Java EE 6 certified nor Java EE 7
> > > >> certified).
> > > >> >>  Could we have that download page to be split into something
> like 2
> > > >> parts:
> > > >> >>  1.x and 7.x
> > > >> &g

Re: Example+request

[Romain Manni-Bucau]

Issue with mails is it depends on:
- the type of transport
- the provider setup
- the provider protocol (some dont respect the standard protocol)

I can share the config for gmail but it is pretty much the one you have and
it is straight forward. Yahoo is another story typically.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-26 21:54 GMT+02:00 paul :

> In order to avoid be spammed to death I am keeping any email address off
> my website and only giving the user a HTML form to fill out with a backing
> Servlet.  Then in the Servlet I am sending an email using a external email
> service provider, back to the appropriate person at their corporate email
> address.   The external email service provider requires a SSL/TLS
> connection on port 465.  There is no example on the TomEE examples page (
> https://tomee.apache.org/examples-trunk/index.html) for this use case.
> The only thread on the users form that I found is this three year old one (
> http://tomee-openejb.979440.n4.nabble.com/Not-loading-smtps-resource-properly-td4664442.html#a4664460).
> There is a lot of back and forth about trying this then that then it
> worked, O, not it didn't really work, etc.
>
> Please consider creating a JavaMail SSL/TLS Servlet example.
>

Re: [VOTE] Apache TomEE 7.0.0

[Romain Manni-Bucau]

for the one using tentacle to check notice/license files: i uploaded it
there http://home.apache.org/~rmannibucau/orgapachetomee-1097/ (skipped
binaries/exploded folders cause my network connection doesn't allow that
ATM)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-24 12:32 GMT+02:00 Romain Manni-Bucau :

> @Jon: no cause we didn't change any dependencies outside asf
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-05-24 11:57 GMT+02:00 Mark Struberg :
>
>> I did a run over dependencies and couldn't find anything.
>>
>>
>> So here is my
>>
>>
>> +1
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>> > On Monday, 23 May 2016, 23:48, Romain Manni-Bucau <
>> rmannibu...@gmail.com> wrote:
>> > > Le 23 mai 2016 23:42, "Jean-Louis Monteiro"
>> >  a
>> > écrit :
>> >>
>> >>  So what is the status regarding the LICENSE and NOTICE?
>> >
>> > Nothing patrticular.
>> >
>> >>  Don't want to spend time checking the release if there is still
>> pending
>> >>  tasks to do.
>> >>
>> >>  We have agreed that the documentation needs to be clear regarding the
>> >>  status of this release (not Java EE 6 certified nor Java EE 7
>> certified).
>> >>  Could we have that download page to be split into something like 2
>> parts:
>> >>  1.x and 7.x
>> >>  With the information on the policy at the top.
>> >>  Each section explicitly mentioning which Java EE version are we
>> >>  implementing, if it is certified and what is complete or not in the
>> TomEE
>> >>  7.x
>> >>  The current version with all the links at the top looks now a bit
>> messy
>> > and
>> >>  the policy on a separate page makes it difficult to find out in my
>> > opinion.
>> >>
>> >
>> > Was planning to just keep 1 version by minor for maintained releases +
>> link
>> > the version policy. All other versions would go in archives. That is my
>> > second task once vote passed.
>> >
>> > This is however out of vote scope, version policy page work has been
>> done
>> > and nobody complained in 5 days so guess it is fine to go then we can
>> > enhance it if needed but i dont see it anymore as a blocker - compared
>> to
>> > the lack of votes ;).
>> >
>> >>  That seemed to be the agreement of the last vote.
>> >>
>> >>  That said, I spent some time grabbing the sources and trying to
>> compile
>> >>  without success.
>> >>  XAPoolTest keeps failing locally when I run it with openejb-core
>> >>
>> >
>> > The code of this vote was green on buildbot when tagged so can likely be
>> > something else or envrt dpd. Ping me if you need help.
>> >
>> >>  Alone it works. I'll check that out tomorrow if I can get the test
>> > fixed
>> >>  and more reliable (if possible).
>> >>
>> >
>> > Thanks for taking time to have a look.
>> >
>> >
>> >>
>> >>  --
>> >>  Jean-Louis Monteiro
>> >>  http://twitter.com/jlouismonteiro
>> >>  http://www.tomitribe.com
>> >>
>> >>  On Fri, May 20, 2016 at 6:16 PM, John D. Ament
>> > 
>> >>  wrote:
>> >>
>> >>  > On Fri, May 20, 2016 at 12:40 PM David Blevins
>> > 
>> >>  > wrote:
>> >>  >
>> >>  > >
>> >>  > > > On May 19, 2016, at 11:27 PM, Romain Manni-Bucau <
>> >>  > rmannibu...@gmail.com>
>> >>  > > wrote:
>> >>  > > >
>> >>  > > > 2016-05-20 1:23 GMT+02:00 David Blevins
>> > :
>> >>  > > >
>> >>  > > >> Also, we’ve histor

Re: Disable default JAX-RS provider in apache-tomee-7.0.0-M3-plus

[Romain Manni-Bucau]

yes or just disabled line, should be enough IIRC


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-26 14:33 GMT+02:00 Dignesh :

> Hi Thanks for quick reply.
>
> Below is the content.Is this is correct ?
>
> server  = org.apache.openejb.server.cxf.rs.CxfRSService
> auth = NONE
> realm = PropertiesLogin
> disabled=true
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Disable-default-JAX-RS-provider-in-apache-tomee-7-0-0-M3-plus-tp4678602p4678604.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Disable default JAX-RS provider in apache-tomee-7.0.0-M3-plus

[Romain Manni-Bucau]

echo "disabled=true" > conf/conf.d/cxf-rs.properties

will do it


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-26 14:12 GMT+02:00 Dignesh :

> Hello,
>
> I am using Jersey as my JAX-RS provider.I want to disable the default one
> which is provided in TomEE.
> Is there any configuration though which this can be achieved.?
>
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Disable-default-JAX-RS-provider-in-apache-tomee-7-0-0-M3-plus-tp4678602.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: [VOTE] Apache TomEE 7.0.0

[Romain Manni-Bucau]

@Jon: no cause we didn't change any dependencies outside asf


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-24 11:57 GMT+02:00 Mark Struberg :

> I did a run over dependencies and couldn't find anything.
>
>
> So here is my
>
>
> +1
>
> LieGrue,
> strub
>
>
>
>
>
> > On Monday, 23 May 2016, 23:48, Romain Manni-Bucau 
> wrote:
> > > Le 23 mai 2016 23:42, "Jean-Louis Monteiro"
> >  a
> > écrit :
> >>
> >>  So what is the status regarding the LICENSE and NOTICE?
> >
> > Nothing patrticular.
> >
> >>  Don't want to spend time checking the release if there is still pending
> >>  tasks to do.
> >>
> >>  We have agreed that the documentation needs to be clear regarding the
> >>  status of this release (not Java EE 6 certified nor Java EE 7
> certified).
> >>  Could we have that download page to be split into something like 2
> parts:
> >>  1.x and 7.x
> >>  With the information on the policy at the top.
> >>  Each section explicitly mentioning which Java EE version are we
> >>  implementing, if it is certified and what is complete or not in the
> TomEE
> >>  7.x
> >>  The current version with all the links at the top looks now a bit messy
> > and
> >>  the policy on a separate page makes it difficult to find out in my
> > opinion.
> >>
> >
> > Was planning to just keep 1 version by minor for maintained releases +
> link
> > the version policy. All other versions would go in archives. That is my
> > second task once vote passed.
> >
> > This is however out of vote scope, version policy page work has been done
> > and nobody complained in 5 days so guess it is fine to go then we can
> > enhance it if needed but i dont see it anymore as a blocker - compared to
> > the lack of votes ;).
> >
> >>  That seemed to be the agreement of the last vote.
> >>
> >>  That said, I spent some time grabbing the sources and trying to compile
> >>  without success.
> >>  XAPoolTest keeps failing locally when I run it with openejb-core
> >>
> >
> > The code of this vote was green on buildbot when tagged so can likely be
> > something else or envrt dpd. Ping me if you need help.
> >
> >>  Alone it works. I'll check that out tomorrow if I can get the test
> > fixed
> >>  and more reliable (if possible).
> >>
> >
> > Thanks for taking time to have a look.
> >
> >
> >>
> >>  --
> >>  Jean-Louis Monteiro
> >>  http://twitter.com/jlouismonteiro
> >>  http://www.tomitribe.com
> >>
> >>  On Fri, May 20, 2016 at 6:16 PM, John D. Ament
> > 
> >>  wrote:
> >>
> >>  > On Fri, May 20, 2016 at 12:40 PM David Blevins
> > 
> >>  > wrote:
> >>  >
> >>  > >
> >>  > > > On May 19, 2016, at 11:27 PM, Romain Manni-Bucau <
> >>  > rmannibu...@gmail.com>
> >>  > > wrote:
> >>  > > >
> >>  > > > 2016-05-20 1:23 GMT+02:00 David Blevins
> > :
> >>  > > >
> >>  > > >> Also, we’ve historically done a preview run in advance
> > of an
> > official
> >>  > > vote
> >>  > > >> for major releases:
> >>  > > >>
> >>  > > >>  [PREVIEW] OpenEJB 4.7.0/TomEE 1.7.0 (staging-1034)
> >>  > > >>  http://openejb.markmail.org/thread/jjiheacmtd4tb6qw
> >>  > > >>
> >>  > > >>  [preview] OpenEJB 4.6.0/TomEE 1.6.0 (staging-092)
> >>  > > >>  http://markmail.org/message/u6ripoz3lsxvcron
> >>  > > >>
> >>  > > >>  1.0.0 preview binaries
> >>  > > >>  http://markmail.org/message/f6ix44zeqlcaet3w
> >>  > > >>
> >>  > > >>  [preview] OpenEJB 4.5.1/TomEE 1.5.1 (staging-132)
> >>  > > >>  http://markmail.org/message/l3rvltbc3az7xu65
> >>  > > >>
> >>  > > >> Binary comparison of this release to previous to help
> > with LICENSE
> > and
> >>  > > >> NOTICE file update

Re: [VOTE] Apache TomEE 7.0.0

[Romain Manni-Bucau]

Le 23 mai 2016 23:42, "Jean-Louis Monteiro"  a
écrit :
>
> So what is the status regarding the LICENSE and NOTICE?

Nothing patrticular.

> Don't want to spend time checking the release if there is still pending
> tasks to do.
>
> We have agreed that the documentation needs to be clear regarding the
> status of this release (not Java EE 6 certified nor Java EE 7 certified).
> Could we have that download page to be split into something like 2 parts:
> 1.x and 7.x
> With the information on the policy at the top.
> Each section explicitly mentioning which Java EE version are we
> implementing, if it is certified and what is complete or not in the TomEE
> 7.x
> The current version with all the links at the top looks now a bit messy
and
> the policy on a separate page makes it difficult to find out in my
opinion.
>

Was planning to just keep 1 version by minor for maintained releases + link
the version policy. All other versions would go in archives. That is my
second task once vote passed.

This is however out of vote scope, version policy page work has been done
and nobody complained in 5 days so guess it is fine to go then we can
enhance it if needed but i dont see it anymore as a blocker - compared to
the lack of votes ;).

> That seemed to be the agreement of the last vote.
>
> That said, I spent some time grabbing the sources and trying to compile
> without success.
> XAPoolTest keeps failing locally when I run it with openejb-core
>

The code of this vote was green on buildbot when tagged so can likely be
something else or envrt dpd. Ping me if you need help.

> Alone it works. I'll check that out tomorrow if I can get the test fixed
> and more reliable (if possible).
>

Thanks for taking time to have a look.

>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, May 20, 2016 at 6:16 PM, John D. Ament 
> wrote:
>
> > On Fri, May 20, 2016 at 12:40 PM David Blevins 
> > wrote:
> >
> > >
> > > > On May 19, 2016, at 11:27 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > > >
> > > > 2016-05-20 1:23 GMT+02:00 David Blevins :
> > > >
> > > >> Also, we’ve historically done a preview run in advance of an
official
> > > vote
> > > >> for major releases:
> > > >>
> > > >>  [PREVIEW] OpenEJB 4.7.0/TomEE 1.7.0 (staging-1034)
> > > >>  http://openejb.markmail.org/thread/jjiheacmtd4tb6qw
> > > >>
> > > >>  [preview] OpenEJB 4.6.0/TomEE 1.6.0 (staging-092)
> > > >>  http://markmail.org/message/u6ripoz3lsxvcron
> > > >>
> > > >>  1.0.0 preview binaries
> > > >>  http://markmail.org/message/f6ix44zeqlcaet3w
> > > >>
> > > >>  [preview] OpenEJB 4.5.1/TomEE 1.5.1 (staging-132)
> > > >>  http://markmail.org/message/l3rvltbc3az7xu65
> > > >>
> > > >> Binary comparison of this release to previous to help with LICENSE
and
> > > >> NOTICE file updates:
> > > >>
> > > >>  1.0.0 - 1.5.0  http://openejb.markmail.org/thread/ppvkyeznaryjluve
> > > >>
> > > >>  1.5.0 - 1.5.1  http://markmail.org/message/pmwkycgdrz2php6n
> > > >>
> > > >>  1.5.1 - 1.6.0  http://openejb.markmail.org/thread/xwy56krafcxm3kgs
> > > >>
> > > >> And RAT scan:
> > > >>
> > > >> - http://markmail.org/message/fmj5kveiw6kwmq6d <
> > > >> http://markmail.org/message/fmj5kveiw6kwmq6d>
> > > >>
> > > >> Also preemptive note, despite that “72 hours” has been in all the
vote
> > > >> threads, we’ve always left votes open longer to ensure everyone has
> > > time to
> > > >> give feedback.  So I’m hoping the response is not “you have 72
hours
> > to
> > > do
> > > >> this” as they’ve historically been done by the release manager.
> > > >>
> > > >> Can we consider this a preview release and execute the diffs, rat
> > > reports
> > > >> and ensure our LICENSE and NOTICE files are up to date?  Or at the
> > very
> > > >> least pause this vote till that stuff is done.
> > > >>
> > > >>
> > > > 6 months ago I would have said yes but since v7 is > 1 year old
think
> > we
> > > > got all the time to do all the fancy stuff we want and if not done
in 1
> > > > year will likely not be done now so *personally* I don&#

Re: ApplicationComposer and @Startup (and logging)

[Romain Manni-Bucau]

without more info you'll not get much help I fear. Providing a github
project showing the issue will make it trivial to solve IMO.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-23 15:01 GMT+02:00 Gregory Orciuch :

> Hi,
> any further idea how to enable log4j ?
>
> 2016-05-20 11:57 GMT+02:00 Gregory Orciuch :
>
> > Yeap directly, actually I only pull the openejb-core for the
> > ApplicationComposer
> >
> > 2016-05-20 11:56 GMT+02:00 Romain Manni-Bucau :
> >
> >> 2016-05-20 11:54 GMT+02:00 Gregory Orciuch :
> >>
> >> > 2. Great. works. .setInitOnStartup(true) does the trick. For group
> >> > reference. Something like this: ejbJar.addEnterpriseBean(new
> >> > SingletonBean(CacheInitBean.class)).setInitOnStartup(true);
> >> >
> >> > 1. It's kinda blind on log4j stuff. Added the log4j maven test
> >> dependency,
> >> > then added the log4j.properties to src/test/resources . Log level is
> >> > fine... what else ?
> >> >
> >> >
> >> do you use log4j API directly? TomEE uses JUL by default and needs to be
> >> configured to use log4j but not your code.
> >>
> >>
> >> > 2016-05-20 11:47 GMT+02:00 Romain Manni-Bucau  >:
> >> >
> >> > > Hello
> >> > >
> >> > > 2016-05-20 11:34 GMT+02:00 Gregory Orciuch :
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > I think I'm facing an configuration issue here.
> >> > > > So having the @Singleton and @Startup Bean which is added in
> >> > application
> >> > > > composer as below:
> >> > > > @Module
> >> > > > public EjbJar beans() {
> >> > > > EjbJar ejbJar = new EjbJar("ejb-beans");
> >> > > >
> >> > > > ejbJar.addEnterpriseBean(new
> >> > SingletonBean(CacheInitBean.class));
> >> > > > 
> >> > > >
> >> > > >
> >> > > > This guy needs to perform a @PostConstruct actions, and I do not
> see
> >> > the
> >> > > > logs out and seems like the PostConstruct is not fired at all
> >> > > >
> >> > > > So two questions
> >> > > > 1. How to ensure the log4j works for ApplicationComposer's created
> >> > beans
> >> > > ?
> >> > > >
> >> > >
> >> > > What's your issue? adding the jars and config should be enough
> >> > >
> >> > >
> >> > > > 2. Why @Startup seems to be skipped ?
> >> > > >
> >> > > >
> >> > > You set up a SingletonBean so you need to set setInitOnStartup
> >> > >
> >> > >
> >> > > > BR,
> >> > > > Gregory
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>

Re: ApplicationComposer and @Startup (and logging)

[Romain Manni-Bucau]

2016-05-20 11:54 GMT+02:00 Gregory Orciuch :

> 2. Great. works. .setInitOnStartup(true) does the trick. For group
> reference. Something like this: ejbJar.addEnterpriseBean(new
> SingletonBean(CacheInitBean.class)).setInitOnStartup(true);
>
> 1. It's kinda blind on log4j stuff. Added the log4j maven test dependency,
> then added the log4j.properties to src/test/resources . Log level is
> fine... what else ?
>
>
do you use log4j API directly? TomEE uses JUL by default and needs to be
configured to use log4j but not your code.


> 2016-05-20 11:47 GMT+02:00 Romain Manni-Bucau :
>
> > Hello
> >
> > 2016-05-20 11:34 GMT+02:00 Gregory Orciuch :
> >
> > > Hi,
> > >
> > > I think I'm facing an configuration issue here.
> > > So having the @Singleton and @Startup Bean which is added in
> application
> > > composer as below:
> > > @Module
> > > public EjbJar beans() {
> > > EjbJar ejbJar = new EjbJar("ejb-beans");
> > >
> > > ejbJar.addEnterpriseBean(new
> SingletonBean(CacheInitBean.class));
> > > 
> > >
> > >
> > > This guy needs to perform a @PostConstruct actions, and I do not see
> the
> > > logs out and seems like the PostConstruct is not fired at all
> > >
> > > So two questions
> > > 1. How to ensure the log4j works for ApplicationComposer's created
> beans
> > ?
> > >
> >
> > What's your issue? adding the jars and config should be enough
> >
> >
> > > 2. Why @Startup seems to be skipped ?
> > >
> > >
> > You set up a SingletonBean so you need to set setInitOnStartup
> >
> >
> > > BR,
> > > Gregory
> > >
> >
>

Re: ApplicationComposer and @Startup (and logging)

[Romain Manni-Bucau]

Hello

2016-05-20 11:34 GMT+02:00 Gregory Orciuch :

> Hi,
>
> I think I'm facing an configuration issue here.
> So having the @Singleton and @Startup Bean which is added in application
> composer as below:
> @Module
> public EjbJar beans() {
> EjbJar ejbJar = new EjbJar("ejb-beans");
>
> ejbJar.addEnterpriseBean(new SingletonBean(CacheInitBean.class));
> 
>
>
> This guy needs to perform a @PostConstruct actions, and I do not see the
> logs out and seems like the PostConstruct is not fired at all
>
> So two questions
> 1. How to ensure the log4j works for ApplicationComposer's created beans ?
>

What's your issue? adding the jars and config should be enough


> 2. Why @Startup seems to be skipped ?
>
>
You set up a SingletonBean so you need to set setInitOnStartup


> BR,
> Gregory
>

Re: [VOTE] Apache TomEE 7.0.0

[Romain Manni-Bucau]

2016-05-20 1:23 GMT+02:00 David Blevins :

> Also, we’ve historically done a preview run in advance of an official vote
> for major releases:
>
>   [PREVIEW] OpenEJB 4.7.0/TomEE 1.7.0 (staging-1034)
>   http://openejb.markmail.org/thread/jjiheacmtd4tb6qw
>
>   [preview] OpenEJB 4.6.0/TomEE 1.6.0 (staging-092)
>   http://markmail.org/message/u6ripoz3lsxvcron
>
>   1.0.0 preview binaries
>   http://markmail.org/message/f6ix44zeqlcaet3w
>
>   [preview] OpenEJB 4.5.1/TomEE 1.5.1 (staging-132)
>   http://markmail.org/message/l3rvltbc3az7xu65
>
> Binary comparison of this release to previous to help with LICENSE and
> NOTICE file updates:
>
>   1.0.0 - 1.5.0  http://openejb.markmail.org/thread/ppvkyeznaryjluve
>
>   1.5.0 - 1.5.1  http://markmail.org/message/pmwkycgdrz2php6n
>
>   1.5.1 - 1.6.0  http://openejb.markmail.org/thread/xwy56krafcxm3kgs
>
> And RAT scan:
>
>  - http://markmail.org/message/fmj5kveiw6kwmq6d <
> http://markmail.org/message/fmj5kveiw6kwmq6d>
>
> Also preemptive note, despite that “72 hours” has been in all the vote
> threads, we’ve always left votes open longer to ensure everyone has time to
> give feedback.  So I’m hoping the response is not “you have 72 hours to do
> this” as they’ve historically been done by the release manager.
>
> Can we consider this a preview release and execute the diffs, rat reports
> and ensure our LICENSE and NOTICE files are up to date?  Or at the very
> least pause this vote till that stuff is done.
>
>
6 months ago I would have said yes but since v7 is > 1 year old think we
got all the time to do all the fancy stuff we want and if not done in 1
year will likely not be done now so *personally* I don't accept any excuse
anymore to delay a release.


>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On May 19, 2016, at 12:45 PM, David Blevins 
> wrote:
> >
> > Can you put up a proposed page for the download and I can give feedback
> on how it should be updated.  Let’s start another thread.
> >
> > I’m obviously very time constrained, but happy to give you time and work
> openly on it.
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins <http://twitter.com/dblevins>
> > http://www.tomitribe.com
> >
> >> On May 19, 2016, at 12:37 PM, Romain Manni-Bucau  <mailto:rmannibu...@gmail.com>> wrote:
> >>
> >> @David: http://tomee.apache.org/tomee-version-policies.html <
> http://tomee.apache.org/tomee-version-policies.html>, just added a
> >> link on the download page http://tomee.apache.org/downloads.html.Think
> <http://tomee.apache.org/downloads.html.Think> the
> >> information is there but don't hesitate to tune/customize/update the
> >> website until you are fully happy with it.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau <
> https://twitter.com/rmannibucau>> |  Blog
> >> <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>>
> | Github <https://github.com/rmannibucau <https://github.com/rmannibucau>>
> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau <
> https://www.linkedin.com/in/rmannibucau>> | Tomitriber
> >> <http://www.tomitribe.com <http://www.tomitribe.com/>> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com <
> https://javaeefactory-rmannibucau.rhcloud.com/>>
> >>
> >> 2016-05-19 21:03 GMT+02:00 David Blevins  <mailto:david.blev...@gmail.com>>:
> >>
> >>> Also the download page would need to be updated.  It currently says
> “Java
> >>> EE 6 compliant” and we would need to remove that and replace it with
> “NOT
> >>> Java EE 7 compliant”.  That text should be a link to an explanation of
> why
> >>> and an explanation of the version number.
> >>>
> >>>
> >>> --
> >>> David Blevins
> >>> http://twitter.com/dblevins <http://twitter.com/dblevins>
> >>> http://www.tomitribe.com
> >>>
> >>>> On May 19, 2016, at 11:59 AM, David Blevins 
> >>> wrote:
> >>>>
> >>>> Where is the documentation page again?
> >>>>
> >>>>
> >>>> --
> >>>> David Blevins
> >>>> http://twitter.com/dblevins <http://twitter.com/dblevins>
> >>>> http://www.tomitribe.com
> >>>>
> >>>>> On May 18, 2016, at 12:39 AM, Romain Mann

Re: reworking the CLI?

[Romain Manni-Bucau]

not yet, sent the thread to know what was the thoughts before doing
anything.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-19 22:09 GMT+02:00 Daniel Cunha :

> Ok.
>
> Do we have some issues for it?
>
> On Wed, May 18, 2016 at 11:10 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> wrote:
>
> > Current api/"spi like" is not friendly and cli dep is often an issue for
> > not standalone case.
> > Le 18 mai 2016 23:12, "Daniel Cunha"  a écrit :
> >
> > > Hi Romain,
> > >
> > > yep, I like the way how cli was implemented in BatchEE. Sounds really
> > good
> > > and I don't have opposition to follow the same way.
> > > When you say: Technical issues. What do see like a problem?
> > >
> > >
> > > On Wed, May 18, 2016 at 2:49 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > 2016-05-18 19:44 GMT+02:00 Daniel Cunha :
> > > >
> > > > > We (Me and Hildeberto) proposed some ideas (in Clojure), but out of
> > the
> > > > box
> > > > > some time ago. But wasn't well accept, I guess.
> > > > >
> > > > >
> > > > Yes clojure is an issue for 2 reasons as main interface:
> > > > - its syntax is not user friendly (don't get me wrong, just means
> > peolpe
> > > > expects a sh like syntax for a cli)
> > > > - its dependencies we should avoid IMO
> > > >
> > > >
> > > > > +1 for your idea.
> > > > > I really think that we need improve CLI. I see some tips about it
> on
> > > > > twitter (https://twitter.com/rdebusscher/status/718081027604873216
> )
> > :)
> > > > >
> > > > >
> > > > Yep, we also can check what we did in BatchEE (
> > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-batchee/tree/master/tools/cli/src/main/java/org/apache/batchee/cli
> > > > ).
> > > > It is an annotation based impl on top of [cli] but the interesting
> part
> > > is
> > > > not much the API but the fact it is user extensible and it also
> allows
> > to
> > > > run small tasks like batches easily (start, deploy, run, shutdown).
> > > >
> > > > The potential is huge but first we need to get rid of the technical
> > > issues
> > > > I think.
> > > >
> > > >
> > > > > On Wed, May 18, 2016 at 10:04 AM, Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi guys,
> > > > > >
> > > > > > Spoke with Andy and Jean-Louis and seems we could make our CLI a
> > bit
> > > > > > better.
> > > > > >
> > > > > > So let's write down some proposal and then see 1. if we go this
> > path,
> > > > 2.
> > > > > > how
> > > > > >
> > > > > > ## Proposal
> > > > > >
> > > > > > Make our CLI richer in term of feature and commands and more user
> > > > > friendly.
> > > > > >
> > > > > > Bonus: getting rid of commons-cli would allow us to have a better
> > > > > > dependency management than today for all shade flavors we have.
> > > > > >
> > > > > > ## Technically
> > > > > >
> > > > > > 1. We can replace [cli] by our light backbone or a shade
> > (minimized)
> > > -
> > > > > and
> > > > > > then optimize/clean our shades (tomee embedded *)
> > > > > > 2. We move commands glue code from openejb-core to openejb-cli
> (or
> > > > > whatever
> > > > > > other modules) - to ensure it is reusable and easy to test
> > > > > > 3. We change the registration process to use a standard
> > > ServiceLoader?
> > > > > > (Easier for users to extend it/more natural)
> > > > > > 4. We use annotations instead of properties (same as previous)
> >

Re: [VOTE] Apache TomEE 7.0.0

[Romain Manni-Bucau]

@David: http://tomee.apache.org/tomee-version-policies.html, just added a
link on the download page http://tomee.apache.org/downloads.html.Think the
information is there but don't hesitate to tune/customize/update the
website until you are fully happy with it.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-19 21:03 GMT+02:00 David Blevins :

> Also the download page would need to be updated.  It currently says “Java
> EE 6 compliant” and we would need to remove that and replace it with “NOT
> Java EE 7 compliant”.  That text should be a link to an explanation of why
> and an explanation of the version number.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On May 19, 2016, at 11:59 AM, David Blevins 
> wrote:
> >
> > Where is the documentation page again?
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins <http://twitter.com/dblevins>
> > http://www.tomitribe.com
> >
> >> On May 18, 2016, at 12:39 AM, Romain Manni-Bucau  <mailto:rmannibu...@gmail.com>> wrote:
> >>
> >> Hi
> >>
> >> As mentionned and after the vote about the version here is the 7.0.0
> vote.
> >>
> >> Here are the release notes:
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12335051
> <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12335051
> >
> >>
> >> Keys file is still the same: https://www.apache.org/dist/tomee/KEYS
> >>
> >> As discussed pushed the tag on github:
> >> https://github.com/rmannibucau/tomee/tree/tomee-7.0.0
> >>
> >> New staging repository is
> >> https://repository.apache.org/content/repositories/orgapachetomee-1097
> >>
> >> Dev dist is https://dist.apache.org/repos/dist/dev/tomee/7.0.0
> >>
> >> Vote will be open for 72h or until we get 3 +1 bindings. Binding or not
> >> everyone is very welcomed to test and vote.
> >>
> >>
> >> Please vote:
> >> [ ] +1 yeah it rocks!
> >> [ ] +0 dont' know just wanted to say hello but no idea what we are
> talking
> >> about
> >> [ ] -1 no cause ${blocker <- X}
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> <http://www.tomitribe.com> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com>
> >
>
>

Re: org.apache.openejb.config.ReportValidationResults.logResults FAIL ... Missing class

[Romain Manni-Bucau]

19-May-2016 22:42:57.235 SEVERE [main]
org.apache.openejb.config.ReportValidationResults.logResults FAIL ...
StockBean:  Missing class 
dignesh.tomee.learning.StockServiceLocal
19-May-2016 22:42:57.235 SEVERE [main]
org.apache.openejb.config.ReportValidationResults.logResults FAIL ...
StockBean:  Missing class 
dignesh.tomee.learning.StockServiceRemote
19-May-2016 22:42:57.235 SEVERE [main]
org.apache.openejb.config.ReportValidationResults.logResults FAIL ...
LoginBean:  Missing class 
dignesh.tomee.learning.LoginServiceLocal
19-May-2016 22:42:57.235 SEVERE [main]
org.apache.openejb.config.ReportValidationResults.logResults Invalid
EjbModule(name=artesia-ejb,
path=C:\Users\dgoyal\Downloads\apache-tomee-7.0.0-M3-plus\apache-tomee-plus-7.0.0-M3\apps\artesia\artesia-ejb.jar)
19-May-2016 22:42:57.236 INFO [main]
org.apache.openejb.config.ReportValidationResults.deploy Set the
'openejb.validation.output.level' system property to VERBOSE for
increased validation details.


so you can put in conf/system.properties
"openejb.validation.output.level=VERBOSE" to get more details and
ensure these classes are visible from ear lib classloader.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-19 18:41 GMT+02:00 Dignesh :

> Hi,
>
> I am new to TomEE. I am facing deployment issue when starting the server.
> Server is not able find the business local and remote interfaces. Attached
> relevant ear and log files.Can anyone please let me know where I am going
> wrong.
> Thanks
> artesia.ear
> <http://tomee-openejb.979440.n4.nabble.com/file/n4678538/artesia.ear>
> tomee.xml
> <http://tomee-openejb.979440.n4.nabble.com/file/n4678538/tomee.xml>
> catalina.log
> <http://tomee-openejb.979440.n4.nabble.com/file/n4678538/catalina.log>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/org-apache-openejb-config-ReportValidationResults-logResults-FAIL-Missing-class-business-local-tp4678538.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Unable to find a public ejb server via the multicast URI during remote ejb look up

[Romain Manni-Bucau]

You still have the same error so likely a typo. Can be due to the mailbox
to properties copy. Please ensure system.properties content is right.
Le 19 mai 2016 02:12, "Dignesh"  a écrit :

> I fixed system.properties by adding value infornt of key not on the other
> line.Still I am seeing the same issue.
> Does i am missing some thing in configuration.?Anyelse thing else should be
> added in conf folder? FYI.. I haent made any changes in conf folder ,I only
> modified the system.properties file and added multicast.properties file.
> catalina.log
> 
> system.properties
>  >
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Unable-to-find-a-public-ejb-server-via-the-multicast-URI-during-remote-ejb-look-up-tp4678491p4678526.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: reworking the CLI?

[Romain Manni-Bucau]

Current api/"spi like" is not friendly and cli dep is often an issue for
not standalone case.
Le 18 mai 2016 23:12, "Daniel Cunha"  a écrit :

> Hi Romain,
>
> yep, I like the way how cli was implemented in BatchEE. Sounds really good
> and I don't have opposition to follow the same way.
> When you say: Technical issues. What do see like a problem?
>
>
> On Wed, May 18, 2016 at 2:49 PM, Romain Manni-Bucau  >
> wrote:
>
> > 2016-05-18 19:44 GMT+02:00 Daniel Cunha :
> >
> > > We (Me and Hildeberto) proposed some ideas (in Clojure), but out of the
> > box
> > > some time ago. But wasn't well accept, I guess.
> > >
> > >
> > Yes clojure is an issue for 2 reasons as main interface:
> > - its syntax is not user friendly (don't get me wrong, just means peolpe
> > expects a sh like syntax for a cli)
> > - its dependencies we should avoid IMO
> >
> >
> > > +1 for your idea.
> > > I really think that we need improve CLI. I see some tips about it on
> > > twitter (https://twitter.com/rdebusscher/status/718081027604873216) :)
> > >
> > >
> > Yep, we also can check what we did in BatchEE (
> >
> >
> https://github.com/apache/incubator-batchee/tree/master/tools/cli/src/main/java/org/apache/batchee/cli
> > ).
> > It is an annotation based impl on top of [cli] but the interesting part
> is
> > not much the API but the fact it is user extensible and it also allows to
> > run small tasks like batches easily (start, deploy, run, shutdown).
> >
> > The potential is huge but first we need to get rid of the technical
> issues
> > I think.
> >
> >
> > > On Wed, May 18, 2016 at 10:04 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Hi guys,
> > > >
> > > > Spoke with Andy and Jean-Louis and seems we could make our CLI a bit
> > > > better.
> > > >
> > > > So let's write down some proposal and then see 1. if we go this path,
> > 2.
> > > > how
> > > >
> > > > ## Proposal
> > > >
> > > > Make our CLI richer in term of feature and commands and more user
> > > friendly.
> > > >
> > > > Bonus: getting rid of commons-cli would allow us to have a better
> > > > dependency management than today for all shade flavors we have.
> > > >
> > > > ## Technically
> > > >
> > > > 1. We can replace [cli] by our light backbone or a shade (minimized)
> -
> > > and
> > > > then optimize/clean our shades (tomee embedded *)
> > > > 2. We move commands glue code from openejb-core to openejb-cli (or
> > > whatever
> > > > other modules) - to ensure it is reusable and easy to test
> > > > 3. We change the registration process to use a standard
> ServiceLoader?
> > > > (Easier for users to extend it/more natural)
> > > > 4. We use annotations instead of properties (same as previous)
> > > > 5. add alias support (typically Andy brings "cipher" vs "cypher"
> > handling
> > > > which is a common mistake)
> > > > 6. add matching feature: "./tomee.sh cip"  is not ambiguous so we can
> > > match
> > > > cipher command (algo is: if not ambiguous execute otherwise fail)
> > > >
> > > > There are probably more doors open but that's the start I see/have in
> > > mind.
> > > >
> > > > ## Commands
> > > >
> > > > Currently available:
> > > >
> > > > - cipher: encode/decode a string to use with a PasswordCipher
> > > > - effectivetomee: list the loaded tomee.xml (actual one, not the file
> > > > itself)
> > > > - properties: dump tomee server configuration (same as effective
> tomee,
> > > > that's the internal model)
> > > > - setters: list field usable for a class (to use with )
> > > > - start: start the server (delegates to catalina.sh)
> > > > - stop: stop the server (delegates to catalina.sh)
> > > > - deploy: deploy an app
> > > > - undeploy: undeploy the app
> > > >
> > > > Note: deploy/undeploy commands are to rework a bit to be useful I
> guess
> > > > (the current "id" is the path and is not natural IMO)
> > > >
> > > > We can add:
> > > >
> > > > - add-resource (add in

Re: reworking the CLI?

[Romain Manni-Bucau]

2016-05-18 19:44 GMT+02:00 Daniel Cunha :

> We (Me and Hildeberto) proposed some ideas (in Clojure), but out of the box
> some time ago. But wasn't well accept, I guess.
>
>
Yes clojure is an issue for 2 reasons as main interface:
- its syntax is not user friendly (don't get me wrong, just means peolpe
expects a sh like syntax for a cli)
- its dependencies we should avoid IMO


> +1 for your idea.
> I really think that we need improve CLI. I see some tips about it on
> twitter (https://twitter.com/rdebusscher/status/718081027604873216) :)
>
>
Yep, we also can check what we did in BatchEE (
https://github.com/apache/incubator-batchee/tree/master/tools/cli/src/main/java/org/apache/batchee/cli).
It is an annotation based impl on top of [cli] but the interesting part is
not much the API but the fact it is user extensible and it also allows to
run small tasks like batches easily (start, deploy, run, shutdown).

The potential is huge but first we need to get rid of the technical issues
I think.


> On Wed, May 18, 2016 at 10:04 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> wrote:
>
> > Hi guys,
> >
> > Spoke with Andy and Jean-Louis and seems we could make our CLI a bit
> > better.
> >
> > So let's write down some proposal and then see 1. if we go this path, 2.
> > how
> >
> > ## Proposal
> >
> > Make our CLI richer in term of feature and commands and more user
> friendly.
> >
> > Bonus: getting rid of commons-cli would allow us to have a better
> > dependency management than today for all shade flavors we have.
> >
> > ## Technically
> >
> > 1. We can replace [cli] by our light backbone or a shade (minimized) -
> and
> > then optimize/clean our shades (tomee embedded *)
> > 2. We move commands glue code from openejb-core to openejb-cli (or
> whatever
> > other modules) - to ensure it is reusable and easy to test
> > 3. We change the registration process to use a standard ServiceLoader?
> > (Easier for users to extend it/more natural)
> > 4. We use annotations instead of properties (same as previous)
> > 5. add alias support (typically Andy brings "cipher" vs "cypher" handling
> > which is a common mistake)
> > 6. add matching feature: "./tomee.sh cip"  is not ambiguous so we can
> match
> > cipher command (algo is: if not ambiguous execute otherwise fail)
> >
> > There are probably more doors open but that's the start I see/have in
> mind.
> >
> > ## Commands
> >
> > Currently available:
> >
> > - cipher: encode/decode a string to use with a PasswordCipher
> > - effectivetomee: list the loaded tomee.xml (actual one, not the file
> > itself)
> > - properties: dump tomee server configuration (same as effective tomee,
> > that's the internal model)
> > - setters: list field usable for a class (to use with )
> > - start: start the server (delegates to catalina.sh)
> > - stop: stop the server (delegates to catalina.sh)
> > - deploy: deploy an app
> > - undeploy: undeploy the app
> >
> > Note: deploy/undeploy commands are to rework a bit to be useful I guess
> > (the current "id" is the path and is not natural IMO)
> >
> > We can add:
> >
> > - add-resource (add in tomee.xml a resource and deploy it if running)
> > - modify-resource (change a property)
> > - add/remove-property
> > - jmx-attribute
> > - jmx-operation
> > - ...
> >
> > ## Next steps
> >
> > 1. Please say you think it is a good track or just an idea we can kill
> > (happens ;)).
> > 2. If we are rather positive about that I think it is a good opportunity
> to
> > get newcomers to TomEE. Part of the code is aside tomee (cli one) and the
> > commands themself are done or almost there for most of the ones I listed.
> > It just needs some integration and clean up so that's a great way to get
> > familiar with TomEE internals and model. That said I'm super happy to
> help
> > anyone or code some part if needed.
> >
> > Finally this track would allow us to:
> >
> > - own the CLI code and dependencies making us controlling our deps on the
> > whole chain (for shades and light deployments)
> > - make our CLI more user friendly
> > - open the door to custom commands more easily
> > - rework the commands to add some missing ones
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
>
>
>
> --
> Daniel Cunha
> https://twitter.com/dvlc_
>

Re: Unable to find a public ejb server via the multicast URI during remote ejb look up

[Romain Manni-Bucau]

you don't want to fix you system.properties to put the value in front of
the key and not on another line?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 18:28 GMT+02:00 Dignesh :

> catalina.log
> <http://tomee-openejb.979440.n4.nabble.com/file/n4678517/catalina.log>
>
> I have used M3 .still I am seeing the same issue.Please advice further.
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Unable-to-find-a-public-ejb-server-via-the-multicast-URI-during-remote-ejb-look-up-tp4678491p4678517.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Unable to find a public ejb server via the multicast URI during remote ejb look up

[Romain Manni-Bucau]

2016-05-18 18:05 GMT+02:00 Dignesh :

> I am not clear ...
> 1. I have added below line in system.properties file. And logs shows it is
> using the serviceManager "org.apache.openejb.server.SimpleServiceManager"
> which we have configured right ? is this not correct ?
>
>
Log says the opposites:

18-May-2016 21:49:29.612 SEVERE [main]
org.apache.tomee.catalina.TomcatLoader.initialize can't find the
service manager , the TomEE one will be used

Remove the end of line between = and class name

openejb.service.manager.class =
> org.apache.openejb.server.SimpleServiceManager
>
> 2.does it mean there is something wrong in M1 version Tomee I am using ?
>
>
I don't have time to check ATM, we didn't modify this area so shouldn't but
would need some testing and comparison.


>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Unable-to-find-a-public-ejb-server-via-the-multicast-URI-during-remote-ejb-look-up-tp4678491p4678514.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Unable to find a public ejb server via the multicast URI during remote ejb look up

[Romain Manni-Bucau]

18-May-2016 21:52:52.392 INFO [main]
org.apache.openejb.server.SimpleServiceManager.start   ** Bound
Services **
18-May-2016 21:52:52.392 INFO [main]
org.apache.openejb.server.SimpleServiceManager.printRow   NAME
IP  PORT
18-May-2016 21:52:52.392 INFO [main]
org.apache.openejb.server.SimpleServiceManager.printRow   multicast
239.255.2.3 6142
18-May-2016 21:52:52.392 INFO [main]
org.apache.openejb.server.SimpleServiceManager.start ---


means it is not using the service manager I mentionned. Note: the
shared config works on M3



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 17:50 GMT+02:00 Dignesh :

> Hello,
> I have added the configuration suggested in conf/system.properties file and
> restarted the tomee, Still I am seeing the same error. Attached the
> Catalina
> log and system.properties file.Please advise further
>
> catalina.log
> <http://tomee-openejb.979440.n4.nabble.com/file/n4678512/catalina.log>
> system.properties
> <http://tomee-openejb.979440.n4.nabble.com/file/n4678512/system.properties
> >
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Unable-to-find-a-public-ejb-server-via-the-multicast-URI-during-remote-ejb-look-up-tp4678491p4678512.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Unable to find a public ejb server via the multicast URI during remote ejb look up

[Romain Manni-Bucau]

Suspect multicast doesn't work by default with http transport for ejbd but
should work if you use direct ejbd. You can test it using in
conf/system.properties:

openejb.service.manager.class =
org.apache.openejb.server.SimpleServiceManager



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 15:25 GMT+02:00 Dignesh :

> artesia.ear
> <http://tomee-openejb.979440.n4.nabble.com/file/n4678505/artesia.ear>
>
> I have attached the ear file that is present in the apps folder. I am using
> apache-tomee-7.0.0-M1-plus.
> Below is my simple client program that does the ejb look up.
>
> import java.util.Properties;
>
> import javax.enterprise.context.spi.Context;
> import javax.naming.InitialContext;
>
> import dignesh.learning.tomee.StockServiceRemote;
>
>
> public class RemoteEjbClientExample {
>
> public static void main(String args[]) throws Exception
> {
>
> Properties p = new Properties();
> p.put(javax.naming.Context.INITIAL_CONTEXT_FACTORY,
> "org.apache.openejb.client.RemoteInitialContextFactory");
> p.put(javax.naming.Context.PROVIDER_URL,
> "multicast://239.255.2.3:6142?group=default");
>
>
> InitialContext ctx = new InitialContext(p);
> StockServiceRemote stockServiceRemote =
> (StockServiceRemote)
>
> ctx.lookup("global/artesia/artesia-ejb/StockBean!dignesh.learning.tomee.StockServiceRemote");
> stockServiceRemote.viewStockDetails();
> stockServiceRemote.modifyStockDetails();
> stockServiceRemote.viewStockDetails();
> }
>
>
> }
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Unable-to-find-a-public-ejb-server-via-the-multicast-URI-during-remote-ejb-look-up-tp4678491p4678505.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: [VOTE] Apache TomEE 7.0.0

[Romain Manni-Bucau]

Just to clarify after Andy's mail: tempted to say the opposite: this is not
an important release since we can release whenever we want and versioning
is just a number and as a side note out of topic there. Doc has been
updated some time ago but feel free to adjust it if you or anyone else feel
the need. About the rubber stamped same thing, this is if you think but we
stated there was no stamped contract between EE and TomEE versions on
multiple threads so with the additional doc I think it is clear enough now.
That's just binaries we can use from end to end - and that's the only goal
of this release as stated in the version vote.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 15:32 GMT+02:00 jllado :

> +1 ^^
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/VOTE-Apache-TomEE-7-0-0-tp4678479p4678508.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Raise JMS messages to all the nodes in cluster

[Romain Manni-Bucau]

AMQ website is very good for such questions:
http://activemq.apache.org/how-does-a-queue-compare-to-a-topic.html


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 15:26 GMT+02:00 Dignesh :

> How about the Queues ? The messages wont be sent to all the nodes ?
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Raise-JMS-messages-to-all-the-nodes-in-cluster-tp4678495p4678506.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Unable to find a public ejb server via the multicast URI during remote ejb look up

[Romain Manni-Bucau]

looks good, if you have trouble with that setup maybe take time to
reproduce it in a small project using tomee-maven-plugin to let us
reproduce it with "mvn package -DskipTests tomee:run" and "mvn test" for
the client. Will avoid a lot of ping pong to guess what is missing.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 15:00 GMT+02:00 Dignesh :

>  I have added the jar in the lib folder already.Below is snip of log during
> the service start up.
>
> 18-May-2016 18:58:53.179 INFO [main]
> org.apache.openejb.server.ServiceManager.initServer Creating
> ServerService(id=cxf)
> 18-May-2016 18:58:53.343 INFO [main]
> org.apache.openejb.server.ServiceManager.initServer Creating
> ServerService(id=multicast)
> 18-May-2016 18:58:53.348 INFO [main]
> org.apache.openejb.server.ServiceManager.initServer Creating
> ServerService(id=cxf-rs)
> 18-May-2016 18:58:53.441 INFO [main]
> org.apache.openejb.server.SimpleServiceManager.start   ** Bound Services **
> 18-May-2016 18:58:53.441 INFO [main]
> org.apache.openejb.server.SimpleServiceManager.printRow   NAME
> IP  PORT
> 18-May-2016 18:58:53.441 INFO [main]
> org.apache.openejb.server.SimpleServiceManager.printRow   multicast
> 239.255.2.3 6142
> 18-May-2016 18:58:53.441 INFO [main]
> org.apache.openejb.server.SimpleServiceManager.start ---
> 18-May-2016 18:58:53.441 INFO [main]
> org.apache.openejb.server.SimpleServiceManager.start Ready!
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Unable-to-find-a-public-ejb-server-via-the-multicast-URI-during-remote-ejb-look-up-tp4678491p4678501.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Raise JMS messages to all the nodes in cluster

[Romain Manni-Bucau]

ActiveMQ handles it so you will find most of the doc on their website:
http://activemq.apache.org/how-do-distributed-queues-work.html for instance


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 15:03 GMT+02:00 Dignesh :

> Possibly there could be a issue with the way I have set up the cluster
> environment.
>
> Is there is documentation that shows how to set up a cluster on tomee
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Raise-JMS-messages-to-all-the-nodes-in-cluster-tp4678495p4678502.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Unable to find a public ejb server via the multicast URI during remote ejb look up

[Romain Manni-Bucau]

The mentionned doc uses multicast so the host/port should be valid but
that's it. IIRC openejb-multicast is not in tomee/lib by default so you
need to drop the jar there to add this features (if there it is listed in
services at startup). That's probably the missing part.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 14:51 GMT+02:00 Dignesh :

> Is there any other way to set up cluster environment with tomee. I mean
> does
> it require some configuration to form the cluster.If yes where can i get
> the
> documentation of that
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Unable-to-find-a-public-ejb-server-via-the-multicast-URI-during-remote-ejb-look-up-tp4678491p4678499.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Raise JMS messages to all the nodes in cluster

[Romain Manni-Bucau]

Hi

a JMS topic does it by design. Please see
http://tomee.apache.org/jms-resources-and-mdb-container.html for the config
then a message driven bean can listener for messages.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 14:43 GMT+02:00 Dignesh :

> Hello,
>
> We have a requirement such that ,we need the messages raised to be
> delivered
> to all the nodes present in the cluster.
> Does messages from queue/topic can be delivered to all the nodes present in
> the cluster?
>
> If yes can anyone please provide me the sample configuration to do this.
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Raise-JMS-messages-to-all-the-nodes-in-cluster-tp4678495.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Unable to find a public ejb server via the multicast URI during remote ejb look up

[Romain Manni-Bucau]

2016-05-18 14:38 GMT+02:00 Dignesh :

> Hi,
> So you mean the configuration added in server.xml is not supported in
> TOMEE?
>
>
Not, it is supported for tomcat clustering/session clustering which is not
ejbd clustering.


> I have followed the configuration steps mentioned in below link and still I
> am seeing the issue.
>
>
Your port is the one of the session clustering so it can conflict.


> You can see that I have added multicast.properties file in conf folder with
> the below content.
>
> server  = org.apache.openejb.server.discovery.MulticastDiscoveryAgent
> bind= 228.0.0.4
> port= 45564
> disabled= false
> group   = default
>
> http://tomee.apache.org/multicast-discovery.html.
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Unable-to-find-a-public-ejb-server-via-the-multicast-URI-during-remote-ejb-look-up-tp4678491p4678494.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

reworking the CLI?

[Romain Manni-Bucau]

Hi guys,

Spoke with Andy and Jean-Louis and seems we could make our CLI a bit better.

So let's write down some proposal and then see 1. if we go this path, 2. how

## Proposal

Make our CLI richer in term of feature and commands and more user friendly.

Bonus: getting rid of commons-cli would allow us to have a better
dependency management than today for all shade flavors we have.

## Technically

1. We can replace [cli] by our light backbone or a shade (minimized) - and
then optimize/clean our shades (tomee embedded *)
2. We move commands glue code from openejb-core to openejb-cli (or whatever
other modules) - to ensure it is reusable and easy to test
3. We change the registration process to use a standard ServiceLoader?
(Easier for users to extend it/more natural)
4. We use annotations instead of properties (same as previous)
5. add alias support (typically Andy brings "cipher" vs "cypher" handling
which is a common mistake)
6. add matching feature: "./tomee.sh cip"  is not ambiguous so we can match
cipher command (algo is: if not ambiguous execute otherwise fail)

There are probably more doors open but that's the start I see/have in mind.

## Commands

Currently available:

- cipher: encode/decode a string to use with a PasswordCipher
- effectivetomee: list the loaded tomee.xml (actual one, not the file
itself)
- properties: dump tomee server configuration (same as effective tomee,
that's the internal model)
- setters: list field usable for a class (to use with )
- start: start the server (delegates to catalina.sh)
- stop: stop the server (delegates to catalina.sh)
- deploy: deploy an app
- undeploy: undeploy the app

Note: deploy/undeploy commands are to rework a bit to be useful I guess
(the current "id" is the path and is not natural IMO)

We can add:

- add-resource (add in tomee.xml a resource and deploy it if running)
- modify-resource (change a property)
- add/remove-property
- jmx-attribute
- jmx-operation
- ...

## Next steps

1. Please say you think it is a good track or just an idea we can kill
(happens ;)).
2. If we are rather positive about that I think it is a good opportunity to
get newcomers to TomEE. Part of the code is aside tomee (cli one) and the
commands themself are done or almost there for most of the ones I listed.
It just needs some integration and clean up so that's a great way to get
familiar with TomEE internals and model. That said I'm super happy to help
anyone or code some part if needed.

Finally this track would allow us to:

- own the CLI code and dependencies making us controlling our deps on the
whole chain (for shades and light deployments)
- make our CLI more user friendly
- open the door to custom commands more easily
- rework the commands to add some missing ones


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

Re: Unable to find a public ejb server via the multicast URI during remote ejb look up

[Romain Manni-Bucau]

Hi

multicast:// handling is not in tomcat and shouldn't be considered as
McastService
which is another feature, please see
http://tomee.apache.org/multicast-discovery.html for a detailed
configuration.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 14:07 GMT+02:00 Dignesh :

> Hello team,
>
> I have configured my tomee in cluster.
>
> I have  added below xml element in server.xml file for two nodes.
>
>   channelSendOptions="8">
>
>   expireSessionsOnShutdown="false"
>notifyListenersOnReplication="true"/>
>
>className="org.apache.catalina.tribes.group.GroupChannel">
>  className="org.apache.catalina.tribes.membership.McastService"
> address="228.0.0.4"
> port="45564"
> frequency="500"
> dropTime="3000"/>
>  className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>   address="auto"
>   port="4000"
>   autoBind="100"
>   selectorTimeout="5000"
>   maxThreads="6"/>
>
>  className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
> 
> 
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
> 
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
>   
>
> filter=""/>
>className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>
>className="org.apache.catalina.ha.deploy.FarmWarDeployer"
> tempDir="/tmp/war-temp/"
> deployDir="/tmp/war-deploy/"
> watchDir="/tmp/war-listen/"
> watchEnabled="false"/>
>
>className="org.apache.catalina.ha.session.ClusterSessionListener"/>
> 
>
> I also created multicast.properties file in conf folder as per
> documentation
> for multicast (UDP) discovery with below content
>
> server  = org.apache.openejb.server.discovery.MulticastDiscoveryAgent
> bind= 228.0.0.4
> port= 45564
> disabled= false
> group   = default
>
> I am trying to do the ejb look up using below configuration and I am seeing
> exceptions.
>
> Properties p = new Properties();
> p.put(javax.naming.Context.INITIAL_CONTEXT_FACTORY,
> "org.apache.openejb.client.RemoteInitialContextFactory");
>
> p.put(javax.naming.Context.PROVIDER_URL,
> "multicast://228.0.0.4:45564?group=default");
>
> Can anyone please help me on this issue.
>
> Below is the exception stack trace : -
>
> May 18, 2016 6:12:30 PM org.apache.openejb.client.EventLogger log
> INFO:
> RemoteInitialContextCreated{providerUri=multicast://
> 228.0.0.4:45564?group=default}
> May 18, 2016 6:12:31 PM org.apache.openejb.client.EventLogger log
> WARNING: ConnectionFailed{uri=multicast://228.0.0.4:45564?group=default
> cause=java.lang.IllegalArgumentException: Unable to find a public ejb
> server
> via the multicast URI: multicast://228.0.0.4:45564?group=default}
> May 18, 2016 6:12:31 PM org.apache.openejb.client.EventLogger log
> WARNING:
> BootstrappingConnection{provider=multicast://228.0.0.4:45564?group=default
> }
> May 18, 2016 6:12:33 PM org.apache.openejb.client.EventLogger log
> WARNING: ConnectionFailed{uri=multicast://228.0.0.4:45564?group=default
> cause=java.lang.IllegalArgumentException: Unable to find a public ejb
> server
> via the multicast URI: multicast://228.0.0.4:45564?group=default}
> May 18, 2016 6:12:33 PM org.apache.openejb.client.EventLogger log
> SEVERE: ConnectionStrategyFailed{strategy=StickyConnectionStrategy,
> cluster=org.apache.openejb.client.ClusterMetaData@15eb9b0d,
> server=multicast://228.0.0.4:45564?group=default}
> Exception in thread "main" javax.naming.NamingException: 

Re: IllegalArgumentException on weird constructed URL

[Romain Manni-Bucau]

thanks for confirming! very appreciated


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 11:18 GMT+02:00 Gregory Orciuch :

> Hey, confirm that 7.0.0-SNAPSHOT solved the problem.
>
> 2016-05-18 9:52 GMT+02:00 Romain Manni-Bucau :
>
> > snapshot is there
> https://repository.apache.org/content/groups/snapshots/
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-05-18 9:49 GMT+02:00 Gregory Orciuch :
> >
> > > that's right, maybe next weekend :)
> > > Meanwhile, is there any nightly snapshot available do download ?
> > >
> > > Some tests failed locally, and that's not a small project to compile.
> > >
> > > BR,
> > > Gregory
> > >
> > > 2016-05-17 16:03 GMT+02:00 Romain Manni-Bucau :
> > >
> > > > build a project on github with a failing test ;).
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2016-05-17 15:26 GMT+02:00 Gregory Orciuch :
> > > >
> > > > > Well, exclude unlisted didnt help, any other suggestion ?
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/IllegalArgumentException-on-weird-constructed-URL-tp4678460p4678473.html
> > > > > Sent from the TomEE Dev mailing list archive at Nabble.com.
> > > > >
> > > >
> > >
> >
>

Re: IllegalArgumentException on weird constructed URL

[Romain Manni-Bucau]

snapshot is there https://repository.apache.org/content/groups/snapshots/


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-18 9:49 GMT+02:00 Gregory Orciuch :

> that's right, maybe next weekend :)
> Meanwhile, is there any nightly snapshot available do download ?
>
> Some tests failed locally, and that's not a small project to compile.
>
> BR,
> Gregory
>
> 2016-05-17 16:03 GMT+02:00 Romain Manni-Bucau :
>
> > build a project on github with a failing test ;).
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-05-17 15:26 GMT+02:00 Gregory Orciuch :
> >
> > > Well, exclude unlisted didnt help, any other suggestion ?
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/IllegalArgumentException-on-weird-constructed-URL-tp4678460p4678473.html
> > > Sent from the TomEE Dev mailing list archive at Nabble.com.
> > >
> >
>

[VOTE] Apache TomEE 7.0.0

[Romain Manni-Bucau]

Hi

As mentionned and after the vote about the version here is the 7.0.0 vote.

Here are the release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12335051

Keys file is still the same: https://www.apache.org/dist/tomee/KEYS

As discussed pushed the tag on github:
https://github.com/rmannibucau/tomee/tree/tomee-7.0.0

New staging repository is
https://repository.apache.org/content/repositories/orgapachetomee-1097

Dev dist is https://dist.apache.org/repos/dist/dev/tomee/7.0.0

Vote will be open for 72h or until we get 3 +1 bindings. Binding or not
everyone is very welcomed to test and vote.


Please vote:
[ ] +1 yeah it rocks!
[ ] +0 dont' know just wanted to say hello but no idea what we are talking
about
[ ] -1 no cause ${blocker <- X}

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

Re: IllegalArgumentException on weird constructed URL

[Romain Manni-Bucau]

build a project on github with a failing test ;).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-17 15:26 GMT+02:00 Gregory Orciuch :

> Well, exclude unlisted didnt help, any other suggestion ?
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/IllegalArgumentException-on-weird-constructed-URL-tp4678460p4678473.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: IllegalArgumentException on weird constructed URL

[Romain Manni-Bucau]

setting exclude unlisted = true should maybe help. That said tomee doesnt
read persistence.xml so can be hibernate in your setup which needs the
persistence.xml.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-17 14:59 GMT+02:00 Gregory Orciuch :

> Thanks I try building and using snapshot.
>
> But small question, how I can kinda blacklist that particular
> persistence.xml ?
> I thought that if I create PU from scratch in ApplicationComposer then any
> other persistence.xml wont be used ?(scanned)
>
> Check this out: http://hastebin.com/qoruvocaba.avrasm
>
> So as soon as I dont need that persistence.xml in one of dependent jars
> then
> I name classes one-by-one so.
> Shouldnt that be persistence.xml agnostic?
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/IllegalArgumentException-on-weird-constructed-URL-tp4678460p4678471.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: IllegalArgumentException on weird constructed URL

[Romain Manni-Bucau]

https://issues.apache.org/jira/browse/TOMEE-1811

that said I'm not sure it will really solve your issue since I guess you
use jar-file in your persistence.xml (otherwise you don't have this error)
and if so in flat classpath it is likely not using the right path compared
to wars.

Let me know however if SNAPSHOT is better when redeployed (or if you build
it yourself)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-17 13:40 GMT+02:00 Gregory Orciuch :

> Small update. Same behavior with tomee openejb 7.0.0-M3 :/
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/IllegalArgumentException-on-weird-constructed-URL-tp4678460p4678469.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: IllegalArgumentException on weird constructed URL

[Romain Manni-Bucau]

Maybe we encode it twice but didnt manage to reproduce with 1.7.4 and
7.0.0-SNAPSHOT and hibernate 4 or 5 so you probably need to share a project
on github to move forward.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-17 2:34 GMT+02:00 Jalal Almutawa :

> - without the single quotes
> On May 17, 2016 3:33 AM, "Jalal Almutawa" 
> wrote:
>
> > The encoded part looks strange, as %2520 will be decoded to an actual
> > '%20'
> > On May 17, 2016 12:25 AM, "Romain Manni-Bucau" 
> > wrote:
> >
> >> Space in the path I guess. Which version?
> >> Le 16 mai 2016 19:51, "Gregory Orciuch"  a écrit :
> >>
> >> > Hi,
> >> >
> >> > when running my EJBContainerRunner tests on Windows (on linux is
> fine),
> >> > the windows'centric developers cannot run the openEJB test because of
> >> > something like this:
> >> >
> >> > IllegalArgumentException - File
> >> >
> >> >
> >>
> [/E:/workspace/pim/pim/pim-ejb/jar:file:/C:/Users/John%2520Doe/.m2/repository/com/acme/commons-model/1.0.7/commons-model-1.0.7.jar!/META-INF/persistence.xml]
> >> > referenced by given URL
> >> >
> >> >
> >>
> [file:/E:/workspace/pim/pim/pim-ejb/jar:file:/C:/Users/John%2520Doe/.m2/repository/com/acme/commons-model/1.0.7/commons-model-1.0.7.jar!/META-INF/persistence.xml]
> >> > does not exist:
> >> >
> >> > However the file
> >> >
> >> >
> >>
> C:/Users/John%2520Doe/.m2/repository/com/acme/commons-model/1.0.7/commons-model-1.0.7.jar!/META-INF/persistence.xml
> >> > indeed exists.
> >> >
> >> > It's just the URL looks very weird to me, why it's concatenated;
> >> >
> >> > Full trace here: http://hastebin.com/fifatecono.avrasm
> >> >
> >> > Any suggestion is welcome.
> >> >
> >> > Thanks,
> >> > Gregory
> >> >
> >>
> >
>

Re: IllegalArgumentException on weird constructed URL

[Romain Manni-Bucau]

Space in the path I guess. Which version?
Le 16 mai 2016 19:51, "Gregory Orciuch"  a écrit :

> Hi,
>
> when running my EJBContainerRunner tests on Windows (on linux is fine),
> the windows'centric developers cannot run the openEJB test because of
> something like this:
>
> IllegalArgumentException - File
>
> [/E:/workspace/pim/pim/pim-ejb/jar:file:/C:/Users/John%2520Doe/.m2/repository/com/acme/commons-model/1.0.7/commons-model-1.0.7.jar!/META-INF/persistence.xml]
> referenced by given URL
>
> [file:/E:/workspace/pim/pim/pim-ejb/jar:file:/C:/Users/John%2520Doe/.m2/repository/com/acme/commons-model/1.0.7/commons-model-1.0.7.jar!/META-INF/persistence.xml]
> does not exist:
>
> However the file
>
> C:/Users/John%2520Doe/.m2/repository/com/acme/commons-model/1.0.7/commons-model-1.0.7.jar!/META-INF/persistence.xml
> indeed exists.
>
> It's just the URL looks very weird to me, why it's concatenated;
>
> Full trace here: http://hastebin.com/fifatecono.avrasm
>
> Any suggestion is welcome.
>
> Thanks,
> Gregory
>

Re: IllegalArgumentException on weird constructed URL

[Romain Manni-Bucau]

Hi

the space is probably the error but looks like an hibernate bug.

You can either configure in app composer the root url to enforce it or
configure hibernate scanner to avoid scanning and list entities (that's
what i'd do)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-16 17:20 GMT+02:00 Gregory Orciuch :

> Hi,
>
> when running my EJBContainerRunner tests on Windows (on linux is fine),
> the windows'centric developers cannot run the openEJB test because of
> something like this:
>
> IllegalArgumentException - File
>
> [/E:/workspace/pim/pim/pim-ejb/jar:file:/C:/Users/John%2520Doe/.m2/repository/com/acme/commons-model/1.0.7/commons-model-1.0.7.jar!/META-INF/persistence.xml]
> referenced by given URL
>
> [file:/E:/workspace/pim/pim/pim-ejb/jar:file:/C:/Users/John%2520Doe/.m2/repository/com/acme/commons-model/1.0.7/commons-model-1.0.7.jar!/META-INF/persistence.xml]
> does not exist:
>
> However the file
>
> C:/Users/John%2520Doe/.m2/repository/com/acme/commons-model/1.0.7/commons-model-1.0.7.jar!/META-INF/persistence.xml
> indeed exists.
>
> It's just the URL looks very weird to me, why it's concatenated;
>
> Full trace here: http://hastebin.com/fifatecono.avrasm
>
> Any suggestion is welcome.
>
> Thanks,
> Gregory
>

Re: next release

[Romain Manni-Bucau]

* 8.5.2 now, they rerolled (+ it has a jaspic bugfix we need to get fixed -
thanks Arjan to have given us code to be able to identify it and unit test
it!)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-12 16:06 GMT+02:00 Mark Struberg :

> +1
>
> LieGrue,
> strub
>
>
>
>
>
> > On Wednesday, 11 May 2016, 13:33, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
> > > tomcat 8.5.1 vote started today, think I'll wait this one to pass to
> start
> > tomee release since it fixes a nasty classloading issue and would allow
> us
> > to remove a not so sexy workaround.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
>

next release

[Romain Manni-Bucau]

tomcat 8.5.1 vote started today, think I'll wait this one to pass to start
tomee release since it fixes a nasty classloading issue and would allow us
to remove a not so sexy workaround.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

Re: tomee git commit: TOMEE-1799 - Comparison method violates its general contract

[Romain Manni-Bucau]

What do you mean? Sorting happen once default was created so kind of too
late to ignore it since now it is mandatory.

Happy to investigate why default was needed if you can give few more
details.
Le 6 mai 2016 14:08, "Andy Gumbrecht"  a écrit :

> The sort still doesn't look right to me with the default also as a
> criteria.
>
> On 6 May 2016 at 14:04, Romain Manni-Bucau  wrote:
>
> > Hi Andy
> >
> > This change breaks previous ordering and doesnt fix the referenced issue
> -
> > was not an issue on 7.x.
> >
> > Any objection if I restore previous ordering next week?
> > -- Message transféré --
> > De : 
> > Date : 5 mai 2016 15:11
> > Objet : tomee git commit: TOMEE-1799 - Comparison method violates its
> > general contract
> > À : 
> > Cc :
> >
> > Repository: tomee
> > Updated Branches:
> >   refs/heads/master a9e29701b -> 3a46ba5fd
> >
> >
> > TOMEE-1799 - Comparison method violates its general contract
> >
> > https://issues.apache.org/jira/browse/TOMEE-1799
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/3a46ba5f
> > Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/3a46ba5f
> > Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/3a46ba5f
> >
> > Branch: refs/heads/master
> > Commit: 3a46ba5fd624a68577726124b647d5dcd217d4d9
> > Parents: a9e2970
> > Author: AndyGee 
> > Authored: Thu May 5 15:10:37 2016 +0200
> > Committer: AndyGee 
> > Committed: Thu May 5 15:10:37 2016 +0200
> >
> > --
> >  .../org/apache/openejb/config/AutoConfig.java   |   7 +-
> >  .../openejb/activemq/AMQXASupportTest.java  |   6 +-
> >  .../apache/openejb/config/AutoConfigTest.java   | 448
> +++
> >  3 files changed, 457 insertions(+), 4 deletions(-)
> > --
> >
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/tomee/blob/3a46ba5f/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> > --
> > diff --git
> >
> >
> a/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> >
> >
> b/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> > index fa81261..9c40293 100644
> > ---
> >
> >
> a/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> > +++
> >
> >
> b/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> > @@ -2063,8 +2063,9 @@ public class AutoConfig implements DynamicDeployer,
> > JndiConstants {
> >  return -1;
> >  } else if (o2.startsWith(prefix)) {
> >  return 1;
> > +} else {
> > +return resourceIds.indexOf(o2) -
> > resourceIds.indexOf(o1);
> >  }
> > -return resourceIds.indexOf(o1) -
> resourceIds.indexOf(o2);
> >  }
> >  });
> >  String idd = null;
> > @@ -2269,7 +2270,7 @@ public class AutoConfig implements DynamicDeployer,
> > JndiConstants {
> >  return null;
> >  }
> >
> > -private static class AppResources {
> > +static class AppResources {
> >
> >  private String appId;
> >
> > @@ -2307,7 +2308,7 @@ public class AutoConfig implements DynamicDeployer,
> > JndiConstants {
> >  public AppResources() {
> >  }
> >
> > -public AppResources(final AppModule appModule) {
> > +protected AppResources(final AppModule appModule) {
> >
> >  this.appId = appModule.getModuleId();
> >
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/tomee/blob/3a46ba5f/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
> > --
> > diff --git
> >
> >
> a/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
> >
> >
> b/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
> > index b283305..1391f1e 100644
> > ---
> >
> >
> a/container/openejb-core/src/test/java/org/apache/openejb/activemq/A

Fwd: tomee git commit: TOMEE-1799 - Comparison method violates its general contract

[Romain Manni-Bucau]

Hi Andy

This change breaks previous ordering and doesnt fix the referenced issue -
was not an issue on 7.x.

Any objection if I restore previous ordering next week?
-- Message transféré --
De : 
Date : 5 mai 2016 15:11
Objet : tomee git commit: TOMEE-1799 - Comparison method violates its
general contract
À : 
Cc :

Repository: tomee
Updated Branches:
  refs/heads/master a9e29701b -> 3a46ba5fd


TOMEE-1799 - Comparison method violates its general contract

https://issues.apache.org/jira/browse/TOMEE-1799


Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/3a46ba5f
Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/3a46ba5f
Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/3a46ba5f

Branch: refs/heads/master
Commit: 3a46ba5fd624a68577726124b647d5dcd217d4d9
Parents: a9e2970
Author: AndyGee 
Authored: Thu May 5 15:10:37 2016 +0200
Committer: AndyGee 
Committed: Thu May 5 15:10:37 2016 +0200

--
 .../org/apache/openejb/config/AutoConfig.java   |   7 +-
 .../openejb/activemq/AMQXASupportTest.java  |   6 +-
 .../apache/openejb/config/AutoConfigTest.java   | 448 +++
 3 files changed, 457 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/tomee/blob/3a46ba5f/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
--
diff --git
a/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
b/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
index fa81261..9c40293 100644
---
a/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
+++
b/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
@@ -2063,8 +2063,9 @@ public class AutoConfig implements DynamicDeployer,
JndiConstants {
 return -1;
 } else if (o2.startsWith(prefix)) {
 return 1;
+} else {
+return resourceIds.indexOf(o2) -
resourceIds.indexOf(o1);
 }
-return resourceIds.indexOf(o1) - resourceIds.indexOf(o2);
 }
 });
 String idd = null;
@@ -2269,7 +2270,7 @@ public class AutoConfig implements DynamicDeployer,
JndiConstants {
 return null;
 }

-private static class AppResources {
+static class AppResources {

 private String appId;

@@ -2307,7 +2308,7 @@ public class AutoConfig implements DynamicDeployer,
JndiConstants {
 public AppResources() {
 }

-public AppResources(final AppModule appModule) {
+protected AppResources(final AppModule appModule) {

 this.appId = appModule.getModuleId();


http://git-wip-us.apache.org/repos/asf/tomee/blob/3a46ba5f/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
--
diff --git
a/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
b/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
index b283305..1391f1e 100644
---
a/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
+++
b/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
@@ -119,7 +119,11 @@ public class AMQXASupportTest {
 producer.send(session.createTextMessage(TEXT));
 assertTrue(Listener.sync());
 } finally {
-connection.close();
+try {
+connection.close();
+} catch (final JMSException e) {
+//no-op
+}
 }
 }


http://git-wip-us.apache.org/repos/asf/tomee/blob/3a46ba5f/container/openejb-core/src/test/java/org/apache/openejb/config/AutoConfigTest.java
--
diff --git
a/container/openejb-core/src/test/java/org/apache/openejb/config/AutoConfigTest.java
b/container/openejb-core/src/test/java/org/apache/openejb/config/AutoConfigTest.java
new file mode 100644
index 000..55d4f9f
--- /dev/null
+++
b/container/openejb-core/src/test/java/org/apache/openejb/config/AutoConfigTest.java
@@ -0,0 +1,448 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0

Re: 7.0.0 release vote

[Romain Manni-Bucau]

Being 95% compliant or 2% compliant depends on what: spec, tck, goal,
usability etc...

Numbers mean nothing, user feedback does and is rather good for now.
Le 5 mai 2016 17:04, "ross.cohen"  a écrit :

> Romain Manni-Bucau wrote
> > Le 4 mai 2016 23:28, "ross.cohen" <
>
> > ross.cohen.rc@
>
> > > a écrit :
> >>
> >> Romain Manni-Bucau wrote
> >> > 2016-05-04 14:54 GMT+02:00 ross.cohen <
> >>
> >> > ross.cohen.rc@
> >>
> >> > >:
> >> >
> >> >> David Blevins-2 wrote
> >> >> >> On May 2, 2016, at 5:05 AM, Romain Manni-Bucau <
> >> >
> >> >>
> >> >> That is also my recollection of the question.
> >> >>
> >> >> But whether or not it was the case, it is certainly the case that any
> >> >> user
> >> >> downloading Tomee 7.x will do so under the impression that it is JEE
> 7
> >> >> compliant.  This is reason enough to either wait, or continue under
> >> the
> >> >> current numbering scheme.
> >> >>
> >> >>
> >> >>
> >> > Well both lead to the same: tomee is not adapted. Question is then:
> >> when
> >> > do
> >> > we stop waiting for something likely not coming?
> >>
> >> I don't really care about the TCK.  Everyone would like it if Oracle
> >> would
> >> play nice
> >> and released a TCK for us, but it's not going to happen.  However,
> >> compliance with
> >> the specs is a different matter.  At what point are we compliant with
> the
> >> specs?
> >> Good question.  David says the rest api passes only 75% of the published
> >> examples.  To me, that is non-compliant.   If it were 95%, I'd be
> willing
> > to
> >> call us
> >> compliant.   Exactly where is the line?   I'm not sure, but it can't be
> > much
> >> below 95%.
> >> If users find that the software frequently contradicts the spec, they
> >> will
> >> become
> >> frustrated and angry.
> >
> > Examples are not spec compliant too or abuse of vendor behavior. Also a
> > serious amount of users just need what is in tomee now. I tend to prefer
> > to
> > move forward with active people than waiting passive ones move - we lost
> 2
> > years with such a behavior.
> >
> > What you mentionned is also true for 100% certified servers so with
> > experience I think ignoring it is fine while we fix fast.
>
> If it is truly the case that Tomee is 95%+ compliant, then releasing 7.0
> seems reasonable.  As you point out, no implementation is 100% compliant.
>
> Cheers.
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/7-0-0-release-vote-tp4678284p4678364.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: 7.0.0 release vote

[Romain Manni-Bucau]

Le 4 mai 2016 23:28, "ross.cohen"  a écrit :
>
> Romain Manni-Bucau wrote
> > 2016-05-04 14:54 GMT+02:00 ross.cohen <
>
> > ross.cohen.rc@
>
> > >:
> >
> >> David Blevins-2 wrote
> >> >> On May 2, 2016, at 5:05 AM, Romain Manni-Bucau <
> >
> >>
> >> That is also my recollection of the question.
> >>
> >> But whether or not it was the case, it is certainly the case that any
> >> user
> >> downloading Tomee 7.x will do so under the impression that it is JEE 7
> >> compliant.  This is reason enough to either wait, or continue under the
> >> current numbering scheme.
> >>
> >>
> >>
> > Well both lead to the same: tomee is not adapted. Question is then: when
> > do
> > we stop waiting for something likely not coming?
>
> I don't really care about the TCK.  Everyone would like it if Oracle would
> play nice
> and released a TCK for us, but it's not going to happen.  However,
> compliance with
> the specs is a different matter.  At what point are we compliant with the
> specs?
> Good question.  David says the rest api passes only 75% of the published
> examples.  To me, that is non-compliant.   If it were 95%, I'd be willing
to
> call us
> compliant.   Exactly where is the line?   I'm not sure, but it can't be
much
> below 95%.
> If users find that the software frequently contradicts the spec, they will
> become
> frustrated and angry.
>

Examples are not spec compliant too or abuse of vendor behavior. Also a
serious amount of users just need what is in tomee now. I tend to prefer to
move forward with active people than waiting passive ones move - we lost 2
years with such a behavior.

What you mentionned is also true for 100% certified servers so with
experience I think ignoring it is fine while we fix fast.

Anyway as said vote passed even if some people were not happy. Ill start a
vote next week and let see what happen.

> Cheers
>
>
>
>
>
> --
> View this message in context:
http://tomee-openejb.979440.n4.nabble.com/7-0-0-release-vote-tp4678284p4678361.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: 7.0.0 release vote

[Romain Manni-Bucau]

2016-05-04 14:54 GMT+02:00 ross.cohen :

> David Blevins-2 wrote
> >> On May 2, 2016, at 5:05 AM, Romain Manni-Bucau <
>
> > rmannibucau@
>
> > > wrote:
> >>
> >> Fully agree that's why it has been stated tomee 7 != javaee 7.
> >
> > My memory of that vote was we intentionally aligned the TomEE version
> > number specifically to align to the Java EE version number and further
> > that it would not be changed even if major change in the server occurred,
> > stating “7.1” and “7.2” would be clear enough to communicate breaking
> > upgrades.
> >
> > I voted -1 on that one, but the above was my understanding of what was
> > decided.
> >
> > I’d be glad to hear it is not, but I would question why we didn’t just
> > stick with 2.x if we weren’t intending to communicate “this implements
> > Java EE 7”.
>
> That is also my recollection of the question.
>
> But whether or not it was the case, it is certainly the case that any user
> downloading Tomee 7.x will do so under the impression that it is JEE 7
> compliant.  This is reason enough to either wait, or continue under the
> current numbering scheme.
>
>
>
Well both lead to the same: tomee is not adapted. Question is then: when do
we stop waiting for something likely not coming?


>
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/7-0-0-release-vote-tp4678284p4678347.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: 7.0.0 release vote

[Romain Manni-Bucau]

+1 I would prefer a tons of -1 from users than committers (actually
commiters know how to sort it out so we shouldnt care much of them for such
things ;)).

Now factually vote passed, no new input made the overall debate face
changed so still think we can move forward. I perfectly get - more than you
think - the manager constraint but it will still be there whatever we do
for now. Also if selecting a product is only done on the TCK compliance I'm
happy to let people use some other $ervers (or if the reason is the logo is
using this #abcdef color), quality is not always there but they are often
expensive enough to convince a manager and sadly lock a developer team to
old and buggy versions but whatever constraints are coming from non dev
people I don't want TomEE to be a hostage of such a discussion. This
belongs to vendors and commercial companies not to open source IMHO.

Side note: EE 7 spec have been listed there
http://tomee.apache.org/comparison.html . Of course it doesn't mean any TCK
compliance but it shows the area we worked on - at least the ones I know
about. If I missed any feel free to complete it. If you think the
formatting can be better feel free to play with the dom too, wanted to
avoid another table which basically duplicates a lot of noise but that's
only my voice and I'm for making it clearer if possible.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-03 17:58 GMT+02:00 Jean-Louis Monteiro :

> Thanks for the feedback.
>
> We encourage everyone to vote, as a user, as a contributor, as a
> contributor or as anyone willing to help the project.
> User perspective is also important for the project.
>
> Jean-Louis
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Mon, May 2, 2016 at 4:49 PM, ross.cohen 
> wrote:
>
> >
> > Le 29 avr. 2016 00:49, "ross.cohen" <ross.cohen.rc@> a écrit :
> >
> >
> > > Actually, it looks like a 7.0 release means different things to
> different
> > > people.  Romain, you took everyone's approval of the idea of a 7.0.0
> > release
> > > to be an approval of your particular version of a 7.0.0 release, which
> it
> > > clearly was not.   Looks to me like a finer-grained vote is needed to
> > figure
> > > out exactly what people want as part of 7.0.0 release.
> > >
> >
> > Clearly stated we were speaking of master in the thread when Jon asked
> so I
> > kind of disagree there.
> >
> > > Personally, I think David is correct in saying that a release without
> > some
> > > kind of positive JEE 7 compatibility statement is a serious mistake.  I
> > know
> > > the TCK is out of the question right now, but that simply means you
> need
> > to
> > > invent an alternative compatibility statement:  "Apache-Certified
> > Compliant
> > > to Web Profile Specifications" (or some such).
> > >
> >
> > --This doesnt mean anything to me like that. Being ASF implies ASF
> quality
> > --and we cant claim anything Oracle related so Im lost with what you
> target
> > --there.
> >
> > To the vast majority of prospective users any major version change will
> > strongly
> > imply that Tomee conforms to the JEE 7 Web spec.  The fact that Tomee is
> > jumping
> > from 2.x to 7.0 seals the deal.   I would guess that most people here
> voted
> > for the
> > move to a "7" release under the impression that it would conform to to
> JEE
> > 7
> > web
> > spec --  it's impossible to imagine any other reason for skipping the
> > intervening
> > integers.
> >
> > I'm not a legal person, but it seems like one should be able to say that
> > Tomee
> > conforms to the specifications belonging to the JEE standard released by
> > Oracle.
> > It is a mere statement of fact.  It would be nice to have an "Apache
> > Certified"
> > statement and symbol/stamp; for some reason this sort of thing helps a
> lot
> > of
> > managers sleep better at night.  Remember that programmers often have to
> > fight
> > for the software they want to use.  Frequently, our managers are not very
> > well
> > informed, and are easily flim-flammed by Leviathan's representatives.
> >  It's
> > only later
> > that they learn 

Re: 7.0.0 release vote

[Romain Manni-Bucau]

@David: we needed a version >= 5 (think I voted for 5) just to not break
auto-tools like maven version comparison etc. Then I guess users desired
ee=tomee but when you pointed out this confusion to me I made it clear in a
thread.
@all: now we had milestones 7.x we need for the same reason a 7.0.0 or a >
7.x so 2, 3, 4, 5 and 6 are no more options.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-03 7:53 GMT+02:00 Eduard Ketler :

> Hi all, from a Customers or User perspective i totally agree with using
> version 2.x and wait with 7.x for the EE compliance. Thats pretty straight
> forward David. That would not confusing me.
>
> Eduard
>
> Matej  schrieb am Di., 3. Mai 2016 um 07:08:
>
> > Hi all. Not developer. But I also think jumping to 7.x for no reason will
> > only confuse everyone. If ee7 will not be provided like 98 - 99 %
> > compliant. Then it would really be better to maybe just go 2.x route. I
> > think already now people that choose Tomee, dont really care about being
> > 100% compliant. But still would be nice to not confuse people. Br matej
> > 3. maj 2016 05.43 je oseba "David Blevins" 
> > napisala:
> >
> > >
> > > > On May 2, 2016, at 5:05 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > > wrote:
> > > >
> > > > Fully agree that's why it has been stated tomee 7 != javaee 7.
> > >
> > > My memory of that vote was we intentionally aligned the TomEE version
> > > number specifically to align to the Java EE version number and further
> > that
> > > it would not be changed even if major change in the server occurred,
> > > stating “7.1” and “7.2” would be clear enough to communicate breaking
> > > upgrades.
> > >
> > > I voted -1 on that one, but the above was my understanding of what was
> > > decided.
> > >
> > > I’d be glad to hear it is not, but I would question why we didn’t just
> > > stick with 2.x if we weren’t intending to communicate “this implements
> > Java
> > > EE 7”.
> > >
> > >
> > > -David
> > >
> > >
> >
>

Re: TomEE 1.7.x on Java8

[Romain Manni-Bucau]

if it helps: there is a system property for that in the JVM to revert to
the old sort algo, should solve it. Also think it has been fixed further on
7.x branch.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-02 15:52 GMT+02:00 Andy Gumbrecht :

> OK, wasn't sure. So now I have an issue. It's maybe an app issue as it is
> only one app from 85, but feel like TomEE should cope with this.
>
> https://issues.apache.org/jira/browse/TOMEE-1795
>
> Will post more info when available.
>
> Andy.
>
> On 2 May 2016 at 15:21, Romain Manni-Bucau  wrote:
>
> > Hi Andy,
> >
> > yes we do for default distributions
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-05-02 15:16 GMT+02:00 Andy Gumbrecht :
> >
> > > Are we supporting TomEE 1.7.x on Java8?
> > >
> > > Andy.
> > >
> > > --
> > >   Andy Gumbrecht
> > >   https://twitter.com/AndyGeeDe
> > >   http://www.tomitribe.com
> > >
> >
>
>
>
> --
>   Andy Gumbrecht
>   https://twitter.com/AndyGeeDe
>   http://www.tomitribe.com
>

Re: TomEE 1.7.x on Java8

[Romain Manni-Bucau]

Hi Andy,

yes we do for default distributions


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-02 15:16 GMT+02:00 Andy Gumbrecht :

> Are we supporting TomEE 1.7.x on Java8?
>
> Andy.
>
> --
>   Andy Gumbrecht
>   https://twitter.com/AndyGeeDe
>   http://www.tomitribe.com
>

Re: 7.0.0 release vote

[Romain Manni-Bucau]

did the same and got an enthousistic moment, didnt last :(


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-02 14:31 GMT+02:00 Andy Gumbrecht :

> Yep, misleading use of the word 'OR' on this page -
> http://hibernate.org/community/license/ - "Hibernate projects are licensed
> under either the LGPL 2.1 or the ASL 2.0"
>
> On 2 May 2016 at 14:05, Romain Manni-Bucau  wrote:
>
> > 2016-05-02 14:00 GMT+02:00 Andy Gumbrecht :
> >
> > > I still feel we are due another Milestone release until TomEE is a
> little
> > > closer to the mark. There needs to be a really strong statement as to
> > what
> > > is available and what is not. There has already been some negative
> > feedback
> > > from power users that expected more, and were disappointed to find
> > missing
> > > features they expected to find merely based on the 7.x label - Wrongly
> > > thinking that TomEE EE7 support was complete (Because we haven't really
> > > told them).
> > >
> > >
> > Fully agree that's why it has been stated tomee 7 != javaee 7. We also
> got
> > very negative feedback and worse than negative feedbacks -> blockers to
> not
> > have a version without "M". You are free to do a milestone if you want
> and
> > even a 8.0.0 when we get certified. In the meantime I see only harmful
> > reasons to block all people waiting on a not milestone (including
> vendors).
> >
> > Said otherwise: I try to push the concrete path vs the philosophical one.
> >
> >
> > > Would there be a problem distributing the latest Hibernate (ASL) with
> > > TomEE? - Even if some features would need unwrapping and documenting.
> > >
> > >
> > it is still mentionned being lgpl 2.1 on their website. validator is asl
> > AFAIK cause of JCP but orm is not. Did you find another source?
> >
> >
> > > Andy.
> > >
> > > On 2 May 2016 at 13:48, Roberto Cortez 
> > > wrote:
> > >
> > > > Some JAX-RS tests are using JPA 2.1 features which is not supported
> > yet.
> > > >   From: John D. Ament 
> > > >  To: dev@tomee.apache.org
> > > >  Sent: Monday, May 2, 2016 12:11 PM
> > > >  Subject: Re: 7.0.0 release vote
> > > >
> > > > On Mon, May 2, 2016 at 2:44 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Not portable test, jpa on not jpa tests etc. We pass really more
> > tests
> > > > > AFAIK.
> > > >
> > > >
> > > > Could you elaborate on that a little? What is not portable?  If you
> > want
> > > to
> > > > raise issues in our ticket system please feel free:
> > > > https://github.com/javaee-samples/javaee7-samples/issues
> > > >
> > > > Or if you want to just say them, I can put them into github.
> > > >
> > > >
> > > >
> > > > > Le 2 mai 2016 05:48, "David Blevins"  a
> > > écrit :
> > > > >
> > > > > > No worries on the many posts.  Thank you for the Java EE 7
> samples
> > > > > checkup
> > > > > > :)
> > > > > >
> > > > > > It appears we fail 35% of the JAX-RS 2.0 tests.  Do we know what
> is
> > > > > > preventing us from passing those tests?
> > > > > >
> > > > > >
> > > > > > --
> > > > > > David Blevins
> > > > > > http://twitter.com/dblevins
> > > > > > http://www.tomitribe.com
> > > > > >
> > > > > > > On May 1, 2016, at 6:42 PM, John D. Ament <
> johndam...@apache.org
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > Sorry for so many posts :-)
> > > > > > >
> > > > > > > TomEE Plus 7.0.0-M3 passes 238/338 tests in the suite.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > On Sun, May 1, 2016 at 9:30 PM John D. Ament <
> > > johndam...@apache.org>

Re: 7.0.0 release vote

[Romain Manni-Bucau]

2016-05-02 14:00 GMT+02:00 Andy Gumbrecht :

> I still feel we are due another Milestone release until TomEE is a little
> closer to the mark. There needs to be a really strong statement as to what
> is available and what is not. There has already been some negative feedback
> from power users that expected more, and were disappointed to find missing
> features they expected to find merely based on the 7.x label - Wrongly
> thinking that TomEE EE7 support was complete (Because we haven't really
> told them).
>
>
Fully agree that's why it has been stated tomee 7 != javaee 7. We also got
very negative feedback and worse than negative feedbacks -> blockers to not
have a version without "M". You are free to do a milestone if you want and
even a 8.0.0 when we get certified. In the meantime I see only harmful
reasons to block all people waiting on a not milestone (including vendors).

Said otherwise: I try to push the concrete path vs the philosophical one.


> Would there be a problem distributing the latest Hibernate (ASL) with
> TomEE? - Even if some features would need unwrapping and documenting.
>
>
it is still mentionned being lgpl 2.1 on their website. validator is asl
AFAIK cause of JCP but orm is not. Did you find another source?


> Andy.
>
> On 2 May 2016 at 13:48, Roberto Cortez 
> wrote:
>
> > Some JAX-RS tests are using JPA 2.1 features which is not supported yet.
> >   From: John D. Ament 
> >  To: dev@tomee.apache.org
> >  Sent: Monday, May 2, 2016 12:11 PM
> >  Subject: Re: 7.0.0 release vote
> >
> > On Mon, May 2, 2016 at 2:44 AM Romain Manni-Bucau  >
> > wrote:
> >
> > > Not portable test, jpa on not jpa tests etc. We pass really more tests
> > > AFAIK.
> >
> >
> > Could you elaborate on that a little? What is not portable?  If you want
> to
> > raise issues in our ticket system please feel free:
> > https://github.com/javaee-samples/javaee7-samples/issues
> >
> > Or if you want to just say them, I can put them into github.
> >
> >
> >
> > > Le 2 mai 2016 05:48, "David Blevins"  a
> écrit :
> > >
> > > > No worries on the many posts.  Thank you for the Java EE 7 samples
> > > checkup
> > > > :)
> > > >
> > > > It appears we fail 35% of the JAX-RS 2.0 tests.  Do we know what is
> > > > preventing us from passing those tests?
> > > >
> > > >
> > > > --
> > > > David Blevins
> > > > http://twitter.com/dblevins
> > > > http://www.tomitribe.com
> > > >
> > > > > On May 1, 2016, at 6:42 PM, John D. Ament 
> > > wrote:
> > > > >
> > > > > Sorry for so many posts :-)
> > > > >
> > > > > TomEE Plus 7.0.0-M3 passes 238/338 tests in the suite.
> > > > >
> > > > > John
> > > > >
> > > > > On Sun, May 1, 2016 at 9:30 PM John D. Ament <
> johndam...@apache.org>
> > > > wrote:
> > > > >
> > > > >> I ended up changing the version and updating the code.  I ran the
> > > tests,
> > > > >> you can see the output in this gist:
> > > > >>
> https://gist.github.com/johnament/2443e79836605a913159b14295681536
> > > > >>
> > > > >> TomEE Plus fails at about 100 tests.
> > > > >>
> > > > >> John
> > > > >>
> > > > >>
> > > > >> On Sun, May 1, 2016 at 8:10 PM John D. Ament <
> johndam...@apache.org
> > >
> > > > >> wrote:
> > > > >>
> > > > >>> If it helps any, I can push up the latest TomEE version to the
> > TomEE
> > > > >>> profile:
> > > > >>>
> > > >
> > >
> >
> https://github.com/javaee-samples/javaee7-samples/blob/master/pom.xml#L690
> > > > >>>
> > > > >>> John
> > > > >>>
> > > > >>>
> > > > >>> On Sun, May 1, 2016 at 8:07 PM David Blevins <
> > > david.blev...@gmail.com>
> > > > >>> wrote:
> > > > >>>
> > > > >>>> In terms of statements of compliance, which of these Java EE 7
> > > samples
> > > > >>>> will currently run successfully?
> > > > >>>>
> > > > >>>> - https://github.com/javaee-samples/javaee7-samples <
> > > >

Re: 7.0.0 release vote

[Romain Manni-Bucau]

Fixed several in my fork - guess it has been merged but there was too much
issues to fix them all alone. The build output shows what it is generally -
excepted when the tests are not passing at all like angular example was.
Le 2 mai 2016 13:11, "John D. Ament"  a écrit :

> On Mon, May 2, 2016 at 2:44 AM Romain Manni-Bucau 
> wrote:
>
> > Not portable test, jpa on not jpa tests etc. We pass really more tests
> > AFAIK.
>
>
> Could you elaborate on that a little? What is not portable?  If you want to
> raise issues in our ticket system please feel free:
> https://github.com/javaee-samples/javaee7-samples/issues
>
> Or if you want to just say them, I can put them into github.
>
>
>
> > Le 2 mai 2016 05:48, "David Blevins"  a écrit :
> >
> > > No worries on the many posts.  Thank you for the Java EE 7 samples
> > checkup
> > > :)
> > >
> > > It appears we fail 35% of the JAX-RS 2.0 tests.  Do we know what is
> > > preventing us from passing those tests?
> > >
> > >
> > > --
> > > David Blevins
> > > http://twitter.com/dblevins
> > > http://www.tomitribe.com
> > >
> > > > On May 1, 2016, at 6:42 PM, John D. Ament 
> > wrote:
> > > >
> > > > Sorry for so many posts :-)
> > > >
> > > > TomEE Plus 7.0.0-M3 passes 238/338 tests in the suite.
> > > >
> > > > John
> > > >
> > > > On Sun, May 1, 2016 at 9:30 PM John D. Ament 
> > > wrote:
> > > >
> > > >> I ended up changing the version and updating the code.  I ran the
> > tests,
> > > >> you can see the output in this gist:
> > > >> https://gist.github.com/johnament/2443e79836605a913159b14295681536
> > > >>
> > > >> TomEE Plus fails at about 100 tests.
> > > >>
> > > >> John
> > > >>
> > > >>
> > > >> On Sun, May 1, 2016 at 8:10 PM John D. Ament  >
> > > >> wrote:
> > > >>
> > > >>> If it helps any, I can push up the latest TomEE version to the
> TomEE
> > > >>> profile:
> > > >>>
> > >
> >
> https://github.com/javaee-samples/javaee7-samples/blob/master/pom.xml#L690
> > > >>>
> > > >>> John
> > > >>>
> > > >>>
> > > >>> On Sun, May 1, 2016 at 8:07 PM David Blevins <
> > david.blev...@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>>> In terms of statements of compliance, which of these Java EE 7
> > samples
> > > >>>> will currently run successfully?
> > > >>>>
> > > >>>> - https://github.com/javaee-samples/javaee7-samples <
> > > >>>> https://github.com/javaee-samples/javaee7-samples>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> David Blevins
> > > >>>> http://twitter.com/dblevins
> > > >>>> http://www.tomitribe.com
> > > >>>>
> > > >>>>> On Apr 28, 2016, at 6:19 AM, ross.cohen  >
> > > >>>> wrote:
> > > >>>>>
> > > >>>>> Actually, it looks like a 7.0 release means different things to
> > > >>>> different
> > > >>>>> people.  Romain, you took everyone's approval of the idea of a
> > 7.0.0
> > > >>>> release
> > > >>>>> to be an approval of your particular version of a 7.0.0 release,
> > > which
> > > >>>> it
> > > >>>>> clearly was not.   Looks to me like a finer-grained vote is
> needed
> > to
> > > >>>> figure
> > > >>>>> out exactly what people want as part of 7.0.0 release.
> > > >>>>>
> > > >>>>> Personally, I think David is correct in saying that a release
> > without
> > > >>>> some
> > > >>>>> kind of positive JEE 7 compatibility statement is a serious
> > mistake.
> > > >>>> I know
> > > >>>>> the TCK is out of the question right now, but that simply means
> you
> > > >>>> need to
> > > >>>>> invent an alternative compatibility statement:  "Apache-Certified
> > > >>>> Compliant
> > > >>>>> to Web Profile Specifications" (or some such).
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> View this message in context:
> > > >>>>
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/7-0-0-release-vote-tp4678284.html
> > > >>>>> Sent from the TomEE Dev mailing list archive at Nabble.com.
> > > >>>>
> > > >>>>
> > >
> > >
> >
>

Re: Container has suffered a SystemException

[Romain Manni-Bucau]

Hi

did you tune tomee.security.identity.schedule and
tomee.security.identity.timeout? Defaults are 1mn (6 - value in ms) and
30mn (180 - value in ms) and can lead to that if second value is
reached without interactions with the logged in session (remote ejb).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-05-01 22:29 GMT+02:00 Ingo Mahnke :

> Hallo,
> maybe anybody can help me. Today we try to to use tomee in real productiv
> usage.
> After two hours of online the folling exection occurs:
>
>
>
> javax.ejb.EJBException: Container has suffered a SystemException
>
> org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.java:224)
>
> org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:136)
>
> org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
> com.sun.proxy.$Proxy37.readUser(Unknown Source)
>
> com.quvion.webclient.portal.CheckInFilter.doFilter(CheckInFilter.java)
> root cause
>
> java.rmi.RemoteException: Client identity is not valid -
> EJBRequest{deploymentId='QuvionEMXBean', type=EJB_OBJECT_BUSINESS_METHOD,
> Body{ejb=null, orb=null, methodInstance=null, interfaceClass=null,
> methodName='null', methodParamTypes=null, methodParameters=null,
> primaryKey=null, requestId='null', version=2}}; nested exception is:
> javax.security.auth.login.LoginException: Identity is not
> currently logged in: 26abe643-472c-4d77-b9ea-bc174b9ceb46
>
> org.apache.openejb.server.ejbd.EjbRequestHandler.setResponseError(EjbRequestHandler.java:591)
>
> org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:115)
>
> org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:344)
>
> org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:240)
>
> org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:104)
>
> org.apache.openejb.server.httpd.ServerServlet.service(ServerServlet.java:58)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
> root cause
>
> javax.security.auth.login.LoginException: Identity is not currently logged
> in: 26abe643-472c-4d77-b9ea-bc174b9ceb46
>
> org.apache.openejb.core.security.AbstractSecurityService.associate(AbstractSecurityService.java:265)
>
> org.apache.openejb.core.security.AbstractSecurityService.associate(AbstractSecurityService.java:64)
>
> org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:111)
>
> org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:344)
>
> org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:240)
>
> org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:104)
>
> org.apache.openejb.server.httpd.ServerServlet.service(ServerServlet.java:58)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
>
> We are using Tomee 1.7.4. Atfer restart everything runs fine for about 2
> hours, then this exception occurs again.
>
>
>
> Thank you
> Ingo
>
>
>

Re: 7.0.0 release vote

[Romain Manni-Bucau]

Not portable test, jpa on not jpa tests etc. We pass really more tests
AFAIK.
Le 2 mai 2016 05:48, "David Blevins"  a écrit :

> No worries on the many posts.  Thank you for the Java EE 7 samples checkup
> :)
>
> It appears we fail 35% of the JAX-RS 2.0 tests.  Do we know what is
> preventing us from passing those tests?
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On May 1, 2016, at 6:42 PM, John D. Ament  wrote:
> >
> > Sorry for so many posts :-)
> >
> > TomEE Plus 7.0.0-M3 passes 238/338 tests in the suite.
> >
> > John
> >
> > On Sun, May 1, 2016 at 9:30 PM John D. Ament 
> wrote:
> >
> >> I ended up changing the version and updating the code.  I ran the tests,
> >> you can see the output in this gist:
> >> https://gist.github.com/johnament/2443e79836605a913159b14295681536
> >>
> >> TomEE Plus fails at about 100 tests.
> >>
> >> John
> >>
> >>
> >> On Sun, May 1, 2016 at 8:10 PM John D. Ament 
> >> wrote:
> >>
> >>> If it helps any, I can push up the latest TomEE version to the TomEE
> >>> profile:
> >>>
> https://github.com/javaee-samples/javaee7-samples/blob/master/pom.xml#L690
> >>>
> >>> John
> >>>
> >>>
> >>> On Sun, May 1, 2016 at 8:07 PM David Blevins 
> >>> wrote:
> >>>
>  In terms of statements of compliance, which of these Java EE 7 samples
>  will currently run successfully?
> 
>  - https://github.com/javaee-samples/javaee7-samples <
>  https://github.com/javaee-samples/javaee7-samples>
> 
> 
>  --
>  David Blevins
>  http://twitter.com/dblevins
>  http://www.tomitribe.com
> 
> > On Apr 28, 2016, at 6:19 AM, ross.cohen 
>  wrote:
> >
> > Actually, it looks like a 7.0 release means different things to
>  different
> > people.  Romain, you took everyone's approval of the idea of a 7.0.0
>  release
> > to be an approval of your particular version of a 7.0.0 release,
> which
>  it
> > clearly was not.   Looks to me like a finer-grained vote is needed to
>  figure
> > out exactly what people want as part of 7.0.0 release.
> >
> > Personally, I think David is correct in saying that a release without
>  some
> > kind of positive JEE 7 compatibility statement is a serious mistake.
>  I know
> > the TCK is out of the question right now, but that simply means you
>  need to
> > invent an alternative compatibility statement:  "Apache-Certified
>  Compliant
> > to Web Profile Specifications" (or some such).
> >
> >
> >
> > --
> > View this message in context:
> 
> http://tomee-openejb.979440.n4.nabble.com/7-0-0-release-vote-tp4678284.html
> > Sent from the TomEE Dev mailing list archive at Nabble.com.
> 
> 
>
>

Path to tomee 7.0.0

[Romain Manni-Bucau]

Hi guys,

next release will be the 7.0.0.

What do we want to include in it - not delaying the release of too much?

Personally I'd like to upgrade OWB and detail which spec we worked on in
another page.

Any todo on your side?

Next week has a bank holiday for some of us so i'm targetting a release
~mid may.

Side note: as mentionned on the version vote thread the doc about what is
7.0.0 has been pushed. Don't hesitate to enhance it until the release if
you find it misses anything.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

Re: 7.0.0 release vote

[Romain Manni-Bucau]

Le 29 avr. 2016 00:49, "ross.cohen"  a écrit :
>
> Actually, it looks like a 7.0 release means different things to different
> people.  Romain, you took everyone's approval of the idea of a 7.0.0
release
> to be an approval of your particular version of a 7.0.0 release, which it
> clearly was not.   Looks to me like a finer-grained vote is needed to
figure
> out exactly what people want as part of 7.0.0 release.
>

Clearly stated we were speaking of master in the thread when Jon asked so I
kind of disagree there.

> Personally, I think David is correct in saying that a release without some
> kind of positive JEE 7 compatibility statement is a serious mistake.  I
know
> the TCK is out of the question right now, but that simply means you need
to
> invent an alternative compatibility statement:  "Apache-Certified
Compliant
> to Web Profile Specifications" (or some such).
>

This doesnt mean anything to me like that. Being ASF implies ASF quality
and we cant claim anything Oracle related so Im lost with what you target
there.

We ll clearly not get any EE 7 compatibility on the site. Best we can do is
to list API/impl we have of EE 7.

Last point: your vote would have been very welcomed but now vote passed and
I strongly think we can discuss for 10 years without providing anything to
users so more time passes more I think we could use the date as version it
wouldnt be an issue but we have to release Final versions to stop holding
tomee from being considered by vendors and tools.

>
>
> --
> View this message in context:
http://tomee-openejb.979440.n4.nabble.com/7-0-0-release-vote-tp4678284.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: Websocket Client Bug....

[Romain Manni-Bucau]

Hi

This is more a tomcat issue - so should go on tomcat list. They worked on
such things lately in their test suite I tjink.

That said this send is synchronous so can be due to a read issue more than
a send issue one. Having an ack message is a workaround but maybe test with
multiple server instances too (client/server). Can also be link to timeout
or server.xml config on connectors.
Le 29 avr. 2016 00:49, "tonywestonuk"  a écrit :

> There appears to be a bug in Websocket Client
>
>
> I am getting "java.io.IOException: An existing connection was forcibly
> closed by the remote host". This appears to be when the websocket client is
> closed before all the information has been sent.
>
> Surely session.close should wait until everything has been sent?.
>
> I'm not actually sure how to fix this in code... maybe having the client
> send an 'end-of-data', then the server send an acknowlegement of the
> end-of-data, and only then close the socket?
>
> Butis this a workaround for a bug?
>
> At the moment, I am using https://github.com/TooTallNate/Java-WebSocket
> instead, which doesn't have this issue.  To reproduce: Create the following
> 2 classes,  then navigate to http://localhost:8080/  :
>
>
>
>
> WebsocketClient.java
>
> import java.io.IOException;
> import java.net.URI;
>
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> import javax.servlet.http.*;
> import javax.websocket.*;
> import javax.websocket.RemoteEndpoint.Basic;
>
> @WebServlet("/")
> public class WebsocketClient extends HttpServlet {
>
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse
> resp)
> throws ServletException, IOException {
>
>  try {
>
> Session session =
> ContainerProvider.getWebSocketContainer()
> .connectToServer(new MyEndpoint(),new
> URI("ws://localhost:8080/WebsocketClientBug/ws/testing"));
>
>
> Basic br = session.getBasicRemote();
> for (int i=0; i<100; i++){
> br.sendText("this is some random text");
> }
> session.close();
>
> } catch (Exception e) {e.printStackTrace();}
> }
>
>
> @ClientEndpoint
> public static class MyEndpoint{
> @OnError
> public void error(Throwable err){
> err.printStackTrace();
> }
> }
>
> }
>
>
>
>
> WebsocketServer.java
>
> import javax.websocket.OnMessage;
> import javax.websocket.Session;
> import javax.websocket.server.ServerEndpoint;
>
> @ServerEndpoint("/ws/testing")
> public class WebsocketServer {
>
> @OnMessage
> public void message(Session sess, String payload){
> try {
> Thread.sleep(10);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
>
> }
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Websocket-Client-Bug-tp4678282.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: [VOTE][LAZY] Next tomee release using 7.0.0 version

[Romain Manni-Bucau]

And here is my +1

with one -1 (binding) and 5 +1 bindings the vote passed.

updated http://tomee.apache.org/tomee-version-policies.html page to reflect
that. Feel free to enhance the page if anything is ambiguous or unclear for
you.

Thanks for your votes.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-04-27 22:48 GMT+02:00 Romain Manni-Bucau :

> Was not what I said. Said doc will be part of 7.0.0 delivery and therefore
> vote.
> Le 27 avr. 2016 22:43, "David Blevins"  a écrit :
>
>> I did vote.  -1 for 7.0.0 final being the first release with Tomcat 8.5.
>> And definite -1 to start voting before we have docs ready that describe
>> what state TomEE 7 is in.
>>
>> What I really would not want to see happen is that the documentation
>> effort of TomEE 7’s status be seen as a separate effort and “they” better
>> hurry up or “we” will eventually get impatient and click the publish button
>> without them.
>>
>> I’d love to see us approach that effort together and everyone chip in.  I
>> don’t think 72 hours is enough time to flush out all the materials we’d
>> like to create for a major release that will have some communication
>> challenges.
>>
>>
>> -David
>>
>>
>> > On Apr 26, 2016, at 2:42 PM, Romain Manni-Bucau 
>> wrote:
>> >
>> > @David: you didnt really vote. M4 is not an option of this thread,
>> putting
>> > the doc in vote with 7.0 is a good idea we should do IMO. If you want to
>> > participate to the vote please do or your opinion will not be part of
>> the
>> > result.
>> >
>> > Side note: if 7.0.0 is ok I'll try to gather what we need in a quick
>> thread
>> > before starting vote process.
>> > Le 26 avr. 2016 23:31, "David Blevins"  a
>> écrit :
>> >
>> >> My vote would be for an immediate M4 to flush out any issues with 7.0
>> >> while we work on the proper way to communicate the eventual 7.0 GA
>> status
>> >> and how-tos.
>> >>
>> >> I would be -1 for moving forward with 7.0 votes and letting “someone
>> else”
>> >> get the documentation in order out of fear there would be a “meh, you
>> >> didn’t keep up with me, ok out the door with 7.0 and no documentation.”
>> >>
>> >> I don’t think we could survive a miscommunication on this sensitive
>> topic
>> >> and would want to see it as top priority ahead of any 7.0 GA release.
>> >>
>> >>
>> >> --
>> >> David Blevins
>> >> http://twitter.com/dblevins
>> >> http://www.tomitribe.com
>> >>
>> >>> On Apr 25, 2016, at 5:01 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi guys,
>> >>>
>> >>> seems we'll reach a consensus soon on the fact we have to use 7.0 for
>> >> next
>> >>> release so trying to make the global topic moving forward ie the next
>> >> tomee
>> >>> release version.
>> >>>
>> >>> Using milestones doesn't reflect code state and has the following
>> >>> disadvantages:
>> >>>
>> >>> - we have no clue yet we'll sort soon oracle discussions
>> >>> - it prevents tooling and cloud integration (this thread is not about
>> >>> discussing it is for good reasons or bad)
>> >>> - milestones seems to impact some user/manager minds where it can be
>> more
>> >>> stable than some previous final releases, then also impacts us as a
>> >>> community since we don't reach the usage we should
>> >>> - we are stable since months, if we stop we can still change the
>> version
>> >>> later if desired but today we are
>> >>>
>> >>> To make it clear this is a VOTE by LAZY consensus to use 7.0.0 as next
>> >>> tomee release version.
>> >>>
>> >>> [+1] yes let's do it
>> >>> [ 0] what are you speaking about? meh don't care
>> >>> [-1] no cause ${reason} is a blocker
>> >>>
>> >>> Vote is open for 72 hours.
>> >>>
>> >>> Romain Manni-Bucau
>> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Github
>> >>> <https://github.com/rmannibucau> | LinkedIn
>> >>> <https://www.linkedin.com/in/rmannibucau> |  JavaEE Factory
>> >>> <https://javaeefactory-rmannibucau.rhcloud.com>
>> >>
>> >>
>>
>>

Re: [VOTE][LAZY] Next tomee release using 7.0.0 version

[Romain Manni-Bucau]

Was not what I said. Said doc will be part of 7.0.0 delivery and therefore
vote.
Le 27 avr. 2016 22:43, "David Blevins"  a écrit :

> I did vote.  -1 for 7.0.0 final being the first release with Tomcat 8.5.
> And definite -1 to start voting before we have docs ready that describe
> what state TomEE 7 is in.
>
> What I really would not want to see happen is that the documentation
> effort of TomEE 7’s status be seen as a separate effort and “they” better
> hurry up or “we” will eventually get impatient and click the publish button
> without them.
>
> I’d love to see us approach that effort together and everyone chip in.  I
> don’t think 72 hours is enough time to flush out all the materials we’d
> like to create for a major release that will have some communication
> challenges.
>
>
> -David
>
>
> > On Apr 26, 2016, at 2:42 PM, Romain Manni-Bucau 
> wrote:
> >
> > @David: you didnt really vote. M4 is not an option of this thread,
> putting
> > the doc in vote with 7.0 is a good idea we should do IMO. If you want to
> > participate to the vote please do or your opinion will not be part of the
> > result.
> >
> > Side note: if 7.0.0 is ok I'll try to gather what we need in a quick
> thread
> > before starting vote process.
> > Le 26 avr. 2016 23:31, "David Blevins"  a
> écrit :
> >
> >> My vote would be for an immediate M4 to flush out any issues with 7.0
> >> while we work on the proper way to communicate the eventual 7.0 GA
> status
> >> and how-tos.
> >>
> >> I would be -1 for moving forward with 7.0 votes and letting “someone
> else”
> >> get the documentation in order out of fear there would be a “meh, you
> >> didn’t keep up with me, ok out the door with 7.0 and no documentation.”
> >>
> >> I don’t think we could survive a miscommunication on this sensitive
> topic
> >> and would want to see it as top priority ahead of any 7.0 GA release.
> >>
> >>
> >> --
> >> David Blevins
> >> http://twitter.com/dblevins
> >> http://www.tomitribe.com
> >>
> >>> On Apr 25, 2016, at 5:01 AM, Romain Manni-Bucau  >
> >> wrote:
> >>>
> >>> Hi guys,
> >>>
> >>> seems we'll reach a consensus soon on the fact we have to use 7.0 for
> >> next
> >>> release so trying to make the global topic moving forward ie the next
> >> tomee
> >>> release version.
> >>>
> >>> Using milestones doesn't reflect code state and has the following
> >>> disadvantages:
> >>>
> >>> - we have no clue yet we'll sort soon oracle discussions
> >>> - it prevents tooling and cloud integration (this thread is not about
> >>> discussing it is for good reasons or bad)
> >>> - milestones seems to impact some user/manager minds where it can be
> more
> >>> stable than some previous final releases, then also impacts us as a
> >>> community since we don't reach the usage we should
> >>> - we are stable since months, if we stop we can still change the
> version
> >>> later if desired but today we are
> >>>
> >>> To make it clear this is a VOTE by LAZY consensus to use 7.0.0 as next
> >>> tomee release version.
> >>>
> >>> [+1] yes let's do it
> >>> [ 0] what are you speaking about? meh don't care
> >>> [-1] no cause ${reason} is a blocker
> >>>
> >>> Vote is open for 72 hours.
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Github
> >>> <https://github.com/rmannibucau> | LinkedIn
> >>> <https://www.linkedin.com/in/rmannibucau> |  JavaEE Factory
> >>> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >>
>
>

Re: [VOTE][LAZY] Next tomee release using 7.0.0 version

[Romain Manni-Bucau]

@David: you didnt really vote. M4 is not an option of this thread, putting
the doc in vote with 7.0 is a good idea we should do IMO. If you want to
participate to the vote please do or your opinion will not be part of the
result.

Side note: if 7.0.0 is ok I'll try to gather what we need in a quick thread
before starting vote process.
Le 26 avr. 2016 23:31, "David Blevins"  a écrit :

> My vote would be for an immediate M4 to flush out any issues with 7.0
> while we work on the proper way to communicate the eventual 7.0 GA status
> and how-tos.
>
> I would be -1 for moving forward with 7.0 votes and letting “someone else”
> get the documentation in order out of fear there would be a “meh, you
> didn’t keep up with me, ok out the door with 7.0 and no documentation.”
>
> I don’t think we could survive a miscommunication on this sensitive topic
> and would want to see it as top priority ahead of any 7.0 GA release.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Apr 25, 2016, at 5:01 AM, Romain Manni-Bucau 
> wrote:
> >
> > Hi guys,
> >
> > seems we'll reach a consensus soon on the fact we have to use 7.0 for
> next
> > release so trying to make the global topic moving forward ie the next
> tomee
> > release version.
> >
> > Using milestones doesn't reflect code state and has the following
> > disadvantages:
> >
> > - we have no clue yet we'll sort soon oracle discussions
> > - it prevents tooling and cloud integration (this thread is not about
> > discussing it is for good reasons or bad)
> > - milestones seems to impact some user/manager minds where it can be more
> > stable than some previous final releases, then also impacts us as a
> > community since we don't reach the usage we should
> > - we are stable since months, if we stop we can still change the version
> > later if desired but today we are
> >
> > To make it clear this is a VOTE by LAZY consensus to use 7.0.0 as next
> > tomee release version.
> >
> > [+1] yes let's do it
> > [ 0] what are you speaking about? meh don't care
> > [-1] no cause ${reason} is a blocker
> >
> > Vote is open for 72 hours.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> |  JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
>
>

Re: TomEE 7 and JPA 2.1

[Romain Manni-Bucau]

We had (have but see warning at the end) a hibernate profile to build a
tomee-hibernate. Was not activated by default cause of hibernate license
but should still be working.

The small warning is we probably need to upgrade hibernate versions as we
did for eclipselink (right only on master ATM but we'll release soon once
next version is validated).

Finally I'd go with the tomee maven plugin solution which can be as easy as:


  ...
  
   
 remove:openjpa
 unzip:com.jug.workshop:hibernate-bundle:1.0.0:zip
   
  


if you prepare a zip of hibernate dependencies to add to tomee/lib. TomEE
also has the equivalent in programmatic mode if you want to replace all of
that by code in a dependency.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-04-26 9:36 GMT+02:00 Yann BLAZART 
:

> Hello.
>
> Git clone the TomEE sources  then take a look how the TomEE distributions
> are built (plume by example).
>
> You can do the same thing in your own project / pom, excluding all jpa
> artifacts then adding hibernate ones.
>
> It's even simpler with TomEE embedded.
>
> Regards.
>
> -Original Message-
> From: Alex Soto [mailto:asot...@gmail.com]
> Sent: mardi 26 avril 2016 08:31
> To: dev@tomee.apache.org
> Subject: Re: TomEE 7 and JPA 2.1
>
> Hi Ivan what I would do will be droppng openjpa jars and add Hibernate
> since it is the solution that IMHO most of the people use.
>
> There is a doc in tomee website that explains it
>
> Alex
> El 26 abr. 2016 5:52 a. m., "Mitia Alexandrov" 
> escribió:
>
> > OpenJpa 2.1 is not ready. Use EclipseLink for JPA 2.1, its shipped
> > with latest Plume :)
> >
> > вт, 26 апр. 2016, 2:08 Ivan St. Ivanov :
> >
> > > Hi folks,
> > >
> > > We will be running a series of workshops in Bulgarian JUG to develop
> > > our new website. We'll be using Java EE 7 and TomEE 7. I know it is
> > > still milestone release and not fully EE 7 compatible. But we
> > > decided to take
> > the
> > > "risk".
> > >
> > > In the app we are using the new schema generation annotations coming
> > > with JPA 2.1, but they did not work. When I turned back to the old,
> > > implementation specific ones, it worked.
> > >
> > > Did I get it wrong that none of the WebProfile or PLUME
> > > distributions supports the JPA 2.1 spec? In the former I find
> > > OpenJPA 2.4.0, while in
> > the
> > > latter I see EclipseLink 2.4.2.
> > >
> > > Do you plan to provide JPA 2.1 support at least in the PLUME distro?
> > >
> > > Thanks,
> > > Ivan
> > >
> > > P.S. Roberto sent me a couple of weeks ago instructions how to
> > > integrate Hibernate JPA, but I would like to keep the configuration
> > > steps as few as possible as there will be a lot of people that will
> > > have to do them
> > during
> > > the workshop
> > >
> >
>
>
> This message and any attachments (the "message") is
> intended solely for the intended addressees and is confidential.
> If you receive this message in error,or are not the intended recipient(s),
> please delete it and any copies from your systems and immediately notify
> the sender. Any unauthorized view, use that does not comply with its
> purpose,
> dissemination or disclosure, either whole or partial, is prohibited. Since
> the internet
> cannot guarantee the integrity of this message which may not be reliable,
> BNP PARIBAS
> (and its subsidiaries) shall not be liable for the message if modified,
> changed or falsified.
> Do not print this message unless it is necessary,consider the environment.
>
>
> --
>
> Ce message et toutes les pieces jointes (ci-apres le "message")
> sont etablis a l'intention exclusive de ses destinataires et sont
> confidentiels.
> Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
> merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
> immediatement l'expediteur. Toute lecture non autorisee, toute utilisation
> de
> ce message qui n'est pas conforme a sa destination, toute diffusion ou
> toute
> publication, totale ou partielle, est interdite. L'Internet ne permettant
> pas d'assurer
> l'integrite de ce message electronique susceptible d'alteration, BNP
> Paribas
> (et ses filiales) decline(nt) toute responsabilite au titre de ce message
> dans l'hypothese
> ou il aurait ete modifie, deforme ou falsifie.
> N'imprimez ce message que si necessaire, pensez a l'environnement.
>

Re: TomEE 7 and JPA 2.1

[Romain Manni-Bucau]

Depending the dev workflow you will use, relying on maven plugins can be an
option which allows to customize plugins. They allow to add any jpa impl
pretty easily.
Le 26 avr. 2016 08:31, "Alex Soto"  a écrit :

> Hi Ivan what I would do will be droppng openjpa jars and add Hibernate
> since it is the solution that IMHO most of the people use.
>
> There is a doc in tomee website that explains it
>
> Alex
> El 26 abr. 2016 5:52 a. m., "Mitia Alexandrov" 
> escribió:
>
> > OpenJpa 2.1 is not ready. Use EclipseLink for JPA 2.1, its shipped with
> > latest Plume :)
> >
> > вт, 26 апр. 2016, 2:08 Ivan St. Ivanov :
> >
> > > Hi folks,
> > >
> > > We will be running a series of workshops in Bulgarian JUG to develop
> our
> > > new website. We'll be using Java EE 7 and TomEE 7. I know it is still
> > > milestone release and not fully EE 7 compatible. But we decided to take
> > the
> > > "risk".
> > >
> > > In the app we are using the new schema generation annotations coming
> with
> > > JPA 2.1, but they did not work. When I turned back to the old,
> > > implementation specific ones, it worked.
> > >
> > > Did I get it wrong that none of the WebProfile or PLUME distributions
> > > supports the JPA 2.1 spec? In the former I find OpenJPA 2.4.0, while in
> > the
> > > latter I see EclipseLink 2.4.2.
> > >
> > > Do you plan to provide JPA 2.1 support at least in the PLUME distro?
> > >
> > > Thanks,
> > > Ivan
> > >
> > > P.S. Roberto sent me a couple of weeks ago instructions how to
> integrate
> > > Hibernate JPA, but I would like to keep the configuration steps as few
> as
> > > possible as there will be a lot of people that will have to do them
> > during
> > > the workshop
> > >
> >
>

Re: [VOTE][LAZY] Next tomee release using 7.0.0 version

[Romain Manni-Bucau]

Hi Jon,

nothing more than the proposal "To make it clear this is a VOTE by LAZY
consensus to use 7.0.0 as next tomee release version." = starting a [VOTE]
Apache TomEE 7.0.0 following this vote.

"What is GA" - guess you mean more Final since GA just means available and
milestone are king of GA by definition? I think it is what the *project*
judges stable enough. I think it is very important for us to break this
insane dependency to Oracle we don't control and having delayed us of at
least 2 years. This means you can see the vote as "is master stable enough
to be released as Final and no more as milestone which supposes implicitly
no quality guarantee?".

Legally we can do Final (0.0) when we want certified or not (TomEE is an
autonomous ASF project).

If we get TCK and certified we can do a 8.0.0 if you want to "mark" it but
that's another topic we'll cover if relevant at that point.

Does it clarify the intent?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-04-25 14:28 GMT+02:00 Jonathan Gallimore :

> I'm not sure what I'm voting for and how this relates to the other thread
> "Next release 7.1".
>
> Is it both of the following?
>
> * No change in version numbering (i.e. continue with 7.0.0.M1, M2, M3, M4
> etc until we get to a 7.0.0 GA)
> * Include Tomcat 8.5 and later in the 7.0.x series with no separate fork
> for Tomcat 8.5 support
>
> If it is, I'd expect the next release to be a 7.0.0.M4, with Tomcat 8.5
> included.
>
> The next question is - what is GA? As we aligned with Java EE version
> numbering, I'd expect a 7.0.0.GA to be a JEE 7 certified released, at
> least
> for webprofile, and I think it needs to be very clearly communicated if
> that is not the case. Are their any legal implications of releasing a TomEE
> 7.0.0 GA that is not certified?
>
> Jon
>
> On Mon, Apr 25, 2016 at 1:01 PM, Romain Manni-Bucau  >
> wrote:
>
> > Hi guys,
> >
> > seems we'll reach a consensus soon on the fact we have to use 7.0 for
> next
> > release so trying to make the global topic moving forward ie the next
> tomee
> > release version.
> >
> > Using milestones doesn't reflect code state and has the following
> > disadvantages:
> >
> > - we have no clue yet we'll sort soon oracle discussions
> > - it prevents tooling and cloud integration (this thread is not about
> > discussing it is for good reasons or bad)
> > - milestones seems to impact some user/manager minds where it can be more
> > stable than some previous final releases, then also impacts us as a
> > community since we don't reach the usage we should
> > - we are stable since months, if we stop we can still change the version
> > later if desired but today we are
> >
> > To make it clear this is a VOTE by LAZY consensus to use 7.0.0 as next
> > tomee release version.
> >
> > [+1] yes let's do it
> > [ 0] what are you speaking about? meh don't care
> > [-1] no cause ${reason} is a blocker
> >
> > Vote is open for 72 hours.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> |  JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
>
>
>
> --
> Jonathan Gallimore
> http://twitter.com/jongallimore
> http://www.tomitribe.com
>

Re: Next release 7.1?

[Romain Manni-Bucau]

well we never said we'll align JavaEE 7 with TomEE 7 - made it clear in
http://tomee-openejb.979440.n4.nabble.com/Versioning-help-td4677842.html at
least and probably another thread - so it is milestone until we judged we
want a final.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-04-25 14:22 GMT+02:00 Andy Gumbrecht :

> I mean, it's still a milestone. So should just carry on the 7.0.0-Mx path.
> 7.1.0 can't really exist until 7.0.0 is released?
>
> http://www.tomitribe.com - @AndyGeeDe - On a small screen device.
> On 25 Apr 2016 13:47, "Jonathan Gallimore" 
> wrote:
>
> On Mon, Apr 25, 2016 at 10:20 AM, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
> > My 2 cts
> >
> > We have 3 milestones of the TomEE 7.0.0. People already using it are
> > expecting a final version, and I agree with that.
> >
>
> +1
>
> My personal opinion is that in seeing a jump to a 7.1.M1, people will look
> for a 7.0 GA, and be confused because its missing. I know I would be.
>
>
> >
> > Tomcat 8.5 already integrated to master brings an important feature
> HTTP/2
> > we want to have and offer to our users. Tomcat 8.5 is fully backward
> > compatible with Tomcat 8.x ( x < 5).
> >
>
> +1
>
>
> >
> > So I don't see any issue in having TomEE 7.0.0 final released on the
> master
> > and already integrating Tomcat 8.5.
> >
>
> + 1
>
>
> >
> > I understand Romain's point to reflect Tomcat jump in terms of version,
> but
> > having a TomEE 7.1.0 would appear weird if we don't have a TomEE 7.0.0.
> >
> > If we really want to follow Romain's point and reflect the Tomcat
> > versioning jump, I'd go with first a 7.0.0 based on the M3 with a couple
> of
> > bugfixes but with Tomcat 8.x (x < 5) and also a TomEE 7.1.0 with Tomcat
> 8.x
> > (x >= 5).
> >
> > So my view is
> >
> > Option 1/
> > TomEE 7.0.0 with Tomcat 8.x (x >= 5) with HTTP/2
> >
>
> I don't have any objection to that.
>
>
>
> >
> > *or*
> >
> > Option 2/
> > TomEE 7.0.0 with Tomcat 8.x (x < 5) without HTTP/2
> > +
> > TomEE 7.1.0 with Tomcat 8.x (x >= 5) with HTTP/2
> >
> >
> I think this is confusing - we already have the concept of "flavours"
> (webprofile, jaxrs, plus, plume) which determine what features are "in the
> box". Mixing in whether or not you get HTTP/2 in with the version number
> seems confusing to me.
>
> If Tomcat 8.5 is fully backwards compatible with previous Tomcat 8.x
> releases (and I note that JL says it is above), I see no reason for TomEE
> 7.0.0.M4 onwards to use that, and include HTTP/2 support.
>
> Jon
>
> --
> Jonathan Gallimore
> http://twitter.com/jongallimore
> http://www.tomitribe.com
>

[VOTE][LAZY] Next tomee release using 7.0.0 version

[Romain Manni-Bucau]

Hi guys,

seems we'll reach a consensus soon on the fact we have to use 7.0 for next
release so trying to make the global topic moving forward ie the next tomee
release version.

Using milestones doesn't reflect code state and has the following
disadvantages:

- we have no clue yet we'll sort soon oracle discussions
- it prevents tooling and cloud integration (this thread is not about
discussing it is for good reasons or bad)
- milestones seems to impact some user/manager minds where it can be more
stable than some previous final releases, then also impacts us as a
community since we don't reach the usage we should
- we are stable since months, if we stop we can still change the version
later if desired but today we are

To make it clear this is a VOTE by LAZY consensus to use 7.0.0 as next
tomee release version.

[+1] yes let's do it
[ 0] what are you speaking about? meh don't care
[-1] no cause ${reason} is a blocker

Vote is open for 72 hours.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> |  JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

Re: Next release 7.1?

[Romain Manni-Bucau]

Anyone against option 1?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-04-25 11:20 GMT+02:00 Jean-Louis Monteiro :

> My 2 cts
>
> We have 3 milestones of the TomEE 7.0.0. People already using it are
> expecting a final version, and I agree with that.
>
> Tomcat 8.5 already integrated to master brings an important feature HTTP/2
> we want to have and offer to our users. Tomcat 8.5 is fully backward
> compatible with Tomcat 8.x ( x < 5).
>
> So I don't see any issue in having TomEE 7.0.0 final released on the master
> and already integrating Tomcat 8.5.
>
> I understand Romain's point to reflect Tomcat jump in terms of version, but
> having a TomEE 7.1.0 would appear weird if we don't have a TomEE 7.0.0.
>
> If we really want to follow Romain's point and reflect the Tomcat
> versioning jump, I'd go with first a 7.0.0 based on the M3 with a couple of
> bugfixes but with Tomcat 8.x (x < 5) and also a TomEE 7.1.0 with Tomcat 8.x
> (x >= 5).
>
> So my view is
>
> Option 1/
> TomEE 7.0.0 with Tomcat 8.x (x >= 5) with HTTP/2
>
> *or*
>
> Option 2/
> TomEE 7.0.0 with Tomcat 8.x (x < 5) without HTTP/2
> +
> TomEE 7.1.0 with Tomcat 8.x (x >= 5) with HTTP/2
>
>
> *Side note*: we don't have any Java EE 7 TCK yet and I don't expect it to
> happen anytime soon.
> So even if not certified, I'd still go with a final release (non certified)
> of TomEE
>
> Jean-Louis
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Mon, Apr 25, 2016 at 11:02 AM, Martin Funk 
> wrote:
>
> > To my impression there are customers out there with an eye on TomEE to
> get
> > the JEE 7 certification.
> > And with the current version scheme they expect the TomEE 7.0 to be JEE 7
> > conform, so in
> > my believe they'd be surprised to see an TomEE 7.1 version before 7.0 is
> > JEE 7.
> > They'd expect it to be JEE 7 conforming before bumping up the minor
> version
> > number.
> >
> > Technically I think I understand the issue and I could explain, if I can
> > get into discussion with the customer.
> > The problem are the customers that you can't discuss with, that are
> scared
> > of before you get a chance to talk to them.
> >
> > mf
> >
> > 2016-04-25 10:12 GMT+02:00 Romain Manni-Bucau :
> >
> > > Le 25 avr. 2016 09:39, "Martin Funk"  a écrit :
> > > >
> > > > A user's opinion here.
> > > > Getting TomEE to be JEE 7 compliant is a big obstical whereever I go.
> > > > So releasing a 7.1 before 7.0 is JEE 7 compliant would lead to a big
> > need
> > > > of explenaiton.
> > > >
> > >
> > > What does miss in this thread as explanation? Trying to get how people
> > > percieve versions. They asked for our versioning page and now they ask
> us
> > > to not respect it I understand - so hopefully I miss something ;)
> > >
> > > > People I talk to will not touch TomEE before it is JEE 7 compliant.
> > > >
> > >
> > > That's not a blocker or do I miss anything?
> > >
> > > > mf
> > > >
> > > > 2016-04-25 4:00 GMT+02:00 John D. Ament :
> > > >
> > > > > On Sun, Apr 24, 2016 at 6:59 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Le 25 avr. 2016 00:36, "John D. Ament"  a
> > > écrit :
> > > > > > >
> > > > > > > It doesn't make sense to jump to a 7.1 immediately without even
> > > > > releasing
> > > > > > a
> > > > > > > 7.0.  Just confusing from a semantic versioning standpoint.
> > > > > >
> > > > > > Do you think releasing a version which changes structurally with
> > the
> > > same
> > > > > > minor is less confusing - was my fear ?
> > > > > >
> > > > >
> > > > > Maybe your fears aren't clear.  Granted I haven't tried tomcat 8.5.
> > > Are
> > > > > you saying that using Tomcat 8.5 causes TomEE to have a different
> > > direc

Re: Next release 7.1?

[Romain Manni-Bucau]

Le 25 avr. 2016 09:39, "Martin Funk"  a écrit :
>
> A user's opinion here.
> Getting TomEE to be JEE 7 compliant is a big obstical whereever I go.
> So releasing a 7.1 before 7.0 is JEE 7 compliant would lead to a big need
> of explenaiton.
>

What does miss in this thread as explanation? Trying to get how people
percieve versions. They asked for our versioning page and now they ask us
to not respect it I understand - so hopefully I miss something ;)

> People I talk to will not touch TomEE before it is JEE 7 compliant.
>

That's not a blocker or do I miss anything?

> mf
>
> 2016-04-25 4:00 GMT+02:00 John D. Ament :
>
> > On Sun, Apr 24, 2016 at 6:59 PM Romain Manni-Bucau <
rmannibu...@gmail.com>
> > wrote:
> >
> > > Le 25 avr. 2016 00:36, "John D. Ament"  a
écrit :
> > > >
> > > > It doesn't make sense to jump to a 7.1 immediately without even
> > releasing
> > > a
> > > > 7.0.  Just confusing from a semantic versioning standpoint.
> > >
> > > Do you think releasing a version which changes structurally with the
same
> > > minor is less confusing - was my fear ?
> > >
> >
> > Maybe your fears aren't clear.  Granted I haven't tried tomcat 8.5.  Are
> > you saying that using Tomcat 8.5 causes TomEE to have a different
directory
> > structure or something?  Or what structurally is the issue here? Its not
> > clear.
> >
> >
> > >
> > > >
> > > > Given the current status of the TCK & ASF, I wonder if waiting for
it
> > and
> > > > claiming EE 7 compatibility at a later date would make more sense.
So
> > > > maybe along what Dave's mentioning and favor a TomEE 2 that's
focused
> > on
> > > EE
> > > > 7 capabilities without stating that its EE7 compliant.
> > > >
> > >
> > > As mentionned 2.x would break tools - tomee ones which is ok but
several
> > > externals including maven/ivy (gradle) based ones so I'm against it
and
> > > prefer to confuse vs break.
> > >
> >
> > How does it break maven/ivy/gradle?
> >
> >
> > >
> > > About doing a 7.0 with master:  if everyone wants I m happy to
promote M3
> > > as final - we can disucss later if we backport or not things.
> > >
> > >
> > I think the part I don't understand is what benefit is there to release
> > TomEE ?? based on Tomcat 8.0 when 8.5 is coming out now.  Maybe the
bigger
> > question is does it make sense to release TomEE 7 based on Tomcat 8.5?
> >
> >
> > > If everyone wants just to move on 7.0 I'm also happy with it but
please
> > ack
> > > we delete all the minor part with NO replacement of the page
> > > http://tomee.apache.org/tomee-version-policies.html - we never
respects
> > > any
> > > mathematical logic for minors and cause of our stack I guess we'll
never
> > > do.
> > >
> > > Excepted Alex everyone feedback was 7.0.
> > >
> > > @Alex: wyt about it?
> > >
> > > Anyone feeling something else before we use that?
> > >
> > > > John
> > > >
> > > > On Sun, Apr 24, 2016 at 6:05 PM David Blevins <
david.blev...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > On hijacking, I think your single sentence communicated a lot
more in
> > > your
> > > > > head than was actually said :)  I beg your patience :)
> > > > >
> > > > > “Why not 7.0” or “What about 7.0” are fair questions.  But I see
your
> > > goal
> > > > > a little clearer — some way to get a TomEE version of Tomcat 8.5
out
> > > the
> > > > > door.
> > > > >
> > > > > Let’s get some feedback.
> > > > >
> > > > >
> > > > > --
> > > > > David Blevins
> > > > > http://twitter.com/dblevins
> > > > > http://www.tomitribe.com
> > > > >
> > > > > > On Apr 24, 2016, at 2:29 PM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > > We can do a 7.0 based on M3 and 7.1 (8.0 if you prefer) in the
same
> > > vote.
> > > > > >
> > > > > > Basically I want master released whatever TCK status is and
> > whatever
> > > > > > version it is while

Re: Next release 7.1?

[Romain Manni-Bucau]

Le 25 avr. 2016 04:01, "John D. Ament"  a écrit :
>
> On Sun, Apr 24, 2016 at 6:59 PM Romain Manni-Bucau 
> wrote:
>
> > Le 25 avr. 2016 00:36, "John D. Ament"  a écrit :
> > >
> > > It doesn't make sense to jump to a 7.1 immediately without even
releasing
> > a
> > > 7.0.  Just confusing from a semantic versioning standpoint.
> >
> > Do you think releasing a version which changes structurally with the
same
> > minor is less confusing - was my fear ?
> >
>
> Maybe your fears aren't clear.  Granted I haven't tried tomcat 8.5.  Are
> you saying that using Tomcat 8.5 causes TomEE to have a different
directory
> structure or something?  Or what structurally is the issue here? Its not
> clear.
>

8.5 changed few things bit introduced very big new features and new
configuration. Both should be reflected in a new minor if we respect our
versioning - once again personally I dont care bit need community ack
before moving fwd.

>
> >
> > >
> > > Given the current status of the TCK & ASF, I wonder if waiting for it
and
> > > claiming EE 7 compatibility at a later date would make more sense.  So
> > > maybe along what Dave's mentioning and favor a TomEE 2 that's focused
on
> > EE
> > > 7 capabilities without stating that its EE7 compliant.
> > >
> >
> > As mentionned 2.x would break tools - tomee ones which is ok but several
> > externals including maven/ivy (gradle) based ones so I'm against it and
> > prefer to confuse vs break.
> >
>
> How does it break maven/ivy/gradle?
>

Typically LATEST will not work anymore which is something enough to -1 any
vote.

>
> >
> > About doing a 7.0 with master:  if everyone wants I m happy to promote
M3
> > as final - we can disucss later if we backport or not things.
> >
> >
> I think the part I don't understand is what benefit is there to release
> TomEE ?? based on Tomcat 8.0 when 8.5 is coming out now.  Maybe the bigger
> question is does it make sense to release TomEE 7 based on Tomcat 8.5?
>
>
> > If everyone wants just to move on 7.0 I'm also happy with it but please
ack
> > we delete all the minor part with NO replacement of the page
> > http://tomee.apache.org/tomee-version-policies.html - we never respects
> > any
> > mathematical logic for minors and cause of our stack I guess we'll never
> > do.
> >
> > Excepted Alex everyone feedback was 7.0.
> >
> > @Alex: wyt about it?
> >
> > Anyone feeling something else before we use that?
> >
> > > John
> > >
> > > On Sun, Apr 24, 2016 at 6:05 PM David Blevins 
> > > wrote:
> > >
> > > > On hijacking, I think your single sentence communicated a lot more
in
> > your
> > > > head than was actually said :)  I beg your patience :)
> > > >
> > > > “Why not 7.0” or “What about 7.0” are fair questions.  But I see
your
> > goal
> > > > a little clearer — some way to get a TomEE version of Tomcat 8.5 out
> > the
> > > > door.
> > > >
> > > > Let’s get some feedback.
> > > >
> > > >
> > > > --
> > > > David Blevins
> > > > http://twitter.com/dblevins
> > > > http://www.tomitribe.com
> > > >
> > > > > On Apr 24, 2016, at 2:29 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > > We can do a 7.0 based on M3 and 7.1 (8.0 if you prefer) in the
same
> > vote.
> > > > >
> > > > > Basically I want master released whatever TCK status is and
whatever
> > > > > version it is while > 7.0 for toolings compliance ( 2.x and 3.x
are
> > no
> > > > more
> > > > > an  option IMO cause of that).
> > > > >
> > > > > Side note: speaking about 7.0 hijacks this thread which has as
only
> > > > topic:
> > > > > how to get tomee http2 support out this month or next one.
> > > > > Le 24 avr. 2016 23:23, "David Blevins"  a
> > > > écrit :
> > > > >
> > > > >> I see and agree on not surprising people around a Tomcat 8.0 ->
8.5
> > > > >> upgrade.
> > > > >>
> > > > >> I’m not seeing how discussing finishing 7.0 is highjacking.  I
think
> > > > >> people would find it quite confusing for us to move on to 7.1
> > without
> > >

Re: Next release 7.1?

[Romain Manni-Bucau]

Le 25 avr. 2016 00:36, "John D. Ament"  a écrit :
>
> It doesn't make sense to jump to a 7.1 immediately without even releasing
a
> 7.0.  Just confusing from a semantic versioning standpoint.

Do you think releasing a version which changes structurally with the same
minor is less confusing - was my fear ?

>
> Given the current status of the TCK & ASF, I wonder if waiting for it and
> claiming EE 7 compatibility at a later date would make more sense.  So
> maybe along what Dave's mentioning and favor a TomEE 2 that's focused on
EE
> 7 capabilities without stating that its EE7 compliant.
>

As mentionned 2.x would break tools - tomee ones which is ok but several
externals including maven/ivy (gradle) based ones so I'm against it and
prefer to confuse vs break.

About doing a 7.0 with master:  if everyone wants I m happy to promote M3
as final - we can disucss later if we backport or not things.

If everyone wants just to move on 7.0 I'm also happy with it but please ack
we delete all the minor part with NO replacement of the page
http://tomee.apache.org/tomee-version-policies.html - we never respects any
mathematical logic for minors and cause of our stack I guess we'll never do.

Excepted Alex everyone feedback was 7.0.

@Alex: wyt about it?

Anyone feeling something else before we use that?

> John
>
> On Sun, Apr 24, 2016 at 6:05 PM David Blevins 
> wrote:
>
> > On hijacking, I think your single sentence communicated a lot more in
your
> > head than was actually said :)  I beg your patience :)
> >
> > “Why not 7.0” or “What about 7.0” are fair questions.  But I see your
goal
> > a little clearer — some way to get a TomEE version of Tomcat 8.5 out the
> > door.
> >
> > Let’s get some feedback.
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> >
> > > On Apr 24, 2016, at 2:29 PM, Romain Manni-Bucau 
> > wrote:
> > >
> > > We can do a 7.0 based on M3 and 7.1 (8.0 if you prefer) in the same
vote.
> > >
> > > Basically I want master released whatever TCK status is and whatever
> > > version it is while > 7.0 for toolings compliance ( 2.x and 3.x are no
> > more
> > > an  option IMO cause of that).
> > >
> > > Side note: speaking about 7.0 hijacks this thread which has as only
> > topic:
> > > how to get tomee http2 support out this month or next one.
> > > Le 24 avr. 2016 23:23, "David Blevins"  a
> > écrit :
> > >
> > >> I see and agree on not surprising people around a Tomcat 8.0 -> 8.5
> > >> upgrade.
> > >>
> > >> I’m not seeing how discussing finishing 7.0 is highjacking.  I think
> > >> people would find it quite confusing for us to move on to 7.1 without
> > >> actually doing a GA of 7.0
> > >>
> > >>
> > >> -David
> > >>
> > >>
> > >>> On Apr 24, 2016, at 2:11 PM, Romain Manni-Bucau <
rmannibu...@gmail.com
> > >
> > >> wrote:
> > >>>
> > >>> We can release a 7.0 based on M3 but not master - I dont care much
for
> > >> this
> > >>> thread topic but feel free to open another thread on next 7.0.x if
you
> > >>> care/want. Master is on tomcat 8.5 since few weeks and I d like to
> > >> release
> > >>> it once this thread passed/is done - was planning to wait until
> > wednesday
> > >>> and few more feedbacks - but to not make this important upgrade
silent
> > >> and
> > >>> surprise users I d like to change the version more than a last
digit.
> > >>>
> > >>> Then coming topics are:
> > >>> - objection for a 7.1?
> > >>> - what do we maintain? 1.7/7.1 - not only for the palimdrom beauty
;)?
> > >>>
> > >>> (Please dont hijack this thread commenting on these coming ones,
just
> > >> tried
> > >>> to give a bit more visibility on the overall goal and why I asked
about
> > >> 7.x
> > >>> versioning now)
> > >>> Le 24 avr. 2016 23:04, "David Blevins"  a
> > >> écrit :
> > >>>
> > >>>> Good thread.
> > >>>>
> > >>>> Recap of my understanding:  we release 7.0 as-is and move forward
to
> > 7.1
> > >>>> based on Tomcat 8.5?
> > >>>>
> > >>>> I’d be +1 for that plan.
> > >>>>
> > >>>>
> > >>>> -David
> > >>>>
> > >>>>> On Apr 23, 2016, at 2:17 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > >>>
> > >>>> wrote:
> > >>>>>
> > >>>>> Hi guys
> > >>>>>
> > >>>>> Having tomcat 8.5 now I d like to move tomee to 7.1 to show coming
> > >>>> release
> > >>>>> is not just another 7.0.
> > >>>>>
> > >>>>> Any objection?
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >

Re: Next release 7.1?

[Romain Manni-Bucau]

We can do a 7.0 based on M3 and 7.1 (8.0 if you prefer) in the same vote.

Basically I want master released whatever TCK status is and whatever
version it is while > 7.0 for toolings compliance ( 2.x and 3.x are no more
an  option IMO cause of that).

Side note: speaking about 7.0 hijacks this thread which has as only topic:
how to get tomee http2 support out this month or next one.
Le 24 avr. 2016 23:23, "David Blevins"  a écrit :

> I see and agree on not surprising people around a Tomcat 8.0 -> 8.5
> upgrade.
>
> I’m not seeing how discussing finishing 7.0 is highjacking.  I think
> people would find it quite confusing for us to move on to 7.1 without
> actually doing a GA of 7.0
>
>
> -David
>
>
> > On Apr 24, 2016, at 2:11 PM, Romain Manni-Bucau 
> wrote:
> >
> > We can release a 7.0 based on M3 but not master - I dont care much for
> this
> > thread topic but feel free to open another thread on next 7.0.x if you
> > care/want. Master is on tomcat 8.5 since few weeks and I d like to
> release
> > it once this thread passed/is done - was planning to wait until wednesday
> > and few more feedbacks - but to not make this important upgrade silent
> and
> > surprise users I d like to change the version more than a last digit.
> >
> > Then coming topics are:
> > - objection for a 7.1?
> > - what do we maintain? 1.7/7.1 - not only for the palimdrom beauty ;)?
> >
> > (Please dont hijack this thread commenting on these coming ones, just
> tried
> > to give a bit more visibility on the overall goal and why I asked about
> 7.x
> > versioning now)
> > Le 24 avr. 2016 23:04, "David Blevins"  a
> écrit :
> >
> >> Good thread.
> >>
> >> Recap of my understanding:  we release 7.0 as-is and move forward to 7.1
> >> based on Tomcat 8.5?
> >>
> >> I’d be +1 for that plan.
> >>
> >>
> >> -David
> >>
> >>> On Apr 23, 2016, at 2:17 AM, Romain Manni-Bucau  >
> >> wrote:
> >>>
> >>> Hi guys
> >>>
> >>> Having tomcat 8.5 now I d like to move tomee to 7.1 to show coming
> >> release
> >>> is not just another 7.0.
> >>>
> >>> Any objection?
> >>
> >>
>
>

Re: Next release 7.1?

[Romain Manni-Bucau]

We can release a 7.0 based on M3 but not master - I dont care much for this
thread topic but feel free to open another thread on next 7.0.x if you
care/want. Master is on tomcat 8.5 since few weeks and I d like to release
it once this thread passed/is done - was planning to wait until wednesday
and few more feedbacks - but to not make this important upgrade silent and
surprise users I d like to change the version more than a last digit.

Then coming topics are:
- objection for a 7.1?
- what do we maintain? 1.7/7.1 - not only for the palimdrom beauty ;)?

(Please dont hijack this thread commenting on these coming ones, just tried
to give a bit more visibility on the overall goal and why I asked about 7.x
versioning now)
Le 24 avr. 2016 23:04, "David Blevins"  a écrit :

> Good thread.
>
> Recap of my understanding:  we release 7.0 as-is and move forward to 7.1
> based on Tomcat 8.5?
>
> I’d be +1 for that plan.
>
>
> -David
>
> > On Apr 23, 2016, at 2:17 AM, Romain Manni-Bucau 
> wrote:
> >
> > Hi guys
> >
> > Having tomcat 8.5 now I d like to move tomee to 7.1 to show coming
> release
> > is not just another 7.0.
> >
> > Any objection?
>
>

Next release 7.1?

[Romain Manni-Bucau]

Hi guys

Having tomcat 8.5 now I d like to move tomee to 7.1 to show coming release
is not just another 7.0.

Any objection?

Re: Release date expected for TomEE 7.0

[Romain Manni-Bucau]

Hi françois,

EE 7 compliant you mean? ASF is working with Oracle on that.

If you just need some master features anytime.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-04-22 17:31 GMT+02:00 COURTAULT Francois <
francois.courta...@gemalto.com>:

> Hello,
>
> When could we expect to get TomEE 7.0 final release ?
>
> Best Regards.
> 
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: Migrate weblogic to tomee

[Romain Manni-Bucau]

Hi Alvaro

Not AFAIK and it depends the application generation but if you come back
with issues we can surely help you to solve them quickly.
Le 21 avr. 2016 00:55, "Alvaro Delgado" 
a écrit :

> Hello I was wondering if already exist documentation/guide to can migrate
> an
> EAR web logic application to TomEE 1.7.X
>
> Very really appreciate your big help
>
> Basically the project structure is:
>
> EAR
>   ejb
>   web
>   ws
>
> Thanks in advance.
>
>
> Modules
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Migrate-weblogic-to-tomee-tp4678177.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: JDBC initial size documentation bug

[Romain Manni-Bucau]

Hi David,

yes, that's cause it is generated and one param missed some comments so the
generation misbehaved.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-04-18 11:22 GMT+02:00 Lakatos, David :

> Dear TomEE developer community,
>
> I may have found an error in the documentation here:
> http://tomee.apache.org/datasource-config.html#initialSize as of
> 4/18/2016.
> I think the parameters initialSize and defaultTransactionIsolation got
> mixed somehow. The problem exists in the table above as well.
>
> Q: Can someone confirm this for me?
>
> Thanks,
>
> David Lakatos
> IT Technology Consultant, Implementation Engineer, CS AM SAP Hungary
> SAP Hungary Kft., H-1031 Budapest, Záhony u. 1031, Budapest, Hungary
> (Central European Time)
>
> T +36 1 803 8261, M +36 20 522 1398, E david.laka...@sap.com
>
> Join me online: LinkedIn https://www.linkedin.com/in/davidlakatos
>
>
> Please consider the impact of the environment before printing this e-mail.
>
>
>

Re: reworking the website?

[Romain Manni-Bucau]

Hi Chris

Le 12 avr. 2016 02:33, "Chris Owens"  a
écrit :
>
> Speaking as a reasonably-well-informed user of TomEE, who has been into
the
> code, but who is still very much an outsider, I would say that
documentation
> is probably the biggest obstacle to wider uptake. It's a project I would
be
> happy to work on. I'm willing to put the work in to do some serious
writing.
>
> Before we talk about documentation workflow, git vs other models, CMSes,
> etc., I think there are some much more basic questions to address:
>
> -- Who is the intended audience for each major portion of the
documentation?
>

I d say people not able to go to code and in that category 2 subcategories:
admin and dev.

> -- For TomEE Components that are not owned by this project (e.g., Tomcat,
> cxf, JMS, etc.), how shall our documentation interact with that
component's
> "native" documentation? By reference? By duplication? Other?
>

Reference + enrichment when needed. Really against duplication.

> -- What are the major reference topics that need to be covered? (For
> example, Contexts, Classloaders, Configuration, Testing, Embedded, etc)?
>

Idea was to start with some basics and add info depending the list
questions.

> -- What are the major tutorial or "how-to" threads that need to be
covered?
>
>

Same there. Should also probably consider rework very hard examples to make
them useful and more explicit (arquillian website is a great example there).

>
>
>
> --
> View this message in context:
http://tomee-openejb.979440.n4.nabble.com/reworking-the-website-tp4677918p4678116.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: java.lang.NoSuchMethodError: javassist.util.proxy.ProxyFactory.isProxyClass(Ljava/lang/Class;)Z.

[Romain Manni-Bucau]

in your test do something like:

loader = Thread.currentThread().getContextClassLoader();
do {
System.out.println(loader);
loader = loader.getParent();
} while (loader != null);

It would allow to check if it is the normal tree or if you run in a
particular context which can be polluted by another javassist.

Also in the same method do:

System.out.println(ProxyFactory.class.getProtectionDomain().getCodeSource().getLocation())


Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber


2016-04-06 8:58 GMT+02:00 akshit :
> Hi Romain,
> As you have suggested, I checked maven dependency hierarchy using the
> command: 'mvn dependency:tree' and also have checked the pom Dependency
> Hierarchy in eclipse IDE. And I have found only javassist 3.15.0 GA version
> coming from openejb-core:4.5.1. Still I am facing the same error?
> In your reply I could not understand the meaning of class loader hierarchy.
> How can i check it?
> Any other suggestion will also be preferred..
> Thanks & Regards,
> Akshit Bhatia
>
>
>
> --
> View this message in context: 
> http://tomee-openejb.979440.n4.nabble.com/java-lang-NoSuchMethodError-javassist-util-proxy-ProxyFactory-isProxyClass-Ljava-lang-Class-Z-tp4678040p4678090.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: java.lang.NoSuchMethodError: javassist.util.proxy.ProxyFactory.isProxyClass(Ljava/lang/Class;)Z.

[Romain Manni-Bucau]

if you use maven check the dependency tree and the classloader
hierrchy for tests.

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber


2016-04-05 12:35 GMT+02:00 akshit :
> Hi Romain,
> I thank you for your previous reply.  As you previously stated that the
> exception means that there is a conflicting version of javassist, I have
> checked all the possibilities of different javassist version existing. As of
> now, there is only a single instance of javassist 3.15.0 GA and it is coming
> from openejb-core: 4.5.1. But still I am getting the same error. Please note
> that when I tried the execution after removing conflicting javassist, the
> project ran but only for two times. After that, the same exception is
> coming. And there is still only a single javassist version from openejb-core
> 4.5.1.
> Hoping for a solution.
>
> Thanks & Regards,
>
>
>
>
> --
> View this message in context: 
> http://tomee-openejb.979440.n4.nabble.com/java-lang-NoSuchMethodError-javassist-util-proxy-ProxyFactory-isProxyClass-Ljava-lang-Class-Z-tp4678040p4678085.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: reworking the website?

[Romain Manni-Bucau]

here it is 
https://github.com/rmannibucau/site-tomee-ng/blob/master/src/main/jbake/assets/css/cardio.css#L61,
feel free to play with it ;)

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber


2016-04-05 9:35 GMT+02:00 Alex Soto :
> The site is awesome, I would simply change the Apache TomEE Embedded or
> distributed to another typography/style, but well I am not a designer, not
> sure how to do it exactly.
>
> El dt., 5 abr. 2016 a les 8:55, Romain Manni-Bucau ()
> va escriure:
>
>> done
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>
>>
>> 2016-04-01 21:51 GMT+02:00 Romain Manni-Bucau :
>> > if noone objects I'll move the new website to /ng/ next week.
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>> >
>> >
>> > 2016-03-24 17:59 GMT+01:00 Romain Manni-Bucau :
>> >> up, would be great to have some feedback to know if we can move
>> >> forward, switching the website or exposing it as a subwebsite
>> >>
>> >> Romain Manni-Bucau
>> >> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>> >>
>> >>
>> >> 2016-03-21 21:51 GMT+01:00 Romain Manni-Bucau :
>> >>> Hi Rafael,
>> >>>
>> >>> that's interesting but still needs some manual writing ;). That said
>> >>> the organisation could be the file system one and
>> >>> http://tomee.apache.org/examples/ could be generated easily, good
>> >>> point.
>> >>>
>> >>> My main concern and why I thought starting manually was good was to
>> >>> avoid to just "cat" all sources in a page and expose it. This doesn't
>> >>> promote why the sample has been written so it is like not having it.
>> >>>
>> >>> Finally with javaeeX-samples (think the 8 is on his way) wonder if we
>> >>> shouldn't just merge our portable examples and only keep proprietary
>> >>> ones moving tests of other examples to our main tests.
>> >>>
>> >>> Any opinion on that points (rewriting them to make it obvious):
>> >>>
>> >>> - removing portable examples and ensuring they are in javaee-sample
>> >>> initiative without loosing in test coverage (if that's the case)
>> >>> - avoid to generate examples without documentation
>> >>> - reorganize the structure to match the category (we should surely
>> >>> rework it to have spec + proprietary features + tests + tools as
>> >>> subparts)
>> >>>
>> >>>
>> >>> Romain Manni-Bucau
>> >>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>> >>>
>> >>>
>> >>> 2016-03-21 21:38 GMT+01:00 Rafael Pestano :
>> >>>> Hi Romain,
>> >>>>
>> >>>> Nice work, just two ideas about how the examples could be generated:
>> >>>>
>> >>>> 1 - read from the tests as hibernate user guide is doing¹. Here is
>> the guide
>> >>>> <
>> https://github.com/hibernate/hibernate-orm/tree/master/documentation/src/main/asciidoc/userguide
>> >
>> >>>> and the tests
>> >>>> <
>> https://github.com/hibernate/hibernate-orm/tree/master/documentation/src/test/java/org/hibernate/userguide
>> >
>> >>>> .
>> >>>> 2 - read from a github repo and parse sources as javaee-support² is
>> doing.
>> >>>> Here are the sources <
>> https://github.com/javaee-samples/javaee7-samples>
>> >>>> and here
>> >>>> <
>> https://github.com/javaee-samples/javaee-samples.github.io/blob/develop/_ext/asciidocify.rb
>> >
>> >>>> is how they are parsed.
>> >>>>
>> >>>>
>> >>>> [1] http://hibernate.org/validator/documentation/getting-started/
>> >>>> [2] http://javaee.support/
>> >>>>
>> >>>>
>> >>>> 2016-03-21 13:54 GMT-03:00 Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>:
>> >>>>
>> >>>>> I'll have a deeper look tonight Romain.
>> >>>>> Thanks for putting more content in there. Might be useful to see how
>> it
>> >>>>> renders.
>> >>>>>
>

Re: reworking the website?

[Romain Manni-Bucau]

done

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber


2016-04-01 21:51 GMT+02:00 Romain Manni-Bucau :
> if noone objects I'll move the new website to /ng/ next week.
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>
>
> 2016-03-24 17:59 GMT+01:00 Romain Manni-Bucau :
>> up, would be great to have some feedback to know if we can move
>> forward, switching the website or exposing it as a subwebsite
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>
>>
>> 2016-03-21 21:51 GMT+01:00 Romain Manni-Bucau :
>>> Hi Rafael,
>>>
>>> that's interesting but still needs some manual writing ;). That said
>>> the organisation could be the file system one and
>>> http://tomee.apache.org/examples/ could be generated easily, good
>>> point.
>>>
>>> My main concern and why I thought starting manually was good was to
>>> avoid to just "cat" all sources in a page and expose it. This doesn't
>>> promote why the sample has been written so it is like not having it.
>>>
>>> Finally with javaeeX-samples (think the 8 is on his way) wonder if we
>>> shouldn't just merge our portable examples and only keep proprietary
>>> ones moving tests of other examples to our main tests.
>>>
>>> Any opinion on that points (rewriting them to make it obvious):
>>>
>>> - removing portable examples and ensuring they are in javaee-sample
>>> initiative without loosing in test coverage (if that's the case)
>>> - avoid to generate examples without documentation
>>> - reorganize the structure to match the category (we should surely
>>> rework it to have spec + proprietary features + tests + tools as
>>> subparts)
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>>
>>>
>>> 2016-03-21 21:38 GMT+01:00 Rafael Pestano :
>>>> Hi Romain,
>>>>
>>>> Nice work, just two ideas about how the examples could be generated:
>>>>
>>>> 1 - read from the tests as hibernate user guide is doing¹. Here is the 
>>>> guide
>>>> <https://github.com/hibernate/hibernate-orm/tree/master/documentation/src/main/asciidoc/userguide>
>>>> and the tests
>>>> <https://github.com/hibernate/hibernate-orm/tree/master/documentation/src/test/java/org/hibernate/userguide>
>>>> .
>>>> 2 - read from a github repo and parse sources as javaee-support² is doing.
>>>> Here are the sources <https://github.com/javaee-samples/javaee7-samples>
>>>> and here
>>>> <https://github.com/javaee-samples/javaee-samples.github.io/blob/develop/_ext/asciidocify.rb>
>>>> is how they are parsed.
>>>>
>>>>
>>>> [1] http://hibernate.org/validator/documentation/getting-started/
>>>> [2] http://javaee.support/
>>>>
>>>>
>>>> 2016-03-21 13:54 GMT-03:00 Jean-Louis Monteiro :
>>>>
>>>>> I'll have a deeper look tonight Romain.
>>>>> Thanks for putting more content in there. Might be useful to see how it
>>>>> renders.
>>>>>
>>>>> --
>>>>> Jean-Louis Monteiro
>>>>> http://twitter.com/jlouismonteiro
>>>>> http://www.tomitribe.com
>>>>>
>>>>> On Mon, Mar 21, 2016 at 1:38 PM, Romain Manni-Bucau >>>> >
>>>>> wrote:
>>>>>
>>>>> > Hi guys,
>>>>> >
>>>>> > pushed some more content and GUI fixes. What about deploying it live
>>>>> > on tomee.apache.org/site-ng/?
>>>>> >
>>>>> > Main missing part ATM is the example page but not sure how to tackle
>>>>> > it. Think it should be a manual task cause anything generated either
>>>>> > doesn't render well or doesn't serve the end users very well in term
>>>>> > of content. Can try to start hacking few of them or if anyone wants to
>>>>> > join the website hacking he is very welcomed.
>>>>> >
>>>>> >
>>>>> > Romain Manni-Bucau
>>>>> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>>>> >
>>>>> >
>>>>> > 2016-03-17 19:57 GMT+01:00 Romain Manni-Bucau :
>>>>> > > Tri

Re: Document resolved vulnerability CVE-2015-8581

[Romain Manni-Bucau]

Hi

We got 2016 number, not sure where 2015 one comes from but didnt go through
security process - or was before we tackled it? any other pmc saw it?

If didnt went through security@ no reason to mention it.
Le 4 avr. 2016 22:57, "Robert Panzer"  a écrit :

> Hi,
>
> the TomEE docs currently document CVE-2016-0779 as resolved in TomEE 1.7.4
> and 7.0.0-M3.
> This seems to be a duplicate of CVE-2015-8581.
>
> Therefore this vulnerability should also be documented as resolved.
>
> I opened a ticket and attached a patch that adds a mention of
> CVE-2015-8581 next to CVE-2016-0779.
>
> Would be nice if somebody could review it.
>
> Cheers
> Robert

Re: reworking the website?

[Romain Manni-Bucau]

if noone objects I'll move the new website to /ng/ next week.

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber


2016-03-24 17:59 GMT+01:00 Romain Manni-Bucau :
> up, would be great to have some feedback to know if we can move
> forward, switching the website or exposing it as a subwebsite
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>
>
> 2016-03-21 21:51 GMT+01:00 Romain Manni-Bucau :
>> Hi Rafael,
>>
>> that's interesting but still needs some manual writing ;). That said
>> the organisation could be the file system one and
>> http://tomee.apache.org/examples/ could be generated easily, good
>> point.
>>
>> My main concern and why I thought starting manually was good was to
>> avoid to just "cat" all sources in a page and expose it. This doesn't
>> promote why the sample has been written so it is like not having it.
>>
>> Finally with javaeeX-samples (think the 8 is on his way) wonder if we
>> shouldn't just merge our portable examples and only keep proprietary
>> ones moving tests of other examples to our main tests.
>>
>> Any opinion on that points (rewriting them to make it obvious):
>>
>> - removing portable examples and ensuring they are in javaee-sample
>> initiative without loosing in test coverage (if that's the case)
>> - avoid to generate examples without documentation
>> - reorganize the structure to match the category (we should surely
>> rework it to have spec + proprietary features + tests + tools as
>> subparts)
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>
>>
>> 2016-03-21 21:38 GMT+01:00 Rafael Pestano :
>>> Hi Romain,
>>>
>>> Nice work, just two ideas about how the examples could be generated:
>>>
>>> 1 - read from the tests as hibernate user guide is doing¹. Here is the guide
>>> <https://github.com/hibernate/hibernate-orm/tree/master/documentation/src/main/asciidoc/userguide>
>>> and the tests
>>> <https://github.com/hibernate/hibernate-orm/tree/master/documentation/src/test/java/org/hibernate/userguide>
>>> .
>>> 2 - read from a github repo and parse sources as javaee-support² is doing.
>>> Here are the sources <https://github.com/javaee-samples/javaee7-samples>
>>> and here
>>> <https://github.com/javaee-samples/javaee-samples.github.io/blob/develop/_ext/asciidocify.rb>
>>> is how they are parsed.
>>>
>>>
>>> [1] http://hibernate.org/validator/documentation/getting-started/
>>> [2] http://javaee.support/
>>>
>>>
>>> 2016-03-21 13:54 GMT-03:00 Jean-Louis Monteiro :
>>>
>>>> I'll have a deeper look tonight Romain.
>>>> Thanks for putting more content in there. Might be useful to see how it
>>>> renders.
>>>>
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>>
>>>> On Mon, Mar 21, 2016 at 1:38 PM, Romain Manni-Bucau >>> >
>>>> wrote:
>>>>
>>>> > Hi guys,
>>>> >
>>>> > pushed some more content and GUI fixes. What about deploying it live
>>>> > on tomee.apache.org/site-ng/?
>>>> >
>>>> > Main missing part ATM is the example page but not sure how to tackle
>>>> > it. Think it should be a manual task cause anything generated either
>>>> > doesn't render well or doesn't serve the end users very well in term
>>>> > of content. Can try to start hacking few of them or if anyone wants to
>>>> > join the website hacking he is very welcomed.
>>>> >
>>>> >
>>>> > Romain Manni-Bucau
>>>> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>>> >
>>>> >
>>>> > 2016-03-17 19:57 GMT+01:00 Romain Manni-Bucau :
>>>> > > Tried to push current state/idea to avoid you to have to build it
>>>> > > locally: http://home.apache.org/~rmannibucau/tomeeng/#
>>>> > >
>>>> > > Romain Manni-Bucau
>>>> > > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>>> > >
>>>> > >
>>>> > > 2016-03-17 11:57 GMT+01:00 Robert Panzer :
>>>> > >> Hi,
>>>> > >>
>>>> > >> even though n

Re: java.lang.NoSuchMethodError: javassist.util.proxy.ProxyFactory.isProxyClass(Ljava/lang/Class;)Z.

[Romain Manni-Bucau]

Hi Akshit,

OpenEJB 3.0 didn't have javassist and this mbean wrapper so I guess
you either have mixed versions or not use OpenEJB 3. Then the
exception simply means javassist is there is a conflicting version.

Side note: as OpenEJB 3 doesn't have javassist, OpenEJB 4.7 or 7.x
don't rely anymore on javassist at all.

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber


2016-04-01 6:33 GMT+02:00 akshit :
> Hi,
> In my project I am testing a method of EJB using a JUnit class. So to obtain
> the reference and create a local environment I used openEJB 3.0. And for
> using it, I create a java class where I have set properties related to
> openEJB connection. I have also registered an aspect in aop.xml and have
> added the project, containing aop.xml, in the build path. Kindly find the
> stack trace below. Especially what is the meaning of error:
> NoSuchMethodError:  java.lang.NoSuchMethodError:
> javassist.util.proxy.ProxyFactory.isProxyClass(Ljava/lang/Class;)Z;
>
> Kindly find an attached stack trace I am getting while running my test case.
> openEJB_exception_isproxy.txt
> <http://tomee-openejb.979440.n4.nabble.com/file/n4678040/openEJB_exception_isproxy.txt>
>
> Any idea about the error will be appreciated.
> Thanks in advance.
> Akshit Bhatia
>
>
>
> --
> View this message in context: 
> http://tomee-openejb.979440.n4.nabble.com/java-lang-NoSuchMethodError-javassist-util-proxy-ProxyFactory-isProxyClass-Ljava-lang-Class-Z-tp4678040.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: Performing Java EE resource injections dynamically

[Romain Manni-Bucau]

Do you use a custome classloader? If so try to override equals/hascode to
simulate webapp one
Le 31 mars 2016 06:43, "Dimitri"  a écrit :

> Hi,
>
> In Tomee 7.0.0-M3, I've tried to use JavaeeInstanceManager and
> DefaultInstanceManager to instantiate dynamically loaded class. (To
> obtain the first, I used InstanceManagerFactory; for the second I've
> copied the code from your recent commit and used ContainerServlet to
> obtain parent StandardContext.)
>
> Excerpt from servlet:
>
> StandardContext webapp = (StandardContext) wrapper.getParent();
> DefaultInstanceManager defaultIM = new DefaultInstanceManager(
> webapp.getNamingContextListener().getEnvContext(),
> TomcatInjections.buildInjectionMap(webapp.getNamingResources()),
> webapp,
> ParentClassLoaderFinder.Helper.get());
>
> InstanceManager javaeeIM =
> InstanceManagerFactory.getInstanceManager(getServletConfig());
>
> Object foo = null, bar = null;
>
> try {
>
> URLClassLoader ucl = new URLClassLoader(
> new URL[]{new URL("file:///home/mitya/.../classes/")}, //
> here resides external class "my.Foo"
> this.getClass().getClassLoader() // otherwise
> ClassNotFoundException on UserTransaction, EntityManager etc.
> );
>
> foo = javaeeIM.newInstance("my.Foo", ucl);
> bar = defaultIM.newInstance("my.Foo", ucl);
>
> } catch (IllegalAccessException | InvocationTargetException |
> NamingException | InstantiationException | ClassNotFoundException ex) {
> LOG.log(Level.SEVERE, null, ex);
> }
>
> Foo.java:
>
> public class Foo {
>
> private static final Logger LOG =
> Logger.getLogger(Foo.class.getName());
>
> @Resource(name = "foo")
> private Integer foo;
>
> @Resource
> private UserTransaction tx;
>
> @PersistenceContext
> private EntityManager em;
>
> @PostConstruct
> public void post() {
> LOG.info("Foo::post");
> LOG.info("foo = " + foo);
> LOG.info("em  = " + em);
> LOG.info("tx  = " + tx);
> }
>
> }
>
> With JavaeeInstanceManager, everything works perfect, but *only* if the
> my.Foo class is present in classpath at application startup. If loaded
> from external location, injections are not processed (nulls
> everywhere).
>
> With DefaultInstanceManager, I get the following for every injected
> field:
>
> javax.naming.NameNotFoundException: Name [my.Foo/tx] is not bound in this
> Context. Unable to find [my.Foo].
>
> Does this all work as intended? Can I do anything about it?
>
> Regards,
> Dimitri
>
>

Re: Fwd: [jira] [Resolved] (TOMEE-1762) Add a timeout to DataSource shutdown

[Romain Manni-Bucau]

well idea was to not have it by default (in particular no medium
duration timeout which can break apps flushing at that moment) so
wouldn't break anything since a choice. We can go further and activate
it by resource with another virtual property if desired but
datasources are not particular there. When I did it I was thinking to
AMQ as well where it can be useful.

Only issue I see is creating a thread which can leak by design but
while it is for diagnostic it is fine I guess. We can (should?) wire
it to an event (ResourceDestructionTimeoutEvent? do we want the
creation one?) to be able to plug an alert in such a case.

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber


2016-03-30 22:30 GMT+02:00 Andy :
> Sure, just took the smallest step to solve the known issue but did think
> that the whole resource destroy block could work the same way - Just was not
> sure if 'all' the resource destroy methods could be called safely from a
> thread.
>
>
> On 30/03/2016 00:37, Romain Manni-Bucau wrote:
>>
>> Master got https://issues.apache.org/jira/browse/TOMEE-1761
>>
>> Do we want to merge it with 1.7.x instead of using another config?
>> -- Message transféré --
>> De : "Andy Gumbrecht (JIRA)" 
>> Date : 30 mars 2016 00:29
>> Objet : [jira] [Resolved] (TOMEE-1762) Add a timeout to DataSource
>> shutdown
>> À : 
>> Cc :
>>
>>
>>   [
>>
>> https://issues.apache.org/jira/browse/TOMEE-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Andy Gumbrecht resolved TOMEE-1762.
>> ---
>>  Resolution: Fixed
>>
>> Added system property to TomEE 1.7.5-SNAPSHOT -
>> tomee.datasource.destroy.timeout.ms
>> The default if not specified is 1000
>> Min: 50
>> Max: 3
>>
>>> Add a timeout to DataSource shutdown
>>> 
>>>
>>>  Key: TOMEE-1762
>>>  URL: https://issues.apache.org/jira/browse/TOMEE-1762
>>>  Project: TomEE
>>>   Issue Type: Improvement
>>> Affects Versions: 1.7.4
>>> Reporter: Andy Gumbrecht
>>> Assignee: Andy Gumbrecht
>>> Priority: Minor
>>>  Fix For: 1.7.5
>>>
>>>Original Estimate: 2h
>>>   Remaining Estimate: 2h
>>>
>>> Add a timeout governed by the system property '
>>
>> tomee.datasource.destroy.timeout.ms' that indicates how long a DataSource
>> destroy call will wait for the actual termination.
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.4#6332)
>>
>
> --
>   Andy Gumbrecht
>   https://twitter.com/AndyGeeDe
>

Re: Performing Java EE resource injections dynamically

[Romain Manni-Bucau]

True, we are based on a static analysis at startup so we likely miss
JSP - means if you use it somewhere else it should work. Fixed in
https://issues.apache.org/jira/browse/TOMEE-1764

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber


2016-03-30 1:52 GMT+02:00 Dimitri :
>
>> In the case of resources.xml-defined entry, I didn't manage to
>> resolve it even through JNDI manually.
>
> Sorry, I was wrong, it is resolvable as "openejb:Resource/XXX" in JNDI. But 
> still no way to use @Resource annotation.
>
> Dimitri
>

Re: Performing Java EE resource injections dynamically

[Romain Manni-Bucau]

jspInit() sounds better than PostConstruct. UserTransaction can use @Inject
by spec if Im not mistaken so issues are for entity manager and resources.
Here no portable solution but easy to generate at build tume producers for
them. A simpe Mojo/Ant task/gradle plugin would enable it in few lines of
code and in a portable manner.
Le 30 mars 2016 00:02, "Dimitri"  a écrit :

> > (that's
> > why hot reloading is a good bad idea and can break after a restart
> > even if "F5" tests were green ;)).
>
> Oh yeah, I've got obscure errors after hot reloading hundreds of times.
> Most of them were JNDI-related, by the way ;)
>
> > Hmm, maybe not. JSP support injections and are generated at runtime
> > so
> > it needs some glue code but reusing the same principle would work and
> > this API even if internal is more stable (see InstanceManager of
> > tomcat).
>
> That's it - JSPs came to my mind even before the idea of generating
> annotated classes. Needless to say I did some testing...
>
> === 8< ===
> <%@page import="javax.enterprise.inject.spi.BeanManager"%>
> <%@page import="javax.inject.Inject"%>
> <%@page import="java.util.logging.Logger"%>
> <%@page import="javax.transaction.UserTransaction"%>
> <%@page import="javax.annotation.Resource"%>
> <%@page import="javax.annotation.PostConstruct"%>
>
> <%@page contentType="text/html" pageEncoding="UTF-8"%>
>
> <%!
> @Resource
> private UserTransaction tx;
>
> @Inject
> private BeanManager bm;
>
> private final static Logger LOG = Logger.getLogger("foo.jsp");
>
> @PostConstruct
> public void post() {
> LOG.info("foo.jsp::post()");
> LOG.info("tx = " + tx);
> LOG.info("bm = " + bm);
> }
> %>
>
> <%
> request.setAttribute("tx", tx);
> request.setAttribute("bm", bm);
> %>
>
> 
> 
> 
> 
> JSP Page
> 
> 
> tx = ${requestScope.tx}
> bm = ${requestScope.bm}
> 
> 
> === 8< ===
>
> The results were, errr, a bit disappointing.
>
> TomEE 7.0.0-M3
> ==
> tx = null
> bm = org.apache.webbeans.container.InjectableBeanManager@b4ecb2
> @PostConstruct: invoked
>
> WildFly 10.0.0
> ==
> tx = null
> bm = null
> @PostConstruct: not invoked
>
> GlassFish/Payara 4.1.1
> ==
> bm = (had to remove BeanManager since JSP didn't compile)
> tx = null
> @PostConstruct: not invoked
>
> Is it another blind-spot in the spec? or is it a bug? or am I doing it
> totally wrong?
>
> Dimitri
>

Fwd: [jira] [Resolved] (TOMEE-1762) Add a timeout to DataSource shutdown

[Romain Manni-Bucau]

Master got https://issues.apache.org/jira/browse/TOMEE-1761

Do we want to merge it with 1.7.x instead of using another config?
-- Message transféré --
De : "Andy Gumbrecht (JIRA)" 
Date : 30 mars 2016 00:29
Objet : [jira] [Resolved] (TOMEE-1762) Add a timeout to DataSource shutdown
À : 
Cc :


 [
https://issues.apache.org/jira/browse/TOMEE-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Gumbrecht resolved TOMEE-1762.
---
Resolution: Fixed

Added system property to TomEE 1.7.5-SNAPSHOT -
tomee.datasource.destroy.timeout.ms
The default if not specified is 1000
Min: 50
Max: 3

> Add a timeout to DataSource shutdown
> 
>
> Key: TOMEE-1762
> URL: https://issues.apache.org/jira/browse/TOMEE-1762
> Project: TomEE
>  Issue Type: Improvement
>Affects Versions: 1.7.4
>Reporter: Andy Gumbrecht
>Assignee: Andy Gumbrecht
>Priority: Minor
> Fix For: 1.7.5
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Add a timeout governed by the system property '
tomee.datasource.destroy.timeout.ms' that indicates how long a DataSource
destroy call will wait for the actual termination.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Performing Java EE resource injections dynamically

[Romain Manni-Bucau]

2016-03-29 20:53 GMT+02:00 Dimitri :
> Hi,
>
>> > Does it mean that if I somehow manage to (dynamically) plant the
>> > necessary entries to a JNDI tree, everything would work like in
>> > WildFly? (InjectionTarget is what's used under the hood in
>> > Unmanaged)
>> >
>> if JNDI is the JNDI tree of Comp bean (a kinf of EJB with its own
>> JNDI
>> tree which is a merge of all trees to make it simple) yes
>
> Sounds cool, but how do I obtain an instance to plant? For example,
> after parsing a script (at runtime!) I know that it requires a
> @PersistenceContext with particular name, as well as some @Resource's
> (probably also named), some @EJB's and some @WebServiceRef's. Is there
> a "magic" method in OpenEJB that I can call this way: "okay, my newly-
> loaded component needs this EE stuff, please instantiate it all for me
> (or return reference if already instantiated)"?
>

You can rely on deep internals but I wouldn't recommand it.

Side note: it breaks by design JavaEE since you have passed the
startup which validates as much as possible the application and any
runtime change later on can surprisingly break the application (that's
why hot reloading is a good bad idea and can break after a restart
even if "F5" tests were green ;)).

> Of course I could write my own handlers for each annotation type like
> this:
> - in case of @Resource -> look in JNDI
> - in case of @EJB -> the same
> - in case of @PersistenceContext/@PersistenceUnit -> instantiate (how
> exactly?)

there are in global JNDI tree under a name you can find browsing the
internal tree (but same note: this is not portable and we can break it
without any notice if we need).

> - in case of @WebServiceRef -> ???
>

This one is easier since it is a plain webservice client, only
container config can be missing since it is not on the annotation.

> But I would like to avoid it, since all of it is already implemented in
> OpenEJB either way.
>
>> >
>> Well babel is trivial to run - at least in version 5:
>> https://github.com/rmannibucau/ohmyjs
>
> Looks really cool - didn't know running Babel on Nashorn would be that
> easy! It opens new horizons for me :) In fact, I wouldn't say I'm 100%
> happy with ES5. Nashorn was chosen as a first candidate because of its
> maturity, performance & support from Oracle; but nothing would prevent
> from using any JSR-223 compliant engine.
>

Nashorn is not that fast to be honest - even if good enough generally.
It still interprets a lot of relies on thread locals which can easily
breaks any app, in particular starting to use reactive patterns of
just EJB @Asynchronous :s - check GlobalContext ;).

>>
>> Now I thought to that cause that's what give a language a java
>> developer will not reject immediately I think. es5 is still not
>> tempting for a java developer cause of the scope plus adding
>> injections in comments is another reason to not accept this I think.
>
> Neither am I 100% happy with injections-in-comments. I was also
> thinking about external (XML/JSON) metadata that would come in pair
> with a script. E.g., a script itself could come in foo.js, and its
> metadata in foo.{xml|json|etc.} The latter would contain
> summary/description, imports, dependencies etc. - all the same, but in
> a structured format.
>
> I was examining ES7 decorators, too. Yes, they could be mapped to Java-
> style annotations; the problem is, decorators are applied to JS
> classes/methods/properties only. This will force users to
> unconditionally wrap their JavaScript code in a class, which seems
> reduntant to me. After all, there are a lot of methods to supply script
> metadata, with JSDoc-style annotations being just a first try.
>
>> 1. convert the js to java - just in term of EE contract
>>
>> ex:
>>
>> /**
>> @import org.apache.commons.configuration.Configuration
>> @import java.util.logging.Level
>>
>> @Startup(order = 1)
>> @Inject Configuration config
>> */
>>
>> $LOG.log(Level.INFO, "Starting MyApplication {0} b{1}", [
>> config.getString("myapp.version"),
>> config.getString("myapp.build")
>> ]);
>>
>> would be
>>
>> public class MyJsEnv {
>>   @Inject Configuration config;
>>   // all injections even @Resource, @PersistenceContext etc
>> }
>>
>> 2. I would have impl-ed a websocket endpoint getting MyJsEnv injected
>> and mapping client operations to server operations
>
> This is very similar to what I've tried in the very beginning. Problem
> is, in TomEE this works only statically, meaning that MyJsEnv should be
> available at application deployment (pre-generated, compiled and
> bundled in a WAR). If I generate/load such a class in runtime, EE
> injections won't be processed (contrary to WildFly, which in this case
> correctly processes both @Inject and @Resource/@EJB/@Persistence* etc).

Hmm, maybe not. JSP support injections and are generated at runtime so
it needs some glue code but reusing the same principle would work and
this API even if internal is more stable (see InstanceMa

Re: Performing Java EE resource injections dynamically

[Romain Manni-Bucau]

2016-03-29 14:32 GMT+02:00 Dimitri :
> Hi Romain,
>
>> CDI injections are created - more validated actually - at startup and dont
>> rely on JNDI at all. EE injections rely on JNDI and are linked to CDI
>> through a particular bean (Comp) representing the whole webapp JNDI tree.
>>
>> In term of code an InjectionTarget should work but needs to be there at
>> startup.
>
> Does it mean that if I somehow manage to (dynamically) plant the
> necessary entries to a JNDI tree, everything would work like in
> WildFly? (InjectionTarget is what's used under the hood in Unmanaged)
>

if JNDI is the JNDI tree of Comp bean (a kinf of EJB with its own JNDI
tree which is a merge of all trees to make it simple) yes

>> That said: why not using es6 and or purescript/typescript to get real
>> imports and potentially annotations/decorators and just convert it to java
>
> Did you mean "to JavaScript"? That would involve heavy-weight machinery
> like Babel/Traceur that requires Node.js, and running Node code in
> Nashorn is a non-trivial task (though I know the guy who currently
> works on that). It's an interesting challenge, but I think I'd better
> start with a simpler (ad-hoc) prototype.
>

Well babel is trivial to run - at least in version 5:
https://github.com/rmannibucau/ohmyjs

Now I thought to that cause that's what give a language a java
developer will not reject immediately I think. es5 is still not
tempting for a java developer cause of the scope plus adding
injections in comments is another reason to not accept this I think.
That said it is your choice and I can be totally wrong on that, no
issue ;).

>> and then wire it through websocket? Sounds like a simple and safe impl to
>> me to do that.
>
> Sorry, can't understand how it would solve a problem of dynamic EE
> injections. Could you please elaborate?

Here is the (lazy?) workflow I would have implemented if I would have
had it to do:

1. convert the js to java - just in term of EE contract

ex:

/**
@import org.apache.commons.configuration.Configuration
@import java.util.logging.Level

@Startup(order = 1)
@Inject Configuration config
*/

$LOG.log(Level.INFO, "Starting MyApplication {0} b{1}", [
config.getString("myapp.version"),
config.getString("myapp.build")
]);

would be

public class MyJsEnv {
  @Inject Configuration config;
  // all injections even @Resource, @PersistenceContext etc
}

2. I would have impl-ed a websocket endpoint getting MyJsEnv injected
and mapping client operations to server operations

This is actually pretty close to angularbeans:
http://bessemhmidi.github.io/AngularBeans/ but without the need to
recreate a server side API


This is for remoting - maybe not what you want to achieve.

A common alternative for 100% server usage is to simply name beans and
use them as bindings in the script engine. With the BeanManager it is
pretty easy to implement a Binding to do so (something like
https://github.com/apache/tomee/blob/120a33c7b4de07ae01c17978ea37d88a911ea860/container/openejb-core/src/main/java/org/apache/openejb/util/OpenEJBScripter.java#L104
but more integrate to JSR 223)

>
> Thx! Dimitri
>
>> Le 29 mars 2016 01:48, "Dimitri"  a écrit :
>>
>> >
>> > Sorry for broken links. Shouldn't have used line wrapping in my mail
>> > client.
>> >
>> > Project write-up:
>> > https://gist.github.com/dteleguin/c93fe4a4c666234729d8
>> >
>> > StackOverflow thread:
>> >
>> > http://stackoverflow.com/questions/36239250/injecting-java-ee-resources-into-dynamically-loaded-classes
>> >

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in TomEE

[Romain Manni-Bucau]

2016-03-29 8:48 GMT+02:00 Arjan Tijms :
> Hi,
>
> On Mon, Mar 28, 2016 at 11:53 PM, Romain Manni-Bucau [via TomEE & OpenEJB] <
> ml-node+s979440n4677979...@n4.nabble.com> wrote
>>
>> Issue is mixing some specs. Typically jsf for dispatch-cdi which relies on
>> jsf double stack which is unspecified -
>
>
> Sorry, what is a "jsf double stack" exactly?
>

Going twice in the JSF stack in a single request - not sure there is a name ;)

> Do you mean the include of a JSF resource by a SAM? E.g. this test:
>
> https://github.com/javaee-samples/javaee7-samples/blob/master/jaspic/dispatching-jsf-cdi/src/test/java/org/javaee7/jaspictest/dispatching/JSFCDIIncludeTest.java
>

Yes

>
>> fixed on master -
>
>
> Do you mean fixed in this commit?
> https://github.com/rmannibucau/javaee7-samples/commit/301118feaad47996345a5778a5022c3e427e1e7c
>

No was tomee master for this one;). MyFaces will get the fix too but
it is not really specified AFAIK

Also pushed to my branch fixes for angularjs sample which now runs
too, this one was hibernate specific for JPA layer, not portable on
JAXRS layer and frontend tests were not working for me cause htmlunit
doesn't support enough js + the modal was not correctly interpreted
for it.

>
>
>> so sometimes a
>> failure is not linked to the central feature of the sample :(.
>>
>> >
>> >
>> > On Mon, Mar 28, 2016 at 4:26 PM, Romain Manni-Bucau [via TomEE &
>> OpenEJB]
>> <
>>
>> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=4677979&i=1>>
>> wrote:
>> >
>> > > pushed my work on https://github.com/rmannibucau/javaee7-samples.
>> > > Several samples should pass and doesnt yet. Didn't check why but can
>> > > just be a pom setup issue, implementation hypothesis (like hardcoding
>> > > a h2/hibernate usage ;)) or something like that (typically a lot of
>> > > websocket tests are failing but we should pass them without hacking
>> > > tomee).
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>> > >
>> > >
>> > > 2016-03-28 10:56 GMT+02:00 Romain Manni-Bucau <[hidden email]
>> > > <http:///user/SendEmail.jtp?type=node&node=4677977&i=0>>:
>> > >
>> > > >
>> > > > Le 28 mars 2016 04:44, "Arjan Tijms" <[hidden email]
>> > > <http:///user/SendEmail.jtp?type=node&node=4677977&i=1>> a écrit :
>> > > >>
>> > > >> On Sun, Mar 27, 2016 at 11:33 AM, Romain Manni-Bucau [via TomEE &
>> > > OpenEJB]
>> > > >> <
>> > > >> [hidden email] > /user/SendEmail.jtp?type=node&node=4677977&i=2>>
>>
>> > > wrote:
>> > > >>
>> > > >> > Normally master is deployed each night but sometimes it doesnt
>> work
>> > > so
>> > > >> > should be.
>> > > >> >
>> > > >>
>> > > >> Ok, thanks!
>> > > >>
>> > > >>
>> > > >> >
>> > > >> > Ran some ee samples but some of them are not portable or rely too
>> > > much
>> > > >> > on
>> > > >> > proprietary features. Will try to push my tomee branch next week.
>> > > >> >
>> > > >>
>> > > >> The JASPIC tests from the Java EE 7 samples project should be as
>> > > portable
>> > > >> as one can get. Some servers insist on activating JASPIC (Liberty,
>> > > JBoss),
>> > > >> or having proprietary group to role mapping in place (almost all
>> > > servers
>> > > >> except JBoss).
>> > > >>
>> > > >> Or did you mean general EE samples from that project and not just
>> the
>> > > >> JASPIC ones? If so, a PR to make them more portable and remove
>> reliance
>> > > on
>> > > >> proprietary features would be appreciated ;)
>> > > >>
>> > > >
>> > > > Both by side effects mainly. Wait 1-2 days and i ll push once my
>> review
>>
>> > > > done;)
>> > > >
>> > > >
>> > > >>
>> > > >> >
>> > > >> > >
>> > > >> > >
>> > > >> > 

Re: Performing Java EE resource injections dynamically

[Romain Manni-Bucau]

Hi Dimitri

CDI injections are created - more validated actually - at startup and dont
rely on JNDI at all. EE injections rely on JNDI and are linked to CDI
through a particular bean (Comp) representing the whole webapp JNDI tree.

In term of code an InjectionTarget should work but needs to be there at
startup.

That said: why not using es6 and or purescript/typescript to get real
imports and potentially annotations/decorators and just convert it to java
and then wire it through websocket? Sounds like a simple and safe impl to
me to do that.
Le 29 mars 2016 01:48, "Dimitri"  a écrit :

> Sorry for broken links. Shouldn't have used line wrapping in my mail
> client.
>
> Project write-up:
> https://gist.github.com/dteleguin/c93fe4a4c666234729d8
>
> StackOverflow thread:
>
> http://stackoverflow.com/questions/36239250/injecting-java-ee-resources-into-dynamically-loaded-classes
>

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in TomEE

[Romain Manni-Bucau]

Le 29 mars 2016 00:09, "Arjan Tijms"  a écrit :
>
> Thanks for starting this.
>
> jaxrs/angularjs/src/main/resources/META-INF/persistence.xml is for sure
> wrong in the original.  "java:jboss/datasources/ExampleDS" is obviously
not
> portable.
>
> All JPA based tests use the Java EE 7 default data source, which is
> generally good enough. In some cases where @DataSourceDefinition is used
an
> embedded h2 or other DB is used (but in a portable way, not relying on
> anything privately  provided by the server)
>
> JASPIC tests should be mostly portable (taking the mandated setup
mentioned
> above into account), but let me know if you find anything there.
>

Issue is mixing some specs. Typically jsf for dispatch-cdi which relies on
jsf double stack which is unspecified - fixed on master - so sometimes a
failure is not linked to the central feature of the sample :(.

>
>
> On Mon, Mar 28, 2016 at 4:26 PM, Romain Manni-Bucau [via TomEE & OpenEJB]
<
> ml-node+s979440n4677977...@n4.nabble.com> wrote:
>
> > pushed my work on https://github.com/rmannibucau/javaee7-samples.
> > Several samples should pass and doesnt yet. Didn't check why but can
> > just be a pom setup issue, implementation hypothesis (like hardcoding
> > a h2/hibernate usage ;)) or something like that (typically a lot of
> > websocket tests are failing but we should pass them without hacking
> > tomee).
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >
> >
> > 2016-03-28 10:56 GMT+02:00 Romain Manni-Bucau <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4677977&i=0>>:
> >
> > >
> > > Le 28 mars 2016 04:44, "Arjan Tijms" <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4677977&i=1>> a écrit :
> > >>
> > >> On Sun, Mar 27, 2016 at 11:33 AM, Romain Manni-Bucau [via TomEE &
> > OpenEJB]
> > >> <
> > >> [hidden email] >
> > wrote:
> > >>
> > >> > Normally master is deployed each night but sometimes it doesnt work
> > so
> > >> > should be.
> > >> >
> > >>
> > >> Ok, thanks!
> > >>
> > >>
> > >> >
> > >> > Ran some ee samples but some of them are not portable or rely too
> > much
> > >> > on
> > >> > proprietary features. Will try to push my tomee branch next week.
> > >> >
> > >>
> > >> The JASPIC tests from the Java EE 7 samples project should be as
> > portable
> > >> as one can get. Some servers insist on activating JASPIC (Liberty,
> > JBoss),
> > >> or having proprietary group to role mapping in place (almost all
> > servers
> > >> except JBoss).
> > >>
> > >> Or did you mean general EE samples from that project and not just the
> > >> JASPIC ones? If so, a PR to make them more portable and remove
reliance
> > on
> > >> proprietary features would be appreciated ;)
> > >>
> > >
> > > Both by side effects mainly. Wait 1-2 days and i ll push once my
review
> > > done;)
> > >
> > >
> > >>
> > >> >
> > >> > >
> > >> > >
> > >> > > On Fri, Mar 25, 2016 at 2:45 PM, Romain Manni-Bucau [via TomEE &
> > >> > OpenEJB]
> > >> > <
> > >> >
> > >> > > [hidden email]
> > >> > > <http:///user/SendEmail.jtp?type=node&node=4677974&i=1>>
> > >> > wrote:
> > >> > >
> > >> > > > Hi
> > >> > > >
> > >> > > > answering there even if a bit old but google find this thread
so
> > >> > > > trying to keep threads consistent...
> > >> > > >
> > >> > > > TomEE master is on Tomcat 8.5.x so inherits from Jaspic now.
> > >> > > >
> > >> > > > Romain Manni-Bucau
> > >> > > > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> > >> > > >
> > >> > > >
> > >> > > > 2013-09-03 5:11 GMT+02:00 Anthony Fryer <[hidden email]
> > >> > > > <http:///user/SendEmail.jtp?type=node&node=4677971&i=0>>:
> > >> > > >
> > >> > > > > I was looking for exactly this functionality 2 we

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in TomEE

[Romain Manni-Bucau]

pushed my work on https://github.com/rmannibucau/javaee7-samples.
Several samples should pass and doesnt yet. Didn't check why but can
just be a pom setup issue, implementation hypothesis (like hardcoding
a h2/hibernate usage ;)) or something like that (typically a lot of
websocket tests are failing but we should pass them without hacking
tomee).

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber


2016-03-28 10:56 GMT+02:00 Romain Manni-Bucau :
>
> Le 28 mars 2016 04:44, "Arjan Tijms"  a écrit :
>>
>> On Sun, Mar 27, 2016 at 11:33 AM, Romain Manni-Bucau [via TomEE & OpenEJB]
>> <
>> ml-node+s979440n4677974...@n4.nabble.com> wrote:
>>
>> > Normally master is deployed each night but sometimes it doesnt work so
>> > should be.
>> >
>>
>> Ok, thanks!
>>
>>
>> >
>> > Ran some ee samples but some of them are not portable or rely too much
>> > on
>> > proprietary features. Will try to push my tomee branch next week.
>> >
>>
>> The JASPIC tests from the Java EE 7 samples project should be as portable
>> as one can get. Some servers insist on activating JASPIC (Liberty, JBoss),
>> or having proprietary group to role mapping in place (almost all servers
>> except JBoss).
>>
>> Or did you mean general EE samples from that project and not just the
>> JASPIC ones? If so, a PR to make them more portable and remove reliance on
>> proprietary features would be appreciated ;)
>>
>
> Both by side effects mainly. Wait 1-2 days and i ll push once my review
> done;)
>
>
>>
>> >
>> > >
>> > >
>> > > On Fri, Mar 25, 2016 at 2:45 PM, Romain Manni-Bucau [via TomEE &
>> > OpenEJB]
>> > <
>> >
>> > > [hidden email]
>> > > <http:///user/SendEmail.jtp?type=node&node=4677974&i=1>>
>> > wrote:
>> > >
>> > > > Hi
>> > > >
>> > > > answering there even if a bit old but google find this thread so
>> > > > trying to keep threads consistent...
>> > > >
>> > > > TomEE master is on Tomcat 8.5.x so inherits from Jaspic now.
>> > > >
>> > > > Romain Manni-Bucau
>> > > > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>> > > >
>> > > >
>> > > > 2013-09-03 5:11 GMT+02:00 Anthony Fryer <[hidden email]
>> > > > <http:///user/SendEmail.jtp?type=node&node=4677971&i=0>>:
>> > > >
>> > > > > I was looking for exactly this functionality 2 weeks ago to use
>> > > > > with
>> > > > TomEE.
>> > > > > I ended up having to write a tomcat AuthenticatorValve and a
>> > > > > custom
>> > > > Realm
>> > > > > class to implement the same thing you've done with your standard
>> > JASPIC
>> > > > > implementation (using SocialAuth as you have done).  It would be
>> > great
>> > > > to
>> > > > > have this, especially for the Social Authentication scenario.  Any
>> > > > situation
>> > > > > where you want to access the HttpServletRequest and
>> > HttpServletResponse
>> > > > to
>> > > > > perform redirects and callbacks in the authentication "work flow"
>> > would
>> > > > > benefit from this.
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > View this message in context:
>> > > >
>> >
>> >
>> > http://openejb.979440.n4.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-TomEE-tp4660480p4664957.html
>> > > > > Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>> > > >
>> > > >
>> > > > --
>> > > > If you reply to this email, your message will be added to the
>> > discussion
>> > > > below:
>> > > >
>> > > >
>> >
>> >
>> > http://tomee-openejb.979440.n4.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-TomEE-tp4660480p4677971.html
>> > > > To unsubscribe from Consider support for the Servlet profile of JSR
>> > 196
>> > > > (JASPIC) in TomEE, click here
>> > > >

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in TomEE

[Romain Manni-Bucau]

Le 28 mars 2016 04:44, "Arjan Tijms"  a écrit :
>
> On Sun, Mar 27, 2016 at 11:33 AM, Romain Manni-Bucau [via TomEE &
OpenEJB] <
> ml-node+s979440n4677974...@n4.nabble.com> wrote:
>
> > Normally master is deployed each night but sometimes it doesnt work so
> > should be.
> >
>
> Ok, thanks!
>
>
> >
> > Ran some ee samples but some of them are not portable or rely too much
on
> > proprietary features. Will try to push my tomee branch next week.
> >
>
> The JASPIC tests from the Java EE 7 samples project should be as portable
> as one can get. Some servers insist on activating JASPIC (Liberty, JBoss),
> or having proprietary group to role mapping in place (almost all servers
> except JBoss).
>
> Or did you mean general EE samples from that project and not just the
> JASPIC ones? If so, a PR to make them more portable and remove reliance on
> proprietary features would be appreciated ;)
>

Both by side effects mainly. Wait 1-2 days and i ll push once my review
done;)
>
> >
> > >
> > >
> > > On Fri, Mar 25, 2016 at 2:45 PM, Romain Manni-Bucau [via TomEE &
> > OpenEJB]
> > <
> >
> > > [hidden email] >
> > wrote:
> > >
> > > > Hi
> > > >
> > > > answering there even if a bit old but google find this thread so
> > > > trying to keep threads consistent...
> > > >
> > > > TomEE master is on Tomcat 8.5.x so inherits from Jaspic now.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> > > >
> > > >
> > > > 2013-09-03 5:11 GMT+02:00 Anthony Fryer <[hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4677971&i=0>>:
> > > >
> > > > > I was looking for exactly this functionality 2 weeks ago to use
with
> > > > TomEE.
> > > > > I ended up having to write a tomcat AuthenticatorValve and a
custom
> > > > Realm
> > > > > class to implement the same thing you've done with your standard
> > JASPIC
> > > > > implementation (using SocialAuth as you have done).  It would be
> > great
> > > > to
> > > > > have this, especially for the Social Authentication scenario.  Any
> > > > situation
> > > > > where you want to access the HttpServletRequest and
> > HttpServletResponse
> > > > to
> > > > > perform redirects and callbacks in the authentication "work flow"
> > would
> > > > > benefit from this.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > >
> >
> >
http://openejb.979440.n4.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-TomEE-tp4660480p4664957.html
> > > > > Sent from the OpenEJB Dev mailing list archive at Nabble.com.
> > > >
> > > >
> > > > --
> > > > If you reply to this email, your message will be added to the
> > discussion
> > > > below:
> > > >
> > > >
> >
> >
http://tomee-openejb.979440.n4.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-TomEE-tp4660480p4677971.html
> > > > To unsubscribe from Consider support for the Servlet profile of JSR
> > 196
> > > > (JASPIC) in TomEE, click here
> > > > <
> >
> > > > .
> > > > NAML
> > > > <
> >
> >
http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> >
> >
http://tomee-openejb.979440.n4.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-TomEE-tp4660480p4677972.html
> > > Sent from the TomEE Dev mailing list archive at Nabble.com.
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
http://tomee-openejb.979440.n4.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-TomEE-tp4660480p4677974.html
> > To unsubscribe from Consider support for the Servlet profile of JSR 196
> > (JASPIC) in TomEE, click here
> > <
http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4660480&code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ2NjA0ODB8LTM3MzU5NTg0OA==
>
> > .
> > NAML
> > <
http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
>
> >
>
>
>
>
> --
> View this message in context:
http://tomee-openejb.979440.n4.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-TomEE-tp4660480p4677975.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.