Re: Geronimo on Docker?
Someone made one 4 months ago. https://github.com/jaxzin/docker-geronimo -RG - Original Message - From: Alan D. Cabrera l...@toolazydogs.com To: geronimo-dev dev@geronimo.apache.org Sent: Wednesday, April 1, 2015 11:37:42 AM Subject: Geronimo on Docker? I think that it would be pretty cool if we had Geronimo on Docker. How would we structure our images? Regards, Alan
Re: Board report time 2015-04
Looking at this from an angle of enterprise management, I always liked the following features about Geronimo: 1) I can load any service as a gbean on top of Geronimo, and run it. This includes: Tomcat, Jetty, or even Apache JAMES. In fact, I could run Apache JAMES by itself inside Geronimo without Tomcat or Jetty. When the first example JAMES gbean was discussed, I was happy to see it. I wished it had gone somewhere. I think this feature points at the OSGi - being able to load and manage services on top of the kernel. 2) With Geronimo, I don't have to run tomcat on top of the tanuki wrapper (http://wrapper.tanukisoftware.com/). Tomcat is shipped without any kind of watchdog. Running it in the enterprise requires some kind of active monitoring to make sure it keeps running. Geronimo meets this need. 3) Geronimo was working towards being friendly in Web Server Farm management. It was having a model that allowed configuration to be pushed out from a central maven-like repository. 4) Geronimo works with a maven-like repository. For building, installing, distributing, and maintaining components and applications in Geronimo, its adherence to a maven model makes that really structured and more understandable as we integrate other things into Geronimo. 5) Geronimo instances. At one time Geronimo allowed multiple instances, then later in version 3 it did not, then I contributed to get multiple instance working again, then the project team started discussing changes that would not allow that again. Okay, with today's docker/component standard, perhaps multiple instance support is not as necessary. However, I still think it is a good feature to have. One should be able to install Geronimo one time, after which they should be able to create and destroy multiple instances at will without a lot of heavy lifting. In the enterprise, we want to run different services in their own JVM, but we do not necessarily want to have to install and configure the entire Geronimo package every time. We want to install Geronimo only once on a server - especially when we are talking about web farm management, we want one admin node on one server to proxy-manage all local instances. -RG - Original Message - From: Mark Struberg strub...@yahoo.de To: geronimo-dev dev@geronimo.apache.org Sent: Tuesday, April 7, 2015 2:25:54 AM Subject: Re: Board report time 2015-04 It’s not only the spec-api stuff. There are also many other things like xbean, geronimo-jta, javamail, etc. It’s basically a commons-EE atm. If you talk about a reboot then I wonder what you had in mind. There is TomEE which takes the really lightweight approach. And having two implementations providing the same doesn’t make sense. At least not if there are exactly the same people involved… Should the Geronimo-Server focus on OSGi? That is what made the big difference so far. No clue otherwise. LieGrue, strub Am 07.04.2015 um 08:10 schrieb Alan D. Cabrera l...@toolazydogs.com: I agree, we should start moving our focus. When you speak of #2, what bits do you speak of? The glue that assembles the various JSR implementations of the JEE spec? I wonder if we should start a total re-write. We’ve learned a thing or two since this project started and the current Zeitgeist for server software has moved on. I think it’s an exciting time to take a fresh look at Geronimo and to “re-imagine” it. If you all agree, what to keep and what to re-write? Regards, Alan On Apr 6, 2015, at 7:50 AM, Mark Struberg strub...@yahoo.de wrote: Txs Alan! I think we should probably move our focus finally? The Geronimo project basically consists of 2 different things. 1.) the Geronimo EE server 2.) all the rest ;) 2 is doing really fine. 1 is worrying. Or are there any significant people interested in continueing with 1? Should we reflect this in the report? LieGrue, strub Am 04.04.2015 um 20:36 schrieb Alan D. Cabrera l...@toolazydogs.com: Here's my initial draft: https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2015-04+-+April If I missed something please let me know or go ahead and update the page directly. Regards, Alan
[jira] [Commented] (GERONIMO-6324) Cannot deploy with remote server
[
https://issues.apache.org/jira/browse/GERONIMO-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253646#comment-13253646
]
Russell E Glaue commented on GERONIMO-6324:
---
The error is from a core java object java.net. The port 1099 cannot be
connected to.
So discover if these things are correct on your system:
1. You do not have a local firewall running that would block access to port 1099
2. The startup output from Geronimo reports that the RMI port has successfully
bound to port 1099
Since the connection was refused, there is either a firewall blocking access to
port 1099 on the specified xxx.xxx.xxx.xxx IP Address, or Geronimo's RMI
service is not listening on port 1099.
Cannot deploy with remote server
Key: GERONIMO-6324
URL: https://issues.apache.org/jira/browse/GERONIMO-6324
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 3.0-beta-1
Environment: Remote server running Ubuntu 10.04
Local development machine running OSX 10.7.2
Reporter: Josh Fee
Labels: deploy, remote
Attempt to run deploy command for a remote server times out. At some point
the hostname is lost and changed to 127.0.1.1
{code}
$ ./deploy -host xxx.xxx.xxx.xxx list-modules
Using GERONIMO_HOME:
/Users/joshfee/Development/geronimo-tomcat7-javaee6-3.0-beta-1
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:/System/Library/Frameworks/JavaVM.framework/Home
Username: system
Password: ***
2012-04-13 12:28:57,446 ERROR [DeployTool] Error:
org.apache.geronimo.common.DeploymentException: Unable to connect to server
at deployer:geronimo:jmx://ee368s12.no-ip.org:1099 -- Connection refused to
host: 127.0.1.1; nested exception is:
java.net.ConnectException: Operation timed out
at
org.apache.geronimo.deployment.cli.OnlineServerConnection.tryToConnect(OnlineServerConnection.java:128)
at
org.apache.geronimo.deployment.cli.OnlineServerConnection.init(OnlineServerConnection.java:75)
at
org.apache.geronimo.deployment.cli.OnlineServerConnection.init(OnlineServerConnection.java:50)
at
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:167)
at
org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64)
at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:32)
Caused by:
javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException:
Connection refused to host: 127.0.1.1; nested exception is:
java.net.ConnectException: Operation timed out
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:194)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:141)
at
javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManager.java:111)
at
org.apache.geronimo.deployment.cli.OnlineServerConnection.tryToConnect(OnlineServerConnection.java:122)
... 7 more
Caused by: java.rmi.ConnectException: Connection refused to host: 127.0.1.1;
nested exception is:
java.net.ConnectException: Operation timed out
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:110)
at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown
Source)
at
javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2327)
at
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:277)
at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:186)
... 10 more
Caused by: java.net.ConnectException: Operation timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect
[jira] [Commented] (GERONIMO-6324) Cannot deploy with remote server
[
https://issues.apache.org/jira/browse/GERONIMO-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253699#comment-13253699
]
Russell E Glaue commented on GERONIMO-6324:
---
The error message you provided states Connection refused to host: 127.0.1.1
127.0.1.1 is used for the local-loopback.
This would suggest that jmx://ee368s12.no-ip.org:1099 and 127.0.1.1:1099 are
the same.
Perhaps you have the domain ee368s12.no-ip.org configured in /etc/hosts for
127.0.1.1 ?
The error you have received would explain a scenario where ee368s12.no-ip.org
is a remote server as you say, but you have the domain configured locally to
resolve to 127.0.1.1 .
Cannot deploy with remote server
Key: GERONIMO-6324
URL: https://issues.apache.org/jira/browse/GERONIMO-6324
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 3.0-beta-1
Environment: Remote server running Ubuntu 10.04
Local development machine running OSX 10.7.2
Reporter: Josh Fee
Labels: deploy, remote
Attempt to run deploy command for a remote server times out. At some point
the hostname is lost and changed to 127.0.1.1
{code}
$ ./deploy -host xxx.xxx.xxx.xxx list-modules
Using GERONIMO_HOME:
/Users/joshfee/Development/geronimo-tomcat7-javaee6-3.0-beta-1
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:/System/Library/Frameworks/JavaVM.framework/Home
Username: system
Password: ***
2012-04-13 12:28:57,446 ERROR [DeployTool] Error:
org.apache.geronimo.common.DeploymentException: Unable to connect to server
at deployer:geronimo:jmx://ee368s12.no-ip.org:1099 -- Connection refused to
host: 127.0.1.1; nested exception is:
java.net.ConnectException: Operation timed out
at
org.apache.geronimo.deployment.cli.OnlineServerConnection.tryToConnect(OnlineServerConnection.java:128)
at
org.apache.geronimo.deployment.cli.OnlineServerConnection.init(OnlineServerConnection.java:75)
at
org.apache.geronimo.deployment.cli.OnlineServerConnection.init(OnlineServerConnection.java:50)
at
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:167)
at
org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64)
at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:32)
Caused by:
javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException:
Connection refused to host: 127.0.1.1; nested exception is:
java.net.ConnectException: Operation timed out
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:194)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:141)
at
javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManager.java:111)
at
org.apache.geronimo.deployment.cli.OnlineServerConnection.tryToConnect(OnlineServerConnection.java:122)
... 7 more
Caused by: java.rmi.ConnectException: Connection refused to host: 127.0.1.1;
nested exception is:
java.net.ConnectException: Operation timed out
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:110)
at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown
Source)
at
javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2327)
at
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:277)
at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:186)
... 10 more
Caused by: java.net.ConnectException: Operation timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.init
Re: Regarding GERONIMO-6317 Profiling clustering modules to save build time
On 04/05/2012 02:49 PM, Kevan Miller wrote: On Apr 5, 2012, at 9:50 AM, Russell E Glaue wrote: Clustering features are not available in the current 3.0-beta branch, so add some profiles to not build it, thus save the build time. Is commit 1309635 related to this? Is someone able to explain why WADI Clustering and Plugin Farming are not available in the 3.0-beta branch? Is it broken? Hi Russell, The WADI project seems to be largely dormant. Without anyone willing to bring the function forward, I don't think anyone has looked at trying to get it to work on a 3.0 base. Is WADI important to you? --kevan I'm wanting to get Geronimo up in my employer's web farms, and finally getting multiple instance support was a huge step forward for me. But now removing support for clustering is a step backward. We had been planning on its use. Some mechanism is important to anyone who wants web user sessions to have persistence among multiple clustered/loadbalanced Geronimo servers. And we have had (used to anyway) lots of conversations on the importance of Geronimo clustering capabilities and how to do it. https://cwiki.apache.org/GMOxDEV/clustering-initial-discussion.html Yes.., we can use other 3rd party like Terracotta, but that does not make Geronimo enterprise-ready out-of-the-box. And the terracotta plugin is probably not updated for 3.0. https://cwiki.apache.org/GMOxDEV/clustering-geronimo-with-open-terracotta.html If we remove WADI support, will we replace it with some other mechanism to share web user sessions among Geronimo instances? Or will we tell users to rely on tomcat's and jetty's native session replication and management? This alternative will not be a clean configuration, since the changes would have manually to go into tomcat and jetty server config files - not deployed as plans. -RG
[jira] [Commented] (GERONIMO-6320) Downloads for Linux/Mac (tar.gz) at http://geronimo.apache.org/apache-geronimo-v221-release.html contains a compressed web page, not a tar file
[ https://issues.apache.org/jira/browse/GERONIMO-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248412#comment-13248412 ] Russell E Glaue commented on GERONIMO-6320: --- I have verified this on Safari 5 on Mac OS X 10.5.8 regarding the link: http://www.apache.org/dyn/closer.cgi/geronimo/2.2.1/geronimo-jetty7-javaee5-2.2.1-bin.tar.gz It exhibits the bug reported https://bugs.webkit.org/show_bug.cgi?id=32262 Adding a 1 to the end of the url brings up an HTML page proving that a URL ending with tar.gz or gz is handled specially by MacOSX/Safari and is not the web site. Using Firefox 3 on Mac OS X 10.5.8 for this link works normally. -RG Downloads for Linux/Mac (tar.gz) at http://geronimo.apache.org/apache-geronimo-v221-release.html contains a compressed web page, not a tar file --- Key: GERONIMO-6320 URL: https://issues.apache.org/jira/browse/GERONIMO-6320 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: website Affects Versions: 2.2.1 Environment: Apache Geronimo web site download page for 2.2.1 Reporter: John Plocher On the web page: http://geronimo.apache.org/apache-geronimo-v221-release.html Platform Download Link PGP SHA MD5 Linux/Mac OS X/Unix Downloads (TAR) Geronimo 2.2.1 with Jetty 7 (tar.gz) PGP SHA MD5 Linux/Mac OS X/Unix Downloads (TAR) Geronimo 2.2.1 with Tomcat 6 (tar.gz) PGP SHA MD5 The download links http://www.apache.org/dyn/closer.cgi/geronimo/2.2.1/geronimo-jetty7-javaee5-2.2.1-bin.tar.gz http://www.apache.org/dyn/closer.cgi/geronimo/2.2.1/geronimo-tomcat6-javaee5-2.2.1-bin.tar.gz give gz compressed html pages, not tar archives... -bash-3.2$ gunzip geronimo-jetty7-javaee5-2.2.1-bin.tar.gz -bash-3.2$ file geronimo-jetty7-javaee5-2.2.1-bin.tar geronimo-jetty7-javaee5-2.2.1-bin.tar: HTML document text !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html lang=en head titleApache Download Mirrors/title ... The normal apache mirror sites seem to have the correct tar.gz files/content... -bash-3.2$ file geronimo-jetty7-javaee5-2.2.1-bin-mirror.tar geronimo-jetty7-javaee5-2.2.1-bin-mirror.tar: POSIX tar archive -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Regarding GERONIMO-6317 Profiling clustering modules to save build time
On 04/06/2012 10:11 AM, Kevan Miller wrote: On Apr 6, 2012, at 10:47 AM, Russell E Glaue wrote: On 04/05/2012 02:49 PM, Kevan Miller wrote: On Apr 5, 2012, at 9:50 AM, Russell E Glaue wrote: Clustering features are not available in the current 3.0-beta branch, so add some profiles to not build it, thus save the build time. Is commit 1309635 related to this? Is someone able to explain why WADI Clustering and Plugin Farming are not available in the 3.0-beta branch? Is it broken? Hi Russell, The WADI project seems to be largely dormant. Without anyone willing to bring the function forward, I don't think anyone has looked at trying to get it to work on a 3.0 base. Is WADI important to you? --kevan I'm wanting to get Geronimo up in my employer's web farms, and finally getting multiple instance support was a huge step forward for me. But now removing support for clustering is a step backward. We had been planning on its use. Some mechanism is important to anyone who wants web user sessions to have persistence among multiple clustered/loadbalanced Geronimo servers. And we have had (used to anyway) lots of conversations on the importance of Geronimo clustering capabilities and how to do it. https://cwiki.apache.org/GMOxDEV/clustering-initial-discussion.html Yes.., we can use other 3rd party like Terracotta, but that does not make Geronimo enterprise-ready out-of-the-box. And the terracotta plugin is probably not updated for 3.0. https://cwiki.apache.org/GMOxDEV/clustering-geronimo-with-open-terracotta.html If we remove WADI support, will we replace it with some other mechanism to share web user sessions among Geronimo instances? Or will we tell users to rely on tomcat's and jetty's native session replication and management? This alternative will not be a clean configuration, since the changes would have manually to go into tomcat and jetty server config files - not deployed as plans. OK. So, for session replication, most people that I know of use Tomcat native clustering (https://cwiki.apache.org/GMOxDOC30/tomcat-native-clustering.html). Does that not work for you? If we can go into specific issues, that would be great... Great conversation to be having. Thanks! --kevan It is not that the tomcat alternative is not going to work for me. What I said about that was This alternative will not be a clean configuration, since the changes would have to manually go into tomcat and jetty server config files - not deployed as plans. After Forest and I got the multiple-instance support squared away for Geronimo, I have been working towards how to configure Geronimo by only deploying plans, and documenting it (I had been updating the Geronimo wiki as I go along - but got side tracked recently). This is currently the needed procedure for remote configuration. The document, https://cwiki.apache.org/GMOxDOC30/tomcat-native-clustering.html (which seems to be discussing Tomcat 6) discusses how you must manually edit the server.xml file to configure the engine. There is thin if no documentation on bundling server config file in like a car to deploy along with a plan. But I guess we'd have to do it that way if we stick to the native tomcat/jetty approaches to having clustering in Geronimo. Thoughts? -RG
Re: Regarding GERONIMO-6317 Profiling clustering modules to save build time
On 04/06/2012 10:11 AM, Kevan Miller wrote: On Apr 6, 2012, at 10:47 AM, Russell E Glaue wrote: On 04/05/2012 02:49 PM, Kevan Miller wrote: On Apr 5, 2012, at 9:50 AM, Russell E Glaue wrote: Clustering features are not available in the current 3.0-beta branch, so add some profiles to not build it, thus save the build time. Is commit 1309635 related to this? Is someone able to explain why WADI Clustering and Plugin Farming are not available in the 3.0-beta branch? Is it broken? Hi Russell, The WADI project seems to be largely dormant. Without anyone willing to bring the function forward, I don't think anyone has looked at trying to get it to work on a 3.0 base. Is WADI important to you? --kevan I'm wanting to get Geronimo up in my employer's web farms, and finally getting multiple instance support was a huge step forward for me. But now removing support for clustering is a step backward. We had been planning on its use. Some mechanism is important to anyone who wants web user sessions to have persistence among multiple clustered/loadbalanced Geronimo servers. And we have had (used to anyway) lots of conversations on the importance of Geronimo clustering capabilities and how to do it. https://cwiki.apache.org/GMOxDEV/clustering-initial-discussion.html Yes.., we can use other 3rd party like Terracotta, but that does not make Geronimo enterprise-ready out-of-the-box. And the terracotta plugin is probably not updated for 3.0. https://cwiki.apache.org/GMOxDEV/clustering-geronimo-with-open-terracotta.html If we remove WADI support, will we replace it with some other mechanism to share web user sessions among Geronimo instances? Or will we tell users to rely on tomcat's and jetty's native session replication and management? This alternative will not be a clean configuration, since the changes would have manually to go into tomcat and jetty server config files - not deployed as plans. OK. So, for session replication, most people that I know of use Tomcat native clustering (https://cwiki.apache.org/GMOxDOC30/tomcat-native-clustering.html). Does that not work for you? If we can go into specific issues, that would be great... Great conversation to be having. Thanks! --kevan Please correct me if I am wrong, Is not the WADI support providing one configuration for clustering all deployed tomcat containers in a single Geronimo instance? But if we use the tomcat default clustering support, we have to configure it on a per-container basis, even when multiple containers operate in the same Geronimo run-time instance? -- So it I have five containers configured in a single instance, each will have to be configured individually for clustering. The prior WADI support shares the session clustering among all containers, and the later requires each container to instantiate its own independent clustering - which is more overhead when compared to the prior option. I'm not necessarily a big supporter of WADI, and am definitely ready to accept alternatives. I would just like there to be a comparably good and well documented alternative - even if it is me writing the documentation, which I am willing. I agree that having to support WADI integration in Geronimo source is more work when the typical user will be fine with, and probably prefer, the default Tomcat clustering. Especially with the WADI project not being active. Now having discussed the benefits of WADI as a better geronimo solution, do we have a desire to provide that level of benefit with some alternate solution that can be used in place of WADI? I appreciate this discussion. I want to continue to keep Enterprise Geronimo Usability at the top of the discussion list. -RG
Regarding GERONIMO-6317 Profiling clustering modules to save build time
Clustering features are not available in the current 3.0-beta branch, so add some profiles to not build it, thus save the build time. Is commit 1309635 related to this? Is someone able to explain why WADI Clustering and Plugin Farming are not available in the 3.0-beta branch? Is it broken? -RG
Re: Geronimo release cycle
Thanks for the clarification. It is probably time for us to stamp the 3.0-beta branch as either 3.0-beta-2 or 3.0 full release any way. We have made some significant advances in 3.0-beta-2 development. -RG On 03/29/2012 07:41 AM, Arsen Abdrakhmanov wrote: Dear Team, Thank you very much for your attention to my request and please, let me give small comment regarding my previous message. Frankly speaking, I have meant primarily the release cycle for 2.1.x and 2.2.x versions of Geronimo. We were not using the 3.0 version of Geronimo, as there was no stable non-beta release for it. Actually, we were using the 2.2.1 version of Geronimo in our previous project. For the moment, I am in position to make a decision for moving to the version 2.1.8 for new project, as the release is much newer. The question was, that if the minor versions were released at least semi-annually, it would be very usefull for us in terms of access to bug-fixed versions. In this case, we would never discuss in our company the variants with downgrade to previous major version of application server. Regarding the 3.0 version of Geronimo, I would be glad to use it in upcoming projects, but if the newer minor versions of 3.0.x could be released more frequently. Hope, you got my idea. Sorry for inconveniences caused. Best regards, Arsen Abdrakhmanov 2012/3/27 Arsen Abdrakhmanov arsen.abdrakhma...@gmail.com mailto:arsen.abdrakhma...@gmail.com Dear Geronimo Team, Actually, I am the fan of geronimo for more than 5 years already. For the moment, I am promoting the usage of Geronimo as a platform for non-critical applications in our company (banking industry in KZ). According to our company's internal policy, only official releases of open-source software products can be used for internal applications. Currently, the release cycle for Geronimo is about an year or even longer, so it takes significant amount of time before we could use an updated version of software with bug fixes and enhancements. Taking that into account, can you give any information on your plans to accelerate the release cycle for new versions of Geronimo? I think, it would be very useful for the whole geronimo user community, if the releases were published at least semi-anually. Hope, it can also increase the popularity of Geronimo among other application servers. Best regards, Arsen Abdrakhmanov
[jira] [Commented] (GERONIMO-6287) Server instance which created by gogo command deploy:new-server-instance can't be started
[
https://issues.apache.org/jira/browse/GERONIMO-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240477#comment-13240477
]
Russell E Glaue commented on GERONIMO-6287:
---
I agree with the patch GERONIMO-5164/new-instance+30.patch
It creates/copies {{var}} and {{etc}}
And only creates {{repository}}
With changes provided in GERONIMO-6270, the {{repository}} directory gets
created automatically on server startup if it does not exist.
I would remove the comment in the patch that reads:
{code}
+//?? repository folder needed by karaf, but don't know why ?
{code}
Karaf requires a repository local to the base path of the geronimo server
instance. Karaf specifically looks for it on startup, but does nothing with it.
We have the {{o.a.g.server.dir/repository}} configured in
o.a.g.server.dir/etc/org.ops4j.pax.url.mvn.cfg as:
{code}
org.ops4j.pax.url.mvn.defaultRepositories=file:${karaf.home}/repository@snapshots,file:${karaf.base}/repository@snapshots
{code}
Karaf looks for artifacts to deploy from one repository if the server is a
single server, or two repositories if the server is one of multiple instances.
When running multiple instance {{karaf.home/repository}} is the read-only
bootstrap repository, and {{karaf.base/repository}} is the read-write local
deploy repository for the specific geronimo instance.
It is not safe for multiple instances to deploy to the same bootstrap
repository, as one instance's deployment will be seen by another. So we need to
separate out local repositories for each instance to deploy to.
If a comment is desired, I recommend this:
{code}
+//the repository folder is needed for local deployments, defined in
etc/org.ops4j.pax.url.mvn.cfg
+//we want to deploy artifacts specific to the instance to this local
repository, not the shared bootstrap repository
{code}
Server instance which created by gogo command deploy:new-server-instance
can't be started
Key: GERONIMO-6287
URL: https://issues.apache.org/jira/browse/GERONIMO-6287
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands, osgi
Affects Versions: 3.0-beta-1
Environment: JDK6 SR10
Redhat 6.1 x86_64 GNU/Linux
Build: 2012.02.23
Reporter: Tina Li
Assignee: xiezhi
Priority: Minor
Attachments: gogoCommand.patch
Steps:
1. Start geronimo successfully using ./geronimo.sh run
2. Using gogo command to create a new instance named inst1:
geronimo deploy:new-server-instance inst1
Connection established
Server created
3.Change the PortOffset of the new instance
4. Try to start the server instance:
$ export GERONIMO_SERVER=inst1
$ bin/geronimo.sh run -l
5. But failed to start:
Error launching framework: java.lang.IllegalArgumentException: Property
karaf.framework must be set in the etc/config.properties configuration file
6.Check the content under geronimo_home/inst1, only /var existed but /etc
missing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (GERONIMO-6287) Server instance which created by gogo command deploy:new-server-instance can't be started
[
https://issues.apache.org/jira/browse/GERONIMO-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240477#comment-13240477
]
Russell E Glaue edited comment on GERONIMO-6287 at 3/28/12 3:40 PM:
I agree with the patch GERONIMO-5164/new-instance+30.patch
It creates/copies {{var}} and {{etc}}
And only creates {{repository}}
With changes provided in GERONIMO-6270, the {{repository}} directory gets
created automatically on server startup if it does not exist.
I would remove the comment in the patch that reads:
{code}
+//?? repository folder needed by karaf, but don't know why ?
{code}
Karaf requires a repository local to the base path of the geronimo server
instance. Karaf specifically looks for it on startup. It is intended that it be
used for artifacts locally deployed to this geronimo instance being created -
we do not want to deploy instance specific artifacts to the bootstrap
repository which is shared among all instances in a multi-instance run-time
configuration.
We describe reasoning in the Geronimo 30 docs:
https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html
We have the {{o.a.g.server.dir/repository}} configured in
o.a.g.server.dir/etc/org.ops4j.pax.url.mvn.cfg as:
{code}
org.ops4j.pax.url.mvn.defaultRepositories=file:${karaf.home}/repository@snapshots,file:${karaf.base}/repository@snapshots
{code}
Karaf looks for artifacts to deploy from one repository if the server is a
single server, or two repositories if the server is one of multiple instances.
When running multiple instance {{karaf.home/repository}} is the read-only
bootstrap repository, and {{karaf.base/repository}} is the read-write local
deploy repository for the specific geronimo instance.
It is not safe for multiple instances to deploy to the same bootstrap
repository, as one instance's deployment will be seen by another. So we need to
separate out local repositories for each instance to deploy to.
If a comment is desired, I recommend this:
{code}
+//the repository folder is needed for local deployments, defined in
etc/org.ops4j.pax.url.mvn.cfg
+//we want to deploy artifacts specific to the instance to this local
repository, not the shared bootstrap repository
{code}
was (Author: rglaue):
I agree with the patch GERONIMO-5164/new-instance+30.patch
It creates/copies {{var}} and {{etc}}
And only creates {{repository}}
With changes provided in GERONIMO-6270, the {{repository}} directory gets
created automatically on server startup if it does not exist.
I would remove the comment in the patch that reads:
{code}
+//?? repository folder needed by karaf, but don't know why ?
{code}
Karaf requires a repository local to the base path of the geronimo server
instance. Karaf specifically looks for it on startup, but does nothing with it.
We have the {{o.a.g.server.dir/repository}} configured in
o.a.g.server.dir/etc/org.ops4j.pax.url.mvn.cfg as:
{code}
org.ops4j.pax.url.mvn.defaultRepositories=file:${karaf.home}/repository@snapshots,file:${karaf.base}/repository@snapshots
{code}
Karaf looks for artifacts to deploy from one repository if the server is a
single server, or two repositories if the server is one of multiple instances.
When running multiple instance {{karaf.home/repository}} is the read-only
bootstrap repository, and {{karaf.base/repository}} is the read-write local
deploy repository for the specific geronimo instance.
It is not safe for multiple instances to deploy to the same bootstrap
repository, as one instance's deployment will be seen by another. So we need to
separate out local repositories for each instance to deploy to.
If a comment is desired, I recommend this:
{code}
+//the repository folder is needed for local deployments, defined in
etc/org.ops4j.pax.url.mvn.cfg
+//we want to deploy artifacts specific to the instance to this local
repository, not the shared bootstrap repository
{code}
Server instance which created by gogo command deploy:new-server-instance
can't be started
Key: GERONIMO-6287
URL: https://issues.apache.org/jira/browse/GERONIMO-6287
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands, osgi
Affects Versions: 3.0-beta-1
Environment: JDK6 SR10
Redhat 6.1 x86_64 GNU/Linux
Build: 2012.02.23
Reporter: Tina Li
Assignee: xiezhi
Priority: Minor
Attachments: gogoCommand.patch
Steps:
1. Start geronimo successfully using ./geronimo.sh run
2. Using gogo command to create a new instance named inst1:
geronimo deploy:new-server-instance inst1
Connection established
Server
[jira] [Commented] (GERONIMO-5164) Incomplete feature for deploy:new-instance command in geronimo3.0
[
https://issues.apache.org/jira/browse/GERONIMO-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240483#comment-13240483
]
Russell E Glaue commented on GERONIMO-5164:
---
Regarding patch GERONIMO-5164/new-instance+30.patch
I would remove the comment in the patch that reads:
{code}
+//?? repository folder needed by karaf, but don't know why ?
{code}
If a comment is desired, I recommend this:
{code}
+//the repository folder is needed for local deployments, defined in
etc/org.ops4j.pax.url.mvn.cfg
+//we want to deploy artifacts specific to the instance to this local
repository, not the shared bootstrap repository
{code}
See also:
[GERONIMO-6287#comment-13240477|https://issues.apache.org/jira/browse/GERONIMO-6287?focusedCommentId=13240477page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13240477]
Incomplete feature for deploy:new-instance command in geronimo3.0
-
Key: GERONIMO-5164
URL: https://issues.apache.org/jira/browse/GERONIMO-5164
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 3.0
Environment: Windows XP
Reporter: Vanessa Wang
Assignee: Shawn Jiang
Priority: Minor
Fix For: 3.0
Attachments: new-instance 30.patch, start new-instance-server
command_30.patch
deploy/new-instance Command in geronimo previous version just copy var
folder.
In G30 with karaf, bin, etc, data, repository also need copied or created in
new instance folder.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo release cycle
move current trunk to 3.1 and change current beta branch to 3.0. +1 As long as 3.0-beta-2 passes Java EE 1.6 tests and also provides no broken core/primary functionality we have 2.2, we should stamp it as 3.0. 3.1 can focus on the continuation of 3.x enhancements. -RG On 03/28/2012 06:46 AM, Forrest Xia wrote: On Wed, Mar 28, 2012 at 6:08 PM, Shawn Jiang genspr...@gmail.com mailto:genspr...@gmail.com wrote: 1.x J2EE 1.4 2.0 Java EE 1.5 2.1 Java EE 1.5 2.2 Java EE 1.5 3.0 Java EE 1.6 Considering the previous practice, we'd better to move current trunk to 3.1 and change current beta branch to 3.0. Sounds good. Any more idea? On Tue, Mar 27, 2012 at 11:48 PM, Forrest Xia forres...@gmail.com mailto:forres...@gmail.com wrote: Saw this query, have an idea about the current release roadmap. 1. Can we move the current incomplete trunk work to version 4 of geronimo? 2. Rename 3.0-beta branch as the formal 3.0 release? Any thoughts? Forrest -- Forwarded message -- From: *Arsen Abdrakhmanov* arsen.abdrakhma...@gmail.com mailto:arsen.abdrakhma...@gmail.com Date: Tue, Mar 27, 2012 at 7:20 PM Subject: Geronimo release cycle To: u...@geronimo.apache.org mailto:u...@geronimo.apache.org Dear Geronimo Team, Actually, I am the fan of geronimo for more than 5 years already. For the moment, I am promoting the usage of Geronimo as a platform for non-critical applications in our company (banking industry in KZ). According to our company's internal policy, only official releases of open-source software products can be used for internal applications. Currently, the release cycle for Geronimo is about an year or even longer, so it takes significant amount of time before we could use an updated version of software with bug fixes and enhancements. Taking that into account, can you give any information on your plans to accelerate the release cycle for new versions of Geronimo? I think, it would be very useful for the whole geronimo user community, if the releases were published at least semi-anually. Hope, it can also increase the popularity of Geronimo among other application servers. Best regards, Arsen Abdrakhmanov -- Thanks! Regards, Forrest -- Shawn -- Thanks! Regards, Forrest
[jira] [Resolved] (GERONIMO-6174) Environment variables being set in bin/geronimo does not account for named server instances
[
https://issues.apache.org/jira/browse/GERONIMO-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue resolved GERONIMO-6174.
---
Resolution: Fixed
Fix Version/s: 3.0-beta-2
3.0
Assignee: Russell E Glaue
All remaining issues were resolved through GERONIMO-6270
Environment variables being set in bin/geronimo does not account for named
server instances
---
Key: GERONIMO-6174
URL: https://issues.apache.org/jira/browse/GERONIMO-6174
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 3.0
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Trivial
Labels: geronimo
Fix For: 3.0, 3.0-beta-2
I have been able to workaround these two issues by setting properties.
Questions:
1A) But should these properties be dynamically set relative to the named
instance directory instead of GERONIMO_HOME?
1B) Or do we require the user to explicitly set these in the environment in
order to start a named instance?
2) Does setting karaf.home in GERONIMO_OPTS as relative to the named instance
directory instead of GERONIMO_HOME potentially cause any other issues?
To produce these issues follow these steps:
1. Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
2. Create a Geronimo named instance directory as /opt/geronimo3/gserv1
3. Move the directories var, etc, and repository into /opt/geronimo3/gserv1
4. Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issue #1
#export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
#
# Uncomment for the Workaround of issue #2
#GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat}
1) GERONIMO_TMPDIR
On startup, the `bin/geronimo` startup script sets GERONIMO_TMPDIR explicitly
as
$GERONIMO_HOME/var/temp , but the actual temp directory is really
{org.apache.geronimo.server.dir}/var/temp (or
$GERONIMO_HOME/{org.apache.geronimo.server.name}/var/temp)
It does not account for the cases where an instance is being started.
{noformat:borderStyle=solid}
[user@system gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
Error launching framework: java.lang.IllegalArgumentException: Invalid
temporary directory. The '/opt/geronimo3/var/temp' path does not exist.
{noformat}
The workaround is to specifically specify GERONIMO_TMPDIR in your environment
before starting the instance.
2) karaf.home
On startup, the `bin/geronimo` script sets karaf.home explicitly as
$GERONIMO_HOME . Karaf expects to use {karaf.home}/etc/shell.init.script each
time a shell session is started (See:
geronimo/server/trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties).
The setting of the karaf.home property in `bin/geronimo` does not account for
the cases where a Geronimo named instance is being started.
{noformat:borderStyle=solid}
[root@rglaue7 gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
__ _
/ /___ _ (_) ___
/ / __ / _ \/ ___/ __ \/ __ \/ // __ `__ \/ __ \
/ /_/ // __/ / / /_/ / / / / // / / / / / /_/ /
\/ \___/_/ \/_/ /_/_//_/ /_/ /_/\/
Apache Geronimo (3.0-SNAPSHOT)
Hit 'tab' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo.
Error in initialization script: /opt/geronimo3/etc/shell.init.script (No such
file or directory)
... snip ...
{noformat}
The workaround is to set karaf.home in GERONIMO_OPTS before starting the
instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Build hangs in Geronimo Plugins, System Database :: System Database 3.0-SNAPSHOT
I have not been able to build 3.0 trunk as well. I have not reported it because I know that since the 3.0-beta-1 release we have been doing some heavy lifting in the code. Have you tried building the 3.0-beta branch instead? We are committing bug fixes to both trunk and 3.0-beta https://svn.apache.org/repos/asf/geronimo/server/branches/3.0-beta While 3.0 trunk is not able to be compiled, the nightly SNAPSHOT assemblies are also not available for trunk builds. https://repository.apache.org/content/groups/snapshots/org/apache/geronimo/assemblies/ (Note the .zip and .tar.gz files are from Dec 20) It would be nice if we could make nightly builds available for the 3.0-beta branch while Geronimo is in beta. It would help us help our community test our Beta progress. Without a nightly build, I believe it will prevent general involvement. -RG On 03/05/2012 04:53 PM, uromahn wrote: Hmmm... very interesting. I am wondering why I seem to be the first/only one noticing this. I did some extensive search in Jira and the forum and could not find this mentioned anywhere else. Also, I am seeing this issue since about two weeks now. Is the build working for you? If yes, what are the differences between your local environment and the one that one gets from SVN? -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Build-hangs-in-Geronimo-Plugins-System-Database-System-Database-3-0-SNAPSHOT-tp3801590p3802189.html Sent from the Development mailing list archive at Nabble.com.
Re: Updating Configuring Virtual Host in Tomcat, for G3.0
Great. Are you able to point me at discussions and examples of creating jars for TomcatServerGBean and TomcatContainerGBean? I have been looking for this, and have not found any. -RG On 03/06/2012 01:50 AM, Ivan wrote: Hi, I think that the GBean way to construct the server will be still there, while there are two ways, one is as you did in the past, configure many GBean instances, including connector gbean, container gbean, and etc. Another type is to define a TomcatServerGBean, and provide a server.xml, which is the recommended one. For the first way, we are still maintaining that, you may see that there are some changes recently for adding some new Tomcat parameters. For your scenario, with the later one, I am thinking whether you could do it in the following way, create a plain jar file, including a geronimo-service.xml file, which configures a TomcatServerGBean and TomcatContainer GBean, and there may also some customized Tomcat implementations in that jar file, then deploy it to those remote server to have a new Tomcat server instance created. 2012/3/6 Russell E Glaue rgl...@cait.org mailto:rgl...@cait.org I think Geronimo should go with a full OSGi implementation as a core, GBeans can take a back seat to OSGi if we can put all service configurations into the OSGi service registry. I want to believe that as an industry, most projects will become compatible as an OSGi service. Take for example Apache JAMES which has already been proven can be implemented as a GBean-service in the Geronimo stack. If a project wanted to take advantage of Geronimo as a framework, it makes sense that there would be more support in any community to move towards a general OSGi compatibility instead of specific customization for a single proprietary project. For the future of Geronimo, it will be easy to adopt other projects as they move towards becoming compliant as a OSGi service. OSGi should be the focus for the future of Geronimo. If there is reluctance to move Geronimo into a full OSGi implementation, then I feel the only alternative is to fully support GBeans for complete Geronimo configuration. To not embrace OSGi, and to move away from GBeans to file-based configuration, is to degrade the ability of Geronimo to enter the enterprise. We who must managed 100 web servers need remote management and deployment. Of course, like I already said, current commercial offering like Oracle iPlanet Web Server (formally Sun Enterprise Web Server) use remote configuration through file-based configuration. So this approach is not to be frowned upon. But the future is moving towards OSGi. We are beginning to have this in a lot of our daily-used devices like mobile. Better to start on the path towards OSGi now than have to make up for the bigger gap later. -RG On 02/29/2012 12:19 PM, David Jencks wrote: Hi Russell, My current viewpoint on gbeans is that in an osgi framework they are a bad idea since their capabilities are better expressed using osgi services and config admin. I am not all that confident that there is enough interest in actually rewriting the code in this way, but architecturally I think it is the best alternative. For things like tomcat server.xml there's a big question of the best size of components. We originally tried to have a geronimo component (gbean) for the smallest size tomcat component, and this has caused a lot of problems including really bad impedance mismatch on component lifecycles and forcing tomcat users to learn a totally unfamiliar configuration interface. At the moment we have 2 competing configuration mechanisms, server.xml and gbeans, and I think this is too complicated and confusing. Another possibility might be to have a single tomcat service that accepts the server.xml from config admin and sets up the entire tomcat server from that. If you want to change something you edit server.xml in config admin. Farming could be handled by a distributed config admin service. I haven't looked into tomcat configuration much since I started learning about config admin and managed service factories so there might be another way to do this with less monolithic tomcat configuration but still through osgi mechanisms. What do you think? thanks david jencks On Feb 29, 2012, at 8:57 AM, Russell E Glaue wrote: Are you suggesting that at some future milestone, Tomcat would no longer be configurable with a GBean deployment? Is it being considered that in regards to newer versions of Tomcat, the GBean may not be updated to incorporate newly introduced tomcat parameters
Re: Build hangs in Geronimo Plugins, System Database :: System Database 3.0-SNAPSHOT
On 03/06/2012 12:02 PM, uromahn wrote: Hi Russell, thank you for your reply. Two things: 1. Having a project that is unable to build since last December does not give me a lot of confidence in the project itself. That is why we branched it to 3.0-beta. 3.0-beta is 3.0 trunk without the new core stuff causing the build issues. 2. We are actually doing some POC work here that does *not* work with Geronimo 3.0-beta as we are not using the standard JEE model and some of the standard OSGI features that come with Karaf are not working in that version. As a result I would rather wait until we have a more stable trunk. Can you tell me what is in 3.0 trunk that is not in 3.0-beta branch? Mind I am talking about the 3.0-beta source code in the HEAD of subversion, and not the binary download from the Geronimo web site 4 months ago. We are actively keeping 3.0-beta up to date with all bug fixes and most feature enhancements that are in 3.0 trunk. Anything in 3.0 trunk that is not in 3.0 beta branch is the stuff we are working on introducing, and we don't recommend using those until we have completed them. Some additional notes about #1 above: I completely understand that introducing significant changes to a complex project such as Geronimo is complex and may break things - I have worked on complex software projects myself and have worked through various refactoring efforts. However, if one introduces such changes, it is always a good idea to do the refactoring in small enough steps in order to not break the build for too long and disrupt the continuous integration process. We took a different route. We took the can-build stable trunk and branched it. We apply updates to both trunk and 3.0-beta branch. Though we could have branched 3.0 trunk to work on complex changes and then merge them back with completed, we chose this method due to the nature of the complex technology we are adding to 3.0 in which multiple people are working on. I am wondering how we are supposed to test the trunk if there is no chance to build it! I believe there are ways to compile trunk right now, which I am not immediately familiar with. It involves setting up local repositories on your build station and installing extra stuff. This prevents anyone from building 3.0 trunk out of the box (that is a straight svn check out, configure maven env, and mvn install). Like I said, however, we are applying updates to both trunk and beta, so the build testing for our stable releases is in the 3.0-beta branch. Additionally, the 2.2 and 2.1 versions are also branched similar to 3.0-beta, and we will also apply fixes backwards and forwards across the branches. trunk has traditionally been place new technology is introduced which may potentially break out-of-the-box builds. Historically, if trunk does not build, we have worked towards resolving the issues that prevent it. Sorry if I am too blunt about this but this is very frustrating. Geronimo was an excellent project until now and this situation is starting to destroy my confidence in it. I am sorry you are frustrated. I hope that is less now that I have explained the difference between the development approach in trunk versus the 3.0-beta branch. Please try building 3.0-beta from the 3.0-beta branch and using that. If it is missing something important to you that 3.0 trunk has, please let us know. But like I said, the 3.0-beta branch should have everything trunk has. -RG
Re: Build hangs in Geronimo Plugins, System Database :: System Database 3.0-SNAPSHOT
Hi, I just updated from apache geronimo SVN 3.0-beta less than 1 hour ago, no issues for me. I am aware of your previous discussions with David J. back in January surrounding Karaf 3.0 and your desire for OSGi. David (and others) is delicately working Geronimo 3.0 towards OSGi on Karaf. I think Karaf is an excellent project, and Geronimo's use of it goes along with its pre-dated mission to create a J2EE server from the output of other projects. The Geronimo Kernel is an excellent approach allowing others to build specific enterprise applications on top of Geronimo core, like Derby DB and Apache JAMES mail server and more. It also allows us to strip out stuff we don't want like the J2EE stuff and run a lite container like LittleG. This makes Geronimo a very unique project, because you can build what you need. And from an enterprise farming view, you can remotely deploy and manage on that level much more easily. That being said, I understand you have current needs for the OSGi platform, specifically wrapped up in a nice Geronimo 3.0 package as it should be. In the previous January thread you replied to, David did mention that compiling 3.0 trunk is possible when you maintain a local nexus repository and exclude mirroring the org.apache.geronimo.* classes/packages. If you are in need of getting 3.0 trunk compiled, I would try that approach. If you have not setup a local Maven repo like nexus before, there is an initial climb to understand it. However, we use it here and it is our preferred method for managing maven artifacts. In the past, on rare occassion, trunk has been in this sate before. The ongoing issue that continues to surface over and over is at the crutch of the Geronimo project... Geronimo's dependency on other project's output. And when Geronimo is in SNAPSHOT as it is right now, it depends on SNAPSHOT releases of the other projects. As you experienced with Karaf, when these projects release a SNAPSHOT with an issue it also effects Geronimo. To resolve, all we can do is one of two things in these cases: 1. Go to the other project and report the problem and wait for the fix to make it into their SNAPSHOT release. 2. Setup a local maven proxy repo (like with nexus) and control what artifacts we download and use in our builds. So again, since you are so reliant upon Geronimo SNAPSHOTS, please recognize the state SNAPSHOT causes for Geronimo from dependency projects. And thus I would highly recommend following David J's advice on setting up nexus. It should also speed up your build time of trunk. And lastly, I have been (recently) maintaining the GMOxDEV wiki doc on building trunk. I will take your advice and update the page to alert future users of this risk. https://cwiki.apache.org/GMOxDOC30/building-geronimo-with-maven.html All of us working together make Geronimo what it is. So I appreciate you taking time to come to the mail list to discuss your issues. Thank you. -RG Russell E Glaue Apache Geronimo volunteer and contributor Enterprise Technology Engineer Center for the Application of Information Technologies Western Illinois University On 03/06/2012 02:14 PM, uromahn wrote: Russel, thank you for taking the time and explain this to me in such a detail. To get you understand, here is why I wanted to give 3.0-trunk a try. As I mentioned, we are working on an OSGI-based POC that is currently using Apache Karaf 2.2.5. However, we would like to use some of the JEE features/services and instead of adding those capabilities to Karaf, I wanted to leverage G3. Unfortunately, I am unable to deploy our current application to 3.0-beta and hence I must assume that it is not 100% OSGI-compliant and hence the attempted switch to 3.0-trunk which is essentially Karaf 3.0-SNAPSHOP plus all the JEE capabilities around it. On the other side, I think I start to understand your reasoning now and will try the latest 3.0-beta branch and see if I am more successful with that. Unfortunately, at this moment in time (and since about 1 1/2 hours) the Apache SVN server seems to be down and I can't get the 3.0-beta branch. -Uli -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Build-hangs-in-Geronimo-Plugins-System-Database-System-Database-3-0-SNAPSHOT-tp3801590p3804864.html Sent from the Development mailing list archive at Nabble.com.
Re: Build hangs in Geronimo Plugins, System Database :: System Database 3.0-SNAPSHOT
Just an additional short note. After reading your post, I proceeded to build Geronimo 3.0-beta, and was successful. Here is my build environment: Geronimo: URL: https://svn.apache.org/repos/asf/geronimo/server/branches/3.0-beta Revision: 1297660 Maven: MAVEN_OPTS='-XX:+HeapDumpOnOutOfMemoryError -Xmx2048m -XX:PermSize=512m -XX:MaxPermSize=640m -XX:ReservedCodeCacheSize=64m' Java: java version 1.6.0_25 Java(TM) SE Runtime Environment (build 1.6.0_25-b06) Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing) Execution: mvn clean install -Ptomcat -DskipTests=true Also, I finished updating the documentation to include a general warning about the state of building SNAPSHOT releases from trunk. https://cwiki.apache.org/GMOxDOC30/building-geronimo-with-maven.html https://cwiki.apache.org/GMOxDEV/building-apache-geronimo.html#BuildingApacheGeronimo-Overview -RG On 03/06/2012 02:14 PM, uromahn wrote: Russel, thank you for taking the time and explain this to me in such a detail. To get you understand, here is why I wanted to give 3.0-trunk a try. As I mentioned, we are working on an OSGI-based POC that is currently using Apache Karaf 2.2.5. However, we would like to use some of the JEE features/services and instead of adding those capabilities to Karaf, I wanted to leverage G3. Unfortunately, I am unable to deploy our current application to 3.0-beta and hence I must assume that it is not 100% OSGI-compliant and hence the attempted switch to 3.0-trunk which is essentially Karaf 3.0-SNAPSHOP plus all the JEE capabilities around it. On the other side, I think I start to understand your reasoning now and will try the latest 3.0-beta branch and see if I am more successful with that. Unfortunately, at this moment in time (and since about 1 1/2 hours) the Apache SVN server seems to be down and I can't get the 3.0-beta branch. -Uli -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Build-hangs-in-Geronimo-Plugins-System-Database-System-Database-3-0-SNAPSHOT-tp3801590p3804864.html Sent from the Development mailing list archive at Nabble.com.
Re: Build hangs in Geronimo Plugins, System Database :: System Database 3.0-SNAPSHOT
I use eris.apache.org (140.211.11.4) without issue - today at least. I am located in Illinois. I am plugged into the Illinois Century Network which connects directly to the major backbone in Chicago. 140.211.11.4 is in Oregon, south of Portland. If your connection is timing out, there may be a high load of traffic going through one of your upstream ISPs. Being able to ping a server is different from maintaining a connection without dropped packets. -RG On 03/06/2012 03:36 PM, uromahn wrote: Thank you David and Russell for your candid feedback. It looks like I will have to follow Russell's suggested approach and setup a local Maven repo, which I had done before, so it shouldn't take me too long to get going. Also, regarding the Apache SVN: If I try to access http://svn.apache.org/repos/asf/geronimo/server/trunk which resolves to eris.apache.org (140.211.11.4), the request times out for me. However, if I go to the EU mirror hosted on harmonia.apache.org I can access and checkout the sources. I can, however, ping the svn.apache.org server. -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Build-hangs-in-Geronimo-Plugins-System-Database-System-Database-3-0-SNAPSHOT-tp3801590p3805089.html Sent from the Development mailing list archive at Nabble.com.
Re: Build hangs in Geronimo Plugins, System Database :: System Database 3.0-SNAPSHOT
On 03/06/2012 04:35 PM, Russell E Glaue wrote: I use eris.apache.org (140.211.11.4) without issue - today at least. I am located in Illinois. I am plugged into the Illinois Century Network which connects directly to the major backbone in Chicago. 140.211.11.4 is in Oregon, south of Portland. If your connection is timing out, there may be a high load of traffic going through one of your upstream ISPs. Being able to ping a server is different from maintaining a connection without dropped packets. This is important for Subversion because it is VERY talkative. If you monitor subversion traffic, which is HTTP, it makes many many requests. This tends to create an environment for lots of potential network related issues. -RG On 03/06/2012 03:36 PM, uromahn wrote: Thank you David and Russell for your candid feedback. It looks like I will have to follow Russell's suggested approach and setup a local Maven repo, which I had done before, so it shouldn't take me too long to get going. Also, regarding the Apache SVN: If I try to access http://svn.apache.org/repos/asf/geronimo/server/trunk which resolves to eris.apache.org (140.211.11.4), the request times out for me. However, if I go to the EU mirror hosted on harmonia.apache.org I can access and checkout the sources. I can, however, ping the svn.apache.org server. -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/Build-hangs-in-Geronimo-Plugins-System-Database-System-Database-3-0-SNAPSHOT-tp3801590p3805089.html Sent from the Development mailing list archive at Nabble.com.
Re: Updating Configuring Virtual Host in Tomcat, for G3.0
I think Geronimo should go with a full OSGi implementation as a core, GBeans can take a back seat to OSGi if we can put all service configurations into the OSGi service registry. I want to believe that as an industry, most projects will become compatible as an OSGi service. Take for example Apache JAMES which has already been proven can be implemented as a GBean-service in the Geronimo stack. If a project wanted to take advantage of Geronimo as a framework, it makes sense that there would be more support in any community to move towards a general OSGi compatibility instead of specific customization for a single proprietary project. For the future of Geronimo, it will be easy to adopt other projects as they move towards becoming compliant as a OSGi service. OSGi should be the focus for the future of Geronimo. If there is reluctance to move Geronimo into a full OSGi implementation, then I feel the only alternative is to fully support GBeans for complete Geronimo configuration. To not embrace OSGi, and to move away from GBeans to file-based configuration, is to degrade the ability of Geronimo to enter the enterprise. We who must managed 100 web servers need remote management and deployment. Of course, like I already said, current commercial offering like Oracle iPlanet Web Server (formally Sun Enterprise Web Server) use remote configuration through file-based configuration. So this approach is not to be frowned upon. But the future is moving towards OSGi. We are beginning to have this in a lot of our daily-used devices like mobile. Better to start on the path towards OSGi now than have to make up for the bigger gap later. -RG On 02/29/2012 12:19 PM, David Jencks wrote: Hi Russell, My current viewpoint on gbeans is that in an osgi framework they are a bad idea since their capabilities are better expressed using osgi services and config admin. I am not all that confident that there is enough interest in actually rewriting the code in this way, but architecturally I think it is the best alternative. For things like tomcat server.xml there's a big question of the best size of components. We originally tried to have a geronimo component (gbean) for the smallest size tomcat component, and this has caused a lot of problems including really bad impedance mismatch on component lifecycles and forcing tomcat users to learn a totally unfamiliar configuration interface. At the moment we have 2 competing configuration mechanisms, server.xml and gbeans, and I think this is too complicated and confusing. Another possibility might be to have a single tomcat service that accepts the server.xml from config admin and sets up the entire tomcat server from that. If you want to change something you edit server.xml in config admin. Farming could be handled by a distributed config admin service. I haven't looked into tomcat configuration much since I started learning about config admin and managed service factories so there might be another way to do this with less monolithic tomcat configuration but still through osgi mechanisms. What do you think? thanks david jencks On Feb 29, 2012, at 8:57 AM, Russell E Glaue wrote: Are you suggesting that at some future milestone, Tomcat would no longer be configurable with a GBean deployment? Is it being considered that in regards to newer versions of Tomcat, the GBean may not be updated to incorporate newly introduced tomcat parameters? That would suggest that GBean configuration for Geronimo's Tomcat will become deprecated. How would it be suggested that in this case Geronimo's Tomcat could be centrally managed? Do we go back to pushing configuration files? That would change how plugin based farms are managed. -RG On 02/29/2012 08:56 AM, Ivan wrote: Yes, I agree that all the options should be documented, as you mentioned, we need it in many places. For the server.xml, I am thinking that it should be the main direction for the tomcat container configuration in the future, IMHO. As in the past versions, we find that those wrapper GBeans become more and more complicated for. e.g. with the new Tomcat version,some new parameters are introduced, and it is required to add those attributes for existing GBeans. From another side, it is really not user-friendly to configure those things with GBean. e.g. While configuring cluster, users may need to add a long GBean configurations in the config.xml, which is error proven. 2012/2/29 Russell E Glauergl...@cait.orgmailto:rgl...@cait.org Do you think that var/catalina/server.xml should be the primary emphasis for managing the default web container? I think all options should be documented, but that one can be first. Geronimo can run multiple web containers, but those have to be configured via a GBean. So the virtual hosts would be configured similarly in these environments. And when Geronimo is in a Farming environment, GBean deployment
[jira] [Commented] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220091#comment-13220091
]
Russell E Glaue commented on GERONIMO-6284:
---
Setting those properties before server start works.
If those properties are only to be used in startup and not with the deployer,
then this jira is resolved.
Thanks Forrest.
Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
--
Key: GERONIMO-6284
URL: https://issues.apache.org/jira/browse/GERONIMO-6284
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Assignee: Forrest Xia
Priority: Minor
Labels: geronimo
Cannot deploy to a Geronimo Instance. Deploy expects GERONIMO_HOME/var/...
Create a new Geronimo instance as documented in
https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html
- remove GERONIMO_HOME/etc
- remove GERONIMO_HOME/var
- create the empty file GERONIMO_HOME/var
Start the Geronimo instance as follows:
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3/gserv1
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/geronimo run
{noformat}
Create a second repository for the new instance
- mkdir {{gserv1/repository}}
- Create {{gserv1/repository.xml}} as documented in
https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html
{noformat:borderStyle=solid}
module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
environment
moduleId
groupIdorg.example.configs/groupId
artifactIdmyrepo/artifactId
version2.2/version
typecar/type
/moduleId
dependencies
dependency
groupIdorg.apache.geronimo.framework/groupId
artifactIdj2ee-system/artifactId
version2.2/version
typecar/type
/dependency
/dependencies
hidden-classes/
non-overridable-classes/
/environment
gbean name=Repo2
class=org.apache.geronimo.system.repository.Maven2Repository
attribute name=rootgserv1/repository//attribute
attribute name=resolveToServerfalse/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
/gbean
gbean name=Local2
class=org.apache.geronimo.system.configuration.RepositoryConfigurationStore
reference name=Repository
nameRepo2/name
/reference
/gbean
/module
{noformat}
Deploy the repository.xml file
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/deploy -port 1199 deploy
/opt/geronimo3/gserv1/repository.xml
{noformat}
The following error results:
{noformat:borderStyle=solid}
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0_25/jre
2012-02-21 15:33:44,695 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
abstractName=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car,j2eeType=AttributeStore,name=AttributeManager
java.io.IOException: Unable to create directory for
list:/opt/geronimo3/var/config
at
org.apache.geronimo.system.configuration.LocalAttributeManager.ensureParentDirectory(LocalAttributeManager.java:607)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:352)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:561)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:45
[jira] [Commented] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220096#comment-13220096
]
Russell E Glaue commented on GERONIMO-6284:
---
I will update the multiple repository documentation accordingly.
Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
--
Key: GERONIMO-6284
URL: https://issues.apache.org/jira/browse/GERONIMO-6284
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Assignee: Forrest Xia
Priority: Minor
Labels: geronimo
Fix For: 3.0-beta-2
Cannot deploy to a Geronimo Instance. Deploy expects GERONIMO_HOME/var/...
Create a new Geronimo instance as documented in
https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html
- remove GERONIMO_HOME/etc
- remove GERONIMO_HOME/var
- create the empty file GERONIMO_HOME/var
Start the Geronimo instance as follows:
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3/gserv1
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/geronimo run
{noformat}
Create a second repository for the new instance
- mkdir {{gserv1/repository}}
- Create {{gserv1/repository.xml}} as documented in
https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html
{noformat:borderStyle=solid}
module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
environment
moduleId
groupIdorg.example.configs/groupId
artifactIdmyrepo/artifactId
version2.2/version
typecar/type
/moduleId
dependencies
dependency
groupIdorg.apache.geronimo.framework/groupId
artifactIdj2ee-system/artifactId
version2.2/version
typecar/type
/dependency
/dependencies
hidden-classes/
non-overridable-classes/
/environment
gbean name=Repo2
class=org.apache.geronimo.system.repository.Maven2Repository
attribute name=rootgserv1/repository//attribute
attribute name=resolveToServerfalse/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
/gbean
gbean name=Local2
class=org.apache.geronimo.system.configuration.RepositoryConfigurationStore
reference name=Repository
nameRepo2/name
/reference
/gbean
/module
{noformat}
Deploy the repository.xml file
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/deploy -port 1199 deploy
/opt/geronimo3/gserv1/repository.xml
{noformat}
The following error results:
{noformat:borderStyle=solid}
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0_25/jre
2012-02-21 15:33:44,695 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
abstractName=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car,j2eeType=AttributeStore,name=AttributeManager
java.io.IOException: Unable to create directory for
list:/opt/geronimo3/var/config
at
org.apache.geronimo.system.configuration.LocalAttributeManager.ensureParentDirectory(LocalAttributeManager.java:607)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:352)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:561)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:45)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent
[jira] [Resolved] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue resolved GERONIMO-6284.
---
Resolution: Fixed
Fix Version/s: 3.0-beta-2
Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
--
Key: GERONIMO-6284
URL: https://issues.apache.org/jira/browse/GERONIMO-6284
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Assignee: Forrest Xia
Priority: Minor
Labels: geronimo
Fix For: 3.0-beta-2
Cannot deploy to a Geronimo Instance. Deploy expects GERONIMO_HOME/var/...
Create a new Geronimo instance as documented in
https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html
- remove GERONIMO_HOME/etc
- remove GERONIMO_HOME/var
- create the empty file GERONIMO_HOME/var
Start the Geronimo instance as follows:
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3/gserv1
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/geronimo run
{noformat}
Create a second repository for the new instance
- mkdir {{gserv1/repository}}
- Create {{gserv1/repository.xml}} as documented in
https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html
{noformat:borderStyle=solid}
module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
environment
moduleId
groupIdorg.example.configs/groupId
artifactIdmyrepo/artifactId
version2.2/version
typecar/type
/moduleId
dependencies
dependency
groupIdorg.apache.geronimo.framework/groupId
artifactIdj2ee-system/artifactId
version2.2/version
typecar/type
/dependency
/dependencies
hidden-classes/
non-overridable-classes/
/environment
gbean name=Repo2
class=org.apache.geronimo.system.repository.Maven2Repository
attribute name=rootgserv1/repository//attribute
attribute name=resolveToServerfalse/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
/gbean
gbean name=Local2
class=org.apache.geronimo.system.configuration.RepositoryConfigurationStore
reference name=Repository
nameRepo2/name
/reference
/gbean
/module
{noformat}
Deploy the repository.xml file
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/deploy -port 1199 deploy
/opt/geronimo3/gserv1/repository.xml
{noformat}
The following error results:
{noformat:borderStyle=solid}
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0_25/jre
2012-02-21 15:33:44,695 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
abstractName=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car,j2eeType=AttributeStore,name=AttributeManager
java.io.IOException: Unable to create directory for
list:/opt/geronimo3/var/config
at
org.apache.geronimo.system.configuration.LocalAttributeManager.ensureParentDirectory(LocalAttributeManager.java:607)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:352)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:561)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:45)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254
[jira] [Commented] (GERONIMO-6270) Re-enable multiple instances support in one installation
[ https://issues.apache.org/jira/browse/GERONIMO-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220224#comment-13220224 ] Russell E Glaue commented on GERONIMO-6270: --- All subtasks are resolved. I am now able to successfully run multiple instances from a single Geronimo installation base. Accordingly, I have finished updating the related documentation to reflect all changes made under this jira. * https://cwiki.apache.org/confluence/display/GMOxDOC30/Configuring+multiple+repositories * https://cwiki.apache.org/confluence/display/GMOxDOC30/Running+multiple+Geronimo+instances I think we can close this jira now. :) Thanks everyone! -RG Re-enable multiple instances support in one installation Key: GERONIMO-6270 URL: https://issues.apache.org/jira/browse/GERONIMO-6270 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0-beta-1 Reporter: Forrest Xia Assignee: Yi Xiao We need to investigate how to re-enable the multiple instances support in one installation. Refer to https://issues.apache.org/jira/browse/GERONIMO-6175 https://issues.apache.org/jira/browse/GERONIMO-6174 https://issues.apache.org/jira/browse/GERONIMO-5987 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Updating Configuring Virtual Host in Tomcat, for G3.0
Do you think that var/catalina/server.xml should be the primary emphasis for managing the default web container? I think all options should be documented, but that one can be first. Geronimo can run multiple web containers, but those have to be configured via a GBean. So the virtual hosts would be configured similarly in these environments. And when Geronimo is in a Farming environment, GBean deployment will be the requirement. https://cwiki.apache.org/GMOxDOC30/farming-using-deployment.html I believe a GBean option for all configurations should be documented when possible. Then Geronimo can be configured remotely. -RG On 02/28/2012 07:28 PM, Ivan wrote: Thanks for updating this, I am wondering whether we would encourage the users to use the server.xml to configure virtual host, although the gbean way still works now. 2012/2/29 Russell E Glaue rgl...@cait.org mailto:rgl...@cait.org I am going to start working on this document for G3.0 https://cwiki.apache.org/__GMOxDOC30/configuring-virtual-__host-in-tomcat.html https://cwiki.apache.org/GMOxDOC30/configuring-virtual-host-in-tomcat.html In addition to updating what is there, I am going to add additional information on how to deploy a plan with the deployer to configure virtual hosts. Any comments/suggestions? I will use this plan, which I have verified works. - module xmlns=http://geronimo.apache.__org/xml/ns/deployment-1.2 http://geronimo.apache.org/xml/ns/deployment-1.2 environment moduleId groupIdorg.example.configs.__virtualhosts/groupId artifactIdvirtualhost1/__artifactId version1.0/version typecar/type /moduleId dependencies dependency groupIdorg.apache.geronimo.__configs/groupId artifactIdtomcat7/__artifactId typecar/type /dependency /dependencies hidden-classes/ non-overridable-classes/ /environment gbean name=TomcatVirtualHost_1 class=org.apache.geronimo.__tomcat.HostGBean attribute name=classNameorg.apache.__catalina.core.StandardHost/__attribute attribute name=initParamsname=virtual__host1.com http://virtualhost1.com appBase= workDir=work/attribute reference name=Engine nameTomcatEngine/name /reference /gbean /module - -- Ivan
[jira] [Commented] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219249#comment-13219249
]
Russell E Glaue commented on GERONIMO-6284:
---
Since it is now possible to deploy to multiple instances, this jira is no
longer a show-stopper.
Should we file the two remaining issues into another jira?
Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
--
Key: GERONIMO-6284
URL: https://issues.apache.org/jira/browse/GERONIMO-6284
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Assignee: Forrest Xia
Priority: Minor
Labels: geronimo
Cannot deploy to a Geronimo Instance. Deploy expects GERONIMO_HOME/var/...
Create a new Geronimo instance as documented in
https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html
- remove GERONIMO_HOME/etc
- remove GERONIMO_HOME/var
- create the empty file GERONIMO_HOME/var
Start the Geronimo instance as follows:
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3/gserv1
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/geronimo run
{noformat}
Create a second repository for the new instance
- mkdir {{gserv1/repository}}
- Create {{gserv1/repository.xml}} as documented in
https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html
{noformat:borderStyle=solid}
module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
environment
moduleId
groupIdorg.example.configs/groupId
artifactIdmyrepo/artifactId
version2.2/version
typecar/type
/moduleId
dependencies
dependency
groupIdorg.apache.geronimo.framework/groupId
artifactIdj2ee-system/artifactId
version2.2/version
typecar/type
/dependency
/dependencies
hidden-classes/
non-overridable-classes/
/environment
gbean name=Repo2
class=org.apache.geronimo.system.repository.Maven2Repository
attribute name=rootgserv1/repository//attribute
attribute name=resolveToServerfalse/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
/gbean
gbean name=Local2
class=org.apache.geronimo.system.configuration.RepositoryConfigurationStore
reference name=Repository
nameRepo2/name
/reference
/gbean
/module
{noformat}
Deploy the repository.xml file
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/deploy -port 1199 deploy
/opt/geronimo3/gserv1/repository.xml
{noformat}
The following error results:
{noformat:borderStyle=solid}
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0_25/jre
2012-02-21 15:33:44,695 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
abstractName=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car,j2eeType=AttributeStore,name=AttributeManager
java.io.IOException: Unable to create directory for
list:/opt/geronimo3/var/config
at
org.apache.geronimo.system.configuration.LocalAttributeManager.ensureParentDirectory(LocalAttributeManager.java:607)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:352)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:561)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:45
Re: Updating Configuring Virtual Host in Tomcat, for G3.0
I agree with you. Novice/New users of Geronimo will find GBeans to be a difficult barrier to climb in order to get Geronimo to work. We should provide easier alternatives for these users to help get them started. Yet, on the other hand, the reason why Geronimo is so flexible and powerful as a server is because of GBeans. For users wanting to go from novice to mid-user, they need to begin to learn and understand GBeans. For the later case, we need to make GBeans an easy accomplishment for mid-users who do not understand it too well. I think that is achievable simply by providing example GBean alternatives to the manual configuration we offer for novices. For expert use, of course, almost everything needs to be configurable as a GBean. Geronimo becomes a choice product when using GBeans to manage enterprise deployments. And especially when managing a farm of servers. -RG On 02/29/2012 08:56 AM, Ivan wrote: Yes, I agree that all the options should be documented, as you mentioned, we need it in many places. For the server.xml, I am thinking that it should be the main direction for the tomcat container configuration in the future, IMHO. As in the past versions, we find that those wrapper GBeans become more and more complicated for. e.g. with the new Tomcat version,some new parameters are introduced, and it is required to add those attributes for existing GBeans. From another side, it is really not user-friendly to configure those things with GBean. e.g. While configuring cluster, users may need to add a long GBean configurations in the config.xml, which is error proven. 2012/2/29 Russell E Glaue rgl...@cait.org mailto:rgl...@cait.org Do you think that var/catalina/server.xml should be the primary emphasis for managing the default web container? I think all options should be documented, but that one can be first. Geronimo can run multiple web containers, but those have to be configured via a GBean. So the virtual hosts would be configured similarly in these environments. And when Geronimo is in a Farming environment, GBean deployment will be the requirement. https://cwiki.apache.org/__GMOxDOC30/farming-using-__deployment.html https://cwiki.apache.org/GMOxDOC30/farming-using-deployment.html I believe a GBean option for all configurations should be documented when possible. Then Geronimo can be configured remotely. -RG On 02/28/2012 07:28 PM, Ivan wrote: Thanks for updating this, I am wondering whether we would encourage the users to use the server.xml to configure virtual host, although the gbean way still works now. 2012/2/29 Russell E Glaue rgl...@cait.org mailto:rgl...@cait.org mailto:rgl...@cait.org mailto:rgl...@cait.org I am going to start working on this document for G3.0 https://cwiki.apache.org/GMOxDOC30/configuring-virtual-host-in-tomcat.html https://cwiki.apache.org/__GMOxDOC30/configuring-virtual-__host-in-tomcat.html https://cwiki.apache.org/__GMOxDOC30/configuring-virtual-__host-in-tomcat.html https://cwiki.apache.org/GMOxDOC30/configuring-virtual-host-in-tomcat.html In addition to updating what is there, I am going to add additional information on how to deploy a plan with the deployer to configure virtual hosts. Any comments/suggestions? I will use this plan, which I have verified works. - module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2 http://geronimo.apache.org/__xml/ns/deployment-1.2 http://geronimo.apache.org/xml/ns/deployment-1.2 environment moduleId groupIdorg.example.configs.virtualhosts/groupId artifactIdvirtualhost1/artifactId version1.0/version typecar/type /moduleId dependencies dependency groupIdorg.apache.geronimo.configs/groupId artifactIdtomcat7/artifactId typecar/type /dependency /dependencies hidden-classes/ non-overridable-classes/ /environment gbean name=TomcatVirtualHost_1 class=org.apache.geronimo.tomcat.HostGBean attribute name=classNameorg.apache.catalina.core.StandardHost/attribute attribute name=initParamsname=virtualhost1.com http://virtual__host1.com http://virtualhost1.com appBase= workDir=work/attribute reference name=Engine nameTomcatEngine/name /reference /gbean /module - -- Ivan -- Ivan
Re: Updating Configuring Virtual Host in Tomcat, for G3.0
Are you suggesting that at some future milestone, Tomcat would no longer be configurable with a GBean deployment? Is it being considered that in regards to newer versions of Tomcat, the GBean may not be updated to incorporate newly introduced tomcat parameters? That would suggest that GBean configuration for Geronimo's Tomcat will become deprecated. How would it be suggested that in this case Geronimo's Tomcat could be centrally managed? Do we go back to pushing configuration files? That would change how plugin based farms are managed. -RG On 02/29/2012 08:56 AM, Ivan wrote: Yes, I agree that all the options should be documented, as you mentioned, we need it in many places. For the server.xml, I am thinking that it should be the main direction for the tomcat container configuration in the future, IMHO. As in the past versions, we find that those wrapper GBeans become more and more complicated for. e.g. with the new Tomcat version,some new parameters are introduced, and it is required to add those attributes for existing GBeans. From another side, it is really not user-friendly to configure those things with GBean. e.g. While configuring cluster, users may need to add a long GBean configurations in the config.xml, which is error proven. 2012/2/29 Russell E Glaue rgl...@cait.org mailto:rgl...@cait.org Do you think that var/catalina/server.xml should be the primary emphasis for managing the default web container? I think all options should be documented, but that one can be first. Geronimo can run multiple web containers, but those have to be configured via a GBean. So the virtual hosts would be configured similarly in these environments. And when Geronimo is in a Farming environment, GBean deployment will be the requirement. https://cwiki.apache.org/__GMOxDOC30/farming-using-__deployment.html https://cwiki.apache.org/GMOxDOC30/farming-using-deployment.html I believe a GBean option for all configurations should be documented when possible. Then Geronimo can be configured remotely. -RG On 02/28/2012 07:28 PM, Ivan wrote: Thanks for updating this, I am wondering whether we would encourage the users to use the server.xml to configure virtual host, although the gbean way still works now. 2012/2/29 Russell E Glaue rgl...@cait.org mailto:rgl...@cait.org mailto:rgl...@cait.org mailto:rgl...@cait.org I am going to start working on this document for G3.0 https://cwiki.apache.org/GMOxDOC30/configuring-virtual-host-in-tomcat.html https://cwiki.apache.org/__GMOxDOC30/configuring-virtual-__host-in-tomcat.html https://cwiki.apache.org/__GMOxDOC30/configuring-virtual-__host-in-tomcat.html https://cwiki.apache.org/GMOxDOC30/configuring-virtual-host-in-tomcat.html In addition to updating what is there, I am going to add additional information on how to deploy a plan with the deployer to configure virtual hosts. Any comments/suggestions? I will use this plan, which I have verified works. - module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2 http://geronimo.apache.org/__xml/ns/deployment-1.2 http://geronimo.apache.org/xml/ns/deployment-1.2 environment moduleId groupIdorg.example.configs.virtualhosts/groupId artifactIdvirtualhost1/artifactId version1.0/version typecar/type /moduleId dependencies dependency groupIdorg.apache.geronimo.configs/groupId artifactIdtomcat7/artifactId typecar/type /dependency /dependencies hidden-classes/ non-overridable-classes/ /environment gbean name=TomcatVirtualHost_1 class=org.apache.geronimo.tomcat.HostGBean attribute name=classNameorg.apache.catalina.core.StandardHost/attribute attribute name=initParamsname=virtualhost1.com http://virtual__host1.com http://virtualhost1.com appBase= workDir=work/attribute reference name=Engine nameTomcatEngine/name /reference /gbean /module - -- Ivan -- Ivan
Re: Updating Configuring Virtual Host in Tomcat, for G3.0
We are currently farming with Sun's Enterprise Web Server (v6 and v7), which utilizes an admin config host to push files around. A centralized admin host maintains the files and pushes out changes to the distributed admin hosts on each node. This is all file-based configurations. The central admin node replaces config files on the remote nodes. To create or remove an instance, a command is sent to the distributed admin nodes to tell it to deploy a new instance. (Thus my desire to see GERONIMO-5164 resolved) However, that software has quite a few issues/bugs and I had to write a lot of tooling to actually make it work in a way that regular admin guys need only push a local button on each web server to start up or restart an instance. - Not great for cycling web services remotely. So what you suggest has already been done, and I am familiar with. I can accept this approach. However, for Geronimo, it will get complicated when you are pushing partial tomcat configs around to various servers. Local configuration (like what IP to bind to) can vary server to server. This is because Geronimo would be relying on Tomcat completely for implementation. This is one reason why I _loved_ that Tomcat was abstracted into a GBean. Sun Web Server easily configures multiple web containers per instance. But Catalina has one default web container. (Remember our conversation back in 2008, http://markmail.org/thread/iil2vorcfwe3iiel) (Sun uses catalina under the hood, but abstracts its use) There are some other reasons why I was looking towards GBeans. I can easily push configuration around to multiple servers by deploying plans. This can include configuring multiple web containers and virtual hosts within those web containers and deploying them on various web servers. Those configurations/plans can be managed by replicated maven repositories. I can push these to a remote maven repository in a remote NOC, and then have all the web servers in that NOC feed from it. Right now, if we were to move toward pushing config files, it would be difficult to manage things like accounting for different IP addresses for each server, and setting up multiple Catalina web containers. Perhaps also having difficulty in naming log files with the local host name, or configuring some specifics in the local SYSLOG facilities. (I have issues with these items, and more, in Sun Web Server's centralized admin service today) The managed service factories would have to be capable of generating entire services, and multiple instances of elements with the services, in order to compensate for the advantage GBeans give us now. -RG On 02/29/2012 12:19 PM, David Jencks wrote: Hi Russell, My current viewpoint on gbeans is that in an osgi framework they are a bad idea since their capabilities are better expressed using osgi services and config admin. I am not all that confident that there is enough interest in actually rewriting the code in this way, but architecturally I think it is the best alternative. For things like tomcat server.xml there's a big question of the best size of components. We originally tried to have a geronimo component (gbean) for the smallest size tomcat component, and this has caused a lot of problems including really bad impedance mismatch on component lifecycles and forcing tomcat users to learn a totally unfamiliar configuration interface. At the moment we have 2 competing configuration mechanisms, server.xml and gbeans, and I think this is too complicated and confusing. Another possibility might be to have a single tomcat service that accepts the server.xml from config admin and sets up the entire tomcat server from that. If you want to change something you edit server.xml in config admin. Farming could be handled by a distributed config admin service. I haven't looked into tomcat configuration much since I started learning about config admin and managed service factories so there might be another way to do this with less monolithic tomcat configuration but still through osgi mechanisms. What do you think? thanks david jencks On Feb 29, 2012, at 8:57 AM, Russell E Glaue wrote: Are you suggesting that at some future milestone, Tomcat would no longer be configurable with a GBean deployment? Is it being considered that in regards to newer versions of Tomcat, the GBean may not be updated to incorporate newly introduced tomcat parameters? That would suggest that GBean configuration for Geronimo's Tomcat will become deprecated. How would it be suggested that in this case Geronimo's Tomcat could be centrally managed? Do we go back to pushing configuration files? That would change how plugin based farms are managed. -RG On 02/29/2012 08:56 AM, Ivan wrote: Yes, I agree that all the options should be documented, as you mentioned, we need it in many places. For the server.xml, I am thinking that it should be the main direction for the tomcat container
[jira] [Commented] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218262#comment-13218262
]
Russell E Glaue commented on GERONIMO-6284:
---
Regarding the change http://svn.apache.org/viewvc?view=revrev=1291886 for
fixing the start failure, if a user creates multiple repositories, in G3.0 they
must additionally add the repository to the
{{org.ops4j.pax.url.mvn.defaultRepositories}} property file of
{{etc/org.ops4j.pax.url.mvn.cfg}} every time.
This is going to be an additional step the user will now have to take in order
to add multiple repositories.
I will update the documentation to reflect this.
Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
--
Key: GERONIMO-6284
URL: https://issues.apache.org/jira/browse/GERONIMO-6284
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Assignee: Forrest Xia
Priority: Minor
Labels: geronimo
Cannot deploy to a Geronimo Instance. Deploy expects GERONIMO_HOME/var/...
Create a new Geronimo instance as documented in
https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html
- remove GERONIMO_HOME/etc
- remove GERONIMO_HOME/var
- create the empty file GERONIMO_HOME/var
Start the Geronimo instance as follows:
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3/gserv1
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/geronimo run
{noformat}
Create a second repository for the new instance
- mkdir {{gserv1/repository}}
- Create {{gserv1/repository.xml}} as documented in
https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html
{noformat:borderStyle=solid}
module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
environment
moduleId
groupIdorg.example.configs/groupId
artifactIdmyrepo/artifactId
version2.2/version
typecar/type
/moduleId
dependencies
dependency
groupIdorg.apache.geronimo.framework/groupId
artifactIdj2ee-system/artifactId
version2.2/version
typecar/type
/dependency
/dependencies
hidden-classes/
non-overridable-classes/
/environment
gbean name=Repo2
class=org.apache.geronimo.system.repository.Maven2Repository
attribute name=rootgserv1/repository//attribute
attribute name=resolveToServerfalse/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
/gbean
gbean name=Local2
class=org.apache.geronimo.system.configuration.RepositoryConfigurationStore
reference name=Repository
nameRepo2/name
/reference
/gbean
/module
{noformat}
Deploy the repository.xml file
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/deploy -port 1199 deploy
/opt/geronimo3/gserv1/repository.xml
{noformat}
The following error results:
{noformat:borderStyle=solid}
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0_25/jre
2012-02-21 15:33:44,695 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
abstractName=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car,j2eeType=AttributeStore,name=AttributeManager
java.io.IOException: Unable to create directory for
list:/opt/geronimo3/var/config
at
org.apache.geronimo.system.configuration.LocalAttributeManager.ensureParentDirectory(LocalAttributeManager.java:607)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:352)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:561)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running
Re: Add name-value configuration entry for the deployment scope ?
I think it would be really terrific if the properties that are typically
provided on the command line at startup could be instead, optionally, defined in
a configuration file. Better yet if these can be configured via the portlet.
If Geronimo is to be used in a web server farm of dozens of nodes, there needs
to be a way to remotely administer all properties. And if all properties can be
setup in a config file and no longer need to be passed on the command line, this
would enhance the ability for remote administration. The goal being the
administrator never has to login to the server to deploy new Geronimo instances
and administer them.
-RG
On 02/28/2012 08:17 AM, Ivan wrote:
Hi, I am thinking to try to implement this feature in the coming 3.0-beta-2,
the rough idea is that
a. update our schema file to include things like :
environment
...
properties
property
nameorg.apache.geronimo.jsf.support/name
valuefalse/value
/properties
/envrionment
b. Have a PropertyDefintion GBean in geronimo-system module to describe the
property, the class may something like :
@GBean
public class PropertyDefintionT {
private String name;
private Type type;
private String description;
private String[] parentPropertyNames;
private String[] allowedValues;
public PropertyDefintion(String name, String type, String description,
String[] parentPropertyNames, String[] allowedValues) {
this.name http://this.name = name;
this.type = Type.valueOf(type);
this.description = description;
this.parentPropertyNames = parentPropertyNames;
this.allowedValues = allowedValues;
}
...
3. May also have a PropertyContext GBean for each application, which is used to
hold those configurations.
4. I have some property names in mind, including
org.apache.geronimo.webservice.support : The deployed application will not
use any webservice related stuff.
org.apache.geronimo.webservice.client.support : Need to inject some
service ref for this
org.apache.geronimo.webservice.server.support : Have SEI in the deployed
application.
org.apache.geronimo.webservice.jaxws.support
org.apache.geronimo.webservice.jaxrpc.support
org.apache.geronimo.ejb.support : No ejb component there, with this
configured with false, there is no need to annotation scanning in some
scenarios, e,g, while deploying a web application.
org.apache.geronimo.jsf.support ..
org.apache.geronimo.jaxrs.support ..
.
The most reason for this is that :
a. Geronimo is suffering from bad experience from long long long deployment
time, especially for those big application with many jar files. One of the major
reason is that, there are too many annotation scanning there, and so far we did
not have a uniform annotation scanning framework. With those options above, it
is possible to ignore some process steps. e.g. if
org.apache.geronimo.jsf.support is configured false, then MyFacesModuleBuilder
will not do anything.
b. From the user list, I saw some guys try to use other java ee providers, like
using cxf for webservice, use ri jsf implementation. Now, we may need to stop
the related deployer to avoid some problems.
c. There are some existing configurations here and there in Geronimo codes, all
of them are server scope.
For the OSGi integration side, so far, I did not have much idea for this. Maybe,
we could make those configurations visible in the Configuration instance of the
config admin server ???
Any comment for this ?
2011/2/14 Ivan xhh...@gmail.com mailto:xhh...@gmail.com
JSF issue is just an example, as I find a user fire a JIRA for it. The root
reason is that we use system property everywhere in the geronimo codes,
which is of global scope. Once we want to change the behavior, all the
components are affected. And it would be better to have other scope
configurations, like deployment scope, which means the configuration is only
for current application deployment process. We might also have application
scope configurations, which might be effect for the specified application.
Also, I think that we need this function even when we move to a gbean-free
geronimo, and yes, I agree that the solution now might not applicable in the
future. But, do we have a plan for the gbean-free kernel ?
2011/2/14 David Jencks david_jen...@yahoo.com
mailto:david_jen...@yahoo.com
Hi Ivan,
If I understand your proposal this is what you can currently do in a
maven geronimp plugin project in the car-maven-plugin configuration
where you specify which deployers to start.
I think this makes sense but I'd rather wait to implement it until we
know more what a gbean-free geronimo would look like. I suspect that
anything we do now would be obsolete later.
Would there be any confusion if you had a web app you wanted to deploy
on either
[jira] [Commented] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218288#comment-13218288
]
Russell E Glaue commented on GERONIMO-6284:
---
What about the errors I reported in the 27/Feb comment when the properties
{{org.apache.geronimo.config.file}} and
{{org.apache.geronimo.config.substitutions.file}} are passed in on the command
line?
Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
--
Key: GERONIMO-6284
URL: https://issues.apache.org/jira/browse/GERONIMO-6284
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Assignee: Forrest Xia
Priority: Minor
Labels: geronimo
Cannot deploy to a Geronimo Instance. Deploy expects GERONIMO_HOME/var/...
Create a new Geronimo instance as documented in
https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html
- remove GERONIMO_HOME/etc
- remove GERONIMO_HOME/var
- create the empty file GERONIMO_HOME/var
Start the Geronimo instance as follows:
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3/gserv1
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/geronimo run
{noformat}
Create a second repository for the new instance
- mkdir {{gserv1/repository}}
- Create {{gserv1/repository.xml}} as documented in
https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html
{noformat:borderStyle=solid}
module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
environment
moduleId
groupIdorg.example.configs/groupId
artifactIdmyrepo/artifactId
version2.2/version
typecar/type
/moduleId
dependencies
dependency
groupIdorg.apache.geronimo.framework/groupId
artifactIdj2ee-system/artifactId
version2.2/version
typecar/type
/dependency
/dependencies
hidden-classes/
non-overridable-classes/
/environment
gbean name=Repo2
class=org.apache.geronimo.system.repository.Maven2Repository
attribute name=rootgserv1/repository//attribute
attribute name=resolveToServerfalse/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
/gbean
gbean name=Local2
class=org.apache.geronimo.system.configuration.RepositoryConfigurationStore
reference name=Repository
nameRepo2/name
/reference
/gbean
/module
{noformat}
Deploy the repository.xml file
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/deploy -port 1199 deploy
/opt/geronimo3/gserv1/repository.xml
{noformat}
The following error results:
{noformat:borderStyle=solid}
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0_25/jre
2012-02-21 15:33:44,695 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
abstractName=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car,j2eeType=AttributeStore,name=AttributeManager
java.io.IOException: Unable to create directory for
list:/opt/geronimo3/var/config
at
org.apache.geronimo.system.configuration.LocalAttributeManager.ensureParentDirectory(LocalAttributeManager.java:607)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:352)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:561)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:45
[jira] [Commented] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218299#comment-13218299
]
Russell E Glaue commented on GERONIMO-6284:
---
Also, Geronimo still has the failure that occurs if
{{GERONIMO_HOME/var/config/...}} config files do not exist when deploying a new
repository to a Geronimo instance, even though those files are never used?
Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
--
Key: GERONIMO-6284
URL: https://issues.apache.org/jira/browse/GERONIMO-6284
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Assignee: Forrest Xia
Priority: Minor
Labels: geronimo
Cannot deploy to a Geronimo Instance. Deploy expects GERONIMO_HOME/var/...
Create a new Geronimo instance as documented in
https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html
- remove GERONIMO_HOME/etc
- remove GERONIMO_HOME/var
- create the empty file GERONIMO_HOME/var
Start the Geronimo instance as follows:
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3/gserv1
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/geronimo run
{noformat}
Create a second repository for the new instance
- mkdir {{gserv1/repository}}
- Create {{gserv1/repository.xml}} as documented in
https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html
{noformat:borderStyle=solid}
module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
environment
moduleId
groupIdorg.example.configs/groupId
artifactIdmyrepo/artifactId
version2.2/version
typecar/type
/moduleId
dependencies
dependency
groupIdorg.apache.geronimo.framework/groupId
artifactIdj2ee-system/artifactId
version2.2/version
typecar/type
/dependency
/dependencies
hidden-classes/
non-overridable-classes/
/environment
gbean name=Repo2
class=org.apache.geronimo.system.repository.Maven2Repository
attribute name=rootgserv1/repository//attribute
attribute name=resolveToServerfalse/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
/gbean
gbean name=Local2
class=org.apache.geronimo.system.configuration.RepositoryConfigurationStore
reference name=Repository
nameRepo2/name
/reference
/gbean
/module
{noformat}
Deploy the repository.xml file
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/deploy -port 1199 deploy
/opt/geronimo3/gserv1/repository.xml
{noformat}
The following error results:
{noformat:borderStyle=solid}
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0_25/jre
2012-02-21 15:33:44,695 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
abstractName=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car,j2eeType=AttributeStore,name=AttributeManager
java.io.IOException: Unable to create directory for
list:/opt/geronimo3/var/config
at
org.apache.geronimo.system.configuration.LocalAttributeManager.ensureParentDirectory(LocalAttributeManager.java:607)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:352)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:561)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:45
Updating Configuring Virtual Host in Tomcat, for G3.0
I am going to start working on this document for G3.0 https://cwiki.apache.org/GMOxDOC30/configuring-virtual-host-in-tomcat.html In addition to updating what is there, I am going to add additional information on how to deploy a plan with the deployer to configure virtual hosts. Any comments/suggestions? I will use this plan, which I have verified works. - module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; environment moduleId groupIdorg.example.configs.virtualhosts/groupId artifactIdvirtualhost1/artifactId version1.0/version typecar/type /moduleId dependencies dependency groupIdorg.apache.geronimo.configs/groupId artifactIdtomcat7/artifactId typecar/type /dependency /dependencies hidden-classes/ non-overridable-classes/ /environment gbean name=TomcatVirtualHost_1 class=org.apache.geronimo.tomcat.HostGBean attribute name=classNameorg.apache.catalina.core.StandardHost/attribute attribute name=initParamsname=virtualhost1.com appBase= workDir=work/attribute reference name=Engine nameTomcatEngine/name /reference /gbean /module -
[jira] [Commented] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217227#comment-13217227
]
Russell E Glaue commented on GERONIMO-6284:
---
Excellent!
With the one-line change, works to deploy and undeploy in
geronimo-tomcat7-javaee6-3.0-SNAPSHOT-20111220.
However, it only works if there exists:
- GERONIMO_HOME/var/config.xml
- GERONIMO_HOME/var/config/config-substitution.properties
And setting the {{org.apache.geronimo.config.file}} and
{{org.apache.geronimo.config.substitutions.file}} properties in this scenario...
- as relative paths: Geronimo looks for them relative to GERONIMO_HOME, when it
should be GERONIMO_SERVER
- as full paths: produces an error
I illustrate this here:
with GERONIMO_HOME/var/config/{config-files} missing
{noformat:borderStyle=solid}
[root@server /opt/geronimo3]# mv var var1
[root@server /opt/geronimo3]# touch var
[root@server /opt/geronimo3]# env GERONIMO_SERVER=gserv1 bin/deploy -port 1199
undeploy com.ibm.wasce.samples/cviewer/3.0.0.0/car
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
2012-02-27 09:24:54,672 ERROR [GBeanInstanceState] Error while starting; GBean
is now in the FAILED state:
abstractName=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car,j2eeType=AttributeStore,name=AttributeManager
java.io.IOException: Unable to create directory for
list:/opt/geronimo3/var/config
at
org.apache.geronimo.system.configuration.LocalAttributeManager.ensureParentDirectory(LocalAttributeManager.java:607)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:352)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:561)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:45)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:569)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:466)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:220)
at
org.apache.geronimo.system.osgi.BootActivator.start(BootActivator.java:70)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389)
at
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1131)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457
[jira] [Commented] (GERONIMO-6286) o.a.g.server.dir should be used instead of o.a.g.home.dir in misc places
[ https://issues.apache.org/jira/browse/GERONIMO-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13216636#comment-13216636 ] Russell E Glaue commented on GERONIMO-6286: --- No I did not test. The first patch I am not able to test the SSL, but it was just a path change. I did not know how the code in the second patch was used in Geronimo. It was a little more involved, So I split the patches and asked for it to be reviewed. I should have specifically asked for it to be ”tested”. Sorry. o.a.g.server.dir should be used instead of o.a.g.home.dir in misc places Key: GERONIMO-6286 URL: https://issues.apache.org/jira/browse/GERONIMO-6286 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Assignee: Forrest Xia Labels: geronimo Attachments: geronimo-6286-BaseJava-StartServer-StartClient.patch, geronimo-6286-EmbeddedDaemon-CommandUnlockKeystore-DeployUtils.patch There are some code files still using org.apache.geronimo.home.dir when instead they should ideally be using org.apache.geronimo.server.dir . - framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/main/EmbeddedDaemon.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/CommandUnlockKeystore.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/DeployUtils.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214817#comment-13214817
]
Russell E Glaue commented on GERONIMO-6284:
---
I was able to successfully deploy the plan to a Geronimo install with no
configured instances.
I tested a few different configured plans and determined the problem with the
currently documented plan was the version number of 2.2 in the
org.apache.geronimo.framework j2ee-system dependency. Once that was removed, I
was able to deploy the wiki documented plan.
However, when deploying the cviewer-3.0.0.0.war in GERONIMO-6285 to the second
repository, it failed on load operation. It did deploy to the primary
repository and load successfully.
Here is the plan for my second repository
{noformat:borderStyle=solid}
module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
environment
moduleId
groupIdorg.example.configs.repo2/groupId
artifactIdmyrepo2/artifactId
version2.2/version
typecar/type
/moduleId
dependencies
dependency
groupIdorg.apache.geronimo.framework/groupId
artifactIdj2ee-system/artifactId
typecar/type
/dependency
/dependencies
hidden-classes/
non-overridable-classes/
/environment
gbean name=Repo2
class=org.apache.geronimo.system.repository.Maven2Repository
attribute name=rootrepo2//attribute
attribute name=resolveToServertrue/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
/gbean
gbean name=Local2
class=org.apache.geronimo.system.configuration.RepositoryConfigurationStore
reference name=Repository
nameRepo2/name
/reference
/gbean
/module
{noformat}
Here is the output from attempting to deploy the war to the second repository
{noformat:borderStyle=solid}
[root@server geronimo3-beta]# bin/deploy -port 1099 list-targets
Using GERONIMO_HOME: /opt/geronimo3-beta
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
Username: system
Password: ***
Available Targets:
org.apache.geronimo.framework/j2ee-system/3.0-beta-1/car?ServiceModule=org.apache.geronimo.framework/j2ee-system/3.0-beta-1/car,j2eeType=ConfigurationStore,name=Local
org.example.configs.repo2/myrepo2/2.2/car?ServiceModule=org.example.configs.repo2/myrepo2/2.2/car,j2eeType=ConfigurationStore,name=Local2
[root@server geronimo3-beta]# bin/deploy -port 1099 deploy --targets Local2
cviewer-3.0.0.0.war
Using GERONIMO_HOME: /opt/geronimo3-beta
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
Username: system
Password: ***
2012-02-23 09:58:38,418 ERROR [DeployTool] Error:
org.apache.geronimo.common.DeploymentException: Operation failed: load of
com.ibm.wasce.samples/cviewer/3.0.0.0/car failed
URL [mvn:com.ibm.wasce.samples/cviewer/3.0.0.0/car] could not be
resolved.
URL [mvn:com.ibm.wasce.samples/cviewer/3.0.0.0/car] could not be
resolved.
at
org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java:168)
at
org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:124)
at
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:171)
at
org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64)
at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:32)
[root@server geronimo3-beta]# bin/deploy -port 1099 deploy cviewer-3.0.0.0.war
Using GERONIMO_HOME: /opt/geronimo3-beta
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
Username: system
Password: ***
Deployed com.ibm.wasce.samples/cviewer/3.0.0.0/car @ /cviewer
{noformat}
Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
--
Key: GERONIMO-6284
URL: https://issues.apache.org/jira/browse/GERONIMO-6284
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Assignee: Forrest Xia
Priority: Minor
Labels: geronimo
Cannot deploy to a Geronimo Instance. Deploy expects GERONIMO_HOME/var/...
Create a new Geronimo instance as documented in
https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html
- remove GERONIMO_HOME/etc
- remove GERONIMO_HOME/var
- create the empty file GERONIMO_HOME/var
Start the Geronimo instance as follows:
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3
[jira] [Commented] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214859#comment-13214859
]
Russell E Glaue commented on GERONIMO-6284:
---
I was able to deploy the repository for the Geronimo instance with a simple
work-around.
The work-around is to copy a config.xml and config-substitutions.properties to
GERONIMO_HOME/var/config.
Apparently the deployer code looks to see if those are there, and it causes
problems if they do not exist.
However, if they exist, but you are deploying with a GERONIMO_SERVER defined,
they are checked but not modified.
I do not know if these config files are actually read. And if they are read,
there will be a problem if the GERONIMO_SERVER/var/config/{file} are not the
same files as the deployer looks for in GERONIMO_HOME/var/config/{file}
Also, though I was able to deploy/install a war to the second repository for
the Geronimo instance, it did not successfully load. This is the same error as
reported in the previous commend.
None the less, here is how I successfully deployed the second repository for a
Geronimo instance. Also following is the procedure and error message in
deploying the WAR.
Repository plan:
{noformat:borderStyle=solid}
module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
environment
moduleId
groupIdorg.example.configs.gserv1/groupId
artifactIdgserv1repo/artifactId
version2.2/version
typecar/type
/moduleId
dependencies
dependency
groupIdorg.apache.geronimo.framework/groupId
artifactIdj2ee-system/artifactId
typecar/type
/dependency
/dependencies
hidden-classes/
non-overridable-classes/
/environment
gbean name=gserv1
class=org.apache.geronimo.system.repository.Maven2Repository
attribute name=rootrepository//attribute
attribute name=resolveToServertrue/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
/gbean
gbean name=Localgserv1
class=org.apache.geronimo.system.configuration.RepositoryConfigurationStore
reference name=Repository
namegserv1/name
/reference
/gbean
/module
{noformat}
Setup:
- To setup a Geronimo instance, follow the procedures in
https://cwiki.apache.org/confluence/display/GMOxDOC30/Running+multiple+Geronimo+instances
- remove GERONIMO_HOME/etc
- remove GERONIMO_HOME/var
- Start the gserv1 instance with: {{cd $GERONIMO_HOME; env
GERONIMO_SERVER=gserv1 bin/geronimo run}} (The patch from GERONIMO-6275 is
needed)
Workaround:
{noformat:borderStyle=solid}
[root@server geronimo3]# mkdir -p $GERONIMO_HOME/var/config
[root@server geronimo3]# cp -p $GERONIMO_SERVER/var/config/config.xml
$GERONIMO_HOME/var/config/config.xml
[root@server geronimo3]# cp -p
$GERONIMO_SERVER/var/config/config-substitutions.properties
$GERONIMO_HOME/var/config/config-substitutions.properties
{noformat}
Plan Deployment:
{noformat:borderStyle=solid}
[root@server geronimo3]# env GERONIMO_SERVER=gserv1 bin/deploy -port 1199
deploy gserv1/repository.xml
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
Username: system
Password: ***
Deployed org.example.configs.gserv1/gserv1repo/2.2/car
[root@server geronimo3]# diff var/config/config.xml gserv1/var/config/config.xml
262a263
module name=org.example.configs.gserv1/gserv1repo/2.2/car/
[root@server geronimo3]# env GERONIMO_SERVER=gserv1 bin/deploy -port 1199
list-targets
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
Username: system
Password: ***
Available Targets:
org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local
org.example.configs.gserv1/gserv1repo/2.2/car?ServiceModule=org.example.configs.gserv1/gserv1repo/2.2/car,j2eeType=ConfigurationStore,name=Localgserv1
{noformat}
WAR Deployment:
{noformat:borderStyle=solid}
[root@server geronimo3]# env GERONIMO_SERVER=gserv1 bin/deploy -port 1199
deploy --targets Localgserv1 cviewer-3.0.0.0.war
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
Username: system
Password: ***
2012-02-23 11:04:58,573 ERROR [DeployTool] Error:
org.apache.geronimo.common.DeploymentException: Operation failed: load of
com.ibm.wasce.samples/cviewer/3.0.0.0/car failed
URL [mvn:com.ibm.wasce.samples/cviewer/3.0.0.0/car] could not be
resolved.
URL [mvn:com.ibm.wasce.samples/cviewer/3.0.0.0/car] could not be
resolved.
at
org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java
[jira] [Commented] (GERONIMO-6272) server can not be started if installation path contains bracket ()
[ https://issues.apache.org/jira/browse/GERONIMO-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214875#comment-13214875 ] Russell E Glaue commented on GERONIMO-6272: --- The batch files that start Geronimo obtain the correct path from the system by navigating to GERONIMO_HOME and obtaining that path reported by the system. In this case the path is being passed in with the parenthesis. karaf.base in 3.0-beta is being set to GERONIMO_HOME So I would suppose that either Karaf itself is having an issue with this type of formatted path, or the JexlExpressionParser which handles the resolution of properties is having the issue. However GERONIMO_HOME is being passed in the same in geronimo.bat as -Dorg.apache.geronimo.home.dir=%GERONIMO_HOME% and -Dkaraf.base=%GERONIMO_HOME%, so I would suppose the issue is more directly related to Karaf itself. So if it is Karaf having the issue and not JexlExpressionParser, then this issue is no related to GERONIMO-6281. The work-around for the time being is of course to use a path with safe characters for GERONIMO_HOME. server can not be started if installation path contains bracket () Key: GERONIMO-6272 URL: https://issues.apache.org/jira/browse/GERONIMO-6272 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0-beta-1 Environment: win7 64bit,oracle jdk 1.6.0_26 Reporter: Saphen Qiu Labels: bracket, startup I install geronimo on this path c:\New folder (x), I can not start server with any commands, and get the following errors. But if I rename the folder to New folder without (), then the server can be started successfully. *** C:\New folder (x)\bingeronimo.bat run -c Using GERONIMO_HOME: C:\New folder (x) Using GERONIMO_TMPDIR: C:\New folder (x)\var\temp Using JRE_HOME:C:\Program\Java\jdk1.6.0_26\jre __ _ / /___ _ (_) ___ / / __ / _ \/ ___/ __ \/ __ \/ // __ `__ \/ __ \ / /_/ // __/ / / /_/ / / / / // / / / / / /_/ / \/ \___/_/ \/_/ /_/_//_/ /_/ /_/\/ Apache Geronimo (3.0-beta-2-SNAPSHOT) Hit 'tab' for a list of available commands and '[cmd] --help' for help on a specific command. Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo. geronimo 2012-02-14 15:39:27,135 WARN [FeaturesServiceImpl] Unable to add features repository mvn:org.apache.geronimo. framework/karaf-framework/3.0-beta-2-SNAPSHOT/xml/features at startup java.lang.RuntimeException: URL [mvn:org.apache.geronimo.framework/karaf-framework/3.0-beta-2-SNAPSHOT/xml/features] cou ld not be resolved. at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195) at org.apache.karaf.features.internal.FeatureValidationUtil.validate(FeatureValidationUtil.java:49) at org.apache.karaf.features.internal.FeaturesServiceImpl.validateRepository(FeaturesServiceImpl.java:199) at org.apache.karaf.features.internal.FeaturesServiceImpl.internalAddRepository(FeaturesServiceImpl.java:210) at org.apache.karaf.features.internal.FeaturesServiceImpl.start(FeaturesServiceImpl.java:918) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:226) at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:824) at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:636) at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:724) at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64) at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219) at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:147) at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl .java:640) at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:331) at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:227) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441
[jira] [Created] (GERONIMO-6286) o.a.g.server.dir should be used instead of o.a.g.home.dir in misc places
o.a.g.server.dir should be used instead of o.a.g.home.dir in misc places Key: GERONIMO-6286 URL: https://issues.apache.org/jira/browse/GERONIMO-6286 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue There are some code files still using org.apache.geronimo.home.dir when instead they should ideally be using org.apache.geronimo.server.dir . - framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/main/EmbeddedDaemon.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/CommandUnlockKeystore.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/DeployUtils.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6286) o.a.g.server.dir should be used instead of o.a.g.home.dir in misc places
[ https://issues.apache.org/jira/browse/GERONIMO-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell E Glaue updated GERONIMO-6286: -- Attachment: geronimo-6286-EmbeddedDaemon-CommandUnlockKeystore-DeployUtils.patch geronimo-6286-EmbeddedDaemon-CommandUnlockKeystore-DeployUtils.patch Modifies: - framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/main/EmbeddedDaemon.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/CommandUnlockKeystore.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/DeployUtils.java o.a.g.server.dir should be used instead of o.a.g.home.dir in misc places Key: GERONIMO-6286 URL: https://issues.apache.org/jira/browse/GERONIMO-6286 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Labels: geronimo Attachments: geronimo-6286-EmbeddedDaemon-CommandUnlockKeystore-DeployUtils.patch There are some code files still using org.apache.geronimo.home.dir when instead they should ideally be using org.apache.geronimo.server.dir . - framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/main/EmbeddedDaemon.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/CommandUnlockKeystore.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/DeployUtils.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (GERONIMO-6286) o.a.g.server.dir should be used instead of o.a.g.home.dir in misc places
[ https://issues.apache.org/jira/browse/GERONIMO-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215028#comment-13215028 ] Russell E Glaue edited comment on GERONIMO-6286 at 2/23/12 8:37 PM: geronimo-6286-BaseJava-StartServer-StartClient.patch Modifies: - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/BaseJavaCommand.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java Please review this patch. I thought it best to keep this one simple and require the user to specify the full path for the org.apache.geronimo.server.dir if they wish to define it. was (Author: rglaue): geronimo-6286-BaseJava-StartServer-StartClient.patch Modifies: - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java Please review this patch. I thought it best to keep this one simple and require the user to specify the full path for the org.apache.geronimo.server.dir if they wish to define it. o.a.g.server.dir should be used instead of o.a.g.home.dir in misc places Key: GERONIMO-6286 URL: https://issues.apache.org/jira/browse/GERONIMO-6286 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Labels: geronimo Attachments: geronimo-6286-BaseJava-StartServer-StartClient.patch, geronimo-6286-EmbeddedDaemon-CommandUnlockKeystore-DeployUtils.patch There are some code files still using org.apache.geronimo.home.dir when instead they should ideally be using org.apache.geronimo.server.dir . - framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/main/EmbeddedDaemon.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/CommandUnlockKeystore.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/DeployUtils.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6286) o.a.g.server.dir should be used instead of o.a.g.home.dir in misc places
[ https://issues.apache.org/jira/browse/GERONIMO-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell E Glaue updated GERONIMO-6286: -- Attachment: geronimo-6286-BaseJava-StartServer-StartClient.patch geronimo-6286-BaseJava-StartServer-StartClient.patch Modifies: - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java Please review this patch. I thought it best to keep this one simple and require the user to specify the full path for the org.apache.geronimo.server.dir if they wish to define it. o.a.g.server.dir should be used instead of o.a.g.home.dir in misc places Key: GERONIMO-6286 URL: https://issues.apache.org/jira/browse/GERONIMO-6286 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Labels: geronimo Attachments: geronimo-6286-BaseJava-StartServer-StartClient.patch, geronimo-6286-EmbeddedDaemon-CommandUnlockKeystore-DeployUtils.patch There are some code files still using org.apache.geronimo.home.dir when instead they should ideally be using org.apache.geronimo.server.dir . - framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/main/EmbeddedDaemon.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/CommandUnlockKeystore.java - framework/modules/geronimo-deploy-tool/src/main/java/org/apache/geronimo/deployment/cli/DeployUtils.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java - framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13213762#comment-13213762
]
Russell E Glaue commented on GERONIMO-6281:
---
For activemq.data, you just need to use a relative path for a new instance. For
example, if the instance name is GERONIMO_SERVER=inst1, then you set it like
this:
activemq.data=inst1/var/activemq
No need to add a absolute path there.
The problem is that ActiveMQ access activemq.data relative to the directory
you are in when you start Geronimo.
That is if you start Geronimo, without the no configured instances, like this:
- $ cd /opt
- $ export GERONIMO_HOME=/opt/geronimo
- $ /opt/geronomo/bin/geronimo start
Then ActiveMQ uses the following path as activemq.data:
- /opt/var/activemq
In this scenario, we want ActiveMQ to use {{GERONIMO_HOME/var/activemq}}, and
not {{PWD/var/activemq}}
For the configured instance example you provide, ActiveMQ would create
{{/opt/inst1/var/activemq}}. It would not use
{{/opt/geronimo/inst1/var/activemq}} as you would expect.
Now take for example that I want to start Geronimo as a unix service.
If {{GERONIMO_HOME=/opt/geronimo}}
And the unix service starts geronimo in {{/}} (file system root)
ActiveMQ will create {{/var/activemq}}
ActiveMQ does not use {{GERONIMO_HOME/var/activemq}} as you would be expecting
Geronimo will fail to start if it is being started by a non-root user since
ActiveMQ will not have permissions to create {{/var/activemq}}
How do we address this?
My recommendation is to change ActiveMQ to use org.apache.geronimo.server.dir
as the base path and not PWD.
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq-config-substitutions.patch,
geronimo-6281-activemq.patch, geronimo-6281-karaf.patch,
geronimo-6281-snapshot.patch, geronimo-6281-trunk-karaf.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache
Can't create second repository
Does anyone know why the documented procedure for creating a second repository throws an error? https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html Unpack geronimo-tomcat7-javaee6-3.0-SNAPSHOT-20111220 as /opt/geronimo3 Or unpack geronimo-tomcat7-javaee6-3.0-beta-1 as /opt/geronimo3 [root@server geronimo3]$ cd /opt/geronimo3 [root@server geronimo3]$ bin/geronimo start Using GERONIMO_HOME: /opt/geronimo3 Using GERONIMO_TMPDIR: /opt/geronimo3/var/temp Using JRE_HOME:/usr/jdk1.6.0/jre Using GERONIMO_OUT:/opt/geronimo3/var/log/geronimo.out Geronimo started in background. PID: 8625 [root@server geronimo3]$ bin/deploy -port 1099 deploy repo2.xml Using GERONIMO_HOME: /opt/geronimo3 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/usr/jdk1.6.0_25/jre Username: system Password: *** 2012-02-22 13:09:32,223 ERROR [DeployTool] Error: org.apache.geronimo.common.DeploymentException: Unable to deploy repo2.xml: Unable to resolve reference ServerInfo in gbean org.example.configs/myrepo/2.2/car?ServiceModule=org.example.configs/myrepo/2.2/car,j2eeType=Repository,name=Repo2 to a gbean matching the pattern [?j2eeType=GBean,name=ServerInfo#org.apache.geronimo.system.serverinfo.ServerInfo] due to: No matches for referencePatterns: [?j2eeType=GBean,name=ServerInfo#org.apache.geronimo.system.serverinfo.ServerInfo] (no matches) at org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(CommandDeploy.java:43) at org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java:148) at org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:124) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:171) at org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64) at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:32)
Re: Can't create second repository
The documented procedures in https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html work for /data/geronimo2/geronimo-tomcat6-javaee5-2.2.1 Something changed between 2.2 and 3.0. And ether that change breaks the support for multiple repositories, or the documented procedure needs to be updated to reflect the changes if that support still exists. Can anyone weigh in on what they know? -RG On 02/22/2012 01:02 PM, Russell E Glaue wrote: Does anyone know why the documented procedure for creating a second repository throws an error? https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html Unpack geronimo-tomcat7-javaee6-3.0-SNAPSHOT-20111220 as /opt/geronimo3 Or unpack geronimo-tomcat7-javaee6-3.0-beta-1 as /opt/geronimo3 [root@server geronimo3]$ cd /opt/geronimo3 [root@server geronimo3]$ bin/geronimo start Using GERONIMO_HOME: /opt/geronimo3 Using GERONIMO_TMPDIR: /opt/geronimo3/var/temp Using JRE_HOME: /usr/jdk1.6.0/jre Using GERONIMO_OUT: /opt/geronimo3/var/log/geronimo.out Geronimo started in background. PID: 8625 [root@server geronimo3]$ bin/deploy -port 1099 deploy repo2.xml Using GERONIMO_HOME: /opt/geronimo3 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /usr/jdk1.6.0_25/jre Username: system Password: *** 2012-02-22 13:09:32,223 ERROR [DeployTool] Error: org.apache.geronimo.common.DeploymentException: Unable to deploy repo2.xml: Unable to resolve reference ServerInfo in gbean org.example.configs/myrepo/2.2/car?ServiceModule=org.example.configs/myrepo/2.2/car,j2eeType=Repository,name=Repo2 to a gbean matching the pattern [?j2eeType=GBean,name=ServerInfo#org.apache.geronimo.system.serverinfo.ServerInfo] due to: No matches for referencePatterns: [?j2eeType=GBean,name=ServerInfo#org.apache.geronimo.system.serverinfo.ServerInfo] (no matches) at org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(CommandDeploy.java:43) at org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java:148) at org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:124) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:171) at org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64) at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:32)
Re: Can't create second repository
From what I could decipher, it appears that in Geronimo 3.0 a GBeanInfo class is loaded from a classloader org.eclipse.osgi.framework.internal.core.BundleContextImpl The OSGI is what is different from Geronimo 2.2. Would this suggest the issue might be within the Geronimo 3.0 OSGI implementation? -RG On 02/22/2012 01:50 PM, Russell E Glaue wrote: The documented procedures in https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html work for /data/geronimo2/geronimo-tomcat6-javaee5-2.2.1 Something changed between 2.2 and 3.0. And ether that change breaks the support for multiple repositories, or the documented procedure needs to be updated to reflect the changes if that support still exists. Can anyone weigh in on what they know? -RG On 02/22/2012 01:02 PM, Russell E Glaue wrote: Does anyone know why the documented procedure for creating a second repository throws an error? https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html Unpack geronimo-tomcat7-javaee6-3.0-SNAPSHOT-20111220 as /opt/geronimo3 Or unpack geronimo-tomcat7-javaee6-3.0-beta-1 as /opt/geronimo3 [root@server geronimo3]$ cd /opt/geronimo3 [root@server geronimo3]$ bin/geronimo start Using GERONIMO_HOME: /opt/geronimo3 Using GERONIMO_TMPDIR: /opt/geronimo3/var/temp Using JRE_HOME: /usr/jdk1.6.0/jre Using GERONIMO_OUT: /opt/geronimo3/var/log/geronimo.out Geronimo started in background. PID: 8625 [root@server geronimo3]$ bin/deploy -port 1099 deploy repo2.xml Using GERONIMO_HOME: /opt/geronimo3 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /usr/jdk1.6.0_25/jre Username: system Password: *** 2012-02-22 13:09:32,223 ERROR [DeployTool] Error: org.apache.geronimo.common.DeploymentException: Unable to deploy repo2.xml: Unable to resolve reference ServerInfo in gbean org.example.configs/myrepo/2.2/car?ServiceModule=org.example.configs/myrepo/2.2/car,j2eeType=Repository,name=Repo2 to a gbean matching the pattern [?j2eeType=GBean,name=ServerInfo#org.apache.geronimo.system.serverinfo.ServerInfo] due to: No matches for referencePatterns: [?j2eeType=GBean,name=ServerInfo#org.apache.geronimo.system.serverinfo.ServerInfo] (no matches) at org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(CommandDeploy.java:43) at org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java:148) at org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:124) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:171) at org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64) at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:32)
[jira] [Commented] (GERONIMO-6175) Environment variable org.apache.geronimo.repository.boot.path not used, Repository path does not observe named instances
[
https://issues.apache.org/jira/browse/GERONIMO-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214275#comment-13214275
]
Russell E Glaue commented on GERONIMO-6175:
---
The focus is now on creating second repositories for Geronimo instances.
GERONIMO-6284
All instances will share a primary repository, and utilize second repositories
for local deployments.
Environment variable org.apache.geronimo.repository.boot.path not used,
Repository path does not observe named instances
Key: GERONIMO-6175
URL: https://issues.apache.org/jira/browse/GERONIMO-6175
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 3.0, 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Assignee: Forrest Xia
Priority: Minor
Labels: geronimo
I only list this issue as minor, as the issue does not prevent running
Geronimo, or more than one copy of Geronimo on a single server. However, this
issue does prevent the proper utilization of multiple named server instances.
Two issues:
# On startup, Geronimo does not use the repository relative to the named
server instance directory.
# We are unable to set the repository with the property
org.apache.geronimo.repository.boot.path to be relative to the named server
instance directory.
From what I could decipher, these are the (or some) of the primary classes
defining the repository
-
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
-
plugins/jaxws/geronimo-jaxws-sun-tools/src/main/java/org/apache/geronimo/jaxws/sun/tools/JAXWSToolsCLI.java
-
plugins/cxf/geronimo-cxf-tools/src/main/java/org/apache/geronimo/cxf/tools/JAXWSToolsCLI.java
And the property org.apache.geronimo.repository.boot.path has a prepended
X in each of the three files.
This tells me it was specifically disabled, and probably for some big issue.
{noformat:borderStyle=solid}
#
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
...
Collection repositories = null;
ArtifactResolver artifactResolver = null;
if (enableBootRepo) {
String repository =
System.getProperty(Xorg.apache.geronimo.repository.boot.path, repository);
Maven2Repository bootRepository = new Maven2Repository(new
File(getBootDirectory(), repository));
repositories = Collections.singleton(bootRepository);
artifactResolver = new DefaultArtifactResolver(new
DefaultArtifactManager(), bootRepository);
} else {
// a bootstrap configuration can not have any dependencies
List dependencies =
configurationData.getEnvironment().getDependencies();
if (!dependencies.isEmpty()) {
configurationData.getEnvironment().setDependencies(Collections.EMPTY_SET);
}
}
...
{noformat}
To produce this issue, follow these steps:
# Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
# Create a Geronimo named instance directory as /opt/geronimo3/gserv1
# Move the directories var, etc, and repository into /opt/geronimo3/gserv1
# If patch GERONIMO-6275 in applied, start with this:
-- env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=/opt/geronimo3/gserv1
/opt/geronimo3/bin/geronimo run
# Or. without the patch, Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issues in GERONIMO-6174
export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
# Attempt to specify the correct root path to the repository for this
# named server instance
GERONIMO_OPTS=${GERONIMO_OPTS}
-Dorg.apache.geronimo.repository.boot.path=${GHOME}/${GVIRT}/repository
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat}
When starting the Geronimo named server instance with the above start script
the following error is experienced:
{noformat:borderStyle=solid}
[user@linux gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
[jira] [Commented] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212629#comment-13212629
]
Russell E Glaue commented on GERONIMO-6281:
---
If we change the activemq.data property in
newinstance/var/config/config-substitutions.properties, then it MUST be
changed as follows:
activemq.data = /fullpathto/geronimo_home/newinstance/var/activemq
Refer to the example I gave showing ActiveMQ creating var directory relative
to the path Geronimo was started. You can see that activemq.data is relative
to the current working directory.
So this means there is a potential problem when starting Geronimo as a Unix
init service. If the init script does not change directory to GERONIMO_HOME,
and activemq.data = newinstance/var/activemq then you will end up with
ActiveMQ deploying all its files in /etc/newinstance/var/activemq
I really believe we need to change the ActiveMQ to use GERONIMO_SERVER as the
root working path instead of the current path Geronimo is in upon startup.
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq.patch, geronimo-6281-karaf.patch,
geronimo-6281-snapshot.patch, geronimo-6281-trunk-karaf.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder
[jira] [Commented] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212669#comment-13212669
]
Russell E Glaue commented on GERONIMO-6281:
---
Let's keep in mind GERONIMO-5164 GERONIMO-5988 . We want to be able to deploy a
new instance of Geronimo with very little or no manual configuration in
config-substitutions.
If we leave as last proposed, setting activemq.data will be a requirement for
any Geronimo instance, including the default.
The workaround is for the shell to change directory to GERONIMO_SERVER before
executing the startup procedure.
-RG
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq.patch, geronimo-6281-karaf.patch,
geronimo-6281-snapshot.patch, geronimo-6281-trunk-karaf.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var/monitoring/snapshot-config.xml (Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for
$PWD/var/monitoring
-- Solution:
--- SnapshotConfigXMLBuilder should instead be using a full path to
var/monitoring, i.e. org.apache.geronimo.server.dir/var/monitoring
[jira] [Commented] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212685#comment-13212685
]
Russell E Glaue commented on GERONIMO-6281:
---
I just found this bug: GERONIMO-6272: server can not be started if installation
path contains bracket ()
This is definitely related, and the resolution as I proposed will also resolve
GERONIMO-6272
Here is why:
- When we start Geronimo, our start scripts take care of remove all unsafe
characters and resolve sym links
- GERONIMO_HOME, GERONIMO_SERVER are safe paths before being based on to
startup the JVM
- ActiveMQ uses the working directory path which may not be safe, as is the
case with GERONIMO-6272
This is another reason to change ActiveMQ to use GERONIMO_SERVER.
ActiveMQ seems to want to use a variable named ${activemq.base}, but it does
not appear to be set in Geronimo.
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq.patch, geronimo-6281-karaf.patch,
geronimo-6281-snapshot.patch, geronimo-6281-trunk-karaf.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var/monitoring/snapshot
[jira] [Commented] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212688#comment-13212688
]
Russell E Glaue commented on GERONIMO-6281:
---
Where this should be done or not, when setting
activemq.data = ${activemq.base}/var/activemq
I receive this error output when I attempt to use ${activemq.base} in
config-substitutions:
WARN [JexlEngine]
org.apache.aries.blueprint.ext.JexlExpressionParser.evaluate@56![0,13]:
'activemq.base;' undefined variable activemq.base
It is similar to the error in GERONIMO-6272
ActiveMQ is not able to find a safe path on its own. Thus Geronimo must
configure a safe path for ActiveMQ.
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq.patch, geronimo-6281-karaf.patch,
geronimo-6281-snapshot.patch, geronimo-6281-trunk-karaf.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var/monitoring/snapshot-config.xml (Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for
$PWD/var/monitoring
-- Solution:
--- SnapshotConfigXMLBuilder should instead be using a full path to
var
[jira] [Commented] (GERONIMO-6272) server can not be started if installation path contains bracket ()
[ https://issues.apache.org/jira/browse/GERONIMO-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212697#comment-13212697 ] Russell E Glaue commented on GERONIMO-6272: --- I know why this is occurring. We are working on a resolution in GERONIMO-6281 that could potentially fix this issue. ActiveMQ uses a parser org.apache.aries.blueprint.ext.JexlExpressionParser.evaluate to obtain the value of activemq.data from var/config/config-substitutions.properties. If activemq.data is a relative path (and it is by default) ActiveMQ prepends the current working directory to activemq.data to get a full path - this is the path to the directory Geronimo is in when it is started up, and this is not necessarily GERONIMO_HOME. If the current working directory has unsafe characters in it, there is an error as reported. The current work-around is to provide the full path with safe characters to var/activemq for activemq.data in config-substitutions.properties. Example: activemq.data = /pathto/geronimo_home/var/activemq server can not be started if installation path contains bracket () Key: GERONIMO-6272 URL: https://issues.apache.org/jira/browse/GERONIMO-6272 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0-beta-1 Environment: win7 64bit,oracle jdk 1.6.0_26 Reporter: Saphen Qiu Labels: bracket, startup I install geronimo on this path c:\New folder (x), I can not start server with any commands, and get the following errors. But if I rename the folder to New folder without (), then the server can be started successfully. *** C:\New folder (x)\bingeronimo.bat run -c Using GERONIMO_HOME: C:\New folder (x) Using GERONIMO_TMPDIR: C:\New folder (x)\var\temp Using JRE_HOME:C:\Program\Java\jdk1.6.0_26\jre __ _ / /___ _ (_) ___ / / __ / _ \/ ___/ __ \/ __ \/ // __ `__ \/ __ \ / /_/ // __/ / / /_/ / / / / // / / / / / /_/ / \/ \___/_/ \/_/ /_/_//_/ /_/ /_/\/ Apache Geronimo (3.0-beta-2-SNAPSHOT) Hit 'tab' for a list of available commands and '[cmd] --help' for help on a specific command. Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo. geronimo 2012-02-14 15:39:27,135 WARN [FeaturesServiceImpl] Unable to add features repository mvn:org.apache.geronimo. framework/karaf-framework/3.0-beta-2-SNAPSHOT/xml/features at startup java.lang.RuntimeException: URL [mvn:org.apache.geronimo.framework/karaf-framework/3.0-beta-2-SNAPSHOT/xml/features] cou ld not be resolved. at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195) at org.apache.karaf.features.internal.FeatureValidationUtil.validate(FeatureValidationUtil.java:49) at org.apache.karaf.features.internal.FeaturesServiceImpl.validateRepository(FeaturesServiceImpl.java:199) at org.apache.karaf.features.internal.FeaturesServiceImpl.internalAddRepository(FeaturesServiceImpl.java:210) at org.apache.karaf.features.internal.FeaturesServiceImpl.start(FeaturesServiceImpl.java:918) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:226) at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:824) at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:636) at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:724) at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64) at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219) at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:147) at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl .java:640) at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:331) at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:227) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun
[jira] [Commented] (GERONIMO-6272) server can not be started if installation path contains bracket ()
[ https://issues.apache.org/jira/browse/GERONIMO-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212710#comment-13212710 ] Russell E Glaue commented on GERONIMO-6272: --- This error was reported WARN [JexlEngine] org.apache.aries.blueprint.ext.JexlExpressionParser.evaluate@56![0,10]: 'kara f.base;' undefined variable karaf.base Try setting the java property karaf.base in GERONIMO_OPTS in your startup procedure. Example. if you Geronimo install directory is C:\New folder (x) DOS cd C:\New folder (x) DOS set GERONIMO_OPTS=-Dkaraf.base=%CD% DOS bin/geronimo start server can not be started if installation path contains bracket () Key: GERONIMO-6272 URL: https://issues.apache.org/jira/browse/GERONIMO-6272 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0-beta-1 Environment: win7 64bit,oracle jdk 1.6.0_26 Reporter: Saphen Qiu Labels: bracket, startup I install geronimo on this path c:\New folder (x), I can not start server with any commands, and get the following errors. But if I rename the folder to New folder without (), then the server can be started successfully. *** C:\New folder (x)\bingeronimo.bat run -c Using GERONIMO_HOME: C:\New folder (x) Using GERONIMO_TMPDIR: C:\New folder (x)\var\temp Using JRE_HOME:C:\Program\Java\jdk1.6.0_26\jre __ _ / /___ _ (_) ___ / / __ / _ \/ ___/ __ \/ __ \/ // __ `__ \/ __ \ / /_/ // __/ / / /_/ / / / / // / / / / / /_/ / \/ \___/_/ \/_/ /_/_//_/ /_/ /_/\/ Apache Geronimo (3.0-beta-2-SNAPSHOT) Hit 'tab' for a list of available commands and '[cmd] --help' for help on a specific command. Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo. geronimo 2012-02-14 15:39:27,135 WARN [FeaturesServiceImpl] Unable to add features repository mvn:org.apache.geronimo. framework/karaf-framework/3.0-beta-2-SNAPSHOT/xml/features at startup java.lang.RuntimeException: URL [mvn:org.apache.geronimo.framework/karaf-framework/3.0-beta-2-SNAPSHOT/xml/features] cou ld not be resolved. at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195) at org.apache.karaf.features.internal.FeatureValidationUtil.validate(FeatureValidationUtil.java:49) at org.apache.karaf.features.internal.FeaturesServiceImpl.validateRepository(FeaturesServiceImpl.java:199) at org.apache.karaf.features.internal.FeaturesServiceImpl.internalAddRepository(FeaturesServiceImpl.java:210) at org.apache.karaf.features.internal.FeaturesServiceImpl.start(FeaturesServiceImpl.java:918) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:226) at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:824) at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:636) at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:724) at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64) at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219) at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:147) at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl .java:640) at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:331) at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:227) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.j ava:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206 ) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886
[jira] [Commented] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212727#comment-13212727
]
Russell E Glaue commented on GERONIMO-6281:
---
Okay,
I figured out how to, for the time being, resolve this issue in a way that if
this were done the user would not have to change activemq.data in
config-substitutions.properties to account for a Geronimo instance
configuration.
Set activemq.data in GERONIMO_SERVER/var/config/config-substitions.properties
to the following:
activemq.data = ${org.apache.geronimo.server.dir}/var/activemq
With the patch from GERONIMO-6275 applied, which always sets
org.apache.geronimo.server.dir on startup, this will work. I consider this a
temporary fix, however. I still advocate for ActiveMQ to internally use
org.apache.geronimo.server.dir as the root path to activemq.data only if
activemq.data is a relative path.
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq.patch, geronimo-6281-karaf.patch,
geronimo-6281-snapshot.patch, geronimo-6281-trunk-karaf.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var
[jira] [Commented] (GERONIMO-6175) Environment variable org.apache.geronimo.repository.boot.path not used, Repository path does not observe named instances
[
https://issues.apache.org/jira/browse/GERONIMO-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212736#comment-13212736
]
Russell E Glaue commented on GERONIMO-6175:
---
The multiple repositories is for adding secondary repositories, and not for
replacing the boot repository.
It has been discussed on the mail list that multiple instances of Geronimo
cannot safely share the same repository because Geronimo is writing back to the
repository for global artifacts.
If this is true, then one of two things should be done:
# Change Geronimo so that multiple instances can safely share a single
boot/global repository
# Change the default location of the Geronimo boot/global repository from
GERONIMO_HOME/repository to GERONIMO_SERVER/repository
Can you verify that multiple Geronimo instances can safely share a common
repository?
Environment variable org.apache.geronimo.repository.boot.path not used,
Repository path does not observe named instances
Key: GERONIMO-6175
URL: https://issues.apache.org/jira/browse/GERONIMO-6175
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 3.0, 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
I only list this issue as minor, as the issue does not prevent running
Geronimo, or more than one copy of Geronimo on a single server. However, this
issue does prevent the proper utilization of multiple named server instances.
Two issues:
# On startup, Geronimo does not use the repository relative to the named
server instance directory.
# We are unable to set the repository with the property
org.apache.geronimo.repository.boot.path to be relative to the named server
instance directory.
From what I could decipher, these are the (or some) of the primary classes
defining the repository
-
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
-
plugins/jaxws/geronimo-jaxws-sun-tools/src/main/java/org/apache/geronimo/jaxws/sun/tools/JAXWSToolsCLI.java
-
plugins/cxf/geronimo-cxf-tools/src/main/java/org/apache/geronimo/cxf/tools/JAXWSToolsCLI.java
And the property org.apache.geronimo.repository.boot.path has a prepended
X in each of the three files.
This tells me it was specifically disabled, and probably for some big issue.
{noformat:borderStyle=solid}
#
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
...
Collection repositories = null;
ArtifactResolver artifactResolver = null;
if (enableBootRepo) {
String repository =
System.getProperty(Xorg.apache.geronimo.repository.boot.path, repository);
Maven2Repository bootRepository = new Maven2Repository(new
File(getBootDirectory(), repository));
repositories = Collections.singleton(bootRepository);
artifactResolver = new DefaultArtifactResolver(new
DefaultArtifactManager(), bootRepository);
} else {
// a bootstrap configuration can not have any dependencies
List dependencies =
configurationData.getEnvironment().getDependencies();
if (!dependencies.isEmpty()) {
configurationData.getEnvironment().setDependencies(Collections.EMPTY_SET);
}
}
...
{noformat}
To produce this issue, follow these steps:
# Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
# Create a Geronimo named instance directory as /opt/geronimo3/gserv1
# Move the directories var, etc, and repository into /opt/geronimo3/gserv1
# If patch GERONIMO-6275 in applied, start with this:
-- env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=/opt/geronimo3/gserv1
/opt/geronimo3/bin/geronimo run
# Or. without the patch, Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issues in GERONIMO-6174
export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
# Attempt to specify the correct root path to the repository for this
# named server instance
GERONIMO_OPTS=${GERONIMO_OPTS}
-Dorg.apache.geronimo.repository.boot.path=${GHOME}/${GVIRT}/repository
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat}
When
[jira] [Commented] (GERONIMO-6175) Environment variable org.apache.geronimo.repository.boot.path not used, Repository path does not observe named instances
[
https://issues.apache.org/jira/browse/GERONIMO-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212828#comment-13212828
]
Russell E Glaue commented on GERONIMO-6175:
---
Review the Geronimo 2.0 Documentation
https://cwiki.apache.org/GMOxDOC20/multiple-repositories.html
The G2.0 documentation is clear in stating that one of the intentions is having
a separate repository for each Geronimo instance, and not using a shared
repository.
Environment variable org.apache.geronimo.repository.boot.path not used,
Repository path does not observe named instances
Key: GERONIMO-6175
URL: https://issues.apache.org/jira/browse/GERONIMO-6175
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 3.0, 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
I only list this issue as minor, as the issue does not prevent running
Geronimo, or more than one copy of Geronimo on a single server. However, this
issue does prevent the proper utilization of multiple named server instances.
Two issues:
# On startup, Geronimo does not use the repository relative to the named
server instance directory.
# We are unable to set the repository with the property
org.apache.geronimo.repository.boot.path to be relative to the named server
instance directory.
From what I could decipher, these are the (or some) of the primary classes
defining the repository
-
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
-
plugins/jaxws/geronimo-jaxws-sun-tools/src/main/java/org/apache/geronimo/jaxws/sun/tools/JAXWSToolsCLI.java
-
plugins/cxf/geronimo-cxf-tools/src/main/java/org/apache/geronimo/cxf/tools/JAXWSToolsCLI.java
And the property org.apache.geronimo.repository.boot.path has a prepended
X in each of the three files.
This tells me it was specifically disabled, and probably for some big issue.
{noformat:borderStyle=solid}
#
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
...
Collection repositories = null;
ArtifactResolver artifactResolver = null;
if (enableBootRepo) {
String repository =
System.getProperty(Xorg.apache.geronimo.repository.boot.path, repository);
Maven2Repository bootRepository = new Maven2Repository(new
File(getBootDirectory(), repository));
repositories = Collections.singleton(bootRepository);
artifactResolver = new DefaultArtifactResolver(new
DefaultArtifactManager(), bootRepository);
} else {
// a bootstrap configuration can not have any dependencies
List dependencies =
configurationData.getEnvironment().getDependencies();
if (!dependencies.isEmpty()) {
configurationData.getEnvironment().setDependencies(Collections.EMPTY_SET);
}
}
...
{noformat}
To produce this issue, follow these steps:
# Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
# Create a Geronimo named instance directory as /opt/geronimo3/gserv1
# Move the directories var, etc, and repository into /opt/geronimo3/gserv1
# If patch GERONIMO-6275 in applied, start with this:
-- env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=/opt/geronimo3/gserv1
/opt/geronimo3/bin/geronimo run
# Or. without the patch, Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issues in GERONIMO-6174
export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
# Attempt to specify the correct root path to the repository for this
# named server instance
GERONIMO_OPTS=${GERONIMO_OPTS}
-Dorg.apache.geronimo.repository.boot.path=${GHOME}/${GVIRT}/repository
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat}
When starting the Geronimo named server instance with the above start script
the following error is experienced:
{noformat:borderStyle=solid}
[user@linux gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
[jira] [Updated] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue updated GERONIMO-6281:
--
Attachment: geronimo-6281-activemq-config-substitutions.patch
geronimo-6281-activemq-config-substitutions.patch
This patch makes changes in config-substitution.properties are previously
discussed.
This patch is only a suggestion. However, it does resolve the issue with
ActiveMQ documented in this jira.
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq-config-substitutions.patch,
geronimo-6281-activemq.patch, geronimo-6281-karaf.patch,
geronimo-6281-snapshot.patch, geronimo-6281-trunk-karaf.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var/monitoring/snapshot-config.xml (Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for
$PWD/var/monitoring
-- Solution:
--- SnapshotConfigXMLBuilder should instead be using a full path to
var/monitoring, i.e. org.apache.geronimo.server.dir/var/monitoring
-- Affected code:
---
trunk/plugins/monitoring/agent-ejb/src/main/java/org/apache/geronimo/monitoring/ejb
[jira] [Commented] (GERONIMO-6175) Environment variable org.apache.geronimo.repository.boot.path not used, Repository path does not observe named instances
[
https://issues.apache.org/jira/browse/GERONIMO-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212936#comment-13212936
]
Russell E Glaue commented on GERONIMO-6175:
---
I found the thread. Forrest, you were part of the discussion
http://apache-geronimo.328035.n3.nabble.com/Geronimo-directory-structure-amp-permissions-td3352899.html
There was discussion about G3.0 not being able to support multiple repositories.
You wrote in that thread that 3.0 does not support multiple instances as the
docs say.
- With all the patches provided and applied under the GERONIMO-6270 umbrella,
how close are we now?
- What do we have left to enable a safe run-time of multiple instances with a
shared repository?
- And is it possible in G30, as indicated in the G20 docs, for each instance to
have its own primary repository and no shared repository?
Environment variable org.apache.geronimo.repository.boot.path not used,
Repository path does not observe named instances
Key: GERONIMO-6175
URL: https://issues.apache.org/jira/browse/GERONIMO-6175
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 3.0, 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
I only list this issue as minor, as the issue does not prevent running
Geronimo, or more than one copy of Geronimo on a single server. However, this
issue does prevent the proper utilization of multiple named server instances.
Two issues:
# On startup, Geronimo does not use the repository relative to the named
server instance directory.
# We are unable to set the repository with the property
org.apache.geronimo.repository.boot.path to be relative to the named server
instance directory.
From what I could decipher, these are the (or some) of the primary classes
defining the repository
-
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
-
plugins/jaxws/geronimo-jaxws-sun-tools/src/main/java/org/apache/geronimo/jaxws/sun/tools/JAXWSToolsCLI.java
-
plugins/cxf/geronimo-cxf-tools/src/main/java/org/apache/geronimo/cxf/tools/JAXWSToolsCLI.java
And the property org.apache.geronimo.repository.boot.path has a prepended
X in each of the three files.
This tells me it was specifically disabled, and probably for some big issue.
{noformat:borderStyle=solid}
#
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
...
Collection repositories = null;
ArtifactResolver artifactResolver = null;
if (enableBootRepo) {
String repository =
System.getProperty(Xorg.apache.geronimo.repository.boot.path, repository);
Maven2Repository bootRepository = new Maven2Repository(new
File(getBootDirectory(), repository));
repositories = Collections.singleton(bootRepository);
artifactResolver = new DefaultArtifactResolver(new
DefaultArtifactManager(), bootRepository);
} else {
// a bootstrap configuration can not have any dependencies
List dependencies =
configurationData.getEnvironment().getDependencies();
if (!dependencies.isEmpty()) {
configurationData.getEnvironment().setDependencies(Collections.EMPTY_SET);
}
}
...
{noformat}
To produce this issue, follow these steps:
# Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
# Create a Geronimo named instance directory as /opt/geronimo3/gserv1
# Move the directories var, etc, and repository into /opt/geronimo3/gserv1
# If patch GERONIMO-6275 in applied, start with this:
-- env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=/opt/geronimo3/gserv1
/opt/geronimo3/bin/geronimo run
# Or. without the patch, Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issues in GERONIMO-6174
export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
# Attempt to specify the correct root path to the repository for this
# named server instance
GERONIMO_OPTS=${GERONIMO_OPTS}
-Dorg.apache.geronimo.repository.boot.path=${GHOME}/${GVIRT}/repository
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat
[jira] [Created] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
--
Key: GERONIMO-6284
URL: https://issues.apache.org/jira/browse/GERONIMO-6284
Project: Geronimo
Issue Type: Sub-task
Security Level: public (Regular issues)
Components: deployment
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Priority: Minor
Cannot deploy to a Geronimo Instance. Deploy expects GERONIMO_HOME/var/...
Create a new Geronimo instance as documented in
https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html
- remove GERONIMO_HOME/etc
- remove GERONIMO_HOME/var
- create the empty file GERONIMO_HOME/var
Start the Geronimo instance as follows:
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3/gserv1
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/geronimo run
{noformat}
Create a second repository for the new instance
- mkdir {{gserv1/repository}}
- Create {{gserv1/repository.xml}} as documented in
https://cwiki.apache.org/GMOxDOC30/configuring-multiple-repositories.html
{noformat:borderStyle=solid}
module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
environment
moduleId
groupIdorg.example.configs/groupId
artifactIdmyrepo/artifactId
version2.2/version
typecar/type
/moduleId
dependencies
dependency
groupIdorg.apache.geronimo.framework/groupId
artifactIdj2ee-system/artifactId
version2.2/version
typecar/type
/dependency
/dependencies
hidden-classes/
non-overridable-classes/
/environment
gbean name=Repo2
class=org.apache.geronimo.system.repository.Maven2Repository
attribute name=rootgserv1/repository//attribute
attribute name=resolveToServerfalse/attribute
reference name=ServerInfo
nameServerInfo/name
/reference
/gbean
gbean name=Local2
class=org.apache.geronimo.system.configuration.RepositoryConfigurationStore
reference name=Repository
nameRepo2/name
/reference
/gbean
/module
{noformat}
Deploy the repository.xml file
{noformat:borderStyle=solid}
linux$ cd /opt/geronimo3
linux$ env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=gserv1
/opt/geronimo3/bin/deploy -port 1199 deploy /opt/geronimo3/gserv1/repository.xml
{noformat}
The following error results:
{noformat:borderStyle=solid}
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0_25/jre
2012-02-21 15:33:44,695 ERROR [GBeanInstanceState] Error while starting; GBean
is now in the FAILED state:
abstractName=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car,j2eeType=AttributeStore,name=AttributeManager
java.io.IOException: Unable to create directory for
list:/opt/geronimo3/var/config
at
org.apache.geronimo.system.configuration.LocalAttributeManager.ensureParentDirectory(LocalAttributeManager.java:607)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:352)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:561)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:45)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:569)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean
[jira] [Commented] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13213061#comment-13213061
]
Russell E Glaue commented on GERONIMO-6284:
---
There is a problem I am not able to pinpoint in the Java code in which the a
ServerInstanceData class is passed to the LocalAttributeManager, such that
the shell path to config.xml and config-substitution.properties is a full path
of GERONIMO_HOME/var/config/... when instead it should be
GERONIMO_SERVER/var/config/
If a relative path to config.xml and config-substitution.properties is given to
LocalAttributeManager, it does the right thing by resolving it with
serverInfo.resolveServer() which resolves according to
org.apache.geronimo.server.dir . So the problem is definitely that the
incorrect path of GERONIMO_HOME/var/config... is being passed in to
LocalAttributeManager.
If I specify the org.apache.geronimo.config.file and
org.apache.geronimo.config.substitutions.file properties with the correct
paths, then the previously recorded error does not occur.
However, the new repository still cannot be created via deploy.
{noformat:borderStyle=solid}
[ger@server geronimo3]$ env GERONIMO_SERVER=gserv1
GERONIMO_OPTS=-Dorg.apache.geronimo.config.file=gserv1/var/config/config.xml
-Dorg.apache.geronimo.config.substitutions.file=gserv1/var/config/config-substitution.properties
bin/deploy -port 1199 deploy /opt/geronimo3/gserv1/repository.xml
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0_25/jre
org.apache.geronimo.kernel.config.LifecycleException: load of
org.apache.geronimo.framework/rmi-naming/3.0-SNAPSHOT/car failed
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:316)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:290)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:125)
at
org.apache.geronimo.system.main.MainBridge.loadPersistentConfigurations(MainBridge.java:82)
at
org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:57)
at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:32)
Caused by: org.osgi.framework.BundleException: Exception in
org.apache.geronimo.kernel.osgi.ConfigurationActivator.start() of bundle
org.apache.geronimo.framework.rmi-naming.
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:311)
... 7 more
Caused by: org.apache.geronimo.kernel.GBeanNotFoundException: More then one
GBean was found with type
'org.apache.geronimo.kernel.config.ConfigurationManager':
[?#org.apache.geronimo.kernel.config.ConfigurationManager] matches:
[org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/online-deployer/3.0-SNAPSHOT/car,j2eeType=ConfigurationManager,name=ConfigurationManager,
org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car,j2eeType=ConfigurationManager,name=ConfigurationManager]
at
org.apache.geronimo.kernel.basic.BasicRegistry.getGBeanInstance(BasicRegistry.java:161)
at
org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:293)
at
org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:288)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.getConfigurationManager(ConfigurationUtil.java:341)
at
org.apache.geronimo.kernel.osgi.ConfigurationActivator.start(ConfigurationActivator.java:56)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
... 11 more
{noformat}
Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var
[jira] [Commented] (GERONIMO-6284) Cannot deploy to multiple instances, deploy expects GERONIMO_HOME/var/
[
https://issues.apache.org/jira/browse/GERONIMO-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13213094#comment-13213094
]
Russell E Glaue commented on GERONIMO-6284:
---
It turns out that the previous command causes LocalAttributeManager and others
to create /opt/geronimo3/gserv1/gserv1/var/config/ directory.
When I created an empty file at /opt/geronimo3/gserv1/gserv1 and reissue the
command, I get this error.
Without the two java properties, they want GERONIMO_HOME/var/config
With the two java proeprties, they want GERONIMO_SERVER/{property-name}
If I remove the gserv1/... in the values of the properties, they want to look
for them as GERONIMO_HOME/var/config/... again.
This might indicate the path resolution logic is not quite right.
{noformat:borderStyle=solid}
[ger@linux7 geronimo3]$ env GERONIMO_SERVER=/opt/geronimo3/gserv1
GERONIMO_OPTS=-Dorg.apache.geronimo.config.file=gserv1/var/config/config.xml
-Dorg.apache.geronimo.config.substitutions.file=gserv1/var/config/config-substitution.properties
/opt/geronimo3/bin/deploy -port 1199 deploy
/opt/geronimo3/gserv1/repository.xml
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0_25/jre
2012-02-21 17:20:19,057 ERROR [LocalAttributeManager] Caught exception
java.io.FileNotFoundException:
/opt/geronimo3/gserv1/gserv1/var/config/config-substitution.properties (Not a
directory) trying to write properties file
/opt/geronimo3/gserv1/gserv1/var/config/config-substitution.properties
2012-02-21 17:20:19,062 ERROR [GBeanInstanceState] Error while starting; GBean
is now in the FAILED state:
abstractName=org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car,j2eeType=AttributeStore,name=AttributeManager
java.io.IOException: Unable to create directory for
list:/opt/geronimo3/gserv1/gserv1/var/config
at
org.apache.geronimo.system.configuration.LocalAttributeManager.ensureParentDirectory(LocalAttributeManager.java:607)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:352)
at
org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:561)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:45)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:569)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:466)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:225)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:702)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:681)
at
org.apache.geronimo.system.main.MainBridge.loadPersistentConfigurations(MainBridge.java:83)
at
org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:57)
at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:32)
2012-02-21 17:20:21,748 ERROR [LocalAttributeManager
[jira] [Commented] (GERONIMO-6175) Environment variable org.apache.geronimo.repository.boot.path not used, Repository path does not observe named instances
[
https://issues.apache.org/jira/browse/GERONIMO-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13213230#comment-13213230
]
Russell E Glaue commented on GERONIMO-6175:
---
I would guess GERONIMO-6285 is an issue related to sharing repositories. All
Geronimo instances will likely have to have a second repository just for local
deploying. The shared repository would only be for the 100MB core/bootstrap
stuff, and will have to be read-only.
I found another issue GERONIMO-6284, preventing the creation of a second
repository for Geronimo instances.
-RG
Environment variable org.apache.geronimo.repository.boot.path not used,
Repository path does not observe named instances
Key: GERONIMO-6175
URL: https://issues.apache.org/jira/browse/GERONIMO-6175
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 3.0, 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
I only list this issue as minor, as the issue does not prevent running
Geronimo, or more than one copy of Geronimo on a single server. However, this
issue does prevent the proper utilization of multiple named server instances.
Two issues:
# On startup, Geronimo does not use the repository relative to the named
server instance directory.
# We are unable to set the repository with the property
org.apache.geronimo.repository.boot.path to be relative to the named server
instance directory.
From what I could decipher, these are the (or some) of the primary classes
defining the repository
-
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
-
plugins/jaxws/geronimo-jaxws-sun-tools/src/main/java/org/apache/geronimo/jaxws/sun/tools/JAXWSToolsCLI.java
-
plugins/cxf/geronimo-cxf-tools/src/main/java/org/apache/geronimo/cxf/tools/JAXWSToolsCLI.java
And the property org.apache.geronimo.repository.boot.path has a prepended
X in each of the three files.
This tells me it was specifically disabled, and probably for some big issue.
{noformat:borderStyle=solid}
#
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
...
Collection repositories = null;
ArtifactResolver artifactResolver = null;
if (enableBootRepo) {
String repository =
System.getProperty(Xorg.apache.geronimo.repository.boot.path, repository);
Maven2Repository bootRepository = new Maven2Repository(new
File(getBootDirectory(), repository));
repositories = Collections.singleton(bootRepository);
artifactResolver = new DefaultArtifactResolver(new
DefaultArtifactManager(), bootRepository);
} else {
// a bootstrap configuration can not have any dependencies
List dependencies =
configurationData.getEnvironment().getDependencies();
if (!dependencies.isEmpty()) {
configurationData.getEnvironment().setDependencies(Collections.EMPTY_SET);
}
}
...
{noformat}
To produce this issue, follow these steps:
# Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
# Create a Geronimo named instance directory as /opt/geronimo3/gserv1
# Move the directories var, etc, and repository into /opt/geronimo3/gserv1
# If patch GERONIMO-6275 in applied, start with this:
-- env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=/opt/geronimo3/gserv1
/opt/geronimo3/bin/geronimo run
# Or. without the patch, Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issues in GERONIMO-6174
export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
# Attempt to specify the correct root path to the repository for this
# named server instance
GERONIMO_OPTS=${GERONIMO_OPTS}
-Dorg.apache.geronimo.repository.boot.path=${GHOME}/${GVIRT}/repository
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat}
When starting the Geronimo named server instance with the above start script
the following error is experienced:
{noformat:borderStyle=solid}
[user@linux gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME
[jira] [Commented] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[ https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211874#comment-13211874 ] Russell E Glaue commented on GERONIMO-6275: --- Yes, I agree with what you have determined. I will help you test, at least the unix scripts, once committed. -RG Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts -- Key: GERONIMO-6275 URL: https://issues.apache.org/jira/browse/GERONIMO-6275 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Assignee: Russell E Glaue Priority: Minor Labels: geronimo Attachments: geronimo-6275-procrun_service.patch, geronimo-6275.patch Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987, GERONIMO-4229 It would be easier to support multiple server instances of Geronimo if there is one shell variable that is used to reference the path on disk to the instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME installation path. This issue tracks the discussion and modification of such a change. GERONIMO_SERVER defines: - GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified - GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if GERONIMO_SERVER is a relative path - GERONIMO_SERVER defines org.apache.geronimo.server.dir In the java code there are the following properties: # org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable # org.apache.geronimo.server.dir - proposed to be equivelant to GERONIMO_SERVER The words BASE versus HOME appear a few times in the source. Once example is karaf.home and karaf.base properties. According to the code usage, it is aparant that these terms are assumed to mean these things: # HOME - path location on disk of read-only binaries and configuration # BASE - path location on disk of read-write configuration and data storage The term BASE is intended to point at a Geronimo Server Instance Base path. However, this has not been clearly defined, and has appeared to cause some misusage. Thus this and other issues lead to the removal of GERONIMO_BASE shell variable and org.apache.geronimo.base.dir java property in GERONIMO-4229 . Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir java property must be defined in the GERONIMO_OPTS variable. However, this prevents the Shell scripts from being able to know and use the path location to the Geronimo Server Instance. In particular, there are a few issues affected by a variable like this not being available. # Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts as GERONIMO_HOME/var/tmp. In turn, the java property java.io.tmpdir is set to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp). Shouldn't GERONIMO_TMPDIR instead be set to a value provided by GERONIMO_SERVER/var/tmp ? -- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools -- This can be argued to whether or not all Geronimo Server Instance should share a common temp directory. # Reported in GERONIMO-6174 - The java properties karaf.home and karaf.base are both being set to GERONIMO_HOME. When instead karaf.base should be set to a value held by GERONIMO_SERVER. -- affected scripts: client, geronimo, internalLauncher -- see resulting errors and reasoning in GERONIMO-6174 # Not Reported - The java property java.util.logging.config.file is being set to GERONIMO_HOME/etc/java.util.logging.properties . It is intended to be an empty configuration file. This only causes a problem when using instances if GERONIMO_HOME/etc does not exist (it would not exist if GERONIMO_SERVER/etc is intended to be used). -- affected scripts: client, geronimo, internalLauncher # Not Reported - Logging startup output to GERONIMO_HOME/var/log/geronimo.out - Obviously if multiple instances are being started, this should be GERONIMO_SERVER/var/log/geronimo.out . Any error is silent if var/log/geronimo.out does not exist. -- affected scripts: geronimo # Not Reported - The register-service script does a grep and awk on GERONIMO_HOME/var/config/config-substitutions.properties to discover the portOffset . Obviously this will not work for multiple instances -- The register-service script does not take multiple instances into consideration at all -- affected scripts: register-service Solution: - Create a new shell
[jira] [Commented] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[ https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211930#comment-13211930 ] Russell E Glaue commented on GERONIMO-6275: --- If we are going to put the resolution logic for GERONIMO_SERVER and GERONIMO_TMPDIR in setjavaenv script, I recommend we put in comments in the geronimo deploy client and setjavaenv scripts to note this and hopefully lower the possibility of misunderstanding - because the current comments say otherwise. I will first test the changes you committed, and then submit a patch to suggest the comments that could be added. Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts -- Key: GERONIMO-6275 URL: https://issues.apache.org/jira/browse/GERONIMO-6275 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Assignee: Russell E Glaue Priority: Minor Labels: geronimo Attachments: geronimo-6275-procrun_service.patch, geronimo-6275.patch Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987, GERONIMO-4229 It would be easier to support multiple server instances of Geronimo if there is one shell variable that is used to reference the path on disk to the instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME installation path. This issue tracks the discussion and modification of such a change. GERONIMO_SERVER defines: - GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified - GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if GERONIMO_SERVER is a relative path - GERONIMO_SERVER defines org.apache.geronimo.server.dir In the java code there are the following properties: # org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable # org.apache.geronimo.server.dir - proposed to be equivelant to GERONIMO_SERVER The words BASE versus HOME appear a few times in the source. Once example is karaf.home and karaf.base properties. According to the code usage, it is aparant that these terms are assumed to mean these things: # HOME - path location on disk of read-only binaries and configuration # BASE - path location on disk of read-write configuration and data storage The term BASE is intended to point at a Geronimo Server Instance Base path. However, this has not been clearly defined, and has appeared to cause some misusage. Thus this and other issues lead to the removal of GERONIMO_BASE shell variable and org.apache.geronimo.base.dir java property in GERONIMO-4229 . Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir java property must be defined in the GERONIMO_OPTS variable. However, this prevents the Shell scripts from being able to know and use the path location to the Geronimo Server Instance. In particular, there are a few issues affected by a variable like this not being available. # Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts as GERONIMO_HOME/var/tmp. In turn, the java property java.io.tmpdir is set to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp). Shouldn't GERONIMO_TMPDIR instead be set to a value provided by GERONIMO_SERVER/var/tmp ? -- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools -- This can be argued to whether or not all Geronimo Server Instance should share a common temp directory. # Reported in GERONIMO-6174 - The java properties karaf.home and karaf.base are both being set to GERONIMO_HOME. When instead karaf.base should be set to a value held by GERONIMO_SERVER. -- affected scripts: client, geronimo, internalLauncher -- see resulting errors and reasoning in GERONIMO-6174 # Not Reported - The java property java.util.logging.config.file is being set to GERONIMO_HOME/etc/java.util.logging.properties . It is intended to be an empty configuration file. This only causes a problem when using instances if GERONIMO_HOME/etc does not exist (it would not exist if GERONIMO_SERVER/etc is intended to be used). -- affected scripts: client, geronimo, internalLauncher # Not Reported - Logging startup output to GERONIMO_HOME/var/log/geronimo.out - Obviously if multiple instances are being started, this should be GERONIMO_SERVER/var/log/geronimo.out . Any error is silent if var/log/geronimo.out does not exist. -- affected scripts: geronimo # Not Reported - The register-service script does a grep and awk
[jira] [Updated] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[ https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell E Glaue updated GERONIMO-6275: -- Attachment: geronimo-6275-B-comments.patch geronimo-6275-B-comments.patch This patch file adds comments to the shell scripts explaining the purpose of setjavaenv.sh/bat and how GERONIMO_SERVER and GERONIMO_TMPDIR are set there. Also, a few minor corrections to comments. This patch includes changes for service_pr.bat Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts -- Key: GERONIMO-6275 URL: https://issues.apache.org/jira/browse/GERONIMO-6275 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Assignee: Russell E Glaue Priority: Minor Labels: geronimo Attachments: geronimo-6275-B-comments.patch, geronimo-6275-procrun_service.patch, geronimo-6275.patch Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987, GERONIMO-4229 It would be easier to support multiple server instances of Geronimo if there is one shell variable that is used to reference the path on disk to the instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME installation path. This issue tracks the discussion and modification of such a change. GERONIMO_SERVER defines: - GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified - GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if GERONIMO_SERVER is a relative path - GERONIMO_SERVER defines org.apache.geronimo.server.dir In the java code there are the following properties: # org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable # org.apache.geronimo.server.dir - proposed to be equivelant to GERONIMO_SERVER The words BASE versus HOME appear a few times in the source. Once example is karaf.home and karaf.base properties. According to the code usage, it is aparant that these terms are assumed to mean these things: # HOME - path location on disk of read-only binaries and configuration # BASE - path location on disk of read-write configuration and data storage The term BASE is intended to point at a Geronimo Server Instance Base path. However, this has not been clearly defined, and has appeared to cause some misusage. Thus this and other issues lead to the removal of GERONIMO_BASE shell variable and org.apache.geronimo.base.dir java property in GERONIMO-4229 . Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir java property must be defined in the GERONIMO_OPTS variable. However, this prevents the Shell scripts from being able to know and use the path location to the Geronimo Server Instance. In particular, there are a few issues affected by a variable like this not being available. # Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts as GERONIMO_HOME/var/tmp. In turn, the java property java.io.tmpdir is set to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp). Shouldn't GERONIMO_TMPDIR instead be set to a value provided by GERONIMO_SERVER/var/tmp ? -- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools -- This can be argued to whether or not all Geronimo Server Instance should share a common temp directory. # Reported in GERONIMO-6174 - The java properties karaf.home and karaf.base are both being set to GERONIMO_HOME. When instead karaf.base should be set to a value held by GERONIMO_SERVER. -- affected scripts: client, geronimo, internalLauncher -- see resulting errors and reasoning in GERONIMO-6174 # Not Reported - The java property java.util.logging.config.file is being set to GERONIMO_HOME/etc/java.util.logging.properties . It is intended to be an empty configuration file. This only causes a problem when using instances if GERONIMO_HOME/etc does not exist (it would not exist if GERONIMO_SERVER/etc is intended to be used). -- affected scripts: client, geronimo, internalLauncher # Not Reported - Logging startup output to GERONIMO_HOME/var/log/geronimo.out - Obviously if multiple instances are being started, this should be GERONIMO_SERVER/var/log/geronimo.out . Any error is silent if var/log/geronimo.out does not exist. -- affected scripts: geronimo # Not Reported - The register-service script does a grep and awk on GERONIMO_HOME/var/config/config-substitutions.properties to discover the portOffset . Obviously this will not work
[jira] [Commented] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[
https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211983#comment-13211983
]
Russell E Glaue commented on GERONIMO-6275:
---
Since were now setting GERONIMO_TMPDIR in setjavaenv.sh, we also need to make
sure that is checked in the # For Cygwin, ensure paths are in UNIX format
before anything is touched section - in the scripts geronimo, client and
deploy. Batch files are okay since they do not account for Cygwin.
Otherwise, all of my testing is successful with the new changes you committed.
Change...
{noformat:borderStyle=solid}
# For Cygwin, ensure paths are in UNIX format before anything is touched
if $cygwin; then
[ -n $JAVA_HOME ] JAVA_HOME=`cygpath --unix $JAVA_HOME`
[ -n $JRE_HOME ] JRE_HOME=`cygpath --unix $JRE_HOME`
[ -n $JDB_SRCPATH ] JDB_SRCPATH=`cygpath --unix $JDB_SRCPATH`
[ -n $GERONIMO_HOME ] GERONIMO_HOME=`cygpath --unix $GERONIMO_HOME`
[ -n $GERONIMO_SERVER ] GERONIMO_SERVER=`cygpath --unix
$GERONIMO_SERVER`
fi
{noformat}
To...
{noformat:borderStyle=solid}
# For Cygwin, ensure paths are in UNIX format before anything is touched
if $cygwin; then
[ -n $JAVA_HOME ] JAVA_HOME=`cygpath --unix $JAVA_HOME`
[ -n $JRE_HOME ] JRE_HOME=`cygpath --unix $JRE_HOME`
[ -n $JDB_SRCPATH ] JDB_SRCPATH=`cygpath --unix $JDB_SRCPATH`
[ -n $GERONIMO_HOME ] GERONIMO_HOME=`cygpath --unix $GERONIMO_HOME`
[ -n $GERONIMO_SERVER ] GERONIMO_SERVER=`cygpath --unix
$GERONIMO_SERVER`
[ -n $GERONIMO_TMPDIR ] GERONIMO_TMPDIR=`cygpath --unix
$GERONIMO_TMPDIR`
fi
{noformat}
Defining and Using org.apache.geronimo.server.dir versus
org.apache.geronimo.home.dir in shell scripts
--
Key: GERONIMO-6275
URL: https://issues.apache.org/jira/browse/GERONIMO-6275
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6275-B-comments.patch,
geronimo-6275-procrun_service.patch, geronimo-6275.patch
Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987,
GERONIMO-4229
It would be easier to support multiple server instances of Geronimo if there
is one shell variable that is used to reference the path on disk to the
instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME
installation path. This issue tracks the discussion and modification of such
a change.
GERONIMO_SERVER defines:
- GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified
- GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if
GERONIMO_SERVER is a relative path
- GERONIMO_SERVER defines org.apache.geronimo.server.dir
In the java code there are the following properties:
# org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable
# org.apache.geronimo.server.dir - proposed to be equivelant to
GERONIMO_SERVER
The words BASE versus HOME appear a few times in the source. Once example
is karaf.home and karaf.base properties. According to the code usage, it
is aparant that these terms are assumed to mean these things:
# HOME - path location on disk of read-only binaries and configuration
# BASE - path location on disk of read-write configuration and data storage
The term BASE is intended to point at a Geronimo Server Instance Base path.
However, this has not been clearly defined, and has appeared to cause some
misusage. Thus this and other issues lead to the removal of GERONIMO_BASE
shell variable and org.apache.geronimo.base.dir java property in
GERONIMO-4229 .
Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir
java property must be defined in the GERONIMO_OPTS variable. However, this
prevents the Shell scripts from being able to know and use the path location
to the Geronimo Server Instance.
In particular, there are a few issues affected by a variable like this not
being available.
# Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts
as GERONIMO_HOME/var/tmp. In turn, the java property java.io.tmpdir is set
to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp). Shouldn't GERONIMO_TMPDIR
instead be set to a value provided by GERONIMO_SERVER/var/tmp ?
-- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools
-- This can be argued to whether or not all Geronimo Server Instance should
share a common temp directory.
# Reported in GERONIMO-6174 - The java properties
[jira] [Issue Comment Edited] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[
https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211983#comment-13211983
]
Russell E Glaue edited comment on GERONIMO-6275 at 2/20/12 5:15 PM:
Since were now setting GERONIMO_TMPDIR in setjavaenv.sh, we also need to make
sure that is checked in the # For Cygwin, ensure paths are in UNIX format
before anything is touched section - in the four scripts: geronimo, client,
deploy and jaxws-tools.sh. Batch files are okay since they do not account for
Cygwin.
Otherwise, all of my testing is successful with the new changes you committed.
Change...
{noformat:borderStyle=solid}
# For Cygwin, ensure paths are in UNIX format before anything is touched
if $cygwin; then
[ -n $JAVA_HOME ] JAVA_HOME=`cygpath --unix $JAVA_HOME`
[ -n $JRE_HOME ] JRE_HOME=`cygpath --unix $JRE_HOME`
[ -n $JDB_SRCPATH ] JDB_SRCPATH=`cygpath --unix $JDB_SRCPATH`
[ -n $GERONIMO_HOME ] GERONIMO_HOME=`cygpath --unix $GERONIMO_HOME`
[ -n $GERONIMO_SERVER ] GERONIMO_SERVER=`cygpath --unix
$GERONIMO_SERVER`
fi
{noformat}
To...
{noformat:borderStyle=solid}
# For Cygwin, ensure paths are in UNIX format before anything is touched
if $cygwin; then
[ -n $JAVA_HOME ] JAVA_HOME=`cygpath --unix $JAVA_HOME`
[ -n $JRE_HOME ] JRE_HOME=`cygpath --unix $JRE_HOME`
[ -n $JDB_SRCPATH ] JDB_SRCPATH=`cygpath --unix $JDB_SRCPATH`
[ -n $GERONIMO_HOME ] GERONIMO_HOME=`cygpath --unix $GERONIMO_HOME`
[ -n $GERONIMO_SERVER ] GERONIMO_SERVER=`cygpath --unix
$GERONIMO_SERVER`
[ -n $GERONIMO_TMPDIR ] GERONIMO_TMPDIR=`cygpath --unix
$GERONIMO_TMPDIR`
fi
{noformat}
was (Author: rglaue):
Since were now setting GERONIMO_TMPDIR in setjavaenv.sh, we also need to
make sure that is checked in the # For Cygwin, ensure paths are in UNIX format
before anything is touched section - in the scripts geronimo, client and
deploy. Batch files are okay since they do not account for Cygwin.
Otherwise, all of my testing is successful with the new changes you committed.
Change...
{noformat:borderStyle=solid}
# For Cygwin, ensure paths are in UNIX format before anything is touched
if $cygwin; then
[ -n $JAVA_HOME ] JAVA_HOME=`cygpath --unix $JAVA_HOME`
[ -n $JRE_HOME ] JRE_HOME=`cygpath --unix $JRE_HOME`
[ -n $JDB_SRCPATH ] JDB_SRCPATH=`cygpath --unix $JDB_SRCPATH`
[ -n $GERONIMO_HOME ] GERONIMO_HOME=`cygpath --unix $GERONIMO_HOME`
[ -n $GERONIMO_SERVER ] GERONIMO_SERVER=`cygpath --unix
$GERONIMO_SERVER`
fi
{noformat}
To...
{noformat:borderStyle=solid}
# For Cygwin, ensure paths are in UNIX format before anything is touched
if $cygwin; then
[ -n $JAVA_HOME ] JAVA_HOME=`cygpath --unix $JAVA_HOME`
[ -n $JRE_HOME ] JRE_HOME=`cygpath --unix $JRE_HOME`
[ -n $JDB_SRCPATH ] JDB_SRCPATH=`cygpath --unix $JDB_SRCPATH`
[ -n $GERONIMO_HOME ] GERONIMO_HOME=`cygpath --unix $GERONIMO_HOME`
[ -n $GERONIMO_SERVER ] GERONIMO_SERVER=`cygpath --unix
$GERONIMO_SERVER`
[ -n $GERONIMO_TMPDIR ] GERONIMO_TMPDIR=`cygpath --unix
$GERONIMO_TMPDIR`
fi
{noformat}
Defining and Using org.apache.geronimo.server.dir versus
org.apache.geronimo.home.dir in shell scripts
--
Key: GERONIMO-6275
URL: https://issues.apache.org/jira/browse/GERONIMO-6275
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6275-B-comments.patch,
geronimo-6275-procrun_service.patch, geronimo-6275.patch
Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987,
GERONIMO-4229
It would be easier to support multiple server instances of Geronimo if there
is one shell variable that is used to reference the path on disk to the
instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME
installation path. This issue tracks the discussion and modification of such
a change.
GERONIMO_SERVER defines:
- GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified
- GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if
GERONIMO_SERVER is a relative path
- GERONIMO_SERVER defines org.apache.geronimo.server.dir
In the java code there are the following properties:
# org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable
# org.apache.geronimo.server.dir - proposed to be equivelant to
GERONIMO_SERVER
The words BASE versus HOME appear a few times in the source
[jira] [Updated] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[ https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell E Glaue updated GERONIMO-6275: -- Attachment: geronimo-6275-B-comments-cygwin-procrun.patch geronimo-6275-B-comments-cygwin-procrun.patch This patch includes: - changes for the comments from patch geronimo-6275-B-comments.patch (Thus geronimo-6275-B-comments-cygwin-procrun.patch supersedes geronimo-6275-B-comments.patch). - changes to filter GERONIMO_TMPDIR through the Cygwin UNIX format section, as specified in a previous comment. - changes to the procrun service_pr.bat to (1) prepend GERONIMO_SERVER in the log file geronimo.out (I missed that one), and (2) to print the GERONIMO_SERVER path when Geronimo is printing GERONIMO_INV_INFO Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts -- Key: GERONIMO-6275 URL: https://issues.apache.org/jira/browse/GERONIMO-6275 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Assignee: Russell E Glaue Priority: Minor Labels: geronimo Attachments: geronimo-6275-B-comments-cygwin-procrun.patch, geronimo-6275-B-comments.patch, geronimo-6275-procrun_service.patch, geronimo-6275.patch Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987, GERONIMO-4229 It would be easier to support multiple server instances of Geronimo if there is one shell variable that is used to reference the path on disk to the instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME installation path. This issue tracks the discussion and modification of such a change. GERONIMO_SERVER defines: - GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified - GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if GERONIMO_SERVER is a relative path - GERONIMO_SERVER defines org.apache.geronimo.server.dir In the java code there are the following properties: # org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable # org.apache.geronimo.server.dir - proposed to be equivelant to GERONIMO_SERVER The words BASE versus HOME appear a few times in the source. Once example is karaf.home and karaf.base properties. According to the code usage, it is aparant that these terms are assumed to mean these things: # HOME - path location on disk of read-only binaries and configuration # BASE - path location on disk of read-write configuration and data storage The term BASE is intended to point at a Geronimo Server Instance Base path. However, this has not been clearly defined, and has appeared to cause some misusage. Thus this and other issues lead to the removal of GERONIMO_BASE shell variable and org.apache.geronimo.base.dir java property in GERONIMO-4229 . Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir java property must be defined in the GERONIMO_OPTS variable. However, this prevents the Shell scripts from being able to know and use the path location to the Geronimo Server Instance. In particular, there are a few issues affected by a variable like this not being available. # Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts as GERONIMO_HOME/var/tmp. In turn, the java property java.io.tmpdir is set to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp). Shouldn't GERONIMO_TMPDIR instead be set to a value provided by GERONIMO_SERVER/var/tmp ? -- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools -- This can be argued to whether or not all Geronimo Server Instance should share a common temp directory. # Reported in GERONIMO-6174 - The java properties karaf.home and karaf.base are both being set to GERONIMO_HOME. When instead karaf.base should be set to a value held by GERONIMO_SERVER. -- affected scripts: client, geronimo, internalLauncher -- see resulting errors and reasoning in GERONIMO-6174 # Not Reported - The java property java.util.logging.config.file is being set to GERONIMO_HOME/etc/java.util.logging.properties . It is intended to be an empty configuration file. This only causes a problem when using instances if GERONIMO_HOME/etc does not exist (it would not exist if GERONIMO_SERVER/etc is intended to be used). -- affected scripts: client, geronimo, internalLauncher # Not Reported - Logging startup output to GERONIMO_HOME/var/log/geronimo.out - Obviously if multiple instances are being
[jira] [Updated] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue updated GERONIMO-6281:
--
Attachment: geronimo-6281-activemq.patch
geronimo-6281-activemq.patch
Modifies:
plugins/activemq/activemq-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/server/JMSBrokerPortlet.java
This patch adds a finalized variable (pathToVarActiveMQ) that defines the full
path to GERONIMO_SERVER/var/activemq/. This variable is then used in each
place the var/activemq/ working directory needs to be provided.
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var/monitoring/snapshot-config.xml (Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for
$PWD/var/monitoring
-- Solution:
--- SnapshotConfigXMLBuilder should instead be using a full path to
var/monitoring, i.e. org.apache.geronimo.server.dir/var/monitoring
-- Affected code:
---
trunk/plugins/monitoring/agent-ejb/src/main/java/org/apache/geronimo/monitoring/ejb/snapshot/SnapshotProcessor.java
---
trunk/plugins/monitoring/agent-jar/src
[jira] [Updated] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue updated GERONIMO-6281:
--
Attachment: geronimo-6281-snapshot.patch
geronimo-6281-snapshot.patch
Modifies:
plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfigXMLBuilder.java
plugins/monitoring/agent-ejb/src/main/java/org/apache/geronimo/monitoring/ejb/snapshot/SnapshotProcessor.java
This patch changes the construction of
org.apache.geronimo.home.dir/var/monitoring/ to
org.apache.geronimo.server.dir/var/monitoring/
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq.patch,
geronimo-6281-snapshot.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var/monitoring/snapshot-config.xml (Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for
$PWD/var/monitoring
-- Solution:
--- SnapshotConfigXMLBuilder should instead be using a full path to
var/monitoring, i.e. org.apache.geronimo.server.dir/var/monitoring
-- Affected code:
---
trunk/plugins/monitoring/agent-ejb/src/main/java/org/apache/geronimo/monitoring/ejb/snapshot
[jira] [Updated] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue updated GERONIMO-6281:
--
Attachment: geronimo-6281-karaf.patch
geronimo-6281-karaf.patch
Modifies:
framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
This patch changes karaf.home with karaf.base for defining the path to (1)
etc/shell.init.script, and (2) etc/equinox-debug.properties
I initially misunderstood that karaf.base being set to geronimoBase is
actually the same as being set to org.apache.geronimo.server.dir. After
reading through the procedure in
framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
I see this is all being set correctly.
After this change, my initial testing shows this fixes the reported issue with
Karaf.
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq.patch, geronimo-6281-karaf.patch,
geronimo-6281-snapshot.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var/monitoring/snapshot-config.xml (Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for
$PWD
[jira] [Updated] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue updated GERONIMO-6281:
--
Attachment: geronimo-6281-trunk-karaf.patch
geronimo-6281-trunk-karaf.patch
Modifies:
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
This changes use of karaf.home to karaf.base in configuration files located
only in trunk and are not found in branches/3.0-beta
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq.patch, geronimo-6281-karaf.patch,
geronimo-6281-snapshot.patch, geronimo-6281-trunk-karaf.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var/monitoring/snapshot-config.xml (Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for
$PWD/var/monitoring
-- Solution:
--- SnapshotConfigXMLBuilder should instead be using a full path to
var/monitoring, i.e. org.apache.geronimo.server.dir/var/monitoring
-- Affected code:
---
trunk/plugins/monitoring/agent-ejb/src/main/java/org/apache/geronimo
[jira] [Commented] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212096#comment-13212096
]
Russell E Glaue commented on GERONIMO-6281:
---
The remaining files reported with the Karaf issue can actually be combined into
their own issues, as follows:
# Issue: Server/Client start
-- Affected Code from branches/3.0-beta:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
# Other Issue: Karaf Repository is the same as GERONIMO_HOME/repository - both
should be changed at the same time. We'll open another jira for this
-- Additional Affected Code from trunk/
---
framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq.patch, geronimo-6281-karaf.patch,
geronimo-6281-snapshot.patch, geronimo-6281-trunk-karaf.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc
[jira] [Assigned] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue reassigned GERONIMO-6281:
-
Assignee: Russell E Glaue
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6281-activemq.patch, geronimo-6281-karaf.patch,
geronimo-6281-snapshot.patch, geronimo-6281-trunk-karaf.patch
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var/monitoring/snapshot-config.xml (Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for
$PWD/var/monitoring
-- Solution:
--- SnapshotConfigXMLBuilder should instead be using a full path to
var/monitoring, i.e. org.apache.geronimo.server.dir/var/monitoring
-- Affected code:
---
trunk/plugins/monitoring/agent-ejb/src/main/java/org/apache/geronimo/monitoring/ejb/snapshot/SnapshotProcessor.java
---
trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfigXMLBuilder.java
# ActiveMQ var/activemq/ directory and Lock File
-- WARN [AMQPersistenceAdapter] Waiting to Lock the Store var/activemq
-- Reason:
--- This is because the ActiveMQ will create and use
[jira] [Updated] (GERONIMO-6175) Environment variable org.apache.geronimo.repository.boot.path not used, Repository path does not observe named instances
[
https://issues.apache.org/jira/browse/GERONIMO-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue updated GERONIMO-6175:
--
Issue Type: Sub-task (was: Bug)
Parent: GERONIMO-6270
Environment variable org.apache.geronimo.repository.boot.path not used,
Repository path does not observe named instances
Key: GERONIMO-6175
URL: https://issues.apache.org/jira/browse/GERONIMO-6175
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 3.0, 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
I only list this issue as minor, as the issue does not prevent running
Geronimo, or more than one copy of Geronimo on a single server. However, this
issue does prevent the proper utilization of multiple named server instances.
Two issues:
# On startup, Geronimo does not use the repository relative to the named
server instance directory.
# We are unable to set the repository with the property
org.apache.geronimo.repository.boot.path to be relative to the named server
instance directory.
From what I could decipher, these are the (or some) of the primary classes
defining the repository
-
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
-
plugins/jaxws/geronimo-jaxws-sun-tools/src/main/java/org/apache/geronimo/jaxws/sun/tools/JAXWSToolsCLI.java
-
plugins/cxf/geronimo-cxf-tools/src/main/java/org/apache/geronimo/cxf/tools/JAXWSToolsCLI.java
And the property org.apache.geronimo.repository.boot.path has a prepended
X in each of the three files.
This tells me it was specifically disabled, and probably for some big issue.
{noformat:borderStyle=solid}
#
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
...
Collection repositories = null;
ArtifactResolver artifactResolver = null;
if (enableBootRepo) {
String repository =
System.getProperty(Xorg.apache.geronimo.repository.boot.path, repository);
Maven2Repository bootRepository = new Maven2Repository(new
File(getBootDirectory(), repository));
repositories = Collections.singleton(bootRepository);
artifactResolver = new DefaultArtifactResolver(new
DefaultArtifactManager(), bootRepository);
} else {
// a bootstrap configuration can not have any dependencies
List dependencies =
configurationData.getEnvironment().getDependencies();
if (!dependencies.isEmpty()) {
configurationData.getEnvironment().setDependencies(Collections.EMPTY_SET);
}
}
...
{noformat}
To produce this issue, follow these steps:
# Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
# Create a Geronimo named instance directory as /opt/geronimo3/gserv1
# Move the directories var, etc, and repository into /opt/geronimo3/gserv1
# If patch GERONIMO-6275 in applied, start with this:
-- env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=/opt/geronimo3/gserv1
/opt/geronimo3/bin/geronimo run
# Or. without the patch, Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issues in GERONIMO-6174
export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
# Attempt to specify the correct root path to the repository for this
# named server instance
GERONIMO_OPTS=${GERONIMO_OPTS}
-Dorg.apache.geronimo.repository.boot.path=${GHOME}/${GVIRT}/repository
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat}
When starting the Geronimo named server instance with the above start script
the following error is experienced:
{noformat:borderStyle=solid}
[user@linux gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
__ _
/ /___ _ (_) ___
/ / __ / _ \/ ___/ __ \/ __ \/ // __ `__ \/ __ \
/ /_/ // __/ / / /_/ / / / / // / / / / / /_/ /
\/ \___/_/ \/_/ /_/_//_/ /_/ /_/\/
Apache
[jira] [Updated] (GERONIMO-6175) Environment variable org.apache.geronimo.repository.boot.path not used, Repository path does not observe named instances
[
https://issues.apache.org/jira/browse/GERONIMO-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue updated GERONIMO-6175:
--
Component/s: (was: startup/shutdown)
Description:
I only list this issue as minor, as the issue does not prevent running
Geronimo, or more than one copy of Geronimo on a single server. However, this
issue does prevent the proper utilization of multiple named server instances.
Two issues:
# On startup, Geronimo does not use the repository relative to the named server
instance directory.
# We are unable to set the repository with the property
org.apache.geronimo.repository.boot.path to be relative to the named server
instance directory.
From what I could decipher, these are the (or some) of the primary classes
defining the repository
-
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
-
plugins/jaxws/geronimo-jaxws-sun-tools/src/main/java/org/apache/geronimo/jaxws/sun/tools/JAXWSToolsCLI.java
-
plugins/cxf/geronimo-cxf-tools/src/main/java/org/apache/geronimo/cxf/tools/JAXWSToolsCLI.java
And the property org.apache.geronimo.repository.boot.path has a prepended X
in each of the three files.
This tells me it was specifically disabled, and probably for some big issue.
{noformat:borderStyle=solid}
#
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
...
Collection repositories = null;
ArtifactResolver artifactResolver = null;
if (enableBootRepo) {
String repository =
System.getProperty(Xorg.apache.geronimo.repository.boot.path, repository);
Maven2Repository bootRepository = new Maven2Repository(new
File(getBootDirectory(), repository));
repositories = Collections.singleton(bootRepository);
artifactResolver = new DefaultArtifactResolver(new
DefaultArtifactManager(), bootRepository);
} else {
// a bootstrap configuration can not have any dependencies
List dependencies =
configurationData.getEnvironment().getDependencies();
if (!dependencies.isEmpty()) {
configurationData.getEnvironment().setDependencies(Collections.EMPTY_SET);
}
}
...
{noformat}
To produce this issue, follow these steps:
# Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
# Create a Geronimo named instance directory as /opt/geronimo3/gserv1
# Move the directories var, etc, and repository into /opt/geronimo3/gserv1
# If patch GERONIMO-6275 in applied, start with this:
-- env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=/opt/geronimo3/gserv1
/opt/geronimo3/bin/geronimo run
# Or. without the patch, Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issues in GERONIMO-6174
export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
# Attempt to specify the correct root path to the repository for this
# named server instance
GERONIMO_OPTS=${GERONIMO_OPTS}
-Dorg.apache.geronimo.repository.boot.path=${GHOME}/${GVIRT}/repository
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat}
When starting the Geronimo named server instance with the above start script
the following error is experienced:
{noformat:borderStyle=solid}
[user@linux gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
__ _
/ /___ _ (_) ___
/ / __ / _ \/ ___/ __ \/ __ \/ // __ `__ \/ __ \
/ /_/ // __/ / / /_/ / / / / // / / / / / /_/ /
\/ \___/_/ \/_/ /_/_//_/ /_/ /_/\/
Apache Geronimo (3.0-SNAPSHOT)
Hit 'tab' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo.
geronimo 2011-09-26 15:01:25,752 ERROR [GBeanInstanceState] Error while
starting; GBean is now in the FAILED state:
abstractName=org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car,j2eeType=Repository,name=Repository
java.lang.IllegalStateException: Maven2Repository must have a root that's a
valid readable directory (not /opt/geronimo3/repository)
at
org.apache.geronimo.kernel.repository.AbstractRepository.init(AbstractRepository.java:51
[jira] [Commented] (GERONIMO-6175) Environment variable org.apache.geronimo.repository.boot.path not used, Repository path does not observe named instances
[
https://issues.apache.org/jira/browse/GERONIMO-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212184#comment-13212184
]
Russell E Glaue commented on GERONIMO-6175:
---
Converted to sub-task of GERONIMO-6270 - we'll use this jira to track
discussion and any modifications to the repository location in regards to
supporting multiple instances.
The first question is Why is the org.apache.geronimo.repository.boot.path
property prepended with an X in the three files it is referenced?
(Xorg.apache.geronimo.repository.boot.path)
Environment variable org.apache.geronimo.repository.boot.path not used,
Repository path does not observe named instances
Key: GERONIMO-6175
URL: https://issues.apache.org/jira/browse/GERONIMO-6175
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 3.0, 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
I only list this issue as minor, as the issue does not prevent running
Geronimo, or more than one copy of Geronimo on a single server. However, this
issue does prevent the proper utilization of multiple named server instances.
Two issues:
# On startup, Geronimo does not use the repository relative to the named
server instance directory.
# We are unable to set the repository with the property
org.apache.geronimo.repository.boot.path to be relative to the named server
instance directory.
From what I could decipher, these are the (or some) of the primary classes
defining the repository
-
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
-
plugins/jaxws/geronimo-jaxws-sun-tools/src/main/java/org/apache/geronimo/jaxws/sun/tools/JAXWSToolsCLI.java
-
plugins/cxf/geronimo-cxf-tools/src/main/java/org/apache/geronimo/cxf/tools/JAXWSToolsCLI.java
And the property org.apache.geronimo.repository.boot.path has a prepended
X in each of the three files.
This tells me it was specifically disabled, and probably for some big issue.
{noformat:borderStyle=solid}
#
framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
...
Collection repositories = null;
ArtifactResolver artifactResolver = null;
if (enableBootRepo) {
String repository =
System.getProperty(Xorg.apache.geronimo.repository.boot.path, repository);
Maven2Repository bootRepository = new Maven2Repository(new
File(getBootDirectory(), repository));
repositories = Collections.singleton(bootRepository);
artifactResolver = new DefaultArtifactResolver(new
DefaultArtifactManager(), bootRepository);
} else {
// a bootstrap configuration can not have any dependencies
List dependencies =
configurationData.getEnvironment().getDependencies();
if (!dependencies.isEmpty()) {
configurationData.getEnvironment().setDependencies(Collections.EMPTY_SET);
}
}
...
{noformat}
To produce this issue, follow these steps:
# Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
# Create a Geronimo named instance directory as /opt/geronimo3/gserv1
# Move the directories var, etc, and repository into /opt/geronimo3/gserv1
# If patch GERONIMO-6275 in applied, start with this:
-- env JAVA_HOME=/usr/jdk1.6.0 GERONIMO_SERVER=/opt/geronimo3/gserv1
/opt/geronimo3/bin/geronimo run
# Or. without the patch, Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issues in GERONIMO-6174
export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
# Attempt to specify the correct root path to the repository for this
# named server instance
GERONIMO_OPTS=${GERONIMO_OPTS}
-Dorg.apache.geronimo.repository.boot.path=${GHOME}/${GVIRT}/repository
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat}
When starting the Geronimo named server instance with the above start script
the following error is experienced:
{noformat:borderStyle=solid}
[user@linux gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0
[jira] [Commented] (GERONIMO-6174) Environment variables being set in bin/geronimo does not account for named server instances
[
https://issues.apache.org/jira/browse/GERONIMO-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212187#comment-13212187
]
Russell E Glaue commented on GERONIMO-6174:
---
The remaining issues in this jira, in regards to using the related java
properties properly, are resolved by GERONIMO-6281 with the provided patches.
Environment variables being set in bin/geronimo does not account for named
server instances
---
Key: GERONIMO-6174
URL: https://issues.apache.org/jira/browse/GERONIMO-6174
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 3.0
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Priority: Trivial
Labels: geronimo
I have been able to workaround these two issues by setting properties.
Questions:
1A) But should these properties be dynamically set relative to the named
instance directory instead of GERONIMO_HOME?
1B) Or do we require the user to explicitly set these in the environment in
order to start a named instance?
2) Does setting karaf.home in GERONIMO_OPTS as relative to the named instance
directory instead of GERONIMO_HOME potentially cause any other issues?
To produce these issues follow these steps:
1. Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
2. Create a Geronimo named instance directory as /opt/geronimo3/gserv1
3. Move the directories var, etc, and repository into /opt/geronimo3/gserv1
4. Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issue #1
#export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
#
# Uncomment for the Workaround of issue #2
#GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat}
1) GERONIMO_TMPDIR
On startup, the `bin/geronimo` startup script sets GERONIMO_TMPDIR explicitly
as
$GERONIMO_HOME/var/temp , but the actual temp directory is really
{org.apache.geronimo.server.dir}/var/temp (or
$GERONIMO_HOME/{org.apache.geronimo.server.name}/var/temp)
It does not account for the cases where an instance is being started.
{noformat:borderStyle=solid}
[user@system gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
Error launching framework: java.lang.IllegalArgumentException: Invalid
temporary directory. The '/opt/geronimo3/var/temp' path does not exist.
{noformat}
The workaround is to specifically specify GERONIMO_TMPDIR in your environment
before starting the instance.
2) karaf.home
On startup, the `bin/geronimo` script sets karaf.home explicitly as
$GERONIMO_HOME . Karaf expects to use {karaf.home}/etc/shell.init.script each
time a shell session is started (See:
geronimo/server/trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties).
The setting of the karaf.home property in `bin/geronimo` does not account for
the cases where a Geronimo named instance is being started.
{noformat:borderStyle=solid}
[root@rglaue7 gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
__ _
/ /___ _ (_) ___
/ / __ / _ \/ ___/ __ \/ __ \/ // __ `__ \/ __ \
/ /_/ // __/ / / /_/ / / / / // / / / / / /_/ /
\/ \___/_/ \/_/ /_/_//_/ /_/ /_/\/
Apache Geronimo (3.0-SNAPSHOT)
Hit 'tab' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo.
Error in initialization script: /opt/geronimo3/etc/shell.init.script (No such
file or directory)
... snip ...
{noformat}
The workaround is to set karaf.home in GERONIMO_OPTS before starting the
instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[
https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211683#comment-13211683
]
Russell E Glaue commented on GERONIMO-6275:
---
The # Resolve the full path to GERONIMO_SERVER section is copied from the
$PRG resolution logic just a dozen lines prior in the section titled # resolve
links - $0 may be a softlink.
I have concern that putting path resolution code in a file identified/named for
java environment purposes (setjavaenv) could lead to confusion. Also, we would
still be duplicating the resolution code since it is identical to the
existing duplicated code that resolves GERONIMO_HOME in each of those same
shell files (because I just copied it).
I hesitated in modifying existing code lines, so I went for the copy-and-paste.
The ideal resolution is probably to move the $PRG/$GERONIMO_HOME resolution
code into a function.
{noformat:borderStyle=solid}
RESOLVE_PATH= # Global return variable for resolvePath()
resolvePath () {
LPRG=$1
[ ! -d $LPRG ] return 1
while [ -h $LPRG ]; do
ls=`ls -ld $LPRG`
link=`expr $ls : '.*- \(.*\)$'`
if expr $link : '/.*' /dev/null; then
LPRG=$link
else
LPRG=`dirname $LPRG`/$link
fi
done
RESOLVE_PATH=$LPRG
return 0
}
# resolve links - $0 may be a softlink
resolvePath $0 PRG=$RESOLVE_PATH
# Get standard environment variables
PRGDIR=`dirname $PRG`
# Only set GERONIMO_HOME if not already set
[ -z $GERONIMO_HOME ] GERONIMO_HOME=`cd $PRGDIR/.. ; pwd`
# Set GERONIMO_SERVER if not already set, otherwise resolve the full path
if [ -z $GERONIMO_SERVER ] ; then
GERONIMO_SERVER=$GERONIMO_HOME
else
ATTEMPTED_SERVER=$GERONIMO_SERVER
resolvePath `cd $GERONIMO_HOME; cd $GERONIMO_SERVER 2/dev/null pwd`
GERONIMO_SERVER=$RESOLVE_PATH
[ -z $GERONIMO_SERVER ] echo ERROR: GERONIMO_SERVER: $ATTEMPTED_SERVER
not found! exit 1
fi
{noformat}
Unfortunately, bash functions cannot return strings, only an exit/return status
in $?. So we would have to use a global variable. Anyone have a more efficient
idea for doing this?
Defining and Using org.apache.geronimo.server.dir versus
org.apache.geronimo.home.dir in shell scripts
--
Key: GERONIMO-6275
URL: https://issues.apache.org/jira/browse/GERONIMO-6275
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6275-procrun_service.patch, geronimo-6275.patch
Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987,
GERONIMO-4229
It would be easier to support multiple server instances of Geronimo if there
is one shell variable that is used to reference the path on disk to the
instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME
installation path. This issue tracks the discussion and modification of such
a change.
GERONIMO_SERVER defines:
- GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified
- GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if
GERONIMO_SERVER is a relative path
- GERONIMO_SERVER defines org.apache.geronimo.server.dir
In the java code there are the following properties:
# org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable
# org.apache.geronimo.server.dir - proposed to be equivelant to
GERONIMO_SERVER
The words BASE versus HOME appear a few times in the source. Once example
is karaf.home and karaf.base properties. According to the code usage, it
is aparant that these terms are assumed to mean these things:
# HOME - path location on disk of read-only binaries and configuration
# BASE - path location on disk of read-write configuration and data storage
The term BASE is intended to point at a Geronimo Server Instance Base path.
However, this has not been clearly defined, and has appeared to cause some
misusage. Thus this and other issues lead to the removal of GERONIMO_BASE
shell variable and org.apache.geronimo.base.dir java property in
GERONIMO-4229 .
Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir
java property must be defined in the GERONIMO_OPTS variable. However, this
prevents the Shell scripts from being able to know and use the path location
to the Geronimo Server Instance.
In particular, there are a few issues affected by a variable like this not
being available.
# Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set
[jira] [Issue Comment Edited] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[
https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211683#comment-13211683
]
Russell E Glaue edited comment on GERONIMO-6275 at 2/20/12 5:59 AM:
The # Resolve the full path to GERONIMO_SERVER section is copied from the
$PRG resolution logic just a dozen lines prior in the section titled # resolve
links - $0 may be a softlink.
I have concern that putting path resolution code in a file identified/named for
java environment purposes (setjavaenv) could lead to confusion. Also, we would
still be duplicating the resolution code since it is identical to the
existing duplicated code that resolves GERONIMO_HOME in each of those same
shell files (because I just copied it).
I hesitated in modifying existing code lines, so I went for the copy-and-paste.
The ideal resolution is probably to move the $PRG/$GERONIMO_HOME resolution
code into a function.
{noformat:borderStyle=solid}
RESOLVE_PATH= # Global return variable for resolvePath()
resolvePath () {
RESOLVE_PATH=
LPRG=$1
[ ! -d $LPRG ] return 1
while [ -h $LPRG ]; do
ls=`ls -ld $LPRG`
link=`expr $ls : '.*- \(.*\)$'`
if expr $link : '/.*' /dev/null; then
LPRG=$link
else
LPRG=`dirname $LPRG`/$link
fi
done
RESOLVE_PATH=$LPRG
return 0
}
# resolve links - $0 may be a softlink
resolvePath $0 PRG=$RESOLVE_PATH
# Get standard environment variables
PRGDIR=`dirname $PRG`
# Only set GERONIMO_HOME if not already set
[ -z $GERONIMO_HOME ] GERONIMO_HOME=`cd $PRGDIR/.. ; pwd`
# Set GERONIMO_SERVER if not already set, otherwise resolve the full path
if [ -z $GERONIMO_SERVER ] ; then
GERONIMO_SERVER=$GERONIMO_HOME
else
ATTEMPTED_SERVER=$GERONIMO_SERVER
resolvePath `cd $GERONIMO_HOME; cd $GERONIMO_SERVER 2/dev/null pwd`
GERONIMO_SERVER=$RESOLVE_PATH
[ -z $GERONIMO_SERVER ] echo ERROR: GERONIMO_SERVER: $ATTEMPTED_SERVER
not found! exit 1
fi
{noformat}
Unfortunately, bash functions cannot return strings, only an exit/return status
in $?. So we would have to use a global variable. Anyone have a more efficient
idea for doing this?
was (Author: rglaue):
The # Resolve the full path to GERONIMO_SERVER section is copied from the
$PRG resolution logic just a dozen lines prior in the section titled # resolve
links - $0 may be a softlink.
I have concern that putting path resolution code in a file identified/named for
java environment purposes (setjavaenv) could lead to confusion. Also, we would
still be duplicating the resolution code since it is identical to the
existing duplicated code that resolves GERONIMO_HOME in each of those same
shell files (because I just copied it).
I hesitated in modifying existing code lines, so I went for the copy-and-paste.
The ideal resolution is probably to move the $PRG/$GERONIMO_HOME resolution
code into a function.
{noformat:borderStyle=solid}
RESOLVE_PATH= # Global return variable for resolvePath()
resolvePath () {
LPRG=$1
[ ! -d $LPRG ] return 1
while [ -h $LPRG ]; do
ls=`ls -ld $LPRG`
link=`expr $ls : '.*- \(.*\)$'`
if expr $link : '/.*' /dev/null; then
LPRG=$link
else
LPRG=`dirname $LPRG`/$link
fi
done
RESOLVE_PATH=$LPRG
return 0
}
# resolve links - $0 may be a softlink
resolvePath $0 PRG=$RESOLVE_PATH
# Get standard environment variables
PRGDIR=`dirname $PRG`
# Only set GERONIMO_HOME if not already set
[ -z $GERONIMO_HOME ] GERONIMO_HOME=`cd $PRGDIR/.. ; pwd`
# Set GERONIMO_SERVER if not already set, otherwise resolve the full path
if [ -z $GERONIMO_SERVER ] ; then
GERONIMO_SERVER=$GERONIMO_HOME
else
ATTEMPTED_SERVER=$GERONIMO_SERVER
resolvePath `cd $GERONIMO_HOME; cd $GERONIMO_SERVER 2/dev/null pwd`
GERONIMO_SERVER=$RESOLVE_PATH
[ -z $GERONIMO_SERVER ] echo ERROR: GERONIMO_SERVER: $ATTEMPTED_SERVER
not found! exit 1
fi
{noformat}
Unfortunately, bash functions cannot return strings, only an exit/return status
in $?. So we would have to use a global variable. Anyone have a more efficient
idea for doing this?
Defining and Using org.apache.geronimo.server.dir versus
org.apache.geronimo.home.dir in shell scripts
--
Key: GERONIMO-6275
URL: https://issues.apache.org/jira/browse/GERONIMO-6275
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6275
[jira] [Issue Comment Edited] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[
https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211683#comment-13211683
]
Russell E Glaue edited comment on GERONIMO-6275 at 2/20/12 6:00 AM:
The # Resolve the full path to GERONIMO_SERVER section is copied from the
$PRG resolution logic just a dozen lines prior in the section titled # resolve
links - $0 may be a softlink.
I have concern that putting path resolution code in a file identified/named for
java environment purposes (setjavaenv) could lead to confusion. Also, we would
still be duplicating the resolution code since it is identical to the
existing duplicated code that resolves GERONIMO_HOME in each of those same
shell files (because I just copied it).
I hesitated in modifying existing code lines, so I went for the copy-and-paste.
The ideal resolution is probably to move the $PRG/$GERONIMO_HOME resolution
code into a function.
{noformat:borderStyle=solid}
RESOLVE_PATH= # Global return variable for resolvePath()
resolvePath () {
RESOLVE_PATH=
LPRG=$1
[ ! -d $LPRG ] return 1
while [ -h $LPRG ]; do
ls=`ls -ld $LPRG`
link=`expr $ls : '.*- \(.*\)$'`
if expr $link : '/.*' /dev/null; then
LPRG=$link
else
LPRG=`dirname $LPRG`/$link
fi
done
RESOLVE_PATH=$LPRG
return 0
}
# resolve links - $0 may be a softlink
resolvePath $0 PRG=$RESOLVE_PATH
# Get standard environment variables
PRGDIR=`dirname $PRG`
# Only set GERONIMO_HOME if not already set
[ -z $GERONIMO_HOME ] GERONIMO_HOME=`cd $PRGDIR/.. ; pwd`
# Set GERONIMO_SERVER if not already set, otherwise resolve the full path
if [ -z $GERONIMO_SERVER ] ; then
GERONIMO_SERVER=$GERONIMO_HOME
else
ATTEMPTED_SERVER=$GERONIMO_SERVER
resolvePath `cd $GERONIMO_HOME; cd $GERONIMO_SERVER 2/dev/null pwd`
GERONIMO_SERVER=$RESOLVE_PATH
[ -z $GERONIMO_SERVER ] echo ERROR: GERONIMO_SERVER: $ATTEMPTED_SERVER
not found! exit 1
fi
{noformat}
Unfortunately, bash functions cannot return strings, only an exit/return status
in $?. So we would have to use a global variable. Anyone have a more efficient
idea for doing this?
was (Author: rglaue):
The # Resolve the full path to GERONIMO_SERVER section is copied from the
$PRG resolution logic just a dozen lines prior in the section titled # resolve
links - $0 may be a softlink.
I have concern that putting path resolution code in a file identified/named for
java environment purposes (setjavaenv) could lead to confusion. Also, we would
still be duplicating the resolution code since it is identical to the
existing duplicated code that resolves GERONIMO_HOME in each of those same
shell files (because I just copied it).
I hesitated in modifying existing code lines, so I went for the copy-and-paste.
The ideal resolution is probably to move the $PRG/$GERONIMO_HOME resolution
code into a function.
{noformat:borderStyle=solid}
RESOLVE_PATH= # Global return variable for resolvePath()
resolvePath () {
RESOLVE_PATH=
LPRG=$1
[ ! -d $LPRG ] return 1
while [ -h $LPRG ]; do
ls=`ls -ld $LPRG`
link=`expr $ls : '.*- \(.*\)$'`
if expr $link : '/.*' /dev/null; then
LPRG=$link
else
LPRG=`dirname $LPRG`/$link
fi
done
RESOLVE_PATH=$LPRG
return 0
}
# resolve links - $0 may be a softlink
resolvePath $0 PRG=$RESOLVE_PATH
# Get standard environment variables
PRGDIR=`dirname $PRG`
# Only set GERONIMO_HOME if not already set
[ -z $GERONIMO_HOME ] GERONIMO_HOME=`cd $PRGDIR/.. ; pwd`
# Set GERONIMO_SERVER if not already set, otherwise resolve the full path
if [ -z $GERONIMO_SERVER ] ; then
GERONIMO_SERVER=$GERONIMO_HOME
else
ATTEMPTED_SERVER=$GERONIMO_SERVER
resolvePath `cd $GERONIMO_HOME; cd $GERONIMO_SERVER 2/dev/null pwd`
GERONIMO_SERVER=$RESOLVE_PATH
[ -z $GERONIMO_SERVER ] echo ERROR: GERONIMO_SERVER: $ATTEMPTED_SERVER
not found! exit 1
fi
{noformat}
Unfortunately, bash functions cannot return strings, only an exit/return status
in $?. So we would have to use a global variable. Anyone have a more efficient
idea for doing this?
Defining and Using org.apache.geronimo.server.dir versus
org.apache.geronimo.home.dir in shell scripts
--
Key: GERONIMO-6275
URL: https://issues.apache.org/jira/browse/GERONIMO-6275
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments
[jira] [Assigned] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[ https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell E Glaue reassigned GERONIMO-6275: - Assignee: Russell E Glaue Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts -- Key: GERONIMO-6275 URL: https://issues.apache.org/jira/browse/GERONIMO-6275 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Assignee: Russell E Glaue Priority: Minor Labels: geronimo Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987, GERONIMO-4229 It would be easier to support multiple server instances of Geronimo if there is one shell variable that is used to reference the path on disk to the instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME installation path. This issue tracks the discussion and modification of such a change. GERONIMO_SERVER defines: - GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified - GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if GERONIMO_SERVER is a relative path - GERONIMO_SERVER defines org.apache.geronimo.server.dir In the java code there are the following properties: # org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable # org.apache.geronimo.server.dir - proposed to be equivelant to GERONIMO_SERVER The words BASE versus HOME appear a few times in the source. Once example is karaf.home and karaf.base properties. According to the code usage, it is aparant that these terms are assumed to mean these things: # HOME - path location on disk of read-only binaries and configuration # BASE - path location on disk of read-write configuration and data storage The term BASE is intended to point at a Geronimo Server Instance Base path. However, this has not been clearly defined, and has appeared to cause some misusage. Thus this and other issues lead to the removal of GERONIMO_BASE shell variable and org.apache.geronimo.base.dir java property in GERONIMO-4229 . Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir java property must be defined in the GERONIMO_OPTS variable. However, this prevents the Shell scripts from being able to know and use the path location to the Geronimo Server Instance. In particular, there are a few issues affected by a variable like this not being available. # Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts as GERONIMO_HOME/var/tmp. In turn, the java property java.io.tmpdir is set to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp). Shouldn't GERONIMO_TMPDIR instead be set to a value provided by GERONIMO_SERVER/var/tmp ? -- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools -- This can be argued to whether or not all Geronimo Server Instance should share a common temp directory. # Reported in GERONIMO-6174 - The java properties karaf.home and karaf.base are both being set to GERONIMO_HOME. When instead karaf.base should be set to a value held by GERONIMO_SERVER. -- affected scripts: client, geronimo, internalLauncher -- see resulting errors and reasoning in GERONIMO-6174 # Not Reported - The java property java.util.logging.config.file is being set to GERONIMO_HOME/etc/java.util.logging.properties . It is intended to be an empty configuration file. This only causes a problem when using instances if GERONIMO_HOME/etc does not exist (it would not exist if GERONIMO_SERVER/etc is intended to be used). -- affected scripts: client, geronimo, internalLauncher # Not Reported - Logging startup output to GERONIMO_HOME/var/log/geronimo.out - Obviously if multiple instances are being started, this should be GERONIMO_SERVER/var/log/geronimo.out . Any error is silent if var/log/geronimo.out does not exist. -- affected scripts: geronimo # Not Reported - The register-service script does a grep and awk on GERONIMO_HOME/var/config/config-substitutions.properties to discover the portOffset . Obviously this will not work for multiple instances -- The register-service script does not take multiple instances into consideration at all -- affected scripts: register-service Solution: - Create a new shell variable GERONIMO_SERVER to hold the path location to the run-time server configuration, and leave GERONIMO_HOME to hold the path location to the Geronimo Installation Path. Arguments: - If GERONIMO_SERVER defaults
[jira] [Updated] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[ https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell E Glaue updated GERONIMO-6275: -- Attachment: geronimo-6275.patch Modifies startup shell scripts to use new variable GERONIMO_SERVER. And use of GERONIMO_HOME is replaced with GERONIMO_SERVER when the path needed is intended to hold the configuration and data for a Geronimo instance. Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts -- Key: GERONIMO-6275 URL: https://issues.apache.org/jira/browse/GERONIMO-6275 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Assignee: Russell E Glaue Priority: Minor Labels: geronimo Attachments: geronimo-6275.patch Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987, GERONIMO-4229 It would be easier to support multiple server instances of Geronimo if there is one shell variable that is used to reference the path on disk to the instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME installation path. This issue tracks the discussion and modification of such a change. GERONIMO_SERVER defines: - GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified - GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if GERONIMO_SERVER is a relative path - GERONIMO_SERVER defines org.apache.geronimo.server.dir In the java code there are the following properties: # org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable # org.apache.geronimo.server.dir - proposed to be equivelant to GERONIMO_SERVER The words BASE versus HOME appear a few times in the source. Once example is karaf.home and karaf.base properties. According to the code usage, it is aparant that these terms are assumed to mean these things: # HOME - path location on disk of read-only binaries and configuration # BASE - path location on disk of read-write configuration and data storage The term BASE is intended to point at a Geronimo Server Instance Base path. However, this has not been clearly defined, and has appeared to cause some misusage. Thus this and other issues lead to the removal of GERONIMO_BASE shell variable and org.apache.geronimo.base.dir java property in GERONIMO-4229 . Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir java property must be defined in the GERONIMO_OPTS variable. However, this prevents the Shell scripts from being able to know and use the path location to the Geronimo Server Instance. In particular, there are a few issues affected by a variable like this not being available. # Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts as GERONIMO_HOME/var/tmp. In turn, the java property java.io.tmpdir is set to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp). Shouldn't GERONIMO_TMPDIR instead be set to a value provided by GERONIMO_SERVER/var/tmp ? -- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools -- This can be argued to whether or not all Geronimo Server Instance should share a common temp directory. # Reported in GERONIMO-6174 - The java properties karaf.home and karaf.base are both being set to GERONIMO_HOME. When instead karaf.base should be set to a value held by GERONIMO_SERVER. -- affected scripts: client, geronimo, internalLauncher -- see resulting errors and reasoning in GERONIMO-6174 # Not Reported - The java property java.util.logging.config.file is being set to GERONIMO_HOME/etc/java.util.logging.properties . It is intended to be an empty configuration file. This only causes a problem when using instances if GERONIMO_HOME/etc does not exist (it would not exist if GERONIMO_SERVER/etc is intended to be used). -- affected scripts: client, geronimo, internalLauncher # Not Reported - Logging startup output to GERONIMO_HOME/var/log/geronimo.out - Obviously if multiple instances are being started, this should be GERONIMO_SERVER/var/log/geronimo.out . Any error is silent if var/log/geronimo.out does not exist. -- affected scripts: geronimo # Not Reported - The register-service script does a grep and awk on GERONIMO_HOME/var/config/config-substitutions.properties to discover the portOffset . Obviously this will not work for multiple instances -- The register-service script does not take multiple instances into consideration at all -- affected scripts
[jira] [Commented] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[
https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210508#comment-13210508
]
Russell E Glaue commented on GERONIMO-6275:
---
The patch geronimo-6275.patch modifies the shell scripts such that the
following commands can now be used to start up a single Geronimo server
instance, or Geronimo without an instance configuration. Run-time output
follows to demonstrate start-up ability after modifications are applied from
the patch.
- Tested with geronimo-tomcat7-javaee6-3.0-SNAPSHOT-20111220
- Windows batch files are also patched, and partially tested for syntax. But
they need full testing on a Windows Geronimo Deployment.
- Geronimo server instance is setup as documented in
https://cwiki.apache.org/confluence/display/GMOxDOC30/Running+multiple+Geronimo+instances
- Note the error message Error in initialization script:
/data/geronimo3/etc/shell.init.script (No such file or directory) is caused
because the Java code for Karaf looks for {karaf.home}/etc/shell.init.script
instead of {karaf.base}/etc/shell.init.script.
Startup Geronimo server instance gserv1
{noformat:borderStyle=solid}
[ger@server /opt/geronimo3/gserv1]# env JAVA_HOME=/usr/jdk1.6.0
GERONIMO_SERVER=gserv1 ../bin/geronimo run
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3/gserv1
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0_25/jre
__ _
/ /___ _ (_) ___
/ / __ / _ \/ ___/ __ \/ __ \/ // __ `__ \/ __ \
/ /_/ // __/ / / /_/ / / / / // / / / / / /_/ /
\/ \___/_/ \/_/ /_/_//_/ /_/ /_/\/
Apache Geronimo (3.0-SNAPSHOT)
Hit 'tab' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo.
Error in initialization script: /data/geronimo3/etc/shell.init.script (No such
file or directory)
geronimo Booting Geronimo Kernel (in Java 1.6.0_25)...
Starting Geronimo Application Server v3.0-SNAPSHOT
[] 100% 47s Startup complete
Listening on Ports:
1150 0.0.0.0 CORBA Naming Service
1199 0.0.0.0 RMI Naming
1627 0.0.0.0 Derby Connector
2101 0.0.0.0 OpenEJB SSL ORB Adapter
4301 0.0.0.0 OpenEJB Daemon
6982 0.0.0.0 OpenEJB ORB Adapter
8109 0.0.0.0 Tomcat Connector AJP TomcatAJPConnector
8180 0.0.0.0 Tomcat Connector HTTP BIO TomcatWebConnector
8543 0.0.0.0 Tomcat Connector HTTPS BIO TomcatWebSSLConnector
10099 0.0.0.0 JMX Remoting Connector
61716 0.0.0.0 ActiveMQ Transport Connector
Started Application Modules:
EAR: org.apache.geronimo.plugins/console-tomcat/3.0-SNAPSHOT/car
JAR: org.apache.geronimo.configs/mejb/3.0-SNAPSHOT/car
RAR: org.apache.geronimo.configs/activemq-ra/3.0-SNAPSHOT/car
RAR: org.apache.geronimo.configs/system-database/3.0-SNAPSHOT/car
RAR: org.apache.geronimo.plugins.monitoring/agent-ds/3.0-SNAPSHOT/car
RAR: org.apache.geronimo.plugins.monitoring/mconsole-ds/3.0-SNAPSHOT/car
RAR: org.apache.geronimo.plugins/uddi-db/3.0-SNAPSHOT/car
WAR: org.apache.geronimo.configs/remote-deploy-tomcat/3.0-SNAPSHOT/car
WAR: org.apache.geronimo.configs/uddi-tomcat/3.0-SNAPSHOT/car
WAR: org.apache.geronimo.configs/welcome-tomcat/3.0-SNAPSHOT/car
WAR: org.apache.geronimo.plugins.monitoring/mconsole-tomcat/3.0-SNAPSHOT/car
WAR: org.apache.geronimo.plugins/activemq-console-tomcat/3.0-SNAPSHOT/car
WAR: org.apache.geronimo.plugins/debugviews-console-tomcat/3.0-SNAPSHOT/car
WAR: org.apache.geronimo.plugins/openejb-console-tomcat/3.0-SNAPSHOT/car
WAR: org.apache.geronimo.plugins/plancreator-console-tomcat/3.0-SNAPSHOT/car
WAR: org.apache.geronimo.plugins/plugin-console-tomcat/3.0-SNAPSHOT/car
WAR: org.apache.geronimo.plugins/sysdb-console-tomcat/3.0-SNAPSHOT/car
Web Applications:
/
/activemq
/console
/console-base
/debug-views
/juddi
/monitoring
/openejb-server
/plan-creator
/plugin
/remote-deploy
/system-database
Geronimo Application Server started
{noformat}
Startup Geronimo server without a configured instance
{noformat:borderStyle=solid}
[ger@server /opt/geronimo3]# env JAVA_HOME=/usr/jdk1.6.0 bin/geronimo run
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_SERVER: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
[jira] [Commented] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[
https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210512#comment-13210512
]
Russell E Glaue commented on GERONIMO-6275:
---
Note that the use of GERONIMO_HOME versus GERONIMO_SERVER is explained in each
shell script in which the variables are used, particularly the meaning of
HOME vs. SERVER.
{noformat:borderStyle=solid}
#
# GERONIMO_HOME (Optional) May point at your Geronimo top-level directory.
# If not specified, it will default to the parent directory
# of the location of this script.
# The HOME directory holds the binary install of Geronimo.
#
# GERONIMO_SERVER (Optional) May point at your Geronimo Server Instance
# top-level directory. If not specified, it will default to
# $GERONIMO_HOME.
# The SERVER directory holds the configuration and data for
# a Geronimo instance.
#
{noformat}
Defining and Using org.apache.geronimo.server.dir versus
org.apache.geronimo.home.dir in shell scripts
--
Key: GERONIMO-6275
URL: https://issues.apache.org/jira/browse/GERONIMO-6275
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Assignee: Russell E Glaue
Priority: Minor
Labels: geronimo
Attachments: geronimo-6275.patch
Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987,
GERONIMO-4229
It would be easier to support multiple server instances of Geronimo if there
is one shell variable that is used to reference the path on disk to the
instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME
installation path. This issue tracks the discussion and modification of such
a change.
GERONIMO_SERVER defines:
- GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified
- GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if
GERONIMO_SERVER is a relative path
- GERONIMO_SERVER defines org.apache.geronimo.server.dir
In the java code there are the following properties:
# org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable
# org.apache.geronimo.server.dir - proposed to be equivelant to
GERONIMO_SERVER
The words BASE versus HOME appear a few times in the source. Once example
is karaf.home and karaf.base properties. According to the code usage, it
is aparant that these terms are assumed to mean these things:
# HOME - path location on disk of read-only binaries and configuration
# BASE - path location on disk of read-write configuration and data storage
The term BASE is intended to point at a Geronimo Server Instance Base path.
However, this has not been clearly defined, and has appeared to cause some
misusage. Thus this and other issues lead to the removal of GERONIMO_BASE
shell variable and org.apache.geronimo.base.dir java property in
GERONIMO-4229 .
Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir
java property must be defined in the GERONIMO_OPTS variable. However, this
prevents the Shell scripts from being able to know and use the path location
to the Geronimo Server Instance.
In particular, there are a few issues affected by a variable like this not
being available.
# Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts
as GERONIMO_HOME/var/tmp. In turn, the java property java.io.tmpdir is set
to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp). Shouldn't GERONIMO_TMPDIR
instead be set to a value provided by GERONIMO_SERVER/var/tmp ?
-- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools
-- This can be argued to whether or not all Geronimo Server Instance should
share a common temp directory.
# Reported in GERONIMO-6174 - The java properties karaf.home and karaf.base
are both being set to GERONIMO_HOME. When instead karaf.base should be set to
a value held by GERONIMO_SERVER.
-- affected scripts: client, geronimo, internalLauncher
-- see resulting errors and reasoning in GERONIMO-6174
# Not Reported - The java property java.util.logging.config.file is being set
to GERONIMO_HOME/etc/java.util.logging.properties . It is intended to be an
empty configuration file. This only causes a problem when using instances if
GERONIMO_HOME/etc does not exist (it would not exist if GERONIMO_SERVER/etc
is intended to be used).
-- affected scripts: client, geronimo, internalLauncher
[jira] [Commented] (GERONIMO-6270) Re-enable multiple instances support in one installation
[
https://issues.apache.org/jira/browse/GERONIMO-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210528#comment-13210528
]
Russell E Glaue commented on GERONIMO-6270:
---
{noformat:borderStyle=solid}
Yi Xiao added a comment - 13/Feb/12 07:33
Hi Russell,
Your comments are reasonable, and need more discussion. I think if we indeed add
the GERONIMO_SERVER, it will also affect GERONIMO-6175, GERONIMO-6174, so we'd
better open an task to track the changes.
{noformat}
Hi Yi Xiao,
I opened the subtask GERONIMO-6275 for this and added a patch.
The patch needs review. The Windows batch files should be tested.
If it is okay, I need someone to commit it for me.
There might be a desire to discuss the GERONIMO_TMPDIR variable. Currently
without this patch, GERONIMO_TMPDIR is constructed as $GERONIMO_HOME/var/temp
in some scripts, and just var/temp in other scripts.
With my patch GERONIMO_TMPDIR is always constructed as
$GERONIMO_SERVER/var/temp
Re-enable multiple instances support in one installation
Key: GERONIMO-6270
URL: https://issues.apache.org/jira/browse/GERONIMO-6270
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 3.0-beta-1
Reporter: Forrest Xia
Assignee: Yi Xiao
We need to investigate how to re-enable the multiple instances support in one
installation.
Refer to
https://issues.apache.org/jira/browse/GERONIMO-6175
https://issues.apache.org/jira/browse/GERONIMO-6174
https://issues.apache.org/jira/browse/GERONIMO-5987
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6174) Environment variables being set in bin/geronimo does not account for named server instances
[
https://issues.apache.org/jira/browse/GERONIMO-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210566#comment-13210566
]
Russell E Glaue commented on GERONIMO-6174:
---
This issue is partially resolved by the introduction of the GERONIMO_SERVER
shell variable with patch in GERONIMO-6275.
With this patch, java properties are being configured on startup in regards to
the existence of a server instance.
Still to be corrected is the proper use of the java properties in the java code.
- karaf.home versus karaf.base
- org.apache.geronimo.home.dir versus org.apache.geronimo.server.dir (and
org.apache.geronimo.server.name)
See GERONIMO-6270 for discussion. It is the parent task of GERONIMO-6275.
Environment variables being set in bin/geronimo does not account for named
server instances
---
Key: GERONIMO-6174
URL: https://issues.apache.org/jira/browse/GERONIMO-6174
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 3.0
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Priority: Trivial
Labels: geronimo
I have been able to workaround these two issues by setting properties.
Questions:
1A) But should these properties be dynamically set relative to the named
instance directory instead of GERONIMO_HOME?
1B) Or do we require the user to explicitly set these in the environment in
order to start a named instance?
2) Does setting karaf.home in GERONIMO_OPTS as relative to the named instance
directory instead of GERONIMO_HOME potentially cause any other issues?
To produce these issues follow these steps:
1. Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
2. Create a Geronimo named instance directory as /opt/geronimo3/gserv1
3. Move the directories var, etc, and repository into /opt/geronimo3/gserv1
4. Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issue #1
#export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
#
# Uncomment for the Workaround of issue #2
#GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat}
1) GERONIMO_TMPDIR
On startup, the `bin/geronimo` startup script sets GERONIMO_TMPDIR explicitly
as
$GERONIMO_HOME/var/temp , but the actual temp directory is really
{org.apache.geronimo.server.dir}/var/temp (or
$GERONIMO_HOME/{org.apache.geronimo.server.name}/var/temp)
It does not account for the cases where an instance is being started.
{noformat:borderStyle=solid}
[user@system gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
Error launching framework: java.lang.IllegalArgumentException: Invalid
temporary directory. The '/opt/geronimo3/var/temp' path does not exist.
{noformat}
The workaround is to specifically specify GERONIMO_TMPDIR in your environment
before starting the instance.
2) karaf.home
On startup, the `bin/geronimo` script sets karaf.home explicitly as
$GERONIMO_HOME . Karaf expects to use {karaf.home}/etc/shell.init.script each
time a shell session is started (See:
geronimo/server/trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties).
The setting of the karaf.home property in `bin/geronimo` does not account for
the cases where a Geronimo named instance is being started.
{noformat:borderStyle=solid}
[root@rglaue7 gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
__ _
/ /___ _ (_) ___
/ / __ / _ \/ ___/ __ \/ __ \/ // __ `__ \/ __ \
/ /_/ // __/ / / /_/ / / / / // / / / / / /_/ /
\/ \___/_/ \/_/ /_/_//_/ /_/ /_/\/
Apache Geronimo (3.0-SNAPSHOT)
Hit 'tab' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo.
Error in initialization script: /opt/geronimo3/etc/shell.init.script (No such
file or directory)
... snip ...
{noformat}
The workaround is to set karaf.home in GERONIMO_OPTS before starting
[jira] [Updated] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[ https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell E Glaue updated GERONIMO-6275: -- Attachment: geronimo-6275-procrun_service.patch geronimo-6275-procrun_service.patch adds GERONIMO_SERVER to plugins/procrun/src/main/resources/bin/service_pr.bat Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts -- Key: GERONIMO-6275 URL: https://issues.apache.org/jira/browse/GERONIMO-6275 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Assignee: Russell E Glaue Priority: Minor Labels: geronimo Attachments: geronimo-6275-procrun_service.patch, geronimo-6275.patch Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987, GERONIMO-4229 It would be easier to support multiple server instances of Geronimo if there is one shell variable that is used to reference the path on disk to the instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME installation path. This issue tracks the discussion and modification of such a change. GERONIMO_SERVER defines: - GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified - GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if GERONIMO_SERVER is a relative path - GERONIMO_SERVER defines org.apache.geronimo.server.dir In the java code there are the following properties: # org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable # org.apache.geronimo.server.dir - proposed to be equivelant to GERONIMO_SERVER The words BASE versus HOME appear a few times in the source. Once example is karaf.home and karaf.base properties. According to the code usage, it is aparant that these terms are assumed to mean these things: # HOME - path location on disk of read-only binaries and configuration # BASE - path location on disk of read-write configuration and data storage The term BASE is intended to point at a Geronimo Server Instance Base path. However, this has not been clearly defined, and has appeared to cause some misusage. Thus this and other issues lead to the removal of GERONIMO_BASE shell variable and org.apache.geronimo.base.dir java property in GERONIMO-4229 . Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir java property must be defined in the GERONIMO_OPTS variable. However, this prevents the Shell scripts from being able to know and use the path location to the Geronimo Server Instance. In particular, there are a few issues affected by a variable like this not being available. # Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts as GERONIMO_HOME/var/tmp. In turn, the java property java.io.tmpdir is set to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp). Shouldn't GERONIMO_TMPDIR instead be set to a value provided by GERONIMO_SERVER/var/tmp ? -- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools -- This can be argued to whether or not all Geronimo Server Instance should share a common temp directory. # Reported in GERONIMO-6174 - The java properties karaf.home and karaf.base are both being set to GERONIMO_HOME. When instead karaf.base should be set to a value held by GERONIMO_SERVER. -- affected scripts: client, geronimo, internalLauncher -- see resulting errors and reasoning in GERONIMO-6174 # Not Reported - The java property java.util.logging.config.file is being set to GERONIMO_HOME/etc/java.util.logging.properties . It is intended to be an empty configuration file. This only causes a problem when using instances if GERONIMO_HOME/etc does not exist (it would not exist if GERONIMO_SERVER/etc is intended to be used). -- affected scripts: client, geronimo, internalLauncher # Not Reported - Logging startup output to GERONIMO_HOME/var/log/geronimo.out - Obviously if multiple instances are being started, this should be GERONIMO_SERVER/var/log/geronimo.out . Any error is silent if var/log/geronimo.out does not exist. -- affected scripts: geronimo # Not Reported - The register-service script does a grep and awk on GERONIMO_HOME/var/config/config-substitutions.properties to discover the portOffset . Obviously this will not work for multiple instances -- The register-service script does not take multiple instances into consideration at all -- affected scripts: register-service Solution: - Create a new shell
[jira] [Created] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Priority: Minor
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to improper
use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being reported
here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script:
/data/geronimo2/geronimo-tomcat7-javaee6-3.0-SNAPSHOT-20111220/etc/shell.init.script
(No such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/data/geronimo2/geronimo-tomcat7-javaee6-3.0-SNAPSHOT-20111220/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/data/geronimo2/geronimo-tomcat7-javaee6-3.0-SNAPSHOT-20111220/var/monitoring/snapshot-config.xml
(Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for
GERONIMO_HOME/var/monitoring
-- Solution:
--- SnapshotConfigXMLBuilder should instead be looking for
GERONIMO_SERVER/var/monitoring
-- Affected code:
---
trunk/plugins/monitoring/agent-ejb/src/main/java/org/apache/geronimo/monitoring/ejb/snapshot/SnapshotProcessor.java
---
trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfigXMLBuilder.java
# ActiveMQ Lock File
-- WARN [AMQPersistenceAdapter] Waiting to Lock the Store var/activemq
-- Reason:
--- This is because the JMSBrokerPortlet will create and use a var directory
relative to the path in which Geronimo was started (Note this may not be the
actual GERONIMO_HOME or GERONIMO_SERVER directory).
--- If two Geronimo instances are started from the same directory, they will
share the same var directory, thus they will both want to use the same ActiveMQ
lock file.
-- Solution:
--- A full path to the var directory should be used, or at least a path
relative to org.apache.geronimo.server.dir
--- The full
[jira] [Updated] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue updated GERONIMO-6281:
--
Issue Type: Sub-task (was: Bug)
Parent: GERONIMO-6270
Geronimo home.dir is being used when server.dir should be used instead for
SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
Key: GERONIMO-6281
URL: https://issues.apache.org/jira/browse/GERONIMO-6281
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: ActiveMQ, javaee6
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to
improper use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being
reported here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script:
/data/geronimo2/geronimo-tomcat7-javaee6-3.0-SNAPSHOT-20111220/etc/shell.init.script
(No such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/data/geronimo2/geronimo-tomcat7-javaee6-3.0-SNAPSHOT-20111220/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/data/geronimo2/geronimo-tomcat7-javaee6-3.0-SNAPSHOT-20111220/var/monitoring/snapshot-config.xml
(Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for
GERONIMO_HOME/var/monitoring
-- Solution:
--- SnapshotConfigXMLBuilder should instead be looking for
GERONIMO_SERVER/var/monitoring
-- Affected code:
---
trunk/plugins/monitoring/agent-ejb/src/main/java/org/apache/geronimo/monitoring/ejb/snapshot/SnapshotProcessor.java
---
trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfigXMLBuilder.java
# ActiveMQ Lock File
-- WARN [AMQPersistenceAdapter] Waiting to Lock the Store var/activemq
-- Reason:
--- This is because the JMSBrokerPortlet will create and use a var directory
relative to the path in which Geronimo was started
[jira] [Updated] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue updated GERONIMO-6281:
--
Description:
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to improper
use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being reported
here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var/monitoring/snapshot-config.xml (Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for
GERONIMO_HOME/var/monitoring
-- Solution:
--- SnapshotConfigXMLBuilder should instead be looking for
GERONIMO_SERVER/var/monitoring
-- Affected code:
---
trunk/plugins/monitoring/agent-ejb/src/main/java/org/apache/geronimo/monitoring/ejb/snapshot/SnapshotProcessor.java
---
trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfigXMLBuilder.java
# ActiveMQ Lock File
-- WARN [AMQPersistenceAdapter] Waiting to Lock the Store var/activemq
-- Reason:
--- This is because the JMSBrokerPortlet will create and use a var directory
relative to the path in which Geronimo was started (Note this may not be the
actual GERONIMO_HOME or GERONIMO_SERVER directory).
--- If two Geronimo instances are started from the same directory, they will
share the same var directory, thus they will both want to use the same ActiveMQ
lock file.
-- Solution:
--- A full path to the var directory should be used, or at least a path
relative to org.apache.geronimo.server.dir
--- The full path to var should be within org.apache.geronimo.server.dir
-- Affected code:
---
trunk/plugins/activemq/activemq-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/server/JMSBrokerPortlet.java
Setup for reproducing the errors:
Follow the example for running multiple instances within the Geronimo Wiki,
here:
#
https://cwiki.apache.org/confluence/display/GMOxDOC30/Running+multiple+Geronimo+instances
# Then remove the GERONIMO_HOME/var and GERONIMO_HOME/etc directories
# Create an empty file {PWD}/var/monitoring to prevent SnapshotConfigXMLBuilder
from creating {PWD}/var/monitoring when it discovers
[jira] [Updated] (GERONIMO-6281) Geronimo home.dir is being used when server.dir should be used instead for SnapshotConfigXMLBuilder, ActiveMQ, and Karaf
[
https://issues.apache.org/jira/browse/GERONIMO-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue updated GERONIMO-6281:
--
Description:
This issue is related to GERONIMO-6270 , GERONIMO-6175 , GERONIMO-6174 ,
GERONIMO-5987 , and is being used to specifically track modifications related
to correctly using the following properties:
# org.apache.geronimo.home.dir (GERONIMO_HOME)
# org.apache.geronimo.server.dir (GERONIMO_SERVER - new shell variable
introduced in GERONIMO-6275)
# karaf.base
# karaf.home
Primary issue to be resolved: The org.apache.geronimo.home.dir property
(GERONIMO_HOME) is being referenced when the org.apache.geronimo.server.dir
property (GERONIMO_SERVER) should be instead.
I have identified three places in Geronimo errors are occurring due to improper
use of the above java properties:
# SnapshotConfigXMLBuilder - originally reported in GERONIMO-6270
# ActiveMQ - is reported in a comment of GERONIMO-5987 , and is being reported
here as requested.
# Karaf - is additionally reported in GERONIMO-6174 .
Note the three issues in startup:
# Karaf initialization script etc/shell.init.script
-- Error in initialization script: /opt/geronimo3/etc/shell.init.script (No
such file or directory)
-- Reason:
--- This is because karaf.home/etc/shell.init.script is being accessed when
instead it should be karaf.base/etc/shell.init.script
-- Solution:
--- The {karaf.base} property should be the same value as the
{org.apache.geronimo.server.dir} property
-- Affected Code:
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/RunClientMojo.java
---
framework/buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/server/StartServerMojo.java
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/framework/src/main/distribution/text/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/system.properties
---
trunk/framework/features/client/src/main/filtered-resources/resources/instances/client/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartServerCommand.java
---
trunk/framework/modules/geronimo-shell-base/src/main/java/org/apache/geronimo/shell/geronimo/StartClientCommand.java
---
trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/serverinfo/BasicServerInfo.java
---
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
-- These code files are affected, but in relation to specifying the repository
---
trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
---
trunk/framework/features/framework/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg
# SnapshotConfigXMLBuilder var/monitoring/ directory
-- (A) ERROR [SnapshotConfigXMLBuilder] Could not make the directory
/opt/geronimo3/var/monitoring/
-- (B) ERROR [SnapshotConfigXMLBuilder]
/opt/geronimo3/var/monitoring/snapshot-config.xml (Not a directory)
-- Reason:
--- This is because SnapshotConfigXMLBuilder is looking for $PWD/var/monitoring
-- Solution:
--- SnapshotConfigXMLBuilder should instead be using a full path to
var/monitoring, i.e. org.apache.geronimo.server.dir/var/monitoring
-- Affected code:
---
trunk/plugins/monitoring/agent-ejb/src/main/java/org/apache/geronimo/monitoring/ejb/snapshot/SnapshotProcessor.java
---
trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfigXMLBuilder.java
# ActiveMQ var/activemq/ directory and Lock File
-- WARN [AMQPersistenceAdapter] Waiting to Lock the Store var/activemq
-- Reason:
--- This is because the ActiveMQ will create and use a var directory relative
to the path in which Geronimo was started (Note this may not be the actual
GERONIMO_HOME or GERONIMO_SERVER directory).
--- If two Geronimo instances are started from the same directory, they will
share the same var directory, thus they will both want to use the same ActiveMQ
lock file. This will conflict in the usage of other files in var/activemq too.
-- Solution:
--- ActiveMQ should instead be using a full path to var/activemq, i.e.
org.apache.geronimo.server.dir/var/activemq
-- Affected code:
---
trunk/plugins/activemq/activemq-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/server/JMSBrokerPortlet.java
Setup for reproducing the errors:
Follow the example for running multiple instances within the Geronimo Wiki,
here:
#
https://cwiki.apache.org/confluence/display/GMOxDOC30/Running+multiple+Geronimo+instances
# Then remove the GERONIMO_HOME/var and GERONIMO_HOME/etc directories
# Create an empty file $PWD/var/monitoring to prevent
[jira] [Commented] (GERONIMO-5987) The ActiveMQ working directory and port are not referenced correctly - multiple instances not possible
[
https://issues.apache.org/jira/browse/GERONIMO-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210652#comment-13210652
]
Russell E Glaue commented on GERONIMO-5987:
---
The ActiveMQ Lock File conflict issue is now filed in GERONIMO-6281
The ActiveMQ working directory and port are not referenced correctly -
multiple instances not possible
--
Key: GERONIMO-5987
URL: https://issues.apache.org/jira/browse/GERONIMO-5987
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 3.0-M1, 3.0
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga)
Reporter: Russell E Glaue
Assignee: Rex Wang
Labels: geronimo
Fix For: 3.0, 3.0-beta-1
Attachments: GERONIMO-5987-detail.patch, GERONIMO-5987-new.patch,
GERONIMO-5987.patch
I am testing with geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT,
geronimo-tomcat7-javaee6-web-3.0-20110523.171218-97
ActiveMQ is configured to run as org.apache.geronimo.home.dir/var/activemq
and port 61616, and does not cooperate with multi-server configurations, nor
does it use the PortOffset. This is the use of the
org.apache.geronimo.server.name option and PortOffset in
var/config/config-substitutions.properties. (see:
https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html)
First, Problem with working directory
When wanting to run more than a single server instance, the ActiveMQ startup
will block waiting for the lock file $GERONIMO_HOME/var/activemq/lock to
become available.
Obviously this causes any server instance started after the first server
instance is started to block during startup while waiting for the lock file
to become available.
Second, Problem with PortOffset
When configuring the PortOffset in
var/config/config-substitutions.properties, all Geroniomo components expect
and attempt to connect to ActiveMQ at the port {ActiveMQ + PortOffset}.
However, regardless of what you set the PortOffset to be, the ActiveMQ
service only ever binds to port 61616, the default configured port (or
whatever you have the port set as for this service).
Steps to repeat working directory problem:
1. Download and unpack G3.0 SNAPSHOT (3.0-20110523 tested)
2. Create the server instances:
-- 2A. cd ${GERONIMO_HOME}
-- 2B-1. mkdir gserver1
-- 2B-2. cp -rp var gserver1/
-- 2B-3. cp -rp etc gserver1/
-- 2B-4. cp -rp repository gserver1/
3. update the PortOffset parameter in
gserver1/var/config/config-substitutions.properties for the gserver1 instance.
4. Start the default instance and gserver1 instance:
-- bin/startup
-- env GERONIMO_OPTS=-Dorg.apache.geronimo.server.name=gserver1 bin/startup
5. `tail -f gserver1/var/logs/geronimo.log` and you will see this as the last
line that outputs:
2011-05-31 16:26:39,609 WARN [AMQPersistenceAdapter] Waiting to Lock the
Store var/activemq
The server waits here indefinitely.
6. Shutdown the default instance and you will see the gserver1 instance
continue on in the startup procedures. (of course you will see errors due to
the PortOffset problem)
* If I first start the gserver1 instance by itself (before starting the
default instance), the directory org.apache.geronimo.home.dir/var/activemq
is created and populated. Instead it should be
org.apache.geronimo.home.dir/org.apache.geronimo.server.name/var/activemq
that is created and populated.
* Probably the patch should be to reference the ActiveMQ working directory as
org.apache.geronimo.server.dir/var/activemq
Steps to repeat PortOffset problem:
1. Download and unpack G3.0 SNAPSHOT (3.0-20110523 tested)
2. Create the server instances:
-- 2A. cd ${GERONIMO_HOME}
-- 2B-1. mkdir gserver1
-- 2B-2. cp -rp var gserver1/
-- 2B-3. cp -rp etc gserver1/
-- 2B-4. cp -rp repository gserver1/
3. update the PortOffset parameter in
gserver1/var/config/config-substitutions.properties in the instance
4. Start the server instance:
-- env GERONIMO_OPTS=-Dorg.apache.geronimo.server.name=gserver1 bin/startup
This is the two error messages you receive when configuring PortOffset to 100
(for example). The second error message, regarding XAResource, repeats:
-
2011-06-01 16:26:49,883 ERROR [MCFConnectionInterceptor] Error occurred
creating
ManagedConnection for handle: nullManagedConnectionInfo:
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@1c211b3. mc:
null]
javax.resource.ResourceException: Could not create connection.
at
org.apache.activemq.ra.ActiveMQManagedConnectionFactory.createManagedConnection(ActiveMQManagedConnectionFactory.java:171)
...
Caused
[jira] [Created] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts -- Key: GERONIMO-6275 URL: https://issues.apache.org/jira/browse/GERONIMO-6275 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Components: startup/shutdown Affects Versions: 3.0-beta-1 Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga); Java JDK1.6.0_25 Reporter: Russell E Glaue Priority: Minor Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987, GERONIMO-4229 It would be easier to support multiple server instances of Geronimo if there is one shell variable that is used to reference the path on disk to the instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME installation path. This issue tracks the discussion and modification of such a change. GERONIMO_SERVER defines: - GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified - GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if GERONIMO_SERVER is a relative path - GERONIMO_SERVER defines org.apache.geronimo.server.dir In the java code there are the following properties: # org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable # org.apache.geronimo.server.dir - proposed to be equivelant to GERONIMO_SERVER The words BASE versus HOME appear a few times in the source. Once example is karaf.home and karaf.base properties. According to the code usage, it is aparant that these terms are assumed to mean these things: # HOME - path location on disk of read-only binaries and configuration # BASE - path location on disk of read-write configuration and data storage The term BASE is intended to point at a Geronimo Server Instance Base path. However, this has not been clearly defined, and has appeared to cause some misusage. Thus this and other issues lead to the removal of GERONIMO_BASE shell variable and org.apache.geronimo.base.dir java property in GERONIMO-4229 . Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir java property must be defined in the GERONIMO_OPTS variable. However, this prevents the Shell scripts from being able to know and use the path location to the Geronimo Server Instance. In particular, there are a few issues affected by a variable like this not being available. # Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts as GERONIMO_HOME/var/tmp. In turn, the java property java.io.tmpdir is set to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp). Shouldn't GERONIMO_TMPDIR instead be set to a value provided by GERONIMO_SERVER/var/tmp ? -- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools -- This can be argued to whether or not all Geronimo Server Instance should share a common temp directory. # Reported in GERONIMO-6174 - The java properties karaf.home and karaf.base are both being set to GERONIMO_HOME. When instead karaf.base should be set to a value held by GERONIMO_SERVER. -- affected scripts: client, geronimo, internalLauncher -- see resulting errors and reasoning in GERONIMO-6174 # Not Reported - The java property java.util.logging.config.file is being set to GERONIMO_HOME/etc/java.util.logging.properties . It is intended to be an empty configuration file. This only causes a problem when using instances if GERONIMO_HOME/etc does not exist (it would not exist if GERONIMO_SERVER/etc is intended to be used). -- affected scripts: client, geronimo, internalLauncher # Not Reported - Logging startup output to GERONIMO_HOME/var/log/geronimo.out - Obviously if multiple instances are being started, this should be GERONIMO_SERVER/var/log/geronimo.out . Any error is silent if var/log/geronimo.out does not exist. -- affected scripts: geronimo # Not Reported - The register-service script does a grep and awk on GERONIMO_HOME/var/config/config-substitutions.properties to discover the portOffset . Obviously this will not work for multiple instances -- The register-service script does not take multiple instances into consideration at all -- affected scripts: register-service Solution: - Create a new shell variable GERONIMO_SERVER to hold the path location to the run-time server configuration, and leave GERONIMO_HOME to hold the path location to the Geronimo Installation Path. Arguments: - If GERONIMO_SERVER defaults to GERONIMO_HOME, then any installation not having multiple instances configured will not be affected. - This will not resolve the multiple instance support issue in Geronimo, GERONIMO-6270, but having this support in the shell scripts will get Geronimo much closer. - About half of the currently known issues (listed above) can be resolved with the addition of GERONIMO_SERVER
[jira] [Updated] (GERONIMO-6174) Environment variables being set in bin/geronimo does not account for named server instances
[
https://issues.apache.org/jira/browse/GERONIMO-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russell E Glaue updated GERONIMO-6174:
--
Description:
I have been able to workaround these two issues by setting properties.
Questions:
1A) But should these properties be dynamically set relative to the named
instance directory instead of GERONIMO_HOME?
1B) Or do we require the user to explicitly set these in the environment in
order to start a named instance?
2) Does setting karaf.home in GERONIMO_OPTS as relative to the named instance
directory instead of GERONIMO_HOME potentially cause any other issues?
To produce these issues follow these steps:
1. Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
2. Create a Geronimo named instance directory as /opt/geronimo3/gserv1
3. Move the directories var, etc, and repository into /opt/geronimo3/gserv1
4. Use this start script
{noformat:borderStyle=solid}
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issue #1
#export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
#
# Uncomment for the Workaround of issue #2
#GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
{noformat}
1) GERONIMO_TMPDIR
On startup, the `bin/geronimo` startup script sets GERONIMO_TMPDIR explicitly as
$GERONIMO_HOME/var/temp , but the actual temp directory is really
{org.apache.geronimo.server.dir}/var/temp (or
$GERONIMO_HOME/{org.apache.geronimo.server.name}/var/temp)
It does not account for the cases where an instance is being started.
{noformat:borderStyle=solid}
[user@system gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
Error launching framework: java.lang.IllegalArgumentException: Invalid
temporary directory. The '/opt/geronimo3/var/temp' path does not exist.
{noformat}
The workaround is to specifically specify GERONIMO_TMPDIR in your environment
before starting the instance.
2) karaf.home
On startup, the `bin/geronimo` script sets karaf.home explicitly as
$GERONIMO_HOME . Karaf expects to use {karaf.home}/etc/shell.init.script each
time a shell session is started (See:
geronimo/server/trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties).
The setting of the karaf.home property in `bin/geronimo` does not account for
the cases where a Geronimo named instance is being started.
{noformat:borderStyle=solid}
[root@rglaue7 gserv1]# ./start.sh
Using GERONIMO_HOME: /opt/geronimo3
Using GERONIMO_TMPDIR: /opt/geronimo3/gserv1/var/temp
Using JRE_HOME:/usr/jdk1.6.0/jre
__ _
/ /___ _ (_) ___
/ / __ / _ \/ ___/ __ \/ __ \/ // __ `__ \/ __ \
/ /_/ // __/ / / /_/ / / / / // / / / / / /_/ /
\/ \___/_/ \/_/ /_/_//_/ /_/ /_/\/
Apache Geronimo (3.0-SNAPSHOT)
Hit 'tab' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit 'ctrl-d' or 'osgi:shutdown' to shutdown Geronimo.
Error in initialization script: /opt/geronimo3/etc/shell.init.script (No such
file or directory)
... snip ...
{noformat}
The workaround is to set karaf.home in GERONIMO_OPTS before starting the
instance.
was:
I have been able to workaround these two issues by setting properties.
Questions:
1A) But should these properties be dynamically set relative to the named
instance directory instead of GERONIMO_HOME?
1B) Or do we require the user to explicitly set these in the environment in
order to start a named instance?
2) Does setting karaf.home in GERONIMO_OPTS as relative to the named instance
directory instead of GERONIMO_HOME potentially cause any other issues?
To produce these issues follow these steps:
1. Unpack the latest Geronimo javaee6 bundle as /opt/geronimo3
2. Create a Geronimo named instance directory as /opt/geronimo3/gserv1
3. Move the directories var, etc, and repository into /opt/geronimo3/gserv1
4. Use this start script
-
#!/bin/bash
GHOME=/opt/geronimo3
GVIRT=gserv1
# Must change to the server directory in order to work around ActiveMQ lock
# file conflict issue reported in GERONIMO-5987.
cd ${GHOME}/${GVIRT}
# Uncomment for the Workaround of issue #1
#export GERONIMO_TMPDIR=${GHOME}/${GVIRT}/var/temp
#
# Uncomment for the Workaround of issue #2
#GERONIMO_OPTS=${GERONIMO_OPTS} -Dkaraf.home=${GHOME}/${GVIRT}
#
GERONIMO_OPTS=${GERONIMO_OPTS} -Dorg.apache.geronimo.server.name=${GVIRT}
export GERONIMO_OPTS
${GHOME}/bin/geronimo run
-
1
[jira] [Commented] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
[
https://issues.apache.org/jira/browse/GERONIMO-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13209853#comment-13209853
]
Russell E Glaue commented on GERONIMO-6275:
---
Reference to documentation in the code implying the meaning and usage of home
versus base:
{noformat:borderStyle=solid}
src:
trunk/framework/modules/geronimo-main/src/main/java/org/apache/geronimo/main/FrameworkLauncher.java
...
/**
* The system property for specifying the Karaf home directory. The home
directory
* hold the binary install of Karaf.
*/
private static final String PROP_KARAF_HOME = karaf.home;
/**
* The system property for specifying the Karaf base directory. The base
directory
* holds the configuration and data for a Karaf instance.
*/
private static final String PROP_KARAF_BASE = karaf.base;
...
{noformat}
Defining and Using org.apache.geronimo.server.dir versus
org.apache.geronimo.home.dir in shell scripts
--
Key: GERONIMO-6275
URL: https://issues.apache.org/jira/browse/GERONIMO-6275
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 3.0-beta-1
Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
(Tikanga); Java JDK1.6.0_25
Reporter: Russell E Glaue
Priority: Minor
Labels: geronimo
Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987,
GERONIMO-4229
It would be easier to support multiple server instances of Geronimo if there
is one shell variable that is used to reference the path on disk to the
instance, proposed as GERONIMO_SERVER as opposed to the GERONIMO_HOME
installation path. This issue tracks the discussion and modification of such
a change.
GERONIMO_SERVER defines:
- GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified
- GERONIMO_SERVER is expanded to GERONIMO_HOME/GERONIMO_SERVER if
GERONIMO_SERVER is a relative path
- GERONIMO_SERVER defines org.apache.geronimo.server.dir
In the java code there are the following properties:
# org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable
# org.apache.geronimo.server.dir - proposed to be equivelant to
GERONIMO_SERVER
The words BASE versus HOME appear a few times in the source. Once example
is karaf.home and karaf.base properties. According to the code usage, it
is aparant that these terms are assumed to mean these things:
# HOME - path location on disk of read-only binaries and configuration
# BASE - path location on disk of read-write configuration and data storage
The term BASE is intended to point at a Geronimo Server Instance Base path.
However, this has not been clearly defined, and has appeared to cause some
misusage. Thus this and other issues lead to the removal of GERONIMO_BASE
shell variable and org.apache.geronimo.base.dir java property in
GERONIMO-4229 .
Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir
java property must be defined in the GERONIMO_OPTS variable. However, this
prevents the Shell scripts from being able to know and use the path location
to the Geronimo Server Instance.
In particular, there are a few issues affected by a variable like this not
being available.
# Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts
as GERONIMO_HOME/var/tmp. In turn, the java property java.io.tmpdir is set
to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp). Shouldn't GERONIMO_TMPDIR
instead be set to a value provided by GERONIMO_SERVER/var/tmp ?
-- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools
-- This can be argued to whether or not all Geronimo Server Instance should
share a common temp directory.
# Reported in GERONIMO-6174 - The java properties karaf.home and karaf.base
are both being set to GERONIMO_HOME. When instead karaf.base should be set to
a value held by GERONIMO_SERVER.
-- affected scripts: client, geronimo, internalLauncher
-- see resulting errors and reasoning in GERONIMO-6174
# Not Reported - The java property java.util.logging.config.file is being set
to GERONIMO_HOME/etc/java.util.logging.properties . It is intended to be an
empty configuration file. This only causes a problem when using instances if
GERONIMO_HOME/etc does not exist (it would not exist if GERONIMO_SERVER/etc
is intended to be used).
-- affected scripts: client, geronimo, internalLauncher
# Not Reported - Logging startup output to GERONIMO_HOME/var/log/geronimo.out
- Obviously if multiple instances are being started, this should be
GERONIMO_SERVER/var/log/geronimo.out . Any error is silent
