[jira] Commented: (GERONIMO-4468) elements are interpreted relatively to EAR root

[Janko Heilgeist (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 {{}} 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 
{{true}} 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...

>  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  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}
>  
> 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)
>  
> 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) elements are interpreted relatively to EAR root

[Ivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665063#action_12665063
 ] 

Ivan commented on GERONIMO-4468:


Oops, :-(
I have not read the specs about this. 
So Janko, do you mean that specs defines that all the jar files in the jar-file 
elements could only be in the lib folder or defined as a module ? If so, only 
the first patch file is needed.
Thanks !

>  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  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}
>  
> 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)
>  
> 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-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.

[Gang Yin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gang Yin updated GERONIMO-4517:
---

Attachment: js-localization-core.patch

Add some java classes and js functions to extend the G-4484 to the display 
manner and localization of javascript messages generated at front-end.
Some sample pics show the reslut after adaption of openejb portlet.

> Apply unified message display style(G-4484) to javascript alert messages. 
> Together with the localization of these messages.
> ---
>
> Key: GERONIMO-4517
> URL: https://issues.apache.org/jira/browse/GERONIMO-4517
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Gang Yin
>Assignee: Gang Yin
>Priority: Minor
> Fix For: 2.2
>
> Attachments: js-localization-core.patch, js-localization-openejb.patch
>
>
> Currently all the messages generated from backend is displayed in a unified 
> manner(G-4484), but frontend javascript use alert boxes to display all kinds 
> of messages without distinguishing their types(e.g. error, warn, info), and 
> the UX of alert boxes is not so good, so I'm going to extend the unified 
> message display style of backend messages to frontend messages. Also, the 
> localization work will be done meantime.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.

[Gang Yin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gang Yin updated GERONIMO-4517:
---

Attachment: js-localization-openejb.patch

adaption of openejb portlet

> Apply unified message display style(G-4484) to javascript alert messages. 
> Together with the localization of these messages.
> ---
>
> Key: GERONIMO-4517
> URL: https://issues.apache.org/jira/browse/GERONIMO-4517
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Gang Yin
>Assignee: Gang Yin
>Priority: Minor
> Fix For: 2.2
>
> Attachments: js-localization-core.patch, js-localization-openejb.patch
>
>
> Currently all the messages generated from backend is displayed in a unified 
> manner(G-4484), but frontend javascript use alert boxes to display all kinds 
> of messages without distinguishing their types(e.g. error, warn, info), and 
> the UX of alert boxes is not so good, so I'm going to extend the unified 
> message display style of backend messages to frontend messages. Also, the 
> localization work will be done 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-4468) elements are interpreted relatively to EAR root

[Janko Heilgeist (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

>  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  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}
>  
> 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)
>  
> 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-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.

[Gang Yin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gang Yin updated GERONIMO-4517:
---

Attachment: screenshot-2.jpg

> Apply unified message display style(G-4484) to javascript alert messages. 
> Together with the localization of these messages.
> ---
>
> Key: GERONIMO-4517
> URL: https://issues.apache.org/jira/browse/GERONIMO-4517
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Gang Yin
>Assignee: Gang Yin
>Priority: Minor
> Fix For: 2.2
>
> Attachments: js-localization-core.patch, 
> js-localization-openejb.patch, screenshot-1.jpg, screenshot-2.jpg
>
>
> Currently all the messages generated from backend is displayed in a unified 
> manner(G-4484), but frontend javascript use alert boxes to display all kinds 
> of messages without distinguishing their types(e.g. error, warn, info), and 
> the UX of alert boxes is not so good, so I'm going to extend the unified 
> message display style of backend messages to frontend messages. Also, the 
> localization work will be done meantime.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.

[Gang Yin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gang Yin updated GERONIMO-4517:
---

Attachment: screenshot-1.jpg

> Apply unified message display style(G-4484) to javascript alert messages. 
> Together with the localization of these messages.
> ---
>
> Key: GERONIMO-4517
> URL: https://issues.apache.org/jira/browse/GERONIMO-4517
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Gang Yin
>Assignee: Gang Yin
>Priority: Minor
> Fix For: 2.2
>
> Attachments: js-localization-core.patch, 
> js-localization-openejb.patch, screenshot-1.jpg, screenshot-2.jpg
>
>
> Currently all the messages generated from backend is displayed in a unified 
> manner(G-4484), but frontend javascript use alert boxes to display all kinds 
> of messages without distinguishing their types(e.g. error, warn, info), and 
> the UX of alert boxes is not so good, so I'm going to extend the unified 
> message display style of backend messages to frontend messages. Also, the 
> localization work will be done meantime.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

ERROR NotFoundException: deploy/farm

[chen zhen]

I'm trying to learn Plugin based Farming according to Example walkthrough on
http://cwiki.apache.org/GMOxDOC22/*farming*-using-deployment.html.


When deploying a sample to the farm(the command as follow)
deploy/farm add -f cluster1 -l pluginList1 -a
org.apache.geronimo.samples/bank-tomcat/2.2-SNAPSHOT/car

error message is:
ERROR NotFoundException: deploy/farm

[jira] Commented: (GERONIMO-4468) elements are interpreted relatively to EAR root

[Ivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665085#action_12665085
 ] 

Ivan commented on GERONIMO-4468:


Thanks, Janko and David, I learned a lot about JPA through this issue :-)

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

Re: ERROR NotFoundException: deploy/farm

[viola lu]

Currently this function doesn't exist in  trunk. But you can find one sample
code from https://svn.apache.org/repos/asf/geronimo/sandbox/failover/.

You can get some hints from a post by shawn "Quetions per plugin based
farming" in dev list.



On Mon, Jan 19, 2009 at 5:51 PM, chen zhen  wrote:

> I'm trying to learn Plugin based Farming according to Example walkthrough
> on 
> http://cwiki.apache.org/GMOxDOC22/*farming*-using-deployment.html.
>
>
> When deploying a sample to the farm(the command as follow)
> deploy/farm add -f cluster1 -l pluginList1 -a
> org.apache.geronimo.samples/bank-tomcat/2.2-SNAPSHOT/car
>
> error message is:
> ERROR NotFoundException: deploy/farm
>



-- 
viola

[DISCUSS] Security Vulnerability Policy created

[Donald Woods]

There was a long discussion around mid-December on the private and 
security Geronimo mailing lists about how to handle security 
vulnerabilities.  The outcome of that discussion (which is mainly a 
boilerplate suggested by Mark Thomas for all projects to use) can be 
found on our Project Policies wiki page at -

  http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html

If you see anything that needs changing or information that needs to be 
added, then please discuss on this thread.



Thanks,
Apache Geronimo PMC

[jira] Updated: (GERONIMO-4170) Upgrade Selenium version for Firefox 3

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-4170:
---

Fix Version/s: 2.1.4

also included in 2.1.4

> Upgrade Selenium version for Firefox 3
> --
>
> Key: GERONIMO-4170
> URL: https://issues.apache.org/jira/browse/GERONIMO-4170
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: testsuite
>Affects Versions: 2.1.2, 2.2
>Reporter: Donald Woods
>Assignee: Jason Dillon
>Priority: Minor
> Fix For: 2.1.4, 2.2
>
>
> The current Selenium 1.0-beta-1 artifacts do not support using Firefox3 (on 
> Linux or MacOSX.)
> When a snapshot or next beta does support FF3, then we should upgrade.
> The current 1.0-SNAPSHOT artifacts as of the 20080627 version still does not 
> work with FF3 on Linux.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMODEVTOOLS-559) GEP signed feature jar(s) should not display nulls when asking the user if they "trust" the certificate(s)

[Delos Dai (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Delos Dai updated GERONIMODEVTOOLS-559:
---

Attachment: 559.patch

Try this patch!

I change the validity into ten years.Meanwhile, some information has been 
filled in. There should no "null" shown now.

Thanks a lot!

> GEP signed feature jar(s) should not display nulls when asking the user if 
> they "trust" the certificate(s)
> --
>
> Key: GERONIMODEVTOOLS-559
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-559
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.2.0, 2.1.4
>Reporter: Tim McConnell
>Assignee: Delos Dai
> Attachments: 559.patch, screenshot-1.jpg, screenshot-2.jpg
>
>
> It seems that as a result of GERONIMODEVTOOLS-521 our jar(s) are signed. 
> However as they are now they may likely cause more confusion with the 
> end-user, rather then instill confidence. When the Eclipse installer 
> discovers they are signed it asks the end-user if they trust the 
> certificate(s). The one for the GEP feature displays too many nulls -- these 
> values should be populated to mitigate possible confusion. I'll attach a 
> screenshot to show what exactly I mean.  

-- 
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) elements are interpreted relatively to EAR root

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-4468:
---

  Component/s: persistence
   Patch Info: [Patch Available]
Fix Version/s: 2.2
   2.1.4

>  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) 
>  Components: persistence
>Affects Versions: 2.1.3
>Reporter: Janko Heilgeist
>Assignee: Ivan
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4468-01.patch, Geronimo-4468.patch, 
> geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
>
>
> The  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}
>  
> 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)
>  
> 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-4369) The new attribute values are overwrote while restarting the DB pool connector

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-4369:
---

  Priority: Blocker  (was: Major)
Regression: [Regression]

> The new attribute values are overwrote while restarting the DB pool connector
> -
>
> Key: GERONIMO-4369
> URL: https://issues.apache.org/jira/browse/GERONIMO-4369
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
> Environment: Geronimo 2.2 snapshot
> JDK 1.5
> Windows XP
>Reporter: Ivan
>Assignee: Ivan
>Priority: Blocker
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4369-11.13.patch, Geronimo-4369-11.17.patch, 
> Geronimo-4369-11.19.patch
>
>
> After editing the values in the db pool, then restart it in the console, the 
> new values lost.
> When saving the new attribute values, such as user name,  the gbeandata in 
> the configurationManager is not updated, so while restarting the connector, 
> the gbinstance copies those old values from it. So the new persistent values 
> do not take effect, 
> Do I miss anything, thanks for any comment !

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4518) Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-4518:
---

 Priority: Blocker  (was: Major)
   Regression: [Regression]
Affects Version/s: 2.1.4
Fix Version/s: 2.2
   2.1.4

> Can't shutdown the server when host was set to 127.0.0.1 in 
> config-substitutions.properties
> ---
>
> Key: GERONIMO-4518
> URL: https://issues.apache.org/jira/browse/GERONIMO-4518
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: startup/shutdown
>Affects Versions: 2.1.4, 2.2
> Environment: Windows XP + Sun JDK 1.5
>Reporter: Shawn Jiang
>Priority: Blocker
> Fix For: 2.1.4, 2.2
>
>
> 1, change the host in config-substitutions.properties to 127.0.0.1
> 2, start the server.
> 3, shutdown the server.
> *expected result*: the server could be shutdown.
> *actual result*: the sever can't be shutdown with exception:  
> java.net.ConnectException: Connection refused: connect
> --
> C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\bin>shutdown --host 127.0.0.1
> Using GERONIMO_HOME:   C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT
> Using GERONIMO_TMPDIR: var\temp
> Using JRE_HOME:D:\dev\JDKs\sun_jdk1.5.0_15\jre
> log4j:WARN No appenders could be found for logger 
> (org.apache.geronimo.kernel.basic.BasicKernel).
> log4j:WARN Please initialize the log4j system properly.
> Username: system
> Password: ***
> Locating server on 127.0.0.1:1099...
> Could not communicate with the server.  The server may not be running or the 
> port number may be inco
> rrect (Connection refused to host: 6.153.277.58; nested exception is:
> java.net.ConnectException: Connection refused: connect)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [DISCUSS] Security Vulnerability Policy created

[Joe Bohn]

Is the omission of any discussion of a JIRA intentional?  In other 
words, is it expected that a JIRA will *not* be created to document or 
track the code change and that CVE will be the only documentation of the 
issue (and then only after a server image has already been released by 
changing the commit log)?


If we are not creating a JIRA, then this brings up a documentation 
issue.  Not announcing the issue until after a server release also 
causes some doc issues.

- We typically use JIRAs to identify all changes within a release.
- We include the list of JIRAs fixed and outstanding within the 
RELEASE_NOTES for each server release.
- The RELEASE_NOTES are included in the server images so that anyone 
downloading a server image can easily understand what issues are 
resolved or still outstanding with that release.
- So typically JIRAs must be resolved before we create a release 
candidate.  The entire release (including the release notes) is then 
validated during the vote for the release candidate.


Security fixes are important, so it seems that they should be mentioned 
in the release notes.  I also understand the sensitive nature of these 
issues and the possibility of exploitation.  However, it seems that the 
code check-in itself already has the potential to make the exposure 
public for those watching carefully.


One possible solution would be to announce the vulnerability once we 
have a work-around available and/or a fix available in a SNAPSHOT image. 
 This will substantially shorten the time between the code changes and 
announce, thereby limiting possible exposure from those noticing or 
discussing the purpose of code changes.  I image that even innocent 
questions about changes which are being inserted to resolve security 
issues could result in an exposure becoming public in an ad hoc manner. 
  Waiting to validate a full release after code check-in might increase 
the possibility that the exposure could be exploited.  And what happens 
if there are other issues with the release that cause it to drag on 
longer than expected?


However, a user can make an informed decision on how to proceed if we 
announce the resolution in a SNAPSHOT and they will get the information 
much more quickly.  It will also allow the project to document the issue 
correctly in a formal release and address any other issues that arise in 
the release process.


Joe

Donald Woods wrote:
There was a long discussion around mid-December on the private and 
security Geronimo mailing lists about how to handle security 
vulnerabilities.  The outcome of that discussion (which is mainly a 
boilerplate suggested by Mark Thomas for all projects to use) can be 
found on our Project Policies wiki page at -

  http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html

If you see anything that needs changing or information that needs to be 
added, then please discuss on this thread.



Thanks,
Apache Geronimo PMC

[jira] Commented: (GERONIMO-4468) elements are interpreted relatively to EAR root

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665152#action_12665152
 ] 

David Jencks commented on GERONIMO-4468:


Just to be clear -- I agree with Janko, to get a non-lib jar avaliable for jpa 
you need to include it in the module's manifest class path.  As a warning note 
that if you include this jar in several web module manifest classpaths each web 
app will load the classes in its own classloader so transferring one of these 
objects from web app to web app will result in ClassCastExceptions.

>  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) 
>  Components: persistence
>Affects Versions: 2.1.3
>Reporter: Janko Heilgeist
>Assignee: Ivan
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4468-01.patch, Geronimo-4468.patch, 
> geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
>
>
> The  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}
>  
> 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)
>  
> 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.

Re: [DISCUSS] Security Vulnerability Policy created

[Donald Woods]

Joe Bohn wrote:
Is the omission of any discussion of a JIRA intentional?  In other 
words, is it expected that a JIRA will *not* be created to document or 
track the code change and that CVE will be the only documentation of the 
issue (and then only after a server image has already been released by 
changing the commit log)?


Good point.  I believe we should create the JIRA as part of step #9.



If we are not creating a JIRA, then this brings up a documentation 
issue.  Not announcing the issue until after a server release also 
causes some doc issues.

- We typically use JIRAs to identify all changes within a release.
- We include the list of JIRAs fixed and outstanding within the 
RELEASE_NOTES for each server release.
- The RELEASE_NOTES are included in the server images so that anyone 
downloading a server image can easily understand what issues are 
resolved or still outstanding with that release.
- So typically JIRAs must be resolved before we create a release 
candidate.  The entire release (including the release notes) is then 
validated during the vote for the release candidate.


Security fixes are important, so it seems that they should be mentioned 
in the release notes.  I also understand the sensitive nature of these 
issues and the possibility of exploitation.  However, it seems that the 
code check-in itself already has the potential to make the exposure 
public for those watching carefully.


One possible solution would be to announce the vulnerability once we 
have a work-around available and/or a fix available in a SNAPSHOT image. 


Agree that we need to be as open as possible.  As part of step #9, I'd 
like to see us add a reference to the fix (but not the complete details) 
on our Security pages for each release.  Step #12 would also be updated, 
to go back and add the CVE number and more details to the Security pages 
as each branch is released.


 This will substantially shorten the time between the code changes and 
announce, thereby limiting possible exposure from those noticing or 
discussing the purpose of code changes.  I image that even innocent 
questions about changes which are being inserted to resolve security 
issues could result in an exposure becoming public in an ad hoc manner. 
  Waiting to validate a full release after code check-in might increase 
the possibility that the exposure could be exploited.  And what happens 
if there are other issues with the release that cause it to drag on 
longer than expected?


However, a user can make an informed decision on how to proceed if we 
announce the resolution in a SNAPSHOT and they will get the information 
much more quickly.  It will also allow the project to document the issue 
correctly in a formal release and address any other issues that arise in 
the release process.


Joe

Donald Woods wrote:
There was a long discussion around mid-December on the private and 
security Geronimo mailing lists about how to handle security 
vulnerabilities.  The outcome of that discussion (which is mainly a 
boilerplate suggested by Mark Thomas for all projects to use) can be 
found on our Project Policies wiki page at -

  http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html

If you see anything that needs changing or information that needs to 
be added, then please discuss on this thread.



Thanks,
Apache Geronimo PMC

[jira] Updated: (GERONIMO-4460) Upgrade Spring plugin to 2.5.6 artifacts

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-4460:
---

Fix Version/s: 2.1.4

Also applied to branches/2.1 (2.1.4-SNAPSHOT) as Rev735754.

> Upgrade Spring plugin to 2.5.6 artifacts
> 
>
> Key: GERONIMO-4460
> URL: https://issues.apache.org/jira/browse/GERONIMO-4460
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: ActiveMQ, console, dependencies
>Affects Versions: 2.2
>Reporter: Donald Woods
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.1.4, 2.2
>
>
> ActiveMQ was using springframework 2.5.5 at build time, so upgrading 
> plugins/spring to 2.5.6 allows us to use the same level for pluto and 
> activemq.
> This also fixes the build pulling in commons-logging-1.0.3.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4295) Upgrade to Derby 10.4.2.0

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-4295:
---

  Component/s: databases
Fix Version/s: 2.1.4

Also applied to branches/2.1 (2.1.4-SNAPSHOT) as Rev735756.

> Upgrade to Derby 10.4.2.0
> -
>
> Key: GERONIMO-4295
> URL: https://issues.apache.org/jira/browse/GERONIMO-4295
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: databases, dependencies
>Affects Versions: 2.0.3, 2.1.3, 2.2
>Reporter: Donald Woods
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.0.3, 2.1.4, 2.2
>
>
> Upgrade to Derby 10.4.2.0, which was released on Sept. 5, 2008.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.

[Donald Woods (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665169#action_12665169
 ] 

Donald Woods commented on GERONIMO-4517:


Applied js-localization-core.patch to trunk as Rev735763.

> Apply unified message display style(G-4484) to javascript alert messages. 
> Together with the localization of these messages.
> ---
>
> Key: GERONIMO-4517
> URL: https://issues.apache.org/jira/browse/GERONIMO-4517
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Gang Yin
>Assignee: Gang Yin
>Priority: Minor
> Fix For: 2.2
>
> Attachments: js-localization-core.patch, 
> js-localization-openejb.patch, screenshot-1.jpg, screenshot-2.jpg
>
>
> Currently all the messages generated from backend is displayed in a unified 
> manner(G-4484), but frontend javascript use alert boxes to display all kinds 
> of messages without distinguishing their types(e.g. error, warn, info), and 
> the UX of alert boxes is not so good, so I'm going to extend the unified 
> message display style of backend messages to frontend messages. Also, the 
> localization work will be done meantime.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-4474) Pull out the text in the JSP files to resource bundle files

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods closed GERONIMO-4474.
--


Closing.  Please open a new JIRA for any additional problems found.  Thanks.

> Pull out the text in the JSP files to resource bundle files
> ---
>
> Key: GERONIMO-4474
> URL: https://issues.apache.org/jira/browse/GERONIMO-4474
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Ivan
>Assignee: Gang Yin
>Priority: Minor
> Fix For: 2.2
>
> Attachments: jsp-localization-activemq-ra.patch, 
> jsp-localization-activemq.patch, jsp-localization-console.patch, 
> jsp-localization-console_v2.patch, jsp-localization-debugview.patch, 
> jsp-localization-debugview_v2.patch, jsp-localization-fix.patch, 
> jsp-localization-jetty-connector.patch, jsp-localization-monitoring.patch, 
> jsp-localization-monitoring_v2.patch, jsp-localization-openejb.patch, 
> jsp-localization-plancreator.patch, jsp-localization-plancreator_v2.patch, 
> jsp-localization-plugin.patch, jsp-localization-plugin_v2.patch, 
> jsp-localization-securityrealm.patch, jsp-localization-sysdb.patch, 
> jsp-localization-tomcat6-connector.patch
>
>
> Currently in the admin console, some text are hard coded in the JSP files.
> We need to pull them out to the resource bundle files, so that we could 
> deliver multi-language versions in the future.

-- 
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) elements are interpreted relatively to EAR root instead of persistence unit

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-4468:
---

Summary:  elements are interpreted relatively to EAR root instead 
of persistence unit  (was:  elements are interpreted relatively to 
EAR root)

>  elements are interpreted relatively to EAR root instead of 
> persistence unit
> --
>
> Key: GERONIMO-4468
> URL: https://issues.apache.org/jira/browse/GERONIMO-4468
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: persistence
>Affects Versions: 2.1.3
>Reporter: Janko Heilgeist
>Assignee: Ivan
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4468-01.patch, Geronimo-4468.patch, 
> geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
>
>
> The  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}
>  
> 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)
>  
> 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] Resolved: (GERONIMO-2990) Axis2: Supports OASIS XML Catalogs 1.1 specification to be used to resolve web service description document (wsdl/xsd)

[Jarek Gawor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor resolved GERONIMO-2990.
---

   Resolution: Duplicate
Fix Version/s: (was: 2.0.4)
   2.2
 Assignee: Jarek Gawor

Latest Axis2 supports OASIS catalogs and the Geronimo integration work will be 
done as part of GERONIMO-4501.


> Axis2:  Supports OASIS XML Catalogs 1.1 specification to be used to resolve 
> web service description document (wsdl/xsd)
> ---
>
> Key: GERONIMO-2990
> URL: https://issues.apache.org/jira/browse/GERONIMO-2990
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: webservices
>Affects Versions: 2.0-M7
>Reporter: Lin Sun
>Assignee: Jarek Gawor
> Fix For: 2.2
>
>
> Per JSR 109, Supports OASIS XML Catalogs 1.1 specification to be used to 
> resolve web service description document (wsdl/xsd) (p47)
> This work is for Axis2 only as CXF already supports it.

-- 
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) elements are interpreted relatively to EAR root instead of persistence unit

[Donald Woods (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665182#action_12665182
 ] 

Donald Woods commented on GERONIMO-4468:


Applied only first patch Geronimo-4468.patch to trunk as Rev735768.

>  elements are interpreted relatively to EAR root instead of 
> persistence unit
> --
>
> Key: GERONIMO-4468
> URL: https://issues.apache.org/jira/browse/GERONIMO-4468
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: persistence
>Affects Versions: 2.1.3
>Reporter: Janko Heilgeist
>Assignee: Ivan
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4468-01.patch, Geronimo-4468.patch, 
> geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
>
>
> The  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}
>  
> 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)
>  
> 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] Resolved: (GERONIMO-4468) elements are interpreted relatively to EAR root instead of persistence unit

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods resolved GERONIMO-4468.


Resolution: Fixed

Applied only first patch Geronimo-4468.patch to branches/2.1 (2.1.4-SNAPSHOT) 
as Rev735769. 

>  elements are interpreted relatively to EAR root instead of 
> persistence unit
> --
>
> Key: GERONIMO-4468
> URL: https://issues.apache.org/jira/browse/GERONIMO-4468
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: persistence
>Affects Versions: 2.1.3
>Reporter: Janko Heilgeist
>Assignee: Ivan
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4468-01.patch, Geronimo-4468.patch, 
> geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
>
>
> The  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}
>  
> 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)
>  
> 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.

Re: ERROR NotFoundException: deploy/farm

[chen zhen]

  I followed the steps according to  Example walkthrough on
http://cwiki.apache.org/GMOxDOC22/plugin-based-  farming.html.
  1. Farm node setup.
  2. Check out bits from svn
https://svn.apache.org/repos/asf/geronimo/sandbox/failover/.Setup
farm controller by maven
  3.  Deploying a sample to the farm. In this step,  I could deploy a
dependency (sample-datasource), the sample  application. But when
distributing the application to the farm nodes, the error is "ERROR
NotFoundException: deploy/farm".
   I wonder whether I can use "GShell deploy/farm" command, when starting
gshell (bin/gsh)  in a separate terminal in
geronimo-tomcat-farm-controller-2.2-SNAPSHOT.





> .




2009/1/19 viola lu 

> Currently this function doesn't exist in  trunk. But you can find one
> sample code from
> https://svn.apache.org/repos/asf/geronimo/sandbox/failover/.
>
> You can get some hints from a post by shawn "Quetions per plugin based
> farming" in dev list.
>
>
>
>
> On Mon, Jan 19, 2009 at 5:51 PM, chen zhen  wrote:
>
>> I'm trying to learn Plugin based Farming according to Example walkthrough
>> on 
>> http://cwiki.apache.org/GMOxDOC22/*farming*-using-deployment.html.
>>
>>
>> When deploying a sample to the farm(the command as follow)
>> deploy/farm add -f cluster1 -l pluginList1 -a
>> org.apache.geronimo.samples/bank-tomcat/2.2-SNAPSHOT/car
>>
>> error message is:
>> ERROR NotFoundException: deploy/farm
>>
>
>
>
> --
> viola
>

Re: ERROR NotFoundException: deploy/farm

[David Jencks]

I think the command has been renamed cluster/deploy

thanks
david jencks

On Jan 19, 2009, at 6:05 PM, chen zhen wrote:

  I followed the steps according to  Example walkthrough on  http://cwiki.apache.org/GMOxDOC22/plugin-based- 
  farming.html.

  1. Farm node setup.
  2. Check out bits from svn  https://svn.apache.org/repos/asf/geronimo/sandbox/failover/ 
. Setup farm controller by maven
  3.  Deploying a sample to the farm. In this step,  I could deploy  
a dependency (sample-datasource), the sample  application. But  
when distributing the application to the farm nodes, the error is  
"ERROR NotFoundException: deploy/farm".
   I wonder whether I can use "GShell deploy/farm" command, when  
starting  gshell (bin/gsh)  in a separate terminal in geronimo- 
tomcat-farm-controller-2.2-SNAPSHOT.








.



2009/1/19 viola lu 
Currently this function doesn't exist in  trunk. But you can find  
one sample code from https://svn.apache.org/repos/asf/geronimo/sandbox/failover/ 
.


You can get some hints from a post by shawn "Quetions per plugin  
based farming" in dev list.





On Mon, Jan 19, 2009 at 5:51 PM, chen zhen  wrote:
I'm trying to learn Plugin based Farming according to Example  
walkthrough on http://cwiki.apache.org/GMOxDOC22/farming-using-deployment.html 
.


When deploying a sample to the farm(the command as follow)

deploy/farm add -f cluster1 -l pluginList1 -a  
org.apache.geronimo.samples/bank-tomcat/2.2-SNAPSHOT/car


error message is:
ERROR NotFoundException: deploy/farm



--
viola

[BUILD] trunk: Failed for Revision: 735917

[gawor]

Geronimo Revision: 735917 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090119/build-2100.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090119
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 37 minutes 46 seconds
[INFO] Finished at: Mon Jan 19 21:43:18 EST 2009
[INFO] Final Memory: 643M/961M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090119/logs-2100-tomcat/test.log
 
 
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from codehaus-snapshots
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:39.716
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO] 
[INFO] 
---
[INFO] 
[INFO] commands-testsuite/deploy  RUNNING
[INFO] commands-testsuite/deploy  SUCCESS (0:01:00.440) 
[INFO] commands-testsuite/gshell  RUNNING
[INFO] commands-testsuite/gshell  SUCCESS (0:00:28.689) 
[INFO] commands-testsuite/jaxws   RUNNING
[INFO] commands-testsuite/jaxws   SUCCESS (0:00:33.750) 
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.245) 
[INFO] concurrent-testsuite/concurrent-basic  RUNNING
[INFO] concurrent-testsuite/concurrent-basic  SUCCESS (0:06:23.286) 
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:20.231) 
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:43.277) 
[INFO] corba-testsuite/corba-helloworld   RUNNING
[INFO] corba-testsuite/corba-helloworld   SUCCESS (0:00:46.033) 
[INFO] corba-testsuite/corba-marshal  RUNNING
[INFO] corba-testsuite/corba-marshal  SUCCESS (0:00:47.357) 
[INFO] corba-testsuite/corba-mytime   RUNNING
[INFO] corba-testsuite/corba-mytime   SUCCESS (0:00:40.002) 
[INFO] deployment-testsuite/deployment-tests  RUNNING
[INFO] deployment-testsuite/deployment-tests  SUCCESS (0:00:31.476) 
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:29.409) 
[INFO] deployment-testsuite/manifestcp-tests  RUNNING
[INFO] deployment-testsuite/manifestcp-tests  SUCCESS (0:00:32.860) 
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:50.044) 
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:55.999) 
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:49.985) 
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.056) 
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:46.999) 
[INFO] security-testsuite/test-security   RUNNING
[INFO] security-testsuite/test-security   FAILURE (0:00:37.404) Java 
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:29.420) 
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5

Re: ERROR NotFoundException: deploy/farm

[chen zhen]

ERROR ProcessingException: "-f" is not a valid option

I use command   "cluster/deploy add -f cluster1 -l pluginList1 -a
org.apache.geronimo.samples/bank-tomcat/2.2-SNAPSHOT/car" to distribute the
application. But the error is "ERROR ProcessingException: "-f" is not a
valid option"

I looked into  the "cluster/deploy" help information and found  "-f" is not
in its options list.




2009/1/20 David Jencks 

> I think the command has been renamed cluster/deploy
> thanks
> david jencks
>
> On Jan 19, 2009, at 6:05 PM, chen zhen wrote:
>
>   I followed the steps according to  Example walkthrough on
> http://cwiki.apache.org/GMOxDOC22/plugin-based-  farming.html.
>   1. Farm node setup.
>   2. Check out bits from svn
> https://svn.apache.org/repos/asf/geronimo/sandbox/failover/.Setup
>  farm controller by maven
>   3.  Deploying a sample to the farm. In this step,  I could deploy a
> dependency (sample-datasource), the sample  application. But when
> distributing the application to the farm nodes, the error is "ERROR
> NotFoundException: deploy/farm".
>I wonder whether I can use "GShell deploy/farm" command, when starting
> gshell (bin/gsh)  in a separate terminal in
> geronimo-tomcat-farm-controller-2.2-SNAPSHOT.
>
>
>
>
>
>> .
>
>
>
>
> 2009/1/19 viola lu 
>
>> Currently this function doesn't exist in  trunk. But you can find one
>> sample code from
>> https://svn.apache.org/repos/asf/geronimo/sandbox/failover/.
>>
>> You can get some hints from a post by shawn "Quetions per plugin based
>> farming" in dev list.
>>
>>
>>
>>
>> On Mon, Jan 19, 2009 at 5:51 PM, chen zhen  wrote:
>>
>>> I'm trying to learn Plugin based Farming according to Example
>>> walkthrough on http://cwiki.apache.org/GMOxDOC22/*farming*
>>> -using-deployment.html.
>>>
>>>
>>> When deploying a sample to the farm(the command as follow)
>>> deploy/farm add -f cluster1 -l pluginList1 -a
>>> org.apache.geronimo.samples/bank-tomcat/2.2-SNAPSHOT/car
>>>
>>> error message is:
>>> ERROR NotFoundException: deploy/farm
>>>
>>
>>
>>
>> --
>> viola
>>
>
>
>