Re: Evil windows path limit...
On Jan 20, 2008 11:59 PM, Jason Dillon [EMAIL PROTECTED] wrote: anyone know how close we are to the limit for the repository? I'd like to be able to use longer groupIds to organize plugins, like: Run the following command jar -tf geronimo-jetty6-javaee5-2.1-SNAPSHOT-bin.zip | while read f; do LENGTH=`expr length $f`; echo $LENGTH $f; done | sort -n and got the following (cut to entries above 210 chars): 211 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-jetty/2.1-SNAPSHOT/console-jetty-2.1-SNAPSHOT.car/base-portlets.war/WEB-INF/view/securityrealmman ager/derby/users/addnormal.jsp 211 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-jetty/2.1-SNAPSHOT/console-jetty-2.1-SNAPSHOT.car/base-portlets.war/WEB-INF/view/securityrealmman ager/derby/users/maximized.jsp 211 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-jetty/2.1-SNAPSHOT/console-jetty-2.1-SNAPSHOT.car/base-portlets.war/WEB-INF/view/securityrealmman ager/se/users/addmaximized.jsp 212 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-jetty/2.1-SNAPSHOT/console-jetty-2.1-SNAPSHOT.car/base-portlets.war/WEB-INF/view/securityrealmman ager/derby/groups/addnormal.jsp 212 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-jetty/2.1-SNAPSHOT/console-jetty-2.1-SNAPSHOT.car/base-portlets.war/WEB-INF/view/securityrealmman ager/derby/groups/maximized.jsp 212 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-jetty/2.1-SNAPSHOT/console-jetty-2.1-SNAPSHOT.car/base-portlets.war/WEB-INF/view/securityrealmman ager/se/groups/addmaximized.jsp 213 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/configs/uddi-jetty6/2.1-SNAPSHOT/uddi-jetty6-2.1-SNAPSHOT.car/uddi-db/META-INF/maven/org.tranql/tranql-connector- derby-embed-local/pom.properties 214 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/configs/system-database/2.1-SNAPSHOT/system-database-2.1-SNAPSHOT.car/rar/META-INF/maven/org.tranql/tranql-connec tor-derby-embed-xa/pom.properties 214 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-jetty/2.1-SNAPSHOT/console-jetty-2.1-SNAPSHOT.car/base-portlets.war/WEB-INF/view/securityrealmman ager/derby/users/addmaximized.jsp 215 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-jetty/2.1-SNAPSHOT/console-jetty-2.1-SNAPSHOT.car/base-portlets.war/WEB-INF/view/securityrealmman ager/derby/groups/addmaximized.jsp 215 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-jetty/2.1-SNAPSHOT/console-jetty-2.1-SNAPSHOT.car/portal-driver.war/WEB-INF/config/services/Portl etEntityRegistryService.properties 219 geronimo-jetty6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-jetty/2.1-SNAPSHOT/console-jetty-2.1-SNAPSHOT.car/portal-driver.war/WEB-INF/config/services/Portl etDefinitionRegistryService.properties It appears we're pretty close. It's 255, I believe. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Resolved: (GERONIMO-3766) monitoring agent should be separated into mejb, jmx, and jar utility classes
[ https://issues.apache.org/jira/browse/GERONIMO-3766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen resolved GERONIMO-3766. Resolution: Fixed monitoring agent should be separated into mejb, jmx, and jar utility classes Key: GERONIMO-3766 URL: https://issues.apache.org/jira/browse/GERONIMO-3766 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: monitoring Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Fix For: 2.1 Attachments: geronimo-3766.patch in order to modularize the monitoring agent, I suggest the following breakdown: agent-ejb which will contain anything MEJB related, so that only this will pull in OpenEJB agent-jmx which will have the code for JMX connections agent-jar -which will have the utility classes/functions that are used by both agent-ejb and agent-jmx So, when packaging these JARs into an EAR, agent-ejb + agent-jar will make up the agent MEJB plugin agent-jmx + agent-jar will make up the agent JMX plugin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3772) Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
[ https://issues.apache.org/jira/browse/GERONIMO-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-3772: --- Assignee: Gianny Damour Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor] --- Key: GERONIMO-3772 URL: https://issues.apache.org/jira/browse/GERONIMO-3772 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: dependencies Affects Versions: 2.1 Reporter: YunFeng Ma Assignee: Gianny Damour Fix For: 2.1 Attachments: GERONIMO-3772.patch Reproduce the error: 1. start the server 2. add a local plugin repository or click link Update Repository List 3. shutdown and restart the server and you should get hit by it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3772) Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
[ https://issues.apache.org/jira/browse/GERONIMO-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3772. --- Resolution: Fixed Thanks for having raised this issue Yun Feng. As Geronimo has build-in support for the main Collection sub-classes, see org.apache.geronimo.common.propertyeditor package which is registered as a PropertyEditor search path, GBeanOverride should not write a propertyEditor attribute for attributes having the type of Collection sub-classes. Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor] --- Key: GERONIMO-3772 URL: https://issues.apache.org/jira/browse/GERONIMO-3772 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: dependencies Affects Versions: 2.1 Reporter: YunFeng Ma Assignee: Gianny Damour Fix For: 2.1 Attachments: GERONIMO-3772.patch Reproduce the error: 1. start the server 2. add a local plugin repository or click link Update Repository List 3. shutdown and restart the server and you should get hit by it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Matt, many many thanks for your hard work and long hours/nights you spent working on Geronimo as our PMC Chair and more. I assume you will no more produce the project reports for the Board; however, we are still expecting your performance reports :) Kevan, congratulations and thanks for accepting the responsibilities of PMC Chair! Gianny On 17/01/2008, at 7:10 AM, Matt Hogstrom wrote: Recently I have had several things change personally and I have found it increasingly difficult to keep up with the Geronimo mailing lists on a daily basis. As a result, I did some soul searching and decided that my intentions to stay on top of Geronimo were good but my follow through wasn't This was specifically in regard to being able to respond to people on issues that I needed to do as PMC chair. I tendered my resignation to the Board earlier this week. There was some discussion on the PMC list about a replacement and the PMC unanimously approved Kevan Miller as my successor. The board just approved this request so Kevan now has the mantle for Geronimo as the PMC chair. It is with great pleasure that I announce that Kevan has accepted this responsibility of PMC chair. The beauty is that Kevan has already been doing most of the work of the PMC chair anyway and is the right person going forward. Please give it up for Kevan Miller, VP, Apache Geronimo! I'm still noodling with some performance work as time allows so I'm not gone. I'll prolly continue to nag in my own unique way. Matt
Yoel Spotts is out of the office.
I will be out of the office starting 01/21/2008 and will not return until 02/04/2008. For SP health related questions, please see Rafal Niedzialkowski, James Innes or Jack Smith. Otherwise, I will respond to your email when I return.
Re: 2.1 Release -- Banging the drum
On Jan 20, 2008, at 1:42 PM, Jason Dillon wrote: I'm going to start working on this... looks like there are more problems that I thought, though not hard to fix... just a PITA. --jason On Jan 20, 2008, at 8:13 AM, Kevan Miller wrote: On Jan 19, 2008, at 1:18 PM, Jacek Laskowski wrote: On Jan 18, 2008 3:15 AM, Kevan Miller [EMAIL PROTECTED] wrote: I agree with Jason. We shouldn't be carrying forward the current structure. And, I think we have enough time to fix this problem while we are fixing other issues with the release. Even though I tend to agree I understand the pain of our end users who suffer from working with 2.0.2 when we keep telling them use the unofficial 2.1 release and I wish we could release G 2.1 as soon as possible. No issues should be counted any more. Just go ahead, release and keep working on 2.2 release. Jacek, Let's level-set for a second. From my original note on this subject: On Jan 16, 2008, at 10:27 AM, Kevan Miller wrote: I'd like to set a target of 2 weeks for reviewing and fixing problems. After that would start the branching, final tck, and packaging work. If we feel this might negatively impact post-2.1 development activities. We can consider creating a 2.1 branch sooner... Are you ok with the 2 week target for reviewing the current trunk codebase and resolving issues? The structure of our pom's are one of the issues that I think have been identified in our current codebase. Seems like we can resolve the problem within our 2 week timeframe. So, I'm all for fixing the poms... --kevan
[BUILD] 2.1: Failed for Revision: 613722
Geronimo Revision: 613722 built with tests included
See the full build-2100.log file at
http://geronimo.apache.org/maven/server/binaries/trunk/20080121/build-2100.log
See the unit test reports at
http://geronimo.apache.org/maven/server/binaries/trunk/20080121/unit-test-reports
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/gshell/gshell-parser/1.0-alpha-1/gshell-parser-1.0-alpha-1.jar
35K downloaded
Downloading:
http://download.java.net/maven/1//org.slf4j/jars/slf4j-simple-1.4.3.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/slf4j/slf4j-simple/1.4.3/slf4j-simple-1.4.3.jar
Downloading:
http://repo1.maven.org/maven2/org/slf4j/slf4j-simple/1.4.3/slf4j-simple-1.4.3.jar
7K downloaded
Downloading:
http://download.java.net/maven/1//org.codehaus.plexus/jars/plexus-component-annotations-1.0-alpha-1.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/codehaus/plexus/plexus-component-annotations/1.0-alpha-1/plexus-component-annotations-1.0-alpha-1.jar
Downloading:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-annotations/1.0-alpha-1/plexus-component-annotations-1.0-alpha-1.jar
4K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.geronimo.gshell.support/jars/gshell-common-1.0-alpha-1.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/gshell/support/gshell-common/1.0-alpha-1/gshell-common-1.0-alpha-1.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/gshell/support/gshell-common/1.0-alpha-1/gshell-common-1.0-alpha-1.jar
47K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.geronimo.gshell.support/jars/gshell-i18n-1.0-alpha-1.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/gshell/support/gshell-i18n/1.0-alpha-1/gshell-i18n-1.0-alpha-1.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/gshell/support/gshell-i18n/1.0-alpha-1/gshell-i18n-1.0-alpha-1.jar
9K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.geronimo.gshell.support/jars/gshell-clp-1.0-alpha-1.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/gshell/support/gshell-clp/1.0-alpha-1/gshell-clp-1.0-alpha-1.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/gshell/support/gshell-clp/1.0-alpha-1/gshell-clp-1.0-alpha-1.jar
45K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.geronimo.gshell/jars/gshell-core-1.0-alpha-1.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/gshell/gshell-core/1.0-alpha-1/gshell-core-1.0-alpha-1.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/gshell/gshell-core/1.0-alpha-1/gshell-core-1.0-alpha-1.jar
97K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/geronimo/geronimo/trunk/framework/modules/geronimo-commands/target/classes/META-INF
[INFO] Copying 2 files to
/home/geronimo/geronimo/trunk/framework/modules/geronimo-commands/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 6 source files to
/home/geronimo/geronimo/trunk/framework/modules/geronimo-commands/target/classes
[INFO] [groovy:compile {execution: default}]
[INFO] Compiling 25 Groovy source files to
/home/geronimo/geronimo/trunk/framework/modules/geronimo-commands/target/classes
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/plexus/plexus-maven-plugin/1.3.6-SNAPSHOT/plexus-maven-plugin-1.3.6-20071005.105006-2.pom
Downloading:
http://snapshots.repository.codehaus.org/org/codehaus/plexus/plexus-maven-plugin/1.3.6-SNAPSHOT/plexus-maven-plugin-1.3.6-20071005.105006-2.pom
4K downloaded
[INFO] snapshot org.codehaus.plexus:plexus-cdc:1.0-alpha-11-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot org.codehaus.plexus:plexus-cdc:1.0-alpha-11-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot org.codehaus.plexus:plexus-cdc:1.0-alpha-11-SNAPSHOT: checking
for updates from snapshots.apache.org
[INFO] snapshot org.codehaus.plexus:plexus-cdc:1.0-alpha-11-SNAPSHOT: checking
for updates from codehaus.snapshots
[INFO] snapshot org.codehaus.plexus:plexus-cdc:1.0-alpha-11-SNAPSHOT: checking
for updates from apache.snapshots
Downloading:
http://snapshots.repository.codehaus.org/org/codehaus/plexus/plexus-cdc/1.0-alpha-11-SNAPSHOT/plexus-cdc-1.0-alpha-11-20071001.044407-3.pom
2K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-tools/1.0.8/plexus-tools-1.0.8.pom
953b downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-13/plexus-component-api-1.0-alpha-13.pom
949b downloaded
Downloading:
http://repo1
[jira] Created: (GERONIMO-3773) hostname lookup causes long startup time when offline
hostname lookup causes long startup time when offline - Key: GERONIMO-3773 URL: https://issues.apache.org/jira/browse/GERONIMO-3773 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: CORBA Affects Versions: 2.1 Reporter: Kevan Miller Priority: Minor Fix For: 2.1 Noticed that when running offline (without any network connectivity), the server startup time is much slower. Looks like yoko is trying to resolve the local hostname from a name server. Is this required? can we use a dotted ip address instead? Here's the stack trace: main prio=5 tid=0x01001b80 nid=0xb0801000 runnable [0xb07ff000..0xb0800188] at java.net.Inet6AddressImpl.getHostByAddr(Native Method) at java.net.InetAddress$1.getHostByAddr(InetAddress.java:842) at java.net.InetAddress.getHostFromNameService(InetAddress.java:532) at java.net.InetAddress.getCanonicalHostName(InetAddress.java:503) at org.apache.yoko.orb.OB.Net.getCanonicalHostname(Net.java:49) at org.apache.yoko.orb.OCI.IIOP.AccFactory_impl.create_acceptor(AccFactory_impl.java:153) at org.apache.yoko.orb.OBPortableServer.POAManagerFactory_impl.create_POAManager(POAManagerFactory_impl.java:251) - locked 0x06dbe108 (a java.util.Hashtable) at org.apache.yoko.orb.OBPortableServer.POA_impl.create_POA(POA_impl.java:672) - locked 0x056ad388 (a java.util.Hashtable) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.initialize(TransientNameService.java:139) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.run(TransientNameService.java:115) at org.apache.geronimo.yoko.ORBConfigAdapter.createNameService(ORBConfigAdapter.java:175) at org.apache.geronimo.corba.NameService.doStart(NameService.java:164) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:998) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) - locked 0x06dbaaf0 (a org.apache.geronimo.gbean.runtime.GBeanDependency) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) - locked 0x06dbaaf0 (a org.apache.geronimo.gbean.runtime.GBeanDependency) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:534) - locked 0x05bd8bf8 (a org.apache.geronimo.kernel.config.EditableKernelConfigurationManager) at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at
Re: How to change KeyStore type?
Providing a keystoreType attribute does not seem to be a big deal. But, if the Keystores portlet has to allow creating all types of keystores, it gets really messy. Here is one more observation. *IBMJDK does not allow storing an empty PKCS12 keystore to disk.* This prevents creating an empty PKCS12 keystore and then adding which ever keys and certificates the user wants to. Here is the approach I want to take. Step 1. Provide a keystoreType attribute in FileKeystoreInstance. Step 2. Update KeyStores portlet to allow creation of all keystore types that the JDK allows to store an empty keystore to disk. Step 1 will allow the users to replace a keystore file of one type with that of another type, change the keystoreType in config.xml and get the server running. Step 2 will allow users to manage all keystore types using Keystores portlet and there is no hard-coding of any keystoreType except for geronimo-default keystore which is JKS. Now to some pitfalls. 1. If keystore type other than JKS is in use, the user may not be able to switch JDK's for reasons like PKCS12 keystore created using IBMJDK are not readble using SUNJDK. 2. Though IBMJDK does not allow creating an empty PKCS12 (and a few other types) keystore as a starting point for managing a PKCS12 keystore, the users can always add a PKCS12 keystore to var/security/keystores and the gbean definition to config.xml. This will make the keystore manageable through KeyStores portlet as long as the keystore is not empty. This will require a change in org.apache.geronimo.management.geronimo.KeystoreManager interface, etc. I doubt if we can consider this change for branches\2.0. Comments? ++Vamsi On Jan 18, 2008 1:37 AM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Yes, sure, I fully agree. I've filed GERONIMO-3757 for this issue and now thinking of the patch to the trunk that would provide the necessary customization - unless any objections arise. As of GERONIMO-2015, I think we may close it, as there're objective reasons (stated there by Vamsavardhana Reddy) to not move from JKS on Sun. Vasily -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 1:37 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? I think we should add PKCS12 to Geronimo. If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose what keystore to use? We can specify keystore in configs or choose type from available on current VM. SY, Alexey 2008/1/15, Zakharov, Vasily M [EMAIL PROTECTED]: Hi, all, Is there a way to change the geronimo-default keystore from JKS to, say, PKCS12 without patching the org.apache.geronimo.security.keystore.FileKeystore* classes? That way of patching sources is suggested at GERONIMO-2015, and it works, but it's probably not the best idea. I see the reasons of not making PKCS12 a default keystore type, but what about making it possible to change keystore type using config.xml, without source recompilation? I've browsed through the configuration options of geronimo-security gbean, a found no way for that. Should I provide a patch for that to be possible, would that be appropriate? Thank you! Vasily Zakharov Intel ESSD ---
RE: How to change KeyStore type?
Vamsi, Thanks for the detailed analysis. The problem indeed looks non-trivial. Step 1. This looks pretty simple, and I'm now creating a patch for that. This change seems very important to me, how about getting it to v2.0.3/2.1? Step 2. This change also seems very important, but less critical than the first one, and it requires essential interface changes, so I tend to agree it certainly should wait till 2.1 or later. As of pitfalls, they seem unavoidable. Sure we want compatibility, but any compatibility has its limits. I suppose that changing JDK under a particular running installation of Geronimo is not a feature in great demand, and in a rare case when such a change would be necessary, a keystore conversion could be done manually (e.g. JKS-PKCS12 conversion can be done in Sun, PKCS12-BKS conversion can be done in Harmony etc.) Vasily From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED] Sent: Monday, January 21, 2008 8:23 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? Providing a keystoreType attribute does not seem to be a big deal. But, if the Keystores portlet has to allow creating all types of keystores, it gets really messy. Here is one more observation. IBMJDK does not allow storing an empty PKCS12 keystore to disk. This prevents creating an empty PKCS12 keystore and then adding which ever keys and certificates the user wants to. Here is the approach I want to take. Step 1. Provide a keystoreType attribute in FileKeystoreInstance. Step 2. Update KeyStores portlet to allow creation of all keystore types that the JDK allows to store an empty keystore to disk. Step 1 will allow the users to replace a keystore file of one type with that of another type, change the keystoreType in config.xml and get the server running. Step 2 will allow users to manage all keystore types using Keystores portlet and there is no hard-coding of any keystoreType except for geronimo-default keystore which is JKS. Now to some pitfalls. 1. If keystore type other than JKS is in use, the user may not be able to switch JDK's for reasons like PKCS12 keystore created using IBMJDK are not readble using SUNJDK. 2. Though IBMJDK does not allow creating an empty PKCS12 (and a few other types) keystore as a starting point for managing a PKCS12 keystore, the users can always add a PKCS12 keystore to var/security/keystores and the gbean definition to config.xml. This will make the keystore manageable through KeyStores portlet as long as the keystore is not empty. This will require a change in org.apache.geronimo.management.geronimo.KeystoreManager interface, etc. I doubt if we can consider this change for branches\2.0. Comments? ++Vamsi On Jan 18, 2008 1:37 AM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Yes, sure, I fully agree. I've filed GERONIMO-3757 for this issue and now thinking of the patch to the trunk that would provide the necessary customization - unless any objections arise. As of GERONIMO-2015, I think we may close it, as there're objective reasons (stated there by Vamsavardhana Reddy) to not move from JKS on Sun. Vasily -Original Message- From: Alexey Petrenko [mailto: [EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 1:37 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? I think we should add PKCS12 to Geronimo. If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose what keystore to use? We can specify keystore in configs or choose type from available on current VM. SY, Alexey 2008/1/15, Zakharov, Vasily M [EMAIL PROTECTED]: Hi, all, Is there a way to change the geronimo-default keystore from JKS to, say, PKCS12 without patching the org.apache.geronimo.security.keystore.FileKeystore* classes? That way of patching sources is suggested at GERONIMO-2015, and it works, but it's probably not the best idea. I see the reasons of not making PKCS12 a default keystore type, but what about making it possible to change keystore type using config.xml, without source recompilation? I've browsed through the configuration options of geronimo-security gbean, a found no way for that. Should I provide a patch for that to be possible, would that be appropriate? Thank you! Vasily Zakharov Intel ESSD ---
[jira] Updated: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3757: -- Attachment: GERONIMO-3757.patch GERONIMO-3757.patch: Created against branches\2.0. o Provides a keystoreType attribute o Keystores portlet updated to support all possible keystoreTypes. This patch may not necessarily be merged into branches\2.0. Please try the patch and comment. KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Attachments: GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reopened GERONIMO-3764: --- Offline deployer does not get a chance to cleanup temporary files :( DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3764: -- Attachment: GERONIMO-3764-2.0.patch GERONIMO-3764-2.0.patch: How about DeployerReaper cleaning up temp directories left by any previous runs? Anyone has a better idea? DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561108#action_12561108 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- deleteOnExit() seems to be a better option. But then deleteOnExit() does not delete files if the JVM is terminated abnormally. DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to 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-3774) monitoring agent should separate any constant assignment inside one class
monitoring agent should separate any constant assignment inside one class - Key: GERONIMO-3774 URL: https://issues.apache.org/jira/browse/GERONIMO-3774 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Trivial There are constant variables such as DEFAULT_RETENTION that are used by both the agent-jmx and agent-ejb. These constants should be placed inside a class dedicated to just constants in agent-jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3775) Plugin installer in admin console isn't cycling through source-repository properly, resulting in failure to download plugins from remote repositories.
Plugin installer in admin console isn't cycling through source-repository properly, resulting in failure to download plugins from remote repositories. Key: GERONIMO-3775 URL: https://issues.apache.org/jira/browse/GERONIMO-3775 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Fix For: 2.1 The plugin installer in the admin console is not cycling through the source-repository and defaulting to only searching the defaultRepository, resulting in failure to download plugins from remote repositories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3607) export a server including a set of plugins
[ https://issues.apache.org/jira/browse/GERONIMO-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3607. -- Resolution: Fixed fixed in rev 614044, also tried to clean up the first page of 'plugins' export a server including a set of plugins -- Key: GERONIMO-3607 URL: https://issues.apache.org/jira/browse/GERONIMO-3607 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 Provide the ablility to package a server that includes a set of plugins, accessible through the console and through gshell. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 2.1 Release -- Banging the drum
+1 - Two weeks sounds good to me. The big feature that I had been waiting for was the Dojo upgrade and that is done. I can start looking at the 'STDOUT' messages. I would assume that sending messages to the console during tests would be fine (yes?) and that the problem would really be when messages from a running server get sent there as well. Or should even the test messages be getting sent to a log? Jay Kevan Miller wrote: All, This note is a bit overdue (it's been a distracting start to the New Year for me). Time, IMO, for us to get focused on our 2.1 release. As David Jencks has pointed out. We need to start cleaning out the 2.1 Jiras. It looks like I've got several open that have been fixed, either by additional development activities or redundant jira's. First step is to take a look at Jira's that you've created and make sure they are still valid and if you think it's important that they be fixed for 2.1. We also need to be taking a close look at our current functionality. Make sure things are working the way we want them to... Especially need to cast a critical eye on our the usability aspects of the new 2.1. Along the way, will be great if we can start pulling docs together. I started running tests last night. Right away, I'm noticing little things like warning messages being sent to STDOUT, etc. I'll start registering problem areas that I'm seeing. I'd like to set a target of 2 weeks for reviewing and fixing problems. After that would start the branching, final tck, and packaging work. If we feel this might negatively impact post-2.1 development activities. We can consider creating a 2.1 branch sooner... Thoughts? --kevan
Re: 2.1 Release -- Banging the drum
On Jan 21, 2008, at 6:44 PM, Jay D. McHugh wrote: +1 - Two weeks sounds good to me. The big feature that I had been waiting for was the Dojo upgrade and that is done. I can start looking at the 'STDOUT' messages. I would assume that sending messages to the console during tests would be fine (yes?) and that the problem would really be when messages from a running server get sent there as well. Or should even the test messages be getting sent to a log? Well, I was thinking of warning/error messages that aren't really warning/error messages. For example: 19:25:17,715 WARN [AbstractGBeanReference] GBean references are not using proxies and the Tomcat restricted listeners error message... --kevan
[jira] Assigned: (GERONIMO-3747) subprojects should use file system parent poms as parent poms in general
[ https://issues.apache.org/jira/browse/GERONIMO-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon reassigned GERONIMO-3747: -- Assignee: Jason Dillon subprojects should use file system parent poms as parent poms in general Key: GERONIMO-3747 URL: https://issues.apache.org/jira/browse/GERONIMO-3747 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: David Jencks Assignee: Jason Dillon Fix For: 2.1 After the move of most stuff into plugins, the parent pom is usually still o.a.g.modules/modules or o.a.g.configs/configs. I think this is a really bad idea. I think the main thing that needs to be changed is to move the car plugin setup code into the root pom. However I'm not sure if this is possible bit of a chicken/egg situation? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3747) subprojects should use file system parent poms as parent poms in general
[ https://issues.apache.org/jira/browse/GERONIMO-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GERONIMO-3747: --- Attachment: GERONIMO-3747-step-1.diff.zip subprojects should use file system parent poms as parent poms in general Key: GERONIMO-3747 URL: https://issues.apache.org/jira/browse/GERONIMO-3747 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: David Jencks Assignee: Jason Dillon Fix For: 2.1 Attachments: GERONIMO-3747-step-1.diff.zip After the move of most stuff into plugins, the parent pom is usually still o.a.g.modules/modules or o.a.g.configs/configs. I think this is a really bad idea. I think the main thing that needs to be changed is to move the car plugin setup code into the root pom. However I'm not sure if this is possible bit of a chicken/egg situation? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.0: Failed for Revision: 613970
Geronimo Revision: 613970 built with tests included
See the full build-1400.log file at
http://geronimo.apache.org/maven/server/binaries/2.0/20080121/build-1400.log
See the unit test reports at
http://geronimo.apache.org/maven/server/binaries/2.0/20080121/unit-test-reports
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-persistence/1.0.0/openjpa-persistence-1.0.0.jar
228K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-jdbc-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-jdbc/1.0.0/openjpa-jdbc-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-jdbc/1.0.0/openjpa-jdbc-1.0.0.jar
1006K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-persistence-jdbc-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
Downloading:
http://tomcat.apache.org/dev/dist/m2-repository/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
Downloading:
http://svn.apache.org/repos/asf/openejb/repo//org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
108K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-lib-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-lib/1.0.0/openjpa-lib-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-lib/1.0.0/openjpa-lib-1.0.0.jar
424K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-kernel-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-kernel/1.0.0/openjpa-kernel-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-kernel/1.0.0/openjpa-kernel-1.0.0.jar
1098K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openejb/jars/openejb-axis-3.0-beta-1.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openejb/openejb-axis/3.0-beta-1/openejb-axis-3.0-beta-1.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-axis/3.0-beta-1/openejb-axis-3.0-beta-1.jar
18K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-kernel-5-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-kernel-5/1.0.0/openjpa-kernel-5-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-kernel-5/1.0.0/openjpa-kernel-5-1.0.0.jar
28K downloaded
[INFO] [compiler:compile]
[INFO] Compiling 20 source files to
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 8 source files to
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.axis.AxisWebServiceContainerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.005 sec
Results :
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/geronimo-axis-2.0.3-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-axis-2.0.3-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/geronimo-axis-2.0.3-SNAPSHOT.jar
to
/home/geronimo/.m2/repository/org/apache/geronimo/modules/geronimo-axis/2.0.3-SNAPSHOT/geronimo-axis-2.0.3-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: Deploy :: Common Config
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/geronimo/geronimo/2.0/modules/geronimo-deploy-config/target/classes/META-INF
[INFO] Copying 2 files to
/home/geronimo/geronimo/2.0/modules/geronimo-deploy-config/target/classes/META-INF
[INFO] [resources:resources
Re: [BUILD] 2.0: Failed for Revision: 613970
Anybody knows how to configure maven to time out when downloading artifacts?
Jarek
On 22 Jan 2008 02:06:54 -, [EMAIL PROTECTED] wrote:
Geronimo Revision: 613970 built with tests included
See the full build-1400.log file at
http://geronimo.apache.org/maven/server/binaries/2.0/20080121/build-1400.log
See the unit test reports at
http://geronimo.apache.org/maven/server/binaries/2.0/20080121/unit-test-reports
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-persistence/1.0.0/openjpa-persistence-1.0.0.jar
228K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-jdbc-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-jdbc/1.0.0/openjpa-jdbc-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-jdbc/1.0.0/openjpa-jdbc-1.0.0.jar
1006K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-persistence-jdbc-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
Downloading:
http://tomcat.apache.org/dev/dist/m2-repository/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
Downloading:
http://svn.apache.org/repos/asf/openejb/repo//org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
108K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-lib-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-lib/1.0.0/openjpa-lib-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-lib/1.0.0/openjpa-lib-1.0.0.jar
424K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-kernel-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-kernel/1.0.0/openjpa-kernel-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-kernel/1.0.0/openjpa-kernel-1.0.0.jar
1098K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openejb/jars/openejb-axis-3.0-beta-1.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openejb/openejb-axis/3.0-beta-1/openejb-axis-3.0-beta-1.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-axis/3.0-beta-1/openejb-axis-3.0-beta-1.jar
18K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-kernel-5-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-kernel-5/1.0.0/openjpa-kernel-5-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-kernel-5/1.0.0/openjpa-kernel-5-1.0.0.jar
28K downloaded
[INFO] [compiler:compile]
[INFO] Compiling 20 source files to
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 8 source files to
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.axis.AxisWebServiceContainerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.005 sec
Results :
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/geronimo-axis-2.0.3-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-axis-2.0.3-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/geronimo-axis-2.0.3-SNAPSHOT.jar
to
/home/geronimo/.m2/repository/org/apache/geronimo/modules/geronimo-axis/2.0.3-SNAPSHOT/geronimo-axis-2.0.3-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: Deploy :: Common Config
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created
[jira] Updated: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Zakharov updated GERONIMO-3757: -- Attachment: Geronimo-3757.patch Vamsavardhana, Thank you a lot for the patch! Now I see it's more complex than I expected. I had to also update the org.apache.geronimo.console.ca.BaseCAHandler and org.apache.console.ca.ConfirmCAHandler for the build to succeed. With these two updates the patch applied fine and the build succeeded. Here I apply the updated patch. KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3775) Plugin installer in admin console isn't cycling through source-repository properly, resulting in failure to download plugins from remote repositories.
[ https://issues.apache.org/jira/browse/GERONIMO-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561207#action_12561207 ] Jarek Gawor commented on GERONIMO-3775: --- Joe, Committed some changes that should hopefully fix this problem (revision 614105). This plugin installation really needs some tests. Plugin installer in admin console isn't cycling through source-repository properly, resulting in failure to download plugins from remote repositories. Key: GERONIMO-3775 URL: https://issues.apache.org/jira/browse/GERONIMO-3775 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Fix For: 2.1 The plugin installer in the admin console is not cycling through the source-repository and defaulting to only searching the defaultRepository, resulting in failure to download plugins from remote repositories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Thanks Matt And Congrats Kevan
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561239#action_12561239 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Completed: At revision: 614127 in branches\2.0 and trunk (2.1) o DeployerReaper in offline deployment does not get a chance to reap the temporary directories. Reap these directories in the next run. o If anyone has a better idea on how to handle this or sees something I am missing, please suggest/comment. DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561249#action_12561249 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Completed: At revision: 614136 in branches\2.0 and trunk (2.1) o Cleanup even when creation of temp file for deployment fails DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
