Re: upgrade from 3.0 to 4.0
The easiest way to do that is: BrokerService broker = new BrokerService(); broker.setPersistent(false); broker.start(); or if you want to configure the broker using an external xbean configuration file: BrokerService broker = BrokerFactory.createBroker(new URI(xbean:file:/path_to_file.xml)); broker.start(); On 5/24/06, sram [EMAIL PROTECTED] wrote: We are upgrading ActiveMQ 3.0 to 4.0, Just wondering best way to replace following persistance code File f = new File(System.getProperty(java.io.tmpdir),ltsEvent); PersistanceAdapter padapter = persistenceFactory.createPersistenceAdapter(f,new MemoryBoundedObjectManager(BusName,MaxEvents); broker.setPersistenceAdapter(new JournalPersistenceAdapter(new File(System.getProperty(java.io.tmpdir)), padapter); since MemoryBoundedObjectManager is not supported, I am looking for best alternative way to configure broker for persistance. Also, If I did not configure the persistance will it use the default derby for persistance Do you know where I can find on how to set Persistance adapter in 4.0 similar to the above 3.0 config. I am still trying to find activemq site with not much luck -- View this message in context: http://www.nabble.com/upgrade+from+3.0+to+4.0-t1678274.html#a4551148 Sent from the ActiveMQ - Dev forum at Nabble.com. -- Regards, Hiram
Re: Move blocker GERONIMO-1960 to 1.1.1?
+1 on excluding this from 1.1. I agree it's not a blocker. I think client-corba needs a dependency on client-security, I thought it was there. I'll try to investigate on the plane tomorrow. I expected you to fix this by modifying the ServiceConfigBuilder to check that the gbean reference was satisfied in the ancestor set when it is reading the xml. This is what the other builders do for e.g. resource-refs, and I think it would be simple and non-invasive. However, in any case I don't think this is a blocker the worst that can happen is that you get an error later rather than sooner, you get essentially the same effect either way. thanks david jencks On May 23, 2006, at 7:55 PM, Dain Sundstrom wrote: I finished the patch for GERONIMO-1960 (http://issues.apache.org/ jira/browse/GERONIMO-1960), but I think it may be destabilizing and should be move to 1.1.1. I added a verify method to Deployment context which is called from getConfigurationData(). This method verifies the references and dependencies on can be resolved. I only try to resolve dependencies and single valued references. Further, only unresolved reference patterns are resolved, under the assumption that the deployer created a resolved pattern correctly. We can not absolute references to beans in external modules. A couple of the client plans threw exceptions so I had to patch them also, which is why I am concerned. The client-security has unnecessary and possibly incorrect module declarations and the client-corba plan has a dependency on SecurityService which can't be resolved since there is no dependency on client-security. I removed the former and commented out the latter. I am not sure if we need the dependency on SecurityService in client-corba, and if so, I'm not sure if we can add a dependency from client-corba to client-security. David Jencks any help here would be appreciated. Anyway, I don't think this is issue actually a blocker issue, and think we can safely move it to 1.1.1 (or 1.2 if my 1.1.1 proposal flops). -dain
Re: Move blocker GERONIMO-1960 to 1.1.1?
On May 23, 2006, at 11:04 PM, David Jencks wrote: +1 on excluding this from 1.1. I agree it's not a blocker. I think client-corba needs a dependency on client-security, I thought it was there. I'll try to investigate on the plane tomorrow. I expected you to fix this by modifying the ServiceConfigBuilder to check that the gbean reference was satisfied in the ancestor set when it is reading the xml. This is what the other builders do for e.g. resource-refs, and I think it would be simple and non- invasive. However, in any case I don't think this is a blocker the worst that can happen is that you get an error later rather than sooner, you get essentially the same effect either way. Umm, re this comment, I should think before writing :-) A moment's further thought reminded me that the reason we can check e.g. resource-refs when we process them is that we have a multistep process in the j2ee module builders and when we resolve the references we already know all the gbeans. This is not the case for service modules so the verify method you added or some other way of introducing 2 steps would be necessary. thanks david jencks thanks david jencks On May 23, 2006, at 7:55 PM, Dain Sundstrom wrote: I finished the patch for GERONIMO-1960 (http://issues.apache.org/ jira/browse/GERONIMO-1960), but I think it may be destabilizing and should be move to 1.1.1. I added a verify method to Deployment context which is called from getConfigurationData(). This method verifies the references and dependencies on can be resolved. I only try to resolve dependencies and single valued references. Further, only unresolved reference patterns are resolved, under the assumption that the deployer created a resolved pattern correctly. We can not absolute references to beans in external modules. A couple of the client plans threw exceptions so I had to patch them also, which is why I am concerned. The client-security has unnecessary and possibly incorrect module declarations and the client-corba plan has a dependency on SecurityService which can't be resolved since there is no dependency on client-security. I removed the former and commented out the latter. I am not sure if we need the dependency on SecurityService in client-corba, and if so, I'm not sure if we can add a dependency from client-corba to client-security. David Jencks any help here would be appreciated. Anyway, I don't think this is issue actually a blocker issue, and think we can safely move it to 1.1.1 (or 1.2 if my 1.1.1 proposal flops). -dain
[jira] Commented: (GERONIMO-2006) Deploying an application with an incorrect deployment plan results in non-functional admin console panel
[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=comments#action_12413071 ] David Jencks commented on GERONIMO-2006: Since it was already on my machine I added and committed the missing portlet in rev 409080. I'll leave it open in case I missed anything else. Deploying an application with an incorrect deployment plan results in non-functional admin console panel Key: GERONIMO-2006 URL: http://issues.apache.org/jira/browse/GERONIMO-2006 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, console Versions: 1.1 Reporter: Dave Colasurdo Assignee: Kevan Miller Priority: Blocker Fix For: 1.1 Attachments: GERONIMO-2006.patch, Myapp.war, badPlan.xml, badPlan.xml, badPlan2.xml, deployment_portlet.jpg, stackTrace.log Deploying myApp.war using badPlan.xml (both attached) results in a non-functioning Show Web App Wars panel. The console Deploy Applications panel reports application installed and started successfully. However, the application did not startup succesfully. The badPlan file is actually missing tcpListenerAddress=auto which causes TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the JIRA. From then on, the Web App Wars console panel shows portlet error and there is no way to uninstall the bad application via the console. The server must be stopped and restarted in order to have the Web App War panel function correctly. The console should be able to report the true status of the deploy/start and recover from deploying a bad plan. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Remaining 1.1 Issues
+0 #2 Matt Hogstrom wrote: +1 #2 Dain Sundstrom wrote: So what alan is point out is I just suggested we add one more feature. I agree that this is another feature, so what do we want to do? I think we have three choices: 1) My idea below, isolate the broken porlets to an experimental section 2) Just remove the broken portlets 3) Fix the broken portlets I'm +1 on option 1 or 2. I don't care which option we choose. -dain On May 23, 2006, at 3:14 PM, Alan D. Cabrera wrote: /me mumbles something about roses... Regards, Alan Dain Sundstrom wrote: How about we create an experimental section of the console menu, that only displays if you click the show experimental link (I'd guess it can all be done with java script on the browser side). I remember for 1.0 we removed a lot of portlets, but I think it would be ok to include most of them as long as we set the expectation that they are not finished works. -dain On May 22, 2006, at 8:14 AM, Aaron Mulder wrote: Here are the things that I still want to squeeze into 1.1: - fix console JMS to accept new providers at runtime - fix console security realms to accept new providers at runtime - add a missing Geronimo security provider to console security realms - fix hot deploy dir so it notices files updated while the server was down and deletes files if they are undeployed some other way There are also AFAIK a number of not-yet-applied patches to review. Thanks, Aaron
Re: 1.2 Release - Whats in it and when?
On May 23, 2006, at 5:49 PM, David Jencks wrote: So, following your lead this is what I'm currently thinking of working on, not necessarily in order: I forgot helping with the axis2 and xfire integrations. thanks david jencks - global jndi. I hope that this will involve advising Krishnakumar rather than implementing it myself. - pluggable jacc. This is sort of half done. The remaining part is making security get installed based on something other than our geronimo-specific security elements in the geronimo plans, so other guys can have a chance. After that we can look at plugging in other jacc implementations. I think there's a tivoli implementation, and I think we can turn Apache Directory and the jetspeed 2 permission manager into 2 more. At least one of these is likely to provide something like direct principal-role mapping that has IIRC sometimes been requested. - I'd like to turn the jetspeed 2 integration I worked on several months ago into a geronimo plugin. We'll see if more pressing things come up, but I'd really like to get this in. It might help with the idea of installing console bits with plugins also. - help with maven 2 plugins if necessary I suspect Anita and the others working on this may need no help however :-) -- I'm the proud owner :-) of some of the oldest open jiras, especially around the J2CA stuff. I'd like to finally get tests going for these and close them out. There's some refactoring involved in some of these also. I plan to take care of a reasonable number of the other open jiras too :-) -- help out with the jetty 6 integration if needed. -- help out with wadi integration if needed. I'm sure plenty more things will turn up but this is what I'm thinking of at the moment. I'm really looking forward to the stuff matt and alan are talking about also. On May 23, 2006, at 1:44 PM, Matt Hogstrom wrote: 1.1 is almost complete and its time to start thinking about 1.2. Aaron summarized the discussion at Java One in his note. I believe Aaron even volunteered to be the release manager for 1.2 :) Here's my 2c to get this off the ground. I am planning on working in performance improvements around SPECjAppServer which will include improvements to OpenEJB as well as TranQL. Also, I am interested in improving our inherent monitoring capability which currently is ghastly. This includes additional counters and metrics. A GUI representation in the Console as well as perhaps collaborating with Alan on ARM instrumenting the server if he'll let me :) I would prefer to not make this overly painful and ship something in short order. Per Aaron's notes and I concur with this idea we should work on 12 week release cycles. 8 weeks for development and 4 for release / bug fixes, etc. On this track we should cut a dev branch from head at the end of July and ship at the end of August. Good idea. Lets see if we can succeed in actually doing this :-) I would also like to focus on cleaning up the JIRAs (some that are two-years old are too old). Yay! Upgrading our dependencies (there are newer versions of AMQ, Logging, and a whole host of other packages). It would be nice if there was some XBean activity but that's more Dain's area. (It would be really nice to include dynamic dll support in XBean like OSGi; hint hint) Also, it would be nice as a project that if something cool isn't ready for our branch then it goes in the next release. There always will be a next release. I'll try to adhere to this (he says while stuffing as many backported features from trunk into 1.1 as possible :-) Let the flood gates go. Matt thanks david jencks
[jira] Created: (SM-438) DefaultServiceMixClient.stop() doesn't stop JBI Container
DefaultServiceMixClient.stop() doesn't stop JBI Container - Key: SM-438 URL: https://issues.apache.org/activemq/browse/SM-438 Project: ServiceMix Type: Bug Components: servicemix-core Environment: jdk 1.5 winXP eclipse 3.1 Reporter: GODOT Philippe Method DefaultServiceMixClient.stop() doesn't stop JBI container. some ActiveMQ thread are blocked status. If you stop the JBI Agent, in the log you have: 09:57:45,201 DEBUG [AbstractConnection] Transport failed: java.net.SocketException: Connection reset [0.0.1:3633] (org.apache.activemq.broker.AbstractConnection.Transport:166) java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:48) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:55) at java.io.DataInputStream.readInt(DataInputStream.java:353) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:270) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:138) at java.lang.Thread.run(Thread.java:595) 09:57:45,201 INFO [DemandForwardingBridgeSupport] Network connection between vm://peer-chdsk-pgodot-3631-1148457416186-1-0#2 and tcp://localhost/127.0.0.1:3620 shutdown: Connection reset [0.0.1:3620] (org.apache.activemq.network.DemandForwardingBridge:264) java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:48) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:55) at java.io.DataInputStream.readInt(DataInputStream.java:353) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:270) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:138) at java.lang.Thread.run(Thread.java:595) This exception wakeup the threads and everything stop. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2038) assemblies\minimal-tomcat-server fails on windows due to file path length
[ http://issues.apache.org/jira/browse/GERONIMO-2038?page=all ] John Sisson closed GERONIMO-2038: - Resolution: Invalid What I thought was a long file name problem must have been another problem and does not occur any more. Closing issue as invalid. assemblies\minimal-tomcat-server fails on windows due to file path length - Key: GERONIMO-2038 URL: http://issues.apache.org/jira/browse/GERONIMO-2038 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem Versions: 1.1 Reporter: John Sisson Assignee: John Sisson Priority: Blocker Fix For: 1.1 Build failed on windows with openejb patch. It appears we have hit a filename limit again, as it failed because it couldn't delete C:\dev\geronimo\br\1.1\assemblies\minimal-tomcat-server\target When I shortened the directory name to min-tomcat-server and changed the artifact name to geronimo-tomcat-min it worked fine. If there are no objections, I will commit a change that changes the tomcat and jetty minimal assemblies to use min rather than minimal in their names. C:\dev\geronimo\br\1.1svn info Path: . URL: https://svn.apache.org/repos/asf/geronimo/branches/1.1 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 407390 Node Kind: directory Schedule: normal Last Changed Author: kevan Last Changed Rev: 407349 Last Changed Date: 2006-05-18 04:30:34 +1000 (Thu, 18 May 2006) Properties Last Updated: 2006-03-31 07:54:02 +1000 (Fri, 31 Mar 2006) 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + 23:04:28,936 INFO [ReactorTag] + | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat 23:04:28,936 INFO [ReactorTag] | assemblies Geronimo Assembly for a Web Server running Tomcat | Memory: 67M/107M 23:04:28,952 INFO [ReactorTag] | Memory: 67M/107M 23:04:28,952 INFO [ReactorTag] | Memory: 67M/107M 23:04:28,952 INFO [ReactorTag] | Memory: 67M/107M 23:04:28,952 INFO [ReactorTag] | Memory: 67M/107M 23:04:28,952 INFO [ReactorTag] | Memory: 67M/107M 23:04:28,952 INFO [ReactorTag] | Memory: 67M/107M 23:04:28,952 INFO [ReactorTag] | Memory: 67M/107M 23:04:28,952 INFO [ReactorTag] | Memory: 67M/107M 23:04:28,952 INFO
Apache Maven Repo Issue for 1.1 release
Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Mailing list Karma
I've seen some posts on the user list in the last couple of months about problems subscribing / unsubscribing. Is there something I can do as a committer to help them out in terms of administration or does this require some kind of mail list karma?
[jira] Closed: (GERONIMO-2006) Deploying an application with an incorrect deployment plan results in non-functional admin console panel
[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=all ] Kevan Miller closed GERONIMO-2006: -- Resolution: Fixed david jencks committed PlanExportServlet Deploying an application with an incorrect deployment plan results in non-functional admin console panel Key: GERONIMO-2006 URL: http://issues.apache.org/jira/browse/GERONIMO-2006 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, console Versions: 1.1 Reporter: Dave Colasurdo Assignee: Kevan Miller Priority: Blocker Fix For: 1.1 Attachments: GERONIMO-2006.patch, Myapp.war, badPlan.xml, badPlan.xml, badPlan2.xml, deployment_portlet.jpg, stackTrace.log Deploying myApp.war using badPlan.xml (both attached) results in a non-functioning Show Web App Wars panel. The console Deploy Applications panel reports application installed and started successfully. However, the application did not startup succesfully. The badPlan file is actually missing tcpListenerAddress=auto which causes TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the JIRA. From then on, the Web App Wars console panel shows portlet error and there is no way to uninstall the bad application via the console. The server must be stopped and restarted in order to have the Web App War panel function correctly. The console should be able to report the true status of the deploy/start and recover from deploying a bad plan. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2054) http://geronimo.apache.org/xml/ns/j2ee/web-1.0 name spaces are not upgraded by Upgrade1_0To1_1
http://geronimo.apache.org/xml/ns/j2ee/web-1.0 name spaces are not upgraded by Upgrade1_0To1_1 -- Key: GERONIMO-2054 URL: http://issues.apache.org/jira/browse/GERONIMO-2054 Project: Geronimo Type: Bug Security: public (Regular issues) Versions: 1.1 Reporter: Kevan Miller Assigned to: Kevan Miller Fix For: 1.1 Upgrade1_0To1_1.java is missing a rule to upgrade http://geronimo.apache.org/xml/ns/j2ee/web-1.0 to http://geronimo.apache.org/xml/ns/j2ee/web-1.1 This means that some geronimo web plans will not be upgraded properly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2054) http://geronimo.apache.org/xml/ns/j2ee/web-1.0 name spaces are not upgraded by Upgrade1_0To1_1
[ http://issues.apache.org/jira/browse/GERONIMO-2054?page=all ] Kevan Miller closed GERONIMO-2054: -- Resolution: Fixed Fixed and tested plan upgrade. http://geronimo.apache.org/xml/ns/j2ee/web-1.0 name spaces are not upgraded by Upgrade1_0To1_1 -- Key: GERONIMO-2054 URL: http://issues.apache.org/jira/browse/GERONIMO-2054 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 1.1 Upgrade1_0To1_1.java is missing a rule to upgrade http://geronimo.apache.org/xml/ns/j2ee/web-1.0 to http://geronimo.apache.org/xml/ns/j2ee/web-1.1 This means that some geronimo web plans will not be upgraded properly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2055) RunningTest is not compatible with non-Sun VMs.
[ http://issues.apache.org/jira/browse/GERONIMO-2055?page=all ] Andrey Pavlenko updated GERONIMO-2055: -- Attachment: RunningTest.patch RunningTest is not compatible with non-Sun VMs. --- Key: GERONIMO-2055 URL: http://issues.apache.org/jira/browse/GERONIMO-2055 Project: Geronimo Type: Bug Security: public(Regular issues) Components: JVM-compatibility Versions: 1.0 Reporter: Andrey Pavlenko Attachments: RunningTest.patch org.apache.geronimo.directory.RunningTest is not compatible with non-Sun VMs because of hardcoded name of Sun's JNDI/LDAP service provider. The attached patch customizes the name of the provider. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2055) RunningTest is not compatible with non-Sun VMs.
RunningTest is not compatible with non-Sun VMs. --- Key: GERONIMO-2055 URL: http://issues.apache.org/jira/browse/GERONIMO-2055 Project: Geronimo Type: Bug Security: public (Regular issues) Components: JVM-compatibility Versions: 1.0 Reporter: Andrey Pavlenko Attachments: RunningTest.patch org.apache.geronimo.directory.RunningTest is not compatible with non-Sun VMs because of hardcoded name of Sun's JNDI/LDAP service provider. The attached patch customizes the name of the provider. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r409112 - EJB Performance Improvement of 6x (did I miss something ?)!
All, I have committed a bug fix to improve performance of DayTrader for EJB transactions that has improved our performance from 500 TPS to 3200 TPS for PingServlet2Session (*a 6x improvement in EJB performance!*). This also includes an uncommitted (and independent) fix to OpenEJB to improve EJB copy performance. This change required me to add the concurrent jar to the MANIFEST classpath on the server.jar. I worked with DJencks on crafting the beast but wanted Dain, et all, to take a peak and make sure that I didn't miss something. This closes a significant performance gap for Geronimo when compared to other OpenSource and Commercial AppServers :) Cheers, Matt [EMAIL PROTECTED] wrote: Author: hogstrom Date: Wed May 24 03:23:45 2006 New Revision: 409112 URL: http://svn.apache.org/viewvc?rev=409112view=rev Log: BUG: This fix addresses an issue in RMIClassLoaderSpiImpl where a codebase is optionally passed for certain copy operations. When profiling DayTrader our performance for PingServlet2Session was extremely poor relative to JBoss and WebSphere. Our throughput on a 2-way 3.0 Ghz system was roughly 500 tps compared to 5400 and 4500 repsepctively. (It appears that JBoss is not honoring pass-by-value semantics properly; thus the significantly higher throughput). I chased the degraded performance to RMIClassLoaderSPIImpl where we were spending nearly 70% of the system's time in normalizeCodebase for less than 1/8 of the requests being processed. Here is some profiling data to show the degredation: === = = = === === == Parent46100.71 70.54 1157864861 115775210210 28) J:org/apache/geronimo/system/rmi/RMIClassLoaderSpiImpl.loadClass(Ljava/lang/ Self46100.71 70.54 1157864861 115775210210 [29] J:org/apache/geronimo/system/rmi/RMIClassLoaderSpiImpl.normalizeCodebase(Lja Child 505500.34 61.97555213244 101708338940 31) J:org/apache/geronimo/system/rmi/RMIClassLoaderSpiImpl.updateCodebase(Ljava/ Child45840.044.40 65515147 7224581400 30) J:org/apache/geronimo/system/rmi/RMIClassLoaderSpiImpl.normalizeURL(Ljava/ne Child 551360.462.71758942891 4446465936 42) J:java/net/URL.init(Ljava/net/URL;Ljava/lang/String;Ljava/net/URLStreamHan Child 2343500.390.59631910516970672051 36) J:java/lang/String.indexOf(I)I Note that of the 4610 requests were a subset of a total of 32000 transactions. Here is the normalizeURL information: === = = = === === == Parent 505240.38 59.74629510012 98041028811 30) J:org/apache/geronimo/system/rmi/RMIClassLoaderSpiImpl.normalizeURL(Ljava/ne Self 505240.38 59.74629510012 98041028811 [32] J:java/io/File.toURI()Ljava/net/URI; Child 505240.23 55.43376226211 90981520312 33) J:java/net/URI.init(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String; Child 505240.123.14189098774 5152641459 54) J:java/io/File.isDirectory()Z Child 505240.170.39274629658646476978 192) J:java/io/File.slashify(Ljava/lang/String;Z)Ljava/lang/String; Child 505240.140.29224357024473009995 210) J:java/io/File.init(Ljava/lang/String;)V Child 505240.050.05 88736649 88736649 386) J:java/lang/String.startsWith(Ljava/lang/String;I)Z Child 505240.040.04 69133406 69133406 408) J:java/io/Win32FileSystem.resolve(Ljava/io/File;)Ljava/lang/String; I added a new method to inercept and cache calls to normalizeCodebase where I simply return a cached result. This has resulted in a 6x+ performance improvement where we have gone from 500 tps to 3200+. Modified: geronimo/branches/1.1/assemblies/j2ee-jetty-server/project.xml geronimo/branches/1.1/assemblies/j2ee-tomcat-server/project.xml geronimo/branches/1.1/assemblies/minimal-jetty-server/project.xml geronimo/branches/1.1/assemblies/minimal-tomcat-server/project.xml geronimo/branches/1.1/assemblies/j2ee-installer/project.xml geronimo/branches/1.1/configs/client-system/project.properties geronimo/branches/1.1/configs/client-system/project.xml geronimo/branches/1.1/configs/j2ee-system/project.properties geronimo/branches/1.1/configs/j2ee-system/project.xml geronimo/branches/1.1/configs/rmi-naming/project.xml geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/rmi/RMIClassLoaderSpiImpl.java Modified: geronimo/branches/1.1/assemblies/j2ee-jetty-server/project.xml URL: http://svn.apache.org/viewvc/geronimo/branches/1.1/assemblies/j2ee-jetty-server/project.xml?rev=409112r1=409111r2=409112view=diff == --- geronimo/branches/1.1/assemblies/j2ee-jetty-server/project.xml
Re: OpenWire - asynchronous consumption
On 5/9/06, PRJH [EMAIL PROTECTED] wrote: On the page http://activemq.codehaus.org/OpenWire+dotNet, the asynchronous consumption examples aren't available (unable to download) - can we have a fix? Otherwise, could someone kindly post these examples or other. Codehaus went down which I think is why the examples are not working. The Apache site is up and working fine... http://incubator.apache.org/activemq/openwire-dotnet.html -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (GERONIMO-2056) Plugins plugin.xml has hardcoded version numbers
Plugins plugin.xml has hardcoded version numbers Key: GERONIMO-2056 URL: http://issues.apache.org/jira/browse/GERONIMO-2056 Project: Geronimo Type: Bug Security: public (Regular issues) Reporter: Matt Hogstrom Assigned to: Aaron Mulder Fix For: 1.2 The plugin.xml file modules/system/src/test-data/geronimo-plugins.xml is loaded with haedcoded version numbers. This needs to be corrected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Apache Maven Repo Issue for 1.1 release
On Wed, May 24, 2006 at 04:05:40AM -0400, Kevan Miller wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. I've noticed some strange behavior that maybe someone can explain. I can reach people.apache.org fine from a web browser, and a maven new4 new5 build starts fine, but at some point during the build I start to get connection timeout messages from Maven because people.apache.org starts refusing connections from my machine on port 80. I can still connect fine from other hosts, so I'm wondering if people.a.o has some sort of dynamic rate limiting that maven is running afoul of. After a few minutes, people.a.o starts accepting connections again, but if I try another maven build I get put back on the blacklist. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Please, please, please! An even better solution would be to add the dependencies to the source control tree so that I get everything I need from svn co. Thanks, Toby
[jira] Commented: (GERONIMO-2053) Restting Geronimo Build Tree for 1.2 Development for post 1.1 activities
[ http://issues.apache.org/jira/browse/GERONIMO-2053?page=comments#action_12413104 ] Matt Hogstrom commented on GERONIMO-2053: - svn mv https://svn.apache.org/repos/asf/geronimo/trunk https://svn.apache.org/repos/asf/geronimo/branches/dead-1.2 Committed revision 409123. svn cp https://svn.apache.org/repos/asf/geronimo/branches/1.1 https://svn.apache.org/repos/asf/geronimo/trunk Committed revision 409124. /dev/geronimo/branches/dead-1.2 hogstrom$ svn commit -m Updated dead-1.2 to help people from accidentally building from here Deleting dead-1.2/maven.xml Adding dead-1.2/maven.xml.please_dont_build_from_here ~/dev/geronimo/trunk hogstrom$ svn commit -m GERONIMO-2053 - Updates to make trunk Version 1.2-SNAPSHOT Sendingtrunk/applications/daytrader/project.properties Sendingtrunk/etc/explicit_versions.properties Sendingtrunk/etc/project.properties Sendingtrunk/modules/system/src/test-data/geronimo-plugins.xml Sendingtrunk/plugins/geronimo-assembly-plugin/project.properties Sendingtrunk/plugins/geronimo-assembly-plugin/project.xml Sendingtrunk/plugins/geronimo-dependency-plugin/project.properties Sendingtrunk/plugins/geronimo-dependency-plugin/project.xml Sendingtrunk/plugins/geronimo-deployment-plugin/plugin.properties Sendingtrunk/plugins/geronimo-deployment-plugin/project.properties Sendingtrunk/plugins/geronimo-deployment-plugin/project.xml Sendingtrunk/plugins/geronimo-izpack-plugin/project.properties Sendingtrunk/plugins/geronimo-izpack-plugin/project.xml Sendingtrunk/plugins/geronimo-packaging-plugin/plugin.properties Sendingtrunk/plugins/geronimo-packaging-plugin/project.properties Sendingtrunk/plugins/geronimo-packaging-plugin/project.xml Sending trunk/plugins/geronimo-packaging-plugin/src/test-resources/plan.xml Sending trunk/plugins/geronimo-packaging-plugin/src/test-resources/result.xml Sendingtrunk/pom.xml Transmitting file data ... Committed revision 409146. Restting Geronimo Build Tree for 1.2 Development for post 1.1 activities Key: GERONIMO-2053 URL: http://issues.apache.org/jira/browse/GERONIMO-2053 Project: Geronimo Type: Task Security: public(Regular issues) Reporter: Matt Hogstrom Assignee: Matt Hogstrom Priority: Blocker Fix For: 1.2 To get us back on track for 1.2 development this JIRA is being opened to track and document changes to the Geronimo development tree. Here are the current proposed changes for 0300 PT. * Create a new branch in ./geronimo/branches/dead-1.2 This branch will contain a current copy of trunk and will be deleted at some future point. Perhaps after 1.2 goes out. * Move the current contents of trunk to ./geronimo/branches/dead-1.2 * Copy ./geronimo/branches/1.1 to ./geronimo/trunk This will be a copy of ./geronimo/branches/1.1 as of approximately 0300 PT on Wednesday. Matt will be on Irc around that time incase people are online that have any issues. Assume that that trunk is unavailable until notified of the move and version changes on the dev list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
trunk 1.2-SNAPSHOT is now live !
I implemented the changes in GERONIMO-2053 to save trunk as branches/dead-1.2 and bring branches/1.1 into trunk. If there are additional changes that are required to complete the conversion to 1.2-SNAPSHOT please document them in GERONIMO-2053 http://issues.apache.org/jira/browse/GERONIMO-2053 so we can track them. I'll leave this open for a few days. Also, remember that any fixes made to branches/1.1 should also be applied to trunk. Cheers, Matt
Re: trunk 1.2-SNAPSHOT is now live !
Matt Hogstrom wrote: I implemented the changes in GERONIMO-2053 to save trunk as branches/dead-1.2 and bring branches/1.1 into trunk. If there are additional changes that are required to complete the conversion to 1.2-SNAPSHOT please document them in GERONIMO-2053 Is this for the work to pull changes from dead-1.2 into the new trunk, or is this for other sorts of issues? http://issues.apache.org/jira/browse/GERONIMO-2053 so we can track them. I'll leave this open for a few days. Also, remember that any fixes made to branches/1.1 should also be applied to trunk. Can we start moving code from dead-1.2 into trunk now? Cheers, Matt
Re: trunk 1.2-SNAPSHOT is now live !
Rick McGuire wrote: Matt Hogstrom wrote: I implemented the changes in GERONIMO-2053 to save trunk as branches/dead-1.2 and bring branches/1.1 into trunk. If there are additional changes that are required to complete the conversion to 1.2-SNAPSHOT please document them in GERONIMO-2053 Is this for the work to pull changes from dead-1.2 into the new trunk, or is this for other sorts of issues? You can now grab anything you want from branches/dead-1.2 and merge it with trunk. http://issues.apache.org/jira/browse/GERONIMO-2053 so we can track them. I'll leave this open for a few days. Also, remember that any fixes made to branches/1.1 should also be applied to trunk. Can we start moving code from dead-1.2 into trunk now? Yes. Cheers, Matt
Re: Implementing Global JNDI
Thanks for the feedback and inputs. Regards Krishnakumar On 5/24/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On May 23, 2006, at 5:19 PM, David Jencks wrote: On May 23, 2006, at 6:28 AM, Krishnakumar B wrote: Hi, I have a few doubts related to implementation of global jndi. * Currently we have java:comp/env stored in Local JNDI. In Global JNDI should objects be bound using a different namespace e.g) java: or java:global? IIUC java: is reserved by the j2ee spec for what it requires: thus IMO we should use something else. IIRC the original global jndi context used geronimo: I'm OK with that or maybe global:. IIRC some servers use just /foo/bar with no context. If I am correct, we should support that also (but not the default). * When we implement global JNDI we have some entries in Global and All entries related to application in Local. When a user creates a context he needs to get from either global or local based on what he needs. Would it be right for lookup code to decide from where to fetch the entry based on how the Context is created? for e.g) if i say InitialContext iniCtx = new InitialContext(java:comp/env); fetch from local and if InitialContext iniCtx = new InitialContext(java:global); fetch from global I'm not sure what you're asking about here. Unless you do something screwy to link one of these to the other, the contents of these contexts will be completely unrelated. Looking at the JavaDocs for InitialContext, it does not have a constructor that takes a String. Did you mean: Context context = (Context) new InitialContext().lookup(java:comp/ env); Context context = (Context) new InitialContext().lookup(global:); * Currently in Local JNDI we store Resource References. Should global JNDI also use the same approach or can we use Object references for e.g) DataSource reference directly put in JNDI For j2ee components I think we should bind the same kinds of References in the global jndi tree as we bind in the current java: context. What we bind for stuff that can't get into the java: context needs more thought: it probably depends on what it is. Of course if the context is not read-only an app can bind whatever it wants wherever it wants, thus bringing to mind the need for security and permissions for this stuff. I don't think we can use the current Reference object we bind into our read only context because they do cache the value and never release it. It is expected that the referece will be GCed when the J2EE application is unloaded. It shouldn't be hard to either turn off the cache or to register listener for the reference target life- cycle events. Would appreciate any thoughts as i am still learning and might have missed some points to consider while trying to implement something like this. My plan for implementing this was: 1. Look at the current ReadOnlyContext implementation and figure out how to make a sufficiently synchronized version of it. I'm hoping that we can have synchronized wrappers around this implementation rather than needing a copy, subclass, or new implementation. I think a read only JNDI and a mutable one are different enough that they need separate implementations. Currently our ENC is using a the EnterpriseNamingContext which does not extend ReadOnlyContext (as it isn't really read only). I'd like to keep the EnterpriseNamingContext simple and strictly read only. Therefore, I'd like to see an new separate implementation. If I were going to write it, I'd base it on ConcurrentReaderHashMap and future objects in Java5 (or backport-concurrent-util), but I'm not writing it, so I say do whatever you are comfortable with. 2. Remind myself of how the geronimo: context used to be installed. I think the same method will still work. We might want a gbean to specifically install it. Make sure that programmatic binding and lookup works. IIRC, we add set naming provider package to org.apache.geronimo.naming and when a user tries to access the foo: root-context, the jvm looks for the class org.apache.geronimo.naming.foo.fooURLContextFactory. We still have one named global that most likely gets loaded when someone looks up global: 3. Figure out how to bind stuff into this context from plans rather than java code. Currently my idea is to do this with binding gbeans: I'm not entirely sure how to do this but one possibility would be to have them contain a Reference object and the name to bind it under. Another possibility would be to not use References but rather have a binding gbean with say a gbean reference to a ManagedConnectionFactoryWrapper: the gbean would call $getResource () on it and then bind the result directly into jndi. This would result in simpler builders but more gbeans: we'd need one for resource-refs and resource-env-refs, and another one for ejbs, and another for plain gbean bindings. One thing I like about this second plan is that the object would only be
[jira] Created: (GERONIMO-2057) Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK
Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK --- Key: GERONIMO-2057 URL: http://issues.apache.org/jira/browse/GERONIMO-2057 Project: Geronimo Type: Bug Security: public (Regular issues) Versions: 1.1 Environment: windows xp with non-Sun JDK Reporter: Joe Bohn Assigned to: Joe Bohn Fix For: 1.1 I hit this problem attempting to build with the IBM JDK. The test class that includes these references is currently disabled and not functional. Therefore, I just commented out the references to the Sun class. When this class is updated to be functional again it should be done in such a way that it is not dependent upon a particular JDK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2058) Invalid gbean names in config.xml do not prevent server starting or module starting
Invalid gbean names in config.xml do not prevent server starting or module
starting
---
Key: GERONIMO-2058
URL: http://issues.apache.org/jira/browse/GERONIMO-2058
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Components: startup/shutdown
Versions: 1.1, 1.2
Reporter: David Jencks
Priority: Blocker
Fix For: 1.1, 1.2
config.xml has this in it, which includes an invalid gbean name:
module name=geronimo/j2ee-security/${pom.currentVersion}/car
gbean name=geronimo.remoting:target=JaasLoginServiceRemotingServer
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanRemoteLoginPort}/attribute
/gbean
gbean name=JMXService
attribute name=protocolrmi/attribute
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanJMXPort}/attribute
attribute
name=urlPath/jndi/rmi://${PlanServerHostname}:${PlanNamingPort}/JMXConnector/attribute
/gbean
/module
At the minimum this modules shouldn't start: I would prefer the server to not
start.
Obviously we also need to fix the name in all the config.xmls, in this case it
should be name=JaasLoginServiceRemotingServer
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2057) Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK
[ http://issues.apache.org/jira/browse/GERONIMO-2057?page=all ] Joe Bohn updated GERONIMO-2057: --- Attachment: 2057_NonSunJDKIssue.patch Patch was created on Windows XP from geronimo root directory Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK --- Key: GERONIMO-2057 URL: http://issues.apache.org/jira/browse/GERONIMO-2057 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Environment: windows xp with non-Sun JDK Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 1.1 Attachments: 2057_NonSunJDKIssue.patch I hit this problem attempting to build with the IBM JDK. The test class that includes these references is currently disabled and not functional. Therefore, I just commented out the references to the Sun class. When this class is updated to be functional again it should be done in such a way that it is not dependent upon a particular JDK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2057) Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK
[ http://issues.apache.org/jira/browse/GERONIMO-2057?page=all ] Joe Bohn reassigned GERONIMO-2057: -- Assign To: Matt Hogstrom (was: Joe Bohn) Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK --- Key: GERONIMO-2057 URL: http://issues.apache.org/jira/browse/GERONIMO-2057 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Environment: windows xp with non-Sun JDK Reporter: Joe Bohn Assignee: Matt Hogstrom Fix For: 1.1 Attachments: 2057_NonSunJDKIssue.patch I hit this problem attempting to build with the IBM JDK. The test class that includes these references is currently disabled and not functional. Therefore, I just commented out the references to the Sun class. When this class is updated to be functional again it should be done in such a way that it is not dependent upon a particular JDK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2057) Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK
[ http://issues.apache.org/jira/browse/GERONIMO-2057?page=comments#action_12413117 ] Matt Hogstrom commented on GERONIMO-2057: - Branches/1.1 Sending modules/security/src/test/org/apache/geronimo/security/network/protocol/SubjectCarryingProtocolTest.java Transmitting file data . Committed revision 409165. trunk/ Sending modules/security/src/test/org/apache/geronimo/security/network/protocol/SubjectCarryingProtocolTest.java Transmitting file data . Committed revision 409166. Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK --- Key: GERONIMO-2057 URL: http://issues.apache.org/jira/browse/GERONIMO-2057 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Environment: windows xp with non-Sun JDK Reporter: Joe Bohn Assignee: Matt Hogstrom Fix For: 1.1 Attachments: 2057_NonSunJDKIssue.patch I hit this problem attempting to build with the IBM JDK. The test class that includes these references is currently disabled and not functional. Therefore, I just commented out the references to the Sun class. When this class is updated to be functional again it should be done in such a way that it is not dependent upon a particular JDK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2057) Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK
[ http://issues.apache.org/jira/browse/GERONIMO-2057?page=all ] Matt Hogstrom closed GERONIMO-2057: --- Resolution: Fixed Applied patch Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK --- Key: GERONIMO-2057 URL: http://issues.apache.org/jira/browse/GERONIMO-2057 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Environment: windows xp with non-Sun JDK Reporter: Joe Bohn Assignee: Matt Hogstrom Fix For: 1.1 Attachments: 2057_NonSunJDKIssue.patch I hit this problem attempting to build with the IBM JDK. The test class that includes these references is currently disabled and not functional. Therefore, I just commented out the references to the Sun class. When this class is updated to be functional again it should be done in such a way that it is not dependent upon a particular JDK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2057) Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK
[ http://issues.apache.org/jira/browse/GERONIMO-2057?page=comments#action_12413119 ] Andrey Pavlenko commented on GERONIMO-2057: --- Joe, similar issue is already exists - http://issues.apache.org/jira/browse/GERONIMO-1832. Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK --- Key: GERONIMO-2057 URL: http://issues.apache.org/jira/browse/GERONIMO-2057 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Environment: windows xp with non-Sun JDK Reporter: Joe Bohn Assignee: Matt Hogstrom Fix For: 1.1 Attachments: 2057_NonSunJDKIssue.patch I hit this problem attempting to build with the IBM JDK. The test class that includes these references is currently disabled and not functional. Therefore, I just commented out the references to the Sun class. When this class is updated to be functional again it should be done in such a way that it is not dependent upon a particular JDK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Apache Maven Repo Issue for 1.1 release
+1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: [VOTE] Release 4.0 of ActiveMQ
For this release, are there plans to bring the Openwire dotnet client up to spec with the current 4.0 java implementation? Cheers, Rob. On 5/22/06, Hiram Chirino [EMAIL PROTECTED] wrote: Ok. quick status report on the 718 issue. I applied the patch and the good news is that subsequent openwire version is still compatible with version that is in the current 4.0 release candidate that we voted on. This is because our Java implementation of openwire does not use/validate the size prefix on each command. That size prefix was put there to support future NIO based transports and other openwire implementations where having the size prefix makes it easier to implement the protocol. So I'm all for just including the patch as bug fix in the next (4.1) release of activemq. So I'm still at +1 for releasing the current binary. On 5/22/06, Hiram Chirino [EMAIL PROTECTED] wrote: so 718 was partially valid. I'm going to rebuild and test the new client against the 4.0 rc. If the patch does not break compatibility with 4.0, then I think we can let 4.0 go out as is. if it does break compatibility then I think we will need to recut a new release candidate for 4.0. Any opinions? On 5/22/06, Hiram Chirino [EMAIL PROTECTED] wrote: Opps. I just reviewed that patch. and It does not seem to be valid. I think I may have jumped the gun on putting in my -1. So I'm retracting my -1 for now, and asking for anybody out there that is interested in the openwire internals to peek into the AMQ-718 and double check me. Thanks! On 5/22/06, Hiram Chirino [EMAIL PROTECTED] wrote: I retract my +1.. This issue has just been reported: https://issues.apache.org/activemq/browse/AMQ-718 We have a small inconsistency in our wireformat that if we don't fix now, we will never be able to fix. So -1 on the release, and I'll start working on applying the provided patch. Thanks for the sharp eyes Andrew Lusk! On 5/20/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: James Strachan wrote: We've had the 4.0 release cut for a little while and we've tested it out and it seems to be fine and to comply with the various release requirements (notice file, incubator disclaimers, license files etc) http://people.apache.org/~chirino/incubator-activemq-4.0/maven1/incubator-activemq/distributions/ The release notes will show up here as soon as the mirrors catch up... http://incubator.apache.org/activemq/activemq-40-release.html if you are impatient, here's the wiki page for the release notes: http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0+Release Please vote to approve this release binary [ ] +1 Release the binary as ActiveMQ 4.0 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 +1 Congrats on all the great work! Regards, Alan -- Regards, Hiram -- Regards, Hiram -- Regards, Hiram -- Regards, Hiram
[jira] Updated: (GERONIMO-1740) Plugin migration to Maven 2: geronimo-packaging-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1740?page=all ]
Anita Kulshreshtha updated GERONIMO-1740:
-
Attachment: pom.patch
deploy-tool.patch
modules.patch
These patches are for packaging the configurations shown below -
1. pom.xml from top directory
2. deploy-tool.patch - This is created separately to emphasize that after this
patch m1 build will not work, hence revert this change to use m1 again.
3. modules.patch
4. configs.patch
To run these (I have used maven 2.0.4 ). If there is any problem with
openejb hand install the m1 openejb jars in m2 repo :)
1. mvn -N install
2. cd modules, mvn
3. cd ../m2-plugins,mvn
4. cd ../configs, mvn -o clean install
After the plugin is built the build can be run from the top directory
using mvn -o clean install. The 'clean' is necessary for the configuraitons.
Here are the results of step 4.
Generated package
D:\anita\geronimo\geronimo-1.1\configs\unavailable-webservices-deployer\target\una
vailable-webservices-deployer-1.1-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
D:\anita\geronimo\geronimo-1.1\configs\unavailable-webservices-deployer\target\una
vailable-webservices-deployer-1.1-SNAPSHOT.car to C:\Documents and
Settings\User\.m2\repository\org\
apache\geronimo\configs\unavailable-webservices-deployer\1.1-SNAPSHOT\unavailable-webservices-deploy
er-1.1-SNAPSHOT.car
[INFO] [maven-one-plugin:install-maven-one-repository {execution: default}]
[INFO] Installing
D:\anita\geronimo\geronimo-1.1\configs\unavailable-webservices-deployer\target\una
vailable-webservices-deployer-1.1-SNAPSHOT.car to C:\Documents and
Settings\User\.maven\repository\o
rg.apache.geronimo.configs\cars\unavailable-webservices-deployer-1.1-SNAPSHOT.car
[INFO]
[INFO]
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Geronimo Configs ... SUCCESS [2.250s]
[INFO] Geronimo Configuration for performing service deployments SUCCESS
[6.203s]
[INFO] System Configuration for the J2EE Server ... SUCCESS [2.547s]
[INFO] RMI Naming configuration ... SUCCESS [1.156s]
[INFO] Server Configuration for the J2EE Server ... SUCCESS [2.797s]
[INFO] Axis Configuration for the J2EE Server . SUCCESS [1.312s]
[INFO] Configuration for performing J2EE deployments .. SUCCESS [2.437s]
[INFO] Axis Configuration for performing J2EE deployments . SUCCESS [1.437s]
[INFO] System Configuration for the J2EE Client ... SUCCESS [0.937s]
[INFO] Directory Configuration SUCCESS [1.500s]
[INFO] Hot Deployer ... SUCCESS [1.359s]
[INFO] Security Configuration for the J2EE server . SUCCESS [2.203s]
[INFO] LDAP Security Realm SUCCESS [1.015s]
[INFO] Online Deployer Configuration .. SUCCESS [1.016s]
[INFO] Shared Library GBean ... SUCCESS [0.765s]
[INFO] Shutdown Configuration . SUCCESS [0.500s]
[INFO] Tomcat Configuration for the J2EE Server ... SUCCESS [2.093s]
[INFO] Tomcat Deployer Configuration for performing J2EE deployments SUCCESS
[0.719s]
[INFO] Configuration for no j2ee app clients .. SUCCESS [0.469s]
[INFO] Configuration for no EJBs .. SUCCESS [0.484s]
[INFO] Unavailable Web Services deployer .. SUCCESS [0.625s]
[INFO]
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 37 seconds
[INFO] Finished at: Wed May 24 09:45:51 EDT 2006
[INFO] Final Memory: 13M/27M
[INFO]
Plugin migration to Maven 2: geronimo-packaging-plugin
--
Key: GERONIMO-1740
URL: http://issues.apache.org/jira/browse/GERONIMO-1740
Project: Geronimo
Type: Sub-task
Security: public(Regular issues)
Components: buildsystem
Versions: 1.x
Reporter: Jacek Laskowski
Assignee: Anita Kulshreshtha
Attachments: configs.patch, deploy-tool.patch, geronimo.patch,
geronimo.patch, geronimo.patch, m2-plugins.patch, m2-plugins.patch,
modules.patch, modules.patch, modules.patch, pom.patch, pom.patch, pom.xml
It's a task to keep track of the progress of the plugin build migration to
Maven2
--
This message is automatically generated by JIRA.
-
If you think
[jira] Updated: (GERONIMO-1740) Plugin migration to Maven 2: geronimo-packaging-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1740?page=all ] Anita Kulshreshtha updated GERONIMO-1740: - Attachment: m2-plugins.patch configs.patch 5. m2-plugins.patch Plugin migration to Maven 2: geronimo-packaging-plugin -- Key: GERONIMO-1740 URL: http://issues.apache.org/jira/browse/GERONIMO-1740 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.x Reporter: Jacek Laskowski Assignee: Anita Kulshreshtha Attachments: configs.patch, configs.patch, deploy-tool.patch, geronimo.patch, geronimo.patch, geronimo.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, pom.patch, pom.patch, pom.xml It's a task to keep track of the progress of the plugin build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Apache Maven Repo Issue for 1.1 release
I added a program I was noodling on into sandbox. Its in sandbox/releasetools/trunk/src/java/org/apache/geroinimo/releasetools/VersionVerifier.java Its not complete and very rough but it effectively grinds through the entire G tree and extracts all dependencies G has on external projects. I started adding code to go to the maven repos and get a current list of projects but haven't finished it. David Blevins had a good suggestion that this could be used to build a project.xml that could declare all the dependencies so you could run maven against the project.xml and download all dependencies at once. If this helps you have at. Matt Aaron Mulder wrote: +1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
[jira] Updated: (GERONIMO-1740) Plugin migration to Maven 2: geronimo-packaging-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1740?page=all ] Anita Kulshreshtha updated GERONIMO-1740: - Attachment: modules.patch Please use this modules.patch. It checks in geronimo-dependency.xml for axis, tomcat and jetty modules. Plugin migration to Maven 2: geronimo-packaging-plugin -- Key: GERONIMO-1740 URL: http://issues.apache.org/jira/browse/GERONIMO-1740 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.x Reporter: Jacek Laskowski Assignee: Anita Kulshreshtha Attachments: configs.patch, configs.patch, deploy-tool.patch, geronimo.patch, geronimo.patch, geronimo.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, modules.patch, pom.patch, pom.patch, pom.xml It's a task to keep track of the progress of the plugin build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2055) RunningTest is not compatible with non-Sun VMs.
[ http://issues.apache.org/jira/browse/GERONIMO-2055?page=all ] Matt Hogstrom reassigned GERONIMO-2055: --- Assign To: Matt Hogstrom RunningTest is not compatible with non-Sun VMs. --- Key: GERONIMO-2055 URL: http://issues.apache.org/jira/browse/GERONIMO-2055 Project: Geronimo Type: Bug Security: public(Regular issues) Components: JVM-compatibility Versions: 1.0 Reporter: Andrey Pavlenko Assignee: Matt Hogstrom Attachments: RunningTest.patch org.apache.geronimo.directory.RunningTest is not compatible with non-Sun VMs because of hardcoded name of Sun's JNDI/LDAP service provider. The attached patch customizes the name of the provider. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Important info regarding Eclipse Plugin 1.1 M2 Build Status
FYI... for those trying to build the eclipse plugin from trunk... Until a new openejb snapshot is published, you will need to copy the openejb jars from the m1 repo to your m2 repo. Then from the root of the tree simply invoke mvn. I've modified the generation of the binaries to use an assembly descriptor (one for the deployable distribution and another for the updatesite distribution). Both of these can be found under the assembly module. (mvn assembly:assembly) The assemblies module is now old and will be removed pending the verification of the this new assembly module. So it would be a great help if someone could verify that the distribution actually runs. Secondly, I'm wanting to release the 1.1 version of the plugin as close as possible to the release of G1.1, so if anyone is looking to help out... here's a few things off of my todo list that shouldn't take long but I haven't had a chance to get around to.. - Need a server editor section that provides a checkbox to enable/ disable test envioronment mode. - I'd like to package all of the plugins as archives (currently those that contain nested jars are exploded in the binaries) and let the platform handle nested jars, so change the assemblies to jar all plugins and then verify Eclipse can handle this ok. (will require code changes when deploying the configstore as that jar and the plan will need to be extracted out from a jar and stored in the plugin metadata) - Get the 1.1 editor support working... (double clicking on a 1.0 plan should load the 1.0 editor and double clicking on a 1.1 plan should load the 1.1 editor) - only new form page needed for 1.1 is for the new environment element - open jiras Thanks Sachin
Re: Fairly big problem with tomcat integration
On May 7, 2006, at 6:11 PM, Davanum Srinivas wrote: David, Could u please post a message on [EMAIL PROTECTED], let's see if we can get someone there to push out a release for us. Thanks for the suggestion Dims, I think we finally have some evidence that my synchronization patch to fix an additional problem is ok, so I've posted to that list. see http://issues.apache.org/jira/browse/GERONIMO-1999 david jencks thanks, dims On 5/7/06, David Jencks [EMAIL PROTECTED] wrote: I've run into a couple fair-sized problems with the tomcat integration and I'm not sure how to proceed. The problems are: 1. commons-modeler 1.1 is broken for use in a jsr-77 compliant environment. The BaseModelMBean has a method ObjectName getObjectName() which is used in preference to any method on the wrapped resource object such as the jsr-77 required String getObjectName() method implemented by StandardContext and StandardWrapper (the servlet wrapper). As a result, getting the value of the objectName attribute from the MEJB returns an ObjectName rather than the spec required String. This is fixed in the commons modeler svn trunk (actually fixed in rev 139253 sept 2003 http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/modeler/ trunk/src/java/org/apache/commons/modeler/BaseModelMBean.java? rev=139253r1=139233r2=139253 ) but AFAICT there have been no releases since that fix. Current trunk does not build cleanly for me, I get a test failure. I imagine that since the commons modeler community has not released anything for more than 1.5 years despite this fix being required for use in a j2ee compliant environment we have 0 chance of getting an official release any time soon. About the only thing I can think to do here is make a private build of commons-modeler. I believe we did not see this earlier because the MEJB was not showing anything for the tomcat created mbeans since it was using a fake mbean server wrapping the geronimo kernel, showing only gbeans. Now we are bridging gbeans into the mbean server and MEJB is querying the real mbean server. 2. We have 2 mbeans claiming to be the web module: one from our gbean, which has no servlets, and one from tomcat, which actuallly has the servlets. These have rather different naming policies. For instance, the tomcat one has J2EEModule=//context-root whereas ours has J2EEModule=jarname or configid/moduleId. I'm tempted to make our gbean claim to be a WebModuleWrapper or something like that so jsr-77 only finds one mbean/web module. I'd like to get at least the J2EEApplication set correctly on the tomcat mbeans and preferably get the WebModule to agree with our setting. Comments? Other proposals? thanks david jencks -- Davanum Srinivas : http://wso2.com/blogs/
[jira] Closed: (GERONIMO-2055) RunningTest is not compatible with non-Sun VMs.
[ http://issues.apache.org/jira/browse/GERONIMO-2055?page=all ] Matt Hogstrom closed GERONIMO-2055: --- Resolution: Fixed hogstrom:~/dev/geronimo/branches/1.1/modules/directory hogstrom$ svn commit Sendingdirectory/project.properties Sendingdirectory/src/test/org/apache/geronimo/directory/RunningTest.java Transmitting file data .. Committed revision 409179. This patch is an incremental step forward but we need to address the mult-VM issue in a global way. Chasing these issues down one by one won't scale. RunningTest is not compatible with non-Sun VMs. --- Key: GERONIMO-2055 URL: http://issues.apache.org/jira/browse/GERONIMO-2055 Project: Geronimo Type: Bug Security: public(Regular issues) Components: JVM-compatibility Versions: 1.0 Reporter: Andrey Pavlenko Assignee: Matt Hogstrom Attachments: RunningTest.patch org.apache.geronimo.directory.RunningTest is not compatible with non-Sun VMs because of hardcoded name of Sun's JNDI/LDAP service provider. The attached patch customizes the name of the provider. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Important info regarding Eclipse Plugin 1.1 M2 Build Status
Hi Sachin, I assume that by repo you are referring to the local repository. When a new file is installed into a Maven2 local repository, certain metadata is written that is later used by mvn. Instead of copying the JARs over, you want to use the install:install-file goal: mvn install:install-file -Dfile=path-to-file -DgroupId=group-id \ -DartifactId=artifact-id -Dversion=version -Dpackaging=packaging Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 Sachin Patel [EMAIL PROTECTED] m To dev@geronimo.apache.org 05/24/2006 10:47 cc AM Subject Important info regarding Eclipse Please respond to Plugin 1.1 M2 Build Status [EMAIL PROTECTED] he.org FYI... for those trying to build the eclipse plugin from trunk... Until a new openejb snapshot is published, you will need to copy the openejb jars from the m1 repo to your m2 repo. Then from the root of the tree simply invoke mvn. I've modified the generation of the binaries to use an assembly descriptor (one for the deployable distribution and another for the updatesite distribution). Both of these can be found under the assembly module. (mvn assembly:assembly) The assemblies module is now old and will be removed pending the verification of the this new assembly module. So it would be a great help if someone could verify that the distribution actually runs. Secondly, I'm wanting to release the 1.1 version of the plugin as close as possible to the release of G1.1, so if anyone is looking to help out... here's a few things off of my todo list that shouldn't take long but I haven't had a chance to get around to.. - Need a server editor section that provides a checkbox to enable/ disable test envioronment mode. - I'd like to package all of the plugins as archives (currently those that contain nested jars are exploded in the binaries) and let the platform handle nested jars, so change the assemblies to jar all plugins and then verify Eclipse can handle this ok. (will require code changes when deploying the configstore as that jar and the plan will need to be extracted out from a jar and stored in the plugin metadata) - Get the 1.1 editor support working... (double clicking on a 1.0 plan should load the 1.0 editor and double clicking on a 1.1 plan should load the 1.1 editor) - only new form page needed for 1.1 is for the new environment element - open jiras Thanks Sachin
[jira] Resolved: (GERONIMO-1999) commons-modeler 1.1 is broken
[ http://issues.apache.org/jira/browse/GERONIMO-1999?page=all ] Davanum Srinivas resolved GERONIMO-1999: Resolution: Fixed I've committed the patch to commons-modeler and put up a jar in the snapshots maven repo with the suffix 20060524.jar: http://people.apache.org/repository/commons-modeler/jars/ Please switch to that till we push out a commons-modeler release. thanks, dims commons-modeler 1.1 is broken - Key: GERONIMO-1999 URL: http://issues.apache.org/jira/browse/GERONIMO-1999 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Tomcat Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 Commons-modeler 1.1 (apparently the last released version, from about 2.5 years ago) has at least 2 problems: 1. the modeler model mbean ignores any method your resource may have called getObjectName() and instead uses its own, which returns an ObjectName. This makes it difficult to use in a jsr-7 compliant environment where the return type must be String (as it is for the tomcat classes getting wrapped). This was fixed in rev 139253 sept 3 2003. 2. Registry is insufficiently synchronized, resulting in intermittent ConcurrentModificationExceptions. This is being tracked in http://issues.apache.org/bugzilla/show_bug.cgi?id=39521 I'm working on a patch for that. I'm going to make a private build of commons-modeler and put in into our build until we can get this officially resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
openejb 2.1 replay of lost commits
This is the most relevant form of communication for OpenEJB activity at the moment. So... I'm about to start replaying the openejb commits lost during the codehaus crash. There's already been a commit to openejb 2.1 (the repo is now at rc 2651). So, I'm not going to be able to reproduce the exact rc 2656 that openejb was at prior to the crash. Instead, we'll end up at 2657. I'm not sure how svn will behave after we catch up/pass rc 2656. Probably should assume that a fresh co will be required. I don't know of any other way of proceeding. Any harm has already been done. If anyone has better ideas, speak soon... --kevan
Re: Important info regarding Eclipse Plugin 1.1 M2 Build Status
Oh right, thank you. On May 24, 2006, at 10:56 AM, [EMAIL PROTECTED] wrote: Hi Sachin, I assume that by repo you are referring to the local repository. When a new file is installed into a Maven2 local repository, certain metadata is written that is later used by mvn. Instead of copying the JARs over, you want to use the install:install-file goal: mvn install:install-file -Dfile=path-to-file - DgroupId=group-id \ -DartifactId=artifact-id -Dversion=version - Dpackaging=packaging Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 Sachin Patel [EMAIL PROTECTED] m To dev@geronimo.apache.org 05/24/2006 10:47 cc AM Subject Important info regarding Eclipse Please respond to Plugin 1.1 M2 Build Status [EMAIL PROTECTED] he.org FYI... for those trying to build the eclipse plugin from trunk... Until a new openejb snapshot is published, you will need to copy the openejb jars from the m1 repo to your m2 repo. Then from the root of the tree simply invoke mvn. I've modified the generation of the binaries to use an assembly descriptor (one for the deployable distribution and another for the updatesite distribution). Both of these can be found under the assembly module. (mvn assembly:assembly) The assemblies module is now old and will be removed pending the verification of the this new assembly module. So it would be a great help if someone could verify that the distribution actually runs. Secondly, I'm wanting to release the 1.1 version of the plugin as close as possible to the release of G1.1, so if anyone is looking to help out... here's a few things off of my todo list that shouldn't take long but I haven't had a chance to get around to.. - Need a server editor section that provides a checkbox to enable/ disable test envioronment mode. - I'd like to package all of the plugins as archives (currently those that contain nested jars are exploded in the binaries) and let the platform handle nested jars, so change the assemblies to jar all plugins and then verify Eclipse can handle this ok. (will require code changes when deploying the configstore as that jar and the plan will need to be extracted out from a jar and stored in the plugin metadata) - Get the 1.1 editor support working... (double clicking on a 1.0 plan should load the 1.0 editor and double clicking on a 1.1 plan should load the 1.1 editor) - only new form page needed for 1.1 is for the new environment element - open jiras Thanks Sachin -sachin
Re: openejb 2.1 replay of lost commits
It doesn't bother me if you do it all at once to give us 2562 -- whatever works. Are you going to apply David Jencks' fix so Geronimo builds again, or does David or someone else need to do it? Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: This is the most relevant form of communication for OpenEJB activity at the moment. So... I'm about to start replaying the openejb commits lost during the codehaus crash. There's already been a commit to openejb 2.1 (the repo is now at rc 2651). So, I'm not going to be able to reproduce the exact rc 2656 that openejb was at prior to the crash. Instead, we'll end up at 2657. I'm not sure how svn will behave after we catch up/pass rc 2656. Probably should assume that a fresh co will be required. I don't know of any other way of proceeding. Any harm has already been done. If anyone has better ideas, speak soon... --kevan
Re: openejb 2.1 replay of lost commits
On May 24, 2006, at 12:26 PM, Aaron Mulder wrote: It doesn't bother me if you do it all at once to give us 2562 -- whatever works. Are you going to apply David Jencks' fix so Geronimo builds again, or does David or someone else need to do it? I told David that I would apply his patch. I'll do as you suggest. Merge all lost commits as 2652. Followed by David Jencks' patch. --kevan Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: This is the most relevant form of communication for OpenEJB activity at the moment. So... I'm about to start replaying the openejb commits lost during the codehaus crash. There's already been a commit to openejb 2.1 (the repo is now at rc 2651). So, I'm not going to be able to reproduce the exact rc 2656 that openejb was at prior to the crash. Instead, we'll end up at 2657. I'm not sure how svn will behave after we catch up/pass rc 2656. Probably should assume that a fresh co will be required. I don't know of any other way of proceeding. Any harm has already been done. If anyone has better ideas, speak soon... --kevan
[jira] Commented: (GERONIMO-2057) Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK
[ http://issues.apache.org/jira/browse/GERONIMO-2057?page=comments#action_12413146 ] Nellya Udovichenko commented on GERONIMO-2057: -- Are there any plans to enable this test in the future? If so, you may integrate the patch for correct test working. See patch for JIRA 1832: http://issues.apache.org/jira/secure/attachment/12325233/SubjectCarryingProtocolTest.patch. Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK --- Key: GERONIMO-2057 URL: http://issues.apache.org/jira/browse/GERONIMO-2057 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Environment: windows xp with non-Sun JDK Reporter: Joe Bohn Assignee: Matt Hogstrom Fix For: 1.1 Attachments: 2057_NonSunJDKIssue.patch I hit this problem attempting to build with the IBM JDK. The test class that includes these references is currently disabled and not functional. Therefore, I just commented out the references to the Sun class. When this class is updated to be functional again it should be done in such a way that it is not dependent upon a particular JDK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Move blocker GERONIMO-1960 to 1.1.1?
On May 23, 2006, at 11:26 PM, David Jencks wrote: On May 23, 2006, at 11:04 PM, David Jencks wrote: +1 on excluding this from 1.1. I agree it's not a blocker. I think client-corba needs a dependency on client-security, I thought it was there. I'll try to investigate on the plane tomorrow. I expected you to fix this by modifying the ServiceConfigBuilder to check that the gbean reference was satisfied in the ancestor set when it is reading the xml. This is what the other builders do for e.g. resource-refs, and I think it would be simple and non- invasive. However, in any case I don't think this is a blocker the worst that can happen is that you get an error later rather than sooner, you get essentially the same effect either way. Umm, re this comment, I should think before writing :-) A moment's further thought reminded me that the reason we can check e.g. resource-refs when we process them is that we have a multistep process in the j2ee module builders and when we resolve the references we already know all the gbeans. This is not the case for service modules so the verify method you added or some other way of introducing 2 steps would be necessary. Bingo! It took me a few tries to get this patch right. My first attempt worked just as you suggested above (verify as reading the xml), and I ran into the problem where beans were referring to stuff further down in the file. My second attempt was to modify the ServiceConfigBuilder to verify after all beans had been added, but I ran into the problem where beans were referring to stuff in modules that hadn't been processed yet. My final attempt was to put the verify method in DeploymentContext and set it to verify when we call getConfigurationData(). Since this method is only called when the deployment is complete, all gbeans should be available. The patch does appear to work, but complexity of writing it made me nervous about putting it into 1.1. -dain
[jira] Updated: (GERONIMO-1832) Non-public Sun classes dependencies in tests
[ http://issues.apache.org/jira/browse/GERONIMO-1832?page=all ] Donald Woods updated GERONIMO-1832: --- Fix Version: 1.1 Assign To: Matt Hogstrom Fixed by G2057. Please close or cancel this one. Non-public Sun classes dependencies in tests Key: GERONIMO-1832 URL: http://issues.apache.org/jira/browse/GERONIMO-1832 Project: Geronimo Type: Bug Security: public(Regular issues) Components: security Versions: 1.0 Reporter: Nellya Udovichenko Assignee: Matt Hogstrom Fix For: 1.1 Attachments: SubjectCarryingProtocolTest.patch org.apache.geronimo.security.network.protocol.SubjectCarryingProtocolTest imports com.sun.security.auth.login.ConfigFile class Test uses hardcoded internal Sun class so it doesn't work on non-Sun's VM. Attached patch adds the property 'auth.login.config' to file security/project.properties to setup needed configuration in test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How about a quick 1.1.1?
+1 to a 1.1.1 release, if we follow the responses/guidelines from Dain and Matt below. -Donald Matt Hogstrom wrote: Inline Dain Sundstrom wrote: On May 23, 2006, at 12:53 PM, Donald Woods wrote: I like the idea, but think we need more discussion on it - I think we need a compromise here. If we make it too restrictive, people won't work on dot releases and they will drag out the normal release cycle to polish their bits because they know it is there last chance. On the other side if we let anything in, our releases well be viewed with suspicion. I think the right tact to take here is to come up with some guidelines, where stuff like schema are not changed in backwards incompatible ways, and stuff like the web console can have larger changes. In the future, I'm hoping we can architect the server so fast moving code, like the console, can be released at a different schedule then say the transaction manager. On this specific, case a modular console would help :) How long would we do 1.1.x releases - until 1.2 is released? I would say as long as people want to do them. Frankly, I would be surprised to see more that 2 of these, but if say Aaron ;) has the energy to do more... We would require each committer to update trunk as fixes were applied to 1.1.x, right? As long as the fix is still valid in trunk, absolutely. What criteria would be used to determine what could go into a 1.1.x vs. what should only go into trunk? I would say 1.1.1 is limited to bug fixes and usability issues. I would put fixing console, cli, and tooling into the usability bucket as long a the changes don't impact he mainline server code. - Could prereq version updates be made in 1.1.x? I don't know what you mean. If your referring to changing pre-reqs on other jars in terms of dependencies I'd say this is an it depends case. changing pre-reqs like Tomcat Versions and the like would have a direct impact on whether a version was still certified or not. - Schema/plan changes would not be allowed in 1.1.x, right? I would allow additive optional elements, which means that any 1.1.0 plan would work in 1.1.1+. We'd need to be careful here in terms of how we end up doing clustering and Administration. If we are expecting users to base configurations off a template this may make items incompatible. We'll also have to pay much closer attention to things that are serialized. - Configuration plans would be locked down (no splitting/renaming contents of configs\)? Got me. - Would we run CTS to verify nothing has been broken? I'd say why not, but I don't think we are required. I don't think this is a requirement (especially if the changes are bug fixes). I'd say this is optional in point releases and up to the discretion of the developer making the change. -dain smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r409112 - EJB Performance Improvement of 6x (did I miss something ?)!
On May 24, 2006, at 3:30 AM, Matt Hogstrom wrote:
+private String getNormalizedCodebase(String codebase)
+throws MalformedURLException {
+String cachedCodebase = (String)cachedCodebases.get
(codebase);
+if (cachedCodebase != null)
+return cachedCodebase;
+
+String normalizedCodebase = normalizeCodebase(codebase);
+String oldValue = (String)cachedCodebases.put(codebase,
normalizedCodebase);
+
+// If there was a previous value remove the one we just
added to make sure the
+// cache doesn't grow.
+if (oldValue != null) {
+cachedCodebases.remove(codebase);
+}
+return normalizedCodebase; // We can use the oldValue
+}
I don't get what you are trying to do here. It appears that you add
the value but if the map already contained the value you turn around
and remove it. I don't see how that stops the cache from growing.
If you want to prevent the cache from growing I think you need
something like this:
if (cache.size CACHE_LIMIT) {
cachedCodeBases.put(codebase, normalizedCodebase);
}
That isn't absolutely safe but is most likely good enough. The
problem is once the cache is full, you will never add another value.
Alternatively, you could drop something from the cache once it is
full, but you would have to figure out how to do it randomly since,
you don't have any data the entries.
You may want to consider switching the implementation to use a
LinkedHashMap with a size limit, so old values are pushed out. The
problem with a LinkedHashMap is you need to synchronize access. This
shouldn't be a big problem as long as you keep the synchronized
blocks small. I'd synchronized, check if the value exists, and if it
didn't add a future object to the map. Then you exist the
synchronized block and call get() on the future object. This causes
the expensive operation normalizedCodebase(codebase) to happen
outside of the main synchronize block.
Regardless, I'm +1 to this patch because it will work as it stands,
although with a small and very slow memory leak of one string per
class loader, and it is way better then what we had before which was
nothing :)
-dain
Re: trunk 1.2-SNAPSHOT is now live !
Great work Matt! Don't we want to wait until the tck is running before we start piling code into 1.2? -dain On May 24, 2006, at 6:06 AM, Matt Hogstrom wrote: Rick McGuire wrote: Matt Hogstrom wrote: I implemented the changes in GERONIMO-2053 to save trunk as branches/dead-1.2 and bring branches/1.1 into trunk. If there are additional changes that are required to complete the conversion to 1.2-SNAPSHOT please document them in GERONIMO-2053 Is this for the work to pull changes from dead-1.2 into the new trunk, or is this for other sorts of issues? You can now grab anything you want from branches/dead-1.2 and merge it with trunk. http://issues.apache.org/jira/browse/GERONIMO-2053 so we can track them. I'll leave this open for a few days. Also, remember that any fixes made to branches/1.1 should also be applied to trunk. Can we start moving code from dead-1.2 into trunk now? Yes. Cheers, Matt
Re: Apache Maven Repo Issue for 1.1 release
Can we stick the repo in our zone? -dain On May 24, 2006, at 7:12 AM, Aaron Mulder wrote: +1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: Apache Maven Repo Issue for 1.1 release
On May 24, 2006, at 10:12 AM, Aaron Mulder wrote: +1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. I'm pretty iffy on putting a maven repo repro into svn. For one, it becomes incorrect anytime a version is upgraded (I guess this isn't so bad, if it's properly described...). Also, I don't care for automated task to be doing a commit into svn and I don't want to be doing the commit by hand on a weekly basis. I also don't care for large binary data being held in svn. I typically have the entire geronimo tree checked out. This would (unless we use an entirely different tree) potentially add multiple repo repro's into geronimo svn. I'd be all for the weekly unstable build process being used to package all necessary dependencies and make them available for download along with the unstable build src. The repo should be cleaned out prior to every unstable build. I'm also in favor of having a maven repo download available that corresponds to the 1.1 release and is available on the download page (if possible). --kevan Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
[jira] Updated: (GERONIMO-1960) Bad GBean reference isn't caught during deployment
[ http://issues.apache.org/jira/browse/GERONIMO-1960?page=all ] Dain Sundstrom updated GERONIMO-1960: - Fix Version: 1.1.1 (was: 1.1) Assign To: David Jencks (was: Dain Sundstrom) David can take a look at the dependency problem in the client plans? Bad GBean reference isn't caught during deployment -- Key: GERONIMO-1960 URL: http://issues.apache.org/jira/browse/GERONIMO-1960 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, kernel Versions: 1.1 Reporter: Aaron Mulder Assignee: David Jencks Priority: Blocker Fix For: 1.1.1 Attachments: 1960.patch, filestore.jar, geronimo-service.xml, geronimo-service.xml If you deploy the attached JAR and plan, it is distributed successfully but fails during startup when the GBean in the plan can't find ServerInfo. This is not correct behavior -- we should fail during distribute if there are bad GBean references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How about a quick 1.1.1?
There are a lot of +1s here so I went ahead and added a 1.1.1 version to jira. If we decide not to do a 1.1.1, we can always delete it. -dain On May 24, 2006, at 10:01 AM, Donald Woods wrote: +1 to a 1.1.1 release, if we follow the responses/guidelines from Dain and Matt below. -Donald Matt Hogstrom wrote: Inline Dain Sundstrom wrote: On May 23, 2006, at 12:53 PM, Donald Woods wrote: I like the idea, but think we need more discussion on it - I think we need a compromise here. If we make it too restrictive, people won't work on dot releases and they will drag out the normal release cycle to polish their bits because they know it is there last chance. On the other side if we let anything in, our releases well be viewed with suspicion. I think the right tact to take here is to come up with some guidelines, where stuff like schema are not changed in backwards incompatible ways, and stuff like the web console can have larger changes. In the future, I'm hoping we can architect the server so fast moving code, like the console, can be released at a different schedule then say the transaction manager. On this specific, case a modular console would help :) How long would we do 1.1.x releases - until 1.2 is released? I would say as long as people want to do them. Frankly, I would be surprised to see more that 2 of these, but if say Aaron ;) has the energy to do more... We would require each committer to update trunk as fixes were applied to 1.1.x, right? As long as the fix is still valid in trunk, absolutely. What criteria would be used to determine what could go into a 1.1.x vs. what should only go into trunk? I would say 1.1.1 is limited to bug fixes and usability issues. I would put fixing console, cli, and tooling into the usability bucket as long a the changes don't impact he mainline server code. - Could prereq version updates be made in 1.1.x? I don't know what you mean. If your referring to changing pre-reqs on other jars in terms of dependencies I'd say this is an it depends case. changing pre- reqs like Tomcat Versions and the like would have a direct impact on whether a version was still certified or not. - Schema/plan changes would not be allowed in 1.1.x, right? I would allow additive optional elements, which means that any 1.1.0 plan would work in 1.1.1+. We'd need to be careful here in terms of how we end up doing clustering and Administration. If we are expecting users to base configurations off a template this may make items incompatible. We'll also have to pay much closer attention to things that are serialized. - Configuration plans would be locked down (no splitting/ renaming contents of configs\)? Got me. - Would we run CTS to verify nothing has been broken? I'd say why not, but I don't think we are required. I don't think this is a requirement (especially if the changes are bug fixes). I'd say this is optional in point releases and up to the discretion of the developer making the change. -dain
Re: trunk 1.2-SNAPSHOT is now live !
Dain Sundstrom wrote: Great work Matt! Don't we want to wait until the tck is running before we start piling code into 1.2? I've got my finger poised over the commit button for the javamail changes...are we go to move things or not? Rick -dain On May 24, 2006, at 6:06 AM, Matt Hogstrom wrote: Rick McGuire wrote: Matt Hogstrom wrote: I implemented the changes in GERONIMO-2053 to save trunk as branches/dead-1.2 and bring branches/1.1 into trunk. If there are additional changes that are required to complete the conversion to 1.2-SNAPSHOT please document them in GERONIMO-2053 Is this for the work to pull changes from dead-1.2 into the new trunk, or is this for other sorts of issues? You can now grab anything you want from branches/dead-1.2 and merge it with trunk. http://issues.apache.org/jira/browse/GERONIMO-2053 so we can track them. I'll leave this open for a few days. Also, remember that any fixes made to branches/1.1 should also be applied to trunk. Can we start moving code from dead-1.2 into trunk now? Yes. Cheers, Matt
Re: Apache Maven Repo Issue for 1.1 release
Inline Kevan Miller wrote: On May 24, 2006, at 10:12 AM, Aaron Mulder wrote: +1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. I'm pretty iffy on putting a maven repo repro into svn. For one, it becomes incorrect anytime a version is upgraded (I guess this isn't so bad, if it's properly described...). Also, I don't care for automated task to be doing a commit into svn and I don't want to be doing the commit by hand on a weekly basis. I also don't care for large binary data being held in svn. I typically have the entire geronimo tree checked out. This would (unless we use an entirely different tree) potentially add multiple repo repro's into geronimo svn. I'd be all for the weekly unstable build process being used to package all necessary dependencies and make them available for download along with the unstable build src. The repo should be cleaned out prior to every unstable build. I'm also in favor of having a maven repo download available that corresponds to the 1.1 release and is available on the download page (if possible). +1 to the Maven download bundle. --kevan Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: Apache Maven Repo Issue for 1.1 release
I think it would be in our best interest for the long term using Maven to host our own repository, which is backed up by svn. By default the projects will point to the http:// base of our repository (say http://svn.apache.org/repos/asf/geronimo/repository/ m2 or http://svn.apache.org/repos/asf/geronimo/repository/m1). This will do the normal dependency download, and will work for most folks out of the box. But, users can also check out the repository to a local directory, add a bit of settings.xml to add a local repository and then run offline. I believe going forward we *must* do something about the dependency on remote sites that affect our build process. IMO the remoteness that Maven brings is a blessing and a curse. To have 100% reliable and repeatable builds we need to isolate (and really remove) the remoteness. --jason On May 24, 2006, at 10:09 AM, Dain Sundstrom wrote: Can we stick the repo in our zone? -dain On May 24, 2006, at 7:12 AM, Aaron Mulder wrote: +1 to having a way to download all the dependencies you need with or in addition to the source. I'm fine if it's effectively a ~/.maven repository, which we should be able to generate by doing a clean build on a regular (weekly?) basis. It could also be something checked into Subversion, but I'm afraid this would gather a lot of cruft, so we'd have to aggressively prune anything in there that was no longer needed. Thanks, Aaron On 5/24/06, Kevan Miller [EMAIL PROTECTED] wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse (HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded (HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get (HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/ repository// org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/ jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work- around/ configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: Move blocker GERONIMO-1960 to 1.1.1?
Well, I do feel that it's a pretty serious issue... Mainly because it's a hard-to-interpret error at an unfortunate time... The thing is distributed but not started so it seems kind of like it worked (e.g. the new thing appears in the console, etc.) but really it didn't. (I expect users to be able to understand error caused deployment to fail but not deployment succeeded but module still isn't running.) I guess I'm OK if this is deferred, but I don't really want to de-emphasize it much. Thanks, Aaron On 5/24/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On May 23, 2006, at 11:26 PM, David Jencks wrote: On May 23, 2006, at 11:04 PM, David Jencks wrote: +1 on excluding this from 1.1. I agree it's not a blocker. I think client-corba needs a dependency on client-security, I thought it was there. I'll try to investigate on the plane tomorrow. I expected you to fix this by modifying the ServiceConfigBuilder to check that the gbean reference was satisfied in the ancestor set when it is reading the xml. This is what the other builders do for e.g. resource-refs, and I think it would be simple and non- invasive. However, in any case I don't think this is a blocker the worst that can happen is that you get an error later rather than sooner, you get essentially the same effect either way. Umm, re this comment, I should think before writing :-) A moment's further thought reminded me that the reason we can check e.g. resource-refs when we process them is that we have a multistep process in the j2ee module builders and when we resolve the references we already know all the gbeans. This is not the case for service modules so the verify method you added or some other way of introducing 2 steps would be necessary. Bingo! It took me a few tries to get this patch right. My first attempt worked just as you suggested above (verify as reading the xml), and I ran into the problem where beans were referring to stuff further down in the file. My second attempt was to modify the ServiceConfigBuilder to verify after all beans had been added, but I ran into the problem where beans were referring to stuff in modules that hadn't been processed yet. My final attempt was to put the verify method in DeploymentContext and set it to verify when we call getConfigurationData(). Since this method is only called when the deployment is complete, all gbeans should be available. The patch does appear to work, but complexity of writing it made me nervous about putting it into 1.1. -dain
[jira] Updated: (GERONIMO-2056) Plugins plugin.xml has hardcoded version numbers
[ http://issues.apache.org/jira/browse/GERONIMO-2056?page=all ] Aaron Mulder updated GERONIMO-2056: --- Component: Plugins Version: 1.1 Description: The plugin.xml file modules/system/src/test-data/geronimo-plugins.xml is loaded with hardcoded version numbers. This needs to be corrected. (was: The plugin.xml file modules/system/src/test-data/geronimo-plugins.xml is loaded with haedcoded version numbers. This needs to be corrected.) Assign To: Matt Hogstrom (was: Aaron Mulder) Who cares? Isn't it just used for a test of processing the file? Plugins plugin.xml has hardcoded version numbers Key: GERONIMO-2056 URL: http://issues.apache.org/jira/browse/GERONIMO-2056 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Plugins Versions: 1.1 Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.2 The plugin.xml file modules/system/src/test-data/geronimo-plugins.xml is loaded with hardcoded version numbers. This needs to be corrected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2052) Dynamically added keystores never appear as unlocked
[ http://issues.apache.org/jira/browse/GERONIMO-2052?page=all ] Aaron Mulder resolved GERONIMO-2052: Resolution: Fixed Dynamically added keystores never appear as unlocked Key: GERONIMO-2052 URL: http://issues.apache.org/jira/browse/GERONIMO-2052 Project: Geronimo Type: Bug Security: public(Regular issues) Components: security, console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 config.xml has password settings, which should be enough, but the console does not see thme as unlocked on either the keystore screen or the Jetty HTTPS screen -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2050) Unlocking a trust store still prompts for private key selection/password
[ http://issues.apache.org/jira/browse/GERONIMO-2050?page=all ] Aaron Mulder resolved GERONIMO-2050: Resolution: Fixed Unlocking a trust store still prompts for private key selection/password Key: GERONIMO-2050 URL: http://issues.apache.org/jira/browse/GERONIMO-2050 Project: Geronimo Type: Bug Security: public(Regular issues) Components: security, console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2051) Console Jetty HTTPS connector has wrong trust store help text
[ http://issues.apache.org/jira/browse/GERONIMO-2051?page=all ] Aaron Mulder resolved GERONIMO-2051: Resolution: Fixed Console Jetty HTTPS connector has wrong trust store help text - Key: GERONIMO-2051 URL: http://issues.apache.org/jira/browse/GERONIMO-2051 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: GERONIMO-2051.patch The trust store text is the same as the key store text -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2049) Jetty HTTPS edit shows no keystores in list
[ http://issues.apache.org/jira/browse/GERONIMO-2049?page=all ] Aaron Mulder resolved GERONIMO-2049: Resolution: Fixed Jetty HTTPS edit shows no keystores in list --- Key: GERONIMO-2049 URL: http://issues.apache.org/jira/browse/GERONIMO-2049 Project: Geronimo Type: Bug Security: public(Regular issues) Components: web, security, console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 When adding a new HTTPS connector in Jetty, it shows a drop-down of available unlocked keystores with at least one private key. When editing the same keystore, the keystore list is empty. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2056) Plugins plugin.xml has hardcoded version numbers
[ http://issues.apache.org/jira/browse/GERONIMO-2056?page=comments#action_12413167 ] Matt Hogstrom commented on GERONIMO-2056: - I did at the time; but was a bit groggy and being mechanical chasing down the stinking SNAPSHOT versions. In retrospect, perhaps the term test-data should have been an indicator that I was being stoopid. Plugins plugin.xml has hardcoded version numbers Key: GERONIMO-2056 URL: http://issues.apache.org/jira/browse/GERONIMO-2056 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Plugins Versions: 1.1 Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.2 The plugin.xml file modules/system/src/test-data/geronimo-plugins.xml is loaded with hardcoded version numbers. This needs to be corrected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2056) Plugins plugin.xml has hardcoded version numbers
[ http://issues.apache.org/jira/browse/GERONIMO-2056?page=all ] Matt Hogstrom closed GERONIMO-2056: --- Resolution: Fixed Plugins plugin.xml has hardcoded version numbers Key: GERONIMO-2056 URL: http://issues.apache.org/jira/browse/GERONIMO-2056 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Plugins Versions: 1.1 Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.2 The plugin.xml file modules/system/src/test-data/geronimo-plugins.xml is loaded with hardcoded version numbers. This needs to be corrected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: trunk 1.2-SNAPSHOT is now live !
Good point. Kevan will need to give us a read on where we stand. I heard there were some hiccups in that area a little bit ago. Kevan, any guesstimate on how long ? Rick, take your finger away from the keyboard :) Dain Sundstrom wrote: Great work Matt! Don't we want to wait until the tck is running before we start piling code into 1.2? -dain On May 24, 2006, at 6:06 AM, Matt Hogstrom wrote: Rick McGuire wrote: Matt Hogstrom wrote: I implemented the changes in GERONIMO-2053 to save trunk as branches/dead-1.2 and bring branches/1.1 into trunk. If there are additional changes that are required to complete the conversion to 1.2-SNAPSHOT please document them in GERONIMO-2053 Is this for the work to pull changes from dead-1.2 into the new trunk, or is this for other sorts of issues? You can now grab anything you want from branches/dead-1.2 and merge it with trunk. http://issues.apache.org/jira/browse/GERONIMO-2053 so we can track them. I'll leave this open for a few days. Also, remember that any fixes made to branches/1.1 should also be applied to trunk. Can we start moving code from dead-1.2 into trunk now? Yes. Cheers, Matt
Re: Apache Maven Repo Issue for 1.1 release
It sounds like there are really two issues IIUC. The first is that normal development is impeded because the sites mirroring Maven content are dynamic and because of circumstances beyond anyone's control give sporadic results. The second is the ability for a user to rebuild Geronimo n.n after we ship it because of problem number 1. Let me provide some input on these problems in reverse order. Regarding rebuilding shipped version of Geronimo I think having a saved copy of the repo used to build Geronimo makes sense. For 1.0 I still have that repo on stan.gbuild.org. Here is the size of the repo: -rw-r--r-- 1 hogstrom users 428521800 Dec 21 21:24 geronimo-1.0-maven-repo.tar.gz 428 MB doesn't seem too bad but is still a big chunk to download. We should make this available but if we get on the train for multiple point releases this may add up pretty quickly. I'm not an Infra person so I don't know if that's a number they would have concern about. Back to the first problem. I have a system that I use that rsyncs to the servers named in maven.remote property about 3 times a day. It works pretty good for me since my builds are at highly available LAN speeds. I think this would be the right solution for us as a team. At some point the instability will cause more and more people to do exactly what were discussing which may end up being at least part of the problem (doesn't solve the dynamic nature of the problem though). Would it make sense to use the same rsync commands I'm using for my internal repo and have one of the GBuild machines host this function? We have control of them and it is consistent with the way we're building and doing continuous builds anyway. Or can we simply put an HTTP server up and point to the maven repo used for GBuild anyway? Matt Kevan Miller wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get(HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: Move blocker GERONIMO-1960 to 1.1.1?
I agree that we should address this in 1.1.1. Another problem I ran into today is when a deployment fails and the artifacts are left in the repo but are unusable requiring a manual removal of the items. I need to see if there is an existing JIRA. Matt Aaron Mulder wrote: Well, I do feel that it's a pretty serious issue... Mainly because it's a hard-to-interpret error at an unfortunate time... The thing is distributed but not started so it seems kind of like it worked (e.g. the new thing appears in the console, etc.) but really it didn't. (I expect users to be able to understand error caused deployment to fail but not deployment succeeded but module still isn't running.) I guess I'm OK if this is deferred, but I don't really want to de-emphasize it much. Thanks, Aaron On 5/24/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On May 23, 2006, at 11:26 PM, David Jencks wrote: On May 23, 2006, at 11:04 PM, David Jencks wrote: +1 on excluding this from 1.1. I agree it's not a blocker. I think client-corba needs a dependency on client-security, I thought it was there. I'll try to investigate on the plane tomorrow. I expected you to fix this by modifying the ServiceConfigBuilder to check that the gbean reference was satisfied in the ancestor set when it is reading the xml. This is what the other builders do for e.g. resource-refs, and I think it would be simple and non- invasive. However, in any case I don't think this is a blocker the worst that can happen is that you get an error later rather than sooner, you get essentially the same effect either way. Umm, re this comment, I should think before writing :-) A moment's further thought reminded me that the reason we can check e.g. resource-refs when we process them is that we have a multistep process in the j2ee module builders and when we resolve the references we already know all the gbeans. This is not the case for service modules so the verify method you added or some other way of introducing 2 steps would be necessary. Bingo! It took me a few tries to get this patch right. My first attempt worked just as you suggested above (verify as reading the xml), and I ran into the problem where beans were referring to stuff further down in the file. My second attempt was to modify the ServiceConfigBuilder to verify after all beans had been added, but I ran into the problem where beans were referring to stuff in modules that hadn't been processed yet. My final attempt was to put the verify method in DeploymentContext and set it to verify when we call getConfigurationData(). Since this method is only called when the deployment is complete, all gbeans should be available. The patch does appear to work, but complexity of writing it made me nervous about putting it into 1.1. -dain
[jira] Commented: (GERONIMO-1832) Non-public Sun classes dependencies in tests
[ http://issues.apache.org/jira/browse/GERONIMO-1832?page=comments#action_12413171 ] Matt Hogstrom commented on GERONIMO-1832: - I want to come back and look at this one. I reviewed this patch and its a better solution than the one provided in 2057. However, these are bandaids to a larger problem which is multiple VMs and how to swap them in and out. Following the current patches one would have to chase down multiple modules which isn't going to scale. Either way this one will be closed. Non-public Sun classes dependencies in tests Key: GERONIMO-1832 URL: http://issues.apache.org/jira/browse/GERONIMO-1832 Project: Geronimo Type: Bug Security: public(Regular issues) Components: security Versions: 1.0 Reporter: Nellya Udovichenko Assignee: Matt Hogstrom Fix For: 1.1 Attachments: SubjectCarryingProtocolTest.patch org.apache.geronimo.security.network.protocol.SubjectCarryingProtocolTest imports com.sun.security.auth.login.ConfigFile class Test uses hardcoded internal Sun class so it doesn't work on non-Sun's VM. Attached patch adds the property 'auth.login.config' to file security/project.properties to setup needed configuration in test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Apache Maven Repo Issue for 1.1 release
Does that 428MB include the Geronimo distributioons themselves? I suspect so -- I use a 60MB .tar.bz2 (repository+source tree) for Geronimo 1.0 build tests (though I think that builds OpenEJB too so the size would vary if we use OpenEJB binaries). Thanks, Aaron On 5/24/06, Matt Hogstrom [EMAIL PROTECTED] wrote: It sounds like there are really two issues IIUC. The first is that normal development is impeded because the sites mirroring Maven content are dynamic and because of circumstances beyond anyone's control give sporadic results. The second is the ability for a user to rebuild Geronimo n.n after we ship it because of problem number 1. Let me provide some input on these problems in reverse order. Regarding rebuilding shipped version of Geronimo I think having a saved copy of the repo used to build Geronimo makes sense. For 1.0 I still have that repo on stan.gbuild.org. Here is the size of the repo: -rw-r--r-- 1 hogstrom users 428521800 Dec 21 21:24 geronimo-1.0-maven-repo.tar.gz 428 MB doesn't seem too bad but is still a big chunk to download. We should make this available but if we get on the train for multiple point releases this may add up pretty quickly. I'm not an Infra person so I don't know if that's a number they would have concern about. Back to the first problem. I have a system that I use that rsyncs to the servers named in maven.remote property about 3 times a day. It works pretty good for me since my builds are at highly available LAN speeds. I think this would be the right solution for us as a team. At some point the instability will cause more and more people to do exactly what were discussing which may end up being at least part of the problem (doesn't solve the dynamic nature of the problem though). Would it make sense to use the same rsync commands I'm using for my internal repo and have one of the GBuild machines host this function? We have control of them and it is consistent with the way we're building and doing continuous builds anyway. Or can we simply put an HTTP server up and point to the maven repo used for GBuild anyway? Matt Kevan Miller wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get(HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other repo sites (codehaus, mortbay, ibiblio) currently referenced by etc/project.properties. 4) Prepare a pre-packaged 1.1 maven repo which could be downloaded to allow users to acquire all the necessary dependencies needed to build 1.1. This means a geronimo src build could be completely independent of any web resource. Comments/suggestions welcome... --kevan
Re: svn commit: r409112 - EJB Performance Improvement of 6x (did I miss something ?)!
According to the ConcurrentReaderHashMap doc a Null value is returned if this value was added and
there are no dups. If there was a dup (meaning you did a get and on null a put in the example
below) then you'll get non-null value in return (meaning you now have more than one). If its now
positive then my put caused the cache to grow (simple race condition) so I remove it. Subsequent
get's will succeed and no more puts will be done. I think that net's out to a single entry and the
additional code is simply managing a race condition for the first to add to the Map.
Am I mis interpreting the code? I ran a test for 30 minutes and did not see the heap growing but
could add some diagnostic code to dump the count on every 1000n requests.
Matt
Dain Sundstrom wrote:
On May 24, 2006, at 3:30 AM, Matt Hogstrom wrote:
+private String getNormalizedCodebase(String codebase)
+throws MalformedURLException {
+String cachedCodebase = (String)cachedCodebases.get(codebase);
+if (cachedCodebase != null)
+return cachedCodebase;
+
+String normalizedCodebase = normalizeCodebase(codebase);
+String oldValue = (String)cachedCodebases.put(codebase,
normalizedCodebase);
+
+// If there was a previous value remove the one we just
added to make sure the
+// cache doesn't grow.
+if (oldValue != null) {
+cachedCodebases.remove(codebase);
+}
+return normalizedCodebase; // We can use the oldValue
+}
I don't get what you are trying to do here. It appears that you add the
value but if the map already contained the value you turn around and
remove it. I don't see how that stops the cache from growing. If you
want to prevent the cache from growing I think you need something like
this:
if (cache.size CACHE_LIMIT) {
cachedCodeBases.put(codebase, normalizedCodebase);
}
That isn't absolutely safe but is most likely good enough. The problem
is once the cache is full, you will never add another value.
Alternatively, you could drop something from the cache once it is full,
but you would have to figure out how to do it randomly since, you don't
have any data the entries.
You may want to consider switching the implementation to use a
LinkedHashMap with a size limit, so old values are pushed out. The
problem with a LinkedHashMap is you need to synchronize access. This
shouldn't be a big problem as long as you keep the synchronized blocks
small. I'd synchronized, check if the value exists, and if it didn't
add a future object to the map. Then you exist the synchronized block
and call get() on the future object. This causes the expensive
operation normalizedCodebase(codebase) to happen outside of the main
synchronize block.
Regardless, I'm +1 to this patch because it will work as it stands,
although with a small and very slow memory leak of one string per class
loader, and it is way better then what we had before which was nothing :)
-dain
Re: Change to commit model for Apache Geronimo
I didn't see a response to this yet, so here ya go... On Tue, May 23, 2006 at 04:40:57PM -0700, David Jencks wrote: ... This might be fine for simple uncontroversial patches such as this one, but there's a danger that this won't allow much time for review, especially for complicated changes such as occurred during the configid/1.1 development. Is there an apache standard minimum wait time or is this something we have to decide for ourselves? I think it will be hard to balance proceeding with further work with giving adequate review time. When calling for votes/opinions/consensus, the typical wait time is 72 hours. That is the generally-accepted value for people in all time zones have had a chance to see it, potentially working around travel and other real life issues. But code patches don't follow that model. See below: Personally I'm ok with committing immediately after 3 +1 votes and rolling back if there is a later -1. This is correct. Note that *your* +1 does not count, per Ken's instructions. Once you have those other +1 votes, then you can assume there is support for the change and go ahead and commit it. Note that a -1 can come in at *any* time. Whether 5 minutes later, 5 days, 5 weeks, or 5 months. Roy would even say 5 years, but I tend to disagree with that :-) The point is, that at any time, somebody should be able to say woah. that wasn't right, for these reasons. we shouldn't ship that change until we talk about this to figure out the right answer. It may take a while for somebody to realize the full ramifications of a change, which is why there is no statute of limitations on vetoes. That said: it is also polite to at least raise a concern before pulling out the veto card. A veto can be considered rather anti-social, so it is good to try and avoid them whenever possible. One of the best ways to do that is to avoid creating the situation in the first place. hmm. I think this code might not agree with everybody. let me post the patch to the list for discussion first. (of course, in RTC, that is always the case, so the idea is most important under the CTR model) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Move blocker GERONIMO-1960 to 1.1.1?
Don't most people just use the one step deploy instead of distribute then start. If I am correct, there should be very little difference in the user experience. -dain On May 24, 2006, at 11:21 AM, Aaron Mulder wrote: Well, I do feel that it's a pretty serious issue... Mainly because it's a hard-to-interpret error at an unfortunate time... The thing is distributed but not started so it seems kind of like it worked (e.g. the new thing appears in the console, etc.) but really it didn't. (I expect users to be able to understand error caused deployment to fail but not deployment succeeded but module still isn't running.) I guess I'm OK if this is deferred, but I don't really want to de-emphasize it much. Thanks, Aaron On 5/24/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On May 23, 2006, at 11:26 PM, David Jencks wrote: On May 23, 2006, at 11:04 PM, David Jencks wrote: +1 on excluding this from 1.1. I agree it's not a blocker. I think client-corba needs a dependency on client-security, I thought it was there. I'll try to investigate on the plane tomorrow. I expected you to fix this by modifying the ServiceConfigBuilder to check that the gbean reference was satisfied in the ancestor set when it is reading the xml. This is what the other builders do for e.g. resource-refs, and I think it would be simple and non- invasive. However, in any case I don't think this is a blocker the worst that can happen is that you get an error later rather than sooner, you get essentially the same effect either way. Umm, re this comment, I should think before writing :-) A moment's further thought reminded me that the reason we can check e.g. resource-refs when we process them is that we have a multistep process in the j2ee module builders and when we resolve the references we already know all the gbeans. This is not the case for service modules so the verify method you added or some other way of introducing 2 steps would be necessary. Bingo! It took me a few tries to get this patch right. My first attempt worked just as you suggested above (verify as reading the xml), and I ran into the problem where beans were referring to stuff further down in the file. My second attempt was to modify the ServiceConfigBuilder to verify after all beans had been added, but I ran into the problem where beans were referring to stuff in modules that hadn't been processed yet. My final attempt was to put the verify method in DeploymentContext and set it to verify when we call getConfigurationData(). Since this method is only called when the deployment is complete, all gbeans should be available. The patch does appear to work, but complexity of writing it made me nervous about putting it into 1.1. -dain
Re: Apache Maven Repo Issue for 1.1 release
Your right Aaron...my recollection was that this was a clean repo. After looking at the zip there was some CTS, other Geronimo artifacts, etc. Here is the current size after doing an rm -rf on three dirs that are not relevant. -rw-r--r-- 1 hogstrom users 52499153 May 24 12:50 processrepo.tar.gz That's cheap. Thanks! Aaron Mulder wrote: Does that 428MB include the Geronimo distributioons themselves? I suspect so -- I use a 60MB .tar.bz2 (repository+source tree) for Geronimo 1.0 build tests (though I think that builds OpenEJB too so the size would vary if we use OpenEJB binaries). Thanks, Aaron On 5/24/06, Matt Hogstrom [EMAIL PROTECTED] wrote: It sounds like there are really two issues IIUC. The first is that normal development is impeded because the sites mirroring Maven content are dynamic and because of circumstances beyond anyone's control give sporadic results. The second is the ability for a user to rebuild Geronimo n.n after we ship it because of problem number 1. Let me provide some input on these problems in reverse order. Regarding rebuilding shipped version of Geronimo I think having a saved copy of the repo used to build Geronimo makes sense. For 1.0 I still have that repo on stan.gbuild.org. Here is the size of the repo: -rw-r--r-- 1 hogstrom users 428521800 Dec 21 21:24 geronimo-1.0-maven-repo.tar.gz 428 MB doesn't seem too bad but is still a big chunk to download. We should make this available but if we get on the train for multiple point releases this may add up pretty quickly. I'm not an Infra person so I don't know if that's a number they would have concern about. Back to the first problem. I have a system that I use that rsyncs to the servers named in maven.remote property about 3 times a day. It works pretty good for me since my builds are at highly available LAN speeds. I think this would be the right solution for us as a team. At some point the instability will cause more and more people to do exactly what were discussing which may end up being at least part of the problem (doesn't solve the dynamic nature of the problem though). Would it make sense to use the same rsync commands I'm using for my internal repo and have one of the GBuild machines host this function? We have control of them and it is consistent with the way we're building and doing continuous builds anyway. Or can we simply put an HTTP server up and point to the maven repo used for GBuild anyway? Matt Kevan Miller wrote: Some of you may have noticed 1.1 build errors last week which were caused by the relocation of the Apache maven repo from 'cvs.apache.org/repository' to 'people.apache.org/repository'. It's my understanding from asfinfra that the maven repo will be moved to yet another location... And also that asfinfra does not feel that an apache maven repo will ever be allocated a permanent location. This repo move broke our 1.1 builds. And, FYI, also either broke or severly hampers builds of our 1.0 src distribution. Given current course and speed, a move from people.apache.org will break the 1.1 src distribution. FYI, an attempt to run an online build of tags/1.0.0 will result in multiple messages of the following form: Attempting to download geronimo-javamail_1.3.1_spec-1.0.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org to people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBase.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1089) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497) at org.apache.maven.wagon.providers.http.HttpWagon.get(HttpWagon.java:287) ... Invalid Redirect URI from: http://cvs.apache.org:80/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar to: http://people.apache.org/repository//org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.0.jar IIUC, maven purposely does not support http redirects. I'm not familiar with the reasons for this. I'm not aware of any work-around/configuration option for changing this behavior. I'm no expert in any of these maven/repo hosting matters. However, I have the following suggestions: 1) Add a comment to our download site that the 1.0 distribution requires a modification to etc/project.properties 2) Plan on removing the people.apache.org/repository from our project.properties file when the 1.1 release is tagged. 3) Review the permanence of the other
Re: Change to commit model for Apache Geronimo
A shot from the peanut gallery... :-) Doesn't that seem like a problem? That maybe there should be more people involved? That it shouldn't be I'm off in my corner working on this stuff. With nobody else. I dunno how to get my +1 votes. IMO, part of Geronimo's issue is growing the community of developers, and especially the group of committers. You'll solve your problem if you can get more people working with you. And I think you'll solve many of Geronimo's issues at the same time. IMO #2, I disagree with Ken's patched in and tested ... there are many changes that I've reviewed which I can give a +1 on just from eyeballing it. Or provide feedback on what needs to change. IOW, I don't always need a computer to tell me what it does. So I think it may be important to request that Ken officially relaxes that requirement a bit :-) Cheers, -g On Tue, May 23, 2006 at 12:38:11PM -0400, Matt Hogstrom wrote: Ken, et al, I'm not sure about other people's feelings regarding exceptions to the Review then commit but I'd like to request some special consideration for DevTools and DayTrader. Both of these dev trees are external to mainline Geronimo development and as such have a very limited set of people working on them. For Devtools I think it is Sachin and for DayTrader it is basically me for now. Based on the requirement for 3 +1s which implies testing and work I don't think we have enough active commiters in these branches to make this work. I would like to solicit input on and request an exception to Review and Commit for Devtools and DayTrader. Matt Jim Jagielski wrote: On May 22, 2006, at 2:49 AM, Jacek Laskowski wrote: On 5/22/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: Due to concerns about how some changes have been getting made in the codebase, I am changing the commit model for the time being. Effective immediately, the development model for Apache Geronimo is changed from Commit-Then-Review to Review-Then-Commit. Not that I don't like the idea as it may eventually help our community to understand changes before they get applied and keep up the pace, but... Shouldn't *your* decision be voted as well or at least discussed here openly, with the community to find out how they feel about our cooperation/openness? What message are we sending out if *you* step out and change the rules just like that? Just a thought many could have come up with after having read it. Just in case there is any confusion, Ken has the full support of the board regarding this. I'm saying this with my board hat on. In true ASF spirit, Ken discussed this with the board before making any decisions... -- Greg Stein, http://www.lyra.org/
Re: Clarification requests on RTC
On Tue, May 23, 2006 at 01:02:43PM -0700, David Jencks wrote: I'm unclear as to the required procedure for RTC. Is it required to literally include the patch contents in an email to the dev list or does a link to a JIRA issue suffice? A patch by reference is just fine. You're still getting multiple peers to look at and review/comment on the patch. It is no longer a solo action, but a group action. For an patch by a non-committer attached to a JIRA issue that I wish to apply, can I vote for it or does it in fact require 4 committer votes, as apparently a patch I come up with does? You're the committer offering up a patch that you believe should be committed to the repository. Sure, the patch happens to come from somebody else, but you're the committer. Get three peers to support you, and you're good to go. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: [Heads up] ServiceMix BeanFlow library available
Hi James, I also looked at BeanFlow and like the basic idea very much, except for the String constants; I guess that's the price of simplicity. My first idea was, however, to use this for multithreaded test case construction! :) These are always a total bear as you probably know. Unfortunately it turns out that only very coarse-grained scenarios could be modeled; for some things I'd need much better control over the timers: exact-start, better scheduling precision, better exception handling/collecting/correlation via the thread group etc. Maybe you have more ideas in that direction? I have an (arguably untypical) test case that really cooks my noodle any time I look at it and if BeanFlow could be used to correctly model execute that it could become an awesome basis for MT test modeling and execution. Drop me a line if you're interested. Holger
[jira] Updated: (GERONIMO-2049) Jetty HTTPS edit shows no keystores in list
[ http://issues.apache.org/jira/browse/GERONIMO-2049?page=all ] Paul McMahan updated GERONIMO-2049: --- Attachment: GERONIMO-2049.patch Aaron, I was working on a patch for this issue when I saw your commit go through. I realize that you already consider the issue to be resolved but I thought you still might want to take a peek at the patch because it addresses one additional problem not covered by your commit AFAICT. The problem is that if there are multiple keystores/truststores available when the editHTTPS.jsp form is loaded then the stores that are currently in use by the connector are not necessarily selected by default (even though they are available in the drop down list). An unwary user could accidentally change the keystore/truststore if they are not paying close attention. The patch also removes some unneeded code. Jetty HTTPS edit shows no keystores in list --- Key: GERONIMO-2049 URL: http://issues.apache.org/jira/browse/GERONIMO-2049 Project: Geronimo Type: Bug Security: public(Regular issues) Components: web, security, console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: GERONIMO-2049.patch When adding a new HTTPS connector in Jetty, it shows a drop-down of available unlocked keystores with at least one private key. When editing the same keystore, the keystore list is empty. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Remaining 1.1 Issues
Not a vote in any way, but experience has shown (in various other projects) that those last minute additions almost invariably cause problems :) On May 23, 2006, at 1:43 AM, Aaron Mulder wrote: I don't agree. 1.1 is not yet out the door, and if anything, it looks like 1.2 will take longer than anticipated. Minor changes, necessary, I vote 1.1. Remember, this change takes pressure off since we'll be able to release more features as plugins. I'm strongly in favor of taking things out of the critical path, whereas deferring to 1.2 will extend the critical path by another 3+ months. Thanks, Aaron On 5/22/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I agree that they are necessary. Let's put them in 1.2. 1.1 is almost out the door and adding new features at this point is very late in the game. We're currently 30 days past our original date and almost 5 months past the 1.0 release. Please defer these till 1.2. Matt Aaron Mulder wrote: We can call them what we want, but I think all the features are necessary, in particular in order to support plugins. The advantage of adding the first two features is that they let us take a lot of other features *out* of the critical path, and release them as plugins (also letting us support non-ASL licensed providers). Basically, the idea is to replace a properties file with a GBean, since you can't effectively add to a properties file at plugin installation time, but you can certainly add GBeans. Bottom line, it's a small impact change (console only, change the lookup logic that's already encapsulated in a helper class to do a GBean interface query instead of a properties file load), and it has significant benefits (new JMS providers or security providers can be added at runtime via plugins and do not need to be hardcoded into the Geronimo distribution). Thanks, Aaron On 5/22/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Based on the list below I think 1,2 and 3 are new function and 4 is a bug fix. Aaron Mulder wrote: Here are the things that I still want to squeeze into 1.1: - fix console JMS to accept new providers at runtime - fix console security realms to accept new providers at runtime - add a missing Geronimo security provider to console security realms - fix hot deploy dir so it notices files updated while the server was down and deletes files if they are undeployed some other way There are also AFAIK a number of not-yet-applied patches to review. Yes, there are several. I'm testing some performance related code. I'm waiting and hoping Codehaus comes up soon :) Thanks, Aaron
[jira] Created: (GERONIMO-2059) dependencies in etc/project.properties need to be updated to use the appropriate versions
dependencies in etc/project.properties need to be updated to use the appropriate versions - Key: GERONIMO-2059 URL: http://issues.apache.org/jira/browse/GERONIMO-2059 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1 Reporter: Kevan Miller Assigned to: Kevan Miller Priority: Minor Fix For: 1.1 A number of package dependencies need to be updated to their appropriate versions. They've been pending for some time due to various svn outages: axis_version=1.4 stax_version=1.1.2-dev stax_api_version=1.0.1 Changes will apply to both project.properties and explicit_versions.properties. I've also detected some incorrect versions for commons_io and commons_fileupload in explicit_versions.properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Change to commit model for Apache Geronimo
I agree that it would be nice to get more committers looking and working on DayTrader as well as DevTools. DayTrader we have been getting additional activity so we are moving in the right direction. Since its a performance/benchmark sample its very different than the server and has a different constituency. So, yes, its a problem however interest is growing so the problem is become less of an issue. Greg Stein wrote: A shot from the peanut gallery... :-) Doesn't that seem like a problem? That maybe there should be more people involved? That it shouldn't be I'm off in my corner working on this stuff. With nobody else. I dunno how to get my +1 votes. IMO, part of Geronimo's issue is growing the community of developers, and especially the group of committers. You'll solve your problem if you can get more people working with you. And I think you'll solve many of Geronimo's issues at the same time. IMO #2, I disagree with Ken's patched in and tested ... there are many changes that I've reviewed which I can give a +1 on just from eyeballing it. Or provide feedback on what needs to change. IOW, I don't always need a computer to tell me what it does. So I think it may be important to request that Ken officially relaxes that requirement a bit :-) I think the above was the most significant concern I had since the current lack of active participation (actually, folks really like the app as it uncovers broken pieces in the server that need to be fixed) I was concerned that getting people to install, test and validate was going to be difficult. If people can use their eyes thats fien. Right now its changing colors and packaging. IMHO DevTools is different in that few committers are running Eclipse and working in that area so getting meaningful feedback will be difficult. I guess time will tell but I'd hate to see Sachin get slowed down. Cheers, -g On Tue, May 23, 2006 at 12:38:11PM -0400, Matt Hogstrom wrote: Ken, et al, I'm not sure about other people's feelings regarding exceptions to the Review then commit but I'd like to request some special consideration for DevTools and DayTrader. Both of these dev trees are external to mainline Geronimo development and as such have a very limited set of people working on them. For Devtools I think it is Sachin and for DayTrader it is basically me for now. Based on the requirement for 3 +1s which implies testing and work I don't think we have enough active commiters in these branches to make this work. I would like to solicit input on and request an exception to Review and Commit for Devtools and DayTrader. Matt Jim Jagielski wrote: On May 22, 2006, at 2:49 AM, Jacek Laskowski wrote: On 5/22/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: Due to concerns about how some changes have been getting made in the codebase, I am changing the commit model for the time being. Effective immediately, the development model for Apache Geronimo is changed from Commit-Then-Review to Review-Then-Commit. Not that I don't like the idea as it may eventually help our community to understand changes before they get applied and keep up the pace, but... Shouldn't *your* decision be voted as well or at least discussed here openly, with the community to find out how they feel about our cooperation/openness? What message are we sending out if *you* step out and change the rules just like that? Just a thought many could have come up with after having read it. Just in case there is any confusion, Ken has the full support of the board regarding this. I'm saying this with my board hat on. In true ASF spirit, Ken discussed this with the board before making any decisions...
Re: Change to commit model for Apache Geronimo
On May 23, 2006, at 12:38 PM, Matt Hogstrom wrote: Ken, et al, I'm not sure about other people's feelings regarding exceptions to the Review then commit but I'd like to request some special consideration for DevTools and DayTrader. Both of these dev trees are external to mainline Geronimo development and as such have a very limited set of people working on them. For Devtools I think it is Sachin and for DayTrader it is basically me for now. Based on the requirement for 3 +1s which implies testing and work I don't think we have enough active commiters in these branches to make this work. IMO, this is a problem with these codebases then... The 3 +1s has been a very solid and reliable benchmark since before the start of the ASF. What can be done to increase involvement and diversity in those dev trees?
Re: Change to commit model for Apache Geronimo
Matt, I know of 3 additional who are committed to helping with DT (me as one of the 3)... We have some nice patches coming up... Dunno if that helps :/ Jeff Matt Hogstrom wrote: I agree that it would be nice to get more committers looking and working on DayTrader as well as DevTools. DayTrader we have been getting additional activity so we are moving in the right direction. Since its a performance/benchmark sample its very different than the server and has a different constituency. So, yes, its a problem however interest is growing so the problem is become less of an issue. Greg Stein wrote: A shot from the peanut gallery... :-) Doesn't that seem like a problem? That maybe there should be more people involved? That it shouldn't be I'm off in my corner working on this stuff. With nobody else. I dunno how to get my +1 votes. IMO, part of Geronimo's issue is growing the community of developers, and especially the group of committers. You'll solve your problem if you can get more people working with you. And I think you'll solve many of Geronimo's issues at the same time. IMO #2, I disagree with Ken's patched in and tested ... there are many changes that I've reviewed which I can give a +1 on just from eyeballing it. Or provide feedback on what needs to change. IOW, I don't always need a computer to tell me what it does. So I think it may be important to request that Ken officially relaxes that requirement a bit :-) I think the above was the most significant concern I had since the current lack of active participation (actually, folks really like the app as it uncovers broken pieces in the server that need to be fixed) I was concerned that getting people to install, test and validate was going to be difficult. If people can use their eyes thats fien. Right now its changing colors and packaging. IMHO DevTools is different in that few committers are running Eclipse and working in that area so getting meaningful feedback will be difficult. I guess time will tell but I'd hate to see Sachin get slowed down. Cheers, -g On Tue, May 23, 2006 at 12:38:11PM -0400, Matt Hogstrom wrote: Ken, et al, I'm not sure about other people's feelings regarding exceptions to the Review then commit but I'd like to request some special consideration for DevTools and DayTrader. Both of these dev trees are external to mainline Geronimo development and as such have a very limited set of people working on them. For Devtools I think it is Sachin and for DayTrader it is basically me for now. Based on the requirement for 3 +1s which implies testing and work I don't think we have enough active commiters in these branches to make this work. I would like to solicit input on and request an exception to Review and Commit for Devtools and DayTrader. Matt Jim Jagielski wrote: On May 22, 2006, at 2:49 AM, Jacek Laskowski wrote: On 5/22/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: Due to concerns about how some changes have been getting made in the codebase, I am changing the commit model for the time being. Effective immediately, the development model for Apache Geronimo is changed from Commit-Then-Review to Review-Then-Commit. Not that I don't like the idea as it may eventually help our community to understand changes before they get applied and keep up the pace, but... Shouldn't *your* decision be voted as well or at least discussed here openly, with the community to find out how they feel about our cooperation/openness? What message are we sending out if *you* step out and change the rules just like that? Just a thought many could have come up with after having read it. Just in case there is any confusion, Ken has the full support of the board regarding this. I'm saying this with my board hat on. In true ASF spirit, Ken discussed this with the board before making any decisions...
Re: Move blocker GERONIMO-1960 to 1.1.1?
Deploy reduces to distribute+start. If the distribute fails, the whole thing fails. If distribute works but start fails, it's left distributed but not started. We could try to undeploy if start fails, which should be a trivial change -- that's probably at least better than what we do now. What do you think? Thanks, Aaron On 5/24/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Don't most people just use the one step deploy instead of distribute then start. If I am correct, there should be very little difference in the user experience. -dain On May 24, 2006, at 11:21 AM, Aaron Mulder wrote: Well, I do feel that it's a pretty serious issue... Mainly because it's a hard-to-interpret error at an unfortunate time... The thing is distributed but not started so it seems kind of like it worked (e.g. the new thing appears in the console, etc.) but really it didn't. (I expect users to be able to understand error caused deployment to fail but not deployment succeeded but module still isn't running.) I guess I'm OK if this is deferred, but I don't really want to de-emphasize it much. Thanks, Aaron On 5/24/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On May 23, 2006, at 11:26 PM, David Jencks wrote: On May 23, 2006, at 11:04 PM, David Jencks wrote: +1 on excluding this from 1.1. I agree it's not a blocker. I think client-corba needs a dependency on client-security, I thought it was there. I'll try to investigate on the plane tomorrow. I expected you to fix this by modifying the ServiceConfigBuilder to check that the gbean reference was satisfied in the ancestor set when it is reading the xml. This is what the other builders do for e.g. resource-refs, and I think it would be simple and non- invasive. However, in any case I don't think this is a blocker the worst that can happen is that you get an error later rather than sooner, you get essentially the same effect either way. Umm, re this comment, I should think before writing :-) A moment's further thought reminded me that the reason we can check e.g. resource-refs when we process them is that we have a multistep process in the j2ee module builders and when we resolve the references we already know all the gbeans. This is not the case for service modules so the verify method you added or some other way of introducing 2 steps would be necessary. Bingo! It took me a few tries to get this patch right. My first attempt worked just as you suggested above (verify as reading the xml), and I ran into the problem where beans were referring to stuff further down in the file. My second attempt was to modify the ServiceConfigBuilder to verify after all beans had been added, but I ran into the problem where beans were referring to stuff in modules that hadn't been processed yet. My final attempt was to put the verify method in DeploymentContext and set it to verify when we call getConfigurationData(). Since this method is only called when the deployment is complete, all gbeans should be available. The patch does appear to work, but complexity of writing it made me nervous about putting it into 1.1. -dain
Re: Change to commit model for Apache Geronimo
I'd be happy to follow the dev of these 2 trees On May 24, 2006, at 5:09 PM, Matt Hogstrom wrote: I agree that it would be nice to get more committers looking and working on DayTrader as well as DevTools. DayTrader we have been getting additional activity so we are moving in the right direction. Since its a performance/benchmark sample its very different than the server and has a different constituency. So, yes, its a problem however interest is growing so the problem is become less of an issue. Greg Stein wrote: A shot from the peanut gallery... :-) Doesn't that seem like a problem? That maybe there should be more people involved? That it shouldn't be I'm off in my corner working on this stuff. With nobody else. I dunno how to get my +1 votes. IMO, part of Geronimo's issue is growing the community of developers, and especially the group of committers. You'll solve your problem if you can get more people working with you. And I think you'll solve many of Geronimo's issues at the same time. IMO #2, I disagree with Ken's patched in and tested ... there are many changes that I've reviewed which I can give a +1 on just from eyeballing it. Or provide feedback on what needs to change. IOW, I don't always need a computer to tell me what it does. So I think it may be important to request that Ken officially relaxes that requirement a bit :-) I think the above was the most significant concern I had since the current lack of active participation (actually, folks really like the app as it uncovers broken pieces in the server that need to be fixed) I was concerned that getting people to install, test and validate was going to be difficult. If people can use their eyes thats fien. Right now its changing colors and packaging. IMHO DevTools is different in that few committers are running Eclipse and working in that area so getting meaningful feedback will be difficult. I guess time will tell but I'd hate to see Sachin get slowed down. Cheers, -g On Tue, May 23, 2006 at 12:38:11PM -0400, Matt Hogstrom wrote: Ken, et al, I'm not sure about other people's feelings regarding exceptions to the Review then commit but I'd like to request some special consideration for DevTools and DayTrader. Both of these dev trees are external to mainline Geronimo development and as such have a very limited set of people working on them. For Devtools I think it is Sachin and for DayTrader it is basically me for now. Based on the requirement for 3 +1s which implies testing and work I don't think we have enough active commiters in these branches to make this work. I would like to solicit input on and request an exception to Review and Commit for Devtools and DayTrader. Matt Jim Jagielski wrote: On May 22, 2006, at 2:49 AM, Jacek Laskowski wrote: On 5/22/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: Due to concerns about how some changes have been getting made in the codebase, I am changing the commit model for the time being. Effective immediately, the development model for Apache Geronimo is changed from Commit-Then-Review to Review-Then-Commit. Not that I don't like the idea as it may eventually help our community to understand changes before they get applied and keep up the pace, but... Shouldn't *your* decision be voted as well or at least discussed here openly, with the community to find out how they feel about our cooperation/openness? What message are we sending out if *you* step out and change the rules just like that? Just a thought many could have come up with after having read it. Just in case there is any confusion, Ken has the full support of the board regarding this. I'm saying this with my board hat on. In true ASF spirit, Ken discussed this with the board before making any decisions...
Re: Remaining 1.1 Issues
Yeah, all right, but what's the difference between a late-breaking fix and a late-breaking feature of comparable size? Anything late-breaking is risky, but we now have the policy that 4 people will review it, plus we have a week to review the build before it becomes final, so what's the big deal? As much as I depress Alan, I don't think there's any point in griping about what goes where and when if we haven't decided what the cut-offs are going to be... If we said May 10, no more features, May 24 no more non-blocker bug fixes, fine. Except then if you want to put a non-blocker bug fix in on May 23, that's totally OK. In the future, let's make that kind of decision instead of the fuzzier I kind of feel uncomfortable with the idea as the build approaches. I'll carry on in another thread. :) Thanks, Aaron On 5/24/06, Jim Jagielski [EMAIL PROTECTED] wrote: Not a vote in any way, but experience has shown (in various other projects) that those last minute additions almost invariably cause problems :) On May 23, 2006, at 1:43 AM, Aaron Mulder wrote: I don't agree. 1.1 is not yet out the door, and if anything, it looks like 1.2 will take longer than anticipated. Minor changes, necessary, I vote 1.1. Remember, this change takes pressure off since we'll be able to release more features as plugins. I'm strongly in favor of taking things out of the critical path, whereas deferring to 1.2 will extend the critical path by another 3+ months. Thanks, Aaron On 5/22/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I agree that they are necessary. Let's put them in 1.2. 1.1 is almost out the door and adding new features at this point is very late in the game. We're currently 30 days past our original date and almost 5 months past the 1.0 release. Please defer these till 1.2. Matt Aaron Mulder wrote: We can call them what we want, but I think all the features are necessary, in particular in order to support plugins. The advantage of adding the first two features is that they let us take a lot of other features *out* of the critical path, and release them as plugins (also letting us support non-ASL licensed providers). Basically, the idea is to replace a properties file with a GBean, since you can't effectively add to a properties file at plugin installation time, but you can certainly add GBeans. Bottom line, it's a small impact change (console only, change the lookup logic that's already encapsulated in a helper class to do a GBean interface query instead of a properties file load), and it has significant benefits (new JMS providers or security providers can be added at runtime via plugins and do not need to be hardcoded into the Geronimo distribution). Thanks, Aaron On 5/22/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Based on the list below I think 1,2 and 3 are new function and 4 is a bug fix. Aaron Mulder wrote: Here are the things that I still want to squeeze into 1.1: - fix console JMS to accept new providers at runtime - fix console security realms to accept new providers at runtime - add a missing Geronimo security provider to console security realms - fix hot deploy dir so it notices files updated while the server was down and deletes files if they are undeployed some other way There are also AFAIK a number of not-yet-applied patches to review. Yes, there are several. I'm testing some performance related code. I'm waiting and hoping Codehaus comes up soon :) Thanks, Aaron
Review-Then-Commit conventions
Can we have the convention to preface the subject with [RTC] ? Regards, Alan
[jira] Commented: (GERONIMO-2059) dependencies in etc/project.properties need to be updated to use the appropriate versions
[ http://issues.apache.org/jira/browse/GERONIMO-2059?page=comments#action_12413185 ] Aaron Mulder commented on GERONIMO-2059: We'll need a more repeatable build of stax than 1.1.2-dev for our 1.1 release, right? dependencies in etc/project.properties need to be updated to use the appropriate versions - Key: GERONIMO-2059 URL: http://issues.apache.org/jira/browse/GERONIMO-2059 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem Versions: 1.1 Reporter: Kevan Miller Assignee: Kevan Miller Priority: Minor Fix For: 1.1 A number of package dependencies need to be updated to their appropriate versions. They've been pending for some time due to various svn outages: axis_version=1.4 stax_version=1.1.2-dev stax_api_version=1.0.1 Changes will apply to both project.properties and explicit_versions.properties. I've also detected some incorrect versions for commons_io and commons_fileupload in explicit_versions.properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-439) servicemix-beanflow - Workflow.joinAll failure to register onStop callback if first Activity stops during start handler
servicemix-beanflow - Workflow.joinAll failure to register onStop callback if
first Activity stops during start handler
---
Key: SM-439
URL: https://issues.apache.org/activemq/browse/SM-439
Project: ServiceMix
Type: Bug
Versions: incubation
Environment: osx, jdk 1.5
Reporter: Jason Anderson
if the following code is run the JoinFlow.stop state will never be thrown
because the internal JoinAll state is set to stopped after forking the first
activity in the JoinSupport(Activity ...) constructor before the onStop
callback is registered in WorkFlow.join
public class JoinTest extends TestCase {
public static class JoinFlow extends WorkflowJoinFlow.Step {
public static enum Step {
first, stop
}
public JoinFlow() {
super(Step.first);
}
public void first() {
final Activity a = new TimeoutActivity() {
protected void onValidStateChange() {
System.out.println(in a);
stop();
}
};
final Activity b = new TimeoutActivity() {
protected void onValidStateChange() {
System.out.println(in b);
stop();
}
};
System.out.println(in first);
joinAll(Step.stop, 1, a, b);
System.out.println(after join);
}
}
public void testJoin() throws Exception {
JoinFlow flow = new JoinFlow();
flow.start();
flow.join();
}
}
I believe if the JoinSupport were to add all the activities to the children
list before forking them it would prevent the JoinAll.onChildStateChange from
being called prematurely with childCount=1, stoppedCount=1 when there should be
2 children but I cannot currently get the maven build to run to test this thoery
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Review-Then-Commit conventions
+1 On May 24, 2006, at 5:36 PM, Alan D. Cabrera wrote: Can we have the convention to preface the subject with [RTC] ? Regards, Alan -sachin
Re: Review-Then-Commit conventions
+1, I like the idea of RTC, it has good benefits: Guarantees the quality of code. Guarantees the effeciency of the solution. Guarantees the distibution of knowledge among team. On 5/25/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Can we have the convention to preface the subject with [RTC] ?Regards,Alan
Re: Change to commit model for Apache Geronimo
I've been pondering the question for a while now... Up to this point, the primary individuals involved in the devtools subproject were either g-users or developers outside the geronimo community and this gives the illusion that there is a lack of interest in this subproject which I do not think is the case. So until we start attracting more tooling folks to the community I think development involvement doesn't necessarily have to start from code contribution, but it can start from a discussion and requirements perspective. And I think we are starting to do this. (Dain's and David J's work on ConfigStore enhancements for example have given them more insight as to what is being done in this area). As we move forward and we continue to enhance the integration within the tools and the runtime more of these discussions will occur making others more tools-aware, and hopefully this will start leading code contributions. So in short, I think its just a waiting game and over time I do believe we can get more involvement in these areas. - sachin On May 24, 2006, at 5:14 PM, Jim Jagielski wrote: On May 23, 2006, at 12:38 PM, Matt Hogstrom wrote: Ken, et al, I'm not sure about other people's feelings regarding exceptions to the Review then commit but I'd like to request some special consideration for DevTools and DayTrader. Both of these dev trees are external to mainline Geronimo development and as such have a very limited set of people working on them. For Devtools I think it is Sachin and for DayTrader it is basically me for now. Based on the requirement for 3 +1s which implies testing and work I don't think we have enough active commiters in these branches to make this work. IMO, this is a problem with these codebases then... The 3 +1s has been a very solid and reliable benchmark since before the start of the ASF. What can be done to increase involvement and diversity in those dev trees? -sachin
[jira] Commented: (GERONIMO-2059) dependencies in etc/project.properties need to be updated to use the appropriate versions
[ http://issues.apache.org/jira/browse/GERONIMO-2059?page=comments#action_12413189 ] Kevan Miller commented on GERONIMO-2059: Well, we shipped G 1.0 on stax-1.1.1-dev. Both stax-1.1.1-dev and stax-1.1.2-dev are in ibiblio. Previous discussions on the dev list referenced stax 1.1.2. stax-1.1.2-dev (http://www.ibiblio.org/maven/stax/jars/stax-1.1.2-dev.jar) was the only 1.1.2 distribution that I could find. Please let me know if there's a more appropriate version... I notice there's a new stax-api-1.0.1.jar dated March 14th. Is this something we should consider? dependencies in etc/project.properties need to be updated to use the appropriate versions - Key: GERONIMO-2059 URL: http://issues.apache.org/jira/browse/GERONIMO-2059 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem Versions: 1.1 Reporter: Kevan Miller Assignee: Kevan Miller Priority: Minor Fix For: 1.1 A number of package dependencies need to be updated to their appropriate versions. They've been pending for some time due to various svn outages: axis_version=1.4 stax_version=1.1.2-dev stax_api_version=1.0.1 Changes will apply to both project.properties and explicit_versions.properties. I've also detected some incorrect versions for commons_io and commons_fileupload in explicit_versions.properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
A request to contribute
Hi all Geronimo people... I am new to Geronimo, but I really want to help and contribute. I consulted dblevins cause I am more interested in OpenEJB, and from Geronimo dev-list I knew that Geronimo console needs people to work on. So I need to know what features needed to be done to see which I can contribute to. Thanks and best regards Mohammad Nour El-Din
Re: A request to contribute
Mohammed, Welcome. We are in the process of releasing 1.1 so that is where the action is. You can take a look at our JIRA system and get familiar with some of the defects we are focusing on for this release. You can get to JIRA at http://geronimo.apache.org and look for the JIRA link on the left side. From there take a peek at the link for 1.1 which will give you a list of defects. To start with this will at least help to get you familiar with some of the issues we are working on together. Matt Mohammed Nour wrote: Hi all *Geronimo* people... I am new to *Geronimo*, but I really want to help and contribute. I consulted *dblevins *cause I am more interested in *OpenEJB*, and from * Geronimo* dev-list I knew that Geronimo console needs people to work on. So I need to know what features needed to be done to see which I can contribute to. Thanks and best regards *Mohammad Nour El-Din*
Re: Remaining 1.1 Issues
I think we should stay focused on the blocker JIRAs for now as our whittle point as discussed earlier in this thread. Other fixes that address functional issues are fine as well. Once those are complete other things could be considered. Right now the significant blocking factor is Codehaus and the restoration of TranQL CVS. Aaron Mulder wrote: Yeah, all right, but what's the difference between a late-breaking fix and a late-breaking feature of comparable size? Anything late-breaking is risky, but we now have the policy that 4 people will review it, plus we have a week to review the build before it becomes final, so what's the big deal? As much as I depress Alan, I don't think there's any point in griping about what goes where and when if we haven't decided what the cut-offs are going to be... If we said May 10, no more features, May 24 no more non-blocker bug fixes, fine. Except then if you want to put a non-blocker bug fix in on May 23, that's totally OK. In the future, let's make that kind of decision instead of the fuzzier I kind of feel uncomfortable with the idea as the build approaches. I'll carry on in another thread. :) Thanks, Aaron On 5/24/06, Jim Jagielski [EMAIL PROTECTED] wrote: Not a vote in any way, but experience has shown (in various other projects) that those last minute additions almost invariably cause problems :) On May 23, 2006, at 1:43 AM, Aaron Mulder wrote: I don't agree. 1.1 is not yet out the door, and if anything, it looks like 1.2 will take longer than anticipated. Minor changes, necessary, I vote 1.1. Remember, this change takes pressure off since we'll be able to release more features as plugins. I'm strongly in favor of taking things out of the critical path, whereas deferring to 1.2 will extend the critical path by another 3+ months. Thanks, Aaron On 5/22/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I agree that they are necessary. Let's put them in 1.2. 1.1 is almost out the door and adding new features at this point is very late in the game. We're currently 30 days past our original date and almost 5 months past the 1.0 release. Please defer these till 1.2. Matt Aaron Mulder wrote: We can call them what we want, but I think all the features are necessary, in particular in order to support plugins. The advantage of adding the first two features is that they let us take a lot of other features *out* of the critical path, and release them as plugins (also letting us support non-ASL licensed providers). Basically, the idea is to replace a properties file with a GBean, since you can't effectively add to a properties file at plugin installation time, but you can certainly add GBeans. Bottom line, it's a small impact change (console only, change the lookup logic that's already encapsulated in a helper class to do a GBean interface query instead of a properties file load), and it has significant benefits (new JMS providers or security providers can be added at runtime via plugins and do not need to be hardcoded into the Geronimo distribution). Thanks, Aaron On 5/22/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Based on the list below I think 1,2 and 3 are new function and 4 is a bug fix. Aaron Mulder wrote: Here are the things that I still want to squeeze into 1.1: - fix console JMS to accept new providers at runtime - fix console security realms to accept new providers at runtime - add a missing Geronimo security provider to console security realms - fix hot deploy dir so it notices files updated while the server was down and deletes files if they are undeployed some other way There are also AFAIK a number of not-yet-applied patches to review. Yes, there are several. I'm testing some performance related code. I'm waiting and hoping Codehaus comes up soon :) Thanks, Aaron
Re: Change to commit model for Apache Geronimo
Jeff Genender wrote: Matt, I know of 3 additional who are committed to helping with DT (me as one of the 3)... We have some nice patches coming up... In the interests of being open and improving communications in the Geronimo community, could you please create some JIRAs for the work you are planning to do. Thanks, John Dunno if that helps :/ Jeff Matt Hogstrom wrote: I agree that it would be nice to get more committers looking and working on DayTrader as well as DevTools. DayTrader we have been getting additional activity so we are moving in the right direction. Since its a performance/benchmark sample its very different than the server and has a different constituency. So, yes, its a problem however interest is growing so the problem is become less of an issue. Greg Stein wrote: A shot from the peanut gallery... :-) Doesn't that seem like a problem? That maybe there should be more people involved? That it shouldn't be I'm off in my corner working on this stuff. With nobody else. I dunno how to get my +1 votes. IMO, part of Geronimo's issue is growing the community of developers, and especially the group of committers. You'll solve your problem if you can get more people working with you. And I think you'll solve many of Geronimo's issues at the same time. IMO #2, I disagree with Ken's patched in and tested ... there are many changes that I've reviewed which I can give a +1 on just from eyeballing it. Or provide feedback on what needs to change. IOW, I don't always need a computer to tell me what it does. So I think it may be important to request that Ken officially relaxes that requirement a bit :-) I think the above was the most significant concern I had since the current lack of active participation (actually, folks really like the app as it uncovers broken pieces in the server that need to be fixed) I was concerned that getting people to install, test and validate was going to be difficult. If people can use their eyes thats fien. Right now its changing colors and packaging. IMHO DevTools is different in that few committers are running Eclipse and working in that area so getting meaningful feedback will be difficult. I guess time will tell but I'd hate to see Sachin get slowed down. Cheers, -g On Tue, May 23, 2006 at 12:38:11PM -0400, Matt Hogstrom wrote: Ken, et al, I'm not sure about other people's feelings regarding exceptions to the Review then commit but I'd like to request some special consideration for DevTools and DayTrader. Both of these dev trees are external to mainline Geronimo development and as such have a very limited set of people working on them. For Devtools I think it is Sachin and for DayTrader it is basically me for now. Based on the requirement for 3 +1s which implies testing and work I don't think we have enough active commiters in these branches to make this work. I would like to solicit input on and request an exception to Review and Commit for Devtools and DayTrader. Matt Jim Jagielski wrote: On May 22, 2006, at 2:49 AM, Jacek Laskowski wrote: On 5/22/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: Due to concerns about how some changes have been getting made in the codebase, I am changing the commit model for the time being. Effective immediately, the development model for Apache Geronimo is changed from Commit-Then-Review to Review-Then-Commit. Not that I don't like the idea as it may eventually help our community to understand changes before they get applied and keep up the pace, but... Shouldn't *your* decision be voted as well or at least discussed here openly, with the community to find out how they feel about our cooperation/openness? What message are we sending out if *you* step out and change the rules just like that? Just a thought many could have come up with after having read it. Just in case there is any confusion, Ken has the full support of the board regarding this. I'm saying this with my board hat on. In true ASF spirit, Ken discussed this with the board before making any decisions...
