[jira] [Commented] (TOMEE-2270) Java11: Unable to initialize agent with embedded-maven-plugin
[ https://issues.apache.org/jira/browse/TOMEE-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394030#comment-17394030 ] Romain Manni-Bucau commented on TOMEE-2270: --- Hi Thiago, no it was not fixed by itself but the best practise stays to enhance your entities at build time - whatever JPA provider you use - and to set tomee.embedded.javaagent.auto.skip=true system property. > Java11: Unable to initialize agent with embedded-maven-plugin > - > > Key: TOMEE-2270 > URL: https://issues.apache.org/jira/browse/TOMEE-2270 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server, TomEE Maven Plugin >Affects Versions: 7.0.5, 8.0.0-M1 >Reporter: Thomas Andraschko >Priority: Major > Fix For: 8.0.8 > > Attachments: test.zip > > > ava.lang.IllegalStateException: Unable to initialize agent > at > org.apache.openejb.javaagent.Agent.checkInitialization(Agent.java:104) > at > org.apache.openejb.javaagent.Agent.getInstrumentation(Agent.java:94) > at org.apache.tomee.embedded.Container.(Container.java:128) > at > org.apache.openejb.maven.plugins.TomEEEmbeddedMojo.execute(TomEEEmbeddedMojo.java:392) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TOMEE-3745) Unexpected com.fasterxml.jackson.core:jackson-databind in openejb-core
[ https://issues.apache.org/jira/browse/TOMEE-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347645#comment-17347645 ] Romain Manni-Bucau commented on TOMEE-3745: --- [~rzo1] didn't do a full review but openejb-core shouldnt have jackson, jaxb as transitive IMO and probably amq too but it requires a finer review since more can be subject to change their scope too. > Unexpected com.fasterxml.jackson.core:jackson-databind in openejb-core > -- > > Key: TOMEE-3745 > URL: https://issues.apache.org/jira/browse/TOMEE-3745 > Project: TomEE > Issue Type: Bug >Affects Versions: 8.0.7 >Reporter: Romain Manni-Bucau >Priority: Major > > Hi, seems master leaks jackson (and a few other dependencies) from > openejb-core. > This task is about ensuring only needed dependencies are transitive and that > it is intentional to let them be imported by consumer projects. > Also it seems that jackson was imported due to OpenAPI (so tomee-mp distro > only) and ActiveMQ but both are actually optional in several usages so a > light distro should be envisionned which would avoid some headaches in terms > of integration, classloading etc for end users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TOMEE-3745) Unexpected com.fasterxml.jackson.core:jackson-databind in openejb-core
Romain Manni-Bucau created TOMEE-3745: - Summary: Unexpected com.fasterxml.jackson.core:jackson-databind in openejb-core Key: TOMEE-3745 URL: https://issues.apache.org/jira/browse/TOMEE-3745 Project: TomEE Issue Type: Improvement Affects Versions: 8.0.7 Reporter: Romain Manni-Bucau Hi, seems master leaks jackson (and a few other dependencies) from openejb-core. This task is about ensuring only needed dependencies are transitive and that it is intentional to let them be imported by consumer projects. Also it seems that jackson was imported due to OpenAPI (so tomee-mp distro only) and ActiveMQ but both are actually optional in several usages so a light distro should be envisionned which would avoid some headaches in terms of integration, classloading etc for end users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TOMEE-3745) Unexpected com.fasterxml.jackson.core:jackson-databind in openejb-core
[ https://issues.apache.org/jira/browse/TOMEE-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated TOMEE-3745: -- Issue Type: Bug (was: Improvement) > Unexpected com.fasterxml.jackson.core:jackson-databind in openejb-core > -- > > Key: TOMEE-3745 > URL: https://issues.apache.org/jira/browse/TOMEE-3745 > Project: TomEE > Issue Type: Bug >Affects Versions: 8.0.7 >Reporter: Romain Manni-Bucau >Priority: Major > > Hi, seems master leaks jackson (and a few other dependencies) from > openejb-core. > This task is about ensuring only needed dependencies are transitive and that > it is intentional to let them be imported by consumer projects. > Also it seems that jackson was imported due to OpenAPI (so tomee-mp distro > only) and ActiveMQ but both are actually optional in several usages so a > light distro should be envisionned which would avoid some headaches in terms > of integration, classloading etc for end users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TOMEE-3742) Drop patched dependencies
Romain Manni-Bucau created TOMEE-3742: - Summary: Drop patched dependencies Key: TOMEE-3742 URL: https://issues.apache.org/jira/browse/TOMEE-3742 Project: TomEE Issue Type: Bug Reporter: Romain Manni-Bucau Fix For: 8.0.7 Last tomee releases use a lot of patch dependencies. Most of them - not to say all ;) - are not needed but this way of doing broke a lot of applications. Just to give a few examples: # it breaks distro scanning (jar are unknown and CVE are missed which is super important for anyone have some security policy in companies) since jars are "corrupted" (from a scanning point of view) # it broke some features (default json providers can't be disabled as before breaking applications) # it makes it random to update backward compatible dependencies # it makes embedded mode quite random and behaving unexpectedly when not using the fork This ticket is about dropping all forks ensuring 1 and 4 are trivially solved by doing (back) nothing and if possible try to fix 2 (the json setup is just about reverting or integrating more with bus providers in cxf for ex). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TOMEE-2905) Examples shouldn't keep org.eclipse.transformer.maven in poms
Romain Manni-Bucau created TOMEE-2905: - Summary: Examples shouldn't keep org.eclipse.transformer.maven in poms Key: TOMEE-2905 URL: https://issues.apache.org/jira/browse/TOMEE-2905 Project: TomEE Issue Type: Bug Affects Versions: 8.0.4 Reporter: Romain Manni-Bucau It is very ackward to have org.eclipse.transformer.maven in the pom, IMHO it should be a parent plugin which does its job by duplicating modules (and fake duplicating sources in temporary folders/target) and potentially deploy the modue with the jakartaee9 classifier and a valid pom. In current state the main (javax) artifact is polluted by this plugin when tested (which is quite bad for atomic example as it was targetted originally) and the jakarta example is not usable to browse the code so IMHO it does not serve the main purposes of the examples. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENEJB-2147) open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
[
https://issues.apache.org/jira/browse/OPENEJB-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193382#comment-17193382
]
Romain Manni-Bucau commented on OPENEJB-2147:
-
[~sameerti_nok] hmm, your app does not look like an EE app with this part - you
would use openejb-cxf-rs instead of jersey. I think this ticket is solved in
the sense the cause is found and solution found. Seems you need more assistance
in the way you built your project but Jira is not the best place for it as
mentionned multiple times. Please use the tomee user list to help you in your
custom setup, will be easier and will not pollute this ticket more.
> open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
> -
>
> Key: OPENEJB-2147
> URL: https://issues.apache.org/jira/browse/OPENEJB-2147
> Project: OpenEJB
> Issue Type: Bug
> Components: container system
>Reporter: Sameer Tiwari
>Priority: Blocker
> Attachments: maven-module-versions.txt, tomee.log
>
>
> We have following versions in our poms
> 5.0-3
> 3.1.4
> Our build time unit tests work with above versions with java 8 as long as
> there's +*NO Java 8 lambda expressions in code*+
> As soon as we add any lambda expression we get errors like following:
> {code:java}
> --
> T E S T S---Running
> com.a.b.c.d.e.f.ZTResourceTest Apache OpenEJB 3.1.4 build:
> 20101112-03:32http://openejb.apache.org/ERROR - FATAL ERROR: Unknown error in
> Assembler. Please send the following stack trace and this message to
> us...@openejb.apache.org : java.lang.ArrayIndexOutOfBoundsException: 25460 at
> org.apache.xbean.asm.ClassReader.readClass(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.openejb.util.AnnotationFinder.readClassDef(AnnotationFinder.java:253)
> at org.apache.openejb.util.AnnotationFinder.find(AnnotationFinder.java:157)
> at
> org.apache.openejb.config.DeploymentLoader.discoverModuleType(DeploymentLoader.java:1210)
> at
> org.apache.openejb.config.DeploymentsResolver.processUrls(DeploymentsResolver.java:365)
> at
> org.apache.openejb.config.DeploymentsResolver.loadFromClasspath(DeploymentsResolver.java:217)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:379)
> at
> org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:300)
> at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:125) at
> org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:60) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:271) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:250) 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.loader.OpenEJBInstance.init(OpenEJBInstance.java:36) at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
> at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
> at
> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at
> javax.naming.InitialContext.init(InitialContext.java:244) at
> javax.naming.InitialContext.(InitialContext.java:216) at
> motive.test.BaseServiceTest.initialize(BaseServiceTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
>
[jira] [Commented] (OPENEJB-2147) open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
[
https://issues.apache.org/jira/browse/OPENEJB-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192762#comment-17192762
]
Romain Manni-Bucau commented on OPENEJB-2147:
-
[~sameerti_nok] latest is 8 (groupid changed to org.apache.tomee)
> open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
> -
>
> Key: OPENEJB-2147
> URL: https://issues.apache.org/jira/browse/OPENEJB-2147
> Project: OpenEJB
> Issue Type: Bug
> Components: container system
>Reporter: Sameer Tiwari
>Priority: Blocker
> Attachments: maven-module-versions.txt
>
>
> We have following versions in our poms
> 5.0-3
> 3.1.4
> Our build time unit tests work with above versions with java 8 as long as
> there's +*NO Java 8 lambda expressions in code*+
> As soon as we add any lambda expression we get errors like following:
> {code:java}
> --
> T E S T S---Running
> com.a.b.c.d.e.f.ZTResourceTest Apache OpenEJB 3.1.4 build:
> 20101112-03:32http://openejb.apache.org/ERROR - FATAL ERROR: Unknown error in
> Assembler. Please send the following stack trace and this message to
> us...@openejb.apache.org : java.lang.ArrayIndexOutOfBoundsException: 25460 at
> org.apache.xbean.asm.ClassReader.readClass(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.openejb.util.AnnotationFinder.readClassDef(AnnotationFinder.java:253)
> at org.apache.openejb.util.AnnotationFinder.find(AnnotationFinder.java:157)
> at
> org.apache.openejb.config.DeploymentLoader.discoverModuleType(DeploymentLoader.java:1210)
> at
> org.apache.openejb.config.DeploymentsResolver.processUrls(DeploymentsResolver.java:365)
> at
> org.apache.openejb.config.DeploymentsResolver.loadFromClasspath(DeploymentsResolver.java:217)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:379)
> at
> org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:300)
> at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:125) at
> org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:60) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:271) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:250) 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.loader.OpenEJBInstance.init(OpenEJBInstance.java:36) at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
> at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
> at
> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at
> javax.naming.InitialContext.init(InitialContext.java:244) at
> javax.naming.InitialContext.(InitialContext.java:216) at
> motive.test.BaseServiceTest.initialize(BaseServiceTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:413) at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
>
[jira] [Commented] (OPENEJB-2147) open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
[
https://issues.apache.org/jira/browse/OPENEJB-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192702#comment-17192702
]
Romain Manni-Bucau commented on OPENEJB-2147:
-
[~sameerti_nok] i would really go on the list since Jira is not that adapted
for such support but the NPE on a loadClass looks like a change in the JVM
(happens on recent JVM IIRC) so you should probably upgrade openejb to a more
recent version again (why i mentionned to directly use the v7 or 8 earlier).
> open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
> -
>
> Key: OPENEJB-2147
> URL: https://issues.apache.org/jira/browse/OPENEJB-2147
> Project: OpenEJB
> Issue Type: Bug
> Components: container system
>Reporter: Sameer Tiwari
>Priority: Blocker
> Attachments: maven-module-versions.txt
>
>
> We have following versions in our poms
> 5.0-3
> 3.1.4
> Our build time unit tests work with above versions with java 8 as long as
> there's +*NO Java 8 lambda expressions in code*+
> As soon as we add any lambda expression we get errors like following:
> {code:java}
> --
> T E S T S---Running
> com.a.b.c.d.e.f.ZTResourceTest Apache OpenEJB 3.1.4 build:
> 20101112-03:32http://openejb.apache.org/ERROR - FATAL ERROR: Unknown error in
> Assembler. Please send the following stack trace and this message to
> us...@openejb.apache.org : java.lang.ArrayIndexOutOfBoundsException: 25460 at
> org.apache.xbean.asm.ClassReader.readClass(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.openejb.util.AnnotationFinder.readClassDef(AnnotationFinder.java:253)
> at org.apache.openejb.util.AnnotationFinder.find(AnnotationFinder.java:157)
> at
> org.apache.openejb.config.DeploymentLoader.discoverModuleType(DeploymentLoader.java:1210)
> at
> org.apache.openejb.config.DeploymentsResolver.processUrls(DeploymentsResolver.java:365)
> at
> org.apache.openejb.config.DeploymentsResolver.loadFromClasspath(DeploymentsResolver.java:217)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:379)
> at
> org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:300)
> at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:125) at
> org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:60) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:271) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:250) 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.loader.OpenEJBInstance.init(OpenEJBInstance.java:36) at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
> at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
> at
> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at
> javax.naming.InitialContext.init(InitialContext.java:244) at
> javax.naming.InitialContext.(InitialContext.java:216) at
> motive.test.BaseServiceTest.initialize(BaseServiceTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:413) at
[jira] [Commented] (OPENEJB-2147) open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
[
https://issues.apache.org/jira/browse/OPENEJB-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191689#comment-17191689
]
Romain Manni-Bucau commented on OPENEJB-2147:
-
looks like a commons-lang3 dependency issue, if you forced the version in your
project maybe upgrade it?
> open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
> -
>
> Key: OPENEJB-2147
> URL: https://issues.apache.org/jira/browse/OPENEJB-2147
> Project: OpenEJB
> Issue Type: Bug
> Components: container system
>Reporter: Sameer Tiwari
>Priority: Blocker
> Attachments: maven-module-versions.txt
>
>
> We have following versions in our poms
> 5.0-3
> 3.1.4
> Our build time unit tests work with above versions with java 8 as long as
> there's +*NO Java 8 lambda expressions in code*+
> As soon as we add any lambda expression we get errors like following:
> {code:java}
> --
> T E S T S---Running
> com.a.b.c.d.e.f.ZTResourceTest Apache OpenEJB 3.1.4 build:
> 20101112-03:32http://openejb.apache.org/ERROR - FATAL ERROR: Unknown error in
> Assembler. Please send the following stack trace and this message to
> us...@openejb.apache.org : java.lang.ArrayIndexOutOfBoundsException: 25460 at
> org.apache.xbean.asm.ClassReader.readClass(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.openejb.util.AnnotationFinder.readClassDef(AnnotationFinder.java:253)
> at org.apache.openejb.util.AnnotationFinder.find(AnnotationFinder.java:157)
> at
> org.apache.openejb.config.DeploymentLoader.discoverModuleType(DeploymentLoader.java:1210)
> at
> org.apache.openejb.config.DeploymentsResolver.processUrls(DeploymentsResolver.java:365)
> at
> org.apache.openejb.config.DeploymentsResolver.loadFromClasspath(DeploymentsResolver.java:217)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:379)
> at
> org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:300)
> at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:125) at
> org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:60) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:271) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:250) 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.loader.OpenEJBInstance.init(OpenEJBInstance.java:36) at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
> at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
> at
> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at
> javax.naming.InitialContext.init(InitialContext.java:244) at
> javax.naming.InitialContext.(InitialContext.java:216) at
> motive.test.BaseServiceTest.initialize(BaseServiceTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:413) at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
>
[jira] [Commented] (OPENEJB-2147) open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
[
https://issues.apache.org/jira/browse/OPENEJB-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191655#comment-17191655
]
Romain Manni-Bucau commented on OPENEJB-2147:
-
Yes, readEntity is a JAXRS 2 method so javaee-api 7 or more (upgrade to openejb
7). TomEE/OpenEJB does not use *javax.** jars. Also the exclusions you did are
required for openejb (why i suggested to upgrade openejb to avoid issues) so
you can't just exclude them without adding them back (if you want another
version). A package change (and artifact renaming: xbean-asm7-shaded for
example) happent to avoid issues in xbean dependency. So overall upgrade
openejb-core and keep transitive dependencies is the safest path IMO.
> open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
> -
>
> Key: OPENEJB-2147
> URL: https://issues.apache.org/jira/browse/OPENEJB-2147
> Project: OpenEJB
> Issue Type: Bug
> Components: container system
>Reporter: Sameer Tiwari
>Priority: Blocker
> Attachments: maven-module-versions.txt
>
>
> We have following versions in our poms
> 5.0-3
> 3.1.4
> Our build time unit tests work with above versions with java 8 as long as
> there's +*NO Java 8 lambda expressions in code*+
> As soon as we add any lambda expression we get errors like following:
> {code:java}
> --
> T E S T S---Running
> com.a.b.c.d.e.f.ZTResourceTest Apache OpenEJB 3.1.4 build:
> 20101112-03:32http://openejb.apache.org/ERROR - FATAL ERROR: Unknown error in
> Assembler. Please send the following stack trace and this message to
> us...@openejb.apache.org : java.lang.ArrayIndexOutOfBoundsException: 25460 at
> org.apache.xbean.asm.ClassReader.readClass(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.openejb.util.AnnotationFinder.readClassDef(AnnotationFinder.java:253)
> at org.apache.openejb.util.AnnotationFinder.find(AnnotationFinder.java:157)
> at
> org.apache.openejb.config.DeploymentLoader.discoverModuleType(DeploymentLoader.java:1210)
> at
> org.apache.openejb.config.DeploymentsResolver.processUrls(DeploymentsResolver.java:365)
> at
> org.apache.openejb.config.DeploymentsResolver.loadFromClasspath(DeploymentsResolver.java:217)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:379)
> at
> org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:300)
> at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:125) at
> org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:60) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:271) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:250) 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.loader.OpenEJBInstance.init(OpenEJBInstance.java:36) at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
> at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
> at
> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at
> javax.naming.InitialContext.init(InitialContext.java:244) at
> javax.naming.InitialContext.(InitialContext.java:216) at
> motive.test.BaseServiceTest.initialize(BaseServiceTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
[jira] [Commented] (OPENEJB-2147) open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
[
https://issues.apache.org/jira/browse/OPENEJB-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191555#comment-17191555
]
Romain Manni-Bucau commented on OPENEJB-2147:
-
[~sameerti_nok] you will go from javaee5 to javaee 6 or 7 but it is backward
compatible so should be smooth if your application is portable. Other
combinations are not (can't be today) tested nor guaranteed.
> open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
> -
>
> Key: OPENEJB-2147
> URL: https://issues.apache.org/jira/browse/OPENEJB-2147
> Project: OpenEJB
> Issue Type: Bug
> Components: container system
>Reporter: Sameer Tiwari
>Priority: Blocker
> Attachments: maven-module-versions.txt
>
>
> We have following versions in our poms
> 5.0-3
> 3.1.4
> Our build time unit tests work with above versions with java 8 as long as
> there's +*NO Java 8 lambda expressions in code*+
> As soon as we add any lambda expression we get errors like following:
> {code:java}
> --
> T E S T S---Running
> com.a.b.c.d.e.f.ZTResourceTest Apache OpenEJB 3.1.4 build:
> 20101112-03:32http://openejb.apache.org/ERROR - FATAL ERROR: Unknown error in
> Assembler. Please send the following stack trace and this message to
> us...@openejb.apache.org : java.lang.ArrayIndexOutOfBoundsException: 25460 at
> org.apache.xbean.asm.ClassReader.readClass(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.openejb.util.AnnotationFinder.readClassDef(AnnotationFinder.java:253)
> at org.apache.openejb.util.AnnotationFinder.find(AnnotationFinder.java:157)
> at
> org.apache.openejb.config.DeploymentLoader.discoverModuleType(DeploymentLoader.java:1210)
> at
> org.apache.openejb.config.DeploymentsResolver.processUrls(DeploymentsResolver.java:365)
> at
> org.apache.openejb.config.DeploymentsResolver.loadFromClasspath(DeploymentsResolver.java:217)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:379)
> at
> org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:300)
> at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:125) at
> org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:60) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:271) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:250) 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.loader.OpenEJBInstance.init(OpenEJBInstance.java:36) at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
> at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
> at
> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at
> javax.naming.InitialContext.init(InitialContext.java:244) at
> javax.naming.InitialContext.(InitialContext.java:216) at
> motive.test.BaseServiceTest.initialize(BaseServiceTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:413) at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
>
[jira] [Commented] (OPENEJB-2147) open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
[
https://issues.apache.org/jira/browse/OPENEJB-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191500#comment-17191500
]
Romain Manni-Bucau commented on OPENEJB-2147:
-
[~sameerti_nok] xbean-asm-shaded but I would recommend upgrading openejb too
since depending your code it can require change there too and it is better to
stick to built-in version (note that late versions don't support a blind
upgrade at all).
> open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
> -
>
> Key: OPENEJB-2147
> URL: https://issues.apache.org/jira/browse/OPENEJB-2147
> Project: OpenEJB
> Issue Type: Bug
> Components: container system
>Reporter: Sameer Tiwari
>Priority: Blocker
> Attachments: maven-module-versions.txt
>
>
> We have following versions in our poms
> 5.0-3
> 3.1.4
> Our build time unit tests work with above versions with java 8 as long as
> there's +*NO Java 8 lambda expressions in code*+
> As soon as we add any lambda expression we get errors like following:
> {code:java}
> --
> T E S T S---Running
> com.a.b.c.d.e.f.ZTResourceTest Apache OpenEJB 3.1.4 build:
> 20101112-03:32http://openejb.apache.org/ERROR - FATAL ERROR: Unknown error in
> Assembler. Please send the following stack trace and this message to
> us...@openejb.apache.org : java.lang.ArrayIndexOutOfBoundsException: 25460 at
> org.apache.xbean.asm.ClassReader.readClass(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.openejb.util.AnnotationFinder.readClassDef(AnnotationFinder.java:253)
> at org.apache.openejb.util.AnnotationFinder.find(AnnotationFinder.java:157)
> at
> org.apache.openejb.config.DeploymentLoader.discoverModuleType(DeploymentLoader.java:1210)
> at
> org.apache.openejb.config.DeploymentsResolver.processUrls(DeploymentsResolver.java:365)
> at
> org.apache.openejb.config.DeploymentsResolver.loadFromClasspath(DeploymentsResolver.java:217)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:379)
> at
> org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:300)
> at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:125) at
> org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:60) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:271) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:250) 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.loader.OpenEJBInstance.init(OpenEJBInstance.java:36) at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
> at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
> at
> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at
> javax.naming.InitialContext.init(InitialContext.java:244) at
> javax.naming.InitialContext.(InitialContext.java:216) at
> motive.test.BaseServiceTest.initialize(BaseServiceTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:413) at
>
[jira] [Commented] (OPENEJB-2147) open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
[
https://issues.apache.org/jira/browse/OPENEJB-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191492#comment-17191492
]
Romain Manni-Bucau commented on OPENEJB-2147:
-
Hi [~sameerti_nok], best is to upgrade to a more recent version with asm >= 5
instead of the old 3.1.4 version using asm3 (java 6).
> open-ejb upgrade from 3.1.4 doesn't support java 8 lambda expressions
> -
>
> Key: OPENEJB-2147
> URL: https://issues.apache.org/jira/browse/OPENEJB-2147
> Project: OpenEJB
> Issue Type: Bug
> Components: container system
>Reporter: Sameer Tiwari
>Priority: Blocker
> Attachments: maven-module-versions.txt
>
>
> We have following versions in our poms
> 5.0-3
> 3.1.4
> Our build time unit tests work with above versions with java 8 as long as
> there's +*NO Java 8 lambda expressions in code*+
> As soon as we add any lambda expression we get errors like following:
> {code:java}
> --
> T E S T S---Running
> com.a.b.c.d.e.f.ZTResourceTest Apache OpenEJB 3.1.4 build:
> 20101112-03:32http://openejb.apache.org/ERROR - FATAL ERROR: Unknown error in
> Assembler. Please send the following stack trace and this message to
> us...@openejb.apache.org : java.lang.ArrayIndexOutOfBoundsException: 25460 at
> org.apache.xbean.asm.ClassReader.readClass(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.xbean.asm.ClassReader.accept(Unknown Source) at
> org.apache.openejb.util.AnnotationFinder.readClassDef(AnnotationFinder.java:253)
> at org.apache.openejb.util.AnnotationFinder.find(AnnotationFinder.java:157)
> at
> org.apache.openejb.config.DeploymentLoader.discoverModuleType(DeploymentLoader.java:1210)
> at
> org.apache.openejb.config.DeploymentsResolver.processUrls(DeploymentsResolver.java:365)
> at
> org.apache.openejb.config.DeploymentsResolver.loadFromClasspath(DeploymentsResolver.java:217)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:379)
> at
> org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:300)
> at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:279)
> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:125) at
> org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:60) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:271) at
> org.apache.openejb.OpenEJB.init(OpenEJB.java:250) 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.loader.OpenEJBInstance.init(OpenEJBInstance.java:36) at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:71)
> at
> org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:53)
> at
> org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:42)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at
> javax.naming.InitialContext.init(InitialContext.java:244) at
> javax.naming.InitialContext.(InitialContext.java:216) at
> motive.test.BaseServiceTest.initialize(BaseServiceTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:413) at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
>
[jira] [Commented] (TOMEE-2200) defineClass used which is not supported by java 11
[
https://issues.apache.org/jira/browse/TOMEE-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854203#comment-16854203
]
Romain Manni-Bucau commented on TOMEE-2200:
---
[~dineshkumarg] yes both for the needed released
> defineClass used which is not supported by java 11
> --
>
> Key: TOMEE-2200
> URL: https://issues.apache.org/jira/browse/TOMEE-2200
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5, 8.0.0-M1
> Environment: ./catalina.sh version
> Using CATALINA_BASE: /opt/tomee705
> Using CATALINA_HOME: /opt/tomee705
> Using CATALINA_TMPDIR: /opt/tomee705/temp
> Using JRE_HOME:/opt/jdk-11
> Using CLASSPATH:
> /opt/tomee705/bin/bootstrap.jar:/opt/tomee705/bin/tomcat-juli.jar
> NOTE: Picked up JDK_JAVA_OPTIONS:
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.io=ALL-UNNAMED
> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
> Server version: Apache Tomcat/8.5.32
> Server built: Jun 20 2018 19:50:35 UTC
> Server number: 8.5.32.0
> OS Name:Linux
> OS Version: 3.10.0-229.el7.x86_64
> Architecture: amd64
> JVM Version:11-ea+21
> JVM Vendor: Oracle Corporation
>Reporter: Donald Kwakkel
>Assignee: Jonathan Gallimore
>Priority: Critical
>
> Not sure if tomee will support java 11, but with latest java 11 version it is
> not possible to start tomee:
> {code:java}
> SEVERE: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/home]]
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:629)
> at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1839)
> at
> Criticaljava.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.openejb.util.proxy.LocalBeanProxyFactory$Unsafe
> at
> org.apache.openejb.util.proxy.LocalBeanProxyFactory.createProxy(LocalBeanProxyFactory.java:137)
> at
> org.apache.openejb.util.proxy.LocalBeanProxyFactory.createProxy(LocalBeanProxyFactory.java:147)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.eagerInitOfLocalBeanProxies(TomcatWebAppBuilder.java:1563)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1309)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1125)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5154)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> ... 10 more
> {code}
> Reason is that defineClass is used which is no longer supported with java 11
> (at least here, maybe also on other places):
> container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java:
> return Unsafe.defineClass(cl, classToProxy, proxyName, proxyBytes);
> Same issue has openwebbeans: https://issues.apache.org/jira/browse/OWB-1248
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TOMEE-2200) defineClass used which is not supported by java 11
[
https://issues.apache.org/jira/browse/TOMEE-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854203#comment-16854203
]
Romain Manni-Bucau edited comment on TOMEE-2200 at 6/3/19 4:43 AM:
---
[~dineshkumarg] yes both for the needed releases
was (Author: romain.manni-bucau):
[~dineshkumarg] yes both for the needed released
> defineClass used which is not supported by java 11
> --
>
> Key: TOMEE-2200
> URL: https://issues.apache.org/jira/browse/TOMEE-2200
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5, 8.0.0-M1
> Environment: ./catalina.sh version
> Using CATALINA_BASE: /opt/tomee705
> Using CATALINA_HOME: /opt/tomee705
> Using CATALINA_TMPDIR: /opt/tomee705/temp
> Using JRE_HOME:/opt/jdk-11
> Using CLASSPATH:
> /opt/tomee705/bin/bootstrap.jar:/opt/tomee705/bin/tomcat-juli.jar
> NOTE: Picked up JDK_JAVA_OPTIONS:
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.io=ALL-UNNAMED
> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
> Server version: Apache Tomcat/8.5.32
> Server built: Jun 20 2018 19:50:35 UTC
> Server number: 8.5.32.0
> OS Name:Linux
> OS Version: 3.10.0-229.el7.x86_64
> Architecture: amd64
> JVM Version:11-ea+21
> JVM Vendor: Oracle Corporation
>Reporter: Donald Kwakkel
>Assignee: Jonathan Gallimore
>Priority: Critical
>
> Not sure if tomee will support java 11, but with latest java 11 version it is
> not possible to start tomee:
> {code:java}
> SEVERE: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/home]]
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:629)
> at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1839)
> at
> Criticaljava.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.openejb.util.proxy.LocalBeanProxyFactory$Unsafe
> at
> org.apache.openejb.util.proxy.LocalBeanProxyFactory.createProxy(LocalBeanProxyFactory.java:137)
> at
> org.apache.openejb.util.proxy.LocalBeanProxyFactory.createProxy(LocalBeanProxyFactory.java:147)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.eagerInitOfLocalBeanProxies(TomcatWebAppBuilder.java:1563)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1309)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1125)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5154)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> ... 10 more
> {code}
> Reason is that defineClass is used which is no longer supported with java 11
> (at least here, maybe also on other places):
> container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java:
> return Unsafe.defineClass(cl, classToProxy, proxyName, proxyBytes);
> Same issue has openwebbeans: https://issues.apache.org/jira/browse/OWB-1248
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (TOMEE-2507) Improve scanning excludes
[ https://issues.apache.org/jira/browse/TOMEE-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved TOMEE-2507. --- Resolution: Fixed PR applied > Improve scanning excludes > - > > Key: TOMEE-2507 > URL: https://issues.apache.org/jira/browse/TOMEE-2507 > Project: TomEE > Issue Type: Improvement > Components: TomEE Core Server >Affects Versions: 8.0.0-M2 >Reporter: Thomas Andraschko >Priority: Minor > Labels: pull-request-available > Fix For: 8.0.0-M3 > > > container/openejb-core/src/main/resources/default.exclusions: > jfreechart- > jscience- > lesscss-engine- > rhino- > tomee/tomee-embedded/src/main/resources/org/apache/tomee/configs/catalina.properties > jfreechart-* > jscience-* > lesscss-engine-* > rhino-* > There are also some excludes which are in default.exclusions but not in > catalina.properties: > commons-io-* > jackson-annotations-* > jackson-core-* > jackson-databind-* > jackson-dataformat* > jackson-mapper-asl-* > jackson-module-jaxb-annotations-* -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TOMEE-2271) Java11: can't resolve old sun JavaEE namespaces correctly
[
https://issues.apache.org/jira/browse/TOMEE-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau closed TOMEE-2271.
-
Resolution: Not A Problem
Was a maven issue so tomee does not need any action
> Java11: can't resolve old sun JavaEE namespaces correctly
> -
>
> Key: TOMEE-2271
> URL: https://issues.apache.org/jira/browse/TOMEE-2271
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server, TomEE Maven Plugin
>Affects Versions: 7.0.5, 8.0.0-M1
>Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 8.0.0-M3
>
>
> Just start an application with tomee-embedded-maven-plugin and the following
> will occur:
> NOTE: this errors will be thrown for XMLs in the tomcat libs and also for
> beans.xml/web-fragements in DS:
> javax.xml.bind.UnmarshalException: unerwartetes Element
> (URI:"[http://java.sun.com/xml/ns/javaee];, lokal:"interceptors"). Erwartete
> Elemente
> sind <{}trim>,<{}decorators>,<{}scan>,<{}alternatives>,<{}interceptors>
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent
> (UnmarshallingContext.java:744)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> (Loader.java:262)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> (Loader.java:257)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement
> (Loader.java:124)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement
> (Loader.java:105)
> at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement
> (StructureLoader.java:268)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
> (UnmarshallingContext.java:574)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement
> (UnmarshallingContext.java:556)
> at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement
> (SAXConnector.java:168)
> at org.xml.sax.helpers.XMLFilterImpl.startElement (XMLFilterImpl.java:551)
> at org.apache.openejb.jee.JaxbJavaee$JavaeeNamespaceFilter.startElement
> (JaxbJavaee.java:293)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
> (AbstractSAXParser.java:510)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
> (XMLNSDocumentScannerImpl.java:374)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
> (XMLDocumentFragmentScannerImpl.java:2708)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> (XMLDocumentScannerImpl.java:605)
> at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
> (XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
> (XMLDocumentFragmentScannerImpl.java:534)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:888)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:824)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
> (XMLParser.java:141)
> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> (AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
> (SAXParserImpl.java:635)
> at org.xml.sax.helpers.XMLFilterImpl.parse (XMLFilterImpl.java:357)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0
> (UnmarshallerImpl.java:258)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> (UnmarshallerImpl.java:236)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> (UnmarshallerImpl.java:288)
> at org.apache.openejb.jee.JaxbJavaee.unmarshalJavaee (JaxbJavaee.java:133)
> at org.apache.openejb.config.ReadDescriptors.readBeans
> (ReadDescriptors.java:691)
> at org.apache.openejb.config.DeploymentLoader.mergeBeansXml
> (DeploymentLoader.java:1196)
> at org.apache.openejb.config.DeploymentLoader.addBeansXmls
> (DeploymentLoader.java:1184)
> at org.apache.openejb.config.DeploymentLoader.createWebModule
> (DeploymentLoader.java:1098)
> at org.apache.openejb.config.DeploymentLoader.createWebModule
> (DeploymentLoader.java:823)
> at org.apache.openejb.config.DeploymentLoader.load
> (DeploymentLoader.java:234)
> at org.apache.tomee.catalina.TomcatWebAppBuilder.loadApplication
> (TomcatWebAppBuilder.java:2347)
> at org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal
> (TomcatWebAppBuilder.java:1197)
> at
[jira] [Commented] (TOMEE-2478) extractWars configuration value does invalid extraction
[ https://issues.apache.org/jira/browse/TOMEE-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16788284#comment-16788284 ] Romain Manni-Bucau commented on TOMEE-2478: --- I suspect this feature was not properly done for both additionnal webapps and current project. Feel free to add a test and do a pr to fix it. > extractWars configuration value does invalid extraction > --- > > Key: TOMEE-2478 > URL: https://issues.apache.org/jira/browse/TOMEE-2478 > Project: TomEE > Issue Type: Bug > Components: TomEE Maven Plugin >Affects Versions: 7.1.0, 8.0.0-M2 >Reporter: James Smith >Priority: Major > Attachments: tomee-fat-jar.zip, tomee-fat-jar.zip > > > I run my TomEE as a fat JAR, and I like to keep the distribution as lean as I > can achieve. I recently noticed while taking advantage of the *extractWars* > configuration value, which instead of leaving *ROOT.war* and *ROOT/* for > instance, it removes the archive and leaving only the directory. > > Unfortunately, the exploded WAR that results from this variable is > *ROOT.war/*, I only noticed this when I was testing Microprofile config > injection in one of my JAX-RS resources. I have attached a very lean example. > Please run it and modify *extractWars* to notice how the config value is not > being injected when the directory is *ROOT.war/*. > > A fix to the issue will most likely be found > [here|https://github.com/apache/tomee/blob/master/maven/tomee-maven-plugin/src/main/java/org/apache/openejb/maven/plugin/AbstractTomEEMojo.java]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2488) Broken documentatoin
Romain Manni-Bucau created TOMEE-2488: - Summary: Broken documentatoin Key: TOMEE-2488 URL: https://issues.apache.org/jira/browse/TOMEE-2488 Project: TomEE Issue Type: Bug Reporter: Romain Manni-Bucau http://tomee.apache.org/docs.html does not lead to the documentation menu of the website leading to the old (openejb) website with inaccurate doc and no real way to find the information. Can be nice to activate back the new navigation to get back a correct user experience. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2489) Documentation website css is broken
Romain Manni-Bucau created TOMEE-2489: - Summary: Documentation website css is broken Key: TOMEE-2489 URL: https://issues.apache.org/jira/browse/TOMEE-2489 Project: TomEE Issue Type: Bug Reporter: Romain Manni-Bucau header is broken on this page for instance: http://tomee.apache.org/developer/testing/other/index.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2458) Loading Beans causes ClassNotFoundException when using custom context classloader
[
https://issues.apache.org/jira/browse/TOMEE-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16751105#comment-16751105
]
Romain Manni-Bucau commented on TOMEE-2458:
---
[~dkwakkel] this extension
https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/classloader/ClassLoaderConfigurer.java
> Loading Beans causes ClassNotFoundException when using custom context
> classloader
> -
>
> Key: TOMEE-2458
> URL: https://issues.apache.org/jira/browse/TOMEE-2458
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 8.0.0-M1
>Reporter: Gerwin
>Priority: Major
> Attachments: myclassloader.jar, myclassloader.jar.withtccl,
> myexception.jar, myexception.jar.withbean, repro.war
>
>
> h4. Steps to reproduce
> # Create a custom Exception and put it in {{CATALINA_HOME/myexception.jar}}
> {code:java}
> public class MyException extends Exception {
> }
> {code}
> # Create a custom ClassLoader and put it in
> {{CATALINA_HOME/myclassloader.jar}}
> {code:java}
> public class MyClassLoader extends WebappClassLoader {
> public MyClassLoader(ClassLoader parent)throws MalformedURLException {
> super(parent);
> addURL(Paths.get(System.getProperty("catalina.home"),
> "myexception.jar").toUri().toURL());
> }
> }
> {code}
> # Put the classloader on the classpath
> {code:none|title=CATALINA_HOME/conf/catalina.properties}
> common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.home}/myclassloader.jar"
> {code}
> # Use the classloader in the context
> {code:xml|title=CATALINA_HOME/webapps/repro/META-INF/context.xml}
>
>
>
> {code}
> # Create a bean with the {{MyException}} in the method signature
> {code:java|title=CATALINA_HOME/webapps/repro/WEB-INF/classes/MyBean.class}
> @Stateless(name = "MyBeanEJB")
> public class MyBean {
> public String hello() throws MyException {
> return "hello";
> }
> }
> {code}
> # Use the bean
> {code:java|title=CATALINA_HOME/webapps/repro/index.jsp}
> <%@ page import="MyBean" %>
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
>
>
> <%
> MyBean myBean = new MyBean();
> out.println(myBean.hello());
> %>
>
>
> {code}
> h4. Actual result
> {code:none|title=CATALINA_HOME/logs/catalina.0.log}
> jan 23, 2019 4:37:17 PM sun.reflect.DelegatingMethodAccessorImpl invoke
> INFO: Starting Servlet Engine: Apache Tomcat (TomEE)/9.0.12 (8.0.0-SNAPSHOT)
> jan 23, 2019 4:37:17 PM sun.reflect.DelegatingMethodAccessorImpl invoke
> INFO: Deploying web application archive [C:\Program
> Files\TomEE\webapps\repro.war]
> jan 23, 2019 4:37:17 PM org.apache.tomee.catalina.TomcatWebAppBuilder init
> INFO: - localhost -> /repro
> jan 23, 2019 4:37:17 PM org.apache.openejb.config.ConfigurationFactory
> configureApplication
> INFO: Configuring enterprise application: C:\Program Files\TomEE\webapps\repro
> jan 23, 2019 4:37:17 PM sun.reflect.NativeMethodAccessorImpl invoke
> SEVERE: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/repro]]
> at
> org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:441)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
> 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.deployWAR(HostConfig.java:986)
> at
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1858)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
> at
> org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:772)
> at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:426)
> 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
>
[jira] [Commented] (TOMEE-2458) Loading Beans causes ClassNotFoundException when using custom context classloader
[
https://issues.apache.org/jira/browse/TOMEE-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16750877#comment-16750877
]
Romain Manni-Bucau commented on TOMEE-2458:
---
[~dkwakkel] nop, this does not look the same issue like that. ParentClassLoader
must be openejb classloader and never the TCCL of an app (it must not be able
to load any app class to be concrete but only server libs except when all are
in the same flat classloader). Here the issue is that the scanned loader does
not match your custom loader strategy since we just respect webapp strategies.
Using WEB-INF/jars.txt or openejb classloader customizer would work since the
scanning and runtime will them use the same list of jars.
> Loading Beans causes ClassNotFoundException when using custom context
> classloader
> -
>
> Key: TOMEE-2458
> URL: https://issues.apache.org/jira/browse/TOMEE-2458
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 8.0.0-M1
>Reporter: Gerwin
>Priority: Major
> Attachments: myclassloader.jar, myclassloader.jar.withtccl,
> myexception.jar, myexception.jar.withbean, repro.war
>
>
> h4. Steps to reproduce
> # Create a custom Exception and put it in {{CATALINA_HOME/myexception.jar}}
> {code:java}
> public class MyException extends Exception {
> }
> {code}
> # Create a custom ClassLoader and put it in
> {{CATALINA_HOME/myclassloader.jar}}
> {code:java}
> public class MyClassLoader extends WebappClassLoader {
> public MyClassLoader(ClassLoader parent)throws MalformedURLException {
> super(parent);
> addURL(Paths.get(System.getProperty("catalina.home"),
> "myexception.jar").toUri().toURL());
> }
> }
> {code}
> # Put the classloader on the classpath
> {code:none|title=CATALINA_HOME/conf/catalina.properties}
> common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.home}/myclassloader.jar"
> {code}
> # Use the classloader in the context
> {code:xml|title=CATALINA_HOME/webapps/repro/META-INF/context.xml}
>
>
>
> {code}
> # Create a bean with the {{MyException}} in the method signature
> {code:java|title=CATALINA_HOME/webapps/repro/WEB-INF/classes/MyBean.class}
> @Stateless(name = "MyBeanEJB")
> public class MyBean {
> public String hello() throws MyException {
> return "hello";
> }
> }
> {code}
> # Use the bean
> {code:java|title=CATALINA_HOME/webapps/repro/index.jsp}
> <%@ page import="MyBean" %>
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
>
>
> <%
> MyBean myBean = new MyBean();
> out.println(myBean.hello());
> %>
>
>
> {code}
> h4. Actual result
> {code:none|title=CATALINA_HOME/logs/catalina.0.log}
> jan 23, 2019 4:37:17 PM sun.reflect.DelegatingMethodAccessorImpl invoke
> INFO: Starting Servlet Engine: Apache Tomcat (TomEE)/9.0.12 (8.0.0-SNAPSHOT)
> jan 23, 2019 4:37:17 PM sun.reflect.DelegatingMethodAccessorImpl invoke
> INFO: Deploying web application archive [C:\Program
> Files\TomEE\webapps\repro.war]
> jan 23, 2019 4:37:17 PM org.apache.tomee.catalina.TomcatWebAppBuilder init
> INFO: - localhost -> /repro
> jan 23, 2019 4:37:17 PM org.apache.openejb.config.ConfigurationFactory
> configureApplication
> INFO: Configuring enterprise application: C:\Program Files\TomEE\webapps\repro
> jan 23, 2019 4:37:17 PM sun.reflect.NativeMethodAccessorImpl invoke
> SEVERE: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/repro]]
> at
> org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:441)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
> 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.deployWAR(HostConfig.java:986)
> at
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1858)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
> at
> org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:772)
> at
>
[jira] [Commented] (TOMEE-2252) Update Apache Johnzon to v1.1.11
[ https://issues.apache.org/jira/browse/TOMEE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726606#comment-16726606 ] Romain Manni-Bucau commented on TOMEE-2252: --- I just closed the vote (keep in mind apache releases have a 3 days vote delay at least) > Update Apache Johnzon to v1.1.11 > > > Key: TOMEE-2252 > URL: https://issues.apache.org/jira/browse/TOMEE-2252 > Project: TomEE > Issue Type: Dependency upgrade > Components: TomEE Core Server >Affects Versions: 8.0.0-M1 >Reporter: Otavio Goncalves de Santana >Priority: Major > Fix For: 8.0.0-M2 > > > Based on the Johnzon issue: https://issues.apache.org/jira/browse/JOHNZON-190 > The Apache TomEE needs to update this library to version 8.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TOMEE-2366) JAXRS Feature not supported until it is annotated with @Provider
[ https://issues.apache.org/jira/browse/TOMEE-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved TOMEE-2366. --- Resolution: Fixed > JAXRS Feature not supported until it is annotated with @Provider > > > Key: TOMEE-2366 > URL: https://issues.apache.org/jira/browse/TOMEE-2366 > Project: TomEE > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Minor > Fix For: 8.0.0-M2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2366) JAXRS Feature not supported until it is annotated with @Provider
Romain Manni-Bucau created TOMEE-2366: - Summary: JAXRS Feature not supported until it is annotated with @Provider Key: TOMEE-2366 URL: https://issues.apache.org/jira/browse/TOMEE-2366 Project: TomEE Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 8.0.0-M2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2271) Java11: can't resolve old sun JavaEE namespaces correctly
[
https://issues.apache.org/jira/browse/TOMEE-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709220#comment-16709220
]
Romain Manni-Bucau commented on TOMEE-2271:
---
Pr still open https://github.com/codehaus-plexus/plexus-classworlds/pull/4 and
not untegrated at maven
> Java11: can't resolve old sun JavaEE namespaces correctly
> -
>
> Key: TOMEE-2271
> URL: https://issues.apache.org/jira/browse/TOMEE-2271
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server, TomEE Maven Plugin
>Affects Versions: 8.0.0-M1, 7.0.5
>Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 8.0.0-Final
>
>
> Just start an application with tomee-embedded-maven-plugin and the following
> will occur:
> NOTE: this errors will be thrown for XMLs in the tomcat libs and also for
> beans.xml/web-fragements in DS:
> javax.xml.bind.UnmarshalException: unerwartetes Element
> (URI:"[http://java.sun.com/xml/ns/javaee];, lokal:"interceptors"). Erwartete
> Elemente
> sind <{}trim>,<{}decorators>,<{}scan>,<{}alternatives>,<{}interceptors>
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent
> (UnmarshallingContext.java:744)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> (Loader.java:262)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> (Loader.java:257)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement
> (Loader.java:124)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement
> (Loader.java:105)
> at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement
> (StructureLoader.java:268)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
> (UnmarshallingContext.java:574)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement
> (UnmarshallingContext.java:556)
> at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement
> (SAXConnector.java:168)
> at org.xml.sax.helpers.XMLFilterImpl.startElement (XMLFilterImpl.java:551)
> at org.apache.openejb.jee.JaxbJavaee$JavaeeNamespaceFilter.startElement
> (JaxbJavaee.java:293)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
> (AbstractSAXParser.java:510)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
> (XMLNSDocumentScannerImpl.java:374)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
> (XMLDocumentFragmentScannerImpl.java:2708)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> (XMLDocumentScannerImpl.java:605)
> at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
> (XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
> (XMLDocumentFragmentScannerImpl.java:534)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:888)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:824)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
> (XMLParser.java:141)
> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> (AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
> (SAXParserImpl.java:635)
> at org.xml.sax.helpers.XMLFilterImpl.parse (XMLFilterImpl.java:357)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0
> (UnmarshallerImpl.java:258)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> (UnmarshallerImpl.java:236)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> (UnmarshallerImpl.java:288)
> at org.apache.openejb.jee.JaxbJavaee.unmarshalJavaee (JaxbJavaee.java:133)
> at org.apache.openejb.config.ReadDescriptors.readBeans
> (ReadDescriptors.java:691)
> at org.apache.openejb.config.DeploymentLoader.mergeBeansXml
> (DeploymentLoader.java:1196)
> at org.apache.openejb.config.DeploymentLoader.addBeansXmls
> (DeploymentLoader.java:1184)
> at org.apache.openejb.config.DeploymentLoader.createWebModule
> (DeploymentLoader.java:1098)
> at org.apache.openejb.config.DeploymentLoader.createWebModule
> (DeploymentLoader.java:823)
> at org.apache.openejb.config.DeploymentLoader.load
> (DeploymentLoader.java:234)
> at org.apache.tomee.catalina.TomcatWebAppBuilder.loadApplication
> (TomcatWebAppBuilder.java:2347)
> at org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal
> (TomcatWebAppBuilder.java:1197)
>
[jira] [Closed] (TOMEE-2186) Upgrade to CXF 3.2.4
[ https://issues.apache.org/jira/browse/TOMEE-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau closed TOMEE-2186. - Resolution: Duplicate > Upgrade to CXF 3.2.4 > > > Key: TOMEE-2186 > URL: https://issues.apache.org/jira/browse/TOMEE-2186 > Project: TomEE > Issue Type: Dependency upgrade >Affects Versions: 8.0.0-M1 >Reporter: Jonathan Gallimore >Assignee: Jonathan Gallimore >Priority: Major > Fix For: 8.0.0-Final > > > Upgrade TomEE 8 to CXF to 3.2.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2270) Java11: Unable to initialize agent with embedded-maven-plugin
[ https://issues.apache.org/jira/browse/TOMEE-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686812#comment-16686812 ] Romain Manni-Bucau commented on TOMEE-2270: --- It enables jpa instrumentation only and eager loading before we load classes...only required for openjpa AFAIK and not fully reliable when not set on the JVM > Java11: Unable to initialize agent with embedded-maven-plugin > - > > Key: TOMEE-2270 > URL: https://issues.apache.org/jira/browse/TOMEE-2270 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server, TomEE Maven Plugin >Affects Versions: 8.0.0-M1, 7.0.5 >Reporter: Thomas Andraschko >Priority: Major > Fix For: 8.0.0-Final > > Attachments: test.zip > > > ava.lang.IllegalStateException: Unable to initialize agent > at > org.apache.openejb.javaagent.Agent.checkInitialization(Agent.java:104) > at > org.apache.openejb.javaagent.Agent.getInstrumentation(Agent.java:94) > at org.apache.tomee.embedded.Container.(Container.java:128) > at > org.apache.openejb.maven.plugins.TomEEEmbeddedMojo.execute(TomEEEmbeddedMojo.java:392) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (TOMEE-2271) Java11: can't resolve old sun JavaEE namespaces correctly
[
https://issues.apache.org/jira/browse/TOMEE-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686753#comment-16686753
]
Romain Manni-Bucau edited comment on TOMEE-2271 at 11/14/18 3:49 PM:
-
Sent a thread on dev@:
http://maven.40175.n5.nabble.com/maven-and-java11-td5949951.html
was (Author: romain.manni-bucau):
Send a thread on dev@:
http://maven.40175.n5.nabble.com/maven-and-java11-td5949951.html
> Java11: can't resolve old sun JavaEE namespaces correctly
> -
>
> Key: TOMEE-2271
> URL: https://issues.apache.org/jira/browse/TOMEE-2271
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server, TomEE Maven Plugin
>Affects Versions: 8.0.0-M1, 7.0.5
>Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 8.0.0-Final
>
>
> Just start an application with tomee-embedded-maven-plugin and the following
> will occur:
> NOTE: this errors will be thrown for XMLs in the tomcat libs and also for
> beans.xml/web-fragements in DS:
> javax.xml.bind.UnmarshalException: unerwartetes Element
> (URI:"[http://java.sun.com/xml/ns/javaee];, lokal:"interceptors"). Erwartete
> Elemente
> sind <{}trim>,<{}decorators>,<{}scan>,<{}alternatives>,<{}interceptors>
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent
> (UnmarshallingContext.java:744)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> (Loader.java:262)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> (Loader.java:257)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement
> (Loader.java:124)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement
> (Loader.java:105)
> at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement
> (StructureLoader.java:268)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
> (UnmarshallingContext.java:574)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement
> (UnmarshallingContext.java:556)
> at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement
> (SAXConnector.java:168)
> at org.xml.sax.helpers.XMLFilterImpl.startElement (XMLFilterImpl.java:551)
> at org.apache.openejb.jee.JaxbJavaee$JavaeeNamespaceFilter.startElement
> (JaxbJavaee.java:293)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
> (AbstractSAXParser.java:510)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
> (XMLNSDocumentScannerImpl.java:374)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
> (XMLDocumentFragmentScannerImpl.java:2708)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> (XMLDocumentScannerImpl.java:605)
> at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
> (XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
> (XMLDocumentFragmentScannerImpl.java:534)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:888)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:824)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
> (XMLParser.java:141)
> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> (AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
> (SAXParserImpl.java:635)
> at org.xml.sax.helpers.XMLFilterImpl.parse (XMLFilterImpl.java:357)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0
> (UnmarshallerImpl.java:258)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> (UnmarshallerImpl.java:236)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> (UnmarshallerImpl.java:288)
> at org.apache.openejb.jee.JaxbJavaee.unmarshalJavaee (JaxbJavaee.java:133)
> at org.apache.openejb.config.ReadDescriptors.readBeans
> (ReadDescriptors.java:691)
> at org.apache.openejb.config.DeploymentLoader.mergeBeansXml
> (DeploymentLoader.java:1196)
> at org.apache.openejb.config.DeploymentLoader.addBeansXmls
> (DeploymentLoader.java:1184)
> at org.apache.openejb.config.DeploymentLoader.createWebModule
> (DeploymentLoader.java:1098)
> at org.apache.openejb.config.DeploymentLoader.createWebModule
> (DeploymentLoader.java:823)
> at org.apache.openejb.config.DeploymentLoader.load
> (DeploymentLoader.java:234)
> at
[jira] [Commented] (TOMEE-2271) Java11: can't resolve old sun JavaEE namespaces correctly
[
https://issues.apache.org/jira/browse/TOMEE-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686753#comment-16686753
]
Romain Manni-Bucau commented on TOMEE-2271:
---
Send a thread on dev@:
http://maven.40175.n5.nabble.com/maven-and-java11-td5949951.html
> Java11: can't resolve old sun JavaEE namespaces correctly
> -
>
> Key: TOMEE-2271
> URL: https://issues.apache.org/jira/browse/TOMEE-2271
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server, TomEE Maven Plugin
>Affects Versions: 8.0.0-M1, 7.0.5
>Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 8.0.0-Final
>
>
> Just start an application with tomee-embedded-maven-plugin and the following
> will occur:
> NOTE: this errors will be thrown for XMLs in the tomcat libs and also for
> beans.xml/web-fragements in DS:
> javax.xml.bind.UnmarshalException: unerwartetes Element
> (URI:"[http://java.sun.com/xml/ns/javaee];, lokal:"interceptors"). Erwartete
> Elemente
> sind <{}trim>,<{}decorators>,<{}scan>,<{}alternatives>,<{}interceptors>
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent
> (UnmarshallingContext.java:744)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> (Loader.java:262)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> (Loader.java:257)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement
> (Loader.java:124)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement
> (Loader.java:105)
> at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement
> (StructureLoader.java:268)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
> (UnmarshallingContext.java:574)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement
> (UnmarshallingContext.java:556)
> at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement
> (SAXConnector.java:168)
> at org.xml.sax.helpers.XMLFilterImpl.startElement (XMLFilterImpl.java:551)
> at org.apache.openejb.jee.JaxbJavaee$JavaeeNamespaceFilter.startElement
> (JaxbJavaee.java:293)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
> (AbstractSAXParser.java:510)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
> (XMLNSDocumentScannerImpl.java:374)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
> (XMLDocumentFragmentScannerImpl.java:2708)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> (XMLDocumentScannerImpl.java:605)
> at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
> (XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
> (XMLDocumentFragmentScannerImpl.java:534)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:888)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:824)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
> (XMLParser.java:141)
> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> (AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
> (SAXParserImpl.java:635)
> at org.xml.sax.helpers.XMLFilterImpl.parse (XMLFilterImpl.java:357)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0
> (UnmarshallerImpl.java:258)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> (UnmarshallerImpl.java:236)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> (UnmarshallerImpl.java:288)
> at org.apache.openejb.jee.JaxbJavaee.unmarshalJavaee (JaxbJavaee.java:133)
> at org.apache.openejb.config.ReadDescriptors.readBeans
> (ReadDescriptors.java:691)
> at org.apache.openejb.config.DeploymentLoader.mergeBeansXml
> (DeploymentLoader.java:1196)
> at org.apache.openejb.config.DeploymentLoader.addBeansXmls
> (DeploymentLoader.java:1184)
> at org.apache.openejb.config.DeploymentLoader.createWebModule
> (DeploymentLoader.java:1098)
> at org.apache.openejb.config.DeploymentLoader.createWebModule
> (DeploymentLoader.java:823)
> at org.apache.openejb.config.DeploymentLoader.load
> (DeploymentLoader.java:234)
> at org.apache.tomee.catalina.TomcatWebAppBuilder.loadApplication
> (TomcatWebAppBuilder.java:2347)
> at org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal
> (TomcatWebAppBuilder.java:1197)
> at
[jira] [Commented] (TOMEE-2271) Java11: can't resolve old sun JavaEE namespaces correctly
[
https://issues.apache.org/jira/browse/TOMEE-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686669#comment-16686669
]
Romain Manni-Bucau commented on TOMEE-2271:
---
Hi, this is not a namespace issue. The issue only happens in maven context - it
works with tomee embedded standalone - and is due to the fact plexus-classworld
(maven) does not implement loadClass(String,String) which leads to part of jaxb
model to be ignored by the JVM (see Package#getPackageInfo). Fix belongs to
maven. We can potentially workaround using a wrapping classloader and reloading
tomee embedded from there but it would break the embedded mojo objective IMHO.
> Java11: can't resolve old sun JavaEE namespaces correctly
> -
>
> Key: TOMEE-2271
> URL: https://issues.apache.org/jira/browse/TOMEE-2271
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server, TomEE Maven Plugin
>Affects Versions: 8.0.0-M1, 7.0.5
>Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 8.0.0-Final
>
>
> Just start an application with tomee-embedded-maven-plugin and the following
> will occur:
> NOTE: this errors will be thrown for XMLs in the tomcat libs and also for
> beans.xml/web-fragements in DS:
> javax.xml.bind.UnmarshalException: unerwartetes Element
> (URI:"[http://java.sun.com/xml/ns/javaee];, lokal:"interceptors"). Erwartete
> Elemente
> sind <{}trim>,<{}decorators>,<{}scan>,<{}alternatives>,<{}interceptors>
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent
> (UnmarshallingContext.java:744)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> (Loader.java:262)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> (Loader.java:257)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement
> (Loader.java:124)
> at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement
> (Loader.java:105)
> at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement
> (StructureLoader.java:268)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
> (UnmarshallingContext.java:574)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement
> (UnmarshallingContext.java:556)
> at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement
> (SAXConnector.java:168)
> at org.xml.sax.helpers.XMLFilterImpl.startElement (XMLFilterImpl.java:551)
> at org.apache.openejb.jee.JaxbJavaee$JavaeeNamespaceFilter.startElement
> (JaxbJavaee.java:293)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
> (AbstractSAXParser.java:510)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
> (XMLNSDocumentScannerImpl.java:374)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
> (XMLDocumentFragmentScannerImpl.java:2708)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> (XMLDocumentScannerImpl.java:605)
> at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
> (XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
> (XMLDocumentFragmentScannerImpl.java:534)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:888)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:824)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
> (XMLParser.java:141)
> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> (AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
> (SAXParserImpl.java:635)
> at org.xml.sax.helpers.XMLFilterImpl.parse (XMLFilterImpl.java:357)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0
> (UnmarshallerImpl.java:258)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> (UnmarshallerImpl.java:236)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> (UnmarshallerImpl.java:288)
> at org.apache.openejb.jee.JaxbJavaee.unmarshalJavaee (JaxbJavaee.java:133)
> at org.apache.openejb.config.ReadDescriptors.readBeans
> (ReadDescriptors.java:691)
> at org.apache.openejb.config.DeploymentLoader.mergeBeansXml
> (DeploymentLoader.java:1196)
> at org.apache.openejb.config.DeploymentLoader.addBeansXmls
> (DeploymentLoader.java:1184)
> at org.apache.openejb.config.DeploymentLoader.createWebModule
> (DeploymentLoader.java:1098)
> at
[jira] [Commented] (TOMEE-2270) Java11: Unable to initialize agent with embedded-maven-plugin
[ https://issues.apache.org/jira/browse/TOMEE-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686694#comment-16686694 ] Romain Manni-Bucau commented on TOMEE-2270: --- the agent should likely be excluded IMHO from openejb-core, it is sometimes used but often it brings nothing or issues. Since we are going 8.0.0 we can exclude it now from openejb-core* tomee-embedded and just add it in tomee standalone > Java11: Unable to initialize agent with embedded-maven-plugin > - > > Key: TOMEE-2270 > URL: https://issues.apache.org/jira/browse/TOMEE-2270 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server, TomEE Maven Plugin >Affects Versions: 8.0.0-M1, 7.0.5 >Reporter: Thomas Andraschko >Priority: Major > Fix For: 8.0.0-Final > > Attachments: test.zip > > > ava.lang.IllegalStateException: Unable to initialize agent > at > org.apache.openejb.javaagent.Agent.checkInitialization(Agent.java:104) > at > org.apache.openejb.javaagent.Agent.getInstrumentation(Agent.java:94) > at org.apache.tomee.embedded.Container.(Container.java:128) > at > org.apache.openejb.maven.plugins.TomEEEmbeddedMojo.execute(TomEEEmbeddedMojo.java:392) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TOMEE-2276) Update TomEE 7.0.6 with Johnzon 1.0.2
[ https://issues.apache.org/jira/browse/TOMEE-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated TOMEE-2276: -- Priority: Minor (was: Major) > Update TomEE 7.0.6 with Johnzon 1.0.2 > - > > Key: TOMEE-2276 > URL: https://issues.apache.org/jira/browse/TOMEE-2276 > Project: TomEE > Issue Type: Improvement >Affects Versions: 7.0.6 >Reporter: Bruno Baptista >Priority: Minor > > The maintainance branch for johnzon contains important changes, namely: > **JOHNZON-193 ensure objectbuilder is reusable. > See: [https://github.com/apache/johnzon/commits/maintenance_1.0.x] > We should expect for a 1.0.2 release of Johnzon. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2270) Java11: Unable to initialize agent with embedded-maven-plugin
[
https://issues.apache.org/jira/browse/TOMEE-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685389#comment-16685389
]
Romain Manni-Bucau commented on TOMEE-2270:
---
Hi guys,
this requires
{code}
-Djdk.attach.allowAttachSelf=true
{code}
in maven opts or so for this plugin since it is embedded
> Java11: Unable to initialize agent with embedded-maven-plugin
> -
>
> Key: TOMEE-2270
> URL: https://issues.apache.org/jira/browse/TOMEE-2270
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server, TomEE Maven Plugin
>Affects Versions: 8.0.0-M1, 7.0.5
>Reporter: Thomas Andraschko
>Priority: Major
> Fix For: 8.0.0-Final
>
> Attachments: test.zip
>
>
> ava.lang.IllegalStateException: Unable to initialize agent
> at
> org.apache.openejb.javaagent.Agent.checkInitialization(Agent.java:104)
> at
> org.apache.openejb.javaagent.Agent.getInstrumentation(Agent.java:94)
> at org.apache.tomee.embedded.Container.(Container.java:128)
> at
> org.apache.openejb.maven.plugins.TomEEEmbeddedMojo.execute(TomEEEmbeddedMojo.java:392)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2274) JAXB 2.3.1
[ https://issues.apache.org/jira/browse/TOMEE-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685377#comment-16685377 ] Romain Manni-Bucau commented on TOMEE-2274: --- [~cbos]do you mean 2.3.0.1 instead of 2.3.1, cause 2.3.1 is not there > JAXB 2.3.1 > -- > > Key: TOMEE-2274 > URL: https://issues.apache.org/jira/browse/TOMEE-2274 > Project: TomEE > Issue Type: Dependency upgrade >Affects Versions: 1.7.5, 8.0.0-M1, 7.0.5, 7.1.0 >Reporter: Jean-Louis MONTEIRO >Assignee: Jean-Louis MONTEIRO >Priority: Major > Fix For: 8.0.0-Final > > > Issue with Java 11 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2200) defineClass used which is not supported by java 11
[
https://issues.apache.org/jira/browse/TOMEE-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16669807#comment-16669807
]
Romain Manni-Bucau commented on TOMEE-2200:
---
[~dkwakkel] not sure it got fully updated but most of its stack runs fine on
j11 and CXF runs on java 11 by itself but requires some adjustment like opening
some modules and providing some implementations like jaxb so not sure what is
the issue
> defineClass used which is not supported by java 11
> --
>
> Key: TOMEE-2200
> URL: https://issues.apache.org/jira/browse/TOMEE-2200
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5
> Environment: ./catalina.sh version
> Using CATALINA_BASE: /opt/tomee705
> Using CATALINA_HOME: /opt/tomee705
> Using CATALINA_TMPDIR: /opt/tomee705/temp
> Using JRE_HOME:/opt/jdk-11
> Using CLASSPATH:
> /opt/tomee705/bin/bootstrap.jar:/opt/tomee705/bin/tomcat-juli.jar
> NOTE: Picked up JDK_JAVA_OPTIONS:
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.io=ALL-UNNAMED
> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
> Server version: Apache Tomcat/8.5.32
> Server built: Jun 20 2018 19:50:35 UTC
> Server number: 8.5.32.0
> OS Name:Linux
> OS Version: 3.10.0-229.el7.x86_64
> Architecture: amd64
> JVM Version:11-ea+21
> JVM Vendor: Oracle Corporation
>Reporter: Donald Kwakkel
>Assignee: Jonathan Gallimore
>Priority: Critical
>
> Not sure if tomee will support java 11, but with latest java 11 version it is
> not possible to start tomee:
> {code:java}
> SEVERE: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/home]]
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:629)
> at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1839)
> at
> Criticaljava.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.openejb.util.proxy.LocalBeanProxyFactory$Unsafe
> at
> org.apache.openejb.util.proxy.LocalBeanProxyFactory.createProxy(LocalBeanProxyFactory.java:137)
> at
> org.apache.openejb.util.proxy.LocalBeanProxyFactory.createProxy(LocalBeanProxyFactory.java:147)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.eagerInitOfLocalBeanProxies(TomcatWebAppBuilder.java:1563)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1309)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1125)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5154)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> ... 10 more
> {code}
> Reason is that defineClass is used which is no longer supported with java 11
> (at least here, maybe also on other places):
> container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java:
> return Unsafe.defineClass(cl, classToProxy, proxyName, proxyBytes);
> Same issue has openwebbeans: https://issues.apache.org/jira/browse/OWB-1248
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TOMEE-2258) Ensure Tomcat engine parent classloader is the startup TCCL
[
https://issues.apache.org/jira/browse/TOMEE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated TOMEE-2258:
--
Description:
Identified issue:
See
org.apache.openejb.assembler.classic.Assembler
loader.loadClass({color:#6a8759}"org.apache.openejb.bval.BValCdiFilter"{color})
throws a ClassNotFound
however
Class.forName({color:#6a8759}"org.apache.openejb.bval.BValCdiFilter"{color})
would work fine
was:
See
org.apache.openejb.assembler.classic.Assembler
loader.loadClass({color:#6a8759}"org.apache.openejb.bval.BValCdiFilter"{color})
throws a ClassNotFound
however
Class.forName({color:#6a8759}"org.apache.openejb.bval.BValCdiFilter"{color})
would work fine
> Ensure Tomcat engine parent classloader is the startup TCCL
> ---
>
> Key: TOMEE-2258
> URL: https://issues.apache.org/jira/browse/TOMEE-2258
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 8.0.0
>Reporter: Thomas Andraschko
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 8.0.0
>
>
> Identified issue:
> See
> org.apache.openejb.assembler.classic.Assembler
>
> loader.loadClass({color:#6a8759}"org.apache.openejb.bval.BValCdiFilter"{color})
> throws a ClassNotFound
> however
> Class.forName({color:#6a8759}"org.apache.openejb.bval.BValCdiFilter"{color})
> would work fine
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TOMEE-2258) Ensure Tomcat engine parent classloader is the startup TCCL
[
https://issues.apache.org/jira/browse/TOMEE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated TOMEE-2258:
--
Summary: Ensure Tomcat engine parent classloader is the startup TCCL (was:
BValCdiFilter isn't applied)
> Ensure Tomcat engine parent classloader is the startup TCCL
> ---
>
> Key: TOMEE-2258
> URL: https://issues.apache.org/jira/browse/TOMEE-2258
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 8.0.0
>Reporter: Thomas Andraschko
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 8.0.0
>
>
> See
> org.apache.openejb.assembler.classic.Assembler
>
> loader.loadClass({color:#6a8759}"org.apache.openejb.bval.BValCdiFilter"{color})
> throws a ClassNotFound
> however
> Class.forName({color:#6a8759}"org.apache.openejb.bval.BValCdiFilter"{color})
> would work fine
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TOMEE-2252) Update Apache Johnzon to v1.1.11
[ https://issues.apache.org/jira/browse/TOMEE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated TOMEE-2252: -- Summary: Update Apache Johnzon to v1.1.11 (was: Update the next TomEE version with newest Apache Johnzon that fixes JOHNZON-190 issue) > Update Apache Johnzon to v1.1.11 > > > Key: TOMEE-2252 > URL: https://issues.apache.org/jira/browse/TOMEE-2252 > Project: TomEE > Issue Type: Dependency upgrade >Reporter: Otavio Goncalves de Santana >Priority: Major > > Based on the Johnzon issue: https://issues.apache.org/jira/browse/JOHNZON-190 > The Apache TomEE needs to update this library either version 8.x, 7.1.x, and > 7.0.x as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2252) Update the next TomEE version with newest Apache Johnzon
[ https://issues.apache.org/jira/browse/TOMEE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635956#comment-16635956 ] Romain Manni-Bucau commented on TOMEE-2252: --- Hi Otavia, probably set the version in the title you want otherwise this jira will stay forever and will always be up to date ;). > Update the next TomEE version with newest Apache Johnzon > > > Key: TOMEE-2252 > URL: https://issues.apache.org/jira/browse/TOMEE-2252 > Project: TomEE > Issue Type: Dependency upgrade >Reporter: Otavio Goncalves de Santana >Priority: Major > > Based on the Johnzon issue: https://issues.apache.org/jira/browse/JOHNZON-190 > The Apache TomEE needs to update this library either version 8.x, 7.1.x, and > 7.0.x as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TOMEE-2252) Update the next TomEE version with newest Apache Johnzon
[ https://issues.apache.org/jira/browse/TOMEE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated TOMEE-2252: -- Issue Type: Dependency upgrade (was: Bug) > Update the next TomEE version with newest Apache Johnzon > > > Key: TOMEE-2252 > URL: https://issues.apache.org/jira/browse/TOMEE-2252 > Project: TomEE > Issue Type: Dependency upgrade >Reporter: Otavio Goncalves de Santana >Priority: Major > > Based on the Johnzon issue: https://issues.apache.org/jira/browse/JOHNZON-190 > The Apache TomEE needs to update this library either version 8.x, 7.1.x, and > 7.0.x as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2250) org.apache.johnzon.max-string-length default is incorrect in system.properties
[ https://issues.apache.org/jira/browse/TOMEE-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635399#comment-16635399 ] Romain Manni-Bucau commented on TOMEE-2250: --- Tip: you can drop it in tomee 8 since it auto-adjust buffers > org.apache.johnzon.max-string-length default is incorrect in system.properties > -- > > Key: TOMEE-2250 > URL: https://issues.apache.org/jira/browse/TOMEE-2250 > Project: TomEE > Issue Type: Dependency upgrade >Affects Versions: 7.0.5 >Reporter: Jonathan Gallimore >Assignee: Jonathan Gallimore >Priority: Minor > Fix For: 8.0.0, 7.0.6, 7.1.1 > > > The comments in system.properties show org.apache.johnzon.max-string-length > having a default value of 8192. This changes in Johnzon 1.0.1 to 256KB and we > should update the comment accordingly. > https://github.com/apache/johnzon/blob/v1.0.1/johnzon-core/src/main/java/org/apache/johnzon/core/JsonParserFactoryImpl.java#L36 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2246) DataSources created in tomee.xml don't appear in JMX
[
https://issues.apache.org/jira/browse/TOMEE-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628297#comment-16628297
]
Romain Manni-Bucau commented on TOMEE-2246:
---
Maybe you just need openejb.datasource.pool=true in your config? IIRC we dont
pool xa datasource by default cause most of used impl are already pooled so we
rely on vendor config and not our well known pools.
> DataSources created in tomee.xml don't appear in JMX
>
>
> Key: TOMEE-2246
> URL: https://issues.apache.org/jira/browse/TOMEE-2246
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Major
> Attachments: Snip20180925_2.png
>
>
> If I recall correctly, you used to be able to see "datasrouces" in jmx
> openejb.management. Am I imagining that? Just noticed they're no longer
> there. Perphaps I'm declaring my datasource incorrectly?
> {code:java}
> id="jdbc/myDataSource"
> type="DataSource">
>
> JdbcUrl=jdbc:mysql:/example.com:3306?verifyServerCertificate=truerequireSSL=trueuseSSL=true
> user=itsme
> password=password
> JdbcDriver=com.mysql.cj.jdbc.MysqlXADataSource
> MinIdle=5
> MaxActive=75
> MaxWait=5000
> InitialSize=5
> ValidationQuery=SELECT 1
> TestOnBorrow=true
> JmxEnabled=true
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2246) DataSources created in tomee.xml don't appear in JMX
[
https://issues.apache.org/jira/browse/TOMEE-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627936#comment-16627936
]
Romain Manni-Bucau commented on TOMEE-2246:
---
Dbcp is supposed slower than tomcat jdbc (default) but it is under very high
load so no big worry.
Driver is intended to be a driver (yes sounds silly ;)), datasource are
supported mainly for @DataSourceDefinition which use the same exact code so we
can miss sthg here in our config wiring.
> DataSources created in tomee.xml don't appear in JMX
>
>
> Key: TOMEE-2246
> URL: https://issues.apache.org/jira/browse/TOMEE-2246
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Major
> Attachments: Snip20180925_2.png
>
>
> If I recall correctly, you used to be able to see "datasrouces" in jmx
> openejb.management. Am I imagining that? Just noticed they're no longer
> there. Perphaps I'm declaring my datasource incorrectly?
> {code:java}
> id="jdbc/myDataSource"
> type="DataSource">
>
> JdbcUrl=jdbc:mysql:/example.com:3306?verifyServerCertificate=truerequireSSL=trueuseSSL=true
> user=itsme
> password=password
> JdbcDriver=com.mysql.cj.jdbc.MysqlXADataSource
> MinIdle=5
> MaxActive=75
> MaxWait=5000
> InitialSize=5
> ValidationQuery=SELECT 1
> TestOnBorrow=true
> JmxEnabled=true
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2246) DataSources created in tomee.xml don't appear in JMX
[
https://issues.apache.org/jira/browse/TOMEE-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627914#comment-16627914
]
Romain Manni-Bucau commented on TOMEE-2246:
---
No global custom DataSourceCreator - which can inhibit this feature?
No log saying the JMX registration failed?
> DataSources created in tomee.xml don't appear in JMX
>
>
> Key: TOMEE-2246
> URL: https://issues.apache.org/jira/browse/TOMEE-2246
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Major
> Attachments: Snip20180925_2.png
>
>
> If I recall correctly, you used to be able to see "datasrouces" in jmx
> openejb.management. Am I imagining that? Just noticed they're no longer
> there. Perphaps I'm declaring my datasource incorrectly?
> {code:java}
> id="jdbc/myDataSource"
> type="DataSource">
>
> JdbcUrl=jdbc:mysql:/example.com:3306?verifyServerCertificate=truerequireSSL=trueuseSSL=true
> user=itsme
> password=password
> JdbcDriver=com.mysql.cj.jdbc.MysqlXADataSource
> MinIdle=5
> MaxActive=75
> MaxWait=5000
> InitialSize=5
> ValidationQuery=SELECT 1
> TestOnBorrow=true
> JmxEnabled=true
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2238) JMSContext Injected by TomEE [may] incorrectly assumes an active RequestScope or TXScope exists
[
https://issues.apache.org/jira/browse/TOMEE-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620094#comment-16620094
]
Romain Manni-Bucau commented on TOMEE-2238:
---
Yes, this is point 4.4 of the spec.
> JMSContext Injected by TomEE [may] incorrectly assumes an active RequestScope
> or TXScope exists
> ---
>
> Key: TOMEE-2238
> URL: https://issues.apache.org/jira/browse/TOMEE-2238
> Project: TomEE
> Issue Type: Bug
>Reporter: Jonathan S Fisher
>Priority: Major
>
> I'll try to post some code later, but we ran into this bug today.
> We have an Instance, which is submitting MyTask to a
> ManagedExecutorService. The MyTask gets a JMXContext injected into it. So
> basically neither a RequestScope or TXScope exist.
> I'm not sure what the correct behavior should be according to the JMS2 spec,
> but if there's a problem, it's probably because we're limited to thse two
> choices:
> {code}
> private synchronized JMSContext context() {
> if (inTx()) {
> return findOrCreateContext(transactionStorage);
> }
> return findOrCreateContext(requestStorage);
> }
> {code}
> {code}
> javax.enterprise.context.ContextNotActiveException: WebBeans context with
> scope type annotation @RequestScoped does not exist within current thread
> at
> org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:335)
> at
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:89)
> at
> org.apache.webbeans.intercept.RequestScopedBeanInterceptorHandler.getContextualInstance(RequestScopedBeanInterceptorHandler.java:76)
> at
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.get(NormalScopedBeanInterceptorHandler.java:71)
> at
> org.apache.openejb.resource.activemq.jms2.cdi.JMS2CDIExtension$RequestAutoContextDestruction$$OwbNormalScopeProxy0.find(org/apache/openejb/resource/activemq/jms2/cdi/JMS2CDIExtensio
> n$RequestAutoContextDestruction.java)
> at
> org.apache.openejb.resource.activemq.jms2.cdi.JMS2CDIExtension$InternalJMSContext.findOrCreateContext(JMS2CDIExtension.java:270)
> at
> org.apache.openejb.resource.activemq.jms2.cdi.JMS2CDIExtension$InternalJMSContext.context(JMS2CDIExtension.java:266)
> at
> org.apache.openejb.resource.activemq.jms2.cdi.JMS2CDIExtension$InternalJMSContext.createTopic(JMS2CDIExtension.java:425)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TOMEE-2236) MyFaces 2.3.2
Romain Manni-Bucau created TOMEE-2236: - Summary: MyFaces 2.3.2 Key: TOMEE-2236 URL: https://issues.apache.org/jira/browse/TOMEE-2236 Project: TomEE Issue Type: Dependency upgrade Reporter: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2233) DateTimeParseException Regression when upgrading to TomEE 7.1.0
[
https://issues.apache.org/jira/browse/TOMEE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16611815#comment-16611815
]
Romain Manni-Bucau commented on TOMEE-2233:
---
TomEE provider can add any setProperty to facilitate that and xbean will be
able to wire it. Do you want to give a try to provide a PR?
> DateTimeParseException Regression when upgrading to TomEE 7.1.0
> ---
>
> Key: TOMEE-2233
> URL: https://issues.apache.org/jira/browse/TOMEE-2233
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.1
> Environment: TomEE 7.1.0 (embedded, plus...), OpenJDK 8, 10, Windows
> 10 & MacOs 10.13
>Reporter: Martin Wiesner
>Priority: Major
>
> When upgrading to TomEE 7.1.0 from 7.0.5, we encounter a regression. We
> observe an unexpected behaviour with _JSON date format parsing_ which was
> working correctly (as configured) in TomEE 7.0.5.
> It can be reproduced in several of our projects, see stack trace below.
> {code:java}
> Caused by: javax.json.bind.JsonbException: Text '20180910121456+0200' could
> not be parsed at index 0
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:200)
> at
> org.apache.johnzon.jaxrs.jsonb.jaxrs.JsonbJaxrsProvider.readFrom(JsonbJaxrsProvider.java:165)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1379)
> at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:377)
> ... 57 more
> Caused by: org.apache.johnzon.mapper.MapperException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:716)
> at
> org.apache.johnzon.mapper.MappingParserImpl.buildObject(MappingParserImpl.java:347)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:150)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:142)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:129)
> at org.apache.johnzon.mapper.Mapper.mapObject(Mapper.java:310)
> at org.apache.johnzon.mapper.Mapper.readObject(Mapper.java:228)
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:194)
> ... 60 more
> Caused by: java.time.format.DateTimeParseException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
> at java.time.LocalDateTime.parse(LocalDateTime.java:492)
> at java.time.LocalDateTime.parse(LocalDateTime.java:477)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:487)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:479)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:37)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:24)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:710)
> ... 67 more{code}
>
> MWE on GitHub will follow shortly via comment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2233) DateTimeParseException Regression when upgrading to TomEE 7.1.0
[
https://issues.apache.org/jira/browse/TOMEE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610661#comment-16610661
]
Romain Manni-Bucau commented on TOMEE-2233:
---
Yes it was intentionally hardcoded, you can use a ZonedDateTime to hold it in
your instance (recommended).
You can also register a custom adapter converting the date with some custom
logic on the provider.
> DateTimeParseException Regression when upgrading to TomEE 7.1.0
> ---
>
> Key: TOMEE-2233
> URL: https://issues.apache.org/jira/browse/TOMEE-2233
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.1
> Environment: TomEE 7.1.0 (embedded, plus...), OpenJDK 8, 10, Windows
> 10 & MacOs 10.13
>Reporter: Martin Wiesner
>Priority: Major
>
> When upgrading to TomEE 7.1.0 from 7.0.5, we encounter a regression. We
> observe an unexpected behaviour with _JSON date format parsing_ which was
> working correctly (as configured) in TomEE 7.0.5.
> It can be reproduced in several of our projects, see stack trace below.
> {code:java}
> Caused by: javax.json.bind.JsonbException: Text '20180910121456+0200' could
> not be parsed at index 0
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:200)
> at
> org.apache.johnzon.jaxrs.jsonb.jaxrs.JsonbJaxrsProvider.readFrom(JsonbJaxrsProvider.java:165)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1379)
> at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:377)
> ... 57 more
> Caused by: org.apache.johnzon.mapper.MapperException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:716)
> at
> org.apache.johnzon.mapper.MappingParserImpl.buildObject(MappingParserImpl.java:347)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:150)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:142)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:129)
> at org.apache.johnzon.mapper.Mapper.mapObject(Mapper.java:310)
> at org.apache.johnzon.mapper.Mapper.readObject(Mapper.java:228)
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:194)
> ... 60 more
> Caused by: java.time.format.DateTimeParseException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
> at java.time.LocalDateTime.parse(LocalDateTime.java:492)
> at java.time.LocalDateTime.parse(LocalDateTime.java:477)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:487)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:479)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:37)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:24)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:710)
> ... 67 more{code}
>
> MWE on GitHub will follow shortly via comment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2233) DateTimeParseException Regression when upgrading to TomEE 7.1.0
[
https://issues.apache.org/jira/browse/TOMEE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610546#comment-16610546
]
Romain Manni-Bucau commented on TOMEE-2233:
---
You can use xbean-reflect model ( / config in tomee.xml or
resources.xml) to instantiate a locale from the constructor (using
constructor-args as XML attribute) and inject it in the resource as a value
using @resourceId or $serviceId
> DateTimeParseException Regression when upgrading to TomEE 7.1.0
> ---
>
> Key: TOMEE-2233
> URL: https://issues.apache.org/jira/browse/TOMEE-2233
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.1
> Environment: TomEE 7.1.0 (embedded, plus...), OpenJDK 8, 10, Windows
> 10 & MacOs 10.13
>Reporter: Martin Wiesner
>Priority: Major
>
> When upgrading to TomEE 7.1.0 from 7.0.5, we encounter a regression. We
> observe an unexpected behaviour with _JSON date format parsing_ which was
> working correctly (as configured) in TomEE 7.0.5.
> It can be reproduced in several of our projects, see stack trace below.
> {code:java}
> Caused by: javax.json.bind.JsonbException: Text '20180910121456+0200' could
> not be parsed at index 0
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:200)
> at
> org.apache.johnzon.jaxrs.jsonb.jaxrs.JsonbJaxrsProvider.readFrom(JsonbJaxrsProvider.java:165)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1379)
> at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:377)
> ... 57 more
> Caused by: org.apache.johnzon.mapper.MapperException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:716)
> at
> org.apache.johnzon.mapper.MappingParserImpl.buildObject(MappingParserImpl.java:347)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:150)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:142)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:129)
> at org.apache.johnzon.mapper.Mapper.mapObject(Mapper.java:310)
> at org.apache.johnzon.mapper.Mapper.readObject(Mapper.java:228)
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:194)
> ... 60 more
> Caused by: java.time.format.DateTimeParseException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
> at java.time.LocalDateTime.parse(LocalDateTime.java:492)
> at java.time.LocalDateTime.parse(LocalDateTime.java:477)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:487)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:479)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:37)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:24)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:710)
> ... 67 more{code}
>
> MWE on GitHub will follow shortly via comment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2233) DateTimeParseException Regression when upgrading to TomEE 7.1.0
[
https://issues.apache.org/jira/browse/TOMEE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610410#comment-16610410
]
Romain Manni-Bucau commented on TOMEE-2233:
---
You can set the property "jsonb.date-format" on the new provider through the
same configuration mecanism using the "otherProperties" key and the value using
a java.util.Properties syntax. This will pass through jsonb config properties.
Alternatively you can implement a JAX-RS ContextResolver and johnzon
will pick this as the right instance to use (easier surely from a code
perspective).
> DateTimeParseException Regression when upgrading to TomEE 7.1.0
> ---
>
> Key: TOMEE-2233
> URL: https://issues.apache.org/jira/browse/TOMEE-2233
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.1
> Environment: TomEE 7.1.0 (embedded, plus...), OpenJDK 8, 10, Windows
> 10 & MacOs 10.13
>Reporter: Martin Wiesner
>Priority: Major
>
> When upgrading to TomEE 7.1.0 from 7.0.5, we encounter a regression. We
> observe an unexpected behaviour with _JSON date format parsing_ which was
> working correctly (as configured) in TomEE 7.0.5.
> It can be reproduced in several of our projects, see stack trace below.
> {code:java}
> Caused by: javax.json.bind.JsonbException: Text '20180910121456+0200' could
> not be parsed at index 0
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:200)
> at
> org.apache.johnzon.jaxrs.jsonb.jaxrs.JsonbJaxrsProvider.readFrom(JsonbJaxrsProvider.java:165)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1379)
> at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:377)
> ... 57 more
> Caused by: org.apache.johnzon.mapper.MapperException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:716)
> at
> org.apache.johnzon.mapper.MappingParserImpl.buildObject(MappingParserImpl.java:347)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:150)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:142)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:129)
> at org.apache.johnzon.mapper.Mapper.mapObject(Mapper.java:310)
> at org.apache.johnzon.mapper.Mapper.readObject(Mapper.java:228)
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:194)
> ... 60 more
> Caused by: java.time.format.DateTimeParseException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
> at java.time.LocalDateTime.parse(LocalDateTime.java:492)
> at java.time.LocalDateTime.parse(LocalDateTime.java:477)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:487)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:479)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:37)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:24)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:710)
> ... 67 more{code}
>
> MWE on GitHub will follow shortly via comment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2233) DateTimeParseException Regression when upgrading to TomEE 7.1.0
[
https://issues.apache.org/jira/browse/TOMEE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610342#comment-16610342
]
Romain Manni-Bucau commented on TOMEE-2233:
---
You can add in conf/system.properties:
{code}
openejb.jaxrs.client.providers=org.apache.openejb.server.cxf.rs.johnzon.TomEEJohnzonProvider,org.apache.openejb.server.cxf.rs.johnzon.TomEEJsonpProvider
{code}
Should force the old behavior normally.
> DateTimeParseException Regression when upgrading to TomEE 7.1.0
> ---
>
> Key: TOMEE-2233
> URL: https://issues.apache.org/jira/browse/TOMEE-2233
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.1
> Environment: TomEE 7.1.0 (embedded, plus...), OpenJDK 8, 10, Windows
> 10 & MacOs 10.13
>Reporter: Martin Wiesner
>Priority: Major
>
> When upgrading to TomEE 7.1.0 from 7.0.5, we encounter a regression. We
> observe an unexpected behaviour with _JSON date format parsing_ which was
> working correctly (as configured) in TomEE 7.0.5.
> It can be reproduced in several of our projects, see stack trace below.
> {code:java}
> Caused by: javax.json.bind.JsonbException: Text '20180910121456+0200' could
> not be parsed at index 0
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:200)
> at
> org.apache.johnzon.jaxrs.jsonb.jaxrs.JsonbJaxrsProvider.readFrom(JsonbJaxrsProvider.java:165)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1379)
> at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:377)
> ... 57 more
> Caused by: org.apache.johnzon.mapper.MapperException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:716)
> at
> org.apache.johnzon.mapper.MappingParserImpl.buildObject(MappingParserImpl.java:347)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:150)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:142)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:129)
> at org.apache.johnzon.mapper.Mapper.mapObject(Mapper.java:310)
> at org.apache.johnzon.mapper.Mapper.readObject(Mapper.java:228)
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:194)
> ... 60 more
> Caused by: java.time.format.DateTimeParseException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
> at java.time.LocalDateTime.parse(LocalDateTime.java:492)
> at java.time.LocalDateTime.parse(LocalDateTime.java:477)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:487)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:479)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:37)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:24)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:710)
> ... 67 more{code}
>
> MWE on GitHub will follow shortly via comment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TOMEE-2233) DateTimeParseException Regression when upgrading to TomEE 7.1.0
[
https://issues.apache.org/jira/browse/TOMEE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609481#comment-16609481
]
Romain Manni-Bucau edited comment on TOMEE-2233 at 9/10/18 4:41 PM:
Hi Martin, LocalDateTime must respect LocalDateTime class parsing (we just do a
parse(text)). Did you ensure you respect that? This is due to the switch to
jsonb impl by default vs johnzon mapper before.
edit: ref
http://tomee-openejb.979440.n4.nabble.com/TomEE-8-Jsonb-Provider-td4684419.html
was (Author: romain.manni-bucau):
Hi Martin, LocalDateTime must respect LocalDateTime class parsing (we just do a
parse(text)). Did you ensure you respect that? This is due to the switch to
jsonb impl by default vs johnzon mapper before.
> DateTimeParseException Regression when upgrading to TomEE 7.1.0
> ---
>
> Key: TOMEE-2233
> URL: https://issues.apache.org/jira/browse/TOMEE-2233
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.1
> Environment: TomEE 7.1.0 (embedded, plus...), OpenJDK 8, 10, Windows
> 10 & MacOs 10.13
>Reporter: Martin Wiesner
>Priority: Major
>
> When upgrading to TomEE 7.1.0 from 7.0.5, we encounter a regression. We
> observe an unexpected behaviour with _JSON date format parsing_ which was
> working correctly (as configured) in TomEE 7.0.5.
> It can be reproduced in several of our projects, see stack trace below.
> {code:java}
> Caused by: javax.json.bind.JsonbException: Text '20180910121456+0200' could
> not be parsed at index 0
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:200)
> at
> org.apache.johnzon.jaxrs.jsonb.jaxrs.JsonbJaxrsProvider.readFrom(JsonbJaxrsProvider.java:165)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1379)
> at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:377)
> ... 57 more
> Caused by: org.apache.johnzon.mapper.MapperException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:716)
> at
> org.apache.johnzon.mapper.MappingParserImpl.buildObject(MappingParserImpl.java:347)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:150)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:142)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:129)
> at org.apache.johnzon.mapper.Mapper.mapObject(Mapper.java:310)
> at org.apache.johnzon.mapper.Mapper.readObject(Mapper.java:228)
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:194)
> ... 60 more
> Caused by: java.time.format.DateTimeParseException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
> at java.time.LocalDateTime.parse(LocalDateTime.java:492)
> at java.time.LocalDateTime.parse(LocalDateTime.java:477)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:487)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:479)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:37)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:24)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:710)
> ... 67 more{code}
>
> MWE on GitHub will follow shortly via comment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2233) DateTimeParseException Regression when upgrading to TomEE 7.1.0
[
https://issues.apache.org/jira/browse/TOMEE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609481#comment-16609481
]
Romain Manni-Bucau commented on TOMEE-2233:
---
Hi Martin, LocalDateTime must respect LocalDateTime class parsing (we just do a
parse(text)). Did you ensure you respect that? This is due to the switch to
jsonb impl by default vs johnzon mapper before.
> DateTimeParseException Regression when upgrading to TomEE 7.1.0
> ---
>
> Key: TOMEE-2233
> URL: https://issues.apache.org/jira/browse/TOMEE-2233
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.1
> Environment: TomEE 7.1.0 (embedded, plus...), OpenJDK 8, 10, Windows
> 10 & MacOs 10.13
>Reporter: Martin Wiesner
>Priority: Major
>
> When upgrading to TomEE 7.1.0 from 7.0.5, we encounter a regression. We
> observe an unexpected behaviour with _JSON date format parsing_ which was
> working correctly (as configured) in TomEE 7.0.5.
> It can be reproduced in several of our projects, see stack trace below.
> {code:java}
> Caused by: javax.json.bind.JsonbException: Text '20180910121456+0200' could
> not be parsed at index 0
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:200)
> at
> org.apache.johnzon.jaxrs.jsonb.jaxrs.JsonbJaxrsProvider.readFrom(JsonbJaxrsProvider.java:165)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1379)
> at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:377)
> ... 57 more
> Caused by: org.apache.johnzon.mapper.MapperException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:716)
> at
> org.apache.johnzon.mapper.MappingParserImpl.buildObject(MappingParserImpl.java:347)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:150)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:142)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(MappingParserImpl.java:129)
> at org.apache.johnzon.mapper.Mapper.mapObject(Mapper.java:310)
> at org.apache.johnzon.mapper.Mapper.readObject(Mapper.java:228)
> at org.apache.johnzon.jsonb.JohnzonJsonb.fromJson(JohnzonJsonb.java:194)
> ... 60 more
> Caused by: java.time.format.DateTimeParseException: Text
> '20180910121456+0200' could not be parsed at index 0
> at
> java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
> at java.time.LocalDateTime.parse(LocalDateTime.java:492)
> at java.time.LocalDateTime.parse(LocalDateTime.java:477)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:487)
> at
> org.apache.johnzon.jsonb.JohnzonBuilder$7.fromString(JohnzonBuilder.java:479)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:37)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(ConverterAdapter.java:24)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(MappingParserImpl.java:710)
> ... 67 more{code}
>
> MWE on GitHub will follow shortly via comment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TOMEE-2232) TomEE doesn't honor @XMLElement() name when deserializing JSON
[
https://issues.apache.org/jira/browse/TOMEE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608158#comment-16608158
]
Romain Manni-Bucau edited comment on TOMEE-2232 at 9/8/18 5:53 PM:
---
The point is that it is nowhere is the spec that json must read jaxb
annotations. Some vendors - oracle and jboss IIRC - did it before json become
an api in javaee. Since it exists as an API (javaee 7) there is no ambiguity or
overlap between jaxb and json.
If you want that not portable feature, configuring jackson as a provider is
likely the fastest and sanest solution but since EE 7/8 it is saner to just use
the javax.json API, in particular with the changes in java in java 9 and later.
Also, if you only want to handle the name and not the namespace stuff of jaxb
you can implement a custom AccessMode in 30 LOC using johnzon and configure it
in tomee. Saner than overriding tomee defaults and use an untested distro ;).
was (Author: romain.manni-bucau):
The point is that it is nowhere is the spec that json must read jaxb
annotations. Some vendors - oracle and jboss IIRC - did it before json become
an api in javaee. Since it exists as an API (javaee 7) there is no ambiguity or
overlap between jaxb and json.
If you want that not portable feature, configuring jackson as a provider is
likely the fastest and sanest solution but since EE 7/8 it is saner to just use
the javax.json API, in particular with the changes in java in java 9 and later.
> TomEE doesn't honor @XMLElement() name when deserializing JSON
> --
>
> Key: TOMEE-2232
> URL: https://issues.apache.org/jira/browse/TOMEE-2232
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Critical
>
> We encountered a strange limitation while working with salesforce. We're
> hitting their login OAUTH endpoint and it returns a JSON string like this:
> {code:json}
> {
>"access_token":"onebiglongstring",
>"instance_url":"https://ab67.salesforce.com;,
>"id":"https://test.salesforce.com/id/sfid/sifd;,
>"token_type":"Bearer",
>"issued_at":"1536415016572",
>"signature":"morebase64"
> }
> {code}
> So naturally we constructed the following Java class:
> {code:java}
> @Data
> public class SalesforceLoginToken {
> @XmlElement(name = "access_token")
> private String accessToken;
> @XmlElement(name = "instance_url")
> private String instanceUrl;
> @XmlElement
> private String id;
> @XmlElement(name = "token_type")
> private String tokenType;
> @XmlElement(name = "issued_at")
> private String issuedAt;
> @XmlElement
> private String signature;
> }
> {code}
> However, TomEE will not deserialize any of the fields where the name is
> specified in the XMLElement. A [head-desking] workaround we're using is to
> break javabean convention and write our variables like this:
> {code:java}
> @XmlElement
> private String token_type;
> {code}
> because this won't work. TomEE simply fills out null every time:
> {code:java}
> @XmlElement(name = "token_type")
> private String tokenType;
> {code}
> I believe this used to work in TomEE 1.7.5, I haven't tested on master or
> anything else.
> Anyway thanks,
> -Jonathan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2232) TomEE doesn't honor @XMLElement() name when deserializing JSON
[
https://issues.apache.org/jira/browse/TOMEE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608158#comment-16608158
]
Romain Manni-Bucau commented on TOMEE-2232:
---
The point is that it is nowhere is the spec that json must read jaxb
annotations. Some vendors - oracle and jboss IIRC - did it before json become
an api in javaee. Since it exists as an API (javaee 7) there is no ambiguity or
overlap between jaxb and json.
If you want that not portable feature, configuring jackson as a provider is
likely the fastest and sanest solution but since EE 7/8 it is saner to just use
the javax.json API, in particular with the changes in java in java 9 and later.
> TomEE doesn't honor @XMLElement() name when deserializing JSON
> --
>
> Key: TOMEE-2232
> URL: https://issues.apache.org/jira/browse/TOMEE-2232
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Critical
>
> We encountered a strange limitation while working with salesforce. We're
> hitting their login OAUTH endpoint and it returns a JSON string like this:
> {code:json}
> {
>"access_token":"onebiglongstring",
>"instance_url":"https://ab67.salesforce.com;,
>"id":"https://test.salesforce.com/id/sfid/sifd;,
>"token_type":"Bearer",
>"issued_at":"1536415016572",
>"signature":"morebase64"
> }
> {code}
> So naturally we constructed the following Java class:
> {code:java}
> @Data
> public class SalesforceLoginToken {
> @XmlElement(name = "access_token")
> private String accessToken;
> @XmlElement(name = "instance_url")
> private String instanceUrl;
> @XmlElement
> private String id;
> @XmlElement(name = "token_type")
> private String tokenType;
> @XmlElement(name = "issued_at")
> private String issuedAt;
> @XmlElement
> private String signature;
> }
> {code}
> However, TomEE will not deserialize any of the fields where the name is
> specified in the XMLElement. A [head-desking] workaround we're using is to
> break javabean convention and write our variables like this:
> {code:java}
> @XmlElement
> private String token_type;
> {code}
> because this won't work. TomEE simply fills out null every time:
> {code:java}
> @XmlElement(name = "token_type")
> private String tokenType;
> {code}
> I believe this used to work in TomEE 1.7.5, I haven't tested on master or
> anything else.
> Anyway thanks,
> -Jonathan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2232) TomEE doesn't honor @XMLElement() name when deserializing JSON
[
https://issues.apache.org/jira/browse/TOMEE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608074#comment-16608074
]
Romain Manni-Bucau commented on TOMEE-2232:
---
I dont see here that jaxb api is respected by json (un)marhsalling and it was
not in javaee 6 since json was out of spec so tomee behavior is really aligned
on your link.
> TomEE doesn't honor @XMLElement() name when deserializing JSON
> --
>
> Key: TOMEE-2232
> URL: https://issues.apache.org/jira/browse/TOMEE-2232
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Critical
>
> We encountered a strange limitation while working with salesforce. We're
> hitting their login OAUTH endpoint and it returns a JSON string like this:
> {code:json}
> {
>"access_token":"onebiglongstring",
>"instance_url":"https://ab67.salesforce.com;,
>"id":"https://test.salesforce.com/id/sfid/sifd;,
>"token_type":"Bearer",
>"issued_at":"1536415016572",
>"signature":"morebase64"
> }
> {code}
> So naturally we constructed the following Java class:
> {code:java}
> @Data
> public class SalesforceLoginToken {
> @XmlElement(name = "access_token")
> private String accessToken;
> @XmlElement(name = "instance_url")
> private String instanceUrl;
> @XmlElement
> private String id;
> @XmlElement(name = "token_type")
> private String tokenType;
> @XmlElement(name = "issued_at")
> private String issuedAt;
> @XmlElement
> private String signature;
> }
> {code}
> However, TomEE will not deserialize any of the fields where the name is
> specified in the XMLElement. A [head-desking] workaround we're using is to
> break javabean convention and write our variables like this:
> {code:java}
> @XmlElement
> private String token_type;
> {code}
> because this won't work. TomEE simply fills out null every time:
> {code:java}
> @XmlElement(name = "token_type")
> private String tokenType;
> {code}
> I believe this used to work in TomEE 1.7.5, I haven't tested on master or
> anything else.
> Anyway thanks,
> -Jonathan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (TOMEE-2232) TomEE doesn't honor @XMLElement() name when deserializing JSON
[
https://issues.apache.org/jira/browse/TOMEE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau resolved TOMEE-2232.
---
Resolution: Not A Bug
> TomEE doesn't honor @XMLElement() name when deserializing JSON
> --
>
> Key: TOMEE-2232
> URL: https://issues.apache.org/jira/browse/TOMEE-2232
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Critical
>
> We encountered a strange limitation while working with salesforce. We're
> hitting their login OAUTH endpoint and it returns a JSON string like this:
> {code:json}
> {
>"access_token":"onebiglongstring",
>"instance_url":"https://ab67.salesforce.com;,
>"id":"https://test.salesforce.com/id/sfid/sifd;,
>"token_type":"Bearer",
>"issued_at":"1536415016572",
>"signature":"morebase64"
> }
> {code}
> So naturally we constructed the following Java class:
> {code:java}
> @Data
> public class SalesforceLoginToken {
> @XmlElement(name = "access_token")
> private String accessToken;
> @XmlElement(name = "instance_url")
> private String instanceUrl;
> @XmlElement
> private String id;
> @XmlElement(name = "token_type")
> private String tokenType;
> @XmlElement(name = "issued_at")
> private String issuedAt;
> @XmlElement
> private String signature;
> }
> {code}
> However, TomEE will not deserialize any of the fields where the name is
> specified in the XMLElement. A [head-desking] workaround we're using is to
> break javabean convention and write our variables like this:
> {code:java}
> @XmlElement
> private String token_type;
> {code}
> because this won't work. TomEE simply fills out null every time:
> {code:java}
> @XmlElement(name = "token_type")
> private String tokenType;
> {code}
> I believe this used to work in TomEE 1.7.5, I haven't tested on master or
> anything else.
> Anyway thanks,
> -Jonathan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2232) TomEE doesn't honor @XMLElement() name when deserializing JSON
[
https://issues.apache.org/jira/browse/TOMEE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608069#comment-16608069
]
Romain Manni-Bucau commented on TOMEE-2232:
---
This is intended, 1.7 and 7.0 use johnzon so use @JohnzonProperty and 7.1 moved
to jsonb so use @JsonbProperty. This kind of worked - it was adding a wrapper -
with 1.5 and previous through jettison but user asked to not keep this bad json
mapping by default so we aligned on the json spec.
> TomEE doesn't honor @XMLElement() name when deserializing JSON
> --
>
> Key: TOMEE-2232
> URL: https://issues.apache.org/jira/browse/TOMEE-2232
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Critical
>
> We encountered a strange limitation while working with salesforce. We're
> hitting their login OAUTH endpoint and it returns a JSON string like this:
> {code:json}
> {
>"access_token":"onebiglongstring",
>"instance_url":"https://ab67.salesforce.com;,
>"id":"https://test.salesforce.com/id/sfid/sifd;,
>"token_type":"Bearer",
>"issued_at":"1536415016572",
>"signature":"morebase64"
> }
> {code}
> So naturally we constructed the following Java class:
> {code:java}
> @Data
> public class SalesforceLoginToken {
> @XmlElement(name = "access_token")
> private String accessToken;
> @XmlElement(name = "instance_url")
> private String instanceUrl;
> @XmlElement
> private String id;
> @XmlElement(name = "token_type")
> private String tokenType;
> @XmlElement(name = "issued_at")
> private String issuedAt;
> @XmlElement
> private String signature;
> }
> {code}
> However, TomEE will not deserialize any of the fields where the name is
> specified in the XMLElement. A [head-desking] workaround we're using is to
> break javabean convention and write our variables like this:
> {code:java}
> @XmlElement
> private String token_type;
> {code}
> because this won't work. TomEE simply fills out null every time:
> {code:java}
> @XmlElement(name = "token_type")
> private String tokenType;
> {code}
> I believe this used to work in TomEE 1.7.5, I haven't tested on master or
> anything else.
> Anyway thanks,
> -Jonathan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2229) JMSContext Injected by TomEE does not participate in JTA, or at least sends messages immediately
[
https://issues.apache.org/jira/browse/TOMEE-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598923#comment-16598923
]
Romain Manni-Bucau commented on TOMEE-2229:
---
did you try the mentionned config:
{code:java}
ResourceAdapter=ra/activemq
{code}
> JMSContext Injected by TomEE does not participate in JTA, or at least sends
> messages immediately
>
>
> Key: TOMEE-2229
> URL: https://issues.apache.org/jira/browse/TOMEE-2229
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Critical
>
> Hey guys,
> We noticed that if you have a JMSContext in a transaction EJB or CDI Bean, it
> always sends messages immediately instead of waiting for the XA to commit.
> We found this by injecting a JMSContext into an MDB marked with
> TransactionAttribute(Required), calling the jmsContext.createProducer()
> method, sending some messages, then sleeping the original MDB thread for
> several seconds. The messages arrive at their destinations immediately, long
> before the MDB thread wakes up and the XA transaction completes.
> Is there a chance our understanding is not correct?
> According to the docs:
> {quote}If the injected JMSContext is used in a JTA transaction (whether
> container-managed or bean-managed), the JMSContext is considered to have
> transaction scope. This means that after the JTA transaction is committed,
> the JMSContext will be automatically closed.{quote}
> References:
> * https://www.oracle.com/technetwork/articles/java/jms20-1947669.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TOMEE-2229) JMSContext Injected by TomEE does not participate in JTA, or at least sends messages immediately
[
https://issues.apache.org/jira/browse/TOMEE-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598923#comment-16598923
]
Romain Manni-Bucau edited comment on TOMEE-2229 at 8/31/18 3:45 PM:
did you try the mentionned config:
{code:java}
ResourceAdapter=ra/activemq
{code}
?
was (Author: romain.manni-bucau):
did you try the mentionned config:
{code:java}
ResourceAdapter=ra/activemq
{code}
> JMSContext Injected by TomEE does not participate in JTA, or at least sends
> messages immediately
>
>
> Key: TOMEE-2229
> URL: https://issues.apache.org/jira/browse/TOMEE-2229
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Critical
>
> Hey guys,
> We noticed that if you have a JMSContext in a transaction EJB or CDI Bean, it
> always sends messages immediately instead of waiting for the XA to commit.
> We found this by injecting a JMSContext into an MDB marked with
> TransactionAttribute(Required), calling the jmsContext.createProducer()
> method, sending some messages, then sleeping the original MDB thread for
> several seconds. The messages arrive at their destinations immediately, long
> before the MDB thread wakes up and the XA transaction completes.
> Is there a chance our understanding is not correct?
> According to the docs:
> {quote}If the injected JMSContext is used in a JTA transaction (whether
> container-managed or bean-managed), the JMSContext is considered to have
> transaction scope. This means that after the JTA transaction is committed,
> the JMSContext will be automatically closed.{quote}
> References:
> * https://www.oracle.com/technetwork/articles/java/jms20-1947669.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2228) CDI Event should fire when TransactionScope is created
[
https://issues.apache.org/jira/browse/TOMEE-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595966#comment-16595966
]
Romain Manni-Bucau commented on TOMEE-2228:
---
Hi Jonathan,
We can add a flag to enable it thanks to a manual user operation but I wouldnt
do it by default since it is highly not portable and it would be an issue for
users using tomee in a test environment and another server elsewhere. This
scope has to respect its spec and not cdi best practises (but +1000 to make an
issue in jta).
On the leak: it doesnt leak cause there is nothing to destroy at container
shutdown since the context is a threadlocal destroyed elsewhere and not
specific to cdi.
> CDI Event should fire when TransactionScope is created
> --
>
> Key: TOMEE-2228
> URL: https://issues.apache.org/jira/browse/TOMEE-2228
> Project: TomEE
> Issue Type: Wish
> Components: TomEE Core Server
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Minor
>
> Given the code:
> {code}
> @ApplicationScoped
> public class MyClass {
> public void processConversationScopedInit(@Observes
> @Initialized(TransactionScoped.class) Object payload) {}
>
> public void processConversationScopedDestroyed(@Observes
> @Destroyed(TransactionScoped.class) Object payload) {}
> }
> {code}
> One would expect these events to fire. Although not specifically mandated in
> the spec, it does encourage portable extensions to fire @Initialized(X.class)
> where X is a custom scope.
> Also, not sure if this is a bug or not, but it appears the TransactionScope
> may leak upon Container shutdown, as TransactionScope is not listed here:
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/cdi/OpenEJBLifecycle.java#L284
> * https://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context
> * TOMEE-1282
> * TOMEE-1315
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TOMEE-2228) CDI Event should fire when TransactionScope is created
[
https://issues.apache.org/jira/browse/TOMEE-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated TOMEE-2228:
--
Issue Type: Wish (was: Bug)
> CDI Event should fire when TransactionScope is created
> --
>
> Key: TOMEE-2228
> URL: https://issues.apache.org/jira/browse/TOMEE-2228
> Project: TomEE
> Issue Type: Wish
> Components: TomEE Core Server
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Major
>
> Given the code:
> {code}
> @ApplicationScoped
> public class MyClass {
> public void processConversationScopedInit(@Observes
> @Initialized(TransactionScoped.class) Object payload) {}
>
> public void processConversationScopedDestroyed(@Observes
> @Destroyed(TransactionScoped.class) Object payload) {}
> }
> {code}
> One would expect these events to fire. Although not specifically mandated in
> the spec, it does encourage portable extensions to fire @Initialized(X.class)
> where X is a custom scope.
> Also, not sure if this is a bug or not, but it appears the TransactionScope
> may leak upon Container shutdown, as TransactionScope is not listed here:
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/cdi/OpenEJBLifecycle.java#L284
> * https://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context
> * TOMEE-1282
> * TOMEE-1315
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TOMEE-2228) CDI Event should fire when TransactionScope is created
[
https://issues.apache.org/jira/browse/TOMEE-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated TOMEE-2228:
--
Priority: Minor (was: Major)
> CDI Event should fire when TransactionScope is created
> --
>
> Key: TOMEE-2228
> URL: https://issues.apache.org/jira/browse/TOMEE-2228
> Project: TomEE
> Issue Type: Wish
> Components: TomEE Core Server
>Affects Versions: 7.0.5
>Reporter: Jonathan S Fisher
>Priority: Minor
>
> Given the code:
> {code}
> @ApplicationScoped
> public class MyClass {
> public void processConversationScopedInit(@Observes
> @Initialized(TransactionScoped.class) Object payload) {}
>
> public void processConversationScopedDestroyed(@Observes
> @Destroyed(TransactionScoped.class) Object payload) {}
> }
> {code}
> One would expect these events to fire. Although not specifically mandated in
> the spec, it does encourage portable extensions to fire @Initialized(X.class)
> where X is a custom scope.
> Also, not sure if this is a bug or not, but it appears the TransactionScope
> may leak upon Container shutdown, as TransactionScope is not listed here:
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/cdi/OpenEJBLifecycle.java#L284
> * https://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context
> * TOMEE-1282
> * TOMEE-1315
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TOMEE-2223) Incorrect JPA entity used when running under docker
[
https://issues.apache.org/jira/browse/TOMEE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16587880#comment-16587880
]
Romain Manni-Bucau edited comment on TOMEE-2223 at 8/21/18 7:16 PM:
Do you deploy an ear? Any chance you get duplicated classes in your classpath?
Can lead to that too.
was (Author: romain.manni-bucau):
ou deploy an ear? Any chance you get duplicated classes in your classpath? Can
lead to that too.
> Incorrect JPA entity used when running under docker
> ---
>
> Key: TOMEE-2223
> URL: https://issues.apache.org/jira/browse/TOMEE-2223
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5
> Environment: * Docker version 17.12.1-ce, build 7390fc6;
> * Official Ubuntu 18.04 (x64) docker image with OpenJDK 8 installed;
> * apache-tomee-webprofile-7.0.5;
> * Apache Derby 10.14.2.0 (embedded);
>Reporter: Fabio Jun Takada Chino
>Priority: Minor
>
> While packing a very simple web application inside a docker container based
> on the official Ubuntu 18.04 image, I found a very inconvenient error related
> to OpenJPA using the wrong entity to access the database.
> When it happens, the following exception can be found in the log:
> {{org.apache.openjpa.persistence.ArgumentException : The given value "test"
> cannot be converted into an identity for "class EntityB". The value is the
> wrong type (java.lang.String)}}{{ using the wrong entity to store information
> inside}}
> The major problem with this code is that the actual method is trying to
> access the entity EntityA instead of EntityB. The conversion error occurs
> because the ID for EntityB is a composite value while the ID for EntityA is
> indeed a string.
> Given that, I tried to trace the issue using a remote debugger but, when I
> activate, the problem vanishes. It does not matter if the debugger is
> connected or not. Since it is not a critical application, I can workaround it
> by leaving the remote debugger enabled but it would be a real issue for
> production environment.
> The docker image I'm using as the base can be found in the Docker Hub with
> the name opencs/ubuntu-openjdk-8-headless.
> The application is a single WAR file with some EJBs, JPA entities, a few
> servlets and a few JSF pages. Almost all JPA entities have single primary
> keys but one of them have a composite key with 2 strings.
> Thanks in advance,
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2223) Incorrect JPA entity used when running under docker
[
https://issues.apache.org/jira/browse/TOMEE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16587880#comment-16587880
]
Romain Manni-Bucau commented on TOMEE-2223:
---
ou deploy an ear? Any chance you get duplicated classes in your classpath? Can
lead to that too.
> Incorrect JPA entity used when running under docker
> ---
>
> Key: TOMEE-2223
> URL: https://issues.apache.org/jira/browse/TOMEE-2223
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5
> Environment: * Docker version 17.12.1-ce, build 7390fc6;
> * Official Ubuntu 18.04 (x64) docker image with OpenJDK 8 installed;
> * apache-tomee-webprofile-7.0.5;
> * Apache Derby 10.14.2.0 (embedded);
>Reporter: Fabio Jun Takada Chino
>Priority: Minor
>
> While packing a very simple web application inside a docker container based
> on the official Ubuntu 18.04 image, I found a very inconvenient error related
> to OpenJPA using the wrong entity to access the database.
> When it happens, the following exception can be found in the log:
> {{org.apache.openjpa.persistence.ArgumentException : The given value "test"
> cannot be converted into an identity for "class EntityB". The value is the
> wrong type (java.lang.String)}}{{ using the wrong entity to store information
> inside}}
> The major problem with this code is that the actual method is trying to
> access the entity EntityA instead of EntityB. The conversion error occurs
> because the ID for EntityB is a composite value while the ID for EntityA is
> indeed a string.
> Given that, I tried to trace the issue using a remote debugger but, when I
> activate, the problem vanishes. It does not matter if the debugger is
> connected or not. Since it is not a critical application, I can workaround it
> by leaving the remote debugger enabled but it would be a real issue for
> production environment.
> The docker image I'm using as the base can be found in the Docker Hub with
> the name opencs/ubuntu-openjdk-8-headless.
> The application is a single WAR file with some EJBs, JPA entities, a few
> servlets and a few JSF pages. Almost all JPA entities have single primary
> keys but one of them have a composite key with 2 strings.
> Thanks in advance,
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2223) Incorrect JPA entity used when running under docker
[
https://issues.apache.org/jira/browse/TOMEE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16586940#comment-16586940
]
Romain Manni-Bucau commented on TOMEE-2223:
---
EJB dont use constructors until it is a CDI constructor so it is likely you
code is ignored and you end up on such an issue. Mobe your constructor code to
a postconstruct method and it should work.
> Incorrect JPA entity used when running under docker
> ---
>
> Key: TOMEE-2223
> URL: https://issues.apache.org/jira/browse/TOMEE-2223
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5
> Environment: * Docker version 17.12.1-ce, build 7390fc6;
> * Official Ubuntu 18.04 (x64) docker image with OpenJDK 8 installed;
> * apache-tomee-webprofile-7.0.5;
> * Apache Derby 10.14.2.0 (embedded);
>Reporter: Fabio Jun Takada Chino
>Priority: Minor
>
> While packing a very simple web application inside a docker container based
> on the official Ubuntu 18.04 image, I found a very inconvenient error related
> to OpenJPA using the wrong entity to access the database.
> When it happens, the following exception can be found in the log:
> {{org.apache.openjpa.persistence.ArgumentException : The given value "test"
> cannot be converted into an identity for "class EntityB". The value is the
> wrong type (java.lang.String)}}{{ using the wrong entity to store information
> inside}}
> The major problem with this code is that the actual method is trying to
> access the entity EntityA instead of EntityB. The conversion error occurs
> because the ID for EntityB is a composite value while the ID for EntityA is
> indeed a string.
> Given that, I tried to trace the issue using a remote debugger but, when I
> activate, the problem vanishes. It does not matter if the debugger is
> connected or not. Since it is not a critical application, I can workaround it
> by leaving the remote debugger enabled but it would be a real issue for
> production environment.
> The docker image I'm using as the base can be found in the Docker Hub with
> the name opencs/ubuntu-openjdk-8-headless.
> The application is a single WAR file with some EJBs, JPA entities, a few
> servlets and a few JSF pages. Almost all JPA entities have single primary
> keys but one of them have a composite key with 2 strings.
> Thanks in advance,
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2223) Incorrect JPA entity used when running under docker
[
https://issues.apache.org/jira/browse/TOMEE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16586391#comment-16586391
]
Romain Manni-Bucau commented on TOMEE-2223:
---
Hmm
maybe set the cavhe mode to none, ensure sql queries are logged to be able to
check cache is not used.
If it doesnt help you should try sharing a reproducer as a girhub maven project
with a failing unit test.
> Incorrect JPA entity used when running under docker
> ---
>
> Key: TOMEE-2223
> URL: https://issues.apache.org/jira/browse/TOMEE-2223
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5
> Environment: * Docker version 17.12.1-ce, build 7390fc6;
> * Official Ubuntu 18.04 (x64) docker image with OpenJDK 8 installed;
> * apache-tomee-webprofile-7.0.5;
> * Apache Derby 10.14.2.0 (embedded);
>Reporter: Fabio Jun Takada Chino
>Priority: Minor
>
> While packing a very simple web application inside a docker container based
> on the official Ubuntu 18.04 image, I found a very inconvenient error related
> to OpenJPA using the wrong entity to access the database.
> When it happens, the following exception can be found in the log:
> {{org.apache.openjpa.persistence.ArgumentException : The given value "test"
> cannot be converted into an identity for "class EntityB". The value is the
> wrong type (java.lang.String)}}{{ using the wrong entity to store information
> inside}}
> The major problem with this code is that the actual method is trying to
> access the entity EntityA instead of EntityB. The conversion error occurs
> because the ID for EntityB is a composite value while the ID for EntityA is
> indeed a string.
> Given that, I tried to trace the issue using a remote debugger but, when I
> activate, the problem vanishes. It does not matter if the debugger is
> connected or not. Since it is not a critical application, I can workaround it
> by leaving the remote debugger enabled but it would be a real issue for
> production environment.
> The docker image I'm using as the base can be found in the Docker Hub with
> the name opencs/ubuntu-openjdk-8-headless.
> The application is a single WAR file with some EJBs, JPA entities, a few
> servlets and a few JSF pages. Almost all JPA entities have single primary
> keys but one of them have a composite key with 2 strings.
> Thanks in advance,
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2223) Incorrect JPA entity used when running under docker
[
https://issues.apache.org/jira/browse/TOMEE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16584932#comment-16584932
]
Romain Manni-Bucau commented on TOMEE-2223:
---
Deactivating the cache can be a good test to do if you can
> Incorrect JPA entity used when running under docker
> ---
>
> Key: TOMEE-2223
> URL: https://issues.apache.org/jira/browse/TOMEE-2223
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5
> Environment: * Docker version 17.12.1-ce, build 7390fc6;
> * Official Ubuntu 18.04 (x64) docker image with OpenJDK 8 installed;
> * apache-tomee-webprofile-7.0.5;
> * Apache Derby 10.14.2.0 (embedded);
>Reporter: Fabio Jun Takada Chino
>Priority: Minor
>
> While packing a very simple web application inside a docker container based
> on the official Ubuntu 18.04 image, I found a very inconvenient error related
> to OpenJPA using the wrong entity to access the database.
> When it happens, the following exception can be found in the log:
> {{org.apache.openjpa.persistence.ArgumentException : The given value "test"
> cannot be converted into an identity for "class EntityB". The value is the
> wrong type (java.lang.String)}}{{ using the wrong entity to store information
> inside}}
> The major problem with this code is that the actual method is trying to
> access the entity EntityA instead of EntityB. The conversion error occurs
> because the ID for EntityB is a composite value while the ID for EntityA is
> indeed a string.
> Given that, I tried to trace the issue using a remote debugger but, when I
> activate, the problem vanishes. It does not matter if the debugger is
> connected or not. Since it is not a critical application, I can workaround it
> by leaving the remote debugger enabled but it would be a real issue for
> production environment.
> The docker image I'm using as the base can be found in the Docker Hub with
> the name opencs/ubuntu-openjdk-8-headless.
> The application is a single WAR file with some EJBs, JPA entities, a few
> servlets and a few JSF pages. Almost all JPA entities have single primary
> keys but one of them have a composite key with 2 strings.
> Thanks in advance,
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2143) AbstractOwbBean.destroy(..) hits NPE in MyFaces 2.2.12 when cleaning up a user's Session and related "ViewScopeBeanHolder"
[
https://issues.apache.org/jira/browse/TOMEE-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553811#comment-16553811
]
Romain Manni-Bucau commented on TOMEE-2143:
---
[~tandraschko] ear support requires to not overpass classloaders. Means to not
statt using a parent bean instead of the child flavor. Here it is what is
happening I think. So either the holder is not correctly looked up or some
webapp code is in the lib part of the ear and injects a bean which should be
from the webapp (we prevent it in tomee to keep it sane and align on ear
classloading rules, alternatives were all worse :()
> AbstractOwbBean.destroy(..) hits NPE in MyFaces 2.2.12 when cleaning up a
> user's Session and related "ViewScopeBeanHolder"
> ---
>
> Key: TOMEE-2143
> URL: https://issues.apache.org/jira/browse/TOMEE-2143
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.3, 7.0.4, 7.0.5
> Environment: TomEE > 7.0.3 (plus)
> MyFaces 2.2.12, Omnifaces 2.6.8
> Shiro 1.4.0
> Java 1.8.0-U171 (OpenJDK / Oracle)
> OS: MacOS 10.13.x, Windows 10 (1607, 1709, 1803)
>Reporter: Martin Wiesner
>Priority: Major
>
> In an *EAR*-bundled application with several EJB jars and two WAR files, when
> I logout from my JSF-application via this piece of code here:
> {code:java}
> public void logout() throws IOException {
> SecurityUtils.getSubject().logout();
> Faces.invalidateSession();
> Faces.redirect("login.xhtml");
> }
> {code}
> The moment the user session is invalidated, the redirect to the login screen
> is triggered sucessfully. However, I encounter the following stack trace
> within my standalone installation of TomEE plus (taken from catalina.out):
> {code:java}
> [http-nio-8080-exec-8] org.apache.webbeans.component.AbstractOwbBean.destroy
> Exception thrown while destroying bean instance : [ViewScopeBeanHolder,
> WebBeansType:MANAGED, Name:null, API
> Types:[org.apache.myfaces.cdi.view.ViewScopeBeanHolder,java.lang.Object,java.io.Serializable],
> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]]
> java.lang.NullPointerException
> at
> org.apache.myfaces.cdi.view.ViewScopeContextImpl.destroyAllActive(ViewScopeContextImpl.java:229)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextImpl.destroyAllActive(ViewScopeContextImpl.java:223)
> at
> org.apache.myfaces.cdi.view.ViewScopeBeanHolder.destroyBeansOnPreDestroy(ViewScopeBeanHolder.java:221)
> 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.webbeans.intercept.LifecycleInterceptorInvocationContext.proceed(LifecycleInterceptorInvocationContext.java:103)
> at
> org.apache.webbeans.portable.InjectionTargetImpl.preDestroy(InjectionTargetImpl.java:352)
> at
> org.apache.webbeans.component.AbstractOwbBean.destroy(AbstractOwbBean.java:179)
> at
> org.apache.webbeans.context.AbstractContext.destroyInstance(AbstractContext.java:206)
> at
> org.apache.webbeans.context.AbstractContext.destroyInstance(AbstractContext.java:192)
> at
> org.apache.webbeans.context.AbstractContext.destroy(AbstractContext.java:218)
> at
> org.apache.webbeans.web.context.WebContextsService.destroyRequestContext(WebContextsService.java:408)
> at
> org.apache.openejb.cdi.CdiAppContextsService.destroyRequestContext(CdiAppContextsService.java:113)
> at
> org.apache.webbeans.web.context.WebContextsService.endContext(WebContextsService.java:223)
> at
> org.apache.openejb.server.httpd.BeginWebBeansListener.requestDestroyed(BeginWebBeansListener.java:99)
> at
> org.apache.catalina.core.StandardContext.fireRequestDestroyEvent(StandardContext.java:5974)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80)
> at
> org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCapturer.invoke(OpenEJBSecurityListener.java:97)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799)
> at
>
[jira] [Commented] (TOMEE-2200) defineClass used which is not supported by java 11
[
https://issues.apache.org/jira/browse/TOMEE-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16543765#comment-16543765
]
Romain Manni-Bucau commented on TOMEE-2200:
---
OWB runs on last EA but java11 will still change since annoucements should
break what is usable today. That said we can use the same hacks in between.
> defineClass used which is not supported by java 11
> --
>
> Key: TOMEE-2200
> URL: https://issues.apache.org/jira/browse/TOMEE-2200
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5
> Environment: ./catalina.sh version
> Using CATALINA_BASE: /opt/tomee705
> Using CATALINA_HOME: /opt/tomee705
> Using CATALINA_TMPDIR: /opt/tomee705/temp
> Using JRE_HOME:/opt/jdk-11
> Using CLASSPATH:
> /opt/tomee705/bin/bootstrap.jar:/opt/tomee705/bin/tomcat-juli.jar
> NOTE: Picked up JDK_JAVA_OPTIONS:
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.io=ALL-UNNAMED
> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
> Server version: Apache Tomcat/8.5.32
> Server built: Jun 20 2018 19:50:35 UTC
> Server number: 8.5.32.0
> OS Name:Linux
> OS Version: 3.10.0-229.el7.x86_64
> Architecture: amd64
> JVM Version:11-ea+21
> JVM Vendor: Oracle Corporation
>Reporter: Donald Kwakkel
>Assignee: Jonathan Gallimore
>Priority: Critical
>
> Not sure if tomee will support java 11, but with latest java 11 version it is
> not possible to start tomee:
> {code:java}
> SEVERE: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/home]]
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:629)
> at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1839)
> at
> Criticaljava.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.openejb.util.proxy.LocalBeanProxyFactory$Unsafe
> at
> org.apache.openejb.util.proxy.LocalBeanProxyFactory.createProxy(LocalBeanProxyFactory.java:137)
> at
> org.apache.openejb.util.proxy.LocalBeanProxyFactory.createProxy(LocalBeanProxyFactory.java:147)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.eagerInitOfLocalBeanProxies(TomcatWebAppBuilder.java:1563)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1309)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1125)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5154)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> ... 10 more
> {code}
> Reason is that defineClass is used which is no longer supported with java 11
> (at least here, maybe also on other places):
> container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java:
> return Unsafe.defineClass(cl, classToProxy, proxyName, proxyBytes);
> Same issue has openwebbeans: https://issues.apache.org/jira/browse/OWB-1248
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2200) defineClass used which is not supported by java 11
[
https://issues.apache.org/jira/browse/TOMEE-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16541536#comment-16541536
]
Romain Manni-Bucau commented on TOMEE-2200:
---
+ CXF
> defineClass used which is not supported by java 11
> --
>
> Key: TOMEE-2200
> URL: https://issues.apache.org/jira/browse/TOMEE-2200
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.5
> Environment: ./catalina.sh version
> Using CATALINA_BASE: /opt/tomee705
> Using CATALINA_HOME: /opt/tomee705
> Using CATALINA_TMPDIR: /opt/tomee705/temp
> Using JRE_HOME:/opt/jdk-11
> Using CLASSPATH:
> /opt/tomee705/bin/bootstrap.jar:/opt/tomee705/bin/tomcat-juli.jar
> NOTE: Picked up JDK_JAVA_OPTIONS:
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.io=ALL-UNNAMED
> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
> Server version: Apache Tomcat/8.5.32
> Server built: Jun 20 2018 19:50:35 UTC
> Server number: 8.5.32.0
> OS Name:Linux
> OS Version: 3.10.0-229.el7.x86_64
> Architecture: amd64
> JVM Version:11-ea+21
> JVM Vendor: Oracle Corporation
>Reporter: Donald Kwakkel
>Assignee: Jonathan Gallimore
>Priority: Critical
>
> Not sure if tomee will support java 11, but with latest java 11 version it is
> not possible to start tomee:
> {code:java}
> SEVERE: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/home]]
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:629)
> at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1839)
> at
> Criticaljava.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.openejb.util.proxy.LocalBeanProxyFactory$Unsafe
> at
> org.apache.openejb.util.proxy.LocalBeanProxyFactory.createProxy(LocalBeanProxyFactory.java:137)
> at
> org.apache.openejb.util.proxy.LocalBeanProxyFactory.createProxy(LocalBeanProxyFactory.java:147)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.eagerInitOfLocalBeanProxies(TomcatWebAppBuilder.java:1563)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1309)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1125)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5154)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> ... 10 more
> {code}
> Reason is that defineClass is used which is no longer supported with java 11
> (at least here, maybe also on other places):
> container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java:
> return Unsafe.defineClass(cl, classToProxy, proxyName, proxyBytes);
> Same issue has openwebbeans. Will log a ticket there and provide link here.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-1912) Enable JACC for Servlet
[
https://issues.apache.org/jira/browse/TOMEE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16535889#comment-16535889
]
Romain Manni-Bucau commented on TOMEE-1912:
---
Nothing AFAIK. No strong request too from userland. Bit feel free to do a pr,
we have the wzb.xml model in mem already so sounds doable even if not requested.
> Enable JACC for Servlet
> ---
>
> Key: TOMEE-1912
> URL: https://issues.apache.org/jira/browse/TOMEE-1912
> Project: TomEE
> Issue Type: New Feature
>Affects Versions: 7.0.1
>Reporter: Arjan Tijms
>Priority: Major
> Labels: security
>
> Currently JACC is only enabled for the EJB container in TomEE, but not for
> the Servlet container.
> Practically this means that for the EJB container permissions are collected
> and put into the {{PolicyConfiguration}} and that for access decisions for
> protected EJB beans the {{Policy}} is called. For the Servlet container
> neither happens.
> I would like to request to enable JACC for the Servlet container as well.
> As Geronimo implemented this earlier for Tomcat, it may be possible to look
> at how Geronimo did this (especially the web.xml constraints to
> {{Permission}} collection transformation is not exactly trivial and would be
> beneficial if it could be re-used from Geronimo).
> The Tomcat community itself also demonstrated a mild interest in JACC (very
> small interest perhaps, but it appeared on their roadmap for consideration a
> couple of times), so perhaps some coordination with Mark is possible.
> See also a discussion about this on the [TomEE mailing
> list|http://tomee-openejb.979440.n4.nabble.com/How-can-I-enable-JACC-in-TomEE-td4673113.html].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2025) Tomee's mail API is not JavaEE7 compatible
[
https://issues.apache.org/jira/browse/TOMEE-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522398#comment-16522398
]
Romain Manni-Bucau commented on TOMEE-2025:
---
[~gerdogdu] did we upgrade? dont think so
> Tomee's mail API is not JavaEE7 compatible
> --
>
> Key: TOMEE-2025
> URL: https://issues.apache.org/jira/browse/TOMEE-2025
> Project: TomEE
> Issue Type: Dependency upgrade
>Affects Versions: 7.0.3, 7.0.4
>Reporter: Svetlin Zarev
>Priority: Trivial
>
> According to the JEE7 specification, the mail API in EE7 must be version 1.5
> [1]:
> {code}
> The Java EE 7 platform requires JavaMail 1.5.
> {code}
> But TomEE comes with version 1.4:
> {code}
> Bundle-Name: Geronimo JavaMail 1.4
> ...
> Specification-Version: 1.4
> {code}
> [1] https://docs.oracle.com/javaee/7/tutorial/overview007.htm#BNACS
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2024) Misleading log entries
[
https://issues.apache.org/jira/browse/TOMEE-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522395#comment-16522395
]
Romain Manni-Bucau commented on TOMEE-2024:
---
[~gerdogdu] we should probably rework the logs in that area to be more explicit
and easier to understand, for now if you don't know the spec it is hard to
follow. A simple RESOURCE_LOCAL without datasource unit is a pain for a lot of
users so tempted to keep it.
> Misleading log entries
> --
>
> Key: TOMEE-2024
> URL: https://issues.apache.org/jira/browse/TOMEE-2024
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.3, 7.0.4
>Reporter: Svetlin Zarev
>Priority: Minor
>
> Assembler:1420-1454:
> {code}
> final String jtaWithJavaAndSlash =
> replaceJavaAndSlash(unit.getJtaDataSource());
> for (final String potentialName : asList(prefix +
> jtaWithJavaAndSlash, originalJtaDataSource, jtaWithJavaAndSlash)) {
> if(potentialName == null) {
> // If unit.getJtaDataSource() is null, one of the
> potentialName is also null.
> continue;
> }
> final ResourceInfo jtaInfo =
> configFactory.getResourceInfo(potentialName);
> if (jtaInfo != null) {
> if
> (!"false".equalsIgnoreCase(jtaInfo.properties.getProperty("JtaManaged")) //
> don't test true since it can be missing
> && (jtaInfo.types.contains("DataSource") ||
> jtaInfo.types.contains(DataSource.class.getName( {
> jtaDataSourceId = jtaInfo.id;
> break;
> } else {
> ->logger.warning("Found matching datasource: " +
> jtaInfo.id + " but this one is not a JTA datasource");
> }
> }
> }
> final String nonJtaWithJavaAndSlash =
> replaceJavaAndSlash(unit.getNonJtaDataSource());
> for (final String potentialName : asList(prefix +
> nonJtaWithJavaAndSlash, originalNonJtaDataSource, nonJtaWithJavaAndSlash)) {
> if(potentialName == null) {
> // If unit.getNonJtaDataSource() is null, one of the
> potentialName is also null.
> continue;
> }
> final ResourceInfo info =
> configFactory.getResourceInfo(potentialName);
> if (info != null) {
> if
> (!"true".equalsIgnoreCase(info.properties.getProperty("JtaManaged"))
> && (info.types.contains("DataSource") ||
> info.types.contains(DataSource.class.getName( {
> nonJtaDataSourceId = info.id;
> break;
> } else {
> ->logger.warning("Found matching datasource: " +
> info.id + " but this one is a JTA datasource");
> }
> }
> }
> {code}
> The two warnings are very misleading, because it prints that my JTA
> data-source is NON JTA one, and my non-jta is jta data-source when my service
> provider does not have "javax.sql.DataSource" in the "types" property.
> Also IMO when I explicitly set the service provider it should not matter what
> "types" it has in the service-jar.xml.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2197) openejb.xml does not work
[ https://issues.apache.org/jira/browse/TOMEE-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522394#comment-16522394 ] Romain Manni-Bucau commented on TOMEE-2197: --- You have the loaded model in ConfigurationFactory right? so just check and throw the exception in the ConfigurationFactory probably. Avoids to require to change the code in 3 locations. > openejb.xml does not work > -- > > Key: TOMEE-2197 > URL: https://issues.apache.org/jira/browse/TOMEE-2197 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Minor > Fix For: 8.0.0, 7.0.5 > > > When declaring a deployment in openejb.xml or tomee.xml we scan > sections. > This contains a file= and a jar= attribute. > The jar= does not work because it later gets overridden by the (often empty) > file attribute. > WORKAROUND: just use the file= attribute and be done > Should be fixed nonetheless. And should issue a warning if both attributes > are used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2175) Update to Tomcat 8.5.28
[ https://issues.apache.org/jira/browse/TOMEE-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522391#comment-16522391 ] Romain Manni-Bucau commented on TOMEE-2175: --- [~gerdogdu]yes, we tend to do it when we actually do the change once an original ticket is created > Update to Tomcat 8.5.28 > --- > > Key: TOMEE-2175 > URL: https://issues.apache.org/jira/browse/TOMEE-2175 > Project: TomEE > Issue Type: Dependency upgrade >Affects Versions: 7.0.4 >Reporter: Jonathan Gallimore >Assignee: Jonathan Gallimore >Priority: Major > Fix For: 7.0.5 > > > Update to Tomcat 8.5.28 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2175) Update to Tomcat 8.5.28
[ https://issues.apache.org/jira/browse/TOMEE-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522172#comment-16522172 ] Romain Manni-Bucau commented on TOMEE-2175: --- [~gerdogdu] a new one is just out and we will reuse this ticket for this upgrade (to have a correct changelog for end users) so re-upgrade and close > Update to Tomcat 8.5.28 > --- > > Key: TOMEE-2175 > URL: https://issues.apache.org/jira/browse/TOMEE-2175 > Project: TomEE > Issue Type: Dependency upgrade >Affects Versions: 7.0.4 >Reporter: Jonathan Gallimore >Assignee: Jonathan Gallimore >Priority: Major > Fix For: 7.0.5 > > > Update to Tomcat 8.5.28 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2197) openejb.xml does not work
[ https://issues.apache.org/jira/browse/TOMEE-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522171#comment-16522171 ] Romain Manni-Bucau commented on TOMEE-2197: --- I'd check in ConfigurationFactory. Rephrased the parser is not the right place cause we have 3 or 4 parsers for that model and none validates this so better to validates it only one. Fail == throw an exception > openejb.xml does not work > -- > > Key: TOMEE-2197 > URL: https://issues.apache.org/jira/browse/TOMEE-2197 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Minor > Fix For: 8.0.0, 7.0.5 > > > When declaring a deployment in openejb.xml or tomee.xml we scan > sections. > This contains a file= and a jar= attribute. > The jar= does not work because it later gets overridden by the (often empty) > file attribute. > WORKAROUND: just use the file= attribute and be done > Should be fixed nonetheless. And should issue a warning if both attributes > are used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TOMEE-2181) Problem with KeyStore.load after upgrading from 7.0.3 to 7.0.4
[ https://issues.apache.org/jira/browse/TOMEE-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved TOMEE-2181. --- Resolution: Workaround > Problem with KeyStore.load after upgrading from 7.0.3 to 7.0.4 > -- > > Key: TOMEE-2181 > URL: https://issues.apache.org/jira/browse/TOMEE-2181 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 >Reporter: Felipe Jaekel >Priority: Major > Attachments: jaybird-full-2.2.11.jar, > mysql-connector-java-5.1.40-bin.jar, tomee.xml > > > I have a webapp where users can upload a PKCS12 file to digital sign PDF > files. > > After I upgraded from 7.0.3 to 7.0.4, when I try to load the PKCS12 file I'm > getting a _java.security.UnrecoverableKeyException: failed to decrypt safe > contents entry: javax.crypto.BadPaddingException: pad block corrupted_ > > This problem doesn't happen with a plain Tomcat 8.5.20 install, so do I need > additional config for TomEE 7.0.4 or is it a bug? > > Sample project to reproduce the issue: > [github|[https://github.com/fkjaekel/KeyStoreLoad.git|http://example.com/]] > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2183) org.apache.commons.codec filtered by the classloader but not provided by TomEE WebProfile
[
https://issues.apache.org/jira/browse/TOMEE-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522169#comment-16522169
]
Romain Manni-Bucau commented on TOMEE-2183:
---
[~gerdogdu]we need in some distro (plus) but not all (webprofile).
URLClassLoaderFirst should be made conditional in that regard (already the case
for soap IIRC)
> org.apache.commons.codec filtered by the classloader but not provided by
> TomEE WebProfile
> -
>
> Key: TOMEE-2183
> URL: https://issues.apache.org/jira/browse/TOMEE-2183
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.4
>Reporter: Violeta Georgieva
>Assignee: Jonathan Gallimore
>Priority: Major
>
> Hi,
>
> I have an EAR file with "lib" folder that contains "commons-codec" and a WAR
> file that uses the libraries located in the "lib" folder. I do not have
> issues with the other libraries in that folder but with "commons-codec" I
> receive the exception below.
>
> I'm using TomEE 7.0.4 WebProfile and in that distribution there is no
> "commons-codec" provided by TomEE itself because of this I'm providing it
> with the EAR file.
>
> While debugging I saw that "org.apache.commons.codec" is intentionally
> filtered by the classloader
>
> [https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/util/classloader/URLClassLoaderFirst.java#L305]
>
> How it is supposed to provide this library so that my application can use it?
>
> Thanks,
> Violeta
>
> {code}
> java.lang.ClassNotFoundException: org.apache.commons.codec.binary.Base64
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
>
> org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:208)
>
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2163) Why was an old version of xalan.jar added to TomEE Plus 7.0.4.
[ https://issues.apache.org/jira/browse/TOMEE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522168#comment-16522168 ] Romain Manni-Bucau commented on TOMEE-2163: --- [~gerdogdu]yes, there are some duplicates IIRC, long story short jstl needs it. Proposal was to update jstl to use optionally xalan but nobody tackled it so we need xalan and harness it with jsp/jstl cases. > Why was an old version of xalan.jar added to TomEE Plus 7.0.4. > --- > > Key: TOMEE-2163 > URL: https://issues.apache.org/jira/browse/TOMEE-2163 > Project: TomEE > Issue Type: Wish > Components: TomEE Build >Affects Versions: 7.0.4 >Reporter: chris palchak >Priority: Major > > This causes problems because it does not support certain features like > blocking external DTDs. Deleting the jar file from the lib directory fixes > the problem. I see there was an issue to add it but no detail. It seems like > something that should be included in war files when needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2197) openejb.xml does not work
[ https://issues.apache.org/jira/browse/TOMEE-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521977#comment-16521977 ] Romain Manni-Bucau commented on TOMEE-2197: --- Fail? Not in the parser though but in the deployer to ensure it is the same for all xml parsers and properties syntax > openejb.xml does not work > -- > > Key: TOMEE-2197 > URL: https://issues.apache.org/jira/browse/TOMEE-2197 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Minor > Fix For: 8.0.0, 7.0.5 > > > When declaring a deployment in openejb.xml or tomee.xml we scan > sections. > This contains a file= and a jar= attribute. > The jar= does not work because it later gets overridden by the (often empty) > file attribute. > WORKAROUND: just use the file= attribute and be done > Should be fixed nonetheless. And should issue a warning if both attributes > are used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2198) OpenSAML packaging incomplete/broken
[ https://issues.apache.org/jira/browse/TOMEE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521908#comment-16521908 ] Romain Manni-Bucau commented on TOMEE-2198: --- Major is fine since it is a wrong packaging of one of our disto. > OpenSAML packaging incomplete/broken > > > Key: TOMEE-2198 > URL: https://issues.apache.org/jira/browse/TOMEE-2198 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 >Reporter: Fabian Richter >Priority: Major > > When I try to initialize OpenSAML in TomEE 7.0.4 with > InitializationService.initialize(); I get > > java.lang.ClassNotFoundException: com.google.common.base.Function > java.net.URLClassLoader.findClass(URLClassLoader.java:381) > java.lang.ClassLoader.loadClass(ClassLoader.java:424) > java.lang.ClassLoader.loadClass(ClassLoader.java:357) > > net.shibboleth.utilities.java.support.xml.AttributeSupport.getAttributeValueAsQName(AttributeSupport.java:334) > > org.opensaml.core.xml.config.XMLConfigurator.initializeObjectProviders(XMLConfigurator.java:231) > > org.opensaml.core.xml.config.XMLConfigurator.load(XMLConfigurator.java:203) > > org.opensaml.core.xml.config.XMLConfigurator.load(XMLConfigurator.java:188) > > org.opensaml.core.xml.config.XMLConfigurator.load(XMLConfigurator.java:162) > > org.opensaml.core.xml.config.AbstractXMLObjectProviderInitializer.init(AbstractXMLObjectProviderInitializer.java:52) > > org.opensaml.core.xml.config.XMLObjectProviderInitializer.init(XMLObjectProviderInitializer.java:45) > > org.opensaml.core.config.InitializationService.initialize(InitializationService.java:56) > > As soon as I add guava-18.0.jar to TomEE/lib it works. > After some discussion on the ML it turned out that "java-support.jar" which > packages the shibboleth SSO implementation is the culprit and should have > been excluded from the TomEE plus distribution alongside guava which was > intentionally left out due to it "breaking too many apps" (quote Romain) > Solution proposal: Why not exclude OpenSAML completely from TomEE as it is > currently not working without manually adding or removing jars from /lib/ > folder? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2150) Tomee 7.0.4 issue with CDI interceptor and WebServiceContext resource injection
[
https://issues.apache.org/jira/browse/TOMEE-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519042#comment-16519042
]
Romain Manni-Bucau commented on TOMEE-2150:
---
[~gerdogdu] we can add this kind of test but please don't use EJBContainer,
rather an application composer test which avoids all the scanning which is not
that great in our internal modules cause it is easy to get side effects. Also
note that this test passes on 7.0.4 so this likely doesn't reproduce the issue.
> Tomee 7.0.4 issue with CDI interceptor and WebServiceContext resource
> injection
>
>
> Key: TOMEE-2150
> URL: https://issues.apache.org/jira/browse/TOMEE-2150
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.4
>Reporter: François Courtault
>Priority: Critical
> Attachments: WebServiceWithAnCdiInterceptorTest.java,
> reproduction_problem.zip
>
>
> I have defined an annotation like below:
> @Inherited
> @InterceptorBinding
> @Target({ElementType.METHOD, ElementType.TYPE})
> @Retention(RetentionPolicy.RUNTIME)
> public @interface MyInterceptor {
> @NonBinding
> String level() default "INFO";
> }
> Then, I have written a class like this:
> @MyInterceptor
> @Interceptor
> public class MyInterceptor {
> private Class intercepted;
> @AroundInvoke
> public Object myMethod(final InvocationContext ctx) throws Exception {
> .
> }
> }
> In my POJO, webservice endpoint, I have:
> @WebService(name = "MyManager", targetNamespace ="http://com.test/wsdl;,
> serviceName = "MyManagerService")
> @MyInterceptor
> public class MyManager implements IMyManager {
> @resource
> private WebServiceContext wsc; //=>=> ALWAYS null on TomEE 7.0.4!!!
>
> }
> }
> That's the test case I built which doesn't work on TomEE 7.0.4 but works on
> Glassfish 4.1.2/5.0, Weblogic Server 12.2.1.3 and Wildfly 10.0.1/11.0.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2150) Tomee 7.0.4 issue with CDI interceptor and WebServiceContext resource injection
[
https://issues.apache.org/jira/browse/TOMEE-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518973#comment-16518973
]
Romain Manni-Bucau commented on TOMEE-2150:
---
[~gerdogdu] maybe run the same test on 7.0.4 which is known as affected. We
upgraded cxf so they can have fixed it but we didnt do anything to solve it.
> Tomee 7.0.4 issue with CDI interceptor and WebServiceContext resource
> injection
>
>
> Key: TOMEE-2150
> URL: https://issues.apache.org/jira/browse/TOMEE-2150
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.4
>Reporter: François Courtault
>Priority: Critical
> Attachments: reproduction_problem.zip
>
>
> I have defined an annotation like below:
> @Inherited
> @InterceptorBinding
> @Target({ElementType.METHOD, ElementType.TYPE})
> @Retention(RetentionPolicy.RUNTIME)
> public @interface MyInterceptor {
> @NonBinding
> String level() default "INFO";
> }
> Then, I have written a class like this:
> @MyInterceptor
> @Interceptor
> public class MyInterceptor {
> private Class intercepted;
> @AroundInvoke
> public Object myMethod(final InvocationContext ctx) throws Exception {
> .
> }
> }
> In my POJO, webservice endpoint, I have:
> @WebService(name = "MyManager", targetNamespace ="http://com.test/wsdl;,
> serviceName = "MyManagerService")
> @MyInterceptor
> public class MyManager implements IMyManager {
> @resource
> private WebServiceContext wsc; //=>=> ALWAYS null on TomEE 7.0.4!!!
>
> }
> }
> That's the test case I built which doesn't work on TomEE 7.0.4 but works on
> Glassfish 4.1.2/5.0, Weblogic Server 12.2.1.3 and Wildfly 10.0.1/11.0.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TOMEE-2179) tomcat 9.0.8
[ https://issues.apache.org/jira/browse/TOMEE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated TOMEE-2179: -- Summary: tomcat 9.0.8 (was: tomcat 9.0.6) > tomcat 9.0.8 > > > Key: TOMEE-2179 > URL: https://issues.apache.org/jira/browse/TOMEE-2179 > Project: TomEE > Issue Type: Dependency upgrade >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 8.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TOMEE-2184) MyFaces 2.3.1
[ https://issues.apache.org/jira/browse/TOMEE-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated TOMEE-2184: -- Summary: MyFaces 2.3.1 (was: MyFaces 2.3.0) > MyFaces 2.3.1 > - > > Key: TOMEE-2184 > URL: https://issues.apache.org/jira/browse/TOMEE-2184 > Project: TomEE > Issue Type: Dependency upgrade >Affects Versions: 8.0.0 >Reporter: Jean-Louis MONTEIRO >Assignee: Jean-Louis MONTEIRO >Priority: Major > Labels: pull-request-available > Fix For: 8.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2189) Allow for custom properties in application context.xml
[ https://issues.apache.org/jira/browse/TOMEE-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458628#comment-16458628 ] Romain Manni-Bucau commented on TOMEE-2189: --- Hi it sounds more like a tomcat issue. In tomee we already have some integration with dynamic properties using placeholders from system props (like tomcat) or the environment. We even have preconfigured templates for resources (like https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/resource/openshift/OpenshiftMySQLPropertiesProvider.java for openshift). Romain > Allow for custom properties in application context.xml > -- > > Key: TOMEE-2189 > URL: https://issues.apache.org/jira/browse/TOMEE-2189 > Project: TomEE > Issue Type: New Feature > Components: TomEE Core Server >Affects Versions: 7.0.4 > Environment: Docker, OpenShift instance. >Reporter: Clinton A Lester >Priority: Major > Labels: easyfix > > Apologies in advance if this is a Tomcat vs TomEE issue. Please direct this > appropriately if that is the case. > Issue: Currently we are unable to easily extend the DataSourceFactory class > to allow for additional custom properties in the context.xml. The reasoning > is mostly that the ALL_PROPERTIES is final. Currently to achieve this we have > override the > getObjectInstance() method and essentially copied and pasted most of the > method, only to add a small code snippet at the end to add addtional values > to the properties object that is passed in to createDataSource(). > Java class: > org.apache.tomcat.jdbc.pool.DataSourceFactory > > Use Case: > Background: Our builds and deployments run in OpenShift on a docker instance. > We have sourced the base image of TomEE which at build time is complied and a > image spun up and then our code is deployed. This base image is the same for > every service. In an effort to keep uniformity, we have need to specify > multiple data sources in context.xml as well as securely provide the > username, password, and database urls. > > Current approach: Rather than list the username, password, and url in the > context.xml which is insecure, we provide them in the form of OpenShift > "secrets" which are only accessible through the environment variable in > OpenShift at deploy time. To do so we have extended DataSourceFactory to read > them from files that we create and add them to the poolProperties. To take > this further, for multiple datasources, we need multiple files. This requires > us to pass in the file names at startup. To accomplish this we override > getObjectInstace() as mentioned before. > > The request is to mitigate the need to copy/paste code by making the > properties configurable or extend friendly. > > I have placed the priority as major, as we are vulnerable to constant patch > updates with new releases, since we have copy/pasted the method within our > extended class. > > Let me know if I can be more informative on our use case and why this feature > would be a benefit to others seeking a configurable and secure way to provide > credentials to the resources in TomEE server. > > Additionally I believe this change is small and simple enough, so I will > apply the corresponding tags if available. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2183) org.apache.commons.codec filtered by the classloader but not provided by TomEE WebProfile
[
https://issues.apache.org/jira/browse/TOMEE-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439289#comment-16439289
]
Romain Manni-Bucau commented on TOMEE-2183:
---
Hi Violeta,
The filter should request the container lib to be used first and if not found
fallback on the child loader.
You can use openejb.classloader.forced-load system prop to deactivate this
behavior too.
> org.apache.commons.codec filtered by the classloader but not provided by
> TomEE WebProfile
> -
>
> Key: TOMEE-2183
> URL: https://issues.apache.org/jira/browse/TOMEE-2183
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.4
>Reporter: Violeta Georgieva
>Priority: Major
>
> Hi,
>
> I have an EAR file with "lib" folder that contains "commons-codec" and a WAR
> file that uses the libraries located in the "lib" folder. I do not have
> issues with the other libraries in that folder but with "commons-codec" I
> receive the exception below.
>
> I'm using TomEE 7.0.4 WebProfile and in that distribution there is no
> "commons-codec" provided by TomEE itself because of this I'm providing it
> with the EAR file.
>
> While debugging I saw that "org.apache.commons.codec" is intentionally
> filtered by the classloader
>
> [https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/util/classloader/URLClassLoaderFirst.java#L305]
>
> How it is supposed to provide this library so that my application can use it?
>
> Thanks,
> Violeta
>
> {code}
> java.lang.ClassNotFoundException: org.apache.commons.codec.binary.Base64
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
>
> org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:208)
>
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2181) Problem with KeyStore.load after upgrading from 7.0.3 to 7.0.4
[ https://issues.apache.org/jira/browse/TOMEE-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416950#comment-16416950 ] Romain Manni-Bucau commented on TOMEE-2181: --- Hi Felipe, it only happens on tomee plus (not webprofile) with JMS activated cause of bouncycastle which is registered in position 2 by default. You can tune it to be later in the chain (org.apache.activemq.broker.BouncyCastlePosition = 8 for instance in conf/system.properties) and the JVM security provider will be taken and work as expected. Romain > Problem with KeyStore.load after upgrading from 7.0.3 to 7.0.4 > -- > > Key: TOMEE-2181 > URL: https://issues.apache.org/jira/browse/TOMEE-2181 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 >Reporter: Felipe Jaekel >Priority: Major > Attachments: jaybird-full-2.2.11.jar, > mysql-connector-java-5.1.40-bin.jar, tomee.xml > > > I have a webapp where users can upload a PKCS12 file to digital sign PDF > files. > > After I upgraded from 7.0.3 to 7.0.4, when I try to load the PKCS12 file I'm > getting a _java.security.UnrecoverableKeyException: failed to decrypt safe > contents entry: javax.crypto.BadPaddingException: pad block corrupted_ > > This problem doesn't happen with a plain Tomcat 8.5.20 install, so do I need > additional config for TomEE 7.0.4 or is it a bug? > > Sample project to reproduce the issue: > [github|[https://github.com/fkjaekel/KeyStoreLoad.git|http://example.com/]] > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2181) Problem with KeyStore.load after upgrading from 7.0.3 to 7.0.4
[ https://issues.apache.org/jira/browse/TOMEE-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415645#comment-16415645 ] Romain Manni-Bucau commented on TOMEE-2181: --- Tested the sample, works fine with tomee 7.0.4 > Problem with KeyStore.load after upgrading from 7.0.3 to 7.0.4 > -- > > Key: TOMEE-2181 > URL: https://issues.apache.org/jira/browse/TOMEE-2181 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 >Reporter: Felipe Jaekel >Priority: Major > > I have a webapp where users can upload a PKCS12 file to digital sign PDF > files. > > After I upgraded from 7.0.3 to 7.0.4, when I try to load the PKCS12 file I'm > getting a _java.security.UnrecoverableKeyException: failed to decrypt safe > contents entry: javax.crypto.BadPaddingException: pad block corrupted_ > > This problem doesn't happen with a plain Tomcat 8.5.20 install, so do I need > additional config for TomEE 7.0.4 or is it a bug? > > Sample project to reproduce the issue: > [github|[https://github.com/fkjaekel/KeyStoreLoad.git|http://example.com/]] > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TOMEE-2182) Arquillian Test Causes java.lang.IncompatibleClassChangeError
[ https://issues.apache.org/jira/browse/TOMEE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved TOMEE-2182. --- Resolution: Invalid Hi Gary, you use javaee-api 6 which is javaee 6 instead of org.apache.tomee:javaee-api:7.0-1 which goes with tomee 7 to be javaee 7. This is what the error says. Side note: javaee-api should be in scope provided and not compile > Arquillian Test Causes java.lang.IncompatibleClassChangeError > - > > Key: TOMEE-2182 > URL: https://issues.apache.org/jira/browse/TOMEE-2182 > Project: TomEE > Issue Type: Bug > Components: TomEE Arquillian Adapters >Affects Versions: 7.0.4 >Reporter: Gary Murphy >Priority: Major > > I am trying to create a very simple Arquillian test for EJBs using embedded > TomEE. I get the following when I try to run the test: > Caused by: java.lang.IncompatibleClassChangeError: Class > org.apache.webbeans.conversation.ConversationStorageBean does not implement > the requested interface javax.enterprise.inject.spi.BeanAttributes > I found an item on the forum to exclude cdi-api, which I attempted to do, but > that did not resolve the issue. > The code can be found on GitHub at: > https://github.com/hilbertglm/arquillian-example.git > I suspect it is an issue with versions or POM setup, but I am stuck at this > point. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TOMEE-2180) johnzon 1.1.7
[ https://issues.apache.org/jira/browse/TOMEE-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved TOMEE-2180. --- Resolution: Fixed > johnzon 1.1.7 > - > > Key: TOMEE-2180 > URL: https://issues.apache.org/jira/browse/TOMEE-2180 > Project: TomEE > Issue Type: Dependency upgrade >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 8.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2179) tomcat 9.0.6
Romain Manni-Bucau created TOMEE-2179: - Summary: tomcat 9.0.6 Key: TOMEE-2179 URL: https://issues.apache.org/jira/browse/TOMEE-2179 Project: TomEE Issue Type: Dependency upgrade Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 8.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2180) johnzon 1.1.7
Romain Manni-Bucau created TOMEE-2180: - Summary: johnzon 1.1.7 Key: TOMEE-2180 URL: https://issues.apache.org/jira/browse/TOMEE-2180 Project: TomEE Issue Type: Dependency upgrade Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 8.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TOMEE-2176) Arquillian test cannot be run in parallel
[
https://issues.apache.org/jira/browse/TOMEE-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated TOMEE-2176:
--
Issue Type: Improvement (was: Bug)
> Arquillian test cannot be run in parallel
> -
>
> Key: TOMEE-2176
> URL: https://issues.apache.org/jira/browse/TOMEE-2176
> Project: TomEE
> Issue Type: Improvement
> Components: TomEE Arquillian Adapters
>Affects Versions: 7.0.3
>Reporter: Thorsten Meinl
>Priority: Minor
>
> In order to speed up tests, I wanted to run them in parallel using Maven
> Surefire's parallel execution capabilities. But even when running every test
> class in its own forked VM tests were failing randomly, mostly due to missing
> files in the temporary container directory. The reason is that all temporary
> containers will use the same directory, which is
> {{dir = System.getProperty("java.io.tmpdir") + "/arquillian-apache-tomee"}}
> and/or
> {{appWorkingDir = System.getProperty("java.io.tmpdir") +
> "/arquillian-tomee-app-working-dir}}
> (see {{org.apache.openejb.arquillian.common.TomEEConfiguration}}).
> This means different processes running TomEE via Arquillian will interfere
> with each other, even completely independent process and even from different
> users.
> As a solution the above-mention directories must be created such that they
> are unique for the process, e.g. by using
> {{java.nio.Files.createTempDirectory}}.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TOMEE-2176) Arquillian test cannot be run in parallel
[
https://issues.apache.org/jira/browse/TOMEE-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated TOMEE-2176:
--
Priority: Minor (was: Major)
> Arquillian test cannot be run in parallel
> -
>
> Key: TOMEE-2176
> URL: https://issues.apache.org/jira/browse/TOMEE-2176
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Arquillian Adapters
>Affects Versions: 7.0.3
>Reporter: Thorsten Meinl
>Priority: Minor
>
> In order to speed up tests, I wanted to run them in parallel using Maven
> Surefire's parallel execution capabilities. But even when running every test
> class in its own forked VM tests were failing randomly, mostly due to missing
> files in the temporary container directory. The reason is that all temporary
> containers will use the same directory, which is
> {{dir = System.getProperty("java.io.tmpdir") + "/arquillian-apache-tomee"}}
> and/or
> {{appWorkingDir = System.getProperty("java.io.tmpdir") +
> "/arquillian-tomee-app-working-dir}}
> (see {{org.apache.openejb.arquillian.common.TomEEConfiguration}}).
> This means different processes running TomEE via Arquillian will interfere
> with each other, even completely independent process and even from different
> users.
> As a solution the above-mention directories must be created such that they
> are unique for the process, e.g. by using
> {{java.nio.Files.createTempDirectory}}.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (TOMEE-2174) Nested parameters prevent EJB interceptor matching
[ https://issues.apache.org/jira/browse/TOMEE-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved TOMEE-2174. --- Resolution: Fixed > Nested parameters prevent EJB interceptor matching > -- > > Key: TOMEE-2174 > URL: https://issues.apache.org/jira/browse/TOMEE-2174 > Project: TomEE > Issue Type: Task >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 8.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
