Re: Regression in Arquillian tests

Thu, 20 Dec 2018 03:15:15 -0800 

Hi,
It makes sense to remove MP support from Plume and Plus while these issues are cleared. 

We should probably create a branch to fix those issues.

Cheers.

Bruno Baptista
https://twitter.com/brunobat_


On 20/12/18 10:44, Roberto Cortez wrote:

Hey Ivan,

Thank you.

What TomEE and the Geronimo implementation actually do is to expose all of 
these endpoints in the application context path being deployed. So for instance 
if you have:

app.war, you get:
  - app/health
  - app/metrics
  - app/openapi

movies.war, you get:
  - movies/health
  - movies/metrics
  - movies/openapi

The issue here, is that these endpoints get deployed with any Web application. 
So if you have a web app with simple Servlet, you also get these endpoints 
deployed with the app. This causes issues if the Servlet is mapped to /*, 
because the REST service will override the base context path. Again, to be able 
to expose the MP endpoints on the base app context root.

I’m thinking that we may need to be more smart about this and not just blindly 
expose or start MP behaviour without some additional checks. Things like:
  - Expose the specific MP REST endpoints if the app has other REST services.
  - Expose the specific MP REST endpoints if using specific MP annotation on 
the app (like @Metric that just need a CDI bean)
  - Don’t any Filters if (for JWT and OpenTracing) if these are not in use.

These are just some that came to my mind, but probably there are other cases. 
I’ll probably suggest to remove MP support for Plume and Plus and add the MP 
binary to TomEE TCK tests, disabled but with the ability for us to run them, so 
we can start making adjustments. There are also issues with EAR deployments and 
MP.

Any thoughts?

Cheers,
Roberto


On 20 Dec 2018, at 07:08, Ivan St. Ivanov <[email protected]> wrote:

Hi everyone,

TL; DR; the mentioned paths seem to be context roots, not subpaths.

Let me chime in on the topic of MP spec paths.

   - The Health check spec in Appendix A states that /health is a context
   [path]. Which means that it is directly after the host, i.e.
   http://localhost:8080/health
   - The Metrics spec calls /metrics "base path" (not as specific as Health
   check calling it *context path*)
   - The Open API spec in its section 5.1 gives an example with /openapi
   being a context path too

I remember a discussion in the MP mailing lists a few months ago, where
someone questioned the fact that MP specs should not be considered just for
microservices, where you have one context only. But also in classical app
server scenarios with multiple applications per server. In that sense, the
person starting the discussion asked for application specific health and
metrics endpoints rather then app server specific.

Cheers,
Ivan

On Thu, Dec 20, 2018 at 2:08 AM Roberto Cortez <[email protected]>
wrote:


As far as I know, all their endpoints are on a subpath, but since a CXF
Rest Service needs to be created to expose these paths (/health, /openapi,
/metrics), I think that somehow the deployment service creates service and
overrides the "/".

I will try to see what can be done in that regard. I was thinking that at
the very least, one thing we could do (not sure if possible) is to check if
we have other REST endpoints in the app, and if not, complete skip the
additional MP endpoints deployment.


On 19 Dec 2018, at 20:31, Jonathan Gallimore <

[email protected]> wrote:

How did you got that NPE? I had to debug it and get it from a catch

clause, because it was not showing up in the logs.

Right. For the benefit of others reading this, I ran the test with
-Dopenejb.server.debug, and put a breakpoint here:


https://github.com/apache/tomcat/blob/TOMCAT_9_0_12/java/org/apache/catalina/core/StandardContext.java#L4494
.

and then did a t.printStackTrace(). The output from the server does end

up

in target/surefire-reports/dumpStream*.


It seems that when you are deploying a simple servlet in a MP enabled

container using the /* as the url pattern, this will get overridden when

MP

starts up and adds the endpoints to consume openapi, metrics, health, so
the servlet call ends up in a 404.

Yeah. That's what I was trying to say in my first message, but my coffee
hadn't kicked in at that point. You phrased it way better.

I think we have two issues - 1 is the URL pattern being taken over my MP,
and 2 is certain things not being wired up for whatever reason e.g. the
OpenTracing filter.

Does MicroProfile have to have its endpoints directly off "/", or can

there

be a sub path?

Jon

On Wed, Dec 19, 2018 at 6:38 PM Roberto Cortez

<[email protected]>

wrote:


Ok, I think I got more info.

It seems that when you are deploying a simple servlet in a MP enabled
container using the /* as the url pattern, this will get overridden

when MP

starts up and adds the endpoints to consume openapi, metrics, health, so
the servlet call ends up in a 404.


On 19 Dec 2018, at 18:27, Roberto Cortez <[email protected]>

wrote:

Ah never mind. Forgot this is running in forked mode.


On 19 Dec 2018, at 18:18, Roberto Cortez <[email protected]

wrote:

I’m not completely sure if that library is the only problem. We may

need to remove it all together. For now, I’m just trying to figure out

the

test failures. For some reason, they are not very descriptive on what
failed.

How did you got that NPE? I had to debug it and get it from a catch

clause, because it was not showing up in the logs.

On 19 Dec 2018, at 17:29, Jonathan Gallimore <

[email protected]> wrote:

Interesting. Not sure what the best way is forward at the moment...
thoughts appreciated. If I have a brainwave, I'll post here.

Currently

I'm

wondering if we can just remove that library from TomEE for the tests

until

we can figure it out.

Jon

On Wed, Dec 19, 2018 at 4:12 PM Roberto Cortez

<[email protected]>

wrote:


It seems that there is no single issue that you can use to fix all

the

tests. Adding MP apparently affected all tests in different ways.

For instance AllFilterTest (the one I started looking), was not

starting

any CDI Extensions. Then I figure out that the web.xml had a

metadacomplete

= true that makes the container to not scan the libs folder.

Removing

that

line made it work.

AppComposerTest for some reason it seems is not able to inject a CDI

bean.

This seems to be more tricky, since it is deploying an

ApplicationComposer

and you list the CDI beans explicitly on the test.

In the end, the sources may be different but the cause seems to be

always

related with the init of the OpenTracing filter. There is a config

to

disable it, but I’m not sure if that is the best approach. Maybe the
initialiser should be more clever and not blindly add the Filter

without

checking in everything in the environment is set up

I’ll keep investigating to have more details.


On 19 Dec 2018, at 15:19, Roberto Cortez

<[email protected]

wrote:

Yes. That is because the CDI Extension is not executing. I’m trying

to

figure out why.

On 19 Dec 2018, at 14:45, Jonathan Gallimore <

[email protected]> wrote:

If it helps, here's the exception I'm getting, which is causing

the

app

to

fail to deploy:

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)

at


org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:251)

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.tomee.catalina.TomcatWebAppBuilder.deployWar(TomcatWebAppBuilder.java:658)

at


org.apache.tomee.catalina.TomcatWebAppBuilder.deployWebApps(TomcatWebAppBuilder.java:598)

at


org.apache.tomee.catalina.deployment.TomcatWebappDeployer.deploy(TomcatWebappDeployer.java:47)

at

org.apache.openejb.assembler.DeployerEjb.deploy(DeployerEjb.java:177)

at

org.apache.openejb.assembler.DeployerEjb.deploy(DeployerEjb.java:140)

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)
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)

at


org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:251)

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.tomee.catalina.TomcatWebAppBuilder.deployWar(TomcatWebAppBuilder.java:658)

at


org.apache.tomee.catalina.TomcatWebAppBuilder.deployWebApps(TomcatWebAppBuilder.java:598)

at


org.apache.tomee.catalina.deployment.TomcatWebappDeployer.deploy(TomcatWebappDeployer.java:47)

at

org.apache.openejb.assembler.DeployerEjb.deploy(DeployerEjb.java:177)

at

org.apache.openejb.assembler.DeployerEjb.deploy(DeployerEjb.java:140)

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)

On Wed, Dec 19, 2018 at 2:33 PM Roberto Cortez

<[email protected]>

wrote:


It seems that the CDI Extensions are not running. I first thought

that

it

was because of this setting: openejb.cdi.activated-on-ejb, but it

seems to

have the same effect.

I’ll keep looking.


On 19 Dec 2018, at 13:21, Jonathan Gallimore <

[email protected]> wrote:

I see the issue with surefire:test@test-tomee-remote-plus too.

Trying to

get some more information.

Jon

On Wed, Dec 19, 2018 at 12:39 PM Jonathan Gallimore <
[email protected]> wrote:


Here's my full output:


https://gist.github.com/jgallimore/ead9d0a218d862596858d7dc72bd6f62

There's a few failures for test-tomee-remote-plus, and it gets

worse

when

testing test-tomee-webapp-* executions.

Hope that helps. Neat trick with the command line

@test-tomee-remote-plume

- thanks for that.

Jon



On Wed, Dec 19, 2018 at 12:15 PM Roberto Cortez
<[email protected]> wrote:


I’m using this sample command now:
mvn -Pall-adapters clean test-compile
surefire:test@test-tomee-remote-plume


-Dtest=org.apache.openejb.arquillian.tests.filter.AllFilterTest

It seems to run fine on plus but not on plume.

Investigating...

On 19 Dec 2018, at 11:44, Roberto Cortez

<[email protected]

wrote:

Maybe it does run first. The problem is that the build is

killed,

so

you don’t have a test report output. You have to go and

manually

search the

logs.

What is the exact test you see failing? I see a failure in

the

JMS

project with a simple clean install:

JMSInjectionTest.testJMSInjection:68->validateTest:74 » IO

Server

returned HTT

On 19 Dec 2018, at 11:18, Jonathan Gallimore <

[email protected]> wrote:

I'm not sure of the module ordering, but I thought this ran

first.

I'll

check the CI output.

If you run a build without tests, and then run `mvn

-Pall-adapters

clean

install`
in

arquillian/arquillian-tomee-tests/arquillian-tomee-webprofile-tests,

you'll see the issue.

Jon

On Wed, Dec 19, 2018 at 11:00 AM Roberto Cortez

<[email protected]>

wrote:


Hi Jon,

I can have a look.

It’s been hard to figure issues out, since we were not able

to

stabilize

the TomEE build in build bot.

Apparently, it just keeps getting stuck in CDI TCK and

timeouts.

Cheers,
Roberto


On 19 Dec 2018, at 10:28, Jonathan Gallimore <

[email protected]> wrote:

I'm not sure if this is being discussed on other threads,

but it

looks

like

we have an issue with our arquillian tests failing.

I did a git bisect late last night, and it looks like it

was

introduced

with the addition of microprofile to the plume and plus

distributions.

I'm

still going through my build output, but it looks like we

have a

couple

of

issues.

Firstly, it looks like something in microprofile adds

JAX-RS to

the

app,

and that seems to get priority over everything, so, for

example,

if I

deploy a servlet with a URL mapping of "/" I can't get to

it -

I'll

always

get a 404.

There seems to be another issue that prevents apps from

deploying

too.

I'll continue analysis and post further details, but also

don't

want

to

tread on toes, so if you're already looking at this,

please

shout!

Cheers

Jon






































					Reply via email to