Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Hi,

Thank you for the feedback.

We actually had to remove MP from Plus and Plume because we found some other issues. See here:
https://jira.apache.org/jira/browse/TOMEE-2407 <https://jira.apache.org/jira/browse/TOMEE-2407>

It is possible to disable it, but I don’t think it is possible to enable it per application. Is this is something that you would like to add, please add a sub-task issue in https://jira.apache.org/jira/browse/TOMEE-2407 <https://jira.apache.org/jira/browse/TOMEE-2407>

Cheers,
Roberto

> On 31 Dec 2018, at 11:19, j4fm <ja...@my-managed.net> wrote:
> 
> Hi, I tested with the last TomEE Plus snapshot which had MP in it and #304
> below.  Apart from having to add a line to exclusions.list for one item, it
> seems to work fine.  Without the exclusions.list entry, I get the following
> because @Provider is being used in our class (think this could be removed
> though):
> 
> “at java.base/java.lang.Class.newInstance(Class.java:571)
>                at
> org.apache.openejb.server.cxf.rs.CxfRsHttpListener.newProvider(CxfRsHttpListener.java:528)
>                at
> org.apache.openejb.server.cxf.rs.CxfRsHttpListener.providers(CxfRsHttpListener.java:463)
>                at
> org.apache.openejb.server.cxf.rs.CxfRsHttpListener.configureFactory(CxfRsHttpListener.java:1012)
>                at
> org.apache.openejb.server.cxf.rs.CxfRsHttpListener.deployApplication(CxfRsHttpListener.java:579)”
> 
> 
> Is having MP scanning disabled by default and enabling it on a
> per-application basis possible?
> 
> Thank you
> 
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Looks fine, logEndpoints http://localhost:8080/webapp/metrics/{registry};
/webapp/health; /webapp/openapi are all listed and it reports deployment
descriptor has finished shortly after.  I will see what else I can figure
out.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

I’ll try to have a look into the issue.

Are you positive that the apps are being deployed correctly? I think there are a few cases where there is a silent error and the app fails to deploy hence, you see the 404. If you have REST endpoints going deployed, it is easy to see if these are ok, since they show up in the log when deployed. Can you confirm?

> On 23 Jan 2019, at 18:32, j4fm <ja...@my-managed.net> wrote:
> 
> So progress is good, I feel like it's close to working with MP.  Took the
> SystemInstance parent failover line out and now it's dependent on this issue
> being resolved https://issues.apache.org/jira/browse/TOMEE-2458 which was
> why it was put in the first place.  I've worked around by adding all the
> context dependencies to common.loader which is not ideal with the amount of
> dependencies that would then affect all other webapps in TomEE.
> 
> I will keep an eye out for the OpenAPI bump.
> 
> Now I'm at:
> 
> Every context deploys successfully but webapps are inaccessible (404 error)
> because of an issue with doFilter on the contextbean we have.  It's a
> convertException on the invoke.
> 
> I believe I had similar to this a while back with the TomEE MP edition and
> you mentioned to set geronimo.opentracing.filter.active=false.  So I set
> that, and the error is gone but still leaves me with 404 not found... just
> no errors at all that I can find.  I get the impression it's almost working.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

So progress is good, I feel like it's close to working with MP.  Took the
SystemInstance parent failover line out and now it's dependent on this issue
being resolved https://issues.apache.org/jira/browse/TOMEE-2458 which was
why it was put in the first place.  I've worked around by adding all the
context dependencies to common.loader which is not ideal with the amount of
dependencies that would then affect all other webapps in TomEE.

I will keep an eye out for the OpenAPI bump.

Now I'm at:

Every context deploys successfully but webapps are inaccessible (404 error)
because of an issue with doFilter on the contextbean we have.  It's a
convertException on the invoke.

I believe I had similar to this a while back with the TomEE MP edition and
you mentioned to set geronimo.opentracing.filter.active=false.  So I set
that, and the error is gone but still leaves me with 404 not found... just
no errors at all that I can find.  I get the impression it's almost working.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Otávio Gonçalves de Santana <os...@tomitribe.com>]

I'm trying to do this by-pass.
So far, I  have this exception:

 org.apache.cxf.service.factory.ServiceConstructionException
    at org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:216)
    at org.apache.openejb.server.cxf.rs.CxfRsHttpListener.deployApplication(CxfRsHttpListener.java:638)
    at org.apache.openejb.server.rest.RESTService.deployApplication(RESTService.java:490)
    at org.apache.openejb.server.rest.RESTService.afterApplicationCreated(RESTService.java:250)
    at org.apache.tomee.webservices.TomeeJaxRsService.afterApplicationCreated(TomeeJaxRsService.java:53)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.openejb.observer.ObserverManager$MethodInvocation.invoke(ObserverManager.java:402)
    at org.apache.openejb.observer.ObserverManager.doFire(ObserverManager.java:111)
    at org.apache.openejb.observer.ObserverManager.fireEvent(ObserverManager.java:100)
    at org.apache.openejb.loader.SystemInstance.fireEvent(SystemInstance.java:134)
    at org.apache.tomee.catalina.TomcatWebAppBuilder.afterStart(TomcatWebAppBuilder.java:1783)
    at org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:117)
    at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
    at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:424)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:193)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:703)
    at org.apache.tomee.catalina.TomcatWebAppBuilder.deployWar(TomcatWebAppBuilder.java:657)
    at org.apache.tomee.catalina.TomcatWebAppBuilder.deployWebApps(TomcatWebAppBuilder.java:597)
    at org.apache.tomee.catalina.deployment.TomcatWebappDeployer.deploy(TomcatWebappDeployer.java:47)
    at org.apache.openejb.assembler.DeployerEjb.deploy(DeployerEjb.java:177)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
    at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
    at org.apache.openejb.security.internal.InternalSecurityInterceptor.invoke(InternalSecurityInterceptor.java:35)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
    at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
    at org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:191)
    at org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:102)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
    at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
    at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85)
    at org.apache.openejb.core.singleton.SingletonContainer._invoke(SingletonContainer.java:272)
    at org.apache.openejb.core.singleton.SingletonContainer.invoke(SingletonContainer.java:221)
    at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:371)
    at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:182)
    at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:360)
    at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:247)
    at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:104)
    at org.apache.openejb.server.httpd.ServerServlet.service(ServerServlet.java:60)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
    at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
    at org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCapturer.invoke(OpenEJBSecurityListener.java:97)
    at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
    at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
    at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:770)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
    at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
No resource classes found
    at org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.checkResources(AbstractJAXRSFactoryBean.java:317)
    at org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:157)
    ... 75 more




On Thu, Mar 28, 2019 at 7:53 AM Otávio Gonçalves de Santana <
osantana@tomitribe.com> wrote:

> I tried this one, but I had some regressions issues.
> I'm still working on one way to fix this.
> Question: Once MicroProfile does not need EJB and all MicroProfile works
> with CDI extensions, that does not make sense if you have just TomCat with
> OpenEJB with these Microprofiles implementations from Apache?
>
> On Wed, Mar 27, 2019 at 3:07 PM Otávio Gonçalves de Santana <
> osantana@tomitribe.com> wrote:
>
>>
>> Hey.
>> I've tested the OpeAPI.
>> That still an error when we put description at an Application.
>>
>>
>> @ApplicationPath("api")@OpenAPIDefinition(info = @Info(
>>         title = "Example application",
>>         version = "1.0.0",
>>         contact = @Contact(
>>                 name = "Otavio",
>>                 email = "otavio@otavio.com",
>>                 url = "http://www.otaviojava.com.br")
>> ),
>>         servers = {
>>                 @Server(url = "/example", description = "localhost")
>>         }
>> )public class MVCApplication extends Application {
>> }
>>
>>
>> The OpenAPI does not show this information because that still pass the
>> InternalApplication
>> instance.
>> At the RESTService
>> <https://github.com/apache/tomee/blob/tomee-8.0.0-M2/server/openejb-rest/src/main/java/org/apache/openejb/server/rest/RESTService.java#L490L492>
>> does make sense to send the original instead ofInternalApplication?
>> ?
>>
>>  ...      listener.deployApplication(getApplication(application), address.complete.substring(0, address.complete.length() - wildcard.length()), nopath.substring(NOPATH_PREFIX.length(), nopath.length() - wildcard.length()), additionalProviders, restEjbs, // app config
>>                 classLoader, injections, context, owbCtx, // injection/webapp context
>>                 new ServiceConfiguration(configuration, appInfo.services)); // deployment config
>>     }
>>
>>     private Application getApplication(Application application) {
>>         if (InternalApplication.class.equals(application.getClass())) {
>>             return InternalApplication.class.cast(application).getOriginal();
>>         }
>>         return application;
>>     }
>>
>>
>>
>> On Thu, Mar 7, 2019 at 11:20 AM j4fm <ja...@my-managed.net> wrote:
>>
>>> Hey Roberto, I have an idea for how to add the per-context
>>> tomee.mp.scan.
>>> Just want to add the AppInfo param to the EnhanceScannableUrlsEvent and
>>> enable/disable the scanning for each mp feature based on per-context
>>> config.
>>> This event was only added since the last release so won't break any
>>> backwards compat, correct?  Thoughts on that approach?
>>>
>>> Thanks
>>>
>>> James
>>>
>>>
>>>
>>> --
>>> Sent from:
>>> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>>>
>>

Re: MicroProfile Integration in Plus and Plume

[Otávio Gonçalves de Santana <os...@tomitribe.com>]

I tried this one, but I had some regressions issues.
I'm still working on one way to fix this.
Question: Once MicroProfile does not need EJB and all MicroProfile works
with CDI extensions, that does not make sense if you have just TomCat with
OpenEJB with these Microprofiles implementations from Apache?

On Wed, Mar 27, 2019 at 3:07 PM Otávio Gonçalves de Santana <
osantana@tomitribe.com> wrote:

>
> Hey.
> I've tested the OpeAPI.
> That still an error when we put description at an Application.
>
>
> @ApplicationPath("api")@OpenAPIDefinition(info = @Info(
>         title = "Example application",
>         version = "1.0.0",
>         contact = @Contact(
>                 name = "Otavio",
>                 email = "otavio@otavio.com",
>                 url = "http://www.otaviojava.com.br")
> ),
>         servers = {
>                 @Server(url = "/example", description = "localhost")
>         }
> )public class MVCApplication extends Application {
> }
>
>
> The OpenAPI does not show this information because that still pass the
> InternalApplication
> instance.
> At the RESTService
> <https://github.com/apache/tomee/blob/tomee-8.0.0-M2/server/openejb-rest/src/main/java/org/apache/openejb/server/rest/RESTService.java#L490L492>
> does make sense to send the original instead ofInternalApplication?
> ?
>
>  ...      listener.deployApplication(getApplication(application), address.complete.substring(0, address.complete.length() - wildcard.length()), nopath.substring(NOPATH_PREFIX.length(), nopath.length() - wildcard.length()), additionalProviders, restEjbs, // app config
>                 classLoader, injections, context, owbCtx, // injection/webapp context
>                 new ServiceConfiguration(configuration, appInfo.services)); // deployment config
>     }
>
>     private Application getApplication(Application application) {
>         if (InternalApplication.class.equals(application.getClass())) {
>             return InternalApplication.class.cast(application).getOriginal();
>         }
>         return application;
>     }
>
>
>
> On Thu, Mar 7, 2019 at 11:20 AM j4fm <ja...@my-managed.net> wrote:
>
>> Hey Roberto, I have an idea for how to add the per-context tomee.mp.scan.
>> Just want to add the AppInfo param to the EnhanceScannableUrlsEvent and
>> enable/disable the scanning for each mp feature based on per-context
>> config.
>> This event was only added since the last release so won't break any
>> backwards compat, correct?  Thoughts on that approach?
>>
>> Thanks
>>
>> James
>>
>>
>>
>> --
>> Sent from:
>> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>>
>

Re: MicroProfile Integration in Plus and Plume

[Otávio Gonçalves de Santana <os...@tomitribe.com>]

Hey.
I've tested the OpeAPI.
That still an error when we put description at an Application.


@ApplicationPath("api")@OpenAPIDefinition(info = @Info(
        title = "Example application",
        version = "1.0.0",
        contact = @Contact(
                name = "Otavio",
                email = "otavio@otavio.com",
                url = "http://www.otaviojava.com.br")
),
        servers = {
                @Server(url = "/example", description = "localhost")
        }
)public class MVCApplication extends Application {
}


The OpenAPI does not show this information because that still pass the
InternalApplication
instance.
At the RESTService
<https://github.com/apache/tomee/blob/tomee-8.0.0-M2/server/openejb-rest/src/main/java/org/apache/openejb/server/rest/RESTService.java#L490L492>
does make sense to send the original instead ofInternalApplication?
?

 ...      listener.deployApplication(getApplication(application),
address.complete.substring(0, address.complete.length() -
wildcard.length()), nopath.substring(NOPATH_PREFIX.length(),
nopath.length() - wildcard.length()), additionalProviders, restEjbs,
// app config
                classLoader, injections, context, owbCtx, //
injection/webapp context
                new ServiceConfiguration(configuration,
appInfo.services)); // deployment config
    }

    private Application getApplication(Application application) {
        if (InternalApplication.class.equals(application.getClass())) {
            return InternalApplication.class.cast(application).getOriginal();
        }
        return application;
    }



On Thu, Mar 7, 2019 at 11:20 AM j4fm <ja...@my-managed.net> wrote:

> Hey Roberto, I have an idea for how to add the per-context tomee.mp.scan.
> Just want to add the AppInfo param to the EnhanceScannableUrlsEvent and
> enable/disable the scanning for each mp feature based on per-context
> config.
> This event was only added since the last release so won't break any
> backwards compat, correct?  Thoughts on that approach?
>
> Thanks
>
> James
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hey Roberto, I have an idea for how to add the per-context tomee.mp.scan. 
Just want to add the AppInfo param to the EnhanceScannableUrlsEvent and
enable/disable the scanning for each mp feature based on per-context config. 
This event was only added since the last release so won't break any
backwards compat, correct?  Thoughts on that approach?

Thanks

James



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

I guess Jon beaten me into it :)

Sorry. I’ve been a little inactive in the last couple of week :)

> On 1 Mar 2019, at 09:30, j4fm <ja...@my-managed.net> wrote:
> 
> Hi Roberto, PR 418 is also ready now that openapi and safeguard latest
> release versions are in maven
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hi Roberto, PR 418 is also ready now that openapi and safeguard latest
release versions are in maven



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

FYI, the full run of tests succeeded locally with this PR over night. :)



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Yes, I’ll check. Thank you!

> On 27 Feb 2019, at 23:13, j4fm <ja...@my-managed.net> wrote:
> 
> The bad news is my tests showed the default.exclusions did not fix the issue.
> The good news is I found the static extension that was always registering
> the JWT providers.  So I've commented that out as now your new approach of
> scanning the providers automatically is working just fine.  I've added that
> to the PR 424.
> 
> I've tested now I'm seeing only one JWT set of providers when
> tomee.mp.scan=all and none when it's none.
> 
> Would you mind checking and merging PR 424 for me for this?
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

The bad news is my tests showed the default.exclusions did not fix the issue.
The good news is I found the static extension that was always registering
the JWT providers.  So I've commented that out as now your new approach of
scanning the providers automatically is working just fine.  I've added that
to the PR 424.

I've tested now I'm seeing only one JWT set of providers when
tomee.mp.scan=all and none when it's none.

Would you mind checking and merging PR 424 for me for this?



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Cool then, PR 424 just needs merging to fix this.  The setting itself is
working just fine.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Oh yes, we probably forgot about that, since it actually never gave an error like we were having with the other filters. Please remove it as well when the setting is off :)

Cheers,
Roberto

> On 27 Feb 2019, at 16:14, j4fm <ja...@my-managed.net> wrote:
> 
> Hi Roberto
> 
> I have found that MP-JWT is missing from the default.exclusions.  Is that
> expected?
> 
> I see the JWT Filter being added in all cases even when tomee.mp.scan=none
> is set but also when tomee.mp.scan=all is set, the JWT Filter is added
> twice.
> 
> If not intended, I have submitted PR424.  Thanks!
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hi Roberto

I have found that MP-JWT is missing from the default.exclusions.  Is that
expected?

I see the JWT Filter being added in all cases even when tomee.mp.scan=none
is set but also when tomee.mp.scan=all is set, the JWT Filter is added
twice.

If not intended, I have submitted PR424.  Thanks!



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Ah sorry.

I think we got a little confused there. I was referring to the feature to allow enable / disable MP scanning per app.

The idea is that you would use that config on a pojo configuration in openejb-jar.xml and read it and set it in the context app to enhance the classpath of the app or not (basically turning on or off the flag).

Cheers,
Roberto

> On 26 Feb 2019, at 00:04, j4fm <ja...@my-managed.net> wrote:
> 
> PR 416
> 
> I'm not sure I quite follow the ConfigSource approach.  I was thinking it
> would need to be done in enhanceScannableUrls to avoid the JARs being
> scanned in the first place.  I don't think setting the .active for metrics
> and opentracing is enough.  Do you think that is possible?
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

PR 416

I'm not sure I quite follow the ConfigSource approach.  I was thinking it
would need to be done in enhanceScannableUrls to avoid the JARs being
scanned in the first place.  I don't think setting the .active for metrics
and opentracing is enough.  Do you think that is possible?



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Cool! 

Did you have a PR for that?

For the tomee.mp.scan per context, have a look here:

org.apache.openejb.server.rest.RESTService#deployApplication

PojoUtil.findConfiguration(pojoConfigurations, "jaxrs-application”); should look into the openejb-jar with a new pojo deployment like mp-application and then pass in the specific configuration for that application. Try to see if you can then load it in org.apache.tomee.microprofile.config.TomEEConfigSource#TomEEConfigSource and we should be good :)

Cheers,
Roberto

> On 25 Feb 2019, at 20:25, j4fm <ja...@my-managed.net> wrote:
> 
> Hi Roberto, fyi, I've solved the issue of using filenames for
> enhanceScannableUrls.  I changed left your approach intact and is still used
> for "mp-common" and if you need to add any files in future.  But for all
> other MP JARs, I switched it to use your list of MP fully-qualified
> extensions class names to locate the JAR file URL.
> 
> That just leaves the tomee.mp.scan setting per context.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hi Roberto, fyi, I've solved the issue of using filenames for
enhanceScannableUrls.  I changed left your approach intact and is still used
for "mp-common" and if you need to add any files in future.  But for all
other MP JARs, I switched it to use your list of MP fully-qualified
extensions class names to locate the JAR file URL.

That just leaves the tomee.mp.scan setting per context.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

For sure...

- Do you have an idea for how best to add the tomee.mp.scan per context?
- Any preference on fixing the filename scanning issue?  I'm wondering if
having Maven dependency rename the JAR in the lib folder slightly so that it
doesn't catch two in one go would be acceptable?

Thanks



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Thank you! You should get the credit, since you ended the work! Great job! :)

Yeah, for the CDI, I guess that the code was there before we changed to use the MP Listener to load the libraries. Before we were just blindly scanning everything (and hence the slowness). 

I think we are still missing a couple of things:

- the ability to set the mp enable / disable per app
- deal with the prefix jar name because of the wrong jar being picked to load

Cheers,
Roberto

> On 22 Feb 2019, at 16:03, j4fm <ja...@my-managed.net> wrote:
> 
> So we have a happy buildbot again for the first time since MP is added to
> Plus/Plume.  Thanks for all your help on this so far.  :)
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

So we have a happy buildbot again for the first time since MP is added to
Plus/Plume.  Thanks for all your help on this so far.  :)



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

All local build tests PASSED with my PR 406! :D




--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

If I undo your two CDIScanner.java commits:

https://github.com/apache/tomee/commit/de5a2ee7aafe08c4caf20c8ae322cabde5f1cbcf#diff-b316d57f3c81b76c38456cebdd2ec27f

https://github.com/apache/tomee/commit/76f91408a2ddd5d05ede0d3be93df4c3d5a96079#diff-b316d57f3c81b76c38456cebdd2ec27f

CDI-Embedded TCK passes.  So I have undone these as part of my PR 406. 
Unless bringing the above back introduces new issues, I believe all tests
pass now.  I'm starting a full test run locally now - it would be good to
get buildbot back on the case if they check out.

You described these two as fixing MP in EAR and additional libraries...
would you mind describing some more? Is there another approach?




--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

PR 406.  Also included a small fix for CXF taking over Jersey app even if
disabled.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I've updated the isCXFResource check to follow the same behaviour as the
JAX-RS application logic itself.  If the application's getClasses() or
getSingletons() return something then Application sub-class fully controls
the resources/endpoints so the isCXFResource check returns true and sends
all requests through the pre-existing CXF filter code route.  If they both
return empty, it does the previous checks to see if they are valid REST
endpoints (picked up by CDI scanner) first.  This aligns it with REST
service logic I described previously.

I believe this should cover the scenarios.

OpenAPI TCK passes with this fix.  Will create a PR for it. :)

Just CDI Embedded left to fix if nothing new.  I will leave the full run of
tests running overnight and see how it is in the morning.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Okay, found out this first one turns out to be straight-up my fault.  The
OpenAPIFilter isn't expected to be loaded by TomEE itself in the chain and
actually goes via an extension loaded by CXF itself triggering it as a
pre-match request filter.  So the enhancement I made needs to take into
account CXF extensions or another solution.  Not sure how easy that would do
but will take a look.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Hi, 

So the issue is that there is no Filter loaded in the app? That is strange. We probably need to dig more into it.

Yeah, sorry, I’ve been a bit busy, so I was not able to look into the Embedded CDI. I’m trying to set up sometime tomorrow to look into it.

Cheers,
Roberto

> On 20 Feb 2019, at 14:32, j4fm <ja...@my-managed.net> wrote:
> 
> Basically adding to or removing from restClass as the
> TomEEMicroProfileListener is currently doing has no effect on REST
> applications that "extend Application" and provide getClasses() or
> getSingletons().  Even if the OpenAPIFilter is in the providers, the
> endpoint is not added so no /openapi endpoint exists.
> 
> When the request for /openapi comes through there is no OpenAPIFilter loaded
> (but the opentracing filter is loaded).  So the OpenAPIFilter does not exist
> to handle the request.
> 
> Did you manage to get to look at the CDI-Embedded?
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Basically adding to or removing from restClass as the
TomEEMicroProfileListener is currently doing has no effect on REST
applications that "extend Application" and provide getClasses() or
getSingletons().  Even if the OpenAPIFilter is in the providers, the
endpoint is not added so no /openapi endpoint exists.

When the request for /openapi comes through there is no OpenAPIFilter loaded
(but the opentracing filter is loaded).  So the OpenAPIFilter does not exist
to handle the request.

Did you manage to get to look at the CDI-Embedded?



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

How would you get the MP endpoint classes added from
TomEEMicroProfileListener#processApplication? 
RESTService#afterApplicationCreated ignores restClass completely if the
Application sub-class getClasses/getSingletons return something - that's the
problem.  Is there another mechanism for adding that isn't ignored for the
"extends Application class" scenario?

There is also definitely more than one issue here.  Once I got past the
issue with the openapi endpoints missing (with my approach above - just to
test, not submitting PR for it at this point) it succeeded but the next
test's issue is it cannot create the TomeeJaxRsService at all.

SEVERE [http-nio-50290-exec-3]
org.apache.openejb.observer.ObserverManager$MethodInvocation.invoke error
invoking org.apache.tomee.webservices.TomeeJaxRsService@7b7fdc8
 org.apache.cxf.service.factory.ServiceConstructionException
	at
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:225)

Looks similar to the issue when openapi was causing an exception creating
the rest api.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Great analysis and explanation! Thank you :)

I think that having a scenario where you scan and use both scanned and app resources might be tricky. We don’t control the application libraries, so we may end up scanning more resources than the user actually wants.

We already know which endpoints we want to add and we already have the tomee.mp.scan option to enable / disable MP. How about if we add the MP rest classes in org.apache.tomee.microprofile.TomEEMicroProfileListener#processApplication before any logic and then let them be removed again with the logic of the servlet root in /*?

Cheers,
Roberto

> On 16 Feb 2019, at 11:19, j4fm <ja...@my-managed.net> wrote:
> 
> I've gone through the CXF resource adding behaviour.  I think the logic can
> be improved.  This is how I see it works as it is:
> 
> (Scenario for "MyApplication extends Application" class)
> 
> It looks like the openejb.jaxrs.application is intended to choose whether to
> use MyApplication's classes/singletons or not but actually in both cases of
> true/false it invokes the same sort of logic that uses MyApplication's
> classes/singletons if provided but restClass if not.  (There is also no
> option of both).
> 
> 1. If openejb.jaxrs.application is true...
>  a. ...then it uses the classes/singletons returned by the MyApplication
> instance if it returns some. In this case it does not add what's in
> restClass (i.e. scanned classes which does include MP endpoints).
>  b. ...if the MyApplication class does not return any classes/singletons,
> it processes restClass (i.e. scanned classes which includes MP endpoints and
> in this case the same classes as MyApplication too)
> 2. If openejb.jaxrs.application is false, it uses the fullServletDeployment
> logic.  This setting and also flag name (!deploymentWithApplication)
> indicate this should be without using MyApplication, i.e. using only the
> runtime scanned classes.  But the comments header in fullServletDeployment
> indicates that it will use MyApplication if it exists.  That's the same as
> the logic in 1 above and when checking the code in fullServletDeployment, it
> does in fact have the same behaviour as 1a and 1b. (i.e. if MyApplication
> provides classes/singletons, it ignores restClass) - "useApp = useApp ||
> classes.size() + singletons.size() > 0";  So this seems to be a bit of an
> odd setting in this scenario but I'm sure there are other scenarios too.
> 
> So right, now to get scanned classes picked up (i.e. MP resources) when
> providing MyApplication resource classes, we'd have to change MyApplication
> to return no classes/singletons.  This means changing the openapi TCK and
> breaking portability for MyApplication.  So this is not an option.
> 
> If I put existing behaviour and backwards compatibility to one side for a
> moment, I'm thinking a setting such as the following would be best...
> 
> openejb.jaxrs.use_rest_classes_from = scanned|application|both|auto
> 
> scanned = Use only rest classes detected by runtime scanner.
> application = Use only rest classes provided by MyApplication.
> both = Use the combined unique list of rest classes from scanned and
> application.
> auto = If MyApplication provides rest classes, use them; Otherwise, use
> scanned (current behaviour regardless of openejb.jaxrs.application setting)
> 
> Choice of default:
> 1. Thinking about backwards compatibility again, I guess this new setting
> could be introduced with the default value of "auto".  But that will not
> resolve the openapi test case or add the MP endpoints to any rest
> application that provides some rest classes itself... to resolve those, then
> either "scanned" or "both" would work.  We could set those just for openapi
> test case and the rest app I have that extends Application that I would like
> to see MP endpoints.
> 
> 2. A default value of "both", could be best as default as it enables app
> portability but also server configured resources, but would change existing
> behaviour (users see MP endpoints added, possibly others in some apps).  It
> would be easy for a user to switch back to "auto" for existing behaviour
> though.
> 
> (While I see openejb.cxf-rs.cache-application wraps MyApplication's rest
> classes/singletons when provided, I don't see it taking into account scanned
> classes.  While it could be updated to do that, I'm not sure the "caching"
> setting should be confused with determining which source(s) to use for rest
> classes - I don't think it does today either.)
> 
> Am interested in your thoughts, I think this would provide missing
> flexibility as well as fix the openapi test case at least.  If agreeing,
> would you prefer default 1 or 2?  I understand I'm pretty fresh to this code
> base so there may be functionality/behaviours around the above I haven't
> seen and am not aware of.
> 
> Depending on your views, I would be happy to create a JIRA for it.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I've gone through the CXF resource adding behaviour.  I think the logic can
be improved.  This is how I see it works as it is:

(Scenario for "MyApplication extends Application" class)

It looks like the openejb.jaxrs.application is intended to choose whether to
use MyApplication's classes/singletons or not but actually in both cases of
true/false it invokes the same sort of logic that uses MyApplication's
classes/singletons if provided but restClass if not.  (There is also no
option of both).

1. If openejb.jaxrs.application is true...
  a. ...then it uses the classes/singletons returned by the MyApplication
instance if it returns some. In this case it does not add what's in
restClass (i.e. scanned classes which does include MP endpoints).
  b. ...if the MyApplication class does not return any classes/singletons,
it processes restClass (i.e. scanned classes which includes MP endpoints and
in this case the same classes as MyApplication too)
2. If openejb.jaxrs.application is false, it uses the fullServletDeployment
logic.  This setting and also flag name (!deploymentWithApplication)
indicate this should be without using MyApplication, i.e. using only the
runtime scanned classes.  But the comments header in fullServletDeployment
indicates that it will use MyApplication if it exists.  That's the same as
the logic in 1 above and when checking the code in fullServletDeployment, it
does in fact have the same behaviour as 1a and 1b. (i.e. if MyApplication
provides classes/singletons, it ignores restClass) - "useApp = useApp ||
classes.size() + singletons.size() > 0";  So this seems to be a bit of an
odd setting in this scenario but I'm sure there are other scenarios too.

So right, now to get scanned classes picked up (i.e. MP resources) when
providing MyApplication resource classes, we'd have to change MyApplication
to return no classes/singletons.  This means changing the openapi TCK and
breaking portability for MyApplication.  So this is not an option.

If I put existing behaviour and backwards compatibility to one side for a
moment, I'm thinking a setting such as the following would be best...

openejb.jaxrs.use_rest_classes_from = scanned|application|both|auto

scanned = Use only rest classes detected by runtime scanner.
application = Use only rest classes provided by MyApplication.
both = Use the combined unique list of rest classes from scanned and
application.
auto = If MyApplication provides rest classes, use them; Otherwise, use
scanned (current behaviour regardless of openejb.jaxrs.application setting)

Choice of default:
1. Thinking about backwards compatibility again, I guess this new setting
could be introduced with the default value of "auto".  But that will not
resolve the openapi test case or add the MP endpoints to any rest
application that provides some rest classes itself... to resolve those, then
either "scanned" or "both" would work.  We could set those just for openapi
test case and the rest app I have that extends Application that I would like
to see MP endpoints.

2. A default value of "both", could be best as default as it enables app
portability but also server configured resources, but would change existing
behaviour (users see MP endpoints added, possibly others in some apps).  It
would be easy for a user to switch back to "auto" for existing behaviour
though.

(While I see openejb.cxf-rs.cache-application wraps MyApplication's rest
classes/singletons when provided, I don't see it taking into account scanned
classes.  While it could be updated to do that, I'm not sure the "caching"
setting should be confused with determining which source(s) to use for rest
classes - I don't think it does today either.)

Am interested in your thoughts, I think this would provide missing
flexibility as well as fix the openapi test case at least.  If agreeing,
would you prefer default 1 or 2?  I understand I'm pretty fresh to this code
base so there may be functionality/behaviours around the above I haven't
seen and am not aware of.

Depending on your views, I would be happy to create a JIRA for it.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Well we can for now try to push your PR since this seems to be a completely different problem not related with the previous work.

In took a bit longer on your PR, since I found a few other failures, but those were related with other commits done in the meanwhile. It seems to be ok. I’ll be merging it. Now we are left with that problem plus the CDI Embedded issues.

Everything should be handled in org.apache.openejb.server.rest.RESTService#deployApplication. There is an Application object there. Try to have a look and see what is the current state of the object when it reaches that code.

Also, I think we could file a separate JIRA for this and implement a test case.

Cheers,
Roberto

> On 15 Feb 2019, at 11:16, j4fm <ja...@my-managed.net> wrote:
> 
> I've confirmed that during
> org.apache.tomee.microprofile.TomEEMicroProfileListener#processApplication,
> the correct MP Endpoints are already present in the restClass list.  This
> isn't an issue with them not being there.
> 
> The issue is somewhere between AnnotationDeployer and CXF deploy, they are
> lost. This only happens for services using the "MyApplication extends
> Application" RS approach, which should be supported too I would think.
> 
> This is a general MicroProfile support issue for TomEE, not specific to
> Plus/Plume (I think) and this isn't related in any way to the CXFJAXRSFilter
> enhancement I did - this filter seems to be fine for all the tests cases now
> (merging that PR should be fine now).
> 
> Do you have a better idea of how the AnnotationDeployer->CXF deploy piece
> works to enable it to work for the "MyApp extends Application" approach?  I
> don't have much time for it today or this weekend but will offer any spare
> time that does come up.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I've confirmed that during
org.apache.tomee.microprofile.TomEEMicroProfileListener#processApplication,
the correct MP Endpoints are already present in the restClass list.  This
isn't an issue with them not being there.

The issue is somewhere between AnnotationDeployer and CXF deploy, they are
lost. This only happens for services using the "MyApplication extends
Application" RS approach, which should be supported too I would think.

This is a general MicroProfile support issue for TomEE, not specific to
Plus/Plume (I think) and this isn't related in any way to the CXFJAXRSFilter
enhancement I did - this filter seems to be fine for all the tests cases now
(merging that PR should be fine now).

Do you have a better idea of how the AnnotationDeployer->CXF deploy piece
works to enable it to work for the "MyApp extends Application" approach?  I
don't have much time for it today or this weekend but will offer any spare
time that does come up.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

This is the microprofile-tck openapi test



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Most likely, the TCK doesn’t have a test case for it…

We can add our own and even contribute to the TCK if we find something is missing. 

> On 14 Feb 2019, at 18:23, j4fm <ja...@my-managed.net> wrote:
> 
> Any idea if this was already an issue with the TomEE MP edition alone?  I'm
> not sure how the tck would pass.
> 
> Just want to make sure that expected behaviour isn't broken or something
> missed before considering adding this.
> 
> I think it is something that should definitely be supported though as
> extending the Application class seems to be quite a common approach for RS
> apps.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Any idea if this was already an issue with the TomEE MP edition alone?  I'm
not sure how the tck would pass.

Just want to make sure that expected behaviour isn't broken or something
missed before considering adding this.

I think it is something that should definitely be supported though as
extending the Application class seems to be quite a common approach for RS
apps.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

I think we may need to add them manually the same way we remove them in org.apache.tomee.microprofile.TomEEMicroProfileListener#processApplication.

> On 14 Feb 2019, at 16:11, j4fm <ja...@my-managed.net> wrote:
> 
> When InternalApplication is used, the constructor adds the classes and
> singletons that exist on the passed in "original" application.  I'm assuming
> the MP endpoints are in those lists in that scenario.
> 
> For people that choose to create their RS application using the "extends
> Application" approach, they create they override getSingletons or getClasses
> or both but they only add their own application specific classes. 
> CxfRsHttpListener only seems to add what is returned from those two
> operations.
> 
> In this "extends application" scenario what is the intended mechanism for
> adding the MP classes to the application?
> 
> Thanks
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

When InternalApplication is used, the constructor adds the classes and
singletons that exist on the passed in "original" application.  I'm assuming
the MP endpoints are in those lists in that scenario.

For people that choose to create their RS application using the "extends
Application" approach, they create they override getSingletons or getClasses
or both but they only add their own application specific classes. 
CxfRsHttpListener only seems to add what is returned from those two
operations.

In this "extends application" scenario what is the intended mechanism for
adding the MP classes to the application?

Thanks



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I saw that value was set correctly in the logs.  Suspecting something else.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Setting "openejb.cxf-rs.cache-application” to “false” should fix that issue. I even added it to TomEEMicroProfileListener. Unless there is something else going on.

> On 14 Feb 2019, at 15:27, j4fm <ja...@my-managed.net> wrote:
> 
> The remaining test failure apart from cdi-embedded is OpenAPI.  It's clear
> that the MP endpoints are not added even though tomee.mp.scan=all is added.
> 
> This is the same for the one REST app I have which doesn't have them.
> 
> The thing they both have in common is that they are both a "MyApplication
> extends Application" app.  There must be some logic to disable MP where the
> default "Application" is not used.  The other apps that do have the MP
> endpoints show "InternalApplication" for the CXF app.
> 
> Learning lots.  Digging deeper...
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

The remaining test failure apart from cdi-embedded is OpenAPI.  It's clear
that the MP endpoints are not added even though tomee.mp.scan=all is added.

This is the same for the one REST app I have which doesn't have them.

The thing they both have in common is that they are both a "MyApplication
extends Application" app.  There must be some logic to disable MP where the
default "Application" is not used.  The other apps that do have the MP
endpoints show "InternalApplication" for the CXF app.

Learning lots.  Digging deeper...



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

I believe the CDI embedded tests failure is related with another issue. Probably something I did. A few commits ago it was fine. Let us solve the other issue first and then I’ll run a couple of git bisects to figure out where the problem started.

> On 13 Feb 2019, at 16:09, j4fm <ja...@my-managed.net> wrote:
> 
> Running full tests again myself too.  I know the cdi-embedded failure still
> happens but I'm not sure that is related or what the cause of that is...
> possibly class loading related?
> 
> SEVERE - CDI Beans module deployment failed
> org.apache.webbeans.exception.WebBeansDeploymentException:
> javax.enterprise.inject.UnsatisfiedResolutionException: Api type
> [org.jboss.cdi.tck.tests.lookup.typesafe.resolution.interceptor.CatInterceptor]
> is not found with the qualifiers
> Qualifiers: [@javax.enterprise.inject.Default()]
> for injection into Field Injection Point, field name :  catInterceptor,
> Bean Owner : [Foo, WebBeansType:MANAGED, Name:null, API
> Types:[java.lang.Object,org.jboss.cdi.tck.tests.lookup.typesafe.resolution.interceptor.Foo],
> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]]
>       at
> org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:356)
>       at
> org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:196)
>       at
> org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:229)
>       at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
>       at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:963)
>       at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:756)
>       at
> org.apache.openejb.arquillian.openejb.OpenEJBDeployableContainer.quickDeploy(OpenEJBDeployableContainer.java:323)
>       at
> org.apache.openejb.arquillian.openejb.OpenEJBDeployableContainer.deploy(OpenEJBDeployableContainer.java:227)
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Running full tests again myself too.  I know the cdi-embedded failure still
happens but I'm not sure that is related or what the cause of that is...
possibly class loading related?

 SEVERE - CDI Beans module deployment failed
 org.apache.webbeans.exception.WebBeansDeploymentException:
javax.enterprise.inject.UnsatisfiedResolutionException: Api type
[org.jboss.cdi.tck.tests.lookup.typesafe.resolution.interceptor.CatInterceptor]
is not found with the qualifiers
 Qualifiers: [@javax.enterprise.inject.Default()]
 for injection into Field Injection Point, field name :  catInterceptor,
Bean Owner : [Foo, WebBeansType:MANAGED, Name:null, API
Types:[java.lang.Object,org.jboss.cdi.tck.tests.lookup.typesafe.resolution.interceptor.Foo],
Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]]
       at
org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:356)
       at
org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:196)
       at
org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:229)
       at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
       at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:963)
       at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:756)
       at
org.apache.openejb.arquillian.openejb.OpenEJBDeployableContainer.quickDeploy(OpenEJBDeployableContainer.java:323)
       at
org.apache.openejb.arquillian.openejb.OpenEJBDeployableContainer.deploy(OpenEJBDeployableContainer.java:227)



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Cool! Thank you! I’ll have a look.

> On 13 Feb 2019, at 15:30, j4fm <ja...@my-managed.net> wrote:
> 
> PR 397 is ready to be tested. :)
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

PR 397 is ready to be tested. :)



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hold off testing PR 397 for the moment, got a fix for resteasy test coming...



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

PR 397



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Yes, I was looking into the test and since your changes make the CXF interceptor to not be invoked the test doesn’t make much sense now.

The only situation when this is valid is if we want to have some kind of interceptor on a 404 and return something else. This might be a breaking change, since we don’t know how everyone else is developing their apps and we don’t know if someone is doing something similar :)

I don’t see an easy answer on this one. Maybe lets just assume the break and see if someone complains :) They could always use a Filter to do the same thing.

I’ll say to just comment the test for now and see how the build looks like.

Thank you!

Cheers,
Roberto

> On 12 Feb 2019, at 16:01, j4fm <ja...@my-managed.net> wrote:
> 
> Have a remaining test issue but not sure on it's validity.  Would like to get
> your thoughts on the JAX-RS NotFound test.
> 
> arquillian\arquillian-tomee-tests\arquillian-tomee-jaxrs-tests\src\test\java\org\apache\openejb\arquillian\tests\jaxrs\notfound\NotFoundTest.java
> 
> This test basically intercepts when CXF itself returns a 404 using a
> customhandler (CXF out interceptor).
> 
> Now with my enhancement the filter only invokes CXF if it's actually a valid
> CXF resource.  So CXF itself never gets to respond with a 404.
> 
> This causes the test to fail because although a 404 is returned, it doesn't
> come from CXF.  It comes from the standard servlet.
> 
> So while I think the test is still valid for testing for a 404, I think it's
> implementation should be changed to be not tied to CXF itself.  (My view
> this is a good thing).
> 
> This test is not really for testing CXF out interceptors... if it is it
> should be split into it's own test and not based on a 404 error.
> 
> Appreciate your input!?
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

For now, I've changed the test to do an assertEquals(404, response) type and
will add to PR as I think that makes most sense for a "NotFound" test.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Have a remaining test issue but not sure on it's validity.  Would like to get
your thoughts on the JAX-RS NotFound test.

arquillian\arquillian-tomee-tests\arquillian-tomee-jaxrs-tests\src\test\java\org\apache\openejb\arquillian\tests\jaxrs\notfound\NotFoundTest.java

This test basically intercepts when CXF itself returns a 404 using a
customhandler (CXF out interceptor).

Now with my enhancement the filter only invokes CXF if it's actually a valid
CXF resource.  So CXF itself never gets to respond with a 404.

This causes the test to fail because although a 404 is returned, it doesn't
come from CXF.  It comes from the standard servlet.

So while I think the test is still valid for testing for a 404, I think it's
implementation should be changed to be not tied to CXF itself.  (My view
this is a good thing).

This test is not really for testing CXF out interceptors... if it is it
should be split into it's own test and not based on a 404 error.

Appreciate your input!?



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Great! Thanks for the update. Send the PR when ready and I’ll be happy to test it and merge it! 

Cheers,
Roberto

> On 11 Feb 2019, at 14:16, j4fm <ja...@my-managed.net> wrote:
> 
> Hey Roberto, progress so far... the JAX-RS issue you referenced a few
> messages ago was solved with my filter enhancement.  But actually found it
> was having the reverse affect for some requests (as in it was passing them
> down the chain when they were valid CXF requests - this was just about
> matching the right path value).  I've solved that now too.
> 
> Back to running the lengthy tests now.  I will update the PR as soon as
> everything looks good locally.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hey Roberto, progress so far... the JAX-RS issue you referenced a few
messages ago was solved with my filter enhancement.  But actually found it
was having the reverse affect for some requests (as in it was passing them
down the chain when they were valid CXF requests - this was just about
matching the right path value).  I've solved that now too.

Back to running the lengthy tests now.  I will update the PR as soon as
everything looks good locally.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hey Roberto, I didn't get much time earlier but will later. The first thing I
noticed is that the assert reports the expected http response and actual
http response the wrong way round. Easy fix, I have ready to submit.

But the important bit is that it expects 200 but gets 404... that's exactly
the problem I had before and what my CXFJAXRSFilter PR fixes. :)

I will continue with it later too.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

The test passes without all-adapters specified. Fails with it. So will find
out which adapter.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

No probs at all. Absolutely sure happy to look.  Did open up the cdi-embdded
exception yesterday but didn't get very far with the little time I had.  Do
you think the two are related?

fyi, I changed the PR to 390 with its own tickets as I expect it helps more
than just MP endpoints, so thought that was justified to help people find
more information on the change in future.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Hey,

Sorry, I was a little bit off in the last few days. 

At the moment there are some other errors that we need to figure out the cause. For instance:

[ERROR] Failures:
[ERROR]   JAXRSHttpHeadersTest.testRequestHeaderCaseInsensitive:373->JaxrsTest.assertStatusCode:82 expected:<404> but was:<200>
[ERROR]   JAXRSHttpHeadersTest.testRequestHeaderMultipleValue:355->JaxrsTest.assertStatusCode:82 expected:<404> but was:<200>
[ERROR]   JAXRSHttpHeadersTest.testRequestHeaderSingleValue:338->JaxrsTest.assertStatusCode:82 expected:<404> but was:<200>

I didn’t had to time to have a look into them yet. I’ll try to check them out. If you have a few cycles, maybe you can help :)

Cheers,
Roberto

> On 8 Feb 2019, at 09:59, j4fm <ja...@my-managed.net> wrote:
> 
> Hey how's it going with the buildbot failures? Anything I could help with
> (not an expert on this but willing to have a look and learn)?  Do you have
> any thoughts on root cause(s)?
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hey how's it going with the buildbot failures? Anything I could help with
(not an expert on this but willing to have a look and learn)?  Do you have
any thoughts on root cause(s)?



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Great! Thank you again. Looks ok. Let me review it and run some tests locally.

Cheers,
Roberto

> On 7 Feb 2019, at 00:01, j4fm <ja...@my-managed.net> wrote:
> 
> Submitted PR 388 to branch TOMEE-2408
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Submitted PR 388 to branch TOMEE-2408



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Good news is the metrics failures have gone but it's still failing for some
reason.  Any ideas why?

I know one tweak I made recently was changing the .startsWith("*") to
.equals("*"). While I'm not certain if that would break other scenarios, I
just don't like changing something like that because, like I said... I just
don't know about other scenarios - even though it works for me.  So I have
undone that (it was bugging me) and am offering a (hopefully you'll agree)
better solution...

I really think the problem is the CXFJAXRSFilter approach itself.  Currently
it tries to process most stuff itself because the logic for ruling out
non-CXF requests seems to be flaweed.

So I've written out the fix I had in mind.  I've thought about this and
think it's the best approach to be robust and play nicely with existing non
CXF apps - leaving them untouched and non-interfering.

I've added a function "isCXFResource(request)" to the CxfRsHttpListener
which the filter calls to check if the servletpath is a registered CXF
endpoint.  If it is not, it passes on down the chain completely untouched
which means all existing non-CXF should work 100% as before.

I've also left the existing logic for CXF apps exactly as before for when it
is actually a CXF app.  That logic makes sense there e.g. when static
content exists in a path that also a CXF app.

Just tested this now for the all the apps I have here and it's the first
time everything works 100% and CXF plays nicely with existing webapps too.

I know I'm not aware of all the scenarios, but I think this has to be best
approach for any filter...  it should leave what it shouldn't be concerned
about untouched and not make it it's own business.

So I will shortly submit a PR for this against TOMEE-2408 for review and
consideration. :)

I'm hoping this may also help with buildbot.  JSP will now work with MP
enabled at least :)



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Thank you! Merged!

> On 6 Feb 2019, at 17:18, j4fm <ja...@my-managed.net> wrote:
> 
> Created PR #387
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Created PR #387



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Great! Let’s try to have the build passing and then figure something better :)

Thank you for all your hard work! Would you like to submit that as a PR?

> On 6 Feb 2019, at 16:22, j4fm <ja...@my-managed.net> wrote:
> 
> Just fyi, harcoded the metrics jar filename as a quick test and it is now
> adding the metrics endpoints just fine.  So that's the only issue with this
> one.  So a fix for this will help make buildbot happier. :)
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Just fyi, harcoded the metrics jar filename as a quick test and it is now
adding the metrics endpoints just fine.  So that's the only issue with this
one.  So a fix for this will help make buildbot happier. :)



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

If I read you correctly, I thought about that as a quick solution but the
problem is the prefixes can be no more specific just because of the
filenames used.

geronimo-metrics-x.x.x.jar
geronimo-metrics-common-x.x.x.jar

If both prefixes are added to the list, both will return
"geronimo-metrics-common" in my case, so common will be added twice.

Looking at the existing library code, the only option is to add (eek
hard-code:/) the full filename of the metrics one including version number
(or rename the metrics files to be the consistent with
geronimo-openapi-impl-x.x.x.jar guess that's out of the question)

I suspect maybe the jar search library needs enhancing or a different
approach is needed completely to finding out the jars.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Ahaha, good catch! 

I was suspecting it might be something like that. Because on my box and other boxes I’ve tried it works fine. The problem is the file list order from the filesystem which is system or even hardware dependant, so it will work in some systems and others it will fail :)

I think an easy fix is to just add both prefix libraries in TomEEMicroProfileListener. Only the non common jar needs to be scanned, so we are adding an extra library that doesn’t need scanning, but we can think about it later. We probably need to do the same with health, since it also includes a common jar.

Thank you for your help :)

> On 6 Feb 2019, at 15:07, j4fm <ja...@my-managed.net> wrote:
> 
> Finally got a chance to run through it.  Found it, should be pretty straight
> forward to fix metrics.  It's just because the MP prefix list causes
> duplicate matches i.e. there are two jars beginning geronimo-metrics-
> (impl+common).  It only finds the first (geronimo-metrics-common).  Health
> only works by chance because it picks up the impl before the common one.
> 
> I don't mind giving it a shot or can you may be quicker at it, let me know?
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Finally got a chance to run through it.  Found it, should be pretty straight
forward to fix metrics.  It's just because the MP prefix list causes
duplicate matches i.e. there are two jars beginning geronimo-metrics-
(impl+common).  It only finds the first (geronimo-metrics-common).  Health
only works by chance because it picks up the impl before the common one.

I don't mind giving it a shot or can you may be quicker at it, let me know?



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I'm also looking into things here to help out.  Will submit a PR to
TOMEE-2408 if I get anything



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Yes, it seems there is something weird going on with the metrics. Trying to have a look.

> On 5 Feb 2019, at 23:45, j4fm <ja...@my-managed.net> wrote:
> 
> I could be wrong but a larger number of tests are failing because the Metrics
> Endpoint is not being added now as I mentioned.
> 
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I could be wrong but a larger number of tests are failing because the Metrics
Endpoint is not being added now as I mentioned.




--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Just looking at the buildbot logs now.  One of the exceptions is because of
the geronimo openapi issue that I mentioned, that I got to the bottom of
over the last couple of days.  When geronimo openapi is updated to what's in
their master now, this one will go away.

i.e. this one...

ava.util.logging.ErrorManager: 5
java.lang.NullPointerException
	at
java.util.PropertyResourceBundle.handleGetObject(PropertyResourceBundle.java:166)
	at java.util.ResourceBundle.getObject(ResourceBundle.java:441)
..
SEVERE - Method setApplication can not be accessed due to security manager
restrictions
SEVERE - error invoking
org.apache.tomee.webservices.TomeeJaxRsService@7c417213
org.apache.cxf.service.factory.ServiceConstructionException
	at
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:225)




--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Thanks!

1 - I guess we need to move to that approach eventually. Lets try to stabilise everything else first so we can concentrate on that one. There are some failing tests on the build bot that I’m unable to reproduce locally. So, I need to figure that out.

2 - The only thing I can think of, is the guarding code here org.apache.tomee.microprofile.TomEEMicroProfileListener#processApplication. Can you confirm that the endpoints are not being removed there for some reason for that particular app?

Cheers,
Roberto

> On 5 Feb 2019, at 16:31, j4fm <ja...@my-managed.net> wrote:
> 
> Awesome, the Geronimo OpenAPI related exception is now resolved.  Just need
> to get their next release when available.
> 
> Two more things:
> 
> 1) Found another case as an issue with the CXFJAXRSFilter... a webapp with
> /path/subpath/page.jsp.  This is coming back with the same 404 as
> previously.  This won't work with the default welcome pages.  I'm looking
> into this for a better solution/suggestion.  It may be better and safer to
> do what I suggested and have the CXFJAXRSFilter only process it's own
> endpoints, and forward everything else down the chain.
> 
> 2) On the REST application that is now working with the OpenAPI fix, I
> notice this is and never has been any MP related endpoints added.  I don't
> think there is any root servlet in place.  Any thoughts what could stop them
> being added? All the other webapps do have them added.
> 
> Thanks
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Awesome, the Geronimo OpenAPI related exception is now resolved.  Just need
to get their next release when available.

Two more things:

1) Found another case as an issue with the CXFJAXRSFilter... a webapp with
/path/subpath/page.jsp.  This is coming back with the same 404 as
previously.  This won't work with the default welcome pages.  I'm looking
into this for a better solution/suggestion.  It may be better and safer to
do what I suggested and have the CXFJAXRSFilter only process it's own
endpoints, and forward everything else down the chain.

2) On the REST application that is now working with the OpenAPI fix, I
notice this is and never has been any MP related endpoints added.  I don't
think there is any root servlet in place.  Any thoughts what could stop them
being added? All the other webapps do have them added.

Thanks



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Metrics should be there. I’ll see what is going on.

Hum, I wonder if the event is being added multiple times. I’ll investigate. Thanks :)

> On 5 Feb 2019, at 02:01, j4fm <ja...@my-managed.net> wrote:
> 
> Few observations:
> - The start time does seem to be reduced (will check again properly
> tomorrow)
> - I no longer see Metrics endpoints.  Is that intended?  Metrics endpoints
> were being added before now.
> - I only see one server URI/endpoint for Health and one for OpenAPI.
> - I see too many log occurrences of:
> 
> INFO [main] org.apache.openejb.util.OptionsLog.info Using
> 'tomee.mp.scan=all'
> INFO [main] org.apache.openejb.util.OptionsLog.info Using
> 'tomee.mp.scan=all'
> INFO [main] org.apache.openejb.util.OptionsLog.info Using
> 'tomee.mp.scan=all'
> INFO [main] org.apache.openejb.util.OptionsLog.info Using
> 'tomee.mp.scan=all'
> INFO [main] org.apache.openejb.util.OptionsLog.info Using
> 'tomee.mp.scan=all'
> 
> For the first context starting, this log entry occurs once.  For the 2nd
> context, it appears twice in a row.  Then for the last one (17th).  It
> appears as a list of 17 in a row.  Nobody will miss the fact this setting is
> enabled, that's for sure! :D
> 
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Few observations:
- The start time does seem to be reduced (will check again properly
tomorrow)
- I no longer see Metrics endpoints.  Is that intended?  Metrics endpoints
were being added before now.
- I only see one server URI/endpoint for Health and one for OpenAPI.
- I see too many log occurrences of:

INFO [main] org.apache.openejb.util.OptionsLog.info Using
'tomee.mp.scan=all'
INFO [main] org.apache.openejb.util.OptionsLog.info Using
'tomee.mp.scan=all'
INFO [main] org.apache.openejb.util.OptionsLog.info Using
'tomee.mp.scan=all'
INFO [main] org.apache.openejb.util.OptionsLog.info Using
'tomee.mp.scan=all'
INFO [main] org.apache.openejb.util.OptionsLog.info Using
'tomee.mp.scan=all'

For the first context starting, this log entry occurs once.  For the 2nd
context, it appears twice in a row.  Then for the last one (17th).  It
appears as a list of 17 in a row.  Nobody will miss the fact this setting is
enabled, that's for sure! :D




--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Ok, I think I’m now done with the issue I’ve found.

I’ve merged your changes. Thank you. Lets see what buildbot says.

Also, you noticed earlier that TomEE startup was a little bit slower. I suspect is because some additional scanning is being done. I’ve tried to remove part of it and I think it can still be improved. Let me know if you notice any improvements.

Cheers,
Roberto

> On 4 Feb 2019, at 16:41, Roberto Cortez <ra...@yahoo.com.INVALID> wrote:
> 
> I’m trying to fix a CDI issue that I’ve found . I think I found the problem. Once I’m done, I’ll add James fix as well.
> 
>> On 4 Feb 2019, at 15:44, Bruno Baptista <br...@gmail.com> wrote:
>> 
>> Thanks James.
>> 
>> Will also take a look.
>> 
>> Bruno Baptista
>> https://twitter.com/brunobat_
>> 
>> 
>> On 04/02/19 15:33, j4fm wrote:
>>> I came across that same problem and solved it.  I already created a PR to fix
>>> the new piece of code that was merged recently.  It's just waiting for
>>> Roberto to merge it (into 2408 branch and then into master).
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> 

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

I’m trying to fix a CDI issue that I’ve found . I think I found the problem. Once I’m done, I’ll add James fix as well.

> On 4 Feb 2019, at 15:44, Bruno Baptista <br...@gmail.com> wrote:
> 
> Thanks James.
> 
> Will also take a look.
> 
> Bruno Baptista
> https://twitter.com/brunobat_
> 
> 
> On 04/02/19 15:33, j4fm wrote:
>> I came across that same problem and solved it.  I already created a PR to fix
>> the new piece of code that was merged recently.  It's just waiting for
>> Roberto to merge it (into 2408 branch and then into master).
>> 
>> 
>> 
>> --
>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Bruno Baptista <br...@gmail.com>]

Thanks James.

Will also take a look.

Bruno Baptista
https://twitter.com/brunobat_


On 04/02/19 15:33, j4fm wrote:
> I came across that same problem and solved it.  I already created a PR to fix
> the new piece of code that was merged recently.  It's just waiting for
> Roberto to merge it (into 2408 branch and then into master).
>
>
>
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I came across that same problem and solved it.  I already created a PR to fix
the new piece of code that was merged recently.  It's just waiting for
Roberto to merge it (into 2408 branch and then into master).



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Bruno Baptista <br...@gmail.com>]

I'm playing with TomEE plus with a pure JAX-RS app and it fails to deploy:

04-Feb-2019 15:19:53.846 SEVERE [main] 
org.apache.catalina.core.StandardContext.filterStart Exception starting 
filter [opentracing] java.lang.NullPointerException at 
org.apache.geronimo.microprofile.opentracing.microprofile.server.OpenTracingFilter.init(OpenTracingFilter.java:57) 
at 
org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:270)

We should probably revert the lib.

Bruno Baptista
https://twitter.com/brunobat_


On 04/02/19 11:28, j4fm wrote:
> Raised GERONIMO-6692 for anybody else who might stumble across this same
> issue in future.
>
>
>
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Raised GERONIMO-6692 for anybody else who might stumble across this same
issue in future.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Good catch on the configuration property. I’ll merge your change :)

Apparently, there is something broken with the CDI TCK, so I’m trying to get to the bottom of it.

Yes please, add an issue on Geronimo OpenAPI.

Thank you!

> On 4 Feb 2019, at 09:54, j4fm <ja...@my-managed.net> wrote:
> 
> FYI, got to the bottom of the last MP issue I am seeing too.
> 
> It turns out with the one webapp, that Geronimo OpenAPI scans and results in
> the StackOverflow exception there is this:
> 
> public class aClass
> {
> ...
>  List<aClass> aList;
> ...
> }
> 
> This causes OpenAPI to recurse infinitely.  Will log a ticket with Geronimo
> OpenAPI.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

FYI, got to the bottom of the last MP issue I am seeing too.

It turns out with the one webapp, that Geronimo OpenAPI scans and results in
the StackOverflow exception there is this:

public class aClass
{
...
  List<aClass> aList;
...
}

This causes OpenAPI to recurse infinitely.  Will log a ticket with Geronimo
OpenAPI.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Line 49.  Defaults to "all" when not set i.e. for Plus.  I changed it and
included it in my PR for your branch.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Isn’t it "none"?

https://github.com/apache/tomee/blob/48bb9101c8b2aa1010e9462a4088985edf44c1af/tomee/tomee-microprofile/mp-common/src/main/java/org/apache/tomee/microprofile/config/TomEEConfigSource.java#L50 <https://github.com/apache/tomee/blob/48bb9101c8b2aa1010e9462a4088985edf44c1af/tomee/tomee-microprofile/mp-common/src/main/java/org/apache/tomee/microprofile/config/TomEEConfigSource.java#L50>


> On 3 Feb 2019, at 18:34, j4fm <ja...@my-managed.net> wrote:
> 
> That fixed it.  With default Plus clone now everything starts okay.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

That fixed it.  With default Plus clone now everything starts okay.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I think
tomee-microprofile/mp-common/src/main/java/org/apache/tomee/microprofile/config/TomEEConfigSource.java
Line 50 should be "none", not "all"





--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Fresh clone from master since your change and running Plus, I get:

SEVERE [main] org.apache.catalina.core.StandardContext.filterStart Exception
starting filter [opentracing]
 javax.enterprise.inject.UnsatisfiedResolutionException: Api type
[org.apache.geronimo.microprofile.opentracing.impl.ScopeManagerImpl] is not
found with the qualifiers
Qualifiers: [@javax.enterprise.inject.Default()]
for injection into Field Injection Point, field name :  manager, Bean Owner
: [OpenTracingFilter, WebBeansType:DEPENDENT, Name:null, API
Types:[javax.servlet.Filter,java.lang.Object,org.apache.geronimo.microprofile.opentracing.microprofile.server.OpenTracingFilter],
Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]]
        at
org.apache.webbeans.util.InjectionExceptionUtil.throwUnsatisfiedResolutionException(InjectionExceptionUtil.java:60)
        at
org.apache.webbeans.container.InjectionResolver.getInjectionPointBean(InjectionResolver.java:292)
        at
org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:79)
        at
org.apache.webbeans.inject.InjectableField.doInjection(InjectableField.java:65)
        at
org.apache.webbeans.portable.InjectionTargetImpl.injectFields(InjectionTargetImpl.java:227)
        at
org.apache.webbeans.portable.InjectionTargetImpl.inject(InjectionTargetImpl.java:213)
        at
org.apache.webbeans.portable.InjectionTargetImpl.inject(InjectionTargetImpl.java:203)
        at
org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:126)
        at
org.apache.openejb.core.WebContext.newWeakableInstance(WebContext.java:153)
        at
org.apache.openejb.core.WebContext.newInstance(WebContext.java:181)
        at
org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:78)
        at
org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:124)
        at
org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:119)
        at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:249)
        at
org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:102)
        at
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4491)
        at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5135)
        at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
        at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743)
        at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719)
        at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:703)
        at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:630)
        at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1840)
        at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
        at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
        at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
        at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:525)
        at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:424)
        at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1585)
        at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:308)
        at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
        at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:424)
        at
org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:367)
        at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:969)
        at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:839)
        at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
        at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1429)
        at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
        at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
        at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
        at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:944)
        at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:261)
        at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
        at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:422)
        at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
        at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:770)
        at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:682)
        at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
        at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:350)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Awesome, just starting back on this now.  I will do local test on your merge
to master first - I feel this will work as an important basic start for
managing risk for existing Plus/Plume based webapps.

I didn't get so far with the one REST webapp that's conflicting with
OpenAPI's functionality.  It's loading quite a number of classes in the
application so maybe it's one of those that's causing an issue.  I will
spend more time on that later, but feel it's separate enough to add the PR
you asked for with the tweaks I made so far.  So I will do that now.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Hey,

I’ve now added the ability to turn on / off MP on Plume or Plus with the configuration property “tomee.mp.scan” [none|all]. For now, it only works for the entire server, so you can’t use it locally for a single application, but I plan to add the support for it as well. Also, its either all the specs or none, but I also plan to support selectively pick the specs.

Even with the flag turned on, Plus and Plume seem pretty stable, but I left it disabled by default. MicroProfile flavour is on of course.

I merged everything to master so we can have a builedbot build and see how it looks like.

Cheers,
Roberto

> On 1 Feb 2019, at 21:42, j4fm <ja...@my-managed.net> wrote:
> 
> This GeronimoOpenAPIExtension.java line 150.
> 
>         return openapis.computeIfAbsent(application,
>                    app -> createOpenApi(application.getClass(),
> Stream.concat(endpoints.stream().map(Bean::getBeanClass),
>                            Stream.concat(app.getClasses().stream(),
> app.getSingletons().stream().map(Object::getClass)))));
> 
> Is what triggers the access exception.
> 
> I see the classes list on the application for this one does not include MP
> classes when it gets there.  So I suspected that it's overriding getClasses
> and it is.
> 
> So I expect that is the problem.  I am going to do a test fix for the
> specific REST application in question and see.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

This GeronimoOpenAPIExtension.java line 150.

         return openapis.computeIfAbsent(application,
                    app -> createOpenApi(application.getClass(),
Stream.concat(endpoints.stream().map(Bean::getBeanClass),
                            Stream.concat(app.getClasses().stream(),
app.getSingletons().stream().map(Object::getClass)))));

Is what triggers the access exception.

I see the classes list on the application for this one does not include MP
classes when it gets there.  So I suspected that it's overriding getClasses
and it is.

So I expect that is the problem.  I am going to do a test fix for the
specific REST application in question and see.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Oddly, even though r=null, the InjectionUtils.java line 376 is executed right
after if (r != null) {

no method return value
requestObject	OpenAPIFilter  (id=669)	
method	Method  (id=671)	
parameterValue	InternalApplication  (id=677)	
inMessage	null	
ex	InvocationTargetException  (id=787)	
	backtrace	Object[5]  (id=814)	
	cause	null	
	depth	71	
	detailMessage	null	
	stackTrace	StackTraceElement[0]  (id=815)	
	suppressedExceptions	Collections$EmptyList<E>  (id=816)	
	target	StackOverflowError  (id=776)	
		backtrace	Object[5]  (id=823)	
			[0]	(id=824)	
			[1]	(id=826)	
			[2]	Object[32]  (id=828)	
				[0]	Class<T> (java.lang.String) (id=634)	
				[1]	Class<T> (java.lang.String) (id=634)	
				[2]	Class<T> (sun.reflect.generics.parser.SignatureParser) (id=832)	
				[3]	Class<T> (sun.reflect.generics.parser.SignatureParser) (id=832)	
				[4]	Class<T> (sun.reflect.generics.parser.SignatureParser) (id=832)	
				[5]	Class<T> (sun.reflect.generics.parser.SignatureParser) (id=832)	
				[6]	Class<T> (sun.reflect.generics.parser.SignatureParser) (id=832)	
				[7]	Class<T> (sun.reflect.generics.parser.SignatureParser) (id=832)	
				[8]	Class<T> (sun.reflect.generics.parser.SignatureParser) (id=832)	
				[9]	Class<T> (sun.reflect.generics.parser.SignatureParser) (id=832)	
				[10]	Class<T> (sun.reflect.generics.repository.FieldRepository) (id=833)	
				[11]	Class<T> (sun.reflect.generics.repository.FieldRepository) (id=833)	
				[12]	Class<T> (sun.reflect.generics.repository.AbstractRepository)
(id=630)	
				[13]	Class<T> (sun.reflect.generics.repository.FieldRepository) (id=833)	
				[14]	Class<T> (sun.reflect.generics.repository.FieldRepository) (id=833)	
				[15]	Class<T> (java.lang.reflect.Field) (id=834)	
				[16]	Class<T> (java.lang.reflect.Field) (id=834)	
				[17]	Class<T>
(org.apache.geronimo.microprofile.openapi.impl.processor.SchemaProcessor)
(id=835)	
				[18]	Class<T> (java.util.Optional) (id=836)	
				[19]	Class<T>
(org.apache.geronimo.microprofile.openapi.impl.processor.SchemaProcessor)
(id=835)	
				[20]	Class<T>
(org.apache.geronimo.microprofile.openapi.impl.processor.SchemaProcessor)
(id=835)	
				[21]	Class<T> (java.util.stream.ForEachOps$ForEachOp$OfRef) (id=837)	
				[22]	Class<T> (java.util.stream.ReferencePipeline$11$1) (id=838)	
				[23]	Class<T> (java.util.stream.ReferencePipeline$2$1) (id=839)	
				[24]	Class<T> (java.util.Spliterators$ArraySpliterator) (id=840)	
				[25]	Class<T> (java.util.stream.AbstractPipeline) (id=841)	
				[26]	Class<T> (java.util.stream.AbstractPipeline) (id=841)	
				[27]	Class<T> (java.util.stream.ForEachOps$ForEachOp) (id=842)	
				[28]	Class<T> (java.util.stream.ForEachOps$ForEachOp$OfRef) (id=837)	
				[29]	Class<T> (java.util.stream.AbstractPipeline) (id=841)	
				[30]	Class<T> (java.util.stream.ReferencePipeline) (id=843)	
				[31]	Class<T>
(org.apache.geronimo.microprofile.openapi.impl.processor.SchemaProcessor)
(id=835)	
			[3]	(id=829)	
			[4]	Object[5]  (id=831)	
		cause	null	
		depth	1024	
		detailMessage	null	
		stackTrace	null	
		suppressedExceptions	null	
r	null	



type() returned	ResponseBuilderImpl  (id=4408)	
messageName	"METHOD_ACCESS_FAILURE" (id=4398)	
parameter	"setApplication" (id=4397)	
logError	true	
errorMessage	Message  (id=4405)	
	bundle	PropertyResourceBundle  (id=797)	
	code	"METHOD_ACCESS_FAILURE" (id=4398)	
	parameters	Object[1]  (id=4413)	


Hopefully something is useful



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Can you paste the full stacktrace anyway?

> On 1 Feb 2019, at 18:52, j4fm <ja...@my-managed.net> wrote:
> 
> When debugging, it's stuck calling with an illegalaccessexception on
> 
> public void
> org.apache.geronimo.microprofile.openapi.jaxrs.OpenAPIFilter.setApplication(javax.ws.rs.core.Application)
> 
> Not really much more detail than backtrace is a StackOverflow exception.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

When debugging, it's stuck calling with an illegalaccessexception on

public void
org.apache.geronimo.microprofile.openapi.jaxrs.OpenAPIFilter.setApplication(javax.ws.rs.core.Application)

Not really much more detail than backtrace is a StackOverflow exception.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Darn it, I thought updating CXF 3.2.8 had fixed it but no, I had forgotten I
turned off openapi filter.

False alarm



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Interesting. So, we may need to update CFX to 3.2.8. I wonder what they changed that fixed the issue.

In the meanwhile I’ve been exploring a few ways to make MP libraries discovery more streamlined so we can then apply configuration to control deployment.

> On 1 Feb 2019, at 18:38, j4fm <ja...@my-managed.net> wrote:
> 
> Sure, that makes sense I will do that.
> 
> I was seeing StackOverflowException and still setApplication accessor
> exceptions.
> 
> However, I updated locally CXF to 3.2.8 and the problem has gone away :)
> 
> So I have openapi.impl 1.0.5, cxf 3.2.8 with your and my tweaks and it's all
> playing nicely!
> 
> Now on to that PR! :)
> 
> Thanks!
> 
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Sure, that makes sense I will do that.

I was seeing StackOverflowException and still setApplication accessor
exceptions.

However, I updated locally CXF to 3.2.8 and the problem has gone away :)

So I have openapi.impl 1.0.5, cxf 3.2.8 with your and my tweaks and it's all
playing nicely!

Now on to that PR! :)

Thanks!




--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Great,

Since I don’t want to merge this yet, I’ve pushed my PR to a separate branch in the apache repo:
https://github.com/apache/tomee/tree/TOMEE-2408 <https://github.com/apache/tomee/tree/TOMEE-2408>

This should be easier for you to collaborate. Just checkout the branch make your changes and submit a PR for that branch. When we are happy we can merge everything back to master.

Regarding the  "setApplication can not be accessed due to security manager restrictions”, as far as I remember this is not the right exception. The actual exception is being caught up in CXF and then passed to the user with that misleading error. If I remember correctly, you need to check the actual exception here: org.apache.cxf.jaxrs.utils.InjectionUtils#reportServerError(java.lang.String, java.lang.String, boolean)

Cheers,
Roberto

> On 1 Feb 2019, at 15:21, j4fm <ja...@my-managed.net> wrote:
> 
> Right, so I can help with:
> - add to the test case you created (/subpath/ location without document name
> and *.abc servlet path);
> - create a PR;
> - troubleshoot the "setApplication can not be accessed due to security
> manager restrictions" issue for existing REST app... though I've seen that
> one mentioned previously in this
> http://tomee-openejb.979440.n4.nabble.com/TomEE-8-Release-Preview-td4684813.html
> thread too... same issue?
> 
> How/where do I start?
> 
> Thanks
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Right, so I can help with:
- add to the test case you created (/subpath/ location without document name
and *.abc servlet path);
- create a PR;
- troubleshoot the "setApplication can not be accessed due to security
manager restrictions" issue for existing REST app... though I've seen that
one mentioned previously in this
http://tomee-openejb.979440.n4.nabble.com/TomEE-8-Release-Preview-td4684813.html
thread too... same issue?

How/where do I start?

Thanks



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

In servletMappingIsUnderRestPath:

mappingByServlet contains:
{StandardEngine[Catalina].StandardHost[localhost].StandardContext[/home].StandardWrapper[CustomServlet]=false,
StandardEngine[Catalina].StandardHost[localhost].StandardContext[/home].StandardWrapper[default]=false}

wrapper =
StandardEngine[Catalina].StandardHost[localhost].StandardContext[/home].StandardWrapper[CustomServlet]

So the result is still false.
I'm not sure how the mappingByServlet is populated with false?




--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Great! Thank you for the pointers.

I’ll help you out tomorrow for your contribution :) You just need to submit a PR.

> On 1 Feb 2019, at 00:03, j4fm <ja...@my-managed.net> wrote:
> 
> Will be happy to contribute as I've not had to before, not sure how to start
> though.  Will also pick that up tomorrow.
> 
> Right now, I just had to get something actually working locally to ensure it
> will work.  And actually have success!  Thank you for your help getting to
> the bottom of these blocking niggles, hoping they can be solved for TomEE 8
> M3.  Happy to help with test cases and tickets as needed.
> 
> I changed findStaticContent (Line 284 onwards):
>        if (pathInfo.endsWith("/") || pathInfo.isEmpty()) { // root is
> redirected to welcomefiles
>            if (pathInfo.endsWith("/")) {
>              pathInfo = pathInfo.substring(0, pathInfo.length() - 1);
>            }
>            for (final String n : welcomeFiles) {
>                final InputStream is =
> request.getServletContext().getResourceAsStream(pathInfo + n);
>                if (is != null) {
>                    return is;
>                }
>            }
> 
> This now returns default welcome pages for sub-paths too.
> 
> I changed CXFJAXRSFilter (Line 124):
> !mapping.startsWith("*") to !mapping.equals("*")
> 
> (again this is just to get it through to test beyond these).
> 
> Everything seems to be up and running now there is just one exception
> remaining (with the filters enabled again) with one webapp which is actually
> an existing JAX-RS web app:
> 
> java.util.logging.ErrorManager: 5
> java.lang.NullPointerException
>  at
> java.base/java.util.PropertyResourceBundle.handleGetObject(PropertyResourceBundle.java:207)
>  at java.base/java.util.ResourceBundle.getObject(ResourceBundle.java:555)
>  at java.base/java.util.ResourceBundle.getString(ResourceBundle.java:521)
>  at
> java.logging/java.util.logging.Formatter.formatMessage(Formatter.java:118)
>  at org.apache.juli.OneLineFormatter.format(OneLineFormatter.java:140)
>  at org.apache.juli.FileHandler.publish(FileHandler.java:282)
>  at
> org.apache.juli.AsyncFileHandler.publishInternal(AsyncFileHandler.java:146)
>  at
> org.apache.juli.AsyncFileHandler$LogEntry.flush(AsyncFileHandler.java:185)
>  at
> org.apache.juli.AsyncFileHandler$LoggerThread.run(AsyncFileHandler.java:161)
> java.util.logging.ErrorManager: 5
> java.lang.NullPointerException
>  at
> java.base/java.util.PropertyResourceBundle.handleGetObject(PropertyResourceBundle.java:207)
>  at java.base/java.util.ResourceBundle.getObject(ResourceBundle.java:555)
>  at java.base/java.util.ResourceBundle.getString(ResourceBundle.java:521)
>  at
> java.logging/java.util.logging.Formatter.formatMessage(Formatter.java:118)
>  at org.apache.juli.OneLineFormatter.format(OneLineFormatter.java:140)
>  at
> java.logging/java.util.logging.StreamHandler.publish(StreamHandler.java:199)
>  at
> java.logging/java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:95)
>  at
> org.apache.tomee.jul.formatter.AsyncConsoleHandler.publishInternal(AsyncConsoleHandler.java:37)
>  at
> org.apache.juli.AsyncFileHandler$LogEntry.flush(AsyncFileHandler.java:185)
>  at
> org.apache.juli.AsyncFileHandler$LoggerThread.run(AsyncFileHandler.java:161)
> 31-Jan-2019 23:26:03.075 SEVERE [main]
> org.apache.cxf.jaxrs.utils.InjectionUtils.reportServerError Method
> setApplication can not be accessed due to security manager restrictions
> 31-Jan-2019 23:26:03.100 SEVERE [main]
> org.apache.openejb.observer.ObserverManager$MethodInvocation.invoke error
> invoking org.apache.tomee.webservices.TomeeJaxRsService@5db4c359
> org.apache.cxf.service.factory.ServiceConstructionException
>  at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:225)
>  at
> org.apache.openejb.server.cxf.rs.CxfRsHttpListener.deployApplication(CxfRsHttpListener.java:641)
> 
> 
> Caused by: javax.ws.rs.InternalServerErrorException: HTTP 500 Internal
> Server Error
>  at
> org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79)
>  at
> org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111)
>  at
> org.apache.cxf.jaxrs.utils.InjectionUtils.reportServerError(InjectionUtils.java:554)
>  at
> org.apache.cxf.jaxrs.utils.InjectionUtils.reportServerError(InjectionUtils.java:540)
>  at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectThroughMethod(InjectionUtils.java:376)
>  at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectThroughMethod(InjectionUtils.java:357)
>  at
> org.apache.cxf.jaxrs.utils.InjectionUtils.injectContextProxiesAndApplication(InjectionUtils.java:1152)
>  at
> org.apache.cxf.jaxrs.provider.ProviderFactory.injectContextProxiesIntoProvider(ProviderFactory.java:655)
>  at
> org.apache.cxf.jaxrs.provider.ServerProviderFactory.injectContextProxiesIntoProvider(ServerProviderFactory.java:310)
>  at
> org.apache.cxf.jaxrs.provider.ProviderFactory.injectContextProxies(ProviderFactory.java:644)
>  at
> org.apache.cxf.jaxrs.provider.ServerProviderFactory.setProviders(ServerProviderFactory.java:275)
>  at
> org.apache.cxf.jaxrs.provider.ProviderFactory.setUserProviders(ProviderFactory.java:789)
>  at
> org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.setupFactory(AbstractJAXRSFactoryBean.java:332)
>  at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setupFactory(JAXRSServerFactoryBean.java:243)
>  at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:182)
> 
> But I will look into this one tomorrow.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Will be happy to contribute as I've not had to before, not sure how to start
though.  Will also pick that up tomorrow.

Right now, I just had to get something actually working locally to ensure it
will work.  And actually have success!  Thank you for your help getting to
the bottom of these blocking niggles, hoping they can be solved for TomEE 8
M3.  Happy to help with test cases and tickets as needed.

I changed findStaticContent (Line 284 onwards):
        if (pathInfo.endsWith("/") || pathInfo.isEmpty()) { // root is
redirected to welcomefiles
            if (pathInfo.endsWith("/")) {
              pathInfo = pathInfo.substring(0, pathInfo.length() - 1);
            }
            for (final String n : welcomeFiles) {
                final InputStream is =
request.getServletContext().getResourceAsStream(pathInfo + n);
                if (is != null) {
                    return is;
                }
            }

This now returns default welcome pages for sub-paths too.

I changed CXFJAXRSFilter (Line 124):
 !mapping.startsWith("*") to !mapping.equals("*")

(again this is just to get it through to test beyond these).

Everything seems to be up and running now there is just one exception
remaining (with the filters enabled again) with one webapp which is actually
an existing JAX-RS web app:

java.util.logging.ErrorManager: 5
java.lang.NullPointerException
  at
java.base/java.util.PropertyResourceBundle.handleGetObject(PropertyResourceBundle.java:207)
  at java.base/java.util.ResourceBundle.getObject(ResourceBundle.java:555)
  at java.base/java.util.ResourceBundle.getString(ResourceBundle.java:521)
  at
java.logging/java.util.logging.Formatter.formatMessage(Formatter.java:118)
  at org.apache.juli.OneLineFormatter.format(OneLineFormatter.java:140)
  at org.apache.juli.FileHandler.publish(FileHandler.java:282)
  at
org.apache.juli.AsyncFileHandler.publishInternal(AsyncFileHandler.java:146)
  at
org.apache.juli.AsyncFileHandler$LogEntry.flush(AsyncFileHandler.java:185)
  at
org.apache.juli.AsyncFileHandler$LoggerThread.run(AsyncFileHandler.java:161)
java.util.logging.ErrorManager: 5
java.lang.NullPointerException
  at
java.base/java.util.PropertyResourceBundle.handleGetObject(PropertyResourceBundle.java:207)
  at java.base/java.util.ResourceBundle.getObject(ResourceBundle.java:555)
  at java.base/java.util.ResourceBundle.getString(ResourceBundle.java:521)
  at
java.logging/java.util.logging.Formatter.formatMessage(Formatter.java:118)
  at org.apache.juli.OneLineFormatter.format(OneLineFormatter.java:140)
  at
java.logging/java.util.logging.StreamHandler.publish(StreamHandler.java:199)
  at
java.logging/java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:95)
  at
org.apache.tomee.jul.formatter.AsyncConsoleHandler.publishInternal(AsyncConsoleHandler.java:37)
  at
org.apache.juli.AsyncFileHandler$LogEntry.flush(AsyncFileHandler.java:185)
  at
org.apache.juli.AsyncFileHandler$LoggerThread.run(AsyncFileHandler.java:161)
31-Jan-2019 23:26:03.075 SEVERE [main]
org.apache.cxf.jaxrs.utils.InjectionUtils.reportServerError Method
setApplication can not be accessed due to security manager restrictions
31-Jan-2019 23:26:03.100 SEVERE [main]
org.apache.openejb.observer.ObserverManager$MethodInvocation.invoke error
invoking org.apache.tomee.webservices.TomeeJaxRsService@5db4c359
 org.apache.cxf.service.factory.ServiceConstructionException
  at
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:225)
  at
org.apache.openejb.server.cxf.rs.CxfRsHttpListener.deployApplication(CxfRsHttpListener.java:641)
  
  
Caused by: javax.ws.rs.InternalServerErrorException: HTTP 500 Internal
Server Error
  at
org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79)
  at
org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111)
  at
org.apache.cxf.jaxrs.utils.InjectionUtils.reportServerError(InjectionUtils.java:554)
  at
org.apache.cxf.jaxrs.utils.InjectionUtils.reportServerError(InjectionUtils.java:540)
  at
org.apache.cxf.jaxrs.utils.InjectionUtils.injectThroughMethod(InjectionUtils.java:376)
  at
org.apache.cxf.jaxrs.utils.InjectionUtils.injectThroughMethod(InjectionUtils.java:357)
  at
org.apache.cxf.jaxrs.utils.InjectionUtils.injectContextProxiesAndApplication(InjectionUtils.java:1152)
  at
org.apache.cxf.jaxrs.provider.ProviderFactory.injectContextProxiesIntoProvider(ProviderFactory.java:655)
  at
org.apache.cxf.jaxrs.provider.ServerProviderFactory.injectContextProxiesIntoProvider(ServerProviderFactory.java:310)
  at
org.apache.cxf.jaxrs.provider.ProviderFactory.injectContextProxies(ProviderFactory.java:644)
  at
org.apache.cxf.jaxrs.provider.ServerProviderFactory.setProviders(ServerProviderFactory.java:275)
  at
org.apache.cxf.jaxrs.provider.ProviderFactory.setUserProviders(ProviderFactory.java:789)
  at
org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.setupFactory(AbstractJAXRSFactoryBean.java:332)
  at
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setupFactory(JAXRSServerFactoryBean.java:243)
  at
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:182)

But I will look into this one tomorrow.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

I wonder why that check is there. What is it trying to prevent?

In the meanwhile I was trying to figure out another issue with the tomee webapp deployment, since it is failing the tests and I don’t want to move into changing that without making sure every test is passing.

Would it be possible for you to contribute to the Test Case that I wrote, with those details, so it would be easier to test changes or fixes?

Thanks!

> On 31 Jan 2019, at 21:27, j4fm <ja...@my-managed.net> wrote:
> 
> I removed all the configs disabling the filters! It seems that has the wrong
> effect in actually disabling the CustomServlet from being processed in
> servletMappingIsUnderRestPath.
> 
> Now I have this code running in servletMappingIsUnderRestPath:
> 
>            if (accept == null) {
>            accept = false;
>            for (final String mapping : wrapper.findMappings()) {
>                    if (!mapping.isEmpty() && !"/*".equals(mapping) &&
> !"/".equals(mapping) && !mapping.startsWith("*")
>                            && mapping.startsWith(this.mapping)) {
>                        accept = true;
>                        break;
>                    }
>                }
> 
> But it doesn't set accept true because the filter happens to be *.abc and
> there is that condition !mapping.startsWith("*").
> 
> So it still returns false and the chain is not continued.  So looks like a
> 2nd issue with the filter, possibly a 3rd with the filter.active config.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I removed all the configs disabling the filters! It seems that has the wrong
effect in actually disabling the CustomServlet from being processed in
servletMappingIsUnderRestPath.

Now I have this code running in servletMappingIsUnderRestPath:

            if (accept == null) {
            accept = false;
            for (final String mapping : wrapper.findMappings()) {
                    if (!mapping.isEmpty() && !"/*".equals(mapping) &&
!"/".equals(mapping) && !mapping.startsWith("*")
                            && mapping.startsWith(this.mapping)) {
                        accept = true;
                        break;
                    }
                }

But it doesn't set accept true because the filter happens to be *.abc and
there is that condition !mapping.startsWith("*").

So it still returns false and the chain is not continued.  So looks like a
2nd issue with the filter, possibly a 3rd with the filter.active config.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Yes, that idea makes sense and I’ll definitely check what is required to do it. 

On the other hand, it might be a bit risky, since we are focusing on this particular problem and we might be missing something. 

If you are not calling a servlet, the code running first servletMappingIsUnderRestPath should return true to proceed with the regular chain.

> On 31 Jan 2019, at 20:23, j4fm <ja...@my-managed.net> wrote:
> 
> Before, the CXFJAXRSFilter was not in the filter chain because there were no
> REST endpoints not being a REST application. So whatever piece of code
> loaded the static resource before must've been adding the default.htm on and
> loading successfully but now the CXFJAXRSFilter code base for loading static
> resources is called which doesn't add the defualt.htm. :)
> 
> This is why I was suggesting the CXFJAXRSFilter only processed known REST
> endpoints and passed everything else off down the chain, rather than
> handling things itself.  This example of a different code base for loading
> static content is an example, instead of leaving existing code to work
> untouched.  (This might not be so easy though, just an impression/thought I
> have).  It's close but not quite the same.
> 
> Now I'm in a position where it's on the next request for
> /webappA/path3/subpath/file.abc -> CustomServlet but of course, static
> resource returns null (expected) and JAXRSInInterceptor is being called
> again with 404.
> 
> Not sure why it isn't calling CustomServlet maybe the 404 just happens
> first?
> 
> Thanks again for your help... really close to the bottom now I think. :)
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Before, the CXFJAXRSFilter was not in the filter chain because there were no
REST endpoints not being a REST application. So whatever piece of code
loaded the static resource before must've been adding the default.htm on and
loading successfully but now the CXFJAXRSFilter code base for loading static
resources is called which doesn't add the defualt.htm. :)

This is why I was suggesting the CXFJAXRSFilter only processed known REST
endpoints and passed everything else off down the chain, rather than
handling things itself.  This example of a different code base for loading
static content is an example, instead of leaving existing code to work
untouched.  (This might not be so easy though, just an impression/thought I
have).  It's close but not quite the same.

Now I'm in a position where it's on the next request for
/webappA/path3/subpath/file.abc -> CustomServlet but of course, static
resource returns null (expected) and JAXRSInInterceptor is being called
again with 404.

Not sure why it isn't calling CustomServlet maybe the 404 just happens
first?

Thanks again for your help... really close to the bottom now I think. :)



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Cool. Thank you so much for all you effort in helping us figure this one out.

One thing that I didn’t understand is, if a call to /webappA/path1/ pre MP integration was working for you? From what is looks like, it wasn’t working before.

> On 31 Jan 2019, at 19:41, j4fm <ja...@my-managed.net> wrote:
> 
> So now I browse directly to /webappA/path1/default.htm and it gets past the
> 404.  Must be that default welcome page is only being added to root paths,
> not sub-paths.
> But left with an empty response now though, next up is it redirects to a
> request which should hit the *.abc=CustomServlet... will step through what
> it's doing.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

So now I browse directly to /webappA/path1/default.htm and it gets past the
404.  Must be that default welcome page is only being added to root paths,
not sub-paths.
But left with an empty response now though, next up is it redirects to a
request which should hit the *.abc=CustomServlet... will step through what
it's doing.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Happy with the suggestion :)

Interesting, yes findStaticContent returns null - for default.htm

requestURI is /webappA/path1/
requestDispatcherPath and servletPath is /path1/default.htm

inside findStaticContent
pathInfo is always /path1/
root "/" and pathInfo.isEmpty are not matched
and finally 
request.getServletContext().getResourceAsStream(pathInfo) is called at the
end with pathInfo being "/path1", returning null.

I checked the StandardContext.servletMappings {*.jspx=jsp,
*.def=CustomServlet, *.jsp=jsp, *.abc=CustomServlet, /faces/*=FacesServlet,
*.faces=FacesServlet, /=default, *.jsf=FacesServlet, *.xhtml=FacesServlet}





--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I'm pulling the test case now to see if I can spot it



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Happy with the suggestion :)

Interesting, yes findStaticContent returns null - for default.htm

requestURI is /webappA/path1/
requestDispatcherPath and servletPath is /path1/default.htm

inside findStaticContent
pathInfo is always /path1/
root "/" and pathInfo.isEmpty are not matched
and finally 
request.getServletContext().getResourceAsStream(pathInfo) is called at the
end with pathInfo being "/path1", returning null.

I checked the StandardContext.servletMappings {*.jspx=jsp,
*.def=CustomServlet, *.jsp=jsp, *.abc=CustomServlet, /faces/*=FacesServlet,
*.faces=FacesServlet, /=default, *.jsf=FacesServlet, *.xhtml=FacesServlet}





--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

By the way,

webapp/path1 and webapp/path2 are static resources right?

So they should fall here:
https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L86-L90 <https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L86-L90>

And maybe delegate.findStaticContent(httpServletRequest, welcomeFiles); might be the one making the paths to fall into JASRSInInterceptor.

What type of resources do you have there? 

> On 31 Jan 2019, at 18:50, Roberto Cortez <ra...@yahoo.com.INVALID> wrote:
> 
> Maybe we can have something like:
> 
> mp.enabled=all <- Everything enabled
> mp.enabled=none <- Everything disabled
> mp.enabled=config,fault-tolerance <- Only config and fault-tolerance enabled
> 
> And so on…
> 
> Can’t remember exactly how to handle global vs app specific configuration., but I’ll have a look.
> 
> The execution there is helpful, I just don’t get it why path1 and path2 are directed to JASRSInInterceptor. The email that I’ve sent you earlier with a test case seems to work fine for the same case. I wonder what is different that would make it go to JASRSInInterceptor. Let me see if I’m able to figure out something.
> 
> Thanks!
> 
>> On 31 Jan 2019, at 18:35, j4fm <ja...@my-managed.net> wrote:
>> 
>> Agree, it would be nice if they just worked - but even without issues, I
>> notice a significant start-up time impact even having only around 8 webapps
>> in this case.  Also agree, the enable/disable are only for the active
>> endpoint stuff like health, metrics, openapi.  Already it is useful to have
>> JARs available like mp-config.
>> 
>> I guess it would be a list setting for which ones are enabled by default
>> globally.  Disabled is default.
>> mp.enabled=health,metrics
>> So default globally for Plus/Plume would be mp.enabled=
>> Default globally for MP edition would be mp.enabled=health,metrics,openapi
>> 
>> Same setting for each context which override the global. So in Plus there
>> could be just one webapp with mp.enabled=health,metrics
>> 
>> (If a webapp has mp.enabled= then it overrides the global by disabling.  If
>> the setting is not specified at all it uses global) (Didn't think too much
>> on it or names, but feel it should be enough)
>> 
>> CXFRSFilter:
>> With the servletMappingIsUnderRestPath check, this is what happens when I
>> debug:
>> 
>> Say, I have traditional non-REST webappA:
>> 
>> /webappA/path1 ->DefaultServlet
>> /webappA/path2 ->DefaultServlet
>> 
>> Then MP comes along and it should be this behaviour:
>> 
>> /webappA/ -> REST.InternalApplication
>> /webappA/path1 ->DefaultServlet
>> /webappA/path2 ->DefaultServlet
>> /webappA/Health -> JASRSInInterceptor
>> 
>> But I see this behaviour:
>> 
>> /webappA/ -> REST.InternalApplication
>> /webappA/path1 ->JASRSInInterceptor
>> /webappA/path2 ->JASRSInInterceptor
>> /webappA/Health -> JASRSInInterceptor
>> 
>> As an example, for the request path /webappA/path1/subpath
>> 
>> I find that the servletMappingIsUnderRestPath is run:
>> 
>> wrapper.servletClass=org.apache.catalina.servlets.DefaultServlet
>> 
>> mappingByServlet contains only
>> {StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webappA].StandardWrapper[default]=false}
>> 
>> wrapper =
>> StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webAppA].StandardWrapper[default]
>> 
>> So the "accept" value is assigned the value "false".  This means the line82
>> does not trigger chain.doFilter.
>> 
>> So it seems to me that everything underneath webappA is sent to
>> JAXRSInInterceptor and causing 404.
>> 
>> 
>> 
>> --
>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> 

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Maybe we can have something like:

mp.enabled=all <- Everything enabled
mp.enabled=none <- Everything disabled
mp.enabled=config,fault-tolerance <- Only config and fault-tolerance enabled

And so on…

Can’t remember exactly how to handle global vs app specific configuration., but I’ll have a look.

The execution there is helpful, I just don’t get it why path1 and path2 are directed to JASRSInInterceptor. The email that I’ve sent you earlier with a test case seems to work fine for the same case. I wonder what is different that would make it go to JASRSInInterceptor. Let me see if I’m able to figure out something.

Thanks!

> On 31 Jan 2019, at 18:35, j4fm <ja...@my-managed.net> wrote:
> 
> Agree, it would be nice if they just worked - but even without issues, I
> notice a significant start-up time impact even having only around 8 webapps
> in this case.  Also agree, the enable/disable are only for the active
> endpoint stuff like health, metrics, openapi.  Already it is useful to have
> JARs available like mp-config.
> 
> I guess it would be a list setting for which ones are enabled by default
> globally.  Disabled is default.
> mp.enabled=health,metrics
> So default globally for Plus/Plume would be mp.enabled=
> Default globally for MP edition would be mp.enabled=health,metrics,openapi
> 
> Same setting for each context which override the global. So in Plus there
> could be just one webapp with mp.enabled=health,metrics
> 
> (If a webapp has mp.enabled= then it overrides the global by disabling.  If
> the setting is not specified at all it uses global) (Didn't think too much
> on it or names, but feel it should be enough)
> 
> CXFRSFilter:
> With the servletMappingIsUnderRestPath check, this is what happens when I
> debug:
> 
> Say, I have traditional non-REST webappA:
> 
> /webappA/path1 ->DefaultServlet
> /webappA/path2 ->DefaultServlet
> 
> Then MP comes along and it should be this behaviour:
> 
> /webappA/ -> REST.InternalApplication
> /webappA/path1 ->DefaultServlet
> /webappA/path2 ->DefaultServlet
> /webappA/Health -> JASRSInInterceptor
> 
> But I see this behaviour:
> 
> /webappA/ -> REST.InternalApplication
> /webappA/path1 ->JASRSInInterceptor
> /webappA/path2 ->JASRSInInterceptor
> /webappA/Health -> JASRSInInterceptor
> 
> As an example, for the request path /webappA/path1/subpath
> 
> I find that the servletMappingIsUnderRestPath is run:
> 
> wrapper.servletClass=org.apache.catalina.servlets.DefaultServlet
> 
> mappingByServlet contains only
> {StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webappA].StandardWrapper[default]=false}
> 
> wrapper =
> StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webAppA].StandardWrapper[default]
> 
> So the "accept" value is assigned the value "false".  This means the line82
> does not trigger chain.doFilter.
> 
> So it seems to me that everything underneath webappA is sent to
> JAXRSInInterceptor and causing 404.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Agree, it would be nice if they just worked - but even without issues, I
notice a significant start-up time impact even having only around 8 webapps
in this case.  Also agree, the enable/disable are only for the active
endpoint stuff like health, metrics, openapi.  Already it is useful to have
JARs available like mp-config.

I guess it would be a list setting for which ones are enabled by default
globally.  Disabled is default.
mp.enabled=health,metrics
So default globally for Plus/Plume would be mp.enabled=
Default globally for MP edition would be mp.enabled=health,metrics,openapi

Same setting for each context which override the global. So in Plus there
could be just one webapp with mp.enabled=health,metrics

(If a webapp has mp.enabled= then it overrides the global by disabling.  If
the setting is not specified at all it uses global) (Didn't think too much
on it or names, but feel it should be enough)

CXFRSFilter:
With the servletMappingIsUnderRestPath check, this is what happens when I
debug:

Say, I have traditional non-REST webappA:

/webappA/path1 ->DefaultServlet
/webappA/path2 ->DefaultServlet

Then MP comes along and it should be this behaviour:

/webappA/ -> REST.InternalApplication
/webappA/path1 ->DefaultServlet
/webappA/path2 ->DefaultServlet
/webappA/Health -> JASRSInInterceptor

But I see this behaviour:

/webappA/ -> REST.InternalApplication
/webappA/path1 ->JASRSInInterceptor
/webappA/path2 ->JASRSInInterceptor
/webappA/Health -> JASRSInInterceptor

As an example, for the request path /webappA/path1/subpath

I find that the servletMappingIsUnderRestPath is run:

wrapper.servletClass=org.apache.catalina.servlets.DefaultServlet

mappingByServlet contains only
{StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webappA].StandardWrapper[default]=false}

wrapper =
StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webAppA].StandardWrapper[default]

So the "accept" value is assigned the value "false".  This means the line82
does not trigger chain.doFilter.

So it seems to me that everything underneath webappA is sent to
JAXRSInInterceptor and causing 404.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Hey,

Are you able to check my PR:
https://github.com/apache/tomee/pull/304 <https://github.com/apache/tomee/pull/304>

And review the following test:
https://github.com/apache/tomee/pull/304/commits/3f59d382b12ebc17b2d1fc9e587486d55fc4a749 <https://github.com/apache/tomee/pull/304/commits/3f59d382b12ebc17b2d1fc9e587486d55fc4a749>

It creates a deployment with a servlet, a static file and a rest endpoint. All are reachable just fine. You can run it with:
mvn -Pall-adapters clean test-compile surefire:test@test-tomee-remote-plume -Dtest=RestWithServletsTest

The MP endpoints do not seem to interfere here. I might be missing something from your case…

Thanks!

Cheers,
Roberto

> On 31 Jan 2019, at 17:48, Roberto Cortez <ra...@yahoo.com.INVALID> wrote:
> 
> Ideally, we should reach an integration state such as MP is always available without requiring additional configuration, but without interfering with the current deployments.
> 
> I agree that probably at this stage it would be safer to have some kind of configuration to opt-in / opt-out, until we have a more stable environment. A tricky thing is to find the right balance. Is it binary? It is either all or nothing? Or do you have individual switches per spec? I see Config and Fault Tolerance to be useful with little to none integration issues. The main problems so far were always with the spec that change the web app in a way, like health, openapi or metrics, which add additional endpoints.
> 
> Regarding the CXFRSFilter, I am looking into it right now and I’ve made a series of tests. The filter is only added when you have REST resources in the app. I can confirm that servlets mapped in “/some_path” work just fine. The ones on “/*" do not and I was about to test around the DefaultServlet.
> 
> Look here:
> https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L102-L136 <https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L102-L136>
> 
> And here:
> https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L82 <https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L82>
> 
> It does try to find a servlet mapping that matches the request in the Tomcat Wrapper and if it finds one, it just proceeds with the chain call (except for /*). If you notice there is a special case for org.apache.catalina.servlets.DefaultServlet, that I’m going to debug next.
> 
> So, in theory, all mapped servlets except for /* and the default servlet should execute properly. 
> 
> The /* is indeed problematic, since you don’t know what is in there and could be effectively a rest endpoint. The only option I see is to do as you suggest and to do the check the other way around, so check if the path is server by a rest path and proceed with it and if not, just let it be handled by the regular chain. It should be possible.
> 
>> On 31 Jan 2019, at 16:56, j4fm <ja...@my-managed.net> wrote:
>> 
>> So I was thinking on this:
>> 
>> 1. It would be ideal to be able to configure if MP endpoints/filters are
>> enabled/disabled by default and then enabled/disabled per-context (i.e.
>> opt-out vs opt-in behaviour).  In TomEE MicroProfile edition, I expect it
>> would be enabled by default.  In Plus/Plume, I expect it would be disabled
>> by default and enabled per-webapp.
>> 
>> 2. With only 1. it would be a shame to not be able to make use of MP on
>> existing webapps.  I was thinking on possible options for resolving the
>> CXF/JAX-RS issue and had some ideas.
>> a. Not sure if possible, but if JAXRSInInterceptor could not raise a 404
>> exception and instead return to pass down the filter chain it could work.
>> b. The CXFRSFilter could do the same endpoint checks that
>> JAXRSInInterceptor does and avoid calling it in the first place for non-REST
>> paths.
>> c. CXFRSFilter could read an "exclude paths" filter configuration for
>> contexts to consider as not REST.
>> d. CXFRSFilter could check for an attribute set by a previous filter to
>> indicate not to process as a REST resource.
>> 
>> Not sure if you had something else in mind.  Let me know if I should raise a
>> ticket or can test something out.
>> 
>> 
>> 
>> --
>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> 

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Ideally, we should reach an integration state such as MP is always available without requiring additional configuration, but without interfering with the current deployments.

I agree that probably at this stage it would be safer to have some kind of configuration to opt-in / opt-out, until we have a more stable environment. A tricky thing is to find the right balance. Is it binary? It is either all or nothing? Or do you have individual switches per spec? I see Config and Fault Tolerance to be useful with little to none integration issues. The main problems so far were always with the spec that change the web app in a way, like health, openapi or metrics, which add additional endpoints.

Regarding the CXFRSFilter, I am looking into it right now and I’ve made a series of tests. The filter is only added when you have REST resources in the app. I can confirm that servlets mapped in “/some_path” work just fine. The ones on “/*" do not and I was about to test around the DefaultServlet.

Look here:
https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L102-L136 <https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L102-L136>

And here:
https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L82 <https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L82>

It does try to find a servlet mapping that matches the request in the Tomcat Wrapper and if it finds one, it just proceeds with the chain call (except for /*). If you notice there is a special case for org.apache.catalina.servlets.DefaultServlet, that I’m going to debug next.

So, in theory, all mapped servlets except for /* and the default servlet should execute properly. 

The /* is indeed problematic, since you don’t know what is in there and could be effectively a rest endpoint. The only option I see is to do as you suggest and to do the check the other way around, so check if the path is server by a rest path and proceed with it and if not, just let it be handled by the regular chain. It should be possible.

> On 31 Jan 2019, at 16:56, j4fm <ja...@my-managed.net> wrote:
> 
> So I was thinking on this:
> 
> 1. It would be ideal to be able to configure if MP endpoints/filters are
> enabled/disabled by default and then enabled/disabled per-context (i.e.
> opt-out vs opt-in behaviour).  In TomEE MicroProfile edition, I expect it
> would be enabled by default.  In Plus/Plume, I expect it would be disabled
> by default and enabled per-webapp.
> 
> 2. With only 1. it would be a shame to not be able to make use of MP on
> existing webapps.  I was thinking on possible options for resolving the
> CXF/JAX-RS issue and had some ideas.
>  a. Not sure if possible, but if JAXRSInInterceptor could not raise a 404
> exception and instead return to pass down the filter chain it could work.
>  b. The CXFRSFilter could do the same endpoint checks that
> JAXRSInInterceptor does and avoid calling it in the first place for non-REST
> paths.
>  c. CXFRSFilter could read an "exclude paths" filter configuration for
> contexts to consider as not REST.
>  d. CXFRSFilter could check for an attribute set by a previous filter to
> indicate not to process as a REST resource.
> 
> Not sure if you had something else in mind.  Let me know if I should raise a
> ticket or can test something out.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

So I was thinking on this:

1. It would be ideal to be able to configure if MP endpoints/filters are
enabled/disabled by default and then enabled/disabled per-context (i.e.
opt-out vs opt-in behaviour).  In TomEE MicroProfile edition, I expect it
would be enabled by default.  In Plus/Plume, I expect it would be disabled
by default and enabled per-webapp.

2. With only 1. it would be a shame to not be able to make use of MP on
existing webapps.  I was thinking on possible options for resolving the
CXF/JAX-RS issue and had some ideas.
  a. Not sure if possible, but if JAXRSInInterceptor could not raise a 404
exception and instead return to pass down the filter chain it could work.
  b. The CXFRSFilter could do the same endpoint checks that
JAXRSInInterceptor does and avoid calling it in the first place for non-REST
paths.
  c. CXFRSFilter could read an "exclude paths" filter configuration for
contexts to consider as not REST.
  d. CXFRSFilter could check for an attribute set by a previous filter to
indicate not to process as a REST resource.

Not sure if you had something else in mind.  Let me know if I should raise a
ticket or can test something out.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Hey! Thanks for the info.

I used to think that the issue was with the root context, but from what you are describing this may not be the case, which does make some sense for your case. I was getting a little confused on how you were having some kind of endpoint clash, but apparently the issue is that CXF just takes over everything.

Let me implement a few test cases and check if there is something that can be done.

Cheers,
Roberto 

> On 30 Jan 2019, at 23:25, j4fm <ja...@my-managed.net> wrote:
> 
> So I got time to look at this again.
> 
> It seems to be pretty clear that if you take an existing non-REST based
> webapp and add REST endpoints with CXF, the CXFJAXRSFilter will then only
> allow REST resources and static resources to be served for that whole
> webapp.  Even without a "/*" servlet mapping it prevents the default servlet
> because JAXRSInInterceptor throws a 404 (line 173) if the request path isn't
> recognised as a REST resource.
> 
> Do you know if there is a reason why CXF doesn't just pass on non-REST paths
> to the next filter in the chain just like it does when the request is a
> non-HttpServletRequest or when it thinks the path is for a static resource? 
> I would think the default servlet would produce a 404 just fine if the
> request path really did not exist.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

So I got time to look at this again.

It seems to be pretty clear that if you take an existing non-REST based
webapp and add REST endpoints with CXF, the CXFJAXRSFilter will then only
allow REST resources and static resources to be served for that whole
webapp.  Even without a "/*" servlet mapping it prevents the default servlet
because JAXRSInInterceptor throws a 404 (line 173) if the request path isn't
recognised as a REST resource.

Do you know if there is a reason why CXF doesn't just pass on non-REST paths
to the next filter in the chain just like it does when the request is a
non-HttpServletRequest or when it thinks the path is for a static resource? 
I would think the default servlet would produce a 404 just fine if the
request path really did not exist.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Endpoint removal:
There is no servlet registration to "/*" on the webapps.  There is a servlet
registration for specific *.abc file extensions and "*.faces=FacesServlet"
and a couple for "/web/start/*" but after that only "/" -> default servlet
mapping.

I have debugged through TomEEMicroProfileListener and it's removing the
MetricsEndpoints and HealthCheckEndpoint and leaving just
CdiHealthChecksEndpoint, CdiMetricsEndpoints and OpenAPIEndpoints, which is
what I believe it's supposed to do (duplicate removal).

Then the endpoint removal for "/*" does nothing because there is no "/*"
mapping.





--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Thanks!

Yes, even with the configs, the endpoints still register, because they are scanned by the REST annotation.

I did add something to unregister the endpoints if we found a servlet registration to /*, which is the problematic pattern that gets overriden by the REST deployment:
https://github.com/apache/tomee/blob/4ade980c56276a2ad4f2df921e12314e38e881cf/tomee/tomee-microprofile/mp-common/src/main/java/org/apache/tomee/microprofile/TomEEMicroProfileListener.java#L33 <https://github.com/apache/tomee/blob/4ade980c56276a2ad4f2df921e12314e38e881cf/tomee/tomee-microprofile/mp-common/src/main/java/org/apache/tomee/microprofile/TomEEMicroProfileListener.java#L33>

For some reason, it might not be working for your case. Are you able to debug and see what is going on?

Anyway, I think that we should grab those configs and also plug them in there, so they always force the specifying endpoint to skip deployment if they are turned off.

Cheers,
Roberto

> On 29 Jan 2019, at 18:40, j4fm <ja...@my-managed.net> wrote:
> 
> Hey Roberto, nice one and congrats with the M2 release. I guessed you were
> busy with that.
> 
> With the configuration settings I mentioned in my previous post (they are in
> the system.properties file), I do still see endpoints registered for an app
> as here:
> 
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints
> REST Application: http://localhost:8080/webapp1/                           
> -> org.apache.openejb.server.rest.InternalApplication@22cf6dad
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints     
> Service URI: http://localhost:8080/webapp1/health                      ->
> Pojo
> org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
> GET http://localhost:8080/webapp1/health                      ->     
> Response getChecks()
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints     
> Service URI: http://localhost:8080/webapp1/metrics                     ->
> Pojo org.apache.geronimo.microprofile.metrics.jaxrs.CdiMetricsEndpoints
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
> GET http://localhost:8080/webapp1/metrics                     ->      Object
> getJson(SecurityContext, UriInfo)
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
> GET http://localhost:8080/webapp1/metrics                     ->      String
> getText(SecurityContext, UriInfo)
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
> GET http://localhost:8080/webapp1/metrics/{registry}          ->      Object
> getJson(String, SecurityContext, UriInfo)
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
> GET http://localhost:8080/webapp1/metrics/{registry}          ->      String
> getText(String, SecurityContext, UriInfo)
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
> GET http://localhost:8080/webapp1/metrics/{registry}/{metric} ->      Object
> getJson(String, String, SecurityContext, UriInfo)
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
> GET http://localhost:8080/webapp1/metrics/{registry}/{metric} ->      String
> getText(String, String, SecurityContext, UriInfo)
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints          
> OPTIONS http://localhost:8080/webapp1/metrics/{registry}          ->     
> Object getMetadata(String, SecurityContext, UriInfo)
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints          
> OPTIONS http://localhost:8080/webapp1/metrics/{registry}/{metric} ->     
> Object getMetadata(String, String, SecurityContext, UriInfo)
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints     
> Service URI: http://localhost:8080/webapp1/openapi                     ->
> Pojo org.apache.geronimo.microprofile.openapi.jaxrs.OpenAPIEndpoint
> INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
> GET http://localhost:8080/webapp1/openapi                     ->     
> OpenAPI get()
> 
> 
> There is a custom servlet with url patterns of a custom file type extension
> e.g *.cah and *.wcb specific to the software.  Everything else is going to
> the default tomee servlet.
> 
> The software has filters that are all with a url pattern of "/*".  One of
> those filters is for the handling of tenantid from the URL
> /webapp1/<tenantid>/... validating it against the database and forwarded to
> /webapp1name/app/webapp2 with an attribute set for the tenantid added from
> the filter.  The URL remains the same in the browser i.e. the
> /webapp1/<tenantid>/... format.
> 
> Everything gets 404 from JAXRSFilter which is in the chain after the
> software's own filters.
> 
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hey Roberto, nice one and congrats with the M2 release. I guessed you were
busy with that.

With the configuration settings I mentioned in my previous post (they are in
the system.properties file), I do still see endpoints registered for an app
as here:

INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints
REST Application: http://localhost:8080/webapp1/                           
-> org.apache.openejb.server.rest.InternalApplication@22cf6dad
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints     
Service URI: http://localhost:8080/webapp1/health                      ->
Pojo
org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
GET http://localhost:8080/webapp1/health                      ->     
Response getChecks()
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints     
Service URI: http://localhost:8080/webapp1/metrics                     ->
Pojo org.apache.geronimo.microprofile.metrics.jaxrs.CdiMetricsEndpoints
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
GET http://localhost:8080/webapp1/metrics                     ->      Object
getJson(SecurityContext, UriInfo)
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
GET http://localhost:8080/webapp1/metrics                     ->      String
getText(SecurityContext, UriInfo)
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
GET http://localhost:8080/webapp1/metrics/{registry}          ->      Object
getJson(String, SecurityContext, UriInfo)
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
GET http://localhost:8080/webapp1/metrics/{registry}          ->      String
getText(String, SecurityContext, UriInfo)
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
GET http://localhost:8080/webapp1/metrics/{registry}/{metric} ->      Object
getJson(String, String, SecurityContext, UriInfo)
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
GET http://localhost:8080/webapp1/metrics/{registry}/{metric} ->      String
getText(String, String, SecurityContext, UriInfo)
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints          
OPTIONS http://localhost:8080/webapp1/metrics/{registry}          ->     
Object getMetadata(String, SecurityContext, UriInfo)
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints          
OPTIONS http://localhost:8080/webapp1/metrics/{registry}/{metric} ->     
Object getMetadata(String, String, SecurityContext, UriInfo)
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints     
Service URI: http://localhost:8080/webapp1/openapi                     ->
Pojo org.apache.geronimo.microprofile.openapi.jaxrs.OpenAPIEndpoint
INFO [main] org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints              
GET http://localhost:8080/webapp1/openapi                     ->     
OpenAPI get()


There is a custom servlet with url patterns of a custom file type extension
e.g *.cah and *.wcb specific to the software.  Everything else is going to
the default tomee servlet.

The software has filters that are all with a url pattern of "/*".  One of
those filters is for the handling of tenantid from the URL
/webapp1/<tenantid>/... validating it against the database and forwarded to
/webapp1name/app/webapp2 with an attribute set for the tenantid added from
the filter.  The URL remains the same in the browser i.e. the
/webapp1/<tenantid>/... format.

Everything gets 404 from JAXRSFilter which is in the chain after the
software's own filters.




--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Sorry, I was caught up the the release work, so I tabled this temporarily. Let’s see if we are able to put the missing fixes in.

For what I understand, it may be that your servlet is being overridden by the MP endpoints. You do see them get deployed, right? Even with the filters and scans disabled, right?

Are you able to provide me the url pattern for the servlet? I would like to try out a test case with it. Thanks!

Cheers,
Roberto

> On 25 Jan 2019, at 15:18, j4fm <ja...@my-managed.net> wrote:
> 
> FYI At this point:
> 
> geronimo.jwtauth.filter.active=false
> geronimo.metrics.jaxrs.activated=false
> mp.openapi.scan.disable=true
> geronimo.opentracing.filter.active=false
> 
> are all set for this test.  (There is a different exception without them,
> which I will step through soon but could be related)
> 
> There exists a servlet for a couple of specific file extensions only in the
> path.  So a standard servlet is serving the rest of the path.  Both the
> specific file extensions and other paths result in 404.
> 
> In the filter chain, it get's as far as the JAXRSFilter filter which results
> in a 404.
> 
> Correct that the user browses /webapp1/<tenantid>/ path where tenantid is a
> database driven path rather than a real path - it maps to /webapp1/.  The
> user can also browse /webapp1/<tenantid>/subapp/<webapp2> which maps to
> /webapp1name/subapp/webapp2.
> 
> 
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

FYI At this point:

geronimo.jwtauth.filter.active=false
geronimo.metrics.jaxrs.activated=false
mp.openapi.scan.disable=true
geronimo.opentracing.filter.active=false

are all set for this test.  (There is a different exception without them,
which I will step through soon but could be related)

There exists a servlet for a couple of specific file extensions only in the
path.  So a standard servlet is serving the rest of the path.  Both the
specific file extensions and other paths result in 404.

In the filter chain, it get's as far as the JAXRSFilter filter which results
in a 404.

Correct that the user browses /webapp1/<tenantid>/ path where tenantid is a
database driven path rather than a real path - it maps to /webapp1/.  The
user can also browse /webapp1/<tenantid>/subapp/<webapp2> which maps to
/webapp1name/subapp/webapp2.





--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

So, if I understood correctly the MP endpoints are overriding your application path in the application root context? Do you have a standard servlet serving that path? I did try to write a piece of guarding code to skip MP REST deployment if it would find clashes. Maybe I didn’t cover all the cases. Can you detail a little more what you have?

I do agree that we should have some configuration to enable / disable MP. We don’t know the deployments out there and there is high chance to break someones deployment with these big changes. Ideally, all the implementations should provide a way to disable them. Not every implementation has that feature, so we either push it there or implement it on our side. I already have a few ideias how to do it.

And thank you for all your feedback. It is been extremely helpful to move forward.

Cheers,
Roberto

> On 24 Jan 2019, at 23:01, j4fm <ja...@my-managed.net> wrote:
> 
> I could trace it to JaxRS is intercepting it and does not find a resource
> resulting in the 404. While it should use the DefaultServlet
> (JAXRSInInterceptor:135 the 404 is created). 
> 
> It is saying in the log: 
> 
> 24-Jan-2019 16:10:35.803 INFO [main]
> org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints REST
> Application: http://localhost:8080/home/                            -〉
> org.apache.openejb.server.rest.InternalApplication@4d2eb4c6
> 
> Might be that this 404 fix doesn't work because it does not seem to
> de-register jaxrs
> https://github.com/apache/tomee/commit/4ade980c56276a2ad4f2df921e12314e38e881cf#diff-359e0b6fffe2693959a884486dd38c5a
> 
> - In our case also metrics and health clashes, because the path segment
> after 'home' is data defined. Would it be possible to have mp (and jax-rs)
> be deployed on a (preferable) configurable sub-path? e.g.
> /home/app/mp/health. Where 'app/mp' is thus the configurable part.
> - I think we're getting really close, but while a few issues remain my
> general gut feeling and suggestion for editions is that TomEE MP edition be
> opt-out (MP active for all webapps by default - because that edition is
> dedicated for MP) and for Plus/Plume it's opt-in (MP inactive by default). 
> While inactive, it's still great to be able to use MP libs without
> extensions/filters like microprofile-config.  Then webapps can enable
> specific MP endpoints as they wish.  This would be ideal in my view.
> 
> Hopefully this makes sense and is helpful feedback... really appreciate how
> much you've helped with this.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I could trace it to JaxRS is intercepting it and does not find a resource
resulting in the 404. While it should use the DefaultServlet
(JAXRSInInterceptor:135 the 404 is created). 

It is saying in the log: 

24-Jan-2019 16:10:35.803 INFO [main]
org.apache.openejb.server.cxf.rs.CxfRsHttpListener.logEndpoints REST
Application: http://localhost:8080/home/                            -〉
org.apache.openejb.server.rest.InternalApplication@4d2eb4c6

Might be that this 404 fix doesn't work because it does not seem to
de-register jaxrs
https://github.com/apache/tomee/commit/4ade980c56276a2ad4f2df921e12314e38e881cf#diff-359e0b6fffe2693959a884486dd38c5a

- In our case also metrics and health clashes, because the path segment
after 'home' is data defined. Would it be possible to have mp (and jax-rs)
be deployed on a (preferable) configurable sub-path? e.g.
/home/app/mp/health. Where 'app/mp' is thus the configurable part.
- I think we're getting really close, but while a few issues remain my
general gut feeling and suggestion for editions is that TomEE MP edition be
opt-out (MP active for all webapps by default - because that edition is
dedicated for MP) and for Plus/Plume it's opt-in (MP inactive by default). 
While inactive, it's still great to be able to use MP libs without
extensions/filters like microprofile-config.  Then webapps can enable
specific MP endpoints as they wish.  This would be ideal in my view.

Hopefully this makes sense and is helpful feedback... really appreciate how
much you've helped with this.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hi Roberto,

Just digging on the 404 issue.  So I have found in one of the webapps
web-fragment.xml the following:
	<filter-mapping>
		<filter-name>SomeFilter</filter-name>
		<url-pattern>/*</url-pattern>
		<dispatcher>REQUEST</dispatcher>
		<dispatcher>FORWARD</dispatcher>
		<dispatcher>ASYNC</dispatcher>
	</filter-mapping>

Does this relate to the root context being taken over by MP that you
mentioned in your issue overview comment above or any other issue you know
of?  I already have patch 304 applied.

It's getting to doFilter in one of the filters, finding it's not
authenticated, creating a new HttpServletRequestWrapper() and at that point
the response turns to 404.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Great! We are getting there :)

> On 24 Jan 2019, at 12:58, j4fm <ja...@my-managed.net> wrote:
> 
> I built and tested the openapi patch and that out of bounds exception no
> longer appears. :)
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I built and tested the openapi patch and that out of bounds exception no
longer appears. :)



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Yes, OpenAPI made the fix:
https://github.com/apache/geronimo-openapi/commit/7ceee65e0b489f4847f4015aa71a3d7b6958b402 <https://github.com/apache/geronimo-openapi/commit/7ceee65e0b489f4847f4015aa71a3d7b6958b402>

We still need to wait for a release or bump to use the SNAPSHOT version.

> On 23 Jan 2019, at 16:07, j4fm <ja...@my-managed.net> wrote:
> 
> On this specific service, there is the following:
> 
> @Path("/")
> @GET
> public Response doGetRoot() {
> …
> }
> 
> Followed by paths with actual values just like you said.  It would be good
> for OpenAPI to provide a fix, I will see if I can test changing it in source
> directly tonight by just changing "/", to "".
> 
> 
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

On this specific service, there is the following:

@Path("/")
@GET
public Response doGetRoot() {
…
}

Followed by paths with actual values just like you said.  It would be good
for OpenAPI to provide a fix, I will see if I can test changing it in source
directly tonight by just changing "/", to "".





--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

I believe this is caused when you have a @Path parent element with just a "/" value and then methods with @Path and and actual value.I think the fix needs to be done on the OpenAPI side, or just remove the "/“ from the @Path parent element, but that involves changing app code. 

I’ve created this PR to OpenAPI: https://github.com/apache/geronimo-openapi/pull/10 <https://github.com/apache/geronimo-openapi/pull/10>. Let’s see what happens.

Thank you!

Cheers,
Roberto

> On 23 Jan 2019, at 14:27, j4fm <ja...@my-managed.net> wrote:
> 
> FYI, as you mentioned, I also see OpenAPI annotation index out of bounds.  If
> you would like me to test out any fix for it, I can do that immediately...
> 
> /Caused by: java.lang.StringIndexOutOfBoundsException: begin 1, end 0,
> length 1
> at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3319)
> at java.base/java.lang.String.substring(String.java:1874)
> at
> org.apache.geronimo.microprofile.openapi.impl.processor.AnnotationProcessor.lambda$buildPath$77(AnnotationProcessor.java:450)/
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

FYI, as you mentioned, I also see OpenAPI annotation index out of bounds.  If
you would like me to test out any fix for it, I can do that immediately...

/Caused by: java.lang.StringIndexOutOfBoundsException: begin 1, end 0,
length 1
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3319)
at java.base/java.lang.String.substring(String.java:1874)
at
org.apache.geronimo.microprofile.openapi.impl.processor.AnnotationProcessor.lambda$buildPath$77(AnnotationProcessor.java:450)/



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Thanks, I’ll see if these are related.

> On 24 Jan 2019, at 08:47, Bruno Baptista <br...@gmail.com> wrote:
> 
> Roberto,
> 
> I run a full build and it didn't finish. It got stuck on while running the tomee/tck/cdi-tomee tests.
> 
> Apart from that, I found these issues:
> 
> itests/legacy-server
> 
> [ERROR] Failures:
> [ERROR]   LegacyServerTest.test:212->assertBalance:230 3 out of 1000 is too low
> 
> tck/cdi-embeddedrver
> [ERROR] Failures:
> [ERROR] EnterpriseSelectedAlternative02Test>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] EnterpriseSelectedAlternative03Test>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] EnterpriseBeanDiscoveryTest>Arquillian.arquillianBeforeClass:109 » Deployment ...
> [ERROR] LibraryInEarTest>Arquillian.arquillianBeforeClass:109 » Deployment can't deplo...
> [ERROR] MultiWebModuleWithExtensionTest>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] SingleWebModuleWithExtensionTest>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] BeanRegistrationByExtensionInEarLibraryTest>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] EnabledManagedBeanInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] EnabledProducerFieldInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] EnabledProducerMethodInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] EnabledSessionBeanInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] InterModuleELResolutionTest>Arquillian.arquillianBeforeClass:109 » Deployment ...
> [ERROR] InterModuleLookupTest>Arquillian.arquillianBeforeClass:109 » Deployment can't ...
> [ERROR] SelectedAlternativeManagedBeanInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] SelectedAlternativeSessionBeanInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] SpecializedProducerMethodInjectionNotAvailableTest>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] SpecializationModularity02Test>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] SpecializationModularity04Test>Arquillian.arquillianBeforeClass:109 » Deployment
> [ERROR] Specialization06Test>Arquillian.arquillianBeforeClass:109 » Deployment can't d...
> 
> Cheers
> 
> Bruno Baptista
> https://twitter.com/brunobat_
> 
> 
> On 23/01/19 12:26, Bruno Baptista wrote:
>> Hi Roberto,
>> 
>> I'll take a look at the PR.
>> 
>> Cheers.
>> 
>> Bruno Baptista
>> https://twitter.com/brunobat_
>> 
>> 
>> On 23/01/19 11:30, Roberto Cortez wrote:
>>> Hi folks,
>>> 
>>> Let me try to give a full overview on what I have been working on in the last couple of days. Progress has been a bit slow unfortunately, due to the amount of combinations and tests that I have to run every time I do a change. On the other hand, I know understand way better how TomEE does the deployment :) Anyway, I’m starting to question myself if I’m going in the right direction.
>>> 
>>> MP EAR Support:
>>> MP CDI Extensions, or any CDI Extension is always loaded if found in the classpath via the ServiceLoader. For WAR this works fine. On EAR, CDI Deployment is deferred because it may be contained in the Webapp and not on the EJB jars, and EJB jars are deployed first (TOMEE-189 and TOMEE-722). Until now, we didn’t rely on CDI to load any of the server features, so this was fine. With MP, we added the ability to include / exclude additional urls to be included in the CDI scanner (https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b <https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b>). 
>>> 
>>> The issue here is that we now need to load only the build in CDI features, while deferring the internal / possible CDI beans contained in the EAR file. This might be a possible solution:
>>> https://github.com/apache/tomee/commit/c6397e26e191f717b96934f2e279acfe320451b9 <https://github.com/apache/tomee/commit/c6397e26e191f717b96934f2e279acfe320451b9>. 
>>> 
>>> Servlet / MP Rest endpoint clashing:
>>> If an existent app is only using servlets and has a servlet mapping to the root context or /*, MP endpoints will override the context root with a REST path and the servlet will 404. This has nothing to do with MP itself, if you write an app with a servlet mapping to /* and add a REST endpoint to /, the REST endpoint takes precedence and you are unable to reach the servlet. My concern here is that someone out there might run into this and we break their app with the new version of TomEE. This should probably do the trick: https://github.com/apache/tomee/commit/4ade980c56276a2ad4f2df921e12314e38e881cf <https://github.com/apache/tomee/commit/4ade980c56276a2ad4f2df921e12314e38e881cf> 
>>> 
>>> Tomcat TomEE Webapp (with Plus and Plume)
>>> Deployment of the TomEE Webapp in Tomcat with MP was also not working. This was because CDI scanning for the TomEE web app was disabled by default (since we didn’t rely on any CDI services before). Also, the web.xml was marked as metadata complete, which also skips any annotation deployment processing. I’m a little concern with the change here due to the previous comment that it might affect TomEE embedded, but so far it seemed fine: https://github.com/apache/tomee/commit/e55760d0e230612de7f99b7c4940b1305456dbaf <https://github.com/apache/tomee/commit/e55760d0e230612de7f99b7c4940b1305456dbaf> 
>>> 
>>> ApplicationComposer on Arquillian Remote
>>> Right now, I was not able to have this working. This is because ApplicationComposer, when using CDI, you manually state in the annotation which CDI beans are required. In this case, any additional Bean scanning is skipped. Again, we probably need to adjust it to also include the container provided CDI beans.
>>> 
>>> RestEndpoint / OpenAPI
>>> I’ve run into a StringIndexOutOfBoundsException when OpenAPI is processing REST annotations. I’m now looking into that. Not sure if it might be a bug in OpenAPI implementation or something else.
>>> 
>>> Well, this is it for now. Sorry for the long email. All the work has been done in this PR:
>>> https://github.com/apache/tomee/pull/304/ <https://github.com/apache/tomee/pull/304/>
>>> 
>>> It would definitely need a few set of eyes to review it.
>>> 
>>> Thank you!
>>> 
>>> Cheers,
>>> Roberto
>>> 
>>>> On 23 Jan 2019, at 11:28, Roberto Cortez <ra...@yahoo.com.INVALID> wrote:
>>>> 
>>>> We introduced a couple of new properties to allows additional jars to be added in the DeploymentLoader, so they can be scanned.
>>>> 
>>>> This was done here:
>>>> https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b <https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b> 
>>>> 
>>>> What you probably need to do is have your custom classloader to also load the mp specific libraries, so they can be also scanned.
>>>> 
>>>> Yes, I’ve run into multiple other issues. I’m going to send an email about it, next. I think we can make it, we just need to validate if these changes make sense and if they are right.
>>>> 
>>>> Thank you,
>>>> Roberto
>>>> 
>>>>> On 23 Jan 2019, at 10:55, j4fm <ja...@my-managed.net> wrote:
>>>>> 
>>>>> Okay, so digging into this loader, there is this line:
>>>>> 
>>>>> SystemInstance.get().setComponent(ParentClassLoaderFinder.class, fallback ->
>>>>> MyClassLoader._getOrCreateInstance(parent));
>>>>> 
>>>>> Commenting it out seems to make it play nicely with MP but brakes the class
>>>>> loading of the webapps when openejb's scanning annotations.
>>>>> 
>>>>> So am currently looking at other solutions to make both work.  I think this
>>>>> is something that can be solved but am suspecting there is a chance there is
>>>>> a bug with openejb not using the correct class loaders for the webapps.
>>>>> Trying some things.
>>>>> 
>>>>> Are you still finding issues with MP in Plus with the test cases failing?
>>>>> Is there anything else blocking having MP in Plus for M2 release?  I don't
>>>>> want to become a blocker for that, will know today if this class loading
>>>>> issue can be solved or a bug.  It would be really great if M2 could have MP
>>>>> in Plus but understand how tight it is.
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>>> 

Re: MicroProfile Integration in Plus and Plume

[Bruno Baptista <br...@gmail.com>]

Roberto,

I run a full build and it didn't finish. It got stuck on while running 
the tomee/tck/cdi-tomee tests.

Apart from that, I found these issues:

itests/legacy-server

[ERROR] Failures:
[ERROR]   LegacyServerTest.test:212->assertBalance:230 3 out of 1000 is 
too low

tck/cdi-embeddedrver
[ERROR] Failures:
[ERROR] 
EnterpriseSelectedAlternative02Test>Arquillian.arquillianBeforeClass:109 
» Deployment
[ERROR] 
EnterpriseSelectedAlternative03Test>Arquillian.arquillianBeforeClass:109 
» Deployment
[ERROR] EnterpriseBeanDiscoveryTest>Arquillian.arquillianBeforeClass:109 
» Deployment ...
[ERROR] LibraryInEarTest>Arquillian.arquillianBeforeClass:109 » 
Deployment can't deplo...
[ERROR] 
MultiWebModuleWithExtensionTest>Arquillian.arquillianBeforeClass:109 » 
Deployment
[ERROR] 
SingleWebModuleWithExtensionTest>Arquillian.arquillianBeforeClass:109 » 
Deployment
[ERROR] 
BeanRegistrationByExtensionInEarLibraryTest>Arquillian.arquillianBeforeClass:109 
» Deployment
[ERROR] 
EnabledManagedBeanInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 
» Deployment
[ERROR] 
EnabledProducerFieldInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 
» Deployment
[ERROR] 
EnabledProducerMethodInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 
» Deployment
[ERROR] 
EnabledSessionBeanInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 
» Deployment
[ERROR] InterModuleELResolutionTest>Arquillian.arquillianBeforeClass:109 
» Deployment ...
[ERROR] InterModuleLookupTest>Arquillian.arquillianBeforeClass:109 » 
Deployment can't ...
[ERROR] 
SelectedAlternativeManagedBeanInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 
» Deployment
[ERROR] 
SelectedAlternativeSessionBeanInjectionAvailabilityTest>Arquillian.arquillianBeforeClass:109 
» Deployment
[ERROR] 
SpecializedProducerMethodInjectionNotAvailableTest>Arquillian.arquillianBeforeClass:109 
» Deployment
[ERROR] 
SpecializationModularity02Test>Arquillian.arquillianBeforeClass:109 » 
Deployment
[ERROR] 
SpecializationModularity04Test>Arquillian.arquillianBeforeClass:109 » 
Deployment
[ERROR] Specialization06Test>Arquillian.arquillianBeforeClass:109 » 
Deployment can't d...

Cheers

Bruno Baptista
https://twitter.com/brunobat_


On 23/01/19 12:26, Bruno Baptista wrote:
> Hi Roberto,
>
> I'll take a look at the PR.
>
> Cheers.
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 23/01/19 11:30, Roberto Cortez wrote:
>> Hi folks,
>>
>> Let me try to give a full overview on what I have been working on in 
>> the last couple of days. Progress has been a bit slow unfortunately, 
>> due to the amount of combinations and tests that I have to run every 
>> time I do a change. On the other hand, I know understand way better 
>> how TomEE does the deployment :) Anyway, I’m starting to question 
>> myself if I’m going in the right direction.
>>
>> MP EAR Support:
>> MP CDI Extensions, or any CDI Extension is always loaded if found in 
>> the classpath via the ServiceLoader. For WAR this works fine. On EAR, 
>> CDI Deployment is deferred because it may be contained in the Webapp 
>> and not on the EJB jars, and EJB jars are deployed first (TOMEE-189 
>> and TOMEE-722). Until now, we didn’t rely on CDI to load any of the 
>> server features, so this was fine. With MP, we added the ability to 
>> include / exclude additional urls to be included in the CDI scanner 
>> (https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b 
>> <https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b>). 
>>
>>
>> The issue here is that we now need to load only the build in CDI 
>> features, while deferring the internal / possible CDI beans contained 
>> in the EAR file. This might be a possible solution:
>> https://github.com/apache/tomee/commit/c6397e26e191f717b96934f2e279acfe320451b9 
>> <https://github.com/apache/tomee/commit/c6397e26e191f717b96934f2e279acfe320451b9>. 
>>
>>
>> Servlet / MP Rest endpoint clashing:
>> If an existent app is only using servlets and has a servlet mapping 
>> to the root context or /*, MP endpoints will override the context 
>> root with a REST path and the servlet will 404. This has nothing to 
>> do with MP itself, if you write an app with a servlet mapping to /* 
>> and add a REST endpoint to /, the REST endpoint takes precedence and 
>> you are unable to reach the servlet. My concern here is that someone 
>> out there might run into this and we break their app with the new 
>> version of TomEE. This should probably do the trick: 
>> https://github.com/apache/tomee/commit/4ade980c56276a2ad4f2df921e12314e38e881cf 
>> <https://github.com/apache/tomee/commit/4ade980c56276a2ad4f2df921e12314e38e881cf> 
>>
>>
>> Tomcat TomEE Webapp (with Plus and Plume)
>> Deployment of the TomEE Webapp in Tomcat with MP was also not 
>> working. This was because CDI scanning for the TomEE web app was 
>> disabled by default (since we didn’t rely on any CDI services 
>> before). Also, the web.xml was marked as metadata complete, which 
>> also skips any annotation deployment processing. I’m a little concern 
>> with the change here due to the previous comment that it might affect 
>> TomEE embedded, but so far it seemed fine: 
>> https://github.com/apache/tomee/commit/e55760d0e230612de7f99b7c4940b1305456dbaf 
>> <https://github.com/apache/tomee/commit/e55760d0e230612de7f99b7c4940b1305456dbaf> 
>>
>>
>> ApplicationComposer on Arquillian Remote
>> Right now, I was not able to have this working. This is because 
>> ApplicationComposer, when using CDI, you manually state in the 
>> annotation which CDI beans are required. In this case, any additional 
>> Bean scanning is skipped. Again, we probably need to adjust it to 
>> also include the container provided CDI beans.
>>
>> RestEndpoint / OpenAPI
>> I’ve run into a StringIndexOutOfBoundsException when OpenAPI is 
>> processing REST annotations. I’m now looking into that. Not sure if 
>> it might be a bug in OpenAPI implementation or something else.
>>
>> Well, this is it for now. Sorry for the long email. All the work has 
>> been done in this PR:
>> https://github.com/apache/tomee/pull/304/ 
>> <https://github.com/apache/tomee/pull/304/>
>>
>> It would definitely need a few set of eyes to review it.
>>
>> Thank you!
>>
>> Cheers,
>> Roberto
>>
>>> On 23 Jan 2019, at 11:28, Roberto Cortez 
>>> <ra...@yahoo.com.INVALID> wrote:
>>>
>>> We introduced a couple of new properties to allows additional jars 
>>> to be added in the DeploymentLoader, so they can be scanned.
>>>
>>> This was done here:
>>> https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b 
>>> <https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b> 
>>>
>>>
>>> What you probably need to do is have your custom classloader to also 
>>> load the mp specific libraries, so they can be also scanned.
>>>
>>> Yes, I’ve run into multiple other issues. I’m going to send an email 
>>> about it, next. I think we can make it, we just need to validate if 
>>> these changes make sense and if they are right.
>>>
>>> Thank you,
>>> Roberto
>>>
>>>> On 23 Jan 2019, at 10:55, j4fm <ja...@my-managed.net> wrote:
>>>>
>>>> Okay, so digging into this loader, there is this line:
>>>>
>>>> SystemInstance.get().setComponent(ParentClassLoaderFinder.class, 
>>>> fallback ->
>>>> MyClassLoader._getOrCreateInstance(parent));
>>>>
>>>> Commenting it out seems to make it play nicely with MP but brakes 
>>>> the class
>>>> loading of the webapps when openejb's scanning annotations.
>>>>
>>>> So am currently looking at other solutions to make both work.  I 
>>>> think this
>>>> is something that can be solved but am suspecting there is a chance 
>>>> there is
>>>> a bug with openejb not using the correct class loaders for the 
>>>> webapps.
>>>> Trying some things.
>>>>
>>>> Are you still finding issues with MP in Plus with the test cases 
>>>> failing?
>>>> Is there anything else blocking having MP in Plus for M2 release?  
>>>> I don't
>>>> want to become a blocker for that, will know today if this class 
>>>> loading
>>>> issue can be solved or a bug.  It would be really great if M2 could 
>>>> have MP
>>>> in Plus but understand how tight it is.
>>>>
>>>>
>>>>
>>>> -- 
>>>> Sent from: 
>>>> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>>

Re: MicroProfile Integration in Plus and Plume

[Bruno Baptista <br...@gmail.com>]

Hi Roberto,

I'll take a look at the PR.

Cheers.

Bruno Baptista
https://twitter.com/brunobat_


On 23/01/19 11:30, Roberto Cortez wrote:
> Hi folks,
>
> Let me try to give a full overview on what I have been working on in the last couple of days. Progress has been a bit slow unfortunately, due to the amount of combinations and tests that I have to run every time I do a change. On the other hand, I know understand way better how TomEE does the deployment :) Anyway, I’m starting to question myself if I’m going in the right direction.
>
> MP EAR Support:
> MP CDI Extensions, or any CDI Extension is always loaded if found in the classpath via the ServiceLoader. For WAR this works fine. On EAR, CDI Deployment is deferred because it may be contained in the Webapp and not on the EJB jars, and EJB jars are deployed first (TOMEE-189 and TOMEE-722). Until now, we didn’t rely on CDI to load any of the server features, so this was fine. With MP, we added the ability to include / exclude additional urls to be included in the CDI scanner (https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b <https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b>).
>
> The issue here is that we now need to load only the build in CDI features, while deferring the internal / possible CDI beans contained in the EAR file. This might be a possible solution:
> https://github.com/apache/tomee/commit/c6397e26e191f717b96934f2e279acfe320451b9 <https://github.com/apache/tomee/commit/c6397e26e191f717b96934f2e279acfe320451b9>.
>
> Servlet / MP Rest endpoint clashing:
> If an existent app is only using servlets and has a servlet mapping to the root context or /*, MP endpoints will override the context root with a REST path and the servlet will 404. This has nothing to do with MP itself, if you write an app with a servlet mapping to /* and add a REST endpoint to /, the REST endpoint takes precedence and you are unable to reach the servlet. My concern here is that someone out there might run into this and we break their app with the new version of TomEE. This should probably do the trick: https://github.com/apache/tomee/commit/4ade980c56276a2ad4f2df921e12314e38e881cf <https://github.com/apache/tomee/commit/4ade980c56276a2ad4f2df921e12314e38e881cf>
>
> Tomcat TomEE Webapp (with Plus and Plume)
> Deployment of the TomEE Webapp in Tomcat with MP was also not working. This was because CDI scanning for the TomEE web app was disabled by default (since we didn’t rely on any CDI services before). Also, the web.xml was marked as metadata complete, which also skips any annotation deployment processing. I’m a little concern with the change here due to the previous comment that it might affect TomEE embedded, but so far it seemed fine: https://github.com/apache/tomee/commit/e55760d0e230612de7f99b7c4940b1305456dbaf <https://github.com/apache/tomee/commit/e55760d0e230612de7f99b7c4940b1305456dbaf>
>
> ApplicationComposer on Arquillian Remote
> Right now, I was not able to have this working. This is because ApplicationComposer, when using CDI, you manually state in the annotation which CDI beans are required. In this case, any additional Bean scanning is skipped. Again, we probably need to adjust it to also include the container provided CDI beans.
>
> RestEndpoint / OpenAPI
> I’ve run into a StringIndexOutOfBoundsException when OpenAPI is processing REST annotations. I’m now looking into that. Not sure if it might be a bug in OpenAPI implementation or something else.
>
> Well, this is it for now. Sorry for the long email. All the work has been done in this PR:
> https://github.com/apache/tomee/pull/304/ <https://github.com/apache/tomee/pull/304/>
>
> It would definitely need a few set of eyes to review it.
>
> Thank you!
>
> Cheers,
> Roberto
>
>> On 23 Jan 2019, at 11:28, Roberto Cortez <ra...@yahoo.com.INVALID> wrote:
>>
>> We introduced a couple of new properties to allows additional jars to be added in the DeploymentLoader, so they can be scanned.
>>
>> This was done here:
>> https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b <https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b>
>>
>> What you probably need to do is have your custom classloader to also load the mp specific libraries, so they can be also scanned.
>>
>> Yes, I’ve run into multiple other issues. I’m going to send an email about it, next. I think we can make it, we just need to validate if these changes make sense and if they are right.
>>
>> Thank you,
>> Roberto
>>
>>> On 23 Jan 2019, at 10:55, j4fm <ja...@my-managed.net> wrote:
>>>
>>> Okay, so digging into this loader, there is this line:
>>>
>>> SystemInstance.get().setComponent(ParentClassLoaderFinder.class, fallback ->
>>> MyClassLoader._getOrCreateInstance(parent));
>>>
>>> Commenting it out seems to make it play nicely with MP but brakes the class
>>> loading of the webapps when openejb's scanning annotations.
>>>
>>> So am currently looking at other solutions to make both work.  I think this
>>> is something that can be solved but am suspecting there is a chance there is
>>> a bug with openejb not using the correct class loaders for the webapps.
>>> Trying some things.
>>>
>>> Are you still finding issues with MP in Plus with the test cases failing?
>>> Is there anything else blocking having MP in Plus for M2 release?  I don't
>>> want to become a blocker for that, will know today if this class loading
>>> issue can be solved or a bug.  It would be really great if M2 could have MP
>>> in Plus but understand how tight it is.
>>>
>>>
>>>
>>> --
>>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Hi folks,

Let me try to give a full overview on what I have been working on in the last couple of days. Progress has been a bit slow unfortunately, due to the amount of combinations and tests that I have to run every time I do a change. On the other hand, I know understand way better how TomEE does the deployment :) Anyway, I’m starting to question myself if I’m going in the right direction.

MP EAR Support:
MP CDI Extensions, or any CDI Extension is always loaded if found in the classpath via the ServiceLoader. For WAR this works fine. On EAR, CDI Deployment is deferred because it may be contained in the Webapp and not on the EJB jars, and EJB jars are deployed first (TOMEE-189 and TOMEE-722). Until now, we didn’t rely on CDI to load any of the server features, so this was fine. With MP, we added the ability to include / exclude additional urls to be included in the CDI scanner (https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b <https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b>).

The issue here is that we now need to load only the build in CDI features, while deferring the internal / possible CDI beans contained in the EAR file. This might be a possible solution:
https://github.com/apache/tomee/commit/c6397e26e191f717b96934f2e279acfe320451b9 <https://github.com/apache/tomee/commit/c6397e26e191f717b96934f2e279acfe320451b9>.

Servlet / MP Rest endpoint clashing:
If an existent app is only using servlets and has a servlet mapping to the root context or /*, MP endpoints will override the context root with a REST path and the servlet will 404. This has nothing to do with MP itself, if you write an app with a servlet mapping to /* and add a REST endpoint to /, the REST endpoint takes precedence and you are unable to reach the servlet. My concern here is that someone out there might run into this and we break their app with the new version of TomEE. This should probably do the trick: https://github.com/apache/tomee/commit/4ade980c56276a2ad4f2df921e12314e38e881cf <https://github.com/apache/tomee/commit/4ade980c56276a2ad4f2df921e12314e38e881cf>

Tomcat TomEE Webapp (with Plus and Plume)
Deployment of the TomEE Webapp in Tomcat with MP was also not working. This was because CDI scanning for the TomEE web app was disabled by default (since we didn’t rely on any CDI services before). Also, the web.xml was marked as metadata complete, which also skips any annotation deployment processing. I’m a little concern with the change here due to the previous comment that it might affect TomEE embedded, but so far it seemed fine: https://github.com/apache/tomee/commit/e55760d0e230612de7f99b7c4940b1305456dbaf <https://github.com/apache/tomee/commit/e55760d0e230612de7f99b7c4940b1305456dbaf>

ApplicationComposer on Arquillian Remote
Right now, I was not able to have this working. This is because ApplicationComposer, when using CDI, you manually state in the annotation which CDI beans are required. In this case, any additional Bean scanning is skipped. Again, we probably need to adjust it to also include the container provided CDI beans.

RestEndpoint / OpenAPI
I’ve run into a StringIndexOutOfBoundsException when OpenAPI is processing REST annotations. I’m now looking into that. Not sure if it might be a bug in OpenAPI implementation or something else.

Well, this is it for now. Sorry for the long email. All the work has been done in this PR:
https://github.com/apache/tomee/pull/304/ <https://github.com/apache/tomee/pull/304/>

It would definitely need a few set of eyes to review it. 

Thank you!

Cheers,
Roberto

> On 23 Jan 2019, at 11:28, Roberto Cortez <ra...@yahoo.com.INVALID> wrote:
> 
> We introduced a couple of new properties to allows additional jars to be added in the DeploymentLoader, so they can be scanned.
> 
> This was done here:
> https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b <https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b>
> 
> What you probably need to do is have your custom classloader to also load the mp specific libraries, so they can be also scanned.
> 
> Yes, I’ve run into multiple other issues. I’m going to send an email about it, next. I think we can make it, we just need to validate if these changes make sense and if they are right.
> 
> Thank you,
> Roberto
> 
>> On 23 Jan 2019, at 10:55, j4fm <ja...@my-managed.net> wrote:
>> 
>> Okay, so digging into this loader, there is this line:
>> 
>> SystemInstance.get().setComponent(ParentClassLoaderFinder.class, fallback ->
>> MyClassLoader._getOrCreateInstance(parent));
>> 
>> Commenting it out seems to make it play nicely with MP but brakes the class
>> loading of the webapps when openejb's scanning annotations.
>> 
>> So am currently looking at other solutions to make both work.  I think this
>> is something that can be solved but am suspecting there is a chance there is
>> a bug with openejb not using the correct class loaders for the webapps. 
>> Trying some things.
>> 
>> Are you still finding issues with MP in Plus with the test cases failing? 
>> Is there anything else blocking having MP in Plus for M2 release?  I don't
>> want to become a blocker for that, will know today if this class loading
>> issue can be solved or a bug.  It would be really great if M2 could have MP
>> in Plus but understand how tight it is.
>> 
>> 
>> 
>> --
>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> 

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

We introduced a couple of new properties to allows additional jars to be added in the DeploymentLoader, so they can be scanned.

This was done here:
https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b <https://github.com/apache/tomee/commit/021b9ca8d01a78f5b7ee3438f30fd8901ff60d5b>

What you probably need to do is have your custom classloader to also load the mp specific libraries, so they can be also scanned.

Yes, I’ve run into multiple other issues. I’m going to send an email about it, next. I think we can make it, we just need to validate if these changes make sense and if they are right.

Thank you,
Roberto

> On 23 Jan 2019, at 10:55, j4fm <ja...@my-managed.net> wrote:
> 
> Okay, so digging into this loader, there is this line:
> 
> SystemInstance.get().setComponent(ParentClassLoaderFinder.class, fallback ->
> MyClassLoader._getOrCreateInstance(parent));
> 
> Commenting it out seems to make it play nicely with MP but brakes the class
> loading of the webapps when openejb's scanning annotations.
> 
> So am currently looking at other solutions to make both work.  I think this
> is something that can be solved but am suspecting there is a chance there is
> a bug with openejb not using the correct class loaders for the webapps. 
> Trying some things.
> 
> Are you still finding issues with MP in Plus with the test cases failing? 
> Is there anything else blocking having MP in Plus for M2 release?  I don't
> want to become a blocker for that, will know today if this class loading
> issue can be solved or a bug.  It would be really great if M2 could have MP
> in Plus but understand how tight it is.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Okay, so digging into this loader, there is this line:

SystemInstance.get().setComponent(ParentClassLoaderFinder.class, fallback ->
MyClassLoader._getOrCreateInstance(parent));

Commenting it out seems to make it play nicely with MP but brakes the class
loading of the webapps when openejb's scanning annotations.

So am currently looking at other solutions to make both work.  I think this
is something that can be solved but am suspecting there is a chance there is
a bug with openejb not using the correct class loaders for the webapps. 
Trying some things.

Are you still finding issues with MP in Plus with the test cases failing? 
Is there anything else blocking having MP in Plus for M2 release?  I don't
want to become a blocker for that, will know today if this class loading
issue can be solved or a bug.  It would be really great if M2 could have MP
in Plus but understand how tight it is.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

In the webapps, there is a loader specified in the context.xml.  This
singleton loader ensures that native libraries used by the webapps are
ultimately only loaded once but only the specific webapps load them rather
than affecting all webapps on TomEE.





--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Hum… could you give more details about your custom class loader?

Right now, I have a failing test that seems caused by me change. Trying to figure it out.

> On 21 Jan 2019, at 23:46, j4fm <ja...@my-managed.net> wrote:
> 
> Hi, sorry for the delay.  Both WAR files and also external webbase context
> with a custom class loader.  Interesting, happy to test.  Thank you
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hi, sorry for the delay.  Both WAR files and also external webbase context
with a custom class loader.  Interesting, happy to test.  Thank you



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

I think I may have found a solution. I’m not completely sure if the fix is safe and won’t break something else. Running some tests and hopefully if everything is ok, I’ll have the fix and merge by tomorrow.

> On 21 Jan 2019, at 14:33, Roberto Cortez <ra...@yahoo.com.INVALID> wrote:
> 
> Hey,
> 
> I was wondering how are you deploying your apps. Are you using EAR files by any chance?
> 
> Cheers,
> Roberto
> 
>> On 18 Jan 2019, at 10:42, Roberto Cortez <ra...@yahoo.com.INVALID> wrote:
>> 
>> Ok thanks. I’ll try to investigate further.
>> 
>>> On 17 Jan 2019, at 21:08, j4fm <ja...@my-managed.net> wrote:
>>> 
>>> They are not small or independent but I will see what I can put together.
>>> 
>>> This looks related...
>>> 
>>> http://tomee-openejb.979440.n4.nabble.com/PRIVATE-ApplicationComposer-7-0-0-and-Jars-td4677302.html
>>> 
>>> 
>>> 
>>> "In CdiScanner I can see the classes in BeanInfo beans. 
>>> 
>>> But just after the following condition is true : 
>>> 
>>> } else if (ejbJar.webapp && !appInfo.webAppAlone) { 
>>>  continue; 
>>> } 
>>> 
>>> (CdiScanner: 118) 
>>> So the classes are not take in care..."
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>> 
> 

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Hey,

I was wondering how are you deploying your apps. Are you using EAR files by any chance?

Cheers,
Roberto

> On 18 Jan 2019, at 10:42, Roberto Cortez <ra...@yahoo.com.INVALID> wrote:
> 
> Ok thanks. I’ll try to investigate further.
> 
>> On 17 Jan 2019, at 21:08, j4fm <ja...@my-managed.net> wrote:
>> 
>> They are not small or independent but I will see what I can put together.
>> 
>> This looks related...
>> 
>> http://tomee-openejb.979440.n4.nabble.com/PRIVATE-ApplicationComposer-7-0-0-and-Jars-td4677302.html
>> 
>> 
>> 
>> "In CdiScanner I can see the classes in BeanInfo beans. 
>> 
>> But just after the following condition is true : 
>> 
>> } else if (ejbJar.webapp && !appInfo.webAppAlone) { 
>>   continue; 
>> } 
>> 
>> (CdiScanner: 118) 
>> So the classes are not take in care..."
>> 
>> 
>> 
>> --
>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> 

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Ok thanks. I’ll try to investigate further.

> On 17 Jan 2019, at 21:08, j4fm <ja...@my-managed.net> wrote:
> 
> They are not small or independent but I will see what I can put together.
> 
> This looks related...
> 
> http://tomee-openejb.979440.n4.nabble.com/PRIVATE-ApplicationComposer-7-0-0-and-Jars-td4677302.html
> 
> 
> 
> "In CdiScanner I can see the classes in BeanInfo beans. 
> 
> But just after the following condition is true : 
> 
> } else if (ejbJar.webapp && !appInfo.webAppAlone) { 
>    continue; 
> } 
> 
> (CdiScanner: 118) 
> So the classes are not take in care..."
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

They are not small or independent but I will see what I can put together.

This looks related...

http://tomee-openejb.979440.n4.nabble.com/PRIVATE-ApplicationComposer-7-0-0-and-Jars-td4677302.html



"In CdiScanner I can see the classes in BeanInfo beans. 

But just after the following condition is true : 

} else if (ejbJar.webapp && !appInfo.webAppAlone) { 
    continue; 
} 

(CdiScanner: 118) 
So the classes are not take in care..."



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Well that is one of the issues.

There are other issues that I’ve seen being thrown by the apps being deployed on the TomEE TCK, but I didn’t focus on them yet. Not sure if they are the same as you are describing here.

Any chance that you can send me a sample that replicates this problem?

Thanks!

Cheers,
Roberto

> On 17 Jan 2019, at 19:16, j4fm <ja...@my-managed.net> wrote:
> 
> I'm not sure the problem I'm having with our existing apps when MP is in Plus
> is related to the root context.  This is with pull304 you wrote.  This
> problem doesn't happen with only a simply basic war file in TomEE only when
> our apps are in (class loader and war files).
> 
> The traditional contexts load fine without MP and MP runs fine with a hello
> world war.
> 
> I've checked again and have examples of the exceptions (lots of them but all
> look they are all of the same type of issue)...
> 
> 
> SEVERE [main] org.apache.openejb.cdi.OpenEJBLifecycle.startApplication CDI
> Beans module deployment failed
> org.apache.webbeans.exception.WebBeansDeploymentException: Error while
> sending SystemEvent to a CDI Extension!
> org.apache.webbeans.portable.events.discovery.AfterDeploymentValidationImpl@2a6b6f4
> at
> org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:731)
> at
> org.apache.webbeans.container.BeanManagerImpl.fireEvent(BeanManagerImpl.java:495)
> at
> org.apache.webbeans.container.BeanManagerImpl.fireLifecycleEvent(BeanManagerImpl.java:490)
> at
> org.apache.webbeans.config.BeansDeployer.fireAfterDeploymentValidationEvent(BeansDeployer.java:870)
> at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:344)
> at
> org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:196)
> at
> org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:229)
> at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
> at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:963)
> at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:756)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1308)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1130)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:134)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5007)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:703)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:630)
> at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1840)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:525)
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:424)
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1585)
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:308)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:424)
> at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:367)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:969)
> at
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:839)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1429)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:944)
> at
> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:261)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:422)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:770)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:682)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:350)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> Caused by: org.apache.webbeans.exception.WebBeansException:
> java.lang.NullPointerException: bean parameter may not be null
> at
> org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:371)
> at
> org.apache.webbeans.event.NotificationManager.invokeObserverMethod(NotificationManager.java:818)
> at
> org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:714)
> ... 53 more
> Caused by: java.lang.NullPointerException: bean parameter may not be null
> at org.apache.webbeans.util.Asserts.assertNotNull(Asserts.java:52)
> at
> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:727)
> at
> org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:180)
> at
> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension.afterValidation(GeronimoOpenAPIExtension.java:113)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.webbeans.event.ObserverMethodImpl.invoke(ObserverMethodImpl.java:404)
> at
> org.apache.webbeans.event.ContainerEventObserverMethodImpl.invoke(ContainerEventObserverMethodImpl.java:85)
> at
> org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:365)
> ... 55 more
> 
> 
> 17-Jan-2019 19:02:17.989 SEVERE [main]
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal Unable to deploy
> collapsed ear in war
> StandardEngine[Catalina].StandardHost[localhost].StandardContext[/anappwar]
> javax.enterprise.inject.spi.DeploymentException: couldn't start owb context
> at
> org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:231)
> at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
> at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:963)
> at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:756)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1308)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1130)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:134)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5007)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:703)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:630)
> at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1840)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:525)
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:424)
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1585)
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:308)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:424)
> at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:367)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:969)
> at
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:839)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1429)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:944)
> at
> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:261)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:422)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:770)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:682)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:350)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> Caused by: org.apache.openejb.OpenEJBRuntimeException:
> org.apache.webbeans.exception.WebBeansDeploymentException: Error while
> sending SystemEvent to a CDI Extension!
> org.apache.webbeans.portable.events.discovery.AfterDeploymentValidationImpl@2a6b6f4
> at
> org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:200)
> at
> org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:229)
> ... 47 more
> Caused by: org.apache.webbeans.exception.WebBeansDeploymentException: Error
> while sending SystemEvent to a CDI Extension!
> org.apache.webbeans.portable.events.discovery.AfterDeploymentValidationImpl@2a6b6f4
> at
> org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:731)
> at
> org.apache.webbeans.container.BeanManagerImpl.fireEvent(BeanManagerImpl.java:495)
> at
> org.apache.webbeans.container.BeanManagerImpl.fireLifecycleEvent(BeanManagerImpl.java:490)
> at
> org.apache.webbeans.config.BeansDeployer.fireAfterDeploymentValidationEvent(BeansDeployer.java:870)
> at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:344)
> at
> org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:196)
> ... 48 more
> Caused by: org.apache.webbeans.exception.WebBeansException:
> java.lang.NullPointerException: bean parameter may not be null
> at
> org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:371)
> at
> org.apache.webbeans.event.NotificationManager.invokeObserverMethod(NotificationManager.java:818)
> at
> org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:714)
> ... 53 more
> Caused by: java.lang.NullPointerException: bean parameter may not be null
> at org.apache.webbeans.util.Asserts.assertNotNull(Asserts.java:52)
> at
> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:727)
> at
> org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:180)
> at
> org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension.afterValidation(GeronimoOpenAPIExtension.java:113)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.webbeans.event.ObserverMethodImpl.invoke(ObserverMethodImpl.java:404)
> at
> org.apache.webbeans.event.ContainerEventObserverMethodImpl.invoke(ContainerEventObserverMethodImpl.java:85)
> at
> org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:365)
> ... 55 more
> 
> SEVERE [main] jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> ContainerBase.removeChild: destroy:
> org.apache.catalina.LifecycleException: An invalid Lifecycle transition was
> attempted ([before_destroy]) for component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/abcdapp]]
> in state [STARTING_PREP]
> at
> org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:431)
> at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:317)
> at
> org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:845)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.undeploy(TomcatWebAppBuilder.java:1656)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.undeploy(TomcatWebAppBuilder.java:1636)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1317)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1130)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:134)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5007)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:703)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:630)
> at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1840)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:525)
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:424)
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1585)
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:308)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:424)
> at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:367)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:969)
> at
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:839)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1429)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:944)
> at
> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:261)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:422)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> -- More  --
> 
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

I'm not sure the problem I'm having with our existing apps when MP is in Plus
is related to the root context.  This is with pull304 you wrote.  This
problem doesn't happen with only a simply basic war file in TomEE only when
our apps are in (class loader and war files).

The traditional contexts load fine without MP and MP runs fine with a hello
world war.

I've checked again and have examples of the exceptions (lots of them but all
look they are all of the same type of issue)...


SEVERE [main] org.apache.openejb.cdi.OpenEJBLifecycle.startApplication CDI
Beans module deployment failed
 org.apache.webbeans.exception.WebBeansDeploymentException: Error while
sending SystemEvent to a CDI Extension!
org.apache.webbeans.portable.events.discovery.AfterDeploymentValidationImpl@2a6b6f4
 at
org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:731)
 at
org.apache.webbeans.container.BeanManagerImpl.fireEvent(BeanManagerImpl.java:495)
 at
org.apache.webbeans.container.BeanManagerImpl.fireLifecycleEvent(BeanManagerImpl.java:490)
 at
org.apache.webbeans.config.BeansDeployer.fireAfterDeploymentValidationEvent(BeansDeployer.java:870)
 at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:344)
 at
org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:196)
 at
org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:229)
 at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
 at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:963)
 at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:756)
 at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1308)
 at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1130)
 at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:134)
 at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
 at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5007)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719)
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:703)
 at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:630)
 at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1840)
 at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
 at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
 at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
 at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
 at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:525)
 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:424)
 at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1585)
 at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:308)
 at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
 at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:424)
 at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:367)
 at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:969)
 at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:839)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1429)
 at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
 at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
 at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
 at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
 at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:944)
 at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:261)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:422)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:770)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:682)
 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:566)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:350)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
Caused by: org.apache.webbeans.exception.WebBeansException:
java.lang.NullPointerException: bean parameter may not be null
 at
org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:371)
 at
org.apache.webbeans.event.NotificationManager.invokeObserverMethod(NotificationManager.java:818)
 at
org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:714)
 ... 53 more
Caused by: java.lang.NullPointerException: bean parameter may not be null
 at org.apache.webbeans.util.Asserts.assertNotNull(Asserts.java:52)
 at
org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:727)
 at
org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:180)
 at
org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension.afterValidation(GeronimoOpenAPIExtension.java:113)
 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:566)
 at
org.apache.webbeans.event.ObserverMethodImpl.invoke(ObserverMethodImpl.java:404)
 at
org.apache.webbeans.event.ContainerEventObserverMethodImpl.invoke(ContainerEventObserverMethodImpl.java:85)
 at
org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:365)
 ... 55 more


17-Jan-2019 19:02:17.989 SEVERE [main]
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal Unable to deploy
collapsed ear in war
StandardEngine[Catalina].StandardHost[localhost].StandardContext[/anappwar]
 javax.enterprise.inject.spi.DeploymentException: couldn't start owb context
 at
org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:231)
 at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
 at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:963)
 at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:756)
 at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1308)
 at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1130)
 at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:134)
 at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
 at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5007)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719)
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:703)
 at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:630)
 at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1840)
 at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
 at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
 at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
 at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
 at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:525)
 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:424)
 at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1585)
 at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:308)
 at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
 at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:424)
 at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:367)
 at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:969)
 at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:839)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1429)
 at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
 at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
 at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
 at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
 at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:944)
 at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:261)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:422)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:770)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:682)
 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:566)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:350)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
Caused by: org.apache.openejb.OpenEJBRuntimeException:
org.apache.webbeans.exception.WebBeansDeploymentException: Error while
sending SystemEvent to a CDI Extension!
org.apache.webbeans.portable.events.discovery.AfterDeploymentValidationImpl@2a6b6f4
 at
org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:200)
 at
org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:229)
 ... 47 more
Caused by: org.apache.webbeans.exception.WebBeansDeploymentException: Error
while sending SystemEvent to a CDI Extension!
org.apache.webbeans.portable.events.discovery.AfterDeploymentValidationImpl@2a6b6f4
 at
org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:731)
 at
org.apache.webbeans.container.BeanManagerImpl.fireEvent(BeanManagerImpl.java:495)
 at
org.apache.webbeans.container.BeanManagerImpl.fireLifecycleEvent(BeanManagerImpl.java:490)
 at
org.apache.webbeans.config.BeansDeployer.fireAfterDeploymentValidationEvent(BeansDeployer.java:870)
 at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:344)
 at
org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:196)
 ... 48 more
Caused by: org.apache.webbeans.exception.WebBeansException:
java.lang.NullPointerException: bean parameter may not be null
 at
org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:371)
 at
org.apache.webbeans.event.NotificationManager.invokeObserverMethod(NotificationManager.java:818)
 at
org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:714)
 ... 53 more
Caused by: java.lang.NullPointerException: bean parameter may not be null
 at org.apache.webbeans.util.Asserts.assertNotNull(Asserts.java:52)
 at
org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:727)
 at
org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:180)
 at
org.apache.geronimo.microprofile.openapi.cdi.GeronimoOpenAPIExtension.afterValidation(GeronimoOpenAPIExtension.java:113)
 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:566)
 at
org.apache.webbeans.event.ObserverMethodImpl.invoke(ObserverMethodImpl.java:404)
 at
org.apache.webbeans.event.ContainerEventObserverMethodImpl.invoke(ContainerEventObserverMethodImpl.java:85)
 at
org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:365)
 ... 55 more

SEVERE [main] jdk.internal.reflect.NativeMethodAccessorImpl.invoke
ContainerBase.removeChild: destroy:
 org.apache.catalina.LifecycleException: An invalid Lifecycle transition was
attempted ([before_destroy]) for component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/abcdapp]]
in state [STARTING_PREP]
 at
org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:431)
 at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:317)
 at
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:845)
 at
org.apache.tomee.catalina.TomcatWebAppBuilder.undeploy(TomcatWebAppBuilder.java:1656)
 at
org.apache.tomee.catalina.TomcatWebAppBuilder.undeploy(TomcatWebAppBuilder.java:1636)
 at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1317)
 at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1130)
 at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:134)
 at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
 at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5007)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719)
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:703)
 at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:630)
 at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1840)
 at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
 at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
 at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
 at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
 at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:525)
 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:424)
 at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1585)
 at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:308)
 at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
 at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:424)
 at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:367)
 at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:969)
 at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:839)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1429)
 at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
 at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
 at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
 at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
 at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:944)
 at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:261)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:422)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
-- More  --




--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

There are cases where MP stuff may clash with older apps, and we caught a couple of these cases in TomEE TCK.

For instance if a webapp is only using servlets and is exposing a servlet in the context root, because MP expose predefined REST endpoints for health, metrics, openapi, etc. the REST Service deployer is going to override the context root to be able to deploy the MP specific endpoints and the original servlet path is not going to work anymore, so you get a 404.

Another case is if you already have any kind of servlet or rest endpoint with the same path of the specific MP endpoints.

So the point is, there is a risk that when you upgrade to a TomEE version with MP support your older apps may clash and they will break and I believe no one would want that :)

Cheers,
Roberto

> On 16 Jan 2019, at 17:46, David Blevins <da...@gmail.com> wrote:
> 
> Zooming back to the start of this thread, can you give some insight on why anyone would want to disable MicroProfile support?  I.e. some perspective on the cost we're attempting to avoid so we can evaluate that against the cost of disabling/enabling.
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 
>> On Jan 16, 2019, at 8:00 AM, Roberto Cortez <ra...@yahoo.com.INVALID> wrote:
>> 
>> Yes, I think I would prefer automatic of course. There might be some challenges to be able to achieve that.
>> 
>> When I was working on it, I was stuck into a point where I was not able to determine if metrics are needed due to their use of interceptors and they are set up with CDI. I probably need to spent some more time looking into it.
>> 
>>> On 16 Jan 2019, at 15:00, j4fm <ja...@my-managed.net> wrote:
>>> 
>>> Happy to contribute if/where I can, for sure - how?
>>> 
>>> If the enabling/disabling of MP scans per-context can be done automatically
>>> - great. If it's a manual configuration that's workable but automatic is
>>> obviously preferred - then things would just work.
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>> 
> 

Re: MicroProfile Integration in Plus and Plume

[David Blevins <da...@gmail.com>]

Zooming back to the start of this thread, can you give some insight on why anyone would want to disable MicroProfile support?  I.e. some perspective on the cost we're attempting to avoid so we can evaluate that against the cost of disabling/enabling.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Jan 16, 2019, at 8:00 AM, Roberto Cortez <ra...@yahoo.com.INVALID> wrote:
> 
> Yes, I think I would prefer automatic of course. There might be some challenges to be able to achieve that.
> 
> When I was working on it, I was stuck into a point where I was not able to determine if metrics are needed due to their use of interceptors and they are set up with CDI. I probably need to spent some more time looking into it.
> 
>> On 16 Jan 2019, at 15:00, j4fm <ja...@my-managed.net> wrote:
>> 
>> Happy to contribute if/where I can, for sure - how?
>> 
>> If the enabling/disabling of MP scans per-context can be done automatically
>> - great. If it's a manual configuration that's workable but automatic is
>> obviously preferred - then things would just work.
>> 
>> 
>> 
>> --
>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> 

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Yes, I think I would prefer automatic of course. There might be some challenges to be able to achieve that.

When I was working on it, I was stuck into a point where I was not able to determine if metrics are needed due to their use of interceptors and they are set up with CDI. I probably need to spent some more time looking into it.

> On 16 Jan 2019, at 15:00, j4fm <ja...@my-managed.net> wrote:
> 
> Happy to contribute if/where I can, for sure - how?
> 
> If the enabling/disabling of MP scans per-context can be done automatically
> - great. If it's a manual configuration that's workable but automatic is
> obviously preferred - then things would just work.
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Happy to contribute if/where I can, for sure - how?

If the enabling/disabling of MP scans per-context can be done automatically
- great. If it's a manual configuration that's workable but automatic is
obviously preferred - then things would just work.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[Roberto Cortez <ra...@yahoo.com.INVALID>]

Hi James,

Thank for your email. I did had some thought and I was trying to track them here:
https://jira.apache.org/jira/browse/TOMEE-2407 <https://jira.apache.org/jira/browse/TOMEE-2407>

Would you like to contribute to it?

Cheers,
Roberto

> On 15 Jan 2019, at 10:24, j4fm <ja...@my-managed.net> wrote:
> 
> Hi again Roberto, I tested this again today and actually I hadn't noticed
> that another ticket commented out MP jars from being added to the Plus
> webapp, just like you said.
> 
> Now if I pull in 304 there our some out of date package references (import
> org.apache.geronimo.microprofile.impl.health.jaxrs.HealthChecksEndpoint;
> import org.apache.geronimo.microprofile.metrics.jaxrs.MetricsEndpoints;) and
> after adding MP jars back in there are null reference exceptions.
> 
> Have you had any more thoughts on the direction for solving this?  Enabled
> per-application is one approach but I'm happy either way if we can have
> non-MP apps and MP apps run in the same TomEE Plus.
> 
> Thank you
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Integration in Plus and Plume

[j4fm <ja...@my-managed.net>]

Hi again Roberto, I tested this again today and actually I hadn't noticed
that another ticket commented out MP jars from being added to the Plus
webapp, just like you said.

Now if I pull in 304 there our some out of date package references (import
org.apache.geronimo.microprofile.impl.health.jaxrs.HealthChecksEndpoint;
import org.apache.geronimo.microprofile.metrics.jaxrs.MetricsEndpoints;) and
after adding MP jars back in there are null reference exceptions.

Have you had any more thoughts on the direction for solving this?  Enabled
per-application is one approach but I'm happy either way if we can have
non-MP apps and MP apps run in the same TomEE Plus.

Thank you



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html