tomee-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Romain Manni-Bucau (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TOMEE-2058) Problem with persistence in application specifying a context path through sun-web.xml
Date Fri, 16 Jun 2017 07:57:02 GMT

    [ https://issues.apache.org/jira/browse/TOMEE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051543#comment-16051543
] 

Romain Manni-Bucau commented on TOMEE-2058:
-------------------------------------------

That's what I had in mind, tomcat mecanism uses its own way to deploy (1 context) and sun-web.xml
was deploying another context through openejb model. Since this is not a "feature" - this
entry was mainly used for embedded testing AFAIK - I don't think we have any strong expectations.
Now being said tomcat kind of enforced more for 8.x the way the context is deduced from the
deployment I'm not sure we'd want to go against tomcat.

You can configure the vendors descriptors we read through a system property and remove SUN
(glassfish) from the list to avoid the sun-web context. Think it is good enough.

Wdyt?

> Problem with persistence in application specifying a context path through sun-web.xml
> -------------------------------------------------------------------------------------
>
>                 Key: TOMEE-2058
>                 URL: https://issues.apache.org/jira/browse/TOMEE-2058
>             Project: TomEE
>          Issue Type: Bug
>          Components: TomEE Core Server
>    Affects Versions: 7.0.3
>            Reporter: Lazar Kirchev
>
> I am deploying a very simple application with JPA on TomEE Plume. 
> The application uses a sun-web.xml to specify an alternative context root. It defines
one entity (Person) and in a servlet creates an instance of this entity and tries to persist
it. 
> If the application is requested through the context root specified in sun-web.xml (http://localhost:8080/Test/TestServlet),
the persisting fails with the following exception:
> {code}
> java.lang.IllegalArgumentException: Object: my.test.entity.Person@1 is not a known Entity
type.
> 	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4226)
> 	at org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:507)
> 	at org.apache.openejb.persistence.JtaEntityManager.persist(JtaEntityManager.java:193)
> 	at my.test.TestServlet.doGet(TestServlet.java:28)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> 	at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:44)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> 	at org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCapturer.invoke(OpenEJBSecurityListener.java:97)
> 	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
> 	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
> 	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> 	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798)
> 	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434)
> 	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> 	at java.lang.Thread.run(Thread.java:807)
> {code}
> On the other hand, if the application is requested through the context path, defined
by the war name (http://localhost:8080/TestPersistence/TestServlet), the entity is successfully
persisted.
> You can reproduce the problem with the [application|https://github.com/lkirchev/Misc].
For the Data Source resource definition you could use:
> {code}
> <Resource id="myDS" type="DataSource">
>     JdbcDriver org.hsqldb.jdbcDriver
>     JdbcUrl jdbc:hsqldb:file:hsqldb
>     UserName sa
>     Password
> </Resource>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message