[jira] Created: (SM-1055) jbi maven plugin can't pick up jar from maven repos if this jar has no relavant pom file when build component installer
jbi maven plugin can't pick up jar from maven repos if this jar has no relavant pom file when build component installer --- Key: SM-1055 URL: https://issues.apache.org/activemq/browse/SM-1055 Project: ServiceMix Issue Type: Bug Reporter: Freeman Fang For example, neethi-2.0.2.jar has no neethi-2.0.2.pom in http://repo1.maven.org/maven2/org/apache/neethi/neethi/2.0.2/ So even my component has dependency on neethi-2.0.2, the jbi maven plugin still can't pick up neethi-2.0.2.jar when build the component installer, neither wirte this jar to component descriptor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
question about servicemix 3.1.2 release
Hi all, When are we going to release servicemix 3.1.2? As a new commiter in servicemix team, I'd like to know how is the release process looks like. If possible, shall I be release manager of this time? :-) Any suggestion is appreciated. Best Regards Freeman
Re: question about servicemix 3.1.2 release
On Sep 12, 2007, at 8:46 AM, Freeman Fang wrote: Hi all, When are we going to release servicemix 3.1.2? As a new commiter in servicemix team, I'd like to know how is the release process looks like. If possible, shall I be release manager of this time? :-) Yeah of course you can :-) There are some instructions available at http://incubator.apache.org/ servicemix/release-guide.html but these are a bit outdated, so we'll have to update those (and maven can not really be used for creating the release)... Let me have a breakfast and write something more accurate... Any suggestion is appreciated. Best Regards Freeman -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: question about servicemix 3.1.2 release
Thanks in advance. Cheers Freeman Nodet Guillaume wrote: On Sep 12, 2007, at 8:46 AM, Freeman Fang wrote: Hi all, When are we going to release servicemix 3.1.2? As a new commiter in servicemix team, I'd like to know how is the release process looks like. If possible, shall I be release manager of this time? :-) Yeah of course you can :-) There are some instructions available at http://incubator.apache.org/servicemix/release-guide.html but these are a bit outdated, so we'll have to update those (and maven can not really be used for creating the release)... Let me have a breakfast and write something more accurate... Any suggestion is appreciated. Best Regards Freeman --Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: question about servicemix 3.1.2 release
I have updated the releasing notes to something that I hope will work ;-) See http://cwiki.apache.org/confluence/display/SM/Release+Guide If you have any questions, just yell ! On 9/12/07, Nodet Guillaume [EMAIL PROTECTED] wrote: On Sep 12, 2007, at 8:46 AM, Freeman Fang wrote: Hi all, When are we going to release servicemix 3.1.2? As a new commiter in servicemix team, I'd like to know how is the release process looks like. If possible, shall I be release manager of this time? :-) Yeah of course you can :-) There are some instructions available at http://incubator.apache.org/servicemix/release-guide.html but these are a bit outdated, so we'll have to update those (and maven can not really be used for creating the release)... Let me have a breakfast and write something more accurate... Any suggestion is appreciated. Best Regards Freeman -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Plugin progress
I think I resolved most of the resolve to wrong version problems (basically #3 below), and I managed to start with framework and deploy plugins until I got a working web console (jetty, and the old non-modular console). There are still a bunch of weirdnesses going on such as openejb having NCDFE but this seems to me like a significant step towards plugin usability. There may be other problems such as I'm not sure the gbean configs are getting copied into config.xml properly. I'll keep looking at this stuff. thanks david jencks On Sep 11, 2007, at 12:13 AM, David Jencks wrote: I've now updated enough of the configs so we can see if we can assemble them into a server. It would be great if some one else could take a look at some of the remaining ones, list at the end of this email. To get your own list of un-cleaned-up configs build g, fire it up, and run search-plugins from the command line deployer: the no category ones aren't done yet. To provide a more reasonable sized testbed for assembling servers out of plugins I also shrank geronimo-framework to the minimum possible size: rmi-naming plus enough security to enable the command line deployer to connect to it. So, while some parts of plugin installation work, overall it doesn't. I keep seeing plugin installation pull in the wrong version of jars and cars and sometimes not find jars that are present in the local maven repo. Here are the problems I've noted so far, in order of discovery: 1. While reviewing config poms I saw some suspicious dependencies. Axis and Axis2 depend on openejb which subverts any attempt to run axis web services on a minimal server. The openejb-deployer requires openejb to be running which subverts any attempt to deploy offline while another server is running on the same machine (port conflicts). 2. Figuring out which repository to look in doesn't work yet. While what is specified in the geronimo-plugin.xml and geronimo- plugins.xml does appear to be honored, using these isn't compatible with developing and testing plugins, since while a plugin is being worked on you want to use only your local repo but after its published you don't (unless perhaps its is hooked up to some kind of maven proxy) I wonder if having a default repo configured in the plugin installer system would work, or perhaps merging the repos at the end of geronimo-plugins.xml with those in each geronimo-plugin.xml. 3. version resolution appears to have some serious problems. I think pretty much all of the geronimo-plugin.xmls contain versions for every jar (something I'm hoping to change) but I ran into a lot of problems. First most of the artifacts got resolved to the 2.0.1 released artifacts which didn't work because the car files didn't have valid geronimo-plugin.xmls in them. After I removed all my 2.0.1 artifacts things were slightly better until I got to something that wouldn't resolve at all, xbean-reflect 3.2- SNAPSHOT. The jar is in my local repo but for some reason it wasn't found. 4. I am doubting more and more that the current requires and obsoletes data are appropriate. For instance, most of the web apps require jetty (or tomcat, pick your flavor). IMO this is the wrong idea. If I want to install one of these web apps, it should install the web server if it's not already present. What I think is more appropriate would be if I'm trying to install a jetty web app and tomcat is installed it should complain: if no other web server is installed then it should install jetty for me. 5. Trying to extract information about what went wrong is really hard and unpleasant. 6. With the CTS configs that happen to be on my machine, there are 93. This is a lot to wade through. We need a better way of organizing them, at least on the command line. Perhaps providing a list of categories to pick from, then the plugins from that category, would be more manageable. Also a deploy this from this maven repo command would be good: this might exist but I haven't found it yet. thanks david jencks no category Geronimo Configs :: Welcome app Jetty 8 : (2.1-SNAPSHOT) Geronimo Configs :: Unavailable Client Deployer 9 : (2.1-SNAPSHOT) Geronimo Configs :: GBean Deployer 11: (2.1-SNAPSHOT) Geronimo Configs :: Shared Library 12: (2.1-SNAPSHOT) Geronimo Configs :: System Database 13: (2.1-SNAPSHOT) Geronimo Configs :: Application Client Deployments 14: (2.1-SNAPSHOT) Geronimo Configs :: J2EE Client transaction 15: (2.1-SNAPSHOT) Geronimo Configs :: CLI Upgrade 16: (2.1-SNAPSHOT) Geronimo Configs :: Unavailable EJB Deployer 17: (2.1-SNAPSHOT) Geronimo Configs :: Plan Upgrade 20: (2.1-SNAPSHOT) Geronimo Configs :: Shutdown 21: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 JAR Configurer 23: (2.1-SNAPSHOT)
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526710 ] Vamsavardhana Reddy commented on GERONIMO-2964: --- I downloaded http://repo1.maven.org/maven2/org/apache/geronimo/configs/servlet-examples-tomcat/2.0.1/servlet-examples-tomcat-2.0.1.car and tried to install it in 2.0.2-SNAPSHOT server using deploy.bat install-plugin I got a message Installation FAILED: Cannot install plugin org.apache.geronimo.configs/servlet-examples-tomcat/2.0.1/car on Geronimo 2.0.2-SNAPSHOT. I see that the geronimo-plugin.xml inside servlet-examples-tomcat-2.0.1.car has geronimo-versionsversion2.0.1/version/geronimo-versions. Does it mean the plug-in will not install on G 2.0.2 whether or not there is API difference? What am I missing? Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Priority: Minor Fix For: 1.2, 2.1 Attachments: g2964.war, GERONIMO-2964-combined.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-200) javax.xml.soap not included in geronimo runtime library
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526716 ] Tomasz Mazan commented on GERONIMODEVTOOLS-200: --- Thanks for quick patch. Works fine. javax.xml.soap not included in geronimo runtime library --- Key: GERONIMODEVTOOLS-200 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-200 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tomasz Mazan Assignee: Tim McConnell Fix For: 2.0 javax.xml.soap not included in geronimo runtime library by default. User have to import single jar to project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Fwd: svn commit: r573772 - in /tomcat: sandbox/gdev6x/ trunk/
On 9/11/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: sorry about the hassle, but I had little support keeping it in trunk, the decision to move it to sandbox had nothing to do with comet, or anything else, simply egos that got in the way of rational decisions. Hi, I'm really worried about Tomcat integration support in Geronimo having read the email. What makes it even more frustrating is the fact that Apache Tomcat is a flagship product of the entire product set of ASF around Java EE and when we came to the point of integrating Tomcat and made Java EE TCK passed possible it went away with a mere svn mv. I hope there's more than egos that can explain the decision. Thanks Filip for your support. Greatly appreciated. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: svn commit: r573772 - in /tomcat: sandbox/gdev6x/ trunk/
On 9/8/07, Paul McMahan [EMAIL PROTECTED] wrote: I raised a concern about moving trunk to sandbox since it's the only branch that contains the annotation support needed by Geronimo. A committer responded that he will think about maintaining a patchset with this annotation support. See http://tinyurl.com/2enw25 How can we work it around? Shall we put Tomcat codebase into our repo and maintain ourselves or start the G-T integration over with the newest trunk bits? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Created: (GERONIMO-3467) Confusing security exception thrown while authenticating using JMX with a just starting server
Confusing security exception thrown while authenticating using JMX with a just starting server -- Key: GERONIMO-3467 URL: https://issues.apache.org/jira/browse/GERONIMO-3467 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.0.2 Reporter: Shiva Kumar H R Fix For: 2.0.2 Scenario is as below: Let's say server is starting and org.apache.geronimo.configs/rmi-naming/2.0.1/car has started, but org.apache.geronimo.configs/j2ee-security/2.0.1/car hasn't yet started. If an external entity (like Geronimo Eclipse Plug-in) now tries to connect to the kernel remotely through JMX, although rmi connection succeeds, authenticate will fail (because security realm has not yet been started). In this case, org.apache.geronimo.jmxremoting.Authenticator.authenticate() is getting a LoginException with error javax.security.auth.login.LoginException: No LoginModules configured for geronimo-admin. However this exception is not propogated, but rather is thrown back as a 'SecurityException(Invalid login)'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3467) Confusing security exception thrown while authenticating using JMX with a just starting server
[ https://issues.apache.org/jira/browse/GERONIMO-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526785 ] Shiva Kumar H R commented on GERONIMO-3467: --- Forgot to mention that this is causing problem in Geronimo Eclipse Plug-in as reported in GERONIMODEVTOOLS-193. Confusing security exception thrown while authenticating using JMX with a just starting server -- Key: GERONIMO-3467 URL: https://issues.apache.org/jira/browse/GERONIMO-3467 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2 Reporter: Shiva Kumar H R Fix For: 2.0.2 Scenario is as below: Let's say server is starting and org.apache.geronimo.configs/rmi-naming/2.0.1/car has started, but org.apache.geronimo.configs/j2ee-security/2.0.1/car hasn't yet started. If an external entity (like Geronimo Eclipse Plug-in) now tries to connect to the kernel remotely through JMX, although rmi connection succeeds, authenticate will fail (because security realm has not yet been started). In this case, org.apache.geronimo.jmxremoting.Authenticator.authenticate() is getting a LoginException with error javax.security.auth.login.LoginException: No LoginModules configured for geronimo-admin. However this exception is not propogated, but rather is thrown back as a 'SecurityException(Invalid login)'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r573772 - in /tomcat: sandbox/gdev6x/ trunk/
After voting to move tomcat/trunk to sandbox there has been some good discussion about the development model for a new trunk, mainly whether it will follow some form of RTC. When a new trunk is created I will ask them to reapply the annotation support patch and offer to help if needed. If Tomcat decides to use RTC then it's possible that the patch won't receive enough binding votes but I'm optimistic that there will be good support. I don't expect there would be any technical issues with it since it was actually developed against the 6.0.x branch, has passed TCK, and David and Remy worked through all of the known issues as it was applied. Filip has also been extremely helpful and provides good insights for this type of thing. As that discussion plays out we can continue to create a special build of tomcat using the procedure described in https:// issues.apache.org/jira/browse/GERONIMO-3206. The only difference being that the annotation support would need to be merged from tomcat/ sandbox/gdev6x onto their latest 6.0.x tag instead of merging it from trunk. Right now the Tomcat binaries used by Geronimo 2.x are kept in SVN under geronimo/server/**/repository. We'll probably need to stick with that approach for a while anyway since the Tomcat team (understandably) has had some reservations about publishing snapshots of trunk, see http://www.nabble.com/please-publish-a-snapshot-tf3850372.html Another possibility would be to investigate whether the basic annotation support provided in the already released versions of Tomcat 6.0.x could be adequate for Geronimo's needs. As I recall we had that working at one point but it had some limitations. Best wishes, Paul On Sep 12, 2007, at 7:44 AM, Jacek Laskowski wrote: On 9/8/07, Paul McMahan [EMAIL PROTECTED] wrote: I raised a concern about moving trunk to sandbox since it's the only branch that contains the annotation support needed by Geronimo. A committer responded that he will think about maintaining a patchset with this annotation support. See http://tinyurl.com/2enw25 How can we work it around? Shall we put Tomcat codebase into our repo and maintain ourselves or start the G-T integration over with the newest trunk bits? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526802 ] Donald Woods commented on GERONIMO-2964: Yep, the XML needs to be updated to include 2.0.2-SNAPSHOT as a valid target. You can either host your own copy of the 2.0.1 plugin (which I do for some testing) or apply your patch onto a copy of the Geronimo 2.0.1 source and rebuild it (which is actually how I originally tested the first patch that was submitted.) Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Priority: Minor Fix For: 1.2, 2.1 Attachments: g2964.war, GERONIMO-2964-combined.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Default server log level
I agree that we should change it from ERROR to INFO. I think any change in log4j is on the fly, i.e. you can change it any time and you don't have to restart the server to pick up the change. Lin Prasad Kashyap wrote: I don't mind if INFO is the default log level. It would be nice if we can also change it 1. during Geronimo startup. 2. during runtime. Possible ? Cheers Prasad On 9/11/07, Kevan Miller [EMAIL PROTECTED] wrote: The intent of this thread is to discuss the default log level for the Geronimo server. I'd like to limit the discussion to the near-term (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging code. I'd like to see more structure and consistency in our logging. However, that's not a 2.0.x issue. The current default log level for a Geronimo 2.0.1 server is ERROR. IMO, this is too restrictive. I think we should set the default to INFO. This will make our server logging more verbose. However, I'd rather have too much information, rather than too little. I think our default target audience should be application developers and new users evaluating Geronimo. Currently, these users are forced to configure log levels to INFO, so that they can obtain necessary information for building and deploying applications on Geronimo. This information should be available by default, not requiring configuration... Users who want to limit the logging output can reconfigure the default logging levels, once they are more comfortable with Geronimo. Comments? --kevan
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.0.0
Hi Donalds, Yes now that all the License files have been fixed (thanks to Kevan) I plan on another vote later today. Thanks Donald Woods wrote: Tim, how is the 2.0.0 plugin updates coming? Do you have an outlook for when we'll be ready for another RC vote? -Donald Kevan Miller wrote: Hey Tim, Apologies for my slow review of the Eclipse plugin. Reviewing the binary distribution, it looks like we are missing license and notice information for xpp3. There may be a few more notices missing, also. With your permission, I'll make updates to the license and notice files in branches/2.0.0... --kevan -- Thanks, Tim McConnell
[DISCUSS] Move J2G from sandbox to devtools
Given all of the work and interest in the J2G tool, I would like to move the current J2G files from sandbox/j2g to devtools/trunk/j2g, so we can start working towards an official release of the tool. Does this require a Vote first or does the CTR process apply here, as the code is already in our svn repo? -Donald smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] Move J2G from sandbox to devtools
Yes! I am all for this, especially so we can progress it onto the Development Tools section of the Geronimo site to make it more noticeable and easily accessible to people interested in migrating applications, as right now the only way to download it or even be aware of it is by digging through our wiki. On 9/12/07, Donald Woods [EMAIL PROTECTED] wrote: Given all of the work and interest in the J2G tool, I would like to move the current J2G files from sandbox/j2g to devtools/trunk/j2g, so we can start working towards an official release of the tool. Does this require a Vote first or does the CTR process apply here, as the code is already in our svn repo? -Donald -- Erik B. Craig
Re: [DISCUSS] Move J2G from sandbox to devtools
On 9/12/07, Donald Woods [EMAIL PROTECTED] wrote: Does this require a Vote first or does the CTR process apply here, as the code is already in our svn repo? I'd say it merely requires lazy consensus where you declare your intent (already done) and after a couple of days (say 72 hours) commit it unless someone objects. It's a good practice to call a vote (after a discussion) and again after 72 hours tally it and act accordingly. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [DISCUSS] Move J2G from sandbox to devtools
Sounds good. I'll give everyone a few days to discuss it and then call a Vote. Thanks. -Donald Jacek Laskowski wrote: On 9/12/07, Donald Woods [EMAIL PROTECTED] wrote: Does this require a Vote first or does the CTR process apply here, as the code is already in our svn repo? I'd say it merely requires lazy consensus where you declare your intent (already done) and after a couple of days (say 72 hours) commit it unless someone objects. It's a good practice to call a vote (after a discussion) and again after 72 hours tally it and act accordingly. Jacek smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] Move J2G from sandbox to devtools
The tool seems to already be getting some attention from users in the community. I think, moving it out of sandbox and into devtools might increase the interest in it. That seems like a good thing to me. -Jason Warner On 9/12/07, Donald Woods [EMAIL PROTECTED] wrote: Sounds good. I'll give everyone a few days to discuss it and then call a Vote. Thanks. -Donald Jacek Laskowski wrote: On 9/12/07, Donald Woods [EMAIL PROTECTED] wrote: Does this require a Vote first or does the CTR process apply here, as the code is already in our svn repo? I'd say it merely requires lazy consensus where you declare your intent (already done) and after a couple of days (say 72 hours) commit it unless someone objects. It's a good practice to call a vote (after a discussion) and again after 72 hours tally it and act accordingly. Jacek
[jira] Commented: (GERONIMO-3461) Disable MEJB gbean in the default assemblies until G3456 is fixed
[ https://issues.apache.org/jira/browse/GERONIMO-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526812 ] Donald Woods commented on GERONIMO-3461: Background info on this temp change - Original Message Subject: MEJB Security Alert Date: Thu, 6 Sep 2007 06:46:21 -0700 (PDT) From: Anita Kulshreshtha [EMAIL PROTECTED] Reply-To: dev@geronimo.apache.org To: dev@geronimo.apache.org All, We have discovered a security vulnerability in Geronimo, where the management EJB (MEJB) allows unchallenged access to Geronimo internals. A temporary workaround is to make the following modifications to the configuration file at GERONIMO_HOME/var/config.xml. This will disable MEJB. module name=org.apache.geronimo.configs/openejb/2.0.1/car gbean name=EJBNetworkService . /gbean gbean load=false name=ejb/mgmt/MEJB/ /module We will be releasing a new version soon to control access to MEJB in a more secure way. This issue will be tracked in https://issues.apache.org/jira/browse/GERONIMO-3456 Thanks Anita Disable MEJB gbean in the default assemblies until G3456 is fixed - Key: GERONIMO-3461 URL: https://issues.apache.org/jira/browse/GERONIMO-3461 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0.1, 2.1 Reporter: Donald Woods Assignee: Donald Woods Fix For: 2.0.2, 2.1 Temporarily disable the MEJB bean due to the security exposure found by Anita, until GERONIMO-3456 is properly fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Move J2G from sandbox to devtools
On Sep 12, 2007, at 10:21 AM, Donald Woods wrote: Given all of the work and interest in the J2G tool, I would like to move the current J2G files from sandbox/j2g to devtools/trunk/j2g, so we can start working towards an official release of the tool. Does this require a Vote first or does the CTR process apply here, as the code is already in our svn repo? No vote is required. Discuss it (like you are doing) and barring objections, do it... My 2 cents -- I agree that it is a good thing to do... --kevan
[jira] Created: (GERONIMO-3468) Links broken through Ajp13.
Links broken through Ajp13. --- Key: GERONIMO-3468 URL: https://issues.apache.org/jira/browse/GERONIMO-3468 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.0.1 Environment: Linux 2.6.21-gentoo-r4 #1 SMP Wed Jul 25 22:03:40 EDT 2007 i686 Pentium III (Katmai) GenuineIntel GNU/Linux apache-2.2.6 mod_jk-1.2.23 sun-jdk-1.5.0.12 Reporter: Aleksandr Tarutin When running behind apache through the Ajp13 connector the 'edit' and 'usage' links on the 'Database Pools' page in the console don't work and just return to the 'Database Pools' page. This happens in Geronimo with Jetty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-193) Runs ping and throws java.lang.SecurityException during Geronimo server startup.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R reassigned GERONIMODEVTOOLS-193: Assignee: Shiva Kumar H R (was: Tim McConnell) Runs ping and throws java.lang.SecurityException during Geronimo server startup. Key: GERONIMODEVTOOLS-193 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Windows XP, Eclipse 3.3, WTP 2.0, Geronimo server 2.0.1, Sun JDK 1.5.0_11 Reporter: Kan Ogawa Assignee: Shiva Kumar H R Hi, While launching Geronimo server on Eclipse, a ping runs in async and the server startup sometimes fails. This server hostname is localhost. Eclipse error log: java.lang.SecurityException: Invalid login at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:73) at javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:214) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:181) 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:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2239) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:271) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.getServerConnection(GeronimoServerBehaviourDelegate.java:689) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.getKernel(GeronimoServerBehaviour.java:73) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.isKernelAlive(GeronimoServerBehaviour.java:93) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.isFullyStarted(GeronimoServerBehaviour.java:113) at org.apache.geronimo.st.core.PingThread.run(PingThread.java:75) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Geronimo Eclipse Plugin 2.0.0
Hi, this particular vote thread has been canceled primarily due missing License and Notice files. Those have now been fixed and a new RC vote will be forthcoming very soon. Thanks for you patience. Tim McConnell wrote: Hi, Please review and vote on the release of the Geronimo Eclipse Plugin 2.0.0 (to correspond with the Geronimo 2.0.1 Server release): The deployable zip file is here: http://people.apache.org/~mcconne/releases/g-eclipse-plugin-2.0.0-deployable.zip The current svn location is here: https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.0.0 The future svn location will be here: https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.0.0 The vote will conclude at 2:00 PM EST on Thursday, September 6th. -- Thanks, Tim McConnell
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526820 ] Anita Kulshreshtha commented on GERONIMO-2964: -- I wish we had a system where one could say version 2.* in geronimo-plugin.xml, and the plugin installer would download artifacts using the server version. geronimo-version in g-plugin.xml could be easily filtered to generate a version corresponding to the server the plugin is being downloaded to. Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Priority: Minor Fix For: 1.2, 2.1 Attachments: g2964.war, GERONIMO-2964-combined.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Plugin progress
On 9/11/07, David Jencks [EMAIL PROTECTED] wrote: 1. While reviewing config poms I saw some suspicious dependencies. Axis and Axis2 depend on openejb which subverts any attempt to run axis web services on a minimal server. The openejb-deployer requires openejb to be running which subverts any attempt to deploy offline while another server is running on the same machine (port conflicts). I'll take a look at this again. Here's some background info: http://marc.info/?l=geronimo-devm=117166218232083w=2 Jarek
[jira] Commented: (GERONIMODEVTOOLS-193) Runs ping and throws java.lang.SecurityException during Geronimo server startup.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526823 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-193: -- Thanks Kan Ogawa for your observations debugging :) Please see the 12-Sep IRC discussions between shivahr and mcconne http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20070912 for further discussions on this. Runs ping and throws java.lang.SecurityException during Geronimo server startup. Key: GERONIMODEVTOOLS-193 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Windows XP, Eclipse 3.3, WTP 2.0, Geronimo server 2.0.1, Sun JDK 1.5.0_11 Reporter: Kan Ogawa Assignee: Shiva Kumar H R Hi, While launching Geronimo server on Eclipse, a ping runs in async and the server startup sometimes fails. This server hostname is localhost. Eclipse error log: java.lang.SecurityException: Invalid login at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:73) at javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:214) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:181) 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:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2239) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:271) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.getServerConnection(GeronimoServerBehaviourDelegate.java:689) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.getKernel(GeronimoServerBehaviour.java:73) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.isKernelAlive(GeronimoServerBehaviour.java:93) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.isFullyStarted(GeronimoServerBehaviour.java:113) at org.apache.geronimo.st.core.PingThread.run(PingThread.java:75) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526830 ] Vamsavardhana Reddy commented on GERONIMO-2964: --- Updating geronimo-plugin.xml in servlet-examples-tomcat-2.0.1.car file to include 2.0.2-SNAPSHOT as a valid version means we have a new plugin artifact. I have done exactly that and tried to install the plugin on Geronimo Tomcat server built from branches\2.0 WITHOUT any patches for the current JIRA. I ended up with an InvalidConfigurationException. Looks like these plugin artifacts built for 2.0.1 won't install on 2.0.2 without having to rebuild those for 2.0.2. I am wondering if compatibility is really a concern!!! Output from command line deployer given below: C:\geronimo-tomcat6-jee5-2.0.2-SNAPSHOTbin\deploy.bat install-plugin c:\temp\se rvlet-examples-tomcat-2.0.1-cooked.car Using GERONIMO_BASE: C:\geronimo-tomcat6-jee5-2.0.2-SNAPSHOT Using GERONIMO_HOME: C:\geronimo-tomcat6-jee5-2.0.2-SNAPSHOT Using GERONIMO_TMPDIR: var\temp Using JRE_HOME:D:\T42\SUNJDK150\jre Username: system Password: *** Checking for status every 1000ms: Finished downloading org.apache.geronimo.configs/servlet-examples-tomcat/2.0.1/c ar (192 kB) (100%) Installation Complete! Used existing: org.apache.geronimo.configs/jasper//car Used existing: org.apache.geronimo.configs/tomcat6//car Downloaded 192 kB in 1s (192 kB/s) Now starting org.apache.geronimo.configs/servlet-examples-tomcat/2.0.1/car... org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronim o.configs/servlet-examples-tomcat/2.0.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConf iguration(SimpleConfigurationManager.java:325) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConf iguration(SimpleConfigurationManager.java:278) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConf iguration(SimpleConfigurationManager.java:253) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConf iguration(KernelConfigurationManager.java:111) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastCla ssByCGLIB$$b117102f.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: 239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.in voke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: 239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBrid ge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImp l.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784 ) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnecti onImpl.java:1408) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectio nImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run (RMIConnectionImpl.java:1245) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(R MIConnectionImpl.java:1348) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImp l.java:782) at sun.reflect.GeneratedMethodAccessor211.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at
Re: svn commit: r573772 - in /tomcat: sandbox/gdev6x/ trunk/
On Sep 12, 2007, at 7:44 AM, Jacek Laskowski wrote: On 9/8/07, Paul McMahan [EMAIL PROTECTED] wrote: I raised a concern about moving trunk to sandbox since it's the only branch that contains the annotation support needed by Geronimo. A committer responded that he will think about maintaining a patchset with this annotation support. See http://tinyurl.com/2enw25 How can we work it around? Shall we put Tomcat codebase into our repo and maintain ourselves or start the G-T integration over with the newest trunk bits? Well, we already use a patched version of Tomcat and distribute the binary in our repository dir. There was discussion about releasing a suitably named binary (rather than maintaining in our svn tree). Don't think that anyone has tackled this, yet. Continuing on this patch should give the Tomcat community time to make amends... --kevan
Re: [jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
Anita, there was some discussion about supporting wildcards in the Geronimo version numbers a while back you might be interested in seeing. http://www.nabble.com/1.1-Candidate-releases-available- tf1746400s134.html#a4765468 Best wishes, Paul On Sep 12, 2007, at 11:31 AM, Anita Kulshreshtha (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-2964? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12526820 ] Anita Kulshreshtha commented on GERONIMO-2964: -- I wish we had a system where one could say version 2.* in geronimo-plugin.xml, and the plugin installer would download artifacts using the server version. geronimo-version in g-plugin.xml could be easily filtered to generate a version corresponding to the server the plugin is being downloaded to. Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/ GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Priority: Minor Fix For: 1.2, 2.1 Attachments: g2964.war, GERONIMO-2964-combined.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat- workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-193) Runs ping and throws java.lang.SecurityException during Geronimo server startup.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526837 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-193: -- This is fixed in branches\2.0.0. Will however leave the JIRA open for better fixing in trunk. Kan Ogawa, The eclipse plug-in which Tim is going to put up for vote later today will have the fix for this. Can you please give it a try and verify that the problem is fixed? Runs ping and throws java.lang.SecurityException during Geronimo server startup. Key: GERONIMODEVTOOLS-193 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Windows XP, Eclipse 3.3, WTP 2.0, Geronimo server 2.0.1, Sun JDK 1.5.0_11 Reporter: Kan Ogawa Assignee: Shiva Kumar H R Hi, While launching Geronimo server on Eclipse, a ping runs in async and the server startup sometimes fails. This server hostname is localhost. Eclipse error log: java.lang.SecurityException: Invalid login at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:73) at javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:214) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:181) 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:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2239) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:271) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.getServerConnection(GeronimoServerBehaviourDelegate.java:689) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.getKernel(GeronimoServerBehaviour.java:73) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.isKernelAlive(GeronimoServerBehaviour.java:93) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.isFullyStarted(GeronimoServerBehaviour.java:113) at org.apache.geronimo.st.core.PingThread.run(PingThread.java:75) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-193) Runs ping and throws java.lang.SecurityException during Geronimo server startup.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-193: - Affects Version/s: (was: 2.0) 2.1 Fix Version/s: 2.1 A temp fix has been committed into branches\2.0.0 until GERONIMO-3467 gets fixed. A more elegant fix should be worked out for trunk. Runs ping and throws java.lang.SecurityException during Geronimo server startup. Key: GERONIMODEVTOOLS-193 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1 Environment: Windows XP, Eclipse 3.3, WTP 2.0, Geronimo server 2.0.1, Sun JDK 1.5.0_11 Reporter: Kan Ogawa Assignee: Shiva Kumar H R Fix For: 2.1 Hi, While launching Geronimo server on Eclipse, a ping runs in async and the server startup sometimes fails. This server hostname is localhost. Eclipse error log: java.lang.SecurityException: Invalid login at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:73) at javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:214) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:181) 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:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2239) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:271) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.getServerConnection(GeronimoServerBehaviourDelegate.java:689) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.getKernel(GeronimoServerBehaviour.java:73) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.isKernelAlive(GeronimoServerBehaviour.java:93) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.isFullyStarted(GeronimoServerBehaviour.java:113) at org.apache.geronimo.st.core.PingThread.run(PingThread.java:75) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3469) From console: database pool doesn't work well if the name contains a / like jdbc/EmployeeDataSource
From console: database pool doesn't work well if the name contains a / like jdbc/EmployeeDataSource --- Key: GERONIMO-3469 URL: https://issues.apache.org/jira/browse/GERONIMO-3469 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: databases Affects Versions: 2.0.1 Environment: winxp + Sun JDK 1.5 Reporter: Lin Sun 1) If I create a database pool called jdbc/EmployeeDataSource, I won't be able to delete it from the database pool portlet page. 2) Also, while creating a new database pool, it seems not giving the option to have different input boxes for the artifact name and the database pool name. They are in the same input box. This was not true for previous releases IIRC. For example, if I name the database pool jdbc/EmployeeDataSource, the full artifact name will be console.dbpool/jdbc%2FEmployeeDatasource/1.0/rar. This is undesired and error prune, as I don't want that / in the artifact name. Seems fixing No. 2 may fix No. 1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Move J2G from sandbox to devtools
+1 - I agree this is a good thing to do. Let me know if you need any help here. Lin Donald Woods wrote: Sounds good. I'll give everyone a few days to discuss it and then call a Vote. Thanks. -Donald Jacek Laskowski wrote: On 9/12/07, Donald Woods [EMAIL PROTECTED] wrote: Does this require a Vote first or does the CTR process apply here, as the code is already in our svn repo? I'd say it merely requires lazy consensus where you declare your intent (already done) and after a couple of days (say 72 hours) commit it unless someone objects. It's a good practice to call a vote (after a discussion) and again after 72 hours tally it and act accordingly. Jacek
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526884 ] Donald Woods commented on GERONIMO-2964: Yep, I was afraid of that Guess we really need to work on Plugin compatibility for the 2.1 release, given everything is becoming a plugin :-) If it's true that none of the 2.0.1 geronimo-example plugins work on a 2.0.2-SNAPSHOT server, then I would be in favor of including this fix, as backwards compatibility would be broken without it anyway... :-( Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Priority: Minor Fix For: 1.2, 2.1 Attachments: g2964.war, GERONIMO-2964-combined.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
Ah! the long summer vacation.. Now we are at 2.0.1. Is all that stuff already implemented? Thanks Anita --- Paul McMahan [EMAIL PROTECTED] wrote: Anita, there was some discussion about supporting wildcards in the Geronimo version numbers a while back you might be interested in seeing. http://www.nabble.com/1.1-Candidate-releases-available- tf1746400s134.html#a4765468 Best wishes, Paul On Sep 12, 2007, at 11:31 AM, Anita Kulshreshtha (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-2964? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12526820 ] Anita Kulshreshtha commented on GERONIMO-2964: -- I wish we had a system where one could say version 2.* in geronimo-plugin.xml, and the plugin installer would download artifacts using the server version. geronimo-version in g-plugin.xml could be easily filtered to generate a version corresponding to the server the plugin is being downloaded to. Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/ GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Priority: Minor Fix For: 1.2, 2.1 Attachments: g2964.war, GERONIMO-2964-combined.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat- workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/
[jira] Updated: (GERONIMO-3461) Disable MEJB gbean in the default assemblies until G3456 is fixed
[ https://issues.apache.org/jira/browse/GERONIMO-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3461: --- Affects Version/s: (was: 2.1) Fix Version/s: (was: 2.1) Disable MEJB gbean in the default assemblies until G3456 is fixed - Key: GERONIMO-3461 URL: https://issues.apache.org/jira/browse/GERONIMO-3461 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0.1 Reporter: Donald Woods Assignee: Donald Woods Fix For: 2.0.2 Temporarily disable the MEJB bean due to the security exposure found by Anita, until GERONIMO-3456 is properly fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3461) Disable MEJB gbean in the default assemblies until G3456 is fixed
[ https://issues.apache.org/jira/browse/GERONIMO-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-3461. -- Resolution: Fixed Committed revision 575052 in branches/2.0 (aka. 2.0.2-SNAPSHOT) Disable MEJB gbean in the default assemblies until G3456 is fixed - Key: GERONIMO-3461 URL: https://issues.apache.org/jira/browse/GERONIMO-3461 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0.1 Reporter: Donald Woods Assignee: Donald Woods Fix For: 2.0.2 Temporarily disable the MEJB bean due to the security exposure found by Anita, until GERONIMO-3456 is properly fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3456) Make MEJB security configurable
[ https://issues.apache.org/jira/browse/GERONIMO-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3456: --- Affects Version/s: 2.1 Fix Version/s: 2.1 Fix needs to go into trunk, too... Make MEJB security configurable --- Key: GERONIMO-3456 URL: https://issues.apache.org/jira/browse/GERONIMO-3456 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, security Affects Versions: 2.0.1, 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Priority: Critical Fix For: 2.0.2, 2.1 Currently access to MEJB is not controlled. Add configurable security for MEJB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-202) A geronimo installation was detected, however the version could not be verified warning while adding Geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-202. -- Resolution: Fixed Assignee: Tim McConnell (was: Shiva Kumar H R) Fixed in r575055 to ensure that the possible locations for the geronimo-system jar is searched to support Geronimo 1.x and 2.x versions A geronimo installation was detected, however the version could not be verified warning while adding Geronimo 2.0.1 - Key: GERONIMODEVTOOLS-202 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Shiva Kumar H R Assignee: Tim McConnell Priority: Minor Fix For: 2.0 Attachments: GERONIMODEVTOOLS-202-temp.patch Initial debugging shows that this is due to: org.apache.geronimo.st.core.GeronimoRuntimeDelegate.detectVersion() method returning null, which in turn is due to missing geronimo-system-*.jar file in GERONIMO-HOME\lib directory of Geronimo 2.0.1 installation. geronimo-system-2.0.1.jar can however be found GERONIMO-HOME\repository\org\apache\geronimo\modules\geronimo-system\2.0.1 directory of AG 2.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3449) HSQLDB embeded database URL can hang Geronimo web console
[ https://issues.apache.org/jira/browse/GERONIMO-3449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526897 ] Lin Sun commented on GERONIMO-3449: --- think I hit this today too with derby embed XA. so this seems to be a generic prob, nothing unique to HSQLDB. HSQLDB embeded database URL can hang Geronimo web console - Key: GERONIMO-3449 URL: https://issues.apache.org/jira/browse/GERONIMO-3449 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Environment: Windows / Eclipse 3.3 / HSQLDB embeded / FireFox 2 Reporter: matthieu Moiroux HSQLDB embeded URL contains file path. If enter database URL with backslash (in Geronimo database pool wizard), Geronimo console goes to a empty screen. Replacing backslash by slash repair it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3470) Setting system properties through the deployment plan fails.
Setting system properties through the deployment plan fails.
Key: GERONIMO-3470
URL: https://issues.apache.org/jira/browse/GERONIMO-3470
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: deployment
Affects Versions: 2.0.1
Reporter: Aleksandr Tarutin
The following behavior observed when defining system properties for deploying a
WAR application in deployment plan using the snipped below:
{code}
gbean name=ServerSystemProperties
class=org.apache.geronimo.system.properties.SystemProperties
attribute name=systemProperties
myVar=myValue
/attribute
/gbean
{code}
During the deployment and the first start the property is present and
everything works as it should.
But the property is not set during any consecutive starts of the application
including when the whole container is restarted.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-2964: -- Attachment: GERONIMO-2964-combined-new.patch GERONIMO-2964-combined-new.patch: Now that plugin backward compatibility is not an issue, I guess this fix can go into 2.0.2 as well. Here is a patch to allow a work-dir tag in web.xml. For G/Jetty, the work-dir is created under var/jetty and for G/Tomcat, the work-dir is created under var/catalina with the specified name. Once again, the patch does not address renaming the schema's to new versions which is to be addressed before committing the patch. I have verified that the patch works on branches\2.0 without any test failures. And the distributiions built address the issue at hand. Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Priority: Minor Fix For: 1.2, 2.1 Attachments: g2964.war, GERONIMO-2964-combined-new.patch, GERONIMO-2964-combined.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-193) Runs ping and throws java.lang.SecurityException during Geronimo server startup.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526957 ] Kan Ogawa commented on GERONIMODEVTOOLS-193: Thanks, Shiva. I have verified your fix and understood that this fix is temporary step. Of course, I think that this issue should not become closed status yet until GERONIMO-3467 gets fixed. Runs ping and throws java.lang.SecurityException during Geronimo server startup. Key: GERONIMODEVTOOLS-193 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1 Environment: Windows XP, Eclipse 3.3, WTP 2.0, Geronimo server 2.0.1, Sun JDK 1.5.0_11 Reporter: Kan Ogawa Assignee: Shiva Kumar H R Fix For: 2.1 Hi, While launching Geronimo server on Eclipse, a ping runs in async and the server startup sometimes fails. This server hostname is localhost. Eclipse error log: java.lang.SecurityException: Invalid login at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:73) at javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:214) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:181) 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:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2239) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:271) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.getServerConnection(GeronimoServerBehaviourDelegate.java:689) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.getKernel(GeronimoServerBehaviour.java:73) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.isKernelAlive(GeronimoServerBehaviour.java:93) at org.apache.geronimo.st.v20.core.GeronimoServerBehaviour.isFullyStarted(GeronimoServerBehaviour.java:113) at org.apache.geronimo.st.core.PingThread.run(PingThread.java:75) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3471) Enabling Web Server Manager statistics appears to have no effect in admin console
Enabling Web Server Manager statistics appears to have no effect in admin console -- Key: GERONIMO-3471 URL: https://issues.apache.org/jira/browse/GERONIMO-3471 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.0.1 Reporter: Kevan Miller Priority: Minor Fix For: 2.0.x, 2.1 Aleksandr reports that clicking enable statistics on the Web Server page of the admin console has no effect. I tested on a Jetty server and it indeed does not work (or has no visible impact). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526964 ] Anita Kulshreshtha commented on GERONIMO-2964: -- Have you tried changing/fixing the SUID for SerializedGBeanState? Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Priority: Minor Fix For: 1.2, 2.1 Attachments: g2964.war, GERONIMO-2964-combined-new.patch, GERONIMO-2964-combined.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3471) Enabling Web Server Manager statistics appears to have no effect in admin console
[ https://issues.apache.org/jira/browse/GERONIMO-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526965 ] Anita Kulshreshtha commented on GERONIMO-3471: -- The Jetty statistics are not hooked up. There is an open issue for this - http://issues.apache.org/jira/browse/GERONIMO-2775 Enabling Web Server Manager statistics appears to have no effect in admin console -- Key: GERONIMO-3471 URL: https://issues.apache.org/jira/browse/GERONIMO-3471 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0.1 Reporter: Kevan Miller Priority: Minor Fix For: 2.0.x, 2.1 Aleksandr reports that clicking enable statistics on the Web Server page of the admin console has no effect. I tested on a Jetty server and it indeed does not work (or has no visible impact). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: question about servicemix 3.1.2 release
Thanks Guillaume Cheers Freeman Guillaume Nodet wrote: I have updated the releasing notes to something that I hope will work ;-) See http://cwiki.apache.org/confluence/display/SM/Release+Guide If you have any questions, just yell ! On 9/12/07, Nodet Guillaume [EMAIL PROTECTED] wrote: On Sep 12, 2007, at 8:46 AM, Freeman Fang wrote: Hi all, When are we going to release servicemix 3.1.2? As a new commiter in servicemix team, I'd like to know how is the release process looks like. If possible, shall I be release manager of this time? :-) Yeah of course you can :-) There are some instructions available at http://incubator.apache.org/servicemix/release-guide.html but these are a bit outdated, so we'll have to update those (and maven can not really be used for creating the release)... Let me have a breakfast and write something more accurate... Any suggestion is appreciated. Best Regards Freeman -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Plugin progress
With a little more work I'm now able to start with framework and add jetty, jasper, and jetty-admin and get a working web console I guess maybe the next step is to make the car-maven-plugin:assemble use the plugin-install features so it builds up the config.xml and other config files. One or more gshell commands to deal with plugins would be pretty nice too. It might be worthwhile to try to figure out how we want to present this to users. We should be at the point where if they package their applications as plugins then by installing those plugins into g- framework you get a minimal server for running those applications. thanks david jencks On Sep 12, 2007, at 3:34 AM, David Jencks wrote: I think I resolved most of the resolve to wrong version problems (basically #3 below), and I managed to start with framework and deploy plugins until I got a working web console (jetty, and the old non-modular console). There are still a bunch of weirdnesses going on such as openejb having NCDFE but this seems to me like a significant step towards plugin usability. There may be other problems such as I'm not sure the gbean configs are getting copied into config.xml properly. I'll keep looking at this stuff. thanks david jencks On Sep 11, 2007, at 12:13 AM, David Jencks wrote: I've now updated enough of the configs so we can see if we can assemble them into a server. It would be great if some one else could take a look at some of the remaining ones, list at the end of this email. To get your own list of un-cleaned-up configs build g, fire it up, and run search-plugins from the command line deployer: the no category ones aren't done yet. To provide a more reasonable sized testbed for assembling servers out of plugins I also shrank geronimo-framework to the minimum possible size: rmi-naming plus enough security to enable the command line deployer to connect to it. So, while some parts of plugin installation work, overall it doesn't. I keep seeing plugin installation pull in the wrong version of jars and cars and sometimes not find jars that are present in the local maven repo. Here are the problems I've noted so far, in order of discovery: 1. While reviewing config poms I saw some suspicious dependencies. Axis and Axis2 depend on openejb which subverts any attempt to run axis web services on a minimal server. The openejb- deployer requires openejb to be running which subverts any attempt to deploy offline while another server is running on the same machine (port conflicts). 2. Figuring out which repository to look in doesn't work yet. While what is specified in the geronimo-plugin.xml and geronimo- plugins.xml does appear to be honored, using these isn't compatible with developing and testing plugins, since while a plugin is being worked on you want to use only your local repo but after its published you don't (unless perhaps its is hooked up to some kind of maven proxy) I wonder if having a default repo configured in the plugin installer system would work, or perhaps merging the repos at the end of geronimo-plugins.xml with those in each geronimo-plugin.xml. 3. version resolution appears to have some serious problems. I think pretty much all of the geronimo-plugin.xmls contain versions for every jar (something I'm hoping to change) but I ran into a lot of problems. First most of the artifacts got resolved to the 2.0.1 released artifacts which didn't work because the car files didn't have valid geronimo-plugin.xmls in them. After I removed all my 2.0.1 artifacts things were slightly better until I got to something that wouldn't resolve at all, xbean-reflect 3.2- SNAPSHOT. The jar is in my local repo but for some reason it wasn't found. 4. I am doubting more and more that the current requires and obsoletes data are appropriate. For instance, most of the web apps require jetty (or tomcat, pick your flavor). IMO this is the wrong idea. If I want to install one of these web apps, it should install the web server if it's not already present. What I think is more appropriate would be if I'm trying to install a jetty web app and tomcat is installed it should complain: if no other web server is installed then it should install jetty for me. 5. Trying to extract information about what went wrong is really hard and unpleasant. 6. With the CTS configs that happen to be on my machine, there are 93. This is a lot to wade through. We need a better way of organizing them, at least on the command line. Perhaps providing a list of categories to pick from, then the plugins from that category, would be more manageable. Also a deploy this from this maven repo command would be good: this might exist but I haven't found it yet. thanks david jencks no category Geronimo Configs :: Welcome app Jetty 8 : (2.1-SNAPSHOT) Geronimo Configs :: Unavailable
[VOTE] Release Geronimo Eclipse Plugin 2.0.0 (RC2)
Hi, Please review and vote on the release of the Geronimo Eclipse Plugin 2.0.0 RC2 (to correspond with the Geronimo 2.0.1 Server release). Changes from RC1 include: 1. Updates to License/Notice files 2. Numerous JIRA fixes The deployable zip file is here: http://people.apache.org/~mcconne/releases/RC2/g-eclipse-plugin-2.0.0-deployable-RC2.zip The update site zip file is here: http://people.apache.org/~mcconne/releases/RC2/g-eclipse-plugin-2.0.0-updatesite-RC2.zip The current svn location is here (revision number 575055): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.0.0 The future svn location will be here: https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.0.0 There is a rudimentary set of install instructions available at the URL below that will hopefully describe the necessary prereqs and steps required to install and run the plugin. I'm in the process of creating Wiki pages for the Plugin Release Process and General Information about the plugin, and would like to use this document as a base for the General Information page. So, I would be very interested in getting feedback on these instructions: http://people.apache.org/~mcconne/releases/RC2/Geronimo_Eclipse_Plugin_2.0.0_Instructions-RC2.txt Additionally, there is an ant build.xml file that can be used to download all the prereqs for the plugin. It is documented in the instructions. Finally, I've created a Staging Site that used to test the update manager functions of Eclipse for downloading both the plugin itself and the Geronimo Server. This is also documented in the instructions. The vote will conclude at 11:00 PM EST on Saturday, September 15th. -- Thanks, Tim McConnell
[DISCUSS] Release Geronimo Eclipse Plugin 2.0.0 (RC2)
Start of discussion thread. -- Thanks, Tim McConnell
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.0.0 (RC2)
Looks good. Thanks Tim. Attached are some minor updates/feedback on your instructions. On 9/12/07, Tim McConnell [EMAIL PROTECTED] wrote: Start of discussion thread. -- Thanks, Tim McConnell === Step #1 -- Install prerequisites=== The Geronimo Eclipse Plugin 2.0.0 has a number of prerequisites that must be installed prior to the installation of the plugin itself. These are necessary to establish the proper Eclipse installation. They are: 1 -- Europa (also known as Eclipse 3.3), which is platform specific 2 -- Web Tools Platform (WTP) 2.0.1 3 -- Data Tools Platform (DTP) 1.5 4 -- Eclipse Modeling Framework (EMF) 2.3 5 -- Graphical Editing Framework (GEF) 3.3 You can manually download the latest versions of these artifacts but it is somewhat cumbersome. Instead I've created an ant script (that is based on the one used to build the plugin) that you can use that will download and unzip everything for you. You can get it from here: http://people.apache.org/~mcconne/releases/RC2/build.xml After you download it somewhere (preferably in a temp subdirectory) you can just invoke it for your specific platform using one of these three commands: ant win32 ant linux ant macos It will create an /org/EUROPA/eclipse/3.3 subdirectory with all the downloaded artifacts and an /EUROPA/eclipse subdirectory where everything has been unzipped. This is now the Eclipse installation directly you should use to test the Geronimo Eclipse 2.0.0 plugin. If you don't wish to use the ant script it's very important to ensure you have the latest versions of each -- otherwise the plugin will not function correctly. For example, the WTP 2.0.0 release is fairly old and buggy, and our plugin will not function correctly. That is why this ant script downloads and installs the WTP 2.0.1 RC1 artifacts. Now that you have all the prerequisites you can do either of the two scenarios below since each must work and both should emulate how it will be installed and used in the real world. Scenarios #1 and #2 are mutually exclusive though -- do one or the other but not both unless you first delete and recreate your Eclipse installation directory (preferably with the ant script above). === Scenario #1 -- Upzip everything === You can just download the plugin itself and unzip it into the same directory where all the prereqs were installed (e.g., EUROPA/eclipse). If you choose this option you must have an installed version of the Geronimo 2.0.1 server somewhere on your system so that you can define an Geronimo Server configuration. If you've never done this before the steps are fairly straightforward: 1 -- Download the plugin and unzip into your EUROPA/eclipse directory. You can download the plugin from here: http://people.apache.org/~mcconne/releases/RC2/g-eclipse-plugin-2.0.0-deployable-RC2.zip 2 -- Invoke the eclipse executable from your EUROPA/eclipse directory. Select or accept the default workspace. 3 -- Open the Java EE perspective. From within Eclipse: a. Close the Welcome tab b. Select Window -- Open Perspective -- Other -- Java EE You should now be in the Java EE perspective. You can see the open perspective tabs in the upper right-hand corner of your Eclipse workspace. 4 -- Define a new server. From Eclipse select: a. File -- New -- Other -- Server -- Server -- Next -- Apache. At this point you must see the Apache Geronimo v2.0 Server selection or the plugin was not installed/unzipped correctly. b. Select Apache Geronimo v2.0 Server -- Next -- then enter the root directory of your Geronimo server installation -- Next -- Next -- Next -- Finish c. Now in the Java EE perspective you should see the Apache Geronimo v2.0 server (bottom pane, middle tab usually) that you can now start in Eclipse (either right-click on it and select start or select the little green and white arrow on the far right of the server pane). You should then see the console and the familiar server startup messages. d. Right-click on the server and select Launch Geronimo Console to bring up an admin console browser window in eclipse. === Scenario #2 -- Use Staging Site === Alternatively, you can download both the Eclipse Plugin and the Geronimo server from the Staging Site
