date:20181004

Re: Connector issues

2018-10-04 Thread Jean-Louis Monteiro

Great note Jon.
Thanks it's appreciated

+1

Le jeu. 4 oct. 2018 à 12:01, Romain Manni-Bucau  a
écrit :

> +1 looks good
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 4 oct. 2018 à 11:59, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> a écrit :
>
> > I have pushed some commits onto the PR here:
> > https://github.com/apache/tomee/pull/174, and would appreciate some
> > review.
> > One the things I found was that if I hold onto a reference to the proxy
> for
> > the transaction, it doesn't get cleaned up, but then losing the reference
> > from the scope at the end of the transaction also didn't clean things up.
> > What was actually going on was:
> >
> > 
> > connection = cf.createConnection();
> >
> > // forget to close it
> >
> > connection2 = cf.createConnection(); // different proxy, but same
> > ManagedConnectionInfo as the TransactionCachingInterceptor provides the
> > same connection
> > connection2.close(); // this removed the ManagedConnectionInfo from the
> > references field on AutoConnectionTracker, so it was no longer tracked
> for
> > cleanup.
> > 
> >
> > The transaction then completed, and connection dropped from scope, but
> > because the ManagedConnectionInfo associated with it wasn't in the
> > references list anymore, it never got cleaned up.
> >
> > To make matters worse, TransactionCachingInterceptor sees that the
> > ManagedConnectionInfo has open handles and refuses to send it back to the
> > pool. The effect is the connections leaked and never went back to the
> pool.
> >
> > So, my latest changes:
> >
> > * Keep a proxy for as long as the transaction runs
> > * Checks the reference list and cleans up at the end
> > * Checks the ManagedConnectionInfo object, and if there are open handles,
> > destroys the connection.
> > * Additionally, if OpenEJB.connector is set to log at FINEST, it should
> > reveal where any unclosed connections are originally opened, to provide
> the
> > developer with a hint on how to fix them.
> >
> > I'll add some tests this afternoon, but any thoughts would be much
> > appreciated.
> >
> > Jon
> >
> >
> > On Fri, Sep 28, 2018 at 3:18 PM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> > > I was thinking the same - do it through the registry. Let me have a go
> at
> > > hacking on that and I'll post back here. Many thanks for the feedback.
> > >
> > > Jon
> > >
> > > On Fri, Sep 28, 2018 at 3:15 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > >> that is what I had in mind, throught it was already the case to be
> > honest
> > >> through the transaction registry - excess of enthusiasm probably ;)
> > >>
> > >> Side note: dropped G for now, if we find something impacting g-txmgr
> > we'll
> > >> add it back
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau  |  Blog
> > >>  | Old Blog
> > >>  | Github <
> > >> https://github.com/rmannibucau> |
> > >> LinkedIn  | Book
> > >> <
> > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >> >
> > >>
> > >>
> > >> Le ven. 28 sept. 2018 à 16:11, Jonathan Gallimore <
> > >> jonathan.gallim...@gmail.com> a écrit :
> > >>
> > >> > I apologize, I CC'd Geronimo in case there was anything relevant on
> > the
> > >> > Geronimo connector side. Happy to drop the CC if its not relevant.
> > >> >
> > >> > Thanks for the quick response!
> > >> >
> > >> > Off the top of my head, I wonder if we could keep a reference to the
> > >> > connection proxy in the transaction (if there is one), and remove
> the
> > >> > reference when the transaction is complete?
> > >> >
> > >> > Jon
> > >> >
> > >> > On Fri, Sep 28, 2018 at 2:57 PM Romain Manni-Bucau <
> > >> rmannibu...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Hi Jon,
> > >> > >
> > >> > > I experienced that kind of "surprise" in recent jvm since gc is
> way
> > >> more
> > >> > > aggressive - cause lambda are way more memory consuming ;). This
> > lead
> > >> to
> > >> > > this kind of issue where the GC happens before the object should
> > >> actually
> > >> > > be finalizable.
> > >> > > I suspect we need to rework the AutoConnectionTracker to take into
> > >> > account
> > >> > > these new behaviors and actually take into consideration the
> > >> lifecycle of
> > >> > > the underlying connection.
> > >> > >
> > >> > > Maybe I got it wrong but I see the ability to disable the proxying
> > as
> > >> a
> > >> > > quickfix/workaround - which is ok - but it means we need to fix
> the
> > >> > source
> > >> > > anyway as a lon

Re: TomEE 8 Release Preview

2018-10-04 Thread Roberto Cortez

I understand. Was just trying to give more detail into it.

I’ll have a better look and try to come up with some test scenarios.

> On 4 Oct 2018, at 10:47, Romain Manni-Bucau  wrote:
> 
> Le jeu. 4 oct. 2018 à 11:42, Roberto Cortez  > a
> écrit :
> 
>> Hi Romain,
>> 
>> Well the exception being thrown is not the actual exception.
>> 
>> This was only happening in the MP binary due to the OpenAPI Geronimo
>> implementation. In the DefaultLoader the ServletContext is injected, but at
>> the time that the JAX-RS app is deployed, which is in the
>> AfterApplicationCreated event, the ServletContextHandler does not have a
>> Context anymore so it throws a IllegalStateException("Didnt find a web
>> context for " + contextClassLoader). The caller for this is the
>> setApplication of the OpenAPIFilter when we try to inject it, so that
>> causes the exception we see in the logs.
>> 
>> We never say this in Arquillian testing, because Arquillian waits for the
>> server to start and then deploys the app. This means we are able to get a
>> ServletContext from the request in ServletContextHandler, so it works fine.
>> 
>> I believe this is also related with the fix you did here:
>> https://issues.apache.org/jira/browse/TOMEE-1687 <
>> https://issues.apache.org/jira/browse/TOMEE-1687>
>> 
>> What do you think?
>> 
> 
> Can be but at the end the two issues are mentionned are not covered:
> 
> 1. a regression will silently come back
> 2. for ears we can leak the servlet context if we end up here (and then the
> app will wrongly behave)
> 
> My point is not to revert what you did but more to ensure it fixes the
> issue in our build.
> 
> 
>> 
>> Cheers,
>> Roberto
>> 
>>> On 4 Oct 2018, at 08:23, Romain Manni-Bucau 
>> wrote:
>>> 
>>> @Roberto: do we have a test to reproduce and prevent future regressions?
>> If
>>> your fix is right the error message is quite unexpected so it would be
>>> better to ensure we don't break it unintentionnally (a side note is that
>>> setting a single webapp context and firing an event for all webapps can
>>> have the same pitfall so it can need to be reworked to ensure we don't
>> hit
>>> it for ears to not leak context between webapp which would be another
>> nasty
>>> bug).
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
>>> Le jeu. 4 oct. 2018 à 01:43, Roberto Cortez 
>> a
>>> écrit :
>>> 
 Hi Cesar,
 
 I think I’ve found the issue. Just pushed a fix and now waiting to the
 build bot to check if everything is ok. I’ll let you know when it is
>> done.
 
 Cheers,
 Roberto
 
> On 3 Oct 2018, at 22:50, Roberto Cortez 
 wrote:
> 
> 
> Not sure. Let me have a look.On Wednesday, October 3, 2018, 8:56:13
 PM GMT+1, César Hernández Mendoza  wrote:
> 
> Hi everyone,
> I have a simple REST app that is working fine with tomee.version
>> 7.1.0,
 but tomee:run it's getting issues after updating it to
>> 8.0.0-RC1-SNAPSHOT
 and also update the javaee-api to 8.0-SNAPSHOT.  mvn test runs fine but
 when I try to run mvn clean install tomee:run I got a cxf error (I
>> attached
 the full log file to this email).
> 03-Oct-2018 11:54:26.368 SEVERE [main]
 org.apache.cxf.jaxrs.utils.InjectionUtils.reportServerError Method
 setApplication can not be accessed due to security manager
 restrictions03-Oct-2018 11:54:26.378 SEVERE [main]
 org.apache.openejb.observer.ObserverManager$MethodInvocation.invoke
>> error
 invoking org.apache.tomee.webservices.TomeeJaxRsService@7ea37dbf
> Any idea why this is happening with the RC1?
> El mar., 2 oct. 2018 a las 14:04, Roberto Cortez
 () escribió:
> 
> Hi Matthew,
> 
> Feel free to try it. Yes, no planned changes, unless something required
 fixing.
> 
> Cheers,
> Roberto
> 
>> On 2 Oct 2018, at 16:37, Matthew Broadhead <
>> matthew.broadh...@nbmlaw.co.uk.INVALID>
 wrote:
>> 
>> should i try out the RC1 or wait for release candidate?  i guess they
 will be the same unless something needs upgrading?
>> 
>> On 02/10/18 12:18, Roberto Cortez wrote:
>>> I guess it would be ASAP :)
>>> 
>>> So if anyone wants to have anything in, now its the time. Speak now
>> or
 forever hold your peace :)
>>> 
>>> Cheers,
>>> Roberto
>>> 
 On 2 Oct 2018, at 00:16, David Blevins 
 wrote:
 
 Awesome.  If you have a date in mind for the first release attempt,
 definitely let people know so they can complete anything they may want
>> to
 get done.
 
 
 --
>>

Re: TomEE 8 Release Preview

2018-10-04 Thread Romain Manni-Bucau

Le jeu. 4 oct. 2018 à 11:42, Roberto Cortez  a
écrit :

> Hi Romain,
>
> Well the exception being thrown is not the actual exception.
>
> This was only happening in the MP binary due to the OpenAPI Geronimo
> implementation. In the DefaultLoader the ServletContext is injected, but at
> the time that the JAX-RS app is deployed, which is in the
> AfterApplicationCreated event, the ServletContextHandler does not have a
> Context anymore so it throws a IllegalStateException("Didnt find a web
> context for " + contextClassLoader). The caller for this is the
> setApplication of the OpenAPIFilter when we try to inject it, so that
> causes the exception we see in the logs.
>
> We never say this in Arquillian testing, because Arquillian waits for the
> server to start and then deploys the app. This means we are able to get a
> ServletContext from the request in ServletContextHandler, so it works fine.
>
> I believe this is also related with the fix you did here:
> https://issues.apache.org/jira/browse/TOMEE-1687 <
> https://issues.apache.org/jira/browse/TOMEE-1687>
>
> What do you think?
>

Can be but at the end the two issues are mentionned are not covered:

1. a regression will silently come back
2. for ears we can leak the servlet context if we end up here (and then the
app will wrongly behave)

My point is not to revert what you did but more to ensure it fixes the
issue in our build.


>
> Cheers,
> Roberto
>
> > On 4 Oct 2018, at 08:23, Romain Manni-Bucau 
> wrote:
> >
> > @Roberto: do we have a test to reproduce and prevent future regressions?
> If
> > your fix is right the error message is quite unexpected so it would be
> > better to ensure we don't break it unintentionnally (a side note is that
> > setting a single webapp context and firing an event for all webapps can
> > have the same pitfall so it can need to be reworked to ensure we don't
> hit
> > it for ears to not leak context between webapp which would be another
> nasty
> > bug).
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le jeu. 4 oct. 2018 à 01:43, Roberto Cortez 
> a
> > écrit :
> >
> >> Hi Cesar,
> >>
> >> I think I’ve found the issue. Just pushed a fix and now waiting to the
> >> build bot to check if everything is ok. I’ll let you know when it is
> done.
> >>
> >> Cheers,
> >> Roberto
> >>
> >>> On 3 Oct 2018, at 22:50, Roberto Cortez 
> >> wrote:
> >>>
> >>>
> >>> Not sure. Let me have a look.On Wednesday, October 3, 2018, 8:56:13
> >> PM GMT+1, César Hernández Mendoza  wrote:
> >>>
> >>> Hi everyone,
> >>> I have a simple REST app that is working fine with tomee.version
> 7.1.0,
> >> but tomee:run it's getting issues after updating it to
> 8.0.0-RC1-SNAPSHOT
> >> and also update the javaee-api to 8.0-SNAPSHOT.  mvn test runs fine but
> >> when I try to run mvn clean install tomee:run I got a cxf error (I
> attached
> >> the full log file to this email).
> >>> 03-Oct-2018 11:54:26.368 SEVERE [main]
> >> org.apache.cxf.jaxrs.utils.InjectionUtils.reportServerError Method
> >> setApplication can not be accessed due to security manager
> >> restrictions03-Oct-2018 11:54:26.378 SEVERE [main]
> >> org.apache.openejb.observer.ObserverManager$MethodInvocation.invoke
> error
> >> invoking org.apache.tomee.webservices.TomeeJaxRsService@7ea37dbf
> >>> Any idea why this is happening with the RC1?
> >>> El mar., 2 oct. 2018 a las 14:04, Roberto Cortez
> >> () escribió:
> >>>
> >>> Hi Matthew,
> >>>
> >>> Feel free to try it. Yes, no planned changes, unless something required
> >> fixing.
> >>>
> >>> Cheers,
> >>> Roberto
> >>>
>  On 2 Oct 2018, at 16:37, Matthew Broadhead <
> matthew.broadh...@nbmlaw.co.uk.INVALID>
> >> wrote:
> 
>  should i try out the RC1 or wait for release candidate?  i guess they
> >> will be the same unless something needs upgrading?
> 
>  On 02/10/18 12:18, Roberto Cortez wrote:
> > I guess it would be ASAP :)
> >
> > So if anyone wants to have anything in, now its the time. Speak now
> or
> >> forever hold your peace :)
> >
> > Cheers,
> > Roberto
> >
> >> On 2 Oct 2018, at 00:16, David Blevins 
> >> wrote:
> >>
> >> Awesome.  If you have a date in mind for the first release attempt,
> >> definitely let people know so they can complete anything they may want
> to
> >> get done.
> >>
> >>
> >> --
> >> David Blevins
> >> http://twitter.com/dblevins
> >> http://www.tomitribe.com
> >>
> >>> On Oct 1, 2018, at 2:41 PM, Roberto Cortez
> >>  wrote:
> >>>
> >>> Hi David,
> >>>
> >>> Thank you.
> >>>
> >>> I do intent to keep pushing with the release. Just doing “this”
> >> already ha

Re: Connector issues

2018-10-04 Thread Romain Manni-Bucau

+1 looks good

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



Le jeu. 4 oct. 2018 à 11:59, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> I have pushed some commits onto the PR here:
> https://github.com/apache/tomee/pull/174, and would appreciate some
> review.
> One the things I found was that if I hold onto a reference to the proxy for
> the transaction, it doesn't get cleaned up, but then losing the reference
> from the scope at the end of the transaction also didn't clean things up.
> What was actually going on was:
>
> 
> connection = cf.createConnection();
>
> // forget to close it
>
> connection2 = cf.createConnection(); // different proxy, but same
> ManagedConnectionInfo as the TransactionCachingInterceptor provides the
> same connection
> connection2.close(); // this removed the ManagedConnectionInfo from the
> references field on AutoConnectionTracker, so it was no longer tracked for
> cleanup.
> 
>
> The transaction then completed, and connection dropped from scope, but
> because the ManagedConnectionInfo associated with it wasn't in the
> references list anymore, it never got cleaned up.
>
> To make matters worse, TransactionCachingInterceptor sees that the
> ManagedConnectionInfo has open handles and refuses to send it back to the
> pool. The effect is the connections leaked and never went back to the pool.
>
> So, my latest changes:
>
> * Keep a proxy for as long as the transaction runs
> * Checks the reference list and cleans up at the end
> * Checks the ManagedConnectionInfo object, and if there are open handles,
> destroys the connection.
> * Additionally, if OpenEJB.connector is set to log at FINEST, it should
> reveal where any unclosed connections are originally opened, to provide the
> developer with a hint on how to fix them.
>
> I'll add some tests this afternoon, but any thoughts would be much
> appreciated.
>
> Jon
>
>
> On Fri, Sep 28, 2018 at 3:18 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > I was thinking the same - do it through the registry. Let me have a go at
> > hacking on that and I'll post back here. Many thanks for the feedback.
> >
> > Jon
> >
> > On Fri, Sep 28, 2018 at 3:15 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> that is what I had in mind, throught it was already the case to be
> honest
> >> through the transaction registry - excess of enthusiasm probably ;)
> >>
> >> Side note: dropped G for now, if we find something impacting g-txmgr
> we'll
> >> add it back
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >>
> >>
> >> Le ven. 28 sept. 2018 à 16:11, Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com> a écrit :
> >>
> >> > I apologize, I CC'd Geronimo in case there was anything relevant on
> the
> >> > Geronimo connector side. Happy to drop the CC if its not relevant.
> >> >
> >> > Thanks for the quick response!
> >> >
> >> > Off the top of my head, I wonder if we could keep a reference to the
> >> > connection proxy in the transaction (if there is one), and remove the
> >> > reference when the transaction is complete?
> >> >
> >> > Jon
> >> >
> >> > On Fri, Sep 28, 2018 at 2:57 PM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >> > wrote:
> >> >
> >> > > Hi Jon,
> >> > >
> >> > > I experienced that kind of "surprise" in recent jvm since gc is way
> >> more
> >> > > aggressive - cause lambda are way more memory consuming ;). This
> lead
> >> to
> >> > > this kind of issue where the GC happens before the object should
> >> actually
> >> > > be finalizable.
> >> > > I suspect we need to rework the AutoConnectionTracker to take into
> >> > account
> >> > > these new behaviors and actually take into consideration the
> >> lifecycle of
> >> > > the underlying connection.
> >> > >
> >> > > Maybe I got it wrong but I see the ability to disable the proxying
> as
> >> a
> >> > > quickfix/workaround - which is ok - but it means we need to fix the
> >> > source
> >> > > anyway as a long term solution. Am I understanding it right? If so
> we
> >> > need
> >> > > to ensure to keep the reference until the connection is released at
> >> least
> >> > > and ensure it was not closed in the pool (kind of testOnXXX).
> >> > > Also wonder if there is anything related to geronimo since you cc-ed
> >> it.
> >> > > IIRC this logic is only in TomEE, no?
> >> > >
> >> > > side note:

Re: Connector issues

2018-10-04 Thread Jonathan Gallimore

I have pushed some commits onto the PR here:
https://github.com/apache/tomee/pull/174, and would appreciate some review.
One the things I found was that if I hold onto a reference to the proxy for
the transaction, it doesn't get cleaned up, but then losing the reference
from the scope at the end of the transaction also didn't clean things up.
What was actually going on was:

connection = cf.createConnection();

// forget to close it

connection2 = cf.createConnection(); // different proxy, but same
ManagedConnectionInfo as the TransactionCachingInterceptor provides the
same connection
connection2.close(); // this removed the ManagedConnectionInfo from the
references field on AutoConnectionTracker, so it was no longer tracked for
cleanup.

The transaction then completed, and connection dropped from scope, but
because the ManagedConnectionInfo associated with it wasn't in the
references list anymore, it never got cleaned up.

To make matters worse, TransactionCachingInterceptor sees that the
ManagedConnectionInfo has open handles and refuses to send it back to the
pool. The effect is the connections leaked and never went back to the pool.

So, my latest changes:

* Keep a proxy for as long as the transaction runs
* Checks the reference list and cleans up at the end
* Checks the ManagedConnectionInfo object, and if there are open handles,
destroys the connection.
* Additionally, if OpenEJB.connector is set to log at FINEST, it should
reveal where any unclosed connections are originally opened, to provide the
developer with a hint on how to fix them.

I'll add some tests this afternoon, but any thoughts would be much
appreciated.

Jon

On Fri, Sep 28, 2018 at 3:18 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> I was thinking the same - do it through the registry. Let me have a go at
> hacking on that and I'll post back here. Many thanks for the feedback.
>
> Jon
>
> On Fri, Sep 28, 2018 at 3:15 PM Romain Manni-Bucau 
> wrote:
>
>> that is what I had in mind, throught it was already the case to be honest
>> through the transaction registry - excess of enthusiasm probably ;)
>>
>> Side note: dropped G for now, if we find something impacting g-txmgr we'll
>> add it back
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le ven. 28 sept. 2018 à 16:11, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> a écrit :
>>
>> > I apologize, I CC'd Geronimo in case there was anything relevant on the
>> > Geronimo connector side. Happy to drop the CC if its not relevant.
>> >
>> > Thanks for the quick response!
>> >
>> > Off the top of my head, I wonder if we could keep a reference to the
>> > connection proxy in the transaction (if there is one), and remove the
>> > reference when the transaction is complete?
>> >
>> > Jon
>> >
>> > On Fri, Sep 28, 2018 at 2:57 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> > > Hi Jon,
>> > >
>> > > I experienced that kind of "surprise" in recent jvm since gc is way
>> more
>> > > aggressive - cause lambda are way more memory consuming ;). This lead
>> to
>> > > this kind of issue where the GC happens before the object should
>> actually
>> > > be finalizable.
>> > > I suspect we need to rework the AutoConnectionTracker to take into
>> > account
>> > > these new behaviors and actually take into consideration the
>> lifecycle of
>> > > the underlying connection.
>> > >
>> > > Maybe I got it wrong but I see the ability to disable the proxying as
>> a
>> > > quickfix/workaround - which is ok - but it means we need to fix the
>> > source
>> > > anyway as a long term solution. Am I understanding it right? If so we
>> > need
>> > > to ensure to keep the reference until the connection is released at
>> least
>> > > and ensure it was not closed in the pool (kind of testOnXXX).
>> > > Also wonder if there is anything related to geronimo since you cc-ed
>> it.
>> > > IIRC this logic is only in TomEE, no?
>> > >
>> > > side note: reference queue is supposed thread safe yes.
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau  |  Blog
>> > >  | Old Blog
>> > >  | Github <
>> > > https://github.com/rmannibucau> |
>> > > LinkedIn  | Book
>> > > <
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > >
>> > >
>> > >
>> > > Le ven. 28 sept. 2018 à 15:49, Jonathan Gallimore <
>> > > jonathan.gallim...@gmail.com> a écrit :
>> > >
>> > > > Hi Folks,
>> > > >
>> > > > I have been looking into some issues with TomEE using Websphere MQ,
>> > > > specific

Re: TomEE 8 Release Preview

2018-10-04 Thread Roberto Cortez

Hi Romain,

Well the exception being thrown is not the actual exception.

This was only happening in the MP binary due to the OpenAPI Geronimo 
implementation. In the DefaultLoader the ServletContext is injected, but at the 
time that the JAX-RS app is deployed, which is in the AfterApplicationCreated 
event, the ServletContextHandler does not have a Context anymore so it throws a 
IllegalStateException("Didnt find a web context for " + contextClassLoader). 
The caller for this is the setApplication of the OpenAPIFilter when we try to 
inject it, so that causes the exception we see in the logs.

We never say this in Arquillian testing, because Arquillian waits for the 
server to start and then deploys the app. This means we are able to get a 
ServletContext from the request in ServletContextHandler, so it works fine.

I believe this is also related with the fix you did here:
https://issues.apache.org/jira/browse/TOMEE-1687 


What do you think?

Cheers,
Roberto

> On 4 Oct 2018, at 08:23, Romain Manni-Bucau  wrote:
> 
> @Roberto: do we have a test to reproduce and prevent future regressions? If
> your fix is right the error message is quite unexpected so it would be
> better to ensure we don't break it unintentionnally (a side note is that
> setting a single webapp context and firing an event for all webapps can
> have the same pitfall so it can need to be reworked to ensure we don't hit
> it for ears to not leak context between webapp which would be another nasty
> bug).
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le jeu. 4 oct. 2018 à 01:43, Roberto Cortez  a
> écrit :
> 
>> Hi Cesar,
>> 
>> I think I’ve found the issue. Just pushed a fix and now waiting to the
>> build bot to check if everything is ok. I’ll let you know when it is done.
>> 
>> Cheers,
>> Roberto
>> 
>>> On 3 Oct 2018, at 22:50, Roberto Cortez 
>> wrote:
>>> 
>>> 
>>> Not sure. Let me have a look.On Wednesday, October 3, 2018, 8:56:13
>> PM GMT+1, César Hernández Mendoza  wrote:
>>> 
>>> Hi everyone,
>>> I have a simple REST app that is working fine with tomee.version  7.1.0,
>> but tomee:run it's getting issues after updating it to 8.0.0-RC1-SNAPSHOT
>> and also update the javaee-api to 8.0-SNAPSHOT.  mvn test runs fine but
>> when I try to run mvn clean install tomee:run I got a cxf error (I attached
>> the full log file to this email).
>>> 03-Oct-2018 11:54:26.368 SEVERE [main]
>> org.apache.cxf.jaxrs.utils.InjectionUtils.reportServerError Method
>> setApplication can not be accessed due to security manager
>> restrictions03-Oct-2018 11:54:26.378 SEVERE [main]
>> org.apache.openejb.observer.ObserverManager$MethodInvocation.invoke error
>> invoking org.apache.tomee.webservices.TomeeJaxRsService@7ea37dbf
>>> Any idea why this is happening with the RC1?
>>> El mar., 2 oct. 2018 a las 14:04, Roberto Cortez
>> () escribió:
>>> 
>>> Hi Matthew,
>>> 
>>> Feel free to try it. Yes, no planned changes, unless something required
>> fixing.
>>> 
>>> Cheers,
>>> Roberto
>>> 
 On 2 Oct 2018, at 16:37, Matthew Broadhead 
 
>> wrote:
 
 should i try out the RC1 or wait for release candidate?  i guess they
>> will be the same unless something needs upgrading?
 
 On 02/10/18 12:18, Roberto Cortez wrote:
> I guess it would be ASAP :)
> 
> So if anyone wants to have anything in, now its the time. Speak now or
>> forever hold your peace :)
> 
> Cheers,
> Roberto
> 
>> On 2 Oct 2018, at 00:16, David Blevins 
>> wrote:
>> 
>> Awesome.  If you have a date in mind for the first release attempt,
>> definitely let people know so they can complete anything they may want to
>> get done.
>> 
>> 
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>> 
>>> On Oct 1, 2018, at 2:41 PM, Roberto Cortez
>>  wrote:
>>> 
>>> Hi David,
>>> 
>>> Thank you.
>>> 
>>> I do intent to keep pushing with the release. Just doing “this”
>> already had me going through some stuff, which Jon helped me out.
>>> 
>>> So consider it a first step :)
>>> 
>>> Cheers,
>>> Roberto
>>> 
 On 1 Oct 2018, at 19:28, David Blevins 
>> wrote:
 
 I think the spirit behind this is great.  However, I don't think it
>> actually helps as the hardest part which will be for you to learn the
>> release process itself.  Time wise you should budget 3 weeks.  When you do
>> know what you're doing the process usually takes 2 weeks minimum as there's
>> almost always at least one aborted vote and reroll.  Given that, the
>> chances of a release by CodeOne

Re: TomEE 8 Release Preview

2018-10-04 Thread Romain Manni-Bucau

@Roberto: do we have a test to reproduce and prevent future regressions? If
your fix is right the error message is quite unexpected so it would be
better to ensure we don't break it unintentionnally (a side note is that
setting a single webapp context and firing an event for all webapps can
have the same pitfall so it can need to be reworked to ensure we don't hit
it for ears to not leak context between webapp which would be another nasty
bug).

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



Le jeu. 4 oct. 2018 à 01:43, Roberto Cortez  a
écrit :

> Hi Cesar,
>
> I think I’ve found the issue. Just pushed a fix and now waiting to the
> build bot to check if everything is ok. I’ll let you know when it is done.
>
> Cheers,
> Roberto
>
> > On 3 Oct 2018, at 22:50, Roberto Cortez 
> wrote:
> >
> >
> > Not sure. Let me have a look.On Wednesday, October 3, 2018, 8:56:13
> PM GMT+1, César Hernández Mendoza  wrote:
> >
> > Hi everyone,
> > I have a simple REST app that is working fine with tomee.version  7.1.0,
> but tomee:run it's getting issues after updating it to 8.0.0-RC1-SNAPSHOT
> and also update the javaee-api to 8.0-SNAPSHOT.  mvn test runs fine but
> when I try to run mvn clean install tomee:run I got a cxf error (I attached
> the full log file to this email).
> > 03-Oct-2018 11:54:26.368 SEVERE [main]
> org.apache.cxf.jaxrs.utils.InjectionUtils.reportServerError Method
> setApplication can not be accessed due to security manager
> restrictions03-Oct-2018 11:54:26.378 SEVERE [main]
> org.apache.openejb.observer.ObserverManager$MethodInvocation.invoke error
> invoking org.apache.tomee.webservices.TomeeJaxRsService@7ea37dbf
> > Any idea why this is happening with the RC1?
> > El mar., 2 oct. 2018 a las 14:04, Roberto Cortez
> () escribió:
> >
> > Hi Matthew,
> >
> > Feel free to try it. Yes, no planned changes, unless something required
> fixing.
> >
> > Cheers,
> > Roberto
> >
> >> On 2 Oct 2018, at 16:37, Matthew Broadhead 
> >> 
> wrote:
> >>
> >> should i try out the RC1 or wait for release candidate?  i guess they
> will be the same unless something needs upgrading?
> >>
> >> On 02/10/18 12:18, Roberto Cortez wrote:
> >>> I guess it would be ASAP :)
> >>>
> >>> So if anyone wants to have anything in, now its the time. Speak now or
> forever hold your peace :)
> >>>
> >>> Cheers,
> >>> Roberto
> >>>
>  On 2 Oct 2018, at 00:16, David Blevins 
> wrote:
> 
>  Awesome.  If you have a date in mind for the first release attempt,
> definitely let people know so they can complete anything they may want to
> get done.
> 
> 
>  --
>  David Blevins
>  http://twitter.com/dblevins
>  http://www.tomitribe.com
> 
> > On Oct 1, 2018, at 2:41 PM, Roberto Cortez
>  wrote:
> >
> > Hi David,
> >
> > Thank you.
> >
> > I do intent to keep pushing with the release. Just doing “this”
> already had me going through some stuff, which Jon helped me out.
> >
> > So consider it a first step :)
> >
> > Cheers,
> > Roberto
> >
> >> On 1 Oct 2018, at 19:28, David Blevins 
> wrote:
> >>
> >> I think the spirit behind this is great.  However, I don't think it
> actually helps as the hardest part which will be for you to learn the
> release process itself.  Time wise you should budget 3 weeks.  When you do
> know what you're doing the process usually takes 2 weeks minimum as there's
> almost always at least one aborted vote and reroll.  Given that, the
> chances of a release by CodeOne are already slim.
> >>
> >> My advice would be to create a release branch and start cutting
> actual binaries in nexus.
> >>
> >> --
> >> David Blevins
> >> http://twitter.com/dblevins
> >> http://www.tomitribe.com
> >>
> >>> On Oct 1, 2018, at 10:57 AM, Roberto Cortez
>  wrote:
> >>>
> >>> Hi everyone,
> >>>
> >>> Following up some of our recent emails, I did push a snapshot
> version marked as RC of the upcoming TomEE 8 Release.
> >>>
> >>> Please, find the binaries here:
> >>>
> https://repository.apache.org/content/repositories/snapshots/org/apache/tomee/apache-tomee/8.0.0-RC1-SNAPSHOT/
> <
> https://repository.apache.org/content/repositories/snapshots/org/apache/tomee/apache-tomee/8.0.0-RC1-SNAPSHOT/
> >
> >>>
> >>> And remember to add the following repository to your project:
> >>> 
> >>> 
> >>> apache.snapshots.https
> >>> Apache Development Snapshot Repository
> >>> https://repository.apache.org/content/repositories/snapshots
> 
> >>> 
> >>> 
> >>>
> >>> It should be very close to the actual release. Please, help up
> take it for a spin and try it out

Re: Connector issues

Re: TomEE 8 Release Preview

Re: TomEE 8 Release Preview

Re: Connector issues

Re: Connector issues

Re: TomEE 8 Release Preview

Re: TomEE 8 Release Preview

7 matches

Site Navigation

Mail list logo

Footer information