[jira] Created: (AMQ-711) commit() should not be called while in auto-commit mode
commit() should not be called while in auto-commit mode --- Key: AMQ-711 URL: https://issues.apache.org/activemq/browse/AMQ-711 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 RC3, 4.0 RC2 Environment: Windows NT SQLServer with jtds driver. Reporter: Niklas Käck Attachments: activemq.xml Unable to startup Broker Service. ERROR BrokerService - Failed to start ActiveMQ JMS Message Broker. Reason: java.io.IOException: commit() should not be called while in auto-commit mode. Stacktrace: java.io.IOException: commit() should not be called while in auto-commit mode. at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:42) at org.apache.activemq.store.jdbc.TransactionContext.close(TransactionContext.java:125) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.createAdapter(JDBCPersistenceAdapter.java:253) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.getAdapter(JDBCPersistenceAdapter.java:213) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.start(JDBCPersistenceAdapter.java:139) at org.apache.activemq.store.journal.JournalPersistenceAdapter.start(JournalPersistenceAdapter.java:215) at org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:907) at org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:867) at org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:453) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:362) at org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:43) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1058 ) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:363) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:275) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:318) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:158) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:48) at org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:40) at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:56) at org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:81) at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:46) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:49) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:64) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:49) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:45) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.activemq.console.Main.runTaskClass(Main.java:135) at org.apache.activemq.console.Main.main(Main.java:67) Caused by: java.sql.SQLException: commit() should not be called while in auto-commit mode. at net.sourceforge.jtds.jdbc.ConnectionJDBC2.commit(ConnectionJDBC2.java:1878) at org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:203) at org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:203) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:199) at org.apache.activemq.store.jdbc.TransactionContext.close(TransactionContext.java:119) Error message: ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService' defined in class path resource [activemq.xml]: Initialization of bean failed; nested exceptio n is java.io.IOException: commit() should not be called while in
Re: [VOTE] Release 4.0 of ActiveMQ
Thanks Hiram! Here's my +1 :) Regards, Jonas - Original Message - From: Hiram Chirino [EMAIL PROTECTED] To: activemq-dev@geronimo.apache.org Sent: Thursday, May 18, 2006 12:44 AM Subject: Re: [VOTE] Release 4.0 of ActiveMQ Hi Jonas, We has installed some RewriteRules to handle the changed links but the redirects do not seem to be working. So I just added a symbolic link that should take care of the problem once the content gets mirrors to the webserver. Regards, Hiram On 5/17/06, Jonas Lim [EMAIL PROTECTED] wrote: corrected some broken links on the readme on svn trunk . I wonder if we can create a new set of distro with this minor correction? regards, Jonas - Original Message - From: James Strachan [EMAIL PROTECTED] To: activemq-dev@geronimo.apache.org Sent: Wednesday, May 17, 2006 1:31 AM Subject: [VOTE] Release 4.0 of ActiveMQ 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 -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram
[jira] Resolved: (AMQ-629) test case SslTransportBrokerTest not working
[ https://issues.apache.org/activemq/browse/AMQ-629?page=all ] Adrian Co resolved AMQ-629: --- Resolution: Fixed Verified that this is passing on all boxes (iago, jafar, aladdin, spinach). Haven't checked on OSX though.. :( test case SslTransportBrokerTest not working Key: AMQ-629 URL: https://issues.apache.org/activemq/browse/AMQ-629 Project: ActiveMQ Type: Bug Components: Test Cases Reporter: james strachan Assignee: Adrian Co Fix For: 4.1 -- 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] Resolved: (AMQ-667) fix SslTransportBrokerTest
[ https://issues.apache.org/activemq/browse/AMQ-667?page=all ] Adrian Co resolved AMQ-667: --- Fix Version: 4.0 Resolution: Fixed Verified passing on iago, spinach, jafar, aladdin. Haven't verified with OS X though. fix SslTransportBrokerTest -- Key: AMQ-667 URL: https://issues.apache.org/activemq/browse/AMQ-667 Project: ActiveMQ Type: Test Components: Test Cases Reporter: james strachan Assignee: Adrian Co Fix For: 4.0 -- 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] Created: (SM-432) Security: Authorization broker
Security: Authorization broker -- Key: SM-432 URL: https://issues.apache.org/activemq/browse/SM-432 Project: ServiceMix Type: New Feature Components: servicemix-core Reporter: Guillaume Nodet Assigned to: Guillaume Nodet Fix For: 3.0-M2 -- 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] Created: (SM-433) Issue in the way servicemix handle soap errors
Issue in the way servicemix handle soap errors -- Key: SM-433 URL: https://issues.apache.org/activemq/browse/SM-433 Project: ServiceMix Type: Bug Components: servicemix-http Environment: Servicemix 3.0 ALL Reporter: Eric Dofonsou Fix For: 3.0 Attachments: ConsumerProcessor.java, ProviderProcessor.java With the current version of servicemix (3.0) , my soap fault message is replace by the following HTTP error message: -- html head titleError 500 Unknown Error/title /head body h2HTTP ERROR: 500/h2 preUnknown Error/pre pRequestURI=/Service//p p i small a href=http://jetty.mortbay.org;Powered by Jetty:///a /small /i /p /body /html because of this message, my generated stubs cannot properly handle the soap message. --- The best solution would be to have my soap fault message return to the calling client as is so all my business rules can be handle. After a few discussion with Guillaume, I've come up with a solution that handle sthe soap faul correctly, what this does is to no longer return an HTTP error message when we get a soap fault on the provider processeur. The soap fault is send as a property of the message to the consumer endpoint who then rebuild the soap fault (and does the conversion (1.1 - 1.2) if required. Ps : The conversion from 1.1 - 1.2 is not handle in this code (I had not quick means of testing it). Attached are the modified files : ConsumerProcessor.java, ProviderProcessor.java -- 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
build failure - problem with etc/explicit_versions.properties ?
I'm getting a build failure where the configurations Configuration for the J2EE Client build fails with SNIP Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve dependency org.apache.geronimo.specs/ geronimo-j2ee_1.4_spec/1.0/jar at org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:112) at org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:397) at org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:267) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.load(SimpleConfigurationManager.java:321) I noticed that the etc/explicit_versions.properties file has the entry: org.apache.geronimo.specs///=1.0 Should this be 1.1-SNAPSHOT as it doesn't seem to match what is in etc/project.properties (1.1-SNAPSHOT)? John
Re: Errors while building G1.1 from branch
Thanks Paul,Your hint works. My build is continuing further, but I am getting a few exceptions as copied below.Build is yet to complete and I will let you know the build status on Friday.Regards,Shiva ... ... ...Attempting to download geronimo-system-1.1-SNAPSHOT.jar.Error getting URI hostorg.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) .Invalid Redirect URI from: http://cvs.apache.org:80/repository//geronimo/jars/geronimo-system-1.1-SNAPSHOT.jar to: http://people.apache.org/repository//geronimo/jars/geronimo-system-1.1-SNAPSHOT.jarError retrieving artifact from [http://cvs.apache.org/repository]: org.apache.maven.wagon.TransferFailedException: Failed to trasfer file: http://cvs.apache.org/repository//geronimo/jars/geronimo-system-1.1-SNAPSHOT.jar. Return code is: 302 Error retrieving artifact from [http://dist.codehaus.org]: org.apache.maven.wagon.TransferFailedException: Connection refused: connectError retrieving artifact from [ http://www.ibiblio.org/maven]: org.apache.maven.wagon.TransferFailedException: Connection timed out: connectArtifact /geronimo/jars/geronimo-system-1.1-SNAPSHOT.jar doesn't exist in remote repository, but it exists locally.build:start:.Attempting to download geronimo-management-1.1-SNAPSHOT.jar.Error getting URI hostorg.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(HttpMethod Base.java:967)Error retrieving artifact from [http://cvs.apache.org/repository]: org.apache.maven.wagon.TransferFailedException : Failed to trasfer file: http://cvs.apache.org/repository//geronimo/jars/geronimo-management-1.1-SNAPSHOT.jar. Return code is:302Error retrieving artifact from [ http://dist.codehaus.org]: org.apache.maven.wagon.TransferFailedException: Connection refused: connect ... ... ...On 5/16/06, Paul McMahan [EMAIL PROTECTED] wrote: The suggestion I gave about rebuilding the plugins should help Vamsibut the problem Shiva is seeing is due to a change inetc/explicit_versions.properties.It looks like the problem is due to this entry in explicit_versions.properties : org.apache.geronimo.specs///=1.0taking precedence over this one :org.apache.geronimo.specs/geronimo-javamail_1.3.1_spec//=1.1-SNAPSHOTWhich causes the deployment routine to look fororg.apache.geronimo.specs /geronimo-javamail_1.3.1_spec/1.0/jarinstead oforg.apache.geronimo.specs/geronimo-javamail_1.3.1_spec/1.1-SNAPSHOT/jarThat's my best guess anyway.As a temporary workaround you should beable successfully build the client config by reverting the etc/ dir to its previous version (406805) while the geronimo devs straighten thisone out.Best wishes,PaulOn 5/16/06, Paul McMahan [EMAIL PROTECTED] wrote: I suggest rebuilding the plugins: cd to each plugin dir, maven clean default. Best wishes, Paul On 5/16/06, Shiva Kumar H R [EMAIL PROTECTED] wrote: Hi, I too am running into an error while building the AG 1.1 server. I am using the following command for building: maven maven -Dmaven.test.skip=true -Dmaven.itest.skip=true new, and the build is failing with the following exception and error. Any hints as to how I can resolve this, will be very much useful. + | configurations Configuration for the J2EE Client | Memory: 38M/51M + ... ... ... 16:55:13,187 ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentExcepti on: Unable to create configuration for deployment org.apache.geronimo.common.DeploymentException: Unable to create configuration f or deployment at org.apache.geronimo.deployment.DeploymentContext.createTempConfigurat ion(DeploymentContext.java:116) at org.apache.geronimo.deployment.DeploymentContext.init(DeploymentCon text.java:96) at org.apache.geronimo.deployment.DeploymentContext.init(DeploymentCon text.java:78) ... ... ... BUILD FAILED File.. E:\Geronimo\svn- win32-1.3.1\bin\g11\maven.xml Element... maven:reactor Line.. 58 Column -1 Unable to obtain goal [multiproject:install-callback] -- C:\Documents and Settin gs\Administrator\.maven\cache\geronimo-packaging-plugin-1.1.0-9\plugin.jelly:72: -1: car:package null Total time : 37 minutes 55 seconds Finished at: Tuesday, May 16, 2006 4:55:13 PM IST Thanks, Shiva
Re: build failure - problem with etc/explicit_versions.properties ?
On May 17, 2006, at 12:19 AM, John Sisson wrote: I'm getting a build failure where the configurations Configuration for the J2EE Client build fails with SNIP Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve dependency org.apache.geronimo.specs/ geronimo-j2ee_1.4_spec/1.0/jar at org.apache.geronimo.kernel.config.ConfigurationResolver.resolve (ConfigurationResolver.java:112) at org.apache.geronimo.kernel.config.Configuration.buildClassPath (Configuration.java:397) at org.apache.geronimo.kernel.config.Configuration.createConfigurationCla sssLoader(Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.init (Configuration.java:267) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.load (SimpleConfigurationManager.java:321) I noticed that the etc/explicit_versions.properties file has the entry: org.apache.geronimo.specs///=1.0 Should this be 1.1-SNAPSHOT as it doesn't seem to match what is in etc/project.properties (1.1-SNAPSHOT)? no :-) I think Kevan was working on this yesterday. Most of the specs should be at 1.0, which is what that entry is for. The 1.1-SNAPSHOT specs need explicit entries like org.apache.geronimo.specs/geronimo-j2ee_1.4_spec//jar=1.1-SNAPSHOT I believe he found a lot of errors such as leaviing off the type. I think the best plan would be to write something that would generate an explicit_versions.properties from the project.xml files filled in with project.properties, and have only these fully specified versions. However I haven't had time to do this and it might be reasonable to wait until m2. thanks david jencks John
[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: geronimo.patch This patch implements packaging for configurations which generate single artifact. For projects like 'daytrader' we might need to use attached artifacts. This is due to the fact that copying an artifact to M2 repostitory does not work. M2 generates files like maven-metadata-local.xml for each installed artifact. This implementation uses install:install for a single artifact. We need to decide how to handle multiple artifacts. This patch has been used to build the following configurations: geronimo-gbean-deployer j2ee-system client-system shutdown rmi-naming The 'modules' are not fully transported, i.e. the modules which are commented out in modules/pom.xml should be built using -Dmaven.skip.test=true. This implementation is likely to change soon as more things are added. 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, geronimo.patch, geronimo.patch, geronimo.patch, m2-plugins.patch, m2-plugins.patch 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: New Feature Wednesday
Hey !!! What happened to the builds that gbuild used to post daily to the repository directory at http://svn.apache.org/repository/geronimo/distribution ? Cheers Prasad On 5/12/06, David Blevins [EMAIL PROTECTED] wrote: On May 11, 2006, at 6:01 AM, Joe Bohn wrote: I agree with everyone else that it is really great to have these unstable builds being produced and posted on a regular basis! It will help encourage users to pick up the latest more quickly and provide us with quicker feedback. Definitely a good start. It takes group participation to really take advantage. How is it expected that users will find these unstable builds? We can link the Latest Unstable wiki page from the website. We can also mention them when we fix problems, I submitted/comitted a patch for this and it will be available in next Wednesday's build! (post link) Or when people have problems building, Give the latest unstable a try and see how it goes. (post link) Is there some way to get to the unstable builds from the geronimo web site? I think more people would find it and use it if there was a link from the downloads page to http://cvs.apache.org/dist/ geronimo/unstable/ . Absolutely. One more question: How long will these builds hang around? I see that there are still builds from 1.0 out there. The script arbitrarily keeps 14 past builds -- can be whatever number we choose. Just a nit - but it would be nice if we could put the most recent build at the top of the list. Sure. Most people don't notice that page is sortable. We can link it that way for convenience. http://cvs.apache.org/dist/geronimo/unstable/?C=M;O=D -David Joe David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Latest +Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
XBean website up
Now we've got the confluence - static html in subversion thing all squared away I've moved the existing XBean site over to Geronimo http://geronimo.apache.org/xbean/ which is all auto-generated and checked into svn updated on apache from the wiki http://goopen.org/confluence/display/XB (you can click on the edit page links on the bottom of a page to edit the pages in the wiki) There are some useful pages to help get to grips with how the site is layed out in terms of pages here http://geronimo.apache.org/xbean/site.html If folks wanted we could do the same thing with the confluence wiki content for the geronimo project too; then it can be hosted as static html at apache -- James --- http://radio.weblogs.com/0112098/
Re: 4.0 release comments
On May 17, 2006, at 10:03 AM, Hiram Chirino wrote: from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://cvs.apache.org/maven-snapshot-repository), codehaus-snapshot (http://snapshots.maven.codehaus.org/maven2), apache-maven1-snapshot (http://cvs.apache.org/repository), maven-csharp (http://maven-csharp.javaforge.com/repo) Perhaps one of the repositories is down. You could always manually download and install the dependency. :( Codehaus has been down for a while. Yea, rolling open source outages :( -Brian
Re: XBean website up
Nice! Do you think the system is flexible enough to render a site that looks like the G home page right now? --jason On May 17, 2006, at 9:43 AM, James Strachan wrote: Now we've got the confluence - static html in subversion thing all squared away I've moved the existing XBean site over to Geronimo http://geronimo.apache.org/xbean/ which is all auto-generated and checked into svn updated on apache from the wiki http://goopen.org/confluence/display/XB (you can click on the edit page links on the bottom of a page to edit the pages in the wiki) There are some useful pages to help get to grips with how the site is layed out in terms of pages here http://geronimo.apache.org/xbean/site.html If folks wanted we could do the same thing with the confluence wiki content for the geronimo project too; then it can be hosted as static html at apache -- James --- http://radio.weblogs.com/0112098/
Re: Errors while building G1.1 from branch
As of this morning you should be able to pick up the fix for explicit_versions.properties (r407124) and also the fix for the maven redirect problem you're seeing (r407165). If you hit a problem with maven not finding howl-logger-1.0.1.jar then you can download it from howl.objectweb.org and place it into your local maven repo (I think you will have to rename the file you download to match what maven looks for). There is a thread on the dev list right now about the problem with howl. Best wishes, Paul On 5/17/06, Shiva Kumar H R [EMAIL PROTECTED] wrote: Thanks Paul, Your hint works. My build is continuing further, but I am getting a few exceptions as copied below. Build is yet to complete and I will let you know the build status on Friday. Regards, Shiva ... ... ... Attempting to download geronimo-system-1.1-SNAPSHOT.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org t o people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpM ethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse ( HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethod Base.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.j ava:1089) ... ... ... Invalid Redirect URI from: http://cvs.apache.org:80/repository//geronimo/jars/ge ronimo-system-1.1-SNAPSHOT.jar to: http://people.apache.org/repository//geronimo /jars/geronimo-system-1.1-SNAPSHOT.jar Error retrieving artifact from [http://cvs.apache.org/repository]: org.apache.ma ven.wagon.TransferFailedException: Failed to trasfer file: http://cvs.apache.org /repository//geronimo/jars/geronimo-system-1.1-SNAPSHOT.jar. Return code is: 302 Error retrieving artifact from [http://dist.codehaus.org]: org.apache.maven.wago n.TransferFailedException: Connection refused: connect Error retrieving artifact from [ http://www.ibiblio.org/maven]: org.apache.maven. wagon.TransferFailedException: Connection timed out: connect Artifact /geronimo/jars/geronimo-system-1.1-SNAPSHOT.jar doesn't exist in remote repository, but it exists locally. build:start: ... ... ... Attempting to download geronimo-management-1.1-SNAPSHOT.jar. Error getting URI host org.apache.commons.httpclient.HttpException : Redirect from host cvs.apache.org t o people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpM ethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse( HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethod Base.java:967) Error retrieving artifact from [http://cvs.apache.org/repository]: org.apache.ma ven.wagon.TransferFailedException : Failed to trasfer file: http://cvs.apache.org /repository//geronimo/jars/geronimo-management-1.1-SNAPSHOT.jar. Return code is: 302 Error retrieving artifact from [ http://dist.codehaus.org]: org.apache.maven.wago n.TransferFailedException: Connection refused: connect ... ... ... On 5/16/06, Paul McMahan [EMAIL PROTECTED] wrote: The suggestion I gave about rebuilding the plugins should help Vamsi but the problem Shiva is seeing is due to a change in etc/explicit_versions.properties. It looks like the problem is due to this entry in explicit_versions.properties : org.apache.geronimo.specs///=1.0 taking precedence over this one : org.apache.geronimo.specs/geronimo-javamail_1.3.1_spec//=1.1-SNAPSHOT Which causes the deployment routine to look for org.apache.geronimo.specs /geronimo-javamail_1.3.1_spec/1.0/jar instead of org.apache.geronimo.specs/geronimo-javamail_1.3.1_spec/1.1-SNAPSHOT/jar That's my best guess anyway. As a temporary workaround you should be able successfully build the client config by reverting the etc/ dir to its previous version (406805) while the geronimo devs straighten this one out. Best wishes, Paul On 5/16/06, Paul McMahan [EMAIL PROTECTED] wrote: I suggest rebuilding the plugins: cd to each plugin dir, maven clean default. Best wishes, Paul On 5/16/06, Shiva Kumar H R [EMAIL PROTECTED] wrote: Hi, I too am running into an error while building the AG 1.1 server. I am using the following command for building: maven maven -Dmaven.test.skip=true -Dmaven.itest.skip=true new, and the build is failing with the following exception and error. Any hints as to how I can resolve this, will be very much useful. + | configurations Configuration for the J2EE Client | Memory: 38M/51M + ... ... ... 16:55:13,187 ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentExcepti on: Unable to create configuration for deployment org.apache.geronimo.common.DeploymentException:
Byte selector does not work
Hi, we're using active-mq 4.0-rc2 and realize that any message sent are
not received if we use a selector with a byte param. Here is the two
programs used to show this behavior. If we change this param from byte
to int it works. Is this a known bug ?
Some parts are not shown to make this sample smaller.
(MESSAGE SENDER)
..
public static void main(String[] args) throws Exception {
TopicPublisher publisher =
getSession().createPublisher(MessageClient.topic);
System.out.println(Started...);
Message msg = getSession().createMessage();
msg.setByteProperty(dummy, (byte) 33);
publisher.publish(msg);
System.out.println(Message sent.);
try {Thread.sleep(1);} catch (Exception exc) {}
publisher.close();
session.close();
conn.close();
System.out.println(Finished.);
}
(end)
(MESSAGE RECEIVER)
..
public static void main(String[] args) throws Exception {
JmsReceiverTest listen = new JmsReceiverTest();
System.out.println(Started...);
TopicSubscriber subscriber =
getSession().createSubscriber(MessageClient.topic, dummy = 33, false);
subscriber.setMessageListener(listen);
synchronized (listen) {
listen.wait(3);
}
subscriber.close();
session.close();
conn.close();
System.out.println(Finished.);
}
public void onMessage(Message msg) {
System.out.println(Message received.);
try {
for (Enumeration e = msg.getPropertyNames();
e.hasMoreElements();) {
String name = (String) e.nextElement();
System.out.println(Property name: + name + , value =
+ msg.getObjectProperty(name));
}
} catch (Exception exc) {
exc.printStackTrace();
}
this.notify();
}
(end)
--
MARCELO Ribeiro
DATACOM
Av. França, 735 - Porto Alegre, RS - 90230-220
DDR: 51 3358 0141
Fax: 51 3358 0101
site: www.datacom-telematica.com.br
e-mail: [EMAIL PROTECTED]
[jira] Updated: (GERONIMO-1860) Tests of optional ConfigID components
[ http://issues.apache.org/jira/browse/GERONIMO-1860?page=all ] Chris Cardona updated GERONIMO-1860: Attachment: testplans.zip I attached the plans I used for my tests (jar and configuration dependencies). The following are the results of my tests: - deploy a module with a JAR dependency where only the artifactId is specified Result: Deployed Plan: ... dep:dependency dep:artifactIdcommons-modeler/dep:artifactId /dep:dependency ... - deploy a module with a JAR dependency where only the artifactId and groupId are specified Result: Deployed Plan: ... dep:dependency dep:groupIdcommons-modeler/dep:groupId dep:artifactIdcommons-modeler/dep:artifactId /dep:dependency ... - deploy a module with a JAR dependency where the type is not specified Result: Deployed Plan: ... dep:dependency dep:groupIdcommons-modeler/dep:groupId dep:artifactIdcommons-modeler/dep:artifactId dep:version1.2-GERONIMO-SNAPSHOT/dep:version /dep:dependency ... - deploy a module with a JAR dependency where the version is not specified Result: Deployed Plan: ... dep:dependency dep:groupIdcommons-modeler/dep:groupId dep:artifactIdcommons-modeler/dep:artifactId dep:typejar/dep:type /dep:dependency ... - deploy a module with a configuration dependency where only the artifactId is specified Result: Not Deployed Error: Unable to distribute webapp.war: Unable to create configuration for deployment load of test/TestWebApp1/1.1/car failed Unable to resolve dependency /system-database//jar Plan: ... dep:dependency dep:artifactIdsystem-database/dep:artifactId /dep:dependency ... - deploy a module with a configuration dependency where only the artifactId and groupId are specified Result: Not Deployed Error: Unable to distribute webapp.war: Unable to create configuration for deployment load of test/TestWebApp1/1.1/car failed Unable to resolve dependency geronimo/system-database//jar Plan: ... dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdsystem-database/dep:artifactId /dep:dependency ... - deploy a module with a configuration dependency where the type is not specified Result: Not Deployed (assumes it's a jar) Error: Unable to distribute webapp.war: Unable to create configuration for deployment load of test/TestWebApp1/1.1/car failed Error starting configuration gbean test/TestWebApp1/1.1/car Unable to resolve dependency geronimo/system-database/1.1-SNAPSHOT/jar Plan: ... dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdsystem-database/dep:artifactId dep:version1.1-SNAPSHOT/dep:version /dep:dependency ... - deploy a module with a configuration dependency where the version is not specified Result: Deployed Deployed test/TestWebApp1/1.1/car @ http://CCARDONA:8080/testwebapp1 Plan: ... dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdsystem-database/dep:artifactId dep:typecar/dep:type /dep:dependency ... Tests of optional ConfigID components - Key: GERONIMO-1860 URL: http://issues.apache.org/jira/browse/GERONIMO-1860 Project: Geronimo Type: Test Security: public(Regular issues) Components: general Versions: 1.1 Reporter: Aaron Mulder Assignee: Paul McMahan Priority: Blocker Fix For: 1.1 Attachments: testplans.zip Before shipping 1.1, we need to make sure the following things work: - deploy a web app with no Geronimo plan - redeploy the same web app with no Geronimo plan - deploy a module with a Geronimo plan with an environment with no configId - redeploy the same module with a Geronimo plan with an environment with no configId - deploy a module with a Geronimo plan with no type in the configId - redeploy the same module with a Geronimo plan with no type in the configId - deploy a module with a Geronimo plan with no version in the configId - redeploy the same module with a Geronimo plan with no version in the configId - deploy a module with a Geronimo plan with no type or version in the configId - redeploy the same module with a Geronimo plan with no type or version in the configId - deploy a module with a Geronimo plan with only an artifactId in the configId - redeploy the same module with a Geronimo plan with only an artifactId in the configId - deploy a module with a JAR dependency where only the artifactId is specified - deploy a module with a JAR dependency where only the artifactId and groupId are specified - deploy a module
Re: Errors while building G1.1 from branch
Assuming you don't change the list of repositories in etc/project.properties you should pick up the howl jar from David's personal repo that he included as the last one in the list. So you shouldn't hit the howl problem or need to download yourself. Joe Paul McMahan wrote: As of this morning you should be able to pick up the fix for explicit_versions.properties (r407124) and also the fix for the maven redirect problem you're seeing (r407165). If you hit a problem with maven not finding howl-logger-1.0.1.jar then you can download it from howl.objectweb.org and place it into your local maven repo (I think you will have to rename the file you download to match what maven looks for). There is a thread on the dev list right now about the problem with howl. Best wishes, Paul On 5/17/06, Shiva Kumar H R [EMAIL PROTECTED] wrote: Thanks Paul, Your hint works. My build is continuing further, but I am getting a few exceptions as copied below. Build is yet to complete and I will let you know the build status on Friday. Regards, Shiva ... ... ... Attempting to download geronimo-system-1.1-SNAPSHOT.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host cvs.apache.org t o people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpM ethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse ( HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethod Base.java:967) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.j ava:1089) ... ... ... Invalid Redirect URI from: http://cvs.apache.org:80/repository//geronimo/jars/ge ronimo-system-1.1-SNAPSHOT.jar to: http://people.apache.org/repository//geronimo /jars/geronimo-system-1.1-SNAPSHOT.jar Error retrieving artifact from [http://cvs.apache.org/repository]: org.apache.ma ven.wagon.TransferFailedException: Failed to trasfer file: http://cvs.apache.org /repository//geronimo/jars/geronimo-system-1.1-SNAPSHOT.jar. Return code is: 302 Error retrieving artifact from [http://dist.codehaus.org]: org.apache.maven.wago n.TransferFailedException: Connection refused: connect Error retrieving artifact from [ http://www.ibiblio.org/maven]: org.apache.maven. wagon.TransferFailedException: Connection timed out: connect Artifact /geronimo/jars/geronimo-system-1.1-SNAPSHOT.jar doesn't exist in remote repository, but it exists locally. build:start: ... ... ... Attempting to download geronimo-management-1.1-SNAPSHOT.jar. Error getting URI host org.apache.commons.httpclient.HttpException : Redirect from host cvs.apache.org t o people.apache.org is not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect (HttpM ethodBase.java:1237) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse( HttpMethodBase.java:1185) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethod Base.java:967) Error retrieving artifact from [http://cvs.apache.org/repository]: org.apache.ma ven.wagon.TransferFailedException : Failed to trasfer file: http://cvs.apache.org /repository//geronimo/jars/geronimo-management-1.1-SNAPSHOT.jar. Return code is: 302 Error retrieving artifact from [ http://dist.codehaus.org]: org.apache.maven.wago n.TransferFailedException: Connection refused: connect ... ... ... On 5/16/06, Paul McMahan [EMAIL PROTECTED] wrote: The suggestion I gave about rebuilding the plugins should help Vamsi but the problem Shiva is seeing is due to a change in etc/explicit_versions.properties. It looks like the problem is due to this entry in explicit_versions.properties : org.apache.geronimo.specs///=1.0 taking precedence over this one : org.apache.geronimo.specs/geronimo-javamail_1.3.1_spec//=1.1-SNAPSHOT Which causes the deployment routine to look for org.apache.geronimo.specs /geronimo-javamail_1.3.1_spec/1.0/jar instead of org.apache.geronimo.specs/geronimo-javamail_1.3.1_spec/1.1-SNAPSHOT/jar That's my best guess anyway. As a temporary workaround you should be able successfully build the client config by reverting the etc/ dir to its previous version (406805) while the geronimo devs straighten this one out. Best wishes, Paul On 5/16/06, Paul McMahan [EMAIL PROTECTED] wrote: I suggest rebuilding the plugins: cd to each plugin dir, maven clean default. Best wishes, Paul On 5/16/06, Shiva Kumar H R [EMAIL PROTECTED] wrote: Hi, I too am running into an error while building the AG 1.1 server. I am using the following command for building: maven maven -Dmaven.test.skip=true -Dmaven.itest.skip=true new, and the build is failing with the following exception and error. Any hints as to how I can resolve this, will be very much useful. + | configurations Configuration for the J2EE
Re: New Feature Wednesday
Build's busted. three days now. On May 17, 2006, at 9:29 AM, Prasad Kashyap wrote: Hey !!! What happened to the builds that gbuild used to post daily to the repository directory at http://svn.apache.org/repository/geronimo/distribution ? Cheers Prasad On 5/12/06, David Blevins [EMAIL PROTECTED] wrote: On May 11, 2006, at 6:01 AM, Joe Bohn wrote: I agree with everyone else that it is really great to have these unstable builds being produced and posted on a regular basis! It will help encourage users to pick up the latest more quickly and provide us with quicker feedback. Definitely a good start. It takes group participation to really take advantage. How is it expected that users will find these unstable builds? We can link the Latest Unstable wiki page from the website. We can also mention them when we fix problems, I submitted/comitted a patch for this and it will be available in next Wednesday's build! (post link) Or when people have problems building, Give the latest unstable a try and see how it goes. (post link) Is there some way to get to the unstable builds from the geronimo web site? I think more people would find it and use it if there was a link from the downloads page to http://cvs.apache.org/dist/ geronimo/unstable/ . Absolutely. One more question: How long will these builds hang around? I see that there are still builds from 1.0 out there. The script arbitrarily keeps 14 past builds -- can be whatever number we choose. Just a nit - but it would be nice if we could put the most recent build at the top of the list. Sure. Most people don't notice that page is sortable. We can link it that way for convenience. http://cvs.apache.org/dist/geronimo/unstable/?C=M;O=D -David Joe David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Latest +Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: New Feature Wednesday
The problem is being caused by Codehaus being down. I've applied the OpenEJB patch from Jira 1434 to the version of OpenEJB on Continuum. This means the build should work. We should know shortly... --kevan On May 17, 2006, at 4:10 PM, David Blevins wrote: Build's busted. three days now. On May 17, 2006, at 9:29 AM, Prasad Kashyap wrote: Hey !!! What happened to the builds that gbuild used to post daily to the repository directory at http://svn.apache.org/repository/geronimo/distribution ? Cheers Prasad On 5/12/06, David Blevins [EMAIL PROTECTED] wrote: On May 11, 2006, at 6:01 AM, Joe Bohn wrote: I agree with everyone else that it is really great to have these unstable builds being produced and posted on a regular basis! It will help encourage users to pick up the latest more quickly and provide us with quicker feedback. Definitely a good start. It takes group participation to really take advantage. How is it expected that users will find these unstable builds? We can link the Latest Unstable wiki page from the website. We can also mention them when we fix problems, I submitted/comitted a patch for this and it will be available in next Wednesday's build! (post link) Or when people have problems building, Give the latest unstable a try and see how it goes. (post link) Is there some way to get to the unstable builds from the geronimo web site? I think more people would find it and use it if there was a link from the downloads page to http://cvs.apache.org/dist/ geronimo/unstable/ . Absolutely. One more question: How long will these builds hang around? I see that there are still builds from 1.0 out there. The script arbitrarily keeps 14 past builds -- can be whatever number we choose. Just a nit - but it would be nice if we could put the most recent build at the top of the list. Sure. Most people don't notice that page is sortable. We can link it that way for convenience. http://cvs.apache.org/dist/geronimo/unstable/?C=M;O=D -David Joe David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Latest +Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Contributions based on Copyrighted Material
Dear Developers, In response to Hernan's call for documentation contributions, I've started work on a Getting Started XDoc based on the Geronimo Quick Start section of Aaron Mulder's online book. However, it occurs to me that because the original material is copyrighted, this may not be such a good idea. At this point, I'm wondering if I shouldn't just start from scratch with entirely original content. Any guidance on this would be greatly appreciated. Thanks, 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
Re: XBean website up
Hey James, It looks great, you beat me on that one :) what are you using to export the content to HTML, any plugin in particular? Cheers! Hernan James Strachan wrote: Now we've got the confluence - static html in subversion thing all squared away I've moved the existing XBean site over to Geronimo http://geronimo.apache.org/xbean/ which is all auto-generated and checked into svn updated on apache from the wiki http://goopen.org/confluence/display/XB (you can click on the edit page links on the bottom of a page to edit the pages in the wiki) There are some useful pages to help get to grips with how the site is layed out in terms of pages here http://geronimo.apache.org/xbean/site.html If folks wanted we could do the same thing with the confluence wiki content for the geronimo project too; then it can be hosted as static html at apache
Re: XBean website up
What is goopen.org? James Strachan wrote: Now we've got the confluence - static html in subversion thing all squared away I've moved the existing XBean site over to Geronimo http://geronimo.apache.org/xbean/ which is all auto-generated and checked into svn updated on apache from the wiki http://goopen.org/confluence/display/XB (you can click on the edit page links on the bottom of a page to edit the pages in the wiki) There are some useful pages to help get to grips with how the site is layed out in terms of pages here http://geronimo.apache.org/xbean/site.html If folks wanted we could do the same thing with the confluence wiki content for the geronimo project too; then it can be hosted as static html at apache
Re: Contributions based on Copyrighted Material
[EMAIL PROTECTED] wrote: Dear Developers, In response to Hernan's call for documentation contributions, I've started work on a Getting Started XDoc based on the Geronimo Quick Start section of Aaron Mulder's online book. However, it occurs to me that because the original material is copyrighted, this may not be such a good idea. Not unless Aaron gives you permission, although you should clarify what you mean by based on. At this point, I'm wondering if I shouldn't just start from scratch with entirely original content. Any guidance on this would be greatly appreciated. Thanks, 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
Re: XBean website up
See http://www.mail-archive.com/activemq-dev@geronimo.apache.org/msg00662.html John Geir Magnusson Jr wrote: What is goopen.org? James Strachan wrote: Now we've got the confluence - static html in subversion thing all squared away I've moved the existing XBean site over to Geronimo http://geronimo.apache.org/xbean/ which is all auto-generated and checked into svn updated on apache from the wiki http://goopen.org/confluence/display/XB (you can click on the edit page links on the bottom of a page to edit the pages in the wiki) There are some useful pages to help get to grips with how the site is layed out in terms of pages here http://geronimo.apache.org/xbean/site.html If folks wanted we could do the same thing with the confluence wiki content for the geronimo project too; then it can be hosted as static html at apache
Re: XBean website up
Heh, maybe go is James' new Active I can see it now... GoMQ, GoIO, GoCluster -David On May 17, 2006, at 2:37 PM, Geir Magnusson Jr wrote: What is goopen.org? James Strachan wrote: Now we've got the confluence - static html in subversion thing all squared away I've moved the existing XBean site over to Geronimo http://geronimo.apache.org/xbean/ which is all auto-generated and checked into svn updated on apache from the wiki http://goopen.org/confluence/display/XB (you can click on the edit page links on the bottom of a page to edit the pages in the wiki) There are some useful pages to help get to grips with how the site is layed out in terms of pages here http://geronimo.apache.org/xbean/site.html If folks wanted we could do the same thing with the confluence wiki content for the geronimo project too; then it can be hosted as static html at apache
Re: XBean website up
Oh. I thought it was to cover in goop, as that API is really invasive - it will goopen your codebase... geir David Blevins wrote: Heh, maybe go is James' new Active I can see it now... GoMQ, GoIO, GoCluster -David On May 17, 2006, at 2:37 PM, Geir Magnusson Jr wrote: What is goopen.org? James Strachan wrote: Now we've got the confluence - static html in subversion thing all squared away I've moved the existing XBean site over to Geronimo http://geronimo.apache.org/xbean/ which is all auto-generated and checked into svn updated on apache from the wiki http://goopen.org/confluence/display/XB (you can click on the edit page links on the bottom of a page to edit the pages in the wiki) There are some useful pages to help get to grips with how the site is layed out in terms of pages here http://geronimo.apache.org/xbean/site.html If folks wanted we could do the same thing with the confluence wiki content for the geronimo project too; then it can be hosted as static html at apache
Re: XBean website up
LOL, i love it. First there was Jelly, then there was Groovy,... now meet Goopy. -David On May 17, 2006, at 4:42 PM, Geir Magnusson Jr wrote: Oh. I thought it was to cover in goop, as that API is really invasive - it will goopen your codebase... geir David Blevins wrote: Heh, maybe go is James' new Active I can see it now... GoMQ, GoIO, GoCluster -David On May 17, 2006, at 2:37 PM, Geir Magnusson Jr wrote: What is goopen.org? James Strachan wrote: Now we've got the confluence - static html in subversion thing all squared away I've moved the existing XBean site over to Geronimo http://geronimo.apache.org/xbean/ which is all auto-generated and checked into svn updated on apache from the wiki http://goopen.org/confluence/display/XB (you can click on the edit page links on the bottom of a page to edit the pages in the wiki) There are some useful pages to help get to grips with how the site is layed out in terms of pages here http://geronimo.apache.org/xbean/site.html If folks wanted we could do the same thing with the confluence wiki content for the geronimo project too; then it can be hosted as static html at apache
[jira] Created: (GERONIMO-2032) [console] Some input and output streams are not closed in finally blocks
[console] Some input and output streams are not closed in finally blocks Key: GERONIMO-2032 URL: http://issues.apache.org/jira/browse/GERONIMO-2032 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson 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] Created: (GERONIMO-2033) [axis] ensure input streams are closed in finally blocks
[axis] ensure input streams are closed in finally blocks Key: GERONIMO-2033 URL: http://issues.apache.org/jira/browse/GERONIMO-2033 Project: Geronimo Type: Bug Security: public (Regular issues) Components: webservices Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Minor 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
Re: [VOTE] Release 4.0 of ActiveMQ
On 5/16/06, James Strachan [EMAIL PROTECTED] 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. +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
[jira] Created: (GERONIMO-2034) [deployment] ensure output streams are closed in finally blocks
[deployment] ensure output streams are closed in finally blocks --- Key: GERONIMO-2034 URL: http://issues.apache.org/jira/browse/GERONIMO-2034 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Minor 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] Created: (GERONIMO-2035) [kernel, system] ensure input and output streams are closed in finally blocks
[kernel, system] ensure input and output streams are closed in finally blocks - Key: GERONIMO-2035 URL: http://issues.apache.org/jira/browse/GERONIMO-2035 Project: Geronimo Type: Bug Security: public (Regular issues) Components: core, kernel Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Minor 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] Created: (GERONIMO-2036) SingleFileHotDeployer doesn't undeploy app on force if directory has changed
SingleFileHotDeployer doesn't undeploy app on force if directory has changed Key: GERONIMO-2036 URL: http://issues.apache.org/jira/browse/GERONIMO-2036 Project: Geronimo Type: Bug Security: public (Regular issues) Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assigned to: Joe Bohn Fix For: 1.1 When using the SingleFileHotDeployer with force deployment the image cannot be copied to a new directory structure or tolerate the directory being renamed. If this is done and the hot deployer attempts to redeploy the application the result will be a failure to deploy because a configuration with the same ID already exists. The right best way to fix this would be to associate relative paths with the configurations rather than the resolved paths. However, that fix is a bit complication for this point in the 1.1 release. Therefore, this fix which is local to just SingleFileHotDeploy will check for an installed configuration with the same ID if we are about to force deploy an application and we haven't found a matching configuration already using the resolved path. -- 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-2036) SingleFileHotDeployer doesn't undeploy app on force if directory has changed
[ http://issues.apache.org/jira/browse/GERONIMO-2036?page=all ] Joe Bohn updated GERONIMO-2036: --- Attachment: 2036_SFHD.patch Patch was created on windows XP from geronimo root directory. SingleFileHotDeployer doesn't undeploy app on force if directory has changed Key: GERONIMO-2036 URL: http://issues.apache.org/jira/browse/GERONIMO-2036 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 1.1 Attachments: 2036_SFHD.patch When using the SingleFileHotDeployer with force deployment the image cannot be copied to a new directory structure or tolerate the directory being renamed. If this is done and the hot deployer attempts to redeploy the application the result will be a failure to deploy because a configuration with the same ID already exists. The right best way to fix this would be to associate relative paths with the configurations rather than the resolved paths. However, that fix is a bit complication for this point in the 1.1 release. Therefore, this fix which is local to just SingleFileHotDeploy will check for an installed configuration with the same ID if we are about to force deploy an application and we haven't found a matching configuration already using the resolved path. -- 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-2036) SingleFileHotDeployer doesn't undeploy app on force if directory has changed
[ http://issues.apache.org/jira/browse/GERONIMO-2036?page=all ] Joe Bohn updated GERONIMO-2036: --- Description: When using the SingleFileHotDeployer with force deployment the image cannot be copied to a new directory structure or tolerate the directory being renamed. If this is done and the hot deployer attempts to redeploy the application the result will be a failure to deploy because a configuration with the same ID already exists. The best way to fix this would be to associate relative paths with the configurations rather than the resolved paths. However, that fix is a bit complication for this point in the 1.1 release. Therefore, this fix which is local to just SingleFileHotDeploy will check for an installed configuration with the same ID if we are about to force deploy an application and we haven't found a matching configuration already using the resolved path. was: When using the SingleFileHotDeployer with force deployment the image cannot be copied to a new directory structure or tolerate the directory being renamed. If this is done and the hot deployer attempts to redeploy the application the result will be a failure to deploy because a configuration with the same ID already exists. The right best way to fix this would be to associate relative paths with the configurations rather than the resolved paths. However, that fix is a bit complication for this point in the 1.1 release. Therefore, this fix which is local to just SingleFileHotDeploy will check for an installed configuration with the same ID if we are about to force deploy an application and we haven't found a matching configuration already using the resolved path. SingleFileHotDeployer doesn't undeploy app on force if directory has changed Key: GERONIMO-2036 URL: http://issues.apache.org/jira/browse/GERONIMO-2036 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 1.1 Attachments: 2036_SFHD.patch When using the SingleFileHotDeployer with force deployment the image cannot be copied to a new directory structure or tolerate the directory being renamed. If this is done and the hot deployer attempts to redeploy the application the result will be a failure to deploy because a configuration with the same ID already exists. The best way to fix this would be to associate relative paths with the configurations rather than the resolved paths. However, that fix is a bit complication for this point in the 1.1 release. Therefore, this fix which is local to just SingleFileHotDeploy will check for an installed configuration with the same ID if we are about to force deploy an application and we haven't found a matching configuration already using the resolved path. -- 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-2037) Build failing on some Windows boxes and Solaris x86
Build failing on some Windows boxes and Solaris x86 --- Key: GERONIMO-2037 URL: http://issues.apache.org/jira/browse/GERONIMO-2037 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Environment: Windows XP - 1.4.2_11-b06 Solaris x86 - 1.4.2_10-b03 Reporter: John Sisson Priority: Blocker Fix For: 1.1 I can build geronimo on my windows notebook ok (with the GERONIMO-1434 openejb patch applied). But when I try to build on my windows desktop (tried latest 1.4.2_11-b06 jvm) it fails with a JVM crash. I found that whilst running with diagnostic code enabled (slowing the build down) the build worked on my windows desktop. I think Joe Bohn had also run into this crash on Windows. I didn't get a JVM crash on Solaris x86, but got a ClassDefNotFoundException (see below) in the same part of the build that had the JVM crash. *Windows Output *** 13:12:30,732 INFO [ReactorTag] | configurations Geronimo Configuration for performing service deployments 13:12:30,732 INFO [ReactorTag] | Memory: 96M/103M build:start: multiproject:install-callback: [echo] Running car:install for Geronimo Configuration for performing service deployments # # An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7c92ae22, pid=5240, tid=4788 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_11-b06 mixed mode) # Problematic frame: # C [ntdll.dll+0x2ae22] # --- T H R E A D --- Current thread (0x000377a8): JavaThread main [_thread_in_native, id=4788] siginfo: ExceptionCode=0xc005, reading address 0xd1d7763b Registers: EAX=0x00048b77, EBX=0x, ECX=0xd1d7763b, EDX=0x00030608 ESP=0x0007d858, EBP=0x0007d914, ESI=0x030654d0, EDI=0x0003 EIP=0x7c92ae22, EFLAGS=0x00010213 Top of Stack: (sp=0x0007d858) 0x0007d858: 77c2c21b 030654f0 04ba4238 0356 0x0007d868: 04ba4238 0008 000e 7ffdd000 0x0007d878: 001e 7ffdd000 000377a8 0007d860 0x0007d888: 63617061 0007d8fc 7c8399f3 7c809bd8 0x0007d898: d1d7763b 77c2f941 00048b77 0x0007d8a8: 030654d0 001e 0007d8c4 0x0007d8b8: 77c62448 01d4 004d 001e 0x0007d8c8: 001e 77c2e556 02fa1bd8 0007d90c Instructions: (pc=0x7c92ae22) 0x7c92ae12: 75 cc 89 75 94 8b 06 89 45 90 8b 4e 04 89 4d 88 0x7c92ae22: 8b 11 3b 50 04 0f 85 93 d1 ff ff 3b d6 0f 85 8b Stack: [0x0004,0x0008), sp=0x0007d858, free space=246k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [ntdll.dll+0x2ae22] C [MSVCRT.dll+0x1c2de] C [zip.dll+0x7a50] C [zip.dll+0x7792] C [zip.dll+0x1b2c] J java.util.zip.ZipFile.getEntry(JLjava/lang/String;)J J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; J java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; J java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry; J sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; J sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; J java.net.URLClassLoader$1.run()Ljava/lang/Object; v ~StubRoutines::call_stub V [jvm.dll+0x72846] V [jvm.dll+0xac976] V [jvm.dll+0x72753] V [jvm.dll+0x881d7] C [java.dll+0x1061] J java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class; J java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; J java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class; J java.lang.ClassLoader.loadClassInternal(Ljava/lang/String;)Ljava/lang/Class; v ~StubRoutines::call_stub V [jvm.dll+0x72846] V [jvm.dll+0xac976] V [jvm.dll+0x72753] V [jvm.dll+0x7255b] V [jvm.dll+0x725d3] V [jvm.dll+0xc40e0] V [jvm.dll+0xc3d47] V [jvm.dll+0xc3836] V [jvm.dll+0xc3745] V [jvm.dll+0xb6a18] V [jvm.dll+0xb6bca] V [jvm.dll+0xb6de3] V [jvm.dll+0x88ea7] j java.lang.Class.getDeclaredMethods0(Z)[Ljava/lang/reflect/Method;+0 J java.lang.Class.privateGetDeclaredMethods(Z)[Ljava/lang/reflect/Method; v ~RuntimeStub::alignment_frame_return Runtime1 stub j java.lang.Class.getDeclaredMethods()[Ljava/lang/reflect/Method;+10 j java.beans.Introspector$1.run()Ljava/lang/Object;+4 v ~StubRoutines::call_stub V [jvm.dll+0x72846] V [jvm.dll+0xac976] V [jvm.dll+0x72753] V [jvm.dll+0x881d7] C [java.dll+0x1015] J java.beans.Introspector.getPublicDeclaredMethods(Ljava/lang/Class;)[Ljava/lang/reflect/Method; J java.beans.Introspector.getTargetMethodInfo()[Ljava/beans/MethodDescriptor; v ~RuntimeStub::alignment_frame_return Runtime1 stub j java.beans.Introspector.getBeanInfo()Ljava/beans/BeanInfo;+6 j java.beans.Introspector.getBeanInfo(Ljava/lang/Class;)Ljava/beans/BeanInfo;+48 J
