[jira] Updated: (GERONIMO-4468) elements are interpreted relatively to EAR root instead of persistence unit

[Forrest Xia (JIRA)]

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

Forrest Xia updated GERONIMO-4468:
--

Attachment: my-ear-1.0-SNAPSHOT_PUjarinwebclasses_ejbjarinweblib.ear

More tries:
1. To my self question 1, the answer is "conditional" yes. we need to add a 
ejb-module in application.xml, and set ejb jar manifest having a Class-Path 
entry to the PU jar file.
2. Tried put PU in web module library directory with attached 
"my-ear-1.0-SNAPSHOT_PUjarinwebclasses_ejbjarinweblib.ear", but seems Geronimo 
did not allow PU in web module. The exception as following. Is it a bug?

At least one deployment 
problem:[org.apache.geronimo.common.DeploymentException: Could not resolve 
reference at deploy time for query 
com.heilgeist.testcase.geronimo.jarfile/my-ear/1.0-SNAPSHOT/ear?J2EEApplication=com.heilgeist.testcase.geronimo.jarfile/my-ear/1.0-SNAPSHOT/ear,PersistenceUnitModule=WEB-INF/lib/my-pu-1.0-SNAPSHOT_inclasses.jar,WebModule=my-war-1.0-SNAPSHOT.war,j2eeType=PersistenceUnit,name=myPU#.
 No GBean references found.]
org.apache.geronimo.common.DeploymentException: At least one deployment 
problem:[org.apache.geronimo.common.DeploymentException: Could not resolve 
reference at deploy time for query 
com.heilgeist.testcase.geronimo.jarfile/my-ear/1.0-SNAPSHOT/ear?J2EEApplication=com.heilgeist.testcase.geronimo.jarfile/my-ear/1.0-SNAPSHOT/ear,PersistenceUnitModule=WEB-INF/lib/my-pu-1.0-SNAPSHOT_inclasses.jar,WebModule=my-war-1.0-SNAPSHOT.war,j2eeType=PersistenceUnit,name=myPU#.
 No GBean references found.]
at 
org.apache.geronimo.persistence.builder.PersistenceUnitRefBuilder.buildNaming(PersistenceUnitRefBuilder.java:154)
at 
org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:53)
at 
org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.configureBasicWebModuleAttributes(AbstractWebModuleBuilder.java:842)
at 
org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:347)
at 
org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165)
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
at 
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at 
org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
at 
org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
at java.lang.Thread.run(Thread.java:735)


>  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, 
> my-ear-1.0-SNAPSHOT_PUjarfileinEARroot.ear, 
> my-ear-1.0-SNAPSHOT_PUjarinwebclasses_ejbjarinweblib.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 deploym

[BUILD] trunk: Failed for Revision: 745342

[gawor]

Geronimo Revision: 745342 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090217/build-2100.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090217
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 35 minutes 26 seconds
[INFO] Finished at: Tue Feb 17 21:40:22 EST 2009
[INFO] Final Memory: 636M/995M
[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/20090217/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:41.144
[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.427) 
[INFO] commands-testsuite/gshell  RUNNING
[INFO] commands-testsuite/gshell  SUCCESS (0:00:28.640) 
[INFO] commands-testsuite/jaxws   RUNNING
[INFO] commands-testsuite/jaxws   SUCCESS (0:00:33.458) 
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.378) 
[INFO] concurrent-testsuite/concurrent-basic  RUNNING
[INFO] concurrent-testsuite/concurrent-basic  SUCCESS (0:06:14.375) 
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:19.821) 
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:43.071) 
[INFO] corba-testsuite/corba-helloworld   RUNNING
[INFO] corba-testsuite/corba-helloworld   SUCCESS (0:01:11.925) 
[INFO] corba-testsuite/corba-marshal  RUNNING
[INFO] corba-testsuite/corba-marshal  SUCCESS (0:00:49.313) 
[INFO] corba-testsuite/corba-mytime   RUNNING
[INFO] corba-testsuite/corba-mytime   SUCCESS (0:00:40.505) 
[INFO] deployment-testsuite/deployment-tests  RUNNING
[INFO] deployment-testsuite/deployment-tests  SUCCESS (0:00:30.115) 
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:29.947) 
[INFO] deployment-testsuite/manifestcp-tests  RUNNING
[INFO] deployment-testsuite/manifestcp-tests  SUCCESS (0:00:30.358) 
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:55.602) 
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:52.027) 
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:01:03.264) 
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.140) 
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:47.829) 
[INFO] security-testsuite/test-security   RUNNING
[INFO] security-testsuite/test-security   FAILURE (0:00:37.674) Java 
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:30.336) 
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5

[BUILD] branches/2.0: Failed for Revision: 745307

[gawor]

Geronimo Revision: 745307 built with tests included
 
See the full build-2000.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.0/20090217/build-2000.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.0/20090217
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 33 minutes 49 seconds
[INFO] Finished at: Tue Feb 17 20:36:13 EST 2009
[INFO] Final Memory: 216M/863M
[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/2.0/20090217/logs-2000-tomcat/test.log
 
[INFO] Running deployment-testsuite.deployment
[INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.274 
sec <<< FAILURE!
--
[INFO] Running jpa-testsuite.jpa
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.289 
sec <<< FAILURE!
[INFO] Running sec-testsuite.security
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.616 
sec <<< FAILURE!
--
[INFO] Running web-testsuite.references
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.282 
sec <<< FAILURE!
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.0/20090217/logs-2000-jetty/test.log
 
[INFO] Running deployment-testsuite.deployment
[INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.35 sec 
<<< FAILURE!
--
[INFO] Running jpa-testsuite.jpa
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.297 
sec <<< FAILURE!
[INFO] Running sec-testsuite.security
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.683 
sec <<< FAILURE!
--
[INFO] Running web-testsuite.references
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.497 
sec <<< FAILURE!

Re: Make "framework" build the entire framework server

[David Jencks]

On Feb 17, 2009, at 12:14 PM, Donald Woods wrote:


Sounds worth the time to try it out.

Two requests:
1) If this works, we publish the framework assembly instead of the  
two minimal assemblies to the Download page for 2.2, as this would  
allow users to build their own custom minimal server assembly (and  
of course some docs telling users how to create the old minimal  
assembly from this new framework assembly.)


I'm neutral or slightly +0.1 on this idea.  I don't actually see how  
it relates to my proposal but if everyone agrees I'm fine with this  
idea.


2) If time permits, can we move or duplicate relevant testsuite  
modules into a new testsuite dir under either the framework dir or a  
new framework-testsuite dir, so that we can verify the basic  
framework cmdline scripts and installing plugins (like Jetty/Tomcat  
to make an equivalent minimal assembly)?


I like this idea.  For a few months now when I work on a plugin set  
(mconsole, activemq) I've included a custom server aseembly in the  
plugin group and added at least one integration test.  This has really  
helped speed up feature development.  IIUC you are proposing doing the  
same for framework.


thanks
david jencks





-Donald


David Jencks wrote:
I'd like to play around with trying to make gbeans less restrictive  
and possibly some classloading ideas.  This would be a lot easier  
if I had a smaller project to deal with.  So, I'd like to make it  
so that framework is self contained and builds the entire framework  
server.  I haven't looked at this too closely recently but I think  
it involves:
moving all or part of buildsupport into framework (at least car- 
maven-plugin)

moving the framework plugingroup into framework
moving the boilerplate and framework assemblies into framework.
I suggested this a few months back (sept 23 2008) and there were  
some objections I didn't fully understand.  Right now I'm sure this  
would make my day to day development life a lot easier so if there  
are objections I'd really appreciate knowing how specifically this  
would make your day to day development life harder.

thanks
david jencks

Re: [VOTE] Use apache's nexus for release and snapshot staging and deployment

[David Jencks]

On Feb 17, 2009, at 12:17 PM, Donald Woods wrote:

Would this be just for trunk or would it also include the upcoming  
2.1.4 release?


What about devtools, specs, components, daytrader and gshell?


I think it would be for everything we release to a maven repo  
including xbean, gshell, components, specs, daytrader, plugins,  
server, and everything else I forgot about.


I guess devtools might be different I'm not sure if that is  
released to a maven repo or to somewhere else??... but if to a maven  
repo then it should use nexus.


david jencks





-Donald


David Jencks wrote:
Last week I noted that there's an apache nexus installation that we  
can use for staging and deployment...  https://issues.apache.org/jira/browse/INFRA-1896

They suggest a vote on this, so here goes.
Lets ask sonatype/infra to move geronimo to using nexus for  
deployment.

+1 about time already
+0 needs more thought
-1... I prefer doing things the hard way :-D
Vote open for 72 hours.
thanks
david jencks

Re: [VOTE] Use apache's nexus for release and snapshot staging and deployment

[Gianny Damour]

+1

Gianny

On 18/02/2009, at 6:17 AM, David Jencks wrote:

Last week I noted that there's an apache nexus installation that we  
can use for staging and deployment...  https://issues.apache.org/ 
jira/browse/INFRA-1896


They suggest a vote on this, so here goes.

Lets ask sonatype/infra to move geronimo to using nexus for  
deployment.


+1 about time already
+0 needs more thought
-1... I prefer doing things the hard way :-D

Vote open for 72 hours.

thanks
david jencks

Re: [VOTE] Release gshell 1.0-alpha2

[Jason Warner]

+1

On Tue, Feb 17, 2009 at 11:45 AM, Joe Bohn  wrote:

> +1 (assuming the discussion issue I raised is really a non-issue).
>
> Joe
>
>
> Guillaume Nodet wrote:
>
>> I've uploaded a release of gshell 1.0-alpha2.
>>
>> The staging repo is available at:
>>  
>> http://people.apache.org/~gnodet/staging/gshell-1.0-alpha2
>> The svn tag is:
>>
>> https://svn.apache.org/repos/asf/geronimo/gshell/tags/gshell-1.0-alpha-2/
>>
>> Please review and vote !
>>
>>  [ ] +1 Release gshell-1.0-alpha2
>>  [ ] -1 Do not
>>
>>
>>
>


-- 
~Jason Warner

Re: [VOTE] Use apache's nexus for release and snapshot staging and deployment

[Donald Woods]

Would this be just for trunk or would it also include the upcoming 2.1.4 
release?


What about devtools, specs, components, daytrader and gshell?


-Donald


David Jencks wrote:
Last week I noted that there's an apache nexus installation that we can 
use for staging and deployment...  
https://issues.apache.org/jira/browse/INFRA-1896


They suggest a vote on this, so here goes.

Lets ask sonatype/infra to move geronimo to using nexus for deployment.

+1 about time already
+0 needs more thought
-1... I prefer doing things the hard way :-D

Vote open for 72 hours.

thanks
david jencks

Re: Make "framework" build the entire framework server

[Donald Woods]

Sounds worth the time to try it out.

Two requests:
1) If this works, we publish the framework assembly instead of the two 
minimal assemblies to the Download page for 2.2, as this would allow 
users to build their own custom minimal server assembly (and of course 
some docs telling users how to create the old minimal assembly from this 
new framework assembly.)
2) If time permits, can we move or duplicate relevant testsuite modules 
into a new testsuite dir under either the framework dir or a new 
framework-testsuite dir, so that we can verify the basic framework 
cmdline scripts and installing plugins (like Jetty/Tomcat to make an 
equivalent minimal assembly)?



-Donald


David Jencks wrote:
I'd like to play around with trying to make gbeans less restrictive and 
possibly some classloading ideas.  This would be a lot easier if I had a 
smaller project to deal with.  So, I'd like to make it so that framework 
is self contained and builds the entire framework server.  I haven't 
looked at this too closely recently but I think it involves:


moving all or part of buildsupport into framework (at least 
car-maven-plugin)

moving the framework plugingroup into framework
moving the boilerplate and framework assemblies into framework.

I suggested this a few months back (sept 23 2008) and there were some 
objections I didn't fully understand.  Right now I'm sure this would 
make my day to day development life a lot easier so if there are 
objections I'd really appreciate knowing how specifically this would 
make your day to day development life harder.


thanks
david jencks

Make "framework" build the entire framework server

[David Jencks]

I'd like to play around with trying to make gbeans less restrictive  
and possibly some classloading ideas.  This would be a lot easier if I  
had a smaller project to deal with.  So, I'd like to make it so that  
framework is self contained and builds the entire framework server.  I  
haven't looked at this too closely recently but I think it involves:


moving all or part of buildsupport into framework (at least car-maven- 
plugin)

moving the framework plugingroup into framework
moving the boilerplate and framework assemblies into framework.

I suggested this a few months back (sept 23 2008) and there were some  
objections I didn't fully understand.  Right now I'm sure this would  
make my day to day development life a lot easier so if there are  
objections I'd really appreciate knowing how specifically this would  
make your day to day development life harder.


thanks
david jencks

Re: [VOTE] Use apache's nexus for release and snapshot staging and deployment

[Kevan Miller]

+1
--kevan
On Feb 17, 2009, at 2:17 PM, David Jencks wrote:

Last week I noted that there's an apache nexus installation that we  
can use for staging and deployment...  https://issues.apache.org/jira/browse/INFRA-1896


They suggest a vote on this, so here goes.

Lets ask sonatype/infra to move geronimo to using nexus for  
deployment.


+1 about time already
+0 needs more thought
-1... I prefer doing things the hard way :-D

Vote open for 72 hours.

thanks
david jencks

Re: [VOTE] Use apache's nexus for release and snapshot staging and deployment

[David Jencks]

Here's my +1

david jencks

On Feb 17, 2009, at 11:17 AM, David Jencks wrote:

Last week I noted that there's an apache nexus installation that we  
can use for staging and deployment...  https://issues.apache.org/jira/browse/INFRA-1896


They suggest a vote on this, so here goes.

Lets ask sonatype/infra to move geronimo to using nexus for  
deployment.


+1 about time already
+0 needs more thought
-1... I prefer doing things the hard way :-D

Vote open for 72 hours.

thanks
david jencks

[VOTE] Use apache's nexus for release and snapshot staging and deployment

[David Jencks]

Last week I noted that there's an apache nexus installation that we  
can use for staging and deployment...  https://issues.apache.org/jira/browse/INFRA-1896


They suggest a vote on this, so here goes.

Lets ask sonatype/infra to move geronimo to using nexus for deployment.

+1 about time already
+0 needs more thought
-1... I prefer doing things the hard way :-D

Vote open for 72 hours.

thanks
david jencks

[jira] Resolved: (GERONIMO-4389) Can't start server when install it in a directory containing space

[Donald Woods (JIRA)]

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

Donald Woods resolved GERONIMO-4389.


Resolution: Fixed

Applied to branches/2.1 (2.1.4-SNAPSHOT) as Rev745162.
Applied to trunk (2.2-SNAPSHOT) as Rev745171.

> Can't start server when install it in a directory containing space
> --
>
> Key: GERONIMO-4389
> URL: https://issues.apache.org/jira/browse/GERONIMO-4389
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: startup/shutdown
>Affects Versions: 2.1.3, 2.2
> Environment: OS:Solaris 10 Sparc
>Reporter: viola.lu
>Assignee: Donald Woods
>Priority: Blocker
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4389_Jack.patch, Geronimo-4389_Jack0217.patch, 
> Geronimo-4389_Jack1108.patch
>
>
> Steps:
> 1.Install geronimo into /opt/geronimo 2.1.3
> 2.Start server
> Errors popup
> [r...@cesolaris bin]#tail -f ../var/log/geronimo.out
> Error opening zip file: /opt/geronimo
> Error occurred during initialization of VM
> agent library failed to init: instrument
> Error opening zip file: /opt/geronimo
> Error occurred during initialization of VM
> agent library failed to init: instrument

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

Re: [DISCUSS] Release gshell 1.0-alpha2

[Jason Dillon]

None of those files are included in a release.

--jason


On Feb 17, 2009, at 10:47 PM, Joe Bohn wrote:

I ran rat against the tag and found the following files missing the  
Apache license header.  These are probably alright because I don't  
see them included in any of the distribution artifacts ... but I  
thought I would check in "just in case".


./NOTES.txt
./build
./extract
./gsh
./rebuild
./src/uml/GShell.mdxml

Joe

Re: [VOTE] Release gshell 1.0-alpha2

[Joe Bohn]

+1 (assuming the discussion issue I raised is really a non-issue).

Joe

Guillaume Nodet wrote:

I've uploaded a release of gshell 1.0-alpha2.

The staging repo is available at:
  http://people.apache.org/~gnodet/staging/gshell-1.0-alpha2
The svn tag is:
  https://svn.apache.org/repos/asf/geronimo/gshell/tags/gshell-1.0-alpha-2/

Please review and vote !

 [ ] +1 Release gshell-1.0-alpha2
 [ ] -1 Do not

Re: [VOTE] Release gshell 1.0-alpha2

[Jay D. McHugh]

+1

Jay

Guillaume Nodet wrote:
> I've uploaded a release of gshell 1.0-alpha2.
> 
> The staging repo is available at:
>   http://people.apache.org/~gnodet/staging/gshell-1.0-alpha2
> The svn tag is:
>   https://svn.apache.org/repos/asf/geronimo/gshell/tags/gshell-1.0-alpha-2/
> 
> Please review and vote !
> 
>  [ ] +1 Release gshell-1.0-alpha2
>  [ ] -1 Do not
> 
> 

[jira] Commented: (GERONIMO-4509) Two EJB server portlet issues

[Manu T George (JIRA)]

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

Manu T George commented on GERONIMO-4509:
-

Commited a patch for GERONIMO-4369. You can now retest this issue and it should 
be fixed

> Two EJB server portlet issues
> -
>
> Key: GERONIMO-4509
> URL: https://issues.apache.org/jira/browse/GERONIMO-4509
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
> Environment: JDK 1.6
> Ubuntu 8.04
> AG 2.2 snapshot 20090110
>Reporter: Forrest Xia
>Assignee: Forrest Xia
>
> For the new EJB server portlet, there are these problems:
> 1. Message prompt just restarting openejb module cause several console 
> exceptions and EJB server portlet disappear in admin console at next time 
> restart server.
> Steps:
> 1.1 Change value of a EJB container parameter, then it prompts OpenEJB module 
> should be restarted for effectiveness. So I use expert mode to restart module 
> org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car, confirm restart, then 
> several exceptions are thrown out as following:
> 2009-01-14 09:35:45,546 ERROR [ConfigManagerPortlet] Exception
> java.lang.IllegalStateException: Configuration 
> org.apache.geronimo.configs/axis2-ejb/2.2-SNAPSHOT/car still has children
> at 
> org.apache.geronimo.kernel.config.ConfigurationStatus.destroy(ConfigurationStatus.java:69)
>   at 
> org.apache.geronimo.kernel.config.ConfigurationModel.removeConfiguration(ConfigurationModel.java:65)
> ...
> 2009-01-14 09:35:45,965 ERROR [[SystemModules]] Servlet.service() for servlet 
> SystemModules threw exception
> java.lang.NullPointerException
>   at 
> org.apache.geronimo.console.configmanager.ConfigManagerPortlet.getConfigurationState(ConfigManagerPortlet.java:325)
>   at 
> org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:272)
>   ...
> 2009-01-14 09:37:08,300 ERROR [[SystemModules]] Servlet.service() for servlet 
> SystemModules threw exception
> java.lang.IllegalStateException: Configuration 
> org.apache.geronimo.configs/jaxws-ejb-deployer/2.2-SNAPSHOT/car still has 
> children
>   at 
> org.apache.geronimo.kernel.config.ConfigurationStatus.destroy(ConfigurationStatus.java:69)
>   at 
> org.apache.geronimo.kernel.config.ConfigurationModel.removeConfiguration(ConfigurationModel.java:65)
> ...
> 2009-01-14 09:37:19,125 ERROR [[SystemModules]] Servlet.service() for servlet 
> SystemModules threw exception
> java.lang.IllegalStateException: Configuration 
> org.apache.geronimo.configs/openejb-deployer/2.2-SNAPSHOT/car still has 
> children
>   at 
> org.apache.geronimo.kernel.config.ConfigurationStatus.destroy(ConfigurationStatus.java:69)
>   at 
> org.apache.geronimo.kernel.config.ConfigurationModel.removeConfiguration(ConfigurationModel.java:65)
>   ...
> Anyway, the openejb module finally restarted, but no children modules appear 
> anymore. Consequently the EJB server portlet disappears from the admin 
> console. No way to check if the changed parameter takes effect.
> 2.2 Followed by step 1, restart geronimo by no change of config.xml, still 
> the EJB server portlet is not there. Then check the config.xml, the portlet 
> module  name="org.apache.geronimo.plugins/openejb-console-tomcat/2.2-SNAPSHOT/car"/> 
> is load=false
> Based on the symptom, I think it might be better to suggest user to restart 
> geronimo server as a whole, not just openejb module.
> 2. Another issue is the parameter value seems be changed only once. For 
> example, if you changed strictpooling from default true to false, then you 
> want to change it back without restarting server, there is no way. This 
> behavior is better to be improved.

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

[Manu T George (JIRA)]

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

Manu T George updated GERONIMO-4369:


Priority: Major  (was: Blocker)
Assignee: (was: Manu T George)

Fixed the general restart issue. What is remaining to be fixed is portlet 
specific

> 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
> Fix For: 2.1.4, 2.2
>
> Attachments: G-4369-0205.patch, G4369-0209.patch, 
> Geronimo-4369-01.21.patch, 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-4468) elements are interpreted relatively to EAR root instead of persistence unit

[Forrest Xia (JIRA)]

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

Forrest Xia updated GERONIMO-4468:
--

Attachment: my-ear-1.0-SNAPSHOT_PUjarfileinEARroot.ear

Tried putting PU jar file(attached 
"my-ear-1.0-SNAPSHOT_PUjarfileinEARroot.ear") in the EAR root and then deploy 
it, an exception happens:
At least one deployment 
problem:[org.apache.geronimo.common.DeploymentException: No default 
PersistenceUnit specified, and none located]
org.apache.geronimo.common.DeploymentException: At least one deployment 
problem:[org.apache.geronimo.common.DeploymentException: No default 
PersistenceUnit specified, and none located]
at 
org.apache.geronimo.persistence.builder.PersistenceUnitRefBuilder.buildNaming(PersistenceUnitRefBuilder.java:154)
at 
org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:53)
at 
org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.configureBasicWebModuleAttributes(AbstractWebModuleBuilder.java:842)
at 
org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:347)
at 
org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165)
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
at 
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at 
org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
at 
org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
at java.lang.Thread.run(Thread.java:735)

So,
Question 1: does Geronimo support put PU jar in the EAR root?

Question 2: Does Geronimo accept persistence.xml in EAR_ROOT/META-INF directory?
I also tried putting persistence.xml in EAR_ROOT/META_INF, it does not work in 
Geronimo as well. But I ever tried JBoss 5, it works!

>  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, 
> my-ear-1.0-SNAPSHOT_PUjarfileinEARroot.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 automaticall

[DISCUSS] Release gshell 1.0-alpha2

[Joe Bohn]

I ran rat against the tag and found the following files missing the 
Apache license header.  These are probably alright because I don't see 
them included in any of the distribution artifacts ... but I thought I 
would check in "just in case".


./NOTES.txt
./build
./extract
./gsh
./rebuild
./src/uml/GShell.mdxml

Joe

[jira] Assigned: (GERONIMO-4389) Can't start server when install it in a directory containing space

[Donald Woods (JIRA)]

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

Donald Woods reassigned GERONIMO-4389:
--

Assignee: Donald Woods  (was: Jack Cai)

> Can't start server when install it in a directory containing space
> --
>
> Key: GERONIMO-4389
> URL: https://issues.apache.org/jira/browse/GERONIMO-4389
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: startup/shutdown
>Affects Versions: 2.1.3, 2.2
> Environment: OS:Solaris 10 Sparc
>Reporter: viola.lu
>Assignee: Donald Woods
>Priority: Blocker
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4389_Jack.patch, Geronimo-4389_Jack0217.patch, 
> Geronimo-4389_Jack1108.patch
>
>
> Steps:
> 1.Install geronimo into /opt/geronimo 2.1.3
> 2.Start server
> Errors popup
> [r...@cesolaris bin]#tail -f ../var/log/geronimo.out
> Error opening zip file: /opt/geronimo
> Error occurred during initialization of VM
> agent library failed to init: instrument
> Error opening zip file: /opt/geronimo
> Error occurred during initialization of VM
> agent library failed to init: instrument

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

Re: [DISCUSS] Geronimo 2.0.3 release

[Kevan Miller]

On Feb 16, 2009, at 5:50 PM, Jay D. McHugh wrote:


Hello all,

I did some work on trying to get a 2.0.3 release that would:
a) build - sucess!
b) pass the TCK - Massive failure (over 5000 tests)

So, considering that we have a 2.1.x and 2.2.x codestream in progress
with JEE6 breathing down our necks - I have been officially pushed  
into

the 'we should probably just document what it takes to upgrade' group.

Are there any folks who truly need to stay on 2.0?

Or would it be reasonable to make a pronouncement that the 2.0.x
codestream is no longer going to be maintained - even for bug fixes  
and

security issues?

Thoughts/comments?

(I'll start documenting the libraries/jars that have changed or been
removed - we will need that regardless)



There should be discussion of this on our user list. Could you start a  
discussion there?


I'm ok with this. Confess that I'm a bit curious about why we'd have  
tck failures. I don't have a big issue with it, but in general we  
don't discuss tck specifics (including numbers of tests, etc) on a  
public list.


--kevan 
 

Re: [VOTE] Release gshell 1.0-alpha2

[Donald Woods]

+1


-Donald


Guillaume Nodet wrote:

I've uploaded a release of gshell 1.0-alpha2.

The staging repo is available at:
  http://people.apache.org/~gnodet/staging/gshell-1.0-alpha2
The svn tag is:
  https://svn.apache.org/repos/asf/geronimo/gshell/tags/gshell-1.0-alpha-2/

Please review and vote !

 [ ] +1 Release gshell-1.0-alpha2
 [ ] -1 Do not

Re: [DISCUSS] Geronimo 2.0.3 release

[Donald Woods]

Pushing users to 2.1.x for continued maintenance releases sounds fine to me.


-Donald


Jay D. McHugh wrote:

Hello all,

I did some work on trying to get a 2.0.3 release that would:
a) build - sucess!
b) pass the TCK - Massive failure (over 5000 tests)

So, considering that we have a 2.1.x and 2.2.x codestream in progress
with JEE6 breathing down our necks - I have been officially pushed into
the 'we should probably just document what it takes to upgrade' group.

Are there any folks who truly need to stay on 2.0?

Or would it be reasonable to make a pronouncement that the 2.0.x
codestream is no longer going to be maintained - even for bug fixes and
security issues?

Thoughts/comments?

(I'll start documenting the libraries/jars that have changed or been
removed - we will need that regardless)

Jay

Joe Bohn wrote:

I guess I should resolve this discussion on "if" we should release 2.0.3
that I started.

Thank you both Jay and Donald for your responses. I'm not completely
opposed to a 2.0.3 release.  I was just wondering aloud if it was the
best use of our resources and if it conveyed the right message to our
users.  I was also wondering a little if it might create more problems
for our users than it solves.  You know the drill ... upgrade from one
maintenance release to another only to discover yet another issue that
then forces you to a new version like 2.1.* because it isn't resolved in
the current maintenance stream.  If it weren't for the security issues I
would see no value in a 2.0.3 release.  Anyway, I am certainly not
planning to stand in the way of a 2.0.3 release.  I'll even do my part
to validate the images and help where I can.  However, my gut still
tells me that we might creating more problems than we are solving. But
since I'm the only one that feels that way I'm not too worried (I've
been wrong plenty of times before ;-) ).

It sounds like we still need to document what is necessary to move from
2.0.* to 2.1.* in any case.  I guess the first step might be adding the
libraries that are no longer included in 2.1.* into the list in the wiki
under http://cwiki.apache.org/GMOxDOC21/what-changed-in-21.html.  Does
anybody have a complete list of these libraries?  We'll probably still
need more specific documentation to make it clear what a user might have
to do when moving from 2.0.* to 2.1.*.  Perhaps another page somewhere
(similar to those under "Migrating to Apache Geronimo")?

Joe


Donald Woods wrote:

I think releasing 2.0.3 is in the best interest of the community,
given the security fixes that it contains.  It also gives us a way to
announce to our users that this will be the last 2.0.x release (which
we never really did for 1.1.x) and that they should start moving to
2.1.x or 2.2 for any new projects.


-Donald


Joe Bohn wrote:

I apologize for not raising this question on the earlier thread.

I'm wondering if it is a good idea to release a 2.0.3 at this point
in time.  We've had several releases of 2.1.x (four) and we'll
hopefully release 2.2 in the not too distant future.  I'm a little
concerned that releasing a 2.0.3 now will just encourage people to
continue on the 2.0.* base rather than taking the plunge and moving
up to 2.1.*.  It's been a year since we released 2.0.2 and in
addition to the security fixes there have been a lot of other
fixes/enhancements in the 2.1 branch.

What are the big stumbling blocks that prevent a user from moving
from 2.0.2 to 2.1.3 to resolve the security concerns?

Rather than releasing 2.0.3, should we maybe consider a greater focus
on ensuring there is a smooth migration path from 2.0.2 to 2.1.3? 
Once we have clearly identified any issues and ensured that we have

adequate directions we could notify the user community that there
will be no further 2.0.* releases and encourage them to move to
2.1.3.  It might actually be easier for us to release 2.0.3 in the
short term, but sooner or later users will have to address the
migration issues ... so I'm just wondering if it might be a better
use of our time to address those migration issues now.

Joe

Jay D. McHugh wrote:

The 2.0.x brach got sidelined by an intermittent
ConcurrentModificationException during stress testing.  But, recently
there were a number of security issues found that apply to 2.0.2.

So, I think it's time to start the discussion for a Geronimo 2.0.3
release (It actually already was started).

Server fixes/enhancements are listed on the Release Status page
(work in
progress)-
http://cwiki.apache.org/GMOxPMGT/geronimo-203-release-status.html

Details on included security fixes in dependent components are
listed on
the Security page -
http://geronimo.apache.org/20x-security-report.html

I have already begun moving issues into 2.0.4 - Does anyone have
additional fixes they would like to include in 2.0.3 before we cut the
branch and start the release process?

If I have moved an issue that you want to work on (And you have time to
work on it right away) move it back onto a 2.0.3 fix and 

Re: svn commit: r712385 - /geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/bin/geronimo.sh

[Jack Cai]

Thanks Kevan for catching this! I've provided a new fix - it's clumsy, but
it works now.

-Jack

2009/2/17 Kevan Miller 

> This change has broken -javaagent processing on my Mac OS X system.
> JAVA_AGENT_OPTS will never be set and as a result we'll never run with the
> OpenJPA runtime enhancer.
> Does it work on Linux or any other unix-based system?
>
> Start geronimo ('startup.sh' or 'geronimo.sh run') and check to see what
> parameters have been passed to java. With this change, it looks like:
>
> bash-3.2$ ps auxww | grep server.jar
> kevan 7245  67.5  2.4  2997696 102400   p0  R+   10:40PM   0:08.80
> /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java
> -Dorg.apache.geronimo.home.dir=/Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT
> -Djava.endorsed.dirs=/Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT/lib/endorsed:/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/lib/endorsed
> -Djava.ext.dirs=/Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT/lib/ext:/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/lib/ext
> -Djava.io.tmpdir=var/temp -jar
> /Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT/bin/server.jar
>
> Without the change, it correctly sets -javaagent:
>
> bash-3.2$ ps auxww | grep server.jar
> kevan17952  128.4  5.0  3074220 209992   p0  R+   11:16PM   0:20.85
> /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java
> -javaagent:/Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT/bin/jpa.jar
> -Dorg.apache.geronimo.home.dir=/Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT
> -Djava.endorsed.dirs=/Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT/lib/endorsed:/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/lib/endorsed
> -Djava.ext.dirs=/Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT/lib/ext:/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/lib/ext
> -Djava.io.tmpdir=var/temp -jar
> /Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT/bin/server.jar
>
> --kevan
>
>
> On Nov 8, 2008, at 7:48 AM, dwo...@apache.org wrote:
>
> Author: dwoods
> Date: Sat Nov  8 04:48:12 2008
> New Revision: 712385
>
> URL: http://svn.apache.org/viewvc?rev=712385&view=rev
> Log:
> GERONIMO-4389 updated patch from Jack
>
> Modified:
>
>
> geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/bin/geronimo.sh
>
> Modified:
> geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/bin/geronimo.sh
> URL:
> http://svn.apache.org/viewvc/geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/bin/geronimo.sh?rev=712385&r1=712384&r2=712385&view=diff
>
> ==
> ---
> geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/bin/geronimo.sh
> (original)
> +++
> geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/bin/geronimo.sh
> Sat Nov  8 04:48:12 2008
> @@ -284,7 +284,7 @@
> fi
>
> # Setup the Java programming language agent
> -JAVA_AGENT_JAR="$GERONIMO_BASE/bin/jpa.jar"
> +JAVA_AGENT_JAR="\"$GERONIMO_BASE/bin/jpa.jar\""
> if [ -f "$JAVA_AGENT_JAR" ]; then
> JAVA_AGENT_OPTS="-javaagent:$JAVA_AGENT_JAR"
> else
> @@ -314,7 +314,7 @@
> elif [ "$1" = "run" ]; then
>   shift
>   exec "$_RUNJAVA" $JAVA_OPTS $GERONIMO_OPTS \
> -"$JAVA_AGENT_OPTS" \
> +$JAVA_AGENT_OPTS \
> -Dorg.apache.geronimo.base.dir="$GERONIMO_BASE" \
> -Djava.endorsed.dirs="$ENDORSED_DIRS" \
> -Djava.ext.dirs="$EXT_DIRS" \
> @@ -325,7 +325,7 @@
>   shift
>   touch "$GERONIMO_OUT"
>   $START_OS_CMD "$_RUNJAVA" $JAVA_OPTS $GERONIMO_OPTS \
> -"$JAVA_AGENT_OPTS" \
> +$JAVA_AGENT_OPTS \
> -Dorg.apache.geronimo.base.dir="$GERONIMO_BASE" \
> -Djava.endorsed.dirs="$ENDORSED_DIRS" \
> -Djava.ext.dirs="$EXT_DIRS" \
>
>
>
>

[jira] Commented: (GERONIMO-4537) Enable geronimo windows service to wrap non-default server instance

[Jack Cai (JIRA)]

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

Jack Cai commented on GERONIMO-4537:


The port specified here is only used to shut down the server.

The service_pr.bat does not read JAVA_OPTS nor GERONIMO_OPTS. But users can 
easily use the geronimosrvw.exe tool to add additional command-line parameters 
that shall be used to start/stop the service. I've updated the doc to clarify 
this: 
http://cwiki.apache.org/confluence/display/GMOxDOC22/Running+Geronimo+as+a+Service

Does this help?

> Enable geronimo windows service to wrap non-default server instance
> ---
>
> Key: GERONIMO-4537
> URL: https://issues.apache.org/jira/browse/GERONIMO-4537
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 2.1.4, 2.2
> Environment: Any windows
>Reporter: Forrest Xia
>Assignee: Jack Cai
>Priority: Minor
>
> For ACD method, the service_pr.bat does not honor GERONIMO_OPTS variable, we 
> cannot use it to wrap a non-default server instance as a windows service. 
> The installed geronimosrv service will always start the default instance, 
> even we use a command line as following:
>   service_pr.bat install --port 1109 --user system --password manager

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

[jira] Updated: (GERONIMO-4389) Can't start server when install it in a directory containing space

[Jack Cai (JIRA)]

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

Jack Cai updated GERONIMO-4389:
---

Attachment: Geronimo-4389_Jack0217.patch

Providing a clumsy fix, but it worked (verified).

> Can't start server when install it in a directory containing space
> --
>
> Key: GERONIMO-4389
> URL: https://issues.apache.org/jira/browse/GERONIMO-4389
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: startup/shutdown
>Affects Versions: 2.1.3, 2.2
> Environment: OS:Solaris 10 Sparc
>Reporter: viola.lu
>Assignee: Jack Cai
>Priority: Blocker
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4389_Jack.patch, Geronimo-4389_Jack0217.patch, 
> Geronimo-4389_Jack1108.patch
>
>
> Steps:
> 1.Install geronimo into /opt/geronimo 2.1.3
> 2.Start server
> Errors popup
> [r...@cesolaris bin]#tail -f ../var/log/geronimo.out
> Error opening zip file: /opt/geronimo
> Error occurred during initialization of VM
> agent library failed to init: instrument
> Error opening zip file: /opt/geronimo
> Error occurred during initialization of VM
> agent library failed to init: instrument

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