[jira] Commented: (GERONIMO-4543) EAR classloader not garbage collected
[ https://issues.apache.org/jira/browse/GERONIMO-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681311#action_12681311 ] Janko Heilgeist commented on GERONIMO-4543: --- Java6 says Please use CMSClassUnloadingEnabled in place of CMSPermGenSweepingEnabled in the future if it is started with -XX:+CMSPermGenSweepingEnabled so I stopped using this option recently. I'll admit that this report is not a major issue. I just discovered the leaks when I debugged an application. They haven't caused any real problems yet. EAR classloader not garbage collected - Key: GERONIMO-4543 URL: https://issues.apache.org/jira/browse/GERONIMO-4543 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Memory Leaks, transaction manager Affects Versions: 2.2 Reporter: Janko Heilgeist Priority: Blocker Fix For: 2.2 Attachments: ear-with-tx.tar.gz, privileged_currenttime.patch The TransactionTimer$CurrentTime thread inherits the AccessControlContext of the first EAR/WAR/EJB-jar that carries out a transaction. Thus, the particular EAR/WAR/EJB-jar's classloader is prevented from being GCed. See http://www.nabble.com/PermGen-space-issues-td22079768s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4543) EAR classloader not garbage collected
[
https://issues.apache.org/jira/browse/GERONIMO-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674936#action_12674936
]
Janko Heilgeist commented on GERONIMO-4543:
---
There is still another reference from CurrentTime to my EAR's classloader
through the inheritableThreadLocals field:
{code}
Java Local Reference (from
org.apache.geronimo.transaction.manager.transactiontimer$currentt...@0x2aaab1e8cd68)
exclude :
--
org.apache.geronimo.transaction.manager.transactiontimer$currentt...@0x2aaab1e8cd68
(164 bytes) (field inheritableThreadLocals:) exclude
-- java.lang.threadlocal$threadlocal...@0x2aaab2485938 (32 bytes) (field
table:) exclude
-- [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x2aaab2454dc0 (144 bytes)
(Element 1 of [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x2aaab2454dc0:)
exclude
-- java.lang.threadlocal$threadlocalmap$en...@0x2aaab2fe39e8 (56 bytes) (field
value:) exclude
--
org.apache.xbean.naming.context.writablecontext$nestedwritablecont...@0x2aaab055f088
(89 bytes) (field bindingsRef:) exclude
-- java.util.concurrent.atomic.atomicrefere...@0x2aaab2031940 (24 bytes)
(field value:) exclude
-- java.util.hash...@0x2aaab22a0040 (64 bytes) (field table:) exclude
-- [Ljava.util.HashMap$Entry;@0x2aaab2031c00 (144 bytes) (Element 3 of
[Ljava.util.HashMap$Entry;@0x2aaab2031c00:) exclude
-- java.util.hashmap$en...@0x2aaab20322d0 (44 bytes) (field value:) exclude
--
org.apache.xbean.naming.context.writablecontext$nestedwritablecont...@0x2aaab055f1a8
(89 bytes) (field contextFederation:) exclude
-- org.apache.xbean.naming.context.contextfederat...@0x2aaab0a133e8 (32 bytes)
(field federatedContextRef:) exclude
-- java.util.concurrent.atomic.atomicrefere...@0x2aaab2031a30 (24 bytes)
(field value:) exclude
-- java.util.collections$unmodifiable...@0x2aaab2031a48 (24 bytes) (field c:)
exclude
-- java.util.linkedhash...@0x2aaab2031a60 (24 bytes) (field map:) exclude
-- java.util.linkedhash...@0x2aaab1f2a660 (73 bytes) (field header:) exclude
-- java.util.linkedhashmap$en...@0x2aaab22a0140 (60 bytes) (field after:)
exclude
-- java.util.linkedhashmap$en...@0x2aaab22a0180 (60 bytes) (field key:) exclude
-- org.apache.xbean.naming.context.immutablecont...@0x2aaab1f2a918 (65 bytes)
(field absoluteIndex:) exclude
-- java.util.collections$unmodifiable...@0x2aaab2032600 (48 bytes) (field m:)
exclude
-- java.util.hash...@0x2aaab0a13568 (64 bytes) (field table:) exclude
-- [Ljava.util.HashMap$Entry;@0x2aaab2031d30 (144 bytes) (Element 15 of
[Ljava.util.HashMap$Entry;@0x2aaab2031d30:) exclude
-- java.util.hashmap$en...@0x2aaab2032690 (44 bytes) (field value:) exclude
-- org.apache.geronimo.naming.reference.handledelegaterefere...@0x2aaab1f2a6b0
(80 bytes) (field classLoader:) exclude
-- org.apache.geronimo.kernel.config.multiparentclassloa...@0x2aaab2fbc000
(156 bytes) exclude
{code}
I assume, that it is the inheritable component context from
org.apache.geronimo.naming.java.RootContext. But I can't find a way to fix
this...
EAR classloader not garbage collected
-
Key: GERONIMO-4543
URL: https://issues.apache.org/jira/browse/GERONIMO-4543
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: transaction manager
Affects Versions: 2.2
Reporter: Janko Heilgeist
Attachments: ear-with-tx.tar.gz, privileged_currenttime.patch
The TransactionTimer$CurrentTime thread inherits the AccessControlContext of
the first EAR/WAR/EJB-jar that carries out a transaction. Thus, the
particular EAR/WAR/EJB-jar's classloader is prevented from being GCed.
See http://www.nabble.com/PermGen-space-issues-td22079768s134.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4545) TomcatJAASRealm keeps reference to undeployed EAR/WAR's classloader
TomcatJAASRealm keeps reference to undeployed EAR/WAR's classloader
---
Key: GERONIMO-4545
URL: https://issues.apache.org/jira/browse/GERONIMO-4545
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.2
Reporter: Janko Heilgeist
Another issue where an undeployed WAR's classloader is not GCed.
{code}
-- org.apache.geronimo.tomcat.realm.tomcatjaasre...@0x2aaab10ab438 (180 bytes)
(field container:) exclude
-- org.apache.geronimo.tomcat.geronimostandardcont...@0x2aaab322d390 (749
bytes) (field parentClassLoader:) exclude
-- org.apache.geronimo.kernel.config.multiparentclassloa...@0x2aaab2e9b2e0
(156 bytes) (field parents:) exclude
-- [Ljava.lang.ClassLoader;@0x2aaab0b97958 (88 bytes) (Element 1 of
[Ljava.lang.ClassLoader;@0x2aaab0b97958:) exclude
--
org.apache.geronimo.kernel.config.childrenconfigurationclassloa...@0x2aaab05e8bc0
(115 bytes) (field parent:) exclude
-- org.apache.geronimo.kernel.config.multiparentclassloa...@0x2aaab2e9b230
(156 bytes) exclude
{code}
It looks to me like the TomcatJAASRealm (its name is DefaultJAASRealm) is a
standard realm that is used by all WARs without explicit configuration. Setting
the realm of a GeronimoStandardContext makes the context store a reference to
its realm AND makes the realm store a reference to the context (see
org.apache.catalina.core.ContainerBase#setRealm() which GeronimoStandardContext
inherits). Thus, the default realm's reference is always directed to the
context of the WAR deployed most recently. This reference keeps the context
from being GCed even if the corresponding WAR has been undeployed in the
meantime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4543) EAR classloader not garbage collected
[ https://issues.apache.org/jira/browse/GERONIMO-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675265#action_12675265 ] Janko Heilgeist commented on GERONIMO-4543: --- Hi Kevan, I've set my JAVA_OPTS to -XX:MaxPermSize=265m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled for some time now and never saw any OOM errors. But last Friday I must have accidentally reset the environment variable somehow without noticing it. On Monday I started seeing the OOM PermGen space errors immediately during first deployment and began investigating the cause. I didn't recognize the missing JAVA_OPTS and instead debugged the application with jmap/jhat. Thus, I noticed that the classes of my EAR never get GCed after undeploying and that got me hooked up on the issue. Shortly after, I switched back to the old JAVA_OPTS and everything worked again. But its just my own private Geronimo installation for development purposes that gets restarted a few times a day. So the OOM may be pushed back long enough to never occur. So much for the background. I currently just deploy/undeploy my app and don't actually drive it. I already noticed a few additional issues when I enable an included Quartz scheduled job and when I call my JUnitE2 test cases. For now, I've disabled them and focus just on getting the app GCed after a single deploy/undeploy. I also noticed that the PermGen space increases minimally (that is a few KB maybe) with each deploy/undeploy cycle. It's not a serious issue yet but I'll investigate it further if it continues. I've only seen the EAR's MultiParentClassLoader, its child WAR's MultiParentClassLoader, and an intermediate ChildConfigurationClassLoader not being GCed. SUN's Frank Kieviet describes a servlet in his blog, that repeatedly loads a class with its own classloader to force a PermGen space GC. Thus, the relevant classloaders should have been GCed if they had been eligible. EAR classloader not garbage collected - Key: GERONIMO-4543 URL: https://issues.apache.org/jira/browse/GERONIMO-4543 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Memory Leaks, transaction manager Affects Versions: 2.2 Reporter: Janko Heilgeist Priority: Blocker Fix For: 2.2 Attachments: ear-with-tx.tar.gz, privileged_currenttime.patch The TransactionTimer$CurrentTime thread inherits the AccessControlContext of the first EAR/WAR/EJB-jar that carries out a transaction. Thus, the particular EAR/WAR/EJB-jar's classloader is prevented from being GCed. See http://www.nabble.com/PermGen-space-issues-td22079768s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4543) EAR classloader not garbage collected
EAR classloader not garbage collected - Key: GERONIMO-4543 URL: https://issues.apache.org/jira/browse/GERONIMO-4543 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: transaction manager Affects Versions: 2.2 Reporter: Janko Heilgeist The TransactionTimer$CurrentTime thread inherits the AccessControlContext of the first EAR/WAR/EJB-jar that carries out a transaction. Thus, the particular EAR/WAR/EJB-jar's classloader is prevented from being GCed. See http://www.nabble.com/PermGen-space-issues-td22079768s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4543) EAR classloader not garbage collected
[
https://issues.apache.org/jira/browse/GERONIMO-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janko Heilgeist updated GERONIMO-4543:
--
Attachment: ear-with-tx.tar.gz
This EAR packages an EJB-jar and a WAR. The EJB exports an empty transactional
method which the WAR's servlet accesses during deployment. After
deploying/undeploying the EAR there are still live connections to the rootset:
{code}
Java Local Reference (from
org.apache.geronimo.transaction.manager.transactiontimer$currentt...@0x2aaab30aaed8)
exclude :
--
org.apache.geronimo.transaction.manager.transactiontimer$currentt...@0x2aaab30aaed8
(164 bytes) (field inheritedAccessControlContext:) exclude
-- java.security.accesscontrolcont...@0x2aaab30aafb0 (41 bytes) (field
context:) exclude
-- [Ljava.security.ProtectionDomain;@0x2aaab30aba00 (136 bytes) (Element 14 of
[Ljava.security.ProtectionDomain;@0x2aaab30aba00:) exclude
-- java.security.protectiondom...@0x2aaab30aba90 (50 bytes) (field
classloader:) exclude
-- org.apache.geronimo.kernel.config.multiparentclassloa...@0x2aaab2a376b8
(156 bytes) (field parents:) exclude
-- [Ljava.lang.ClassLoader;@0x2aaab3086ff0 (88 bytes) (Element 1 of
[Ljava.lang.ClassLoader;@0x2aaab3086ff0:) exclude
--
org.apache.geronimo.kernel.config.childrenconfigurationclassloa...@0x2aaab03bb338
(115 bytes) (field parent:) exclude
-- org.apache.geronimo.kernel.config.multiparentclassloa...@0x2aaab2a37608
(156 bytes) exclude
{code}
EAR classloader not garbage collected
-
Key: GERONIMO-4543
URL: https://issues.apache.org/jira/browse/GERONIMO-4543
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: transaction manager
Affects Versions: 2.2
Reporter: Janko Heilgeist
Attachments: ear-with-tx.tar.gz
The TransactionTimer$CurrentTime thread inherits the AccessControlContext of
the first EAR/WAR/EJB-jar that carries out a transaction. Thus, the
particular EAR/WAR/EJB-jar's classloader is prevented from being GCed.
See http://www.nabble.com/PermGen-space-issues-td22079768s134.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4543) EAR classloader not garbage collected
[ https://issues.apache.org/jira/browse/GERONIMO-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Janko Heilgeist updated GERONIMO-4543: -- Attachment: privileged_currenttime.patch This patch starts the CurrentTime thread in a privileged block to prevent it from inheriting the AccessControlContext of the current thread. EAR classloader not garbage collected - Key: GERONIMO-4543 URL: https://issues.apache.org/jira/browse/GERONIMO-4543 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.2 Reporter: Janko Heilgeist Attachments: ear-with-tx.tar.gz, privileged_currenttime.patch The TransactionTimer$CurrentTime thread inherits the AccessControlContext of the first EAR/WAR/EJB-jar that carries out a transaction. Thus, the particular EAR/WAR/EJB-jar's classloader is prevented from being GCed. See http://www.nabble.com/PermGen-space-issues-td22079768s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4528) Accessing a web service's WSDL throws a NPE
Accessing a web service's WSDL throws a NPE
---
Key: GERONIMO-4528
URL: https://issues.apache.org/jira/browse/GERONIMO-4528
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.2
Environment: 2.2-SNAPSHOT from SVN
Reporter: Janko Heilgeist
I've deployed a web service whose WSDL contains various schema imports without
schemaLocations:
{code:xml}xs:import
namespace=http://schemas.ggf.org/jsdl/2005/11/jsdl/{code}
These imports are resolved via a jax-ws-catalog.xml:
{code:xml}
public
publicId=http://schemas.ggf.org/jsdl/2005/11/jsdl;
uri=schemas/ext/jsdl/jsdl-1.0.xsd/
{code}
Accessing this WSDL via Geronimo with the ?wsdl-URL results in a
NullPointerException on Tomcat/Axis. The code tries to update the
schemaLocation to a server-local URL and, for this reason, retrieves the
imported schema. But it never checks for a valid return value. Jetty/CXF simply
copies these import-elements to the output WSDL without further ado.
{code}
2009-02-06 08:02:21,239 ERROR [Axis2WebServiceContainer] Exception occurred
while trying to invoke service method doService()
java.lang.NullPointerException
at
org.apache.geronimo.axis2.WSDLQueryHandler.updateSchemaImports(WSDLQueryHandler.java:244)
at
org.apache.geronimo.axis2.WSDLQueryHandler.updateSchemaImports(WSDLQueryHandler.java:252)
at
org.apache.geronimo.axis2.WSDLQueryHandler.updateSchemaImports(WSDLQueryHandler.java:268)
at
org.apache.geronimo.axis2.WSDLQueryHandler.updateDefinition(WSDLQueryHandler.java:230)
at
org.apache.geronimo.axis2.WSDLQueryHandler.updateDefinition(WSDLQueryHandler.java:219)
at
org.apache.geronimo.axis2.WSDLQueryHandler.init(WSDLQueryHandler.java:158)
at
org.apache.geronimo.axis2.WSDLQueryHandler.writeResponse(WSDLQueryHandler.java:108)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.processGETRequest(Axis2WebServiceContainer.java:366)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.doService2(Axis2WebServiceContainer.java:306)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.doService(Axis2WebServiceContainer.java:243)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.getWsdl(Axis2WebServiceContainer.java:190)
at
org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.handle(TomcatEJBWebServiceContext.java:213)
at
org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.invoke(TomcatEJBWebServiceContext.java:187)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
{code}
IMHO, both assemblies should first consult an existing jax-ws-catalog.xml to
resolve the schemaLocations. If this doesn't work they should copy the import
verbatim and let the client resolve via its own catalog.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665060#action_12665060
]
Janko Heilgeist commented on GERONIMO-4468:
---
David, I consulted the specification to refresh my memory on the
persistence.xml file. You're right, the specification says in section 6.2.6.1:
bq. The classes and/or jars that are named as part of a persistence unit must
be on the classpath; referencing them from the {{persistence.xml}} file does
not cause them to be placed on the classpath.
So, the mistake was mine: OpenJPA was correct to ignore the entities not on the
application classpath.
Regarding my use of the exclude-unlisted-classes property: I remembered its
usage like it is shown in example 4, section 6.2.1.8, that is specifying the
tag as {{exclude-unlisted-classes/}} sets the property to true; not
specifying the tag sets the property to false. Looking through the schema of
persistence.xml, I can see that it is actually used as
{{exclude-unlisted-classestrue/exclude-unlisted-classes}} and,
correspondingly, to set the property to false. The {{persistence.xml}} included
in my sample code didn't do, what I expected it to do.
My apologies for complicating the whole issue...
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
Assignee: Ivan
Attachments: Geronimo-4468-01.patch, Geronimo-4468.patch,
geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file
or directory whose META-INF directory contains the persistence.xml file is
termed the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying
it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
while on the console OpenJPA throws exceptions because it tries to resolve
the jar-file paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12665079#action_12665079
]
Janko Heilgeist commented on GERONIMO-4468:
---
I think could only be in the lib folder or defined as a module is to strict.
The location of a jar-file can be anywhere in the EAR as long as it is on the
classpath of the persistence unit (PU). What about jar files that are
referenced with a {{Class-Path:}} entry in the PU's {{MANIFEST.MF}}? I expect
that all the ways that a class could possibly end up on a PU's classpath are
already considered when the runtime classpath of a PU is determined.
If I understand David correctly, then it is sufficient to use the copy of the
PU's runtime classpath as it is already done.
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
Assignee: Ivan
Attachments: Geronimo-4468-01.patch, Geronimo-4468.patch,
geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file
or directory whose META-INF directory contains the persistence.xml file is
termed the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying
it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
while on the console OpenJPA throws exceptions because it tries to resolve
the jar-file paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12664122#action_12664122
]
Janko Heilgeist commented on GERONIMO-4468:
---
I tried the patch and it seems to solve the issue (partially?). The referenced
jar-files are now correctly resolved, but not all the entities inside of all
jars are discovered. (In the following traces I replaced the path of the
deployed EAR with $(EAR_ROOT) to make them more readable.)
1. EAR structure as before:
{noformat}
lib/my-pu-1.0-SNAPSHOT.jar
lib/my-entities1-1.0-SNAPSHOT.jar
my-entities2-1.0-SNAPSHOT.jar
{noformat}
During deployment only the entity in the jar on the same level as the
persistence root is discovered:
{noformat}
2 myPU TRACE [Thread-62] openjpa.MetaData - Scanning jar
$(EAR_ROOT)/lib/my-pu-1.0-SNAPSHOT.jar for persistent types.
2 myPU TRACE [Thread-62] openjpa.MetaData - Scanning jar file from URL
file:$(EAR_ROOT)/lib/my-entities1-1.0-SNAPSHOT.jar for persistent types.
2 myPU TRACE [Thread-62] openjpa.MetaData - Scanning jar file from URL
file:$(EAR_ROOT)/my-entities2-1.0-SNAPSHOT.jar for persistent types.
3 myPU TRACE [Thread-62] openjpa.MetaData - Scanning resource
META-INF/orm.xml for persistent types.
5 myPU TRACE [Thread-62] openjpa.MetaData - Scan of META-INF/orm.xml found
persistent types [Ljava.lang.String;@fe9034.
5 myPU TRACE [Thread-62] openjpa.MetaData - Mapping resource location
jar:file:$(EAR_ROOT)/lib/my-entities1-1.0-SNAPSHOT.jar!/META-INF/orm.xml to
persistent types [com.heilgeist.testcase.geronimo.jarfile.MyEntity1].
5 myPU TRACE [Thread-62] openjpa.MetaData - parsePersistentTypeNames() found
[com.heilgeist.testcase.geronimo.jarfile.MyEntity1].
5 myPU TRACE [Thread-62] openjpa.MetaData - Found 1 classes with metadata in
3 milliseconds.
{noformat}
2. EAR with both jars next to the persistence root:
{noformat}
lib/my-pu-1.0-SNAPSHOT.jar
lib/my-entities1-1.0-SNAPSHOT.jar
lib/my-entities2-1.0-SNAPSHOT.jar
{noformat}
During deployment both entities are discovered:
{noformat}
2 myPU TRACE [Thread-61] openjpa.MetaData - Scanning jar
$(EAR_ROOT)/lib/my-pu-1.0-SNAPSHOT.jar for persistent types.
2 myPU TRACE [Thread-61] openjpa.MetaData - Scanning jar file from URL
file:$(EAR_ROOT)/lib/my-entities2-1.0-SNAPSHOT.jar for persistent types.
2 myPU TRACE [Thread-61] openjpa.MetaData - Scanning jar file from URL
file:$(EAR_ROOT)/lib/my-entities1-1.0-SNAPSHOT.jar for persistent types.
2 myPU TRACE [Thread-61] openjpa.MetaData - Scanning resource
META-INF/orm.xml for persistent types.
5 myPU TRACE [Thread-61] openjpa.MetaData - Scan of META-INF/orm.xml found
persistent types [Ljava.lang.String;@1f0c908.
5 myPU TRACE [Thread-61] openjpa.MetaData - Mapping resource location
jar:file:$(EAR_ROOT)/lib/my-entities1-1.0-SNAPSHOT.jar!/META-INF/orm.xml to
persistent types [com.heilgeist.testcase.geronimo.jarfile.MyEntity1].
5 myPU TRACE [Thread-61] openjpa.MetaData - Scan of META-INF/orm.xml found
persistent types [Ljava.lang.String;@11e3986.
5 myPU TRACE [Thread-61] openjpa.MetaData - Mapping resource location
jar:file:$(EAR_ROOT)/lib/my-entities2-1.0-SNAPSHOT.jar!/META-INF/orm.xml to
persistent types [com.heilgeist.testcase.geronimo.jarfile.MyEntity2].
5 myPU TRACE [Thread-61] openjpa.MetaData - parsePersistentTypeNames() found
[com.heilgeist.testcase.geronimo.jarfile.MyEntity2,
com.heilgeist.testcase.geronimo.jarfile.MyEntity1].
5 myPU TRACE [Thread-61] openjpa.MetaData - Found 2 classes with metadata in
4 milliseconds.
{noformat}
I am not sure, whether this is related to this issue (a consequence of the
patch?) or a separate problem.
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
Assignee: Ivan
Attachments: Geronimo-4468.patch, geronimo-jarfile.tar.gz,
my-ear-1.0-SNAPSHOT.ear
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file
or directory whose META-INF directory contains the persistence.xml file is
termed the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying
it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a
[jira] Created: (GERONIMO-4500) Jetty/CXF fails to parse jax-ws-catalog.xml including a DOCTYPE declaration
Jetty/CXF fails to parse jax-ws-catalog.xml including a DOCTYPE declaration
---
Key: GERONIMO-4500
URL: https://issues.apache.org/jira/browse/GERONIMO-4500
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.2
Environment: Geronimo 2.2-SNAPSHOT, Jetty/CXF assembly
Reporter: Janko Heilgeist
I've built an EJB-JAR packaging a web service. The JAR contains all classes,
SEI and service stub generated from an existing WSDL (which is also inside this
JAR). Additionally, it contains the actual EJB implementing the web service.
I tried to annotate the web service implementation with
{code:java}
@WebService( ..., wsdlLocation=http://example.com/myservice.wsdl;)
{code}
and add a META-INF/jax-ws-catalog.xml:
{code:xml}
?xml version=1.0 encoding=UTF-8?
!DOCTYPE catalog PUBLIC -//OASIS//DTD XML Catalogs V1.1//EN
http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd;
catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog
system
systemId=http://example.com/myservice.wsdl;
uri=wsdl/myservice.wsdl/
/catalog
{code}
During deployment, the following exception is thrown:
{noformat}
2009-01-07 17:33:53,087 WARN [OASISCatalogManager] Error loading
META-INF/jax-ws-catalog.xml catalog files
java.io.FileNotFoundException:
http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:905)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:872)
at
com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:282)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:1021)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at
org.apache.xml.resolver.readers.SAXCatalogReader.readCatalog(SAXCatalogReader.java:251)
at org.apache.xml.resolver.Catalog.parseCatalog(Catalog.java:681)
at
org.apache.cxf.catalog.OASISCatalogManager.loadCatalogs(OASISCatalogManager.java:108)
at
org.apache.cxf.catalog.OASISCatalogManager.loadContextCatalogs(OASISCatalogManager.java:93)
at
org.apache.cxf.catalog.OASISCatalogManager.loadContextCatalogs(OASISCatalogManager.java:89)
at
org.apache.cxf.catalog.OASISCatalogManager.register(OASISCatalogManager.java:81)
...
{noformat}
As a workaround the DOCTYPE declaration can be removed. Without the declaration
the exception is gone and the wsdlLocation URL is correctly resolved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4500) Jetty/CXF fails to parse jax-ws-catalog.xml including a DOCTYPE declaration
[
https://issues.apache.org/jira/browse/GERONIMO-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janko Heilgeist updated GERONIMO-4500:
--
Attachment: geronimo-wsdllocation-jetty_cxf-1.0-SNAPSHOT.jar
geronimo-wsdllocation-jetty_cxf.tar.gz
Simple example project and the deployable EJB-JAR to reproduce the exception
Jetty/CXF fails to parse jax-ws-catalog.xml including a DOCTYPE declaration
---
Key: GERONIMO-4500
URL: https://issues.apache.org/jira/browse/GERONIMO-4500
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.2
Environment: Geronimo 2.2-SNAPSHOT, Jetty/CXF assembly
Reporter: Janko Heilgeist
Attachments: geronimo-wsdllocation-jetty_cxf-1.0-SNAPSHOT.jar,
geronimo-wsdllocation-jetty_cxf.tar.gz
I've built an EJB-JAR packaging a web service. The JAR contains all classes,
SEI and service stub generated from an existing WSDL (which is also inside
this JAR). Additionally, it contains the actual EJB implementing the web
service.
I tried to annotate the web service implementation with
{code:java}
@WebService( ..., wsdlLocation=http://example.com/myservice.wsdl;)
{code}
and add a META-INF/jax-ws-catalog.xml:
{code:xml}
?xml version=1.0 encoding=UTF-8?
!DOCTYPE catalog PUBLIC -//OASIS//DTD XML Catalogs V1.1//EN
http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd;
catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog
system
systemId=http://example.com/myservice.wsdl;
uri=wsdl/myservice.wsdl/
/catalog
{code}
During deployment, the following exception is thrown:
{noformat}
2009-01-07 17:33:53,087 WARN [OASISCatalogManager] Error loading
META-INF/jax-ws-catalog.xml catalog files
java.io.FileNotFoundException:
http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:905)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:872)
at
com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:282)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:1021)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at
org.apache.xml.resolver.readers.SAXCatalogReader.readCatalog(SAXCatalogReader.java:251)
at org.apache.xml.resolver.Catalog.parseCatalog(Catalog.java:681)
at
org.apache.cxf.catalog.OASISCatalogManager.loadCatalogs(OASISCatalogManager.java:108)
at
org.apache.cxf.catalog.OASISCatalogManager.loadContextCatalogs(OASISCatalogManager.java:93)
at
org.apache.cxf.catalog.OASISCatalogManager.loadContextCatalogs(OASISCatalogManager.java:89)
at
org.apache.cxf.catalog.OASISCatalogManager.register(OASISCatalogManager.java:81)
...
{noformat}
As a workaround the DOCTYPE declaration can be removed. Without the
declaration the exception is gone and the wsdlLocation URL is correctly
resolved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4501) Tomcat/Axis ignores jax-ws-catalog.xml while resolving wsdlLocation URLs
Tomcat/Axis ignores jax-ws-catalog.xml while resolving wsdlLocation URLs
Key: GERONIMO-4501
URL: https://issues.apache.org/jira/browse/GERONIMO-4501
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.2
Environment: Geronimo 2.2-SNAPSHOT, Tomcat/Axis
Reporter: Janko Heilgeist
The problem description's context is identical to GERONIMO-4500 for the
Jetty/CXF assembly. This time the catalog is completely ignored while resolving
the wsdlLocation URL. The exception is:
{noformat}
2009-01-07 17:45:17,701 ERROR [GBeanInstanceState] Error while starting; GBean
is now in the FAILED state:
abstractName=default/geronimo-wsdllocation-jetty_cxf-1.0-SNAPSHOT.jar/1231346713744/car?EJBModule=default/geronimo-wsdllocation-jetty_cxf-1.0-SNAPSHOT.jar/1231346713744/car,J2EEApplication=null,StatelessSessionBean=HelloWorldServiceEJB,j2eeType=WSLink,name=HelloWorldServiceEJB
java.io.FileNotFoundException: http://example.com/HelloWorld.wsdl
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
at java.net.URL.openStream(URL.java:1007)
at
org.apache.geronimo.axis2.AxisServiceGenerator.readWSDL(AxisServiceGenerator.java:302)
at
org.apache.geronimo.axis2.AxisServiceGenerator.getServiceFromWSDL(AxisServiceGenerator.java:141)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.init(Axis2WebServiceContainer.java:145)
at
org.apache.geronimo.axis2.ejb.EJBWebServiceContainer.init(EJBWebServiceContainer.java:56)
at
org.apache.geronimo.axis2.ejb.EJBWebServiceGBean.init(EJBWebServiceGBean.java:70)
...
{noformat}
The workaround that helped in the case of the Jetty/CXF assembly does not work
with Tomcat/Axis.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file or
directory whose META-INF directory contains the persistence.xml file is termed
the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying it
on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment, while on
the console OpenJPA throws exceptions because it tries to resolve the jar-file
paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janko Heilgeist updated GERONIMO-4468:
--
Attachment: (was: geronimo-jarfile.tar.gz)
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
Attachments: my-ear-1.0-SNAPSHOT.ear
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file
or directory whose META-INF directory contains the persistence.xml file is
termed the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying
it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
while on the console OpenJPA throws exceptions because it tries to resolve
the jar-file paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janko Heilgeist updated GERONIMO-4468:
--
Attachment: my-ear-1.0-SNAPSHOT.ear
geronimo-jarfile.tar.gz
The EAR contains an empty servlet set to load-on-startup just to make the
error visible on deployment.
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
Attachments: geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file
or directory whose META-INF directory contains the persistence.xml file is
termed the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying
it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
while on the console OpenJPA throws exceptions because it tries to resolve
the jar-file paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janko Heilgeist updated GERONIMO-4468:
--
Attachment: (was: my-ear-1.0-SNAPSHOT.ear)
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
Attachments: geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file
or directory whose META-INF directory contains the persistence.xml file is
termed the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying
it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
while on the console OpenJPA throws exceptions because it tries to resolve
the jar-file paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janko Heilgeist updated GERONIMO-4468:
--
Attachment: geronimo-jarfile.tar.gz
my-ear-1.0-SNAPSHOT.ear
Simplified sample EAR
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
Attachments: geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file
or directory whose META-INF directory contains the persistence.xml file is
termed the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying
it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
while on the console OpenJPA throws exceptions because it tries to resolve
the jar-file paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4416) Axis2 creates an invalid extra instance of web service beans
[ https://issues.apache.org/jira/browse/GERONIMO-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Janko Heilgeist updated GERONIMO-4416: -- Attachment: MyServiceEJBImpl.java Axis2 creates an invalid extra instance of web service beans Key: GERONIMO-4416 URL: https://issues.apache.org/jira/browse/GERONIMO-4416 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.1.3, 2.2 Environment: Geronimo with Tomcat/Axis2 Reporter: Janko Heilgeist Attachments: MyServiceEJBImpl.java Axis2 creates an extra instance of a web service EJB that isn't used for anything. There is no resource injection performed for this instance but its life cycle callbacks are executed, which can lead to unexpected behavior. This bug doesn't occur with the Jetty/CXF package. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4416) Axis2 creates an invalid extra instance of web service beans
Axis2 creates an invalid extra instance of web service beans Key: GERONIMO-4416 URL: https://issues.apache.org/jira/browse/GERONIMO-4416 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: webservices Affects Versions: 2.1.3, 2.2 Environment: Geronimo with Tomcat/Axis2 Reporter: Janko Heilgeist Attachments: MyServiceEJBImpl.java Axis2 creates an extra instance of a web service EJB that isn't used for anything. There is no resource injection performed for this instance but its life cycle callbacks are executed, which can lead to unexpected behavior. This bug doesn't occur with the Jetty/CXF package. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4416) Axis2 creates an invalid extra instance of web service beans
[ https://issues.apache.org/jira/browse/GERONIMO-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Janko Heilgeist updated GERONIMO-4416: -- Attachment: openejb-jar.xml ejb-jar.xml MyServiceInterface.java Axis2 creates an invalid extra instance of web service beans Key: GERONIMO-4416 URL: https://issues.apache.org/jira/browse/GERONIMO-4416 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.1.3, 2.2 Environment: Geronimo with Tomcat/Axis2 Reporter: Janko Heilgeist Attachments: ejb-jar.xml, MyServiceEJBImpl.java, MyServiceInterface.java, openejb-jar.xml Axis2 creates an extra instance of a web service EJB that isn't used for anything. There is no resource injection performed for this instance but its life cycle callbacks are executed, which can lead to unexpected behavior. This bug doesn't occur with the Jetty/CXF package. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3954) Allow overriding the value of an env-entry/ from within deployment plans
Allow overriding the value of an env-entry/ from within deployment plans
--
Key: GERONIMO-3954
URL: https://issues.apache.org/jira/browse/GERONIMO-3954
Project: Geronimo
Issue Type: Improvement
Security Level: public (Regular issues)
Reporter: Janko Heilgeist
The provider or assembler of an JavaEE application can define environment
entries inside the standard deployment descriptor files like ejb-jar.xml or
web.xml with
{code:xml}
env-entry
descriptionSome crucial variable!/description
env-entry-namesomeVariable/env-entry-name
env-entry-typejava.lang.String/env-entry-type
!--env-entry-valuecontent of string/env-entry-value--
/env-entry
{code}
Currently, the deployer of this application needs to modify the standard
deployment descriptor to set the environment entry to a value. This is a
problem, if e.g. the archive containing the descriptor file was signed by the
provider and is supposed to be used unmodified. It would be a major
improvement, if the Geronimo deployment plans would allow setting or overriding
the values of these entries.
This seems to have been the case in previous versions of Geronimo. On August
24th, 2003 the schema
incubator-geronimo/modules/core/src/schema/geronimo-ejb-jar.xsd contained the
following elements:
{code:xml}
[...]
xsd:element name=env-entry
xsd:annotation
xsd:documentation
Configuration for an environment entry. Normally an env-entry
is fully configured by the assembler in the standard ejb-jar.xml
deployment descriptor. However, the deployer can specify a
value here if there was no value specified in ejb-jar.xml, or
if the deployer wants to override the value specified there.
/xsd:documentation
/xsd:annotation
xsd:complexType
xsd:sequence
xsd:element ref=env-entry-name minOccurs=1 maxOccurs=1/
xsd:element ref=env-entry-value minOccurs=1 maxOccurs=1/
/xsd:sequence
/xsd:complexType
/xsd:element
[...]
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
