[jira] Created: (GERONIMO-1359) Connector deployer fails for plans with no parent ID
Connector deployer fails for plans with no parent ID Key: GERONIMO-1359 URL: http://issues.apache.org/jira/browse/GERONIMO-1359 Project: Geronimo Type: Bug Components: deployment, connector Versions: 1.0 Reporter: Aaron Mulder Assigned to: Aaron Mulder Fix For: 1.0 When deploying a connector (in this case, a database pool) without a parentId, I get: Deployer operation failed: neither domain and server nor any way to determine them was provided for configuration user/database-pool-MySQL/1/car org.apache.geronimo.common.DeploymentException: neither domain and server nor any way to determine them was provided for configuration user/database-pool-MySQL/1/car at org.apache.geronimo.deployment.DeploymentContext.determineNaming(DeploymentContext.java:121) at org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:111) at org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:85) at org.apache.geronimo.j2ee.deployment.EARContext.init(EARContext.java:60) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:292) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:59) at java.lang.Thread.run(Thread.java:534) -- 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-1359) Connector deployer fails for plans with no parent ID
[ http://issues.apache.org/jira/browse/GERONIMO-1359?page=all ] Aaron Mulder resolved GERONIMO-1359: Resolution: Fixed Aaron checked in fix on 1.0 branch, David J on trunk Connector deployer fails for plans with no parent ID Key: GERONIMO-1359 URL: http://issues.apache.org/jira/browse/GERONIMO-1359 Project: Geronimo Type: Bug Components: deployment, connector Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Fix For: 1.0 When deploying a connector (in this case, a database pool) without a parentId, I get: Deployer operation failed: neither domain and server nor any way to determine them was provided for configuration user/database-pool-MySQL/1/car org.apache.geronimo.common.DeploymentException: neither domain and server nor any way to determine them was provided for configuration user/database-pool-MySQL/1/car at org.apache.geronimo.deployment.DeploymentContext.determineNaming(DeploymentContext.java:121) at org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:111) at org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:85) at org.apache.geronimo.j2ee.deployment.EARContext.init(EARContext.java:60) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:292) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:59) at java.lang.Thread.run(Thread.java:534) -- 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
test
test.
test
test.
Needed steps on sources
I'd like to know if we have to rename the packages to org.apache.servicemix.* or if we can keep the current ones org.servicemix.*. I think that we also have to modify the headers of all sources to include apache license, but i want to be sure about that. Also what copyright should be used, as currently, there are different one used, and some files do not have copyrights ? Cheers, Guillaume
Re: [Vote] Geronimo V1.0 Release binaries
This fix seems to have exposed an issue where the connector builder failed to deploy plans where no parent ID was specified (instead of using the configured default). David J and I have checked in a fix for that. I also fixed the problem where the j2ee-installer assembly failed on missing release notes. All that has been done as of SVN 356751. Aaron On 12/14/05, Aaron Mulder [EMAIL PROTECTED] wrote: I'm sorry to say, but -1: the console has a dangling SNAPSHOT that means that no database pools can be deployed from the database pool portlet. I put all the blame on the guy who did the SNAPSHOT cleanup in the branch, who was, umm, me. :) I checked the fix in to the 1.0 branch. Aaron On 12/14/05, Jason Dillon [EMAIL PROTECTED] wrote: Not gonna do a RCn series first? --jason On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt
Re: [Vote] Geronimo V1.0 Release binaries
Hi there, correction to my previous mail: 1) The strange split of all files between the two src archives was a failure on my side. Actually there are exactly the same files in both zip and tarball. 2) The problem with chopped off last characters in file names to some extent still exists, but it looks like a tar compatibility problem: a) Extracting with Solaris tar (even under Solaris 10) shows the problem b) Extracting with gtar 1.13 shows the problem. c) Extracting with gtar 1.14 does NOT show the problem I'm not sure, if the problem is a bug in the extracting tar, or in the archive building tar. The observation is not the usual imcompatibility betwenn standard tar and gtar relatet to path lengths. In the geronimo case the last character ist being chopped off. So I guess this situation now is mostly uncritical, although it would be nice to check, if it's a build side gnu tar problem. Sorry for the hassle Rainer
Nonsense error Module was not a wae when trying to deploy web-application on server with no running jetty-deployer
I recently experienced trouble deploying an ear file containing a war module. After a lot of head scratching (and waste of Aaron's time) I discovered that the source of the error was that the jetty-deployer wasn't started. The error returned by the deployer was Module was not a war: Adventure.war, which didn't help me a lot to say the least. The error is printed from EARConfigBuilder.java in module j2ee-builder. I'm on the 1.0 build being voted about earlier today. Transcript [1] at the bottom of this mail exposes the error. I know that I'm partly to blame (the jetty-deployer is active in the default configuration), but nonetheless someone might want to create a JIRA? Kindly, Jakob Transcript [1]: $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager distribute target/plan/consumerwebsit e1.0.1.ear-plan.xml adventure1.0.3/consumerwebsite.ear Distributed org/apache/geronimo/Adventure1.0.1 ~/projects/geronimo-ab/sandbox/adventurebuilder $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager stop geronimo/jetty-deployer/1.0/car Stopped geronimo/jetty-deployer/1.0/car ~/projects/geronimo-ab/sandbox/adventurebuilder $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager distribute target/plan/consumerwebsit e1.0.1.ear-plan.xml adventure1.0.3/consumerwebsite.ear Error: Operation failed: Module was not a war: adventure.war --- [2] Running configurations: + geronimo/activemq-broker/1.0/car + geronimo/j2ee-server/1.0/car + geronimo/jetty-deployer/1.0/car + geronimo/ldap-realm/1.0/car + geronimo/uddi-jetty/1.0/car `- uddi-jetty @ http://jrf:8080/juddi `- uddi-db + geronimo/online-deployer/1.0/car + geronimo/activemq/1.0/car + geronimo/directory/1.0/car + geronimo/j2ee-security/1.0/car + geronimo/j2ee-deployer/1.0/car + geronimo/system-database/1.0/car + geronimo/j2ee-system/1.0/car + geronimo/rmi-naming/1.0/car + geronimo/jetty/1.0/car + geronimo/webconsole-jetty/1.0/car `- geronimo-console-standard-1.0.war @ http://jrf:8080/console-standard `- geronimo-console-framework-1.0.war @ http://jrf:8080/console + geronimo/geronimo-gbean-deployer/1.0/car
Move JAXB spec to Geronimo
Hi, the JaxMe project contains a clean room implementation of the JAXB API 1.1. As future versions of J2EE will contain the JAXB API, I propose that these be moved to the other Geronimo J2EE spec implementations. Jochen -- Often it does seem a pity that Noah and his party did not miss the boat. (Mark Twain)
[OT] tar incompatibilities
Concerning my mails related to strange behaviour of the release tarballs: There is an incompatibility between gnu tar and other tars as well as different versions of gnu tar whenever the name of a file (including path) is exactly 100 chars long. POSIX allows exactly 100 chars without using extension mechanisms, newer gnu tars seem to use their own extension algorithm already starting with length 100. All files with strange behaviour in the release tarballs had path+file name exactly 100 chars long and the last char was chopped off whenever the extracting tar was not compatible (even gnu tar) with the building tar.
[jira] Created: (GERONIMO-1360) Misleading error for missing web deployer
Misleading error for missing web deployer - Key: GERONIMO-1360 URL: http://issues.apache.org/jira/browse/GERONIMO-1360 Project: Geronimo Type: Bug Components: deployment Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1 I recently experienced trouble deploying an ear file containing a war module. After a lot of head scratching (and waste of Aaron's time) I discovered that the source of the error was that the jetty-deployer wasn't started. The error returned by the deployer was Module was not a war: Adventure.war, which didn't help me a lot to say the least. The error is printed from EARConfigBuilder.java in module j2ee-builder. I'm on the 1.0 candidate build being voted about earlier today. Transcript [1] at the bottom of this mail exposes the error. I know that I'm partly to blame (the jetty-deployer is active in the default configuration), but nonetheless someone might want to create a JIRA? Kindly, Jakob Transcript [1]: $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager distribute target/plan/consumerwebsit e1.0.1.ear-plan.xml adventure1.0.3/consumerwebsite.ear Distributed org/apache/geronimo/Adventure1.0.1 ~/projects/geronimo-ab/sandbox/adventurebuilder $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager stop geronimo/jetty-deployer/1.0/car Stopped geronimo/jetty-deployer/1.0/car ~/projects/geronimo-ab/sandbox/adventurebuilder $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager distribute target/plan/consumerwebsit e1.0.1.ear-plan.xml adventure1.0.3/consumerwebsite.ear Error: Operation failed: Module was not a war: adventure.war --- [2] Running configurations: + geronimo/activemq-broker/1.0/car + geronimo/j2ee-server/1.0/car + geronimo/jetty-deployer/1.0/car + geronimo/ldap-realm/1.0/car + geronimo/uddi-jetty/1.0/car `- uddi-jetty @ http://jrf:8080/juddi `- uddi-db + geronimo/online-deployer/1.0/car + geronimo/activemq/1.0/car + geronimo/directory/1.0/car + geronimo/j2ee-security/1.0/car + geronimo/j2ee-deployer/1.0/car + geronimo/system-database/1.0/car + geronimo/j2ee-system/1.0/car + geronimo/rmi-naming/1.0/car + geronimo/jetty/1.0/car + geronimo/webconsole-jetty/1.0/car `- geronimo-console-standard-1.0.war @ http://jrf:8080/console-standard `- geronimo-console-framework-1.0.war @ http://jrf:8080/console + geronimo/geronimo-gbean-deployer/1.0/car -- 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] Geronimo V1.0 Release binaries
---BeginMessage--- In geronimo-tomcat-j2ee-1.0.zip i tried to deploy an ear application that was working in M4. with a few changes (new configid format groupId/artifactId/version/type) it started working. But i see following two modules throwing error (TradeEJB and ActiveMQActivationSpec) 15:54:18,747 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:EJBModule=daytrader-ejb-1.0.jar,J2EEApplication=geronimo/daytrader-derby-tomcat/1.0/car,J2EEServer=geronimo,j2eeType=MessageDrivenBean,name=TradeBrokerMDB because no targets are running for reference ActivationSpecWrapper matching the patterns geronimo.server:EJBModule=daytrader-ejb-1.0.jar,J2EEApplication=geronimo/daytrader-derby-tomcat/1.0/car,J2EEServer=geronimo,j2eeType=JCAActivationSpec,name=TradeBrokerMDB 15:54:20,715 WARN [SystemExceptionInterceptor] TradeEJB javax.ejb.NoSuchObjectLocalException: geronimo.server:EJBModule=daytrader-ejb-1.0.jar,J2EEApplication=geronimo/daytrader-derby-tomcat/1.0/car,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=KeySequenceEJB at org.openejb.proxy.EJBMethodInterceptor.createEJBInvocation(EJBMethodInterceptor.java:173) at org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:115) at org.openejb.proxy.SessionEJBLocalHome$$EnhancerByCGLIB$$dd240d0b.create(generated) at org.apache.geronimo.samples.daytrader.ejb.TradeBean.ejbCreate(TradeBean.java:1178) at org.apache.geronimo.samples.daytrader.ejb.TradeBean$$FastClassByCGLIB$$7b99417a.invoke(generated) at org.openejb.slsb.EJBCreateMethod.execute(EJBCreateMethod.java:94) at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72) at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56) at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81) at org.openejb.slsb.StatelessInstanceContext.ejbCreate(StatelessInstanceContext.java:168) at org.openejb.slsb.StatelessInstanceFactory.createInstance(StatelessInstanceFactory.java:74) at org.openejb.util.SoftLimitedInstancePool.acquire(SoftLimitedInstancePool.java:81) at org.openejb.slsb.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:84) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:140) at org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:80) at org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82) at org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238) at org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:129) at org.openejb.proxy.SessionEJBHome$$EnhancerByCGLIB$$9665b69e.create(generated) at org.apache.geronimo.samples.daytrader.direct.TradeDirect.init(TradeDirect.java:2265) at org.apache.geronimo.samples.daytrader.web.TradeWebContextListener.contextInitialized(TradeWebContextListener.java:33) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3692) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4127) at org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:64) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:267) at org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) at org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47) at org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60) at org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:187) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$8cdd2730.addContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:407) at
[jira] Created: (GERONIMO-1361) CMP having a compound PK with only one fields are not supported
CMP having a compound PK with only one fields are not supported --- Key: GERONIMO-1361 URL: http://issues.apache.org/jira/browse/GERONIMO-1361 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M5 Reporter: Gianny Damour Assigned to: Gianny Damour Priority: Minor Fix For: 1.0 I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN [SystemExceptionInterceptor] Product java.lang.ClassCastException at org.tranql.sql.jdbc.binding.StringBinding.setValue(StringBinding.java:43) at org.tranql.sql.jdbc.binding.TypeConverterBinding.setValue(TypeConverterBinding.java:93) at org.tranql.sql.jdbc.binding.TypeConverterBinding.setValue(TypeConverterBinding.java:89) at org.tranql.sql.jdbc.JDBCQueryCommand.execute(JDBCQueryCommand.java:64) at org.tranql.cache.cache.FindByPKCacheQueryCommand.execute(FindByPKCacheQueryCommand.java:6 6) at org.openejb.entity.cmp.CMPFinder.execute(CMPFinder.java:98) at org.openejb.entity.cmp.SingleValuedFinder.execute(SingleValuedFinder.java:80) at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72) at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterc eptor.java:56) at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81) at org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136) at org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:90) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:140) at org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextIntercepto r.java:80) at org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82) at org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238) at org.openejb.server.ejbd.EjbRequestHandler.invoke(EjbRequestHandler.java:297) at org.openejb.server.ejbd.EjbRequestHandler.doEjbHome_FIND(EjbRequestHandler.java:394) at org.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:209) at org.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:150) at org.openejb.server.ejbd.EjbServer.service(EjbServer.java:87) at org.openejb.server.ejbd.EjbServer$$FastClassByCGLIB$$d379d2ff.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor. java:96) at org.activeio.xnet.ServerService$$EnhancerByCGLIB$$e80ad14.service(generated) at org.activeio.xnet.ServicePool$2.run(ServicePool.java:67) at org.activeio.xnet.ServicePool$3.run(ServicePool.java:90) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:138) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) setEntityContext called ejbActivate() called. ejbLoad() called. ejb-jar.xml ?xml version=1.0? ejb-jar xmlns=http://java.sun.com/xml/ns/j2ee; version=2.1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd; display-nameProduct/display-name enterprise-beans entity ejb-nameProduct/ejb-name homeexamples.cmp.ProductHome/home remoteexamples.cmp.Product/remote ejb-classexamples.cmp.ProductBean/ejb-class persistence-typeContainer/persistence-type prim-key-classexamples.cmp.ProductPK/prim-key-class reentrantfalse/reentrant cmp-version2.x/cmp-version abstract-schema-namePRODUCTS/abstract-schema-name cmp-field field-nameproductID/field-name /cmp-field cmp-field field-namename/field-name /cmp-field cmp-field field-namedescription/field-name /cmp-field cmp-field field-namebasePrice/field-name /cmp-field !-- query query-method method-namefindByPrimaryKey/method-name
[jira] Updated: (GERONIMO-1361) CMP having a compound PK with only one field are not supported
[ http://issues.apache.org/jira/browse/GERONIMO-1361?page=all ] Gianny Damour updated GERONIMO-1361: Summary: CMP having a compound PK with only one field are not supported (was: CMP having a compound PK with only one fields are not supported) CMP having a compound PK with only one field are not supported -- Key: GERONIMO-1361 URL: http://issues.apache.org/jira/browse/GERONIMO-1361 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M5 Reporter: Gianny Damour Assignee: Gianny Damour Priority: Minor Fix For: 1.0 I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN [SystemExceptionInterceptor] Product java.lang.ClassCastException at org.tranql.sql.jdbc.binding.StringBinding.setValue(StringBinding.java:43) at org.tranql.sql.jdbc.binding.TypeConverterBinding.setValue(TypeConverterBinding.java:93) at org.tranql.sql.jdbc.binding.TypeConverterBinding.setValue(TypeConverterBinding.java:89) at org.tranql.sql.jdbc.JDBCQueryCommand.execute(JDBCQueryCommand.java:64) at org.tranql.cache.cache.FindByPKCacheQueryCommand.execute(FindByPKCacheQueryCommand.java:6 6) at org.openejb.entity.cmp.CMPFinder.execute(CMPFinder.java:98) at org.openejb.entity.cmp.SingleValuedFinder.execute(SingleValuedFinder.java:80) at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72) at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterc eptor.java:56) at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81) at org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136) at org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:90) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:140) at org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextIntercepto r.java:80) at org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82) at org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238) at org.openejb.server.ejbd.EjbRequestHandler.invoke(EjbRequestHandler.java:297) at org.openejb.server.ejbd.EjbRequestHandler.doEjbHome_FIND(EjbRequestHandler.java:394) at org.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:209) at org.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:150) at org.openejb.server.ejbd.EjbServer.service(EjbServer.java:87) at org.openejb.server.ejbd.EjbServer$$FastClassByCGLIB$$d379d2ff.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor. java:96) at org.activeio.xnet.ServerService$$EnhancerByCGLIB$$e80ad14.service(generated) at org.activeio.xnet.ServicePool$2.run(ServicePool.java:67) at org.activeio.xnet.ServicePool$3.run(ServicePool.java:90) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:138) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) setEntityContext called ejbActivate() called. ejbLoad() called. ejb-jar.xml ?xml version=1.0? ejb-jar xmlns=http://java.sun.com/xml/ns/j2ee; version=2.1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd; display-nameProduct/display-name enterprise-beans entity ejb-nameProduct/ejb-name homeexamples.cmp.ProductHome/home remoteexamples.cmp.Product/remote ejb-classexamples.cmp.ProductBean/ejb-class persistence-typeContainer/persistence-type prim-key-classexamples.cmp.ProductPK/prim-key-class reentrantfalse/reentrant cmp-version2.x/cmp-version abstract-schema-namePRODUCTS/abstract-schema-name
[jira] Closed: (GERONIMO-1361) CMP having a compound PK with only one field are not supported
[ http://issues.apache.org/jira/browse/GERONIMO-1361?page=all ] Gianny Damour closed GERONIMO-1361: --- Resolution: Fixed This was a TranQL issue, which was wrongly trying to identify compound PK based on the number of primary key fields. Thanks to Manu George for having identified this problem. CMP having a compound PK with only one field are not supported -- Key: GERONIMO-1361 URL: http://issues.apache.org/jira/browse/GERONIMO-1361 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M5 Reporter: Gianny Damour Assignee: Gianny Damour Priority: Minor Fix For: 1.0 I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN [SystemExceptionInterceptor] Product java.lang.ClassCastException at org.tranql.sql.jdbc.binding.StringBinding.setValue(StringBinding.java:43) at org.tranql.sql.jdbc.binding.TypeConverterBinding.setValue(TypeConverterBinding.java:93) at org.tranql.sql.jdbc.binding.TypeConverterBinding.setValue(TypeConverterBinding.java:89) at org.tranql.sql.jdbc.JDBCQueryCommand.execute(JDBCQueryCommand.java:64) at org.tranql.cache.cache.FindByPKCacheQueryCommand.execute(FindByPKCacheQueryCommand.java:6 6) at org.openejb.entity.cmp.CMPFinder.execute(CMPFinder.java:98) at org.openejb.entity.cmp.SingleValuedFinder.execute(SingleValuedFinder.java:80) at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72) at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterc eptor.java:56) at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81) at org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136) at org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:90) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:140) at org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextIntercepto r.java:80) at org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82) at org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238) at org.openejb.server.ejbd.EjbRequestHandler.invoke(EjbRequestHandler.java:297) at org.openejb.server.ejbd.EjbRequestHandler.doEjbHome_FIND(EjbRequestHandler.java:394) at org.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:209) at org.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:150) at org.openejb.server.ejbd.EjbServer.service(EjbServer.java:87) at org.openejb.server.ejbd.EjbServer$$FastClassByCGLIB$$d379d2ff.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor. java:96) at org.activeio.xnet.ServerService$$EnhancerByCGLIB$$e80ad14.service(generated) at org.activeio.xnet.ServicePool$2.run(ServicePool.java:67) at org.activeio.xnet.ServicePool$3.run(ServicePool.java:90) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:138) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) setEntityContext called ejbActivate() called. ejbLoad() called. ejb-jar.xml ?xml version=1.0? ejb-jar xmlns=http://java.sun.com/xml/ns/j2ee; version=2.1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd; display-nameProduct/display-name enterprise-beans entity ejb-nameProduct/ejb-name homeexamples.cmp.ProductHome/home remoteexamples.cmp.Product/remote ejb-classexamples.cmp.ProductBean/ejb-class persistence-typeContainer/persistence-type prim-key-classexamples.cmp.ProductPK/prim-key-class reentrantfalse/reentrant cmp-version2.x/cmp-version
OpenEJB PK issue
Hi Gianny, Was just seeing the fix you made. 1 question on that. In CMPContainerBuilder there are 2 methods private FaultHandler buildFaultHandler(SQLQueryBuilder queryBuilder, EJB definingEJB, CMRField field, int slot, boolean prefetch) throws QueryException and private LinkedHashMap createCMPFieldAccessors(SQLQueryBuilder queryBuilder, LinkedHashMap cmrFieldAccessor) I feel that in both of these methods instead of comparing based on relatedEntity.getPrimaryKeyFields().size() we need to change to ejb.isCompoundPK(). Am I right? Thanks Manu
Building the specs jars
I had this figured out several weeks ago, but can't seem to get this working now. I'm trying to make some changes to the geronimo-specs-javamail code, but can't seem to get this to build. What's the procedure for building this code? I'm working with the HEAD version. Rick
Re: Fwd: OpenEJB Question
Hi Aaron, I'm happy to cut a 1.2.2 TranQL release tomorrow night. However, and as pointed out by Manu, there was also an OpenEJB impact. So, it seems that we also need to re-cut an OpenEJB release. So far, I have checked in the fix to trunk and I will port the fix to the v2_0 branch if we decide to re-cut OpenEJB. Thanks, Gianny Aaron Mulder wrote: Gianny, Did the fix go into TranQL? Geronimo 1.0 is not using a TranQL snapshot right now, so someone would need to cut a new TranQL release for us to get the fix into Geronimo 1.0. Thanks, Aaron On 12/13/05, Gianny Damour [EMAIL PROTECTED] wrote: Hi Manu, Thanks for your debugging! This was a bug in IdentityDefinerBuilder, which was wrongly trying to identify a compound PK based on the number of primary key fields. This is now fixed. I will create a JIRA to track this issue tomorrow as it seems that JIRA is down tonight. Thanks, Gianny Manu George wrote: Hi Gianny, I have done all that you mentioned. I am still getting the error.I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN [SystemExceptionInterceptor] Product snip While i was debugging I saw a method public IdentityTransform getPrimaryKeyTransform(Entity entity) in the class IdentityDefinerBuilder. Here based on size of pkFields the SimplePKTransform or CompoundPKTransform class is selected. In the case of a custom class with 1 field also the SimplePKTransform is selected. Is this how it should behave? Could you give a general idea of how the primary key values are taken from the Custom classes in OpenEJB? Thanks Manu
svn commit: r356776 - /incubator/activemq/trunk/activeio/src/java/org/activeio/journal/active/ControlFile.java
Author: jstrachan
Date: Wed Dec 14 05:45:12 2005
New Revision: 356776
URL: http://svn.apache.org/viewcvs?rev=356776view=rev
Log:
removed possible threading error
Modified:
incubator/activemq/trunk/activeio/src/java/org/activeio/journal/active/ControlFile.java
Modified:
incubator/activemq/trunk/activeio/src/java/org/activeio/journal/active/ControlFile.java
URL:
http://svn.apache.org/viewcvs/incubator/activemq/trunk/activeio/src/java/org/activeio/journal/active/ControlFile.java?rev=356776r1=356775r2=356776view=diff
==
---
incubator/activemq/trunk/activeio/src/java/org/activeio/journal/active/ControlFile.java
(original)
+++
incubator/activemq/trunk/activeio/src/java/org/activeio/journal/active/ControlFile.java
Wed Dec 14 05:45:12 2005
@@ -66,15 +66,15 @@
* @throws IOException
*/
public void lock() throws IOException {
-if( lock==null ) {
-Set set = getVmLockSet();
-synchronized(set) {
-if( !set.add(canonicalPath) ) {
+Set set = getVmLockSet();
+synchronized (set) {
+if (lock == null) {
+if (!set.add(canonicalPath)) {
throw new IOException(Journal is already opened by this
application.);
}
-
+
lock = channel.tryLock();
-if( lock ==null ) {
+if (lock == null) {
set.remove(canonicalPath);
throw new IOException(Journal is already opened by
another application);
}
@@ -84,15 +84,16 @@
/**
* Un locks the control file.
- * @throws IOException
+ *
+ * @throws IOException
*/
public void unlock() throws IOException {
-if( lock != null ) {
-Set set = getVmLockSet();
-synchronized(set) {
-lock.release();
-lock=null;
+Set set = getVmLockSet();
+synchronized (set) {
+if (lock != null) {
set.remove(canonicalPath);
+lock.release();
+lock = null;
}
}
}
Re: OpenEJB PK issue
You are right! And thanks for reviewing my commits :) Indeed, buildFaultHandler is still creating the wrong type of IdentityDefiner. I thought that all dependencies on the various IdentityDefiner implementations were removed from OpenEJB thanks to the introduction of IdentityDefinerBuilder; obviously, two references have been forgotten :( About createCMPFieldAccessors, the relatedEntity.getPrimaryKeyFields().size() test must also be replaced by an isCompoundPK test. However, it seems that we should add a special processing to handle a CMP field mapped to a FK column referencing the (single) PK column associated to a compound PK having a single field. Thanks, Gianny Manu George wrote: Hi Gianny, Was just seeing the fix you made. 1 question on that. In CMPContainerBuilder there are 2 methods private FaultHandler buildFaultHandler(SQLQueryBuilder queryBuilder, EJB definingEJB, CMRField field, int slot, boolean prefetch) throws QueryException and private LinkedHashMap createCMPFieldAccessors(SQLQueryBuilder queryBuilder, LinkedHashMap cmrFieldAccessor) I feel that in both of these methods instead of comparing based on relatedEntity.getPrimaryKeyFields().size() we need to change to ejb.isCompoundPK(). Am I right? Thanks Manu
RE: ApacheCon Geronimo Clustering Huddle: 10:00am Wednesday, Hackathon Area.
Once the discussion is done can one of you guys put an update on the list for the less fortunate souls like me who couldn't attend ApacheCon?? Regards, Rajith Attapattu. -Original Message- From: Jules Gosnell [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 13, 2005 8:35 PM To: dev@geronimo.apache.org Subject: ApacheCon Geronimo Clustering Huddle: 10:00am Wednesday, Hackathon Area. Guys, Interest in clustering seems to be growing rapidly, along with requirements from various areas. I thought it would be useful to get everyone with an interest together in one place to answer peoples' questions about Geronimo clustering status and to canvas you all for expectations, requirements and ideas. regards, Jules
Re: building from 1.0 tag
I'll create a JIRA with a patch and instructions on applying the patch. On Wednesday 14 December 2005 02:24, Aaron Mulder wrote: That happens on the continuum build machines, but so far not on my machine. It's kind of not so bad since we aren't distributing the installer yet. But I'm not sure why it's happening, and it would sure be nice to figure it out and fix it. Aaron On 12/14/05, Christopher Chan [EMAIL PROTECTED] wrote: Has anyone experienced this in building from the 1.0 tag? [java] com.izforge.izpack.compiler.CompilerException: /home/cchan/OpenSource/geronimo/1.0tag/assemblies/j2ee-installer/target/g eronimo-1.0/geronimo-izpack.xml:23: Resource not found: /home/cchan/OpenSource/geronimo/1.0tag/assemblies/j2ee-installer/target/g eronimo-1.0/RELEASE-NOTES-1.0-M5.txt [java] at com.izforge.izpack.compiler.CompilerConfig.parseError(CompilerConfig.java :1518) [java] at com.izforge.izpack.compiler.CompilerConfig.findProjectResource(CompilerCo nfig.java:1447) [java] at com.izforge.izpack.compiler.CompilerConfig.addResources(CompilerConfig.ja va:1044) [java] at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig .java:313) [java] at com.izforge.izpack.compiler.CompilerConfig.main(CompilerConfig.java:1847) [java] at com.izforge.izpack.compiler.Compiler.main(Compiler.java:620) [java] [java] (tip : use -? to get the commmand line parameters) [java] [ERROR] Java Result: 1 -- Regards, Erik
Re: New 1.0.x build failure
I'm still seeing the failure with the 1.0 branch Rev356751 from this morning, using Maven 1.1Beta2 and a clean local maven repo and cache... + | configurations Server Configuration for the J2EE Server | Memory: 29M/42M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download jaxr-api-0.5.jar. 28K downloaded Attempting to download juddi-0.9rc4.jar. 727K downloaded Attempting to download jdom-1.0.jar. 149K downloaded build:start: multiproject:install-callback: [echo] Running car:install for Server Configuration for the J2EE Server 4136 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder - org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.MissingDependencyException: uri geronimo/geronimo-util/1.0-SNAPSHOT/jar not found in repository org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.MissingDependencyException: uri geronimo/geronimo-util/1.0-SNAPSHOT/jar not found in repository at org.apache.geronimo.deployment.service.ServiceConfigBuilder.getDependencyURI(ServiceConfigBuilder.java:402) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies(ServiceConfigBuilder.java:276) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies(ServiceConfigBuilder.java:303) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:204) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:167) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) Any ideas? -Donald Bill Stoddard wrote: David Jencks wrote: We may have done a bad thing by not hiding the test upload of released spec jars better. The first upload of the spec uberjar was faulty and did not contain the javamail classes. You might have downloaded this jar. To fix the problem you need to remove your maven org.apache.geronimo.specs directory. Yep, that fixed it. Thanks. Bill smime.p7s Description: S/MIME Cryptographic Signature
[jira] Commented: (GERONIMO-1329) Can not connect to Geronimo with jconsole
[ http://issues.apache.org/jira/browse/GERONIMO-1329?page=comments#action_12360434 ] Guillaume Nodet commented on GERONIMO-1329: --- I'm willingfull to provide a patch for this issue and GERONIMO-1330, using the way i described in my previous post. Before starting on this, i want to be sure that this is the right way to go : delegate jmx calls to the GBean Kernel first, and if the target is not found, then delegate calls to the MBean Server. This may lead to problems if for a reason, a gbean and an mbean have the same name. Any opinions ? Can not connect to Geronimo with jconsole - Key: GERONIMO-1329 URL: http://issues.apache.org/jira/browse/GERONIMO-1329 Project: Geronimo Type: Bug Components: kernel Versions: 1.0-M5 Reporter: Guillaume Nodet Fix For: 1.1 There is a missing mbean that makes jconsole fails to connect -- 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-1362) Release notes changes just before 1.0 tag cut caused installer build errors
Release notes changes just before 1.0 tag cut caused installer build errors
---
Key: GERONIMO-1362
URL: http://issues.apache.org/jira/browse/GERONIMO-1362
Project: Geronimo
Type: Bug
Components: installer
Versions: 1.0-M5
Reporter: erik daughtrey
The release notes for prior milestones were deleted and new release notes for
1.0 created.
This caused the installer build to fail since it had hard coded references.
The patch assumes that a RELEASE-NOTES-${pom.currentVersion}.txt will always
exist as it now does. This seems reasonable as we move forward even into 1.1.
We just need to ensure that a
release notes version for the currentVersion exists.
--
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-1362) Release notes changes just before 1.0 tag cut caused installer build errors
[ http://issues.apache.org/jira/browse/GERONIMO-1362?page=all ]
erik daughtrey updated GERONIMO-1362:
-
Version: 1.0
(was: 1.0-M5)
Release notes changes just before 1.0 tag cut caused installer build errors
---
Key: GERONIMO-1362
URL: http://issues.apache.org/jira/browse/GERONIMO-1362
Project: Geronimo
Type: Bug
Components: installer
Versions: 1.0
Reporter: erik daughtrey
The release notes for prior milestones were deleted and new release notes for
1.0 created.
This caused the installer build to fail since it had hard coded references.
The patch assumes that a RELEASE-NOTES-${pom.currentVersion}.txt will always
exist as it now does. This seems reasonable as we move forward even into
1.1. We just need to ensure that a
release notes version for the currentVersion exists.
--
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-1362) Release notes changes just before 1.0 tag cut caused installer build errors
[ http://issues.apache.org/jira/browse/GERONIMO-1362?page=all ]
erik daughtrey updated GERONIMO-1362:
-
Attachment: installer-1.0-build.patch
This patch fixes the 1.0 build problem related to the IzPack based installer.
To apply the patch:
1. Download the patch to the root of the svn build tree
2. cd to the svn tree for geronimo i.e. the build root
3. run patch -p0 installer-1.0-build.patch
Release notes changes just before 1.0 tag cut caused installer build errors
---
Key: GERONIMO-1362
URL: http://issues.apache.org/jira/browse/GERONIMO-1362
Project: Geronimo
Type: Bug
Components: installer
Versions: 1.0
Reporter: erik daughtrey
Attachments: installer-1.0-build.patch
The release notes for prior milestones were deleted and new release notes for
1.0 created.
This caused the installer build to fail since it had hard coded references.
The patch assumes that a RELEASE-NOTES-${pom.currentVersion}.txt will always
exist as it now does. This seems reasonable as we move forward even into
1.1. We just need to ensure that a
release notes version for the currentVersion exists.
--
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 1.0.x build failure - 2 more questions
Two other build questions: 1) Should /pom.xml be referencing the old geronimo-spec-* JARs, or is this file only used by Maven 2? 2) Where are the OpenEJB 2.0 released files, since etc\project.properties has openejb_version=2.0, but they could not be found on any of the listed Maven repos? Why are we still forcing people to checkout and build OpenEJB with Geronimo??? -Donald Donald Woods wrote: I'm still seeing the failure with the 1.0 branch Rev356751 from this morning, using Maven 1.1Beta2 and a clean local maven repo and cache... + | configurations Server Configuration for the J2EE Server | Memory: 29M/42M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download jaxr-api-0.5.jar. 28K downloaded Attempting to download juddi-0.9rc4.jar. 727K downloaded Attempting to download jdom-1.0.jar. 149K downloaded build:start: multiproject:install-callback: [echo] Running car:install for Server Configuration for the J2EE Server 4136 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder - org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.MissingDependencyException: uri geronimo/geronimo-util/1.0-SNAPSHOT/jar not found in repository org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.MissingDependencyException: uri geronimo/geronimo-util/1.0-SNAPSHOT/jar not found in repository at org.apache.geronimo.deployment.service.ServiceConfigBuilder.getDependencyURI(ServiceConfigBuilder.java:402) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies(ServiceConfigBuilder.java:276) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies(ServiceConfigBuilder.java:303) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:204) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:167) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) Any ideas? -Donald Bill Stoddard wrote: David Jencks wrote: We may have done a bad thing by not hiding the test upload of released spec jars better. The first upload of the spec uberjar was faulty and did not contain the javamail classes. You might have downloaded this jar. To fix the problem you need to remove your maven org.apache.geronimo.specs directory. Yep, that fixed it. Thanks. Bill smime.p7s Description: S/MIME Cryptographic Signature
svn commit: r356814 - /incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/transport/failover/FailoverTransport.java
Author: jstrachan
Date: Wed Dec 14 09:34:16 2005
New Revision: 356814
URL: http://svn.apache.org/viewcvs?rev=356814view=rev
Log:
fixed bug that prevented the initialReconnectDelay value from being changed
Modified:
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/transport/failover/FailoverTransport.java
Modified:
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/transport/failover/FailoverTransport.java
URL:
http://svn.apache.org/viewcvs/incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/transport/failover/FailoverTransport.java?rev=356814r1=356813r2=356814view=diff
==
---
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/transport/failover/FailoverTransport.java
(original)
+++
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/transport/failover/FailoverTransport.java
Wed Dec 14 09:34:16 2005
@@ -115,6 +115,7 @@
if( connectList.isEmpty() ) {
failure = new IOException(No uris available to
connect to.);
} else {
+reconnectDelay = initialReconnectDelay;
Iterator iter = connectList.iterator();
for (int i = 0; iter.hasNext()
connectedTransport == null !disposed; i++) {
URI uri = (URI) iter.next();
@@ -126,7 +127,7 @@
restoreTransport(t);
}
log.debug(Connection established);
-reconnectDelay = 10;
+reconnectDelay = initialReconnectDelay;
connectedTransportURI = uri;
connectedTransport = t;
reconnectMutex.notifyAll();
svn commit: r356815 - /incubator/activemq/trunk/activemq-core/src/test/java/org/activemq/JmsQueueSendReceiveTwoConnectionsStartBeforeBrokerTest.java
Author: jstrachan
Date: Wed Dec 14 09:35:27 2005
New Revision: 356815
URL: http://svn.apache.org/viewcvs?rev=356815view=rev
Log:
added test case which demonstrates that you can start a JMS connection even
when the broker is not there
Added:
incubator/activemq/trunk/activemq-core/src/test/java/org/activemq/JmsQueueSendReceiveTwoConnectionsStartBeforeBrokerTest.java
(with props)
Added:
incubator/activemq/trunk/activemq-core/src/test/java/org/activemq/JmsQueueSendReceiveTwoConnectionsStartBeforeBrokerTest.java
URL:
http://svn.apache.org/viewcvs/incubator/activemq/trunk/activemq-core/src/test/java/org/activemq/JmsQueueSendReceiveTwoConnectionsStartBeforeBrokerTest.java?rev=356815view=auto
==
---
incubator/activemq/trunk/activemq-core/src/test/java/org/activemq/JmsQueueSendReceiveTwoConnectionsStartBeforeBrokerTest.java
(added)
+++
incubator/activemq/trunk/activemq-core/src/test/java/org/activemq/JmsQueueSendReceiveTwoConnectionsStartBeforeBrokerTest.java
Wed Dec 14 09:35:27 2005
@@ -0,0 +1,88 @@
+/**
+* a href=http://activemq.org;ActiveMQ: The Open Source Message Fabric/a
+*
+* Copyright 2005 (C) LogicBlaze, Inc. http://www.logicblaze.com
+*
+* Licensed under the Apache License, Version 2.0 (the License);
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an AS IS BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*
+**/
+package org.activemq;
+
+import edu.emory.mathcs.backport.java.util.Queue;
+import edu.emory.mathcs.backport.java.util.concurrent.ConcurrentLinkedQueue;
+
+import org.activemq.broker.BrokerService;
+
+
+/**
+ * @version $Revision$
+ */
+public class JmsQueueSendReceiveTwoConnectionsStartBeforeBrokerTest extends
JmsQueueSendReceiveTwoConnectionsTest {
+
+private Queue errors = new ConcurrentLinkedQueue();
+private int delayBeforeStartingBroker = 1000;
+private BrokerService broker;
+
+public void startBroker() {
+// Initialize the broker
+System.out.println(Lets wait: + delayBeforeStartingBroker +
millis before creating the broker);
+try {
+Thread.sleep(delayBeforeStartingBroker);
+}
+catch (InterruptedException e) {
+e.printStackTrace();
+}
+
+System.out.println(Now starting the broker);
+try {
+broker = new BrokerService();
+broker.setPersistent(false);
+broker.addConnector(tcp://localhost:61616);
+broker.start();
+}
+catch (Exception e) {
+System.out.println(Caught: + e);
+errors.add(e);
+}
+}
+protected ActiveMQConnectionFactory createConnectionFactory() throws
Exception {
+return new
ActiveMQConnectionFactory(failover:(tcp://localhost:61616)?maxReconnectAttempts=10useExponentialBackOff=falseinitialReconnectDelay=200);
+}
+
+protected void setUp() throws Exception {
+// now lets asynchronously start a broker
+Thread thread = new Thread() {
+public void run() {
+startBroker();
+}
+};
+thread.start();
+
+super.setUp();
+}
+
+protected void tearDown() throws Exception {
+super.tearDown();
+
+if (broker != null) {
+broker.stop();
+}
+if (!errors.isEmpty()) {
+Exception e = (Exception) errors.remove();
+throw e;
+}
+}
+
+
+
+}
Propchange:
incubator/activemq/trunk/activemq-core/src/test/java/org/activemq/JmsQueueSendReceiveTwoConnectionsStartBeforeBrokerTest.java
--
svn:eol-style = native
Propchange:
incubator/activemq/trunk/activemq-core/src/test/java/org/activemq/JmsQueueSendReceiveTwoConnectionsStartBeforeBrokerTest.java
--
svn:keywords = Date Author Id Revision HeadURL
Propchange:
incubator/activemq/trunk/activemq-core/src/test/java/org/activemq/JmsQueueSendReceiveTwoConnectionsStartBeforeBrokerTest.java
--
svn:mime-type = text/plain
[jira] Created: (GERONIMO-1363) DayTrader still using old geronimo-spec files
DayTrader still using old geronimo-spec files - Key: GERONIMO-1363 URL: http://issues.apache.org/jira/browse/GERONIMO-1363 Project: Geronimo Type: Bug Components: sample apps Versions: 1.0 Environment: 1.0 branch Rev356751 Reporter: Donald Woods Priority: Minor A grep through the latest geronimo 1.0 branch shows that DayTrader is still using the old geronimo-spec files instead of the new ones in org.apache.geronimo.specs - applications\daytrader\ejb\project.xml 23 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\streamer\project.xml 25 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\web\project.xml 28 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\wsappclient\project.xml 13 19: artifactIdgeronimo-spec-j2ee/artifactId -- 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 1.0.x build failure
Below problem has been resolved. I had to delete and checkout the OpenEJB source again using m:co to resolve the build failure. We really need the OpenEJB 2.0 files published or JIRA-1317 integrated into AG 1.0 to keep others from hitting the same problems, given the default new maven goals do not include the usage of the m:update, m:clean or m:clean-repo goals... -Donald Donald Woods wrote: I'm still seeing the failure with the 1.0 branch Rev356751 from this morning, using Maven 1.1Beta2 and a clean local maven repo and cache... + | configurations Server Configuration for the J2EE Server | Memory: 29M/42M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download jaxr-api-0.5.jar. 28K downloaded Attempting to download juddi-0.9rc4.jar. 727K downloaded Attempting to download jdom-1.0.jar. 149K downloaded build:start: multiproject:install-callback: [echo] Running car:install for Server Configuration for the J2EE Server 4136 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder - org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.MissingDependencyException: uri geronimo/geronimo-util/1.0-SNAPSHOT/jar not found in repository org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.MissingDependencyException: uri geronimo/geronimo-util/1.0-SNAPSHOT/jar not found in repository at org.apache.geronimo.deployment.service.ServiceConfigBuilder.getDependencyURI(ServiceConfigBuilder.java:402) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies(ServiceConfigBuilder.java:276) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies(ServiceConfigBuilder.java:303) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:204) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:167) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) Any ideas? -Donald Bill Stoddard wrote: David Jencks wrote: We may have done a bad thing by not hiding the test upload of released spec jars better. The first upload of the spec uberjar was faulty and did not contain the javamail classes. You might have downloaded this jar. To fix the problem you need to remove your maven org.apache.geronimo.specs directory. Yep, that fixed it. Thanks. Bill smime.p7s Description: S/MIME Cryptographic Signature
Re: [Vote] Geronimo V1.0 Release binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 assuming the binaries pass the TCK Geir Magnusson Jr. wrote, On 12/13/2005 9:18 PM: +1 assuming the binaries pass the TCK On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoGM21xC6qnMLUpYRAuKMAJ0aFiCWVUa8aqauUzpTqUQ162BfxQCfRokC VFRtWqIysuXM1X81u306x6w= =BoUa -END PGP SIGNATURE-
Re: Building the specs jars
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rick McGuire wrote, On 12/14/2005 5:08 AM: I had this figured out several weeks ago, but can't seem to get this working now. I'm trying to make some changes to the geronimo-specs-javamail code, but can't seem to get this to build. What's the procedure for building this code? I'm working with the HEAD version. Rick I clear my repo and this works for me. What problems are you running into? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoGk31xC6qnMLUpYRAuN8AJ9JfCapya3D1BaJ99zLLz+VnNCgWQCfTYtx 7syJ9Y5SKrP9IPVM1S5WyvA= =YeaL -END PGP SIGNATURE-
Re: Move JAXB spec to Geronimo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jochen Wiedmann wrote, On 12/14/2005 1:46 AM: Hi, the JaxMe project contains a clean room implementation of the JAXB API 1.1. As future versions of J2EE will contain the JAXB API, I propose that these be moved to the other Geronimo J2EE spec implementations. Sounds great. Let's put it in our geronimo/specs/trunk. If it's stable, file a Jira w/ a tar of the files and I can plop that in. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoGmq1xC6qnMLUpYRAthKAJ0XtFJgN4it+8ofXNyz+lfiUnRPmgCeJpAT rKGMkKyGI/NVQMvUMovXd9E= =guTU -END PGP SIGNATURE-
Re: Move JAXB spec to Geronimo
Since JaxMe is at Apache, you can move it over with svn mv. Has the JaxMe community as a whole voted to do this? I think it makes sense, it would just be good to ensure everyone agrees. It will also impact the committer list for Geronimo. Cheers, Brett On 12/14/05, Alan D. Cabrera [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jochen Wiedmann wrote, On 12/14/2005 1:46 AM: Hi, the JaxMe project contains a clean room implementation of the JAXB API 1.1. As future versions of J2EE will contain the JAXB API, I propose that these be moved to the other Geronimo J2EE spec implementations. Sounds great. Let's put it in our geronimo/specs/trunk. If it's stable, file a Jira w/ a tar of the files and I can plop that in. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoGmq1xC6qnMLUpYRAthKAJ0XtFJgN4it+8ofXNyz+lfiUnRPmgCeJpAT rKGMkKyGI/NVQMvUMovXd9E= =guTU -END PGP SIGNATURE-
Re: svn commit: r356499 - /geronimo/specs/branches/1_0/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Stoddard wrote, On 12/13/2005 2:21 PM: [EMAIL PROTECTED] wrote: Author: adc Date: Mon Dec 12 23:39:50 2005 New Revision: 356499 URL: http://svn.apache.org/viewcvs?rev=356499view=rev Log: made a copy Added: geronimo/specs/branches/1_0/ - copied from r356497, geronimo/specs/trunk/ Would it be better to use the same naming convention for the specs branch as for the geronimo kernel, geronimo/specs/branches/1.0? foolish consistency and hobgoblins not withstanding :) Good idea. I personally hate having dots in a directory name. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoGrT1xC6qnMLUpYRAtDJAJ0RftKwNLygxcuJarJmgYG6MgkxDwCdGybT zWn8VAHsnRjlF08BkBuhfg4= =PjSE -END PGP SIGNATURE-
svn commit: r356827 - /incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/store/journal/JournalPersistenceAdapter.java
Author: jstrachan Date: Wed Dec 14 11:00:44 2005 New Revision: 356827 URL: http://svn.apache.org/viewcvs?rev=356827view=rev Log: better logging on startup to reveal the journal configuration Modified: incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/store/journal/JournalPersistenceAdapter.java Modified: incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/store/journal/JournalPersistenceAdapter.java URL: http://svn.apache.org/viewcvs/incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/store/journal/JournalPersistenceAdapter.java?rev=356827r1=356826r2=356827view=diff == --- incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/store/journal/JournalPersistenceAdapter.java (original) +++ incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/store/journal/JournalPersistenceAdapter.java Wed Dec 14 11:00:44 2005 @@ -445,7 +445,7 @@ RecordLocation pos = null; int transactionCounter = 0; -log.info(Journal Recovery Started.); +log.info(Journal Recovery Started from: + journal); ConnectionContext context = new ConnectionContext(); // While we have records in the journal.
svn commit: r356828 - /incubator/servicemix/trunk/maven.xml
Author: geirm Date: Wed Dec 14 11:03:25 2005 New Revision: 356828 URL: http://svn.apache.org/viewcvs?rev=356828view=rev Log: added a newline just to test the commit mail stream Modified: incubator/servicemix/trunk/maven.xml Modified: incubator/servicemix/trunk/maven.xml URL: http://svn.apache.org/viewcvs/incubator/servicemix/trunk/maven.xml?rev=356828r1=356827r2=356828view=diff == --- incubator/servicemix/trunk/maven.xml (original) +++ incubator/servicemix/trunk/maven.xml Wed Dec 14 11:03:25 2005 @@ -15,6 +15,7 @@ See the License for the specific language governing permissions and limitations under the License. -- + project default=default xmlns:j=jelly:core xmlns:u=jelly:util
Re: Building the specs jars
Rick, I've built the specs successfully using maven 2 (maven 2.0.1 doesn't work). 'mvn install' works fine... Hmmm. Just noticed that the version of the jars being built is '1.0'. This should be changed to '1.0-SNAPSHOT' or '1.x-SNAPSHOT'. BTW, what changes are needed to the javamail spec? --kevanOn 12/14/05, Alan D. Cabrera [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE-Hash: SHA1Rick McGuire wrote, On 12/14/2005 5:08 AM: I had this figured out several weeks ago, but can't seem to get this working now.I'm trying to make some changes to the geronimo-specs-javamail code, but can't seem to get this to build. What's the procedure for building this code?I'm working with the HEAD version. RickI clear my repo and this works for me.What problems are you running into? Regards,Alan-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.2 (MingW32)Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoGk31xC6qnMLUpYRAuN8AJ9JfCapya3D1BaJ99zLLz+VnNCgWQCfTYtx7syJ9Y5SKrP9IPVM1S5WyvA==YeaL-END PGP SIGNATURE-
[jira] Closed: (GERONIMO-1362) Release notes changes just before 1.0 tag cut caused installer build errors
[ http://issues.apache.org/jira/browse/GERONIMO-1362?page=all ]
Aaron Mulder closed GERONIMO-1362:
--
Fix Version: 1.0
Resolution: Invalid
Assign To: Aaron Mulder
This patch is so... yesterday! (which is to say thanks, but we already fixed
the branch :)
Release notes changes just before 1.0 tag cut caused installer build errors
---
Key: GERONIMO-1362
URL: http://issues.apache.org/jira/browse/GERONIMO-1362
Project: Geronimo
Type: Bug
Components: installer
Versions: 1.0
Reporter: erik daughtrey
Assignee: Aaron Mulder
Fix For: 1.0
Attachments: installer-1.0-build.patch
The release notes for prior milestones were deleted and new release notes for
1.0 created.
This caused the installer build to fail since it had hard coded references.
The patch assumes that a RELEASE-NOTES-${pom.currentVersion}.txt will always
exist as it now does. This seems reasonable as we move forward even into
1.1. We just need to ensure that a
release notes version for the currentVersion exists.
--
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 JAXB spec to Geronimo
Brett Porter wrote: Since JaxMe is at Apache, you can move it over with svn mv. Exactly. However, initially, I'd prefer a copy operation. (No idea, whether that's as easy in SVN.) That would give a smoother step. We could wait until the generated jar files do meet the Maven repositories and stuff like that. Has the JaxMe community as a whole voted to do this? I think it makes sense, it would just be good to ensure everyone agrees. It will also impact the committer list for Geronimo. You are absolutely right, Brett! Indeed, this should have been my first step. It is just that I have found the directory /www/cvs.apache.org/maven-snapshot-repository/org.apache.geronimo.specs/ today and immediately had the thought that this would be a better place. I'll start a vote on the jaxme-dev mailing list. If this helps: I have no problem to request that we as the JaxMe developers abandon work on the code base (except possibly submitting patches). In other words, none of us would require to be a committer. Alan Cabrera wrote: Sounds great. Let's put it in our geronimo/specs/trunk. If it's stable, file a Jira w/ a tar of the files and I can plop that in. The codebase is *very* stable. Indeed, it had almost no changes since the import into the Apache repositories (almost 2 years ago). No surprise: There almost only interfaces and almost no classes, which are doing the actual work. Jochen
Re: Building the specs jars
Kevan Miller wrote: Rick, I've built the specs successfully using maven 2 (maven 2.0.1 doesn't work). 'mvn install' works fine... Hmmm. Just noticed that the version of the jars being built is '1.0'. This should be changed to '1.0-SNAPSHOT' or '1.x-SNAPSHOT'. Does this require maven 2 to build now? It didn't a couple weeks ago. When I try to build now, it doesn't do anything. BTW, what changes are needed to the javamail spec? There are some items in the code marked as todos that are required for SMTP authentication be to implemented. --kevan On 12/14/05, *Alan D. Cabrera* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rick McGuire wrote, On 12/14/2005 5:08 AM: I had this figured out several weeks ago, but can't seem to get this working now. I'm trying to make some changes to the geronimo-specs-javamail code, but can't seem to get this to build. What's the procedure for building this code? I'm working with the HEAD version. Rick I clear my repo and this works for me. What problems are you running into? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoGk31xC6qnMLUpYRAuN8AJ9JfCapya3D1BaJ99zLLz+VnNCgWQCfTYtx 7syJ9Y5SKrP9IPVM1S5WyvA= =YeaL -END PGP SIGNATURE-
Re: Building the specs jars
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rick McGuire wrote, On 12/14/2005 11:58 AM: Kevan Miller wrote: Rick, I've built the specs successfully using maven 2 (maven 2.0.1 doesn't work). 'mvn install' works fine... Hmmm. Just noticed that the version of the jars being built is '1.0'. This should be changed to '1.0-SNAPSHOT' or '1.x-SNAPSHOT'. Does this require maven 2 to build now? It didn't a couple weeks ago. When I try to build now, it doesn't do anything. The stuff in geronimo/specs was always on maven 2. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoHpe1xC6qnMLUpYRAsGmAJ9sW9VCUgdwgoo1KpRJrmzRxYvjjwCfVg5J SmhxH71niFV9CcLn8SvTR64= =Q4Pv -END PGP SIGNATURE-
Spaces in HTML docs - not unix friendly
Hi all, I've been experimenting with creating an rpm with Geronimo, but rpm does not like spaces in filenames and there are some html documentation that contain spaces in them. Is there a chance to standardize naming to not contain spaces to make it more unix/linux friendly? Under modules/scripts/src/resources/docs: Administration.html Administrative tasks_attachments Administrative tasks.html Apache Geronimo project overview.html Apache Geronimo V1 - Documentation_attachments Apache Geronimo V1 - Documentation.html Architecture_attachments Architecture.html Authorization - mapping J2EE roles to Principals.html Available login modules.html Backup and recovery.html border Component Configuration.html Concepts.html Configuring LDAP_attachments Configuring LDAP.html Deployer tool.html Deploying configurations and resources.html Deploying secure applications.html Deployment.html Deployment plans.html Development.html documentation_banner.jpg Geronimo Administration Console_attachments Geronimo Administration Console.html Geronimo and JAAS.html Geronimo Login Config Schema.html head_bgstretch_1x86.gif Hints and Tips.html Hot deployment.html icons Implementing security - working examples.html index.html Installation.html JaasLoginService API Discussion.html JBoss to Geronimo - EJB-BMP Migration_attachments JBoss to Geronimo - EJB-BMP Migration.html JBoss to Geronimo - EJB-CMP Migration_attachments JBoss to Geronimo - EJB-CMP Migration.html JBoss to Geronimo - EJB-MDB Migration_attachments JBoss to Geronimo - EJB-MDB Migration.html JBoss to Geronimo - EJB-Session Beans Migration_attachments JBoss to Geronimo - EJB-Session Beans Migration.html JBoss to Geronimo - JCA Migration_attachments JBoss to Geronimo - JCA Migration.html JBoss to Geronimo - JDBC Migration_attachments JBoss to Geronimo - JDBC Migration.html JBoss to Geronimo - Security Migration_attachments JBoss to Geronimo - Security Migration.html JBoss to Geronimo - Servlets and JSPs Migration_attachments JBoss to Geronimo - Servlets and JSPs Migration.html JBoss to Geronimo - Web Services Migration_attachments JBoss to Geronimo - Web Services Migration.html left.html Login into Geronimo.html main.html Maintenance.html Mapping J2EE Roles in M5 release.html Migrating to Apache Geronimo.html Performance and high availability.html Quick start - Apache Geronimo for the impatient_attachments Quick start - Apache Geronimo for the impatient.html Security Definition Schema.html Security.html styles Tools and commands.html top.html Troubleshooting.html - Chris
Re: [Vote] Geronimo V1.0 Release binaries
+1 from me. On 12/13/05, Matt Hogstrom [EMAIL PROTECTED] wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt -- Davanum Srinivas : http://wso2.com/blogs/
Re: Building the specs jars
Alan D. Cabrera wrote: The stuff in geronimo/specs was always on maven 2. Whow, I didn't know that. I'm on Maven 1 and can't remember whether or not I tried to build them at any time, but if I had been asked about specs and Maven version, I would've answer there was no dependency and any Maven version would work. Alan Jacek
Needed steps on sources
I'd like to know if we have to rename the packages to org.apache.servicemix.* or if we can keep the current ones org.servicemix.*. I think that we also have to modify the headers of all sources to include apache license, but i want to be sure about that. Also what copyright should be used, as currently, there are different one used, and some files do not have copyrights ? Cheers, Guillaume
Re: Building the specs jars
Jacek Laskowski wrote: Alan D. Cabrera wrote: The stuff in geronimo/specs was always on maven 2. Whow, I didn't know that. I'm on Maven 1 and can't remember whether or not I tried to build them at any time, but if I had been asked about specs and Maven version, I would've answer there was no dependency and any Maven version would work. And I was able to successfully build the javamail jar 3-4 weeks ago using maven 1, so this was a shock to me too! Alan Jacek
[jira] Created: (GERONIMO-1364) update welcome pages to point at HTTP redirects in the geronimo.apache.org site
update welcome pages to point at HTTP redirects in the geronimo.apache.org site --- Key: GERONIMO-1364 URL: http://issues.apache.org/jira/browse/GERONIMO-1364 Project: Geronimo Type: Improvement Components: console Environment: all platforms and environments Reporter: Paul McMahan Priority: Minor JIRA 1318 created redirects in the geronimo.apache.org web site http://issues.apache.org/jira/browse/GERONIMO-1318 The purpose of those redirects is to allow links in the welcome pages to reference pages at the geronimo site instead of using links that may become stale. Since the patch for JIRA 1300 contained pending changes for the welcome pages the original plan was for the contributor of that patch to make the appropriate adjustments. http://issues.apache.org/jira/browse/GERONIMO-1300 However, the patch for 1300 was committed before the welcome pages were adjusted. The purpose of this JIRA is to update the welcome pages to use the redirects and to re-enable the links to the Confluence Wiki (routing the initial request through the HTTP redirects). A few typos are also corrected in the welcome application. -- 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-1364) update welcome pages to point at HTTP redirects in the geronimo.apache.org site
[ http://issues.apache.org/jira/browse/GERONIMO-1364?page=all ] Paul McMahan updated GERONIMO-1364: --- Attachment: GERONIMO-1364.patch patch contains the updated welcome pages update welcome pages to point at HTTP redirects in the geronimo.apache.org site --- Key: GERONIMO-1364 URL: http://issues.apache.org/jira/browse/GERONIMO-1364 Project: Geronimo Type: Improvement Components: console Environment: all platforms and environments Reporter: Paul McMahan Priority: Minor Attachments: GERONIMO-1364.patch JIRA 1318 created redirects in the geronimo.apache.org web site http://issues.apache.org/jira/browse/GERONIMO-1318 The purpose of those redirects is to allow links in the welcome pages to reference pages at the geronimo site instead of using links that may become stale. Since the patch for JIRA 1300 contained pending changes for the welcome pages the original plan was for the contributor of that patch to make the appropriate adjustments. http://issues.apache.org/jira/browse/GERONIMO-1300 However, the patch for 1300 was committed before the welcome pages were adjusted. The purpose of this JIRA is to update the welcome pages to use the redirects and to re-enable the links to the Confluence Wiki (routing the initial request through the HTTP redirects). A few typos are also corrected in the welcome application. -- 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-1318) HTTP redirects for the geronimo.apache.org site
[ http://issues.apache.org/jira/browse/GERONIMO-1318?page=comments#action_12360458 ] Paul McMahan commented on GERONIMO-1318: Alan, there was some confusion about how the welcome pages would be updated. Please see JIRA 1364. http://issues.apache.org/jira/browse/GERONIMO-1364 HTTP redirects for the geronimo.apache.org site --- Key: GERONIMO-1318 URL: http://issues.apache.org/jira/browse/GERONIMO-1318 Project: Geronimo Type: Improvement Components: console Versions: 1.0 Reporter: Paul McMahan Assignee: Alan Cabrera Priority: Minor Fix For: 1.0 Attachments: GERONIMO-1318.patch The welcome application and the welcome portlet currently contain links to web pages outside of the geronimo.apache.org web site (e.g. the docs in Confluence). Since the destination of these links is outside of our control they may go stale during the lifetime of the 1.0 console. So instead of linking to those web pages directly the welcome application and welcome portlet should instead link to web pages on the geronimo.apache.org web site. The geronimo.apache.org web site can then redirect the browser to the external address if necessary. This will allow us to change where the links in the welcome portlet and welcome app take a web browser without actually changing the installed geronimo server. Ideally we could configure the geronimo.apache.org HTTP server to issue the redirects. But since that requires administrative access to the HTTP server we can use html files containing a meta http-equiv=refresh ... tag instead. -- 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-1364) update welcome pages to point at HTTP redirects in the geronimo.apache.org site
[ http://issues.apache.org/jira/browse/GERONIMO-1364?page=all ] Paul McMahan updated GERONIMO-1364: --- Version: 1.0 update welcome pages to point at HTTP redirects in the geronimo.apache.org site --- Key: GERONIMO-1364 URL: http://issues.apache.org/jira/browse/GERONIMO-1364 Project: Geronimo Type: Improvement Components: console Versions: 1.0 Environment: all platforms and environments Reporter: Paul McMahan Priority: Minor Attachments: GERONIMO-1364.patch JIRA 1318 created redirects in the geronimo.apache.org web site http://issues.apache.org/jira/browse/GERONIMO-1318 The purpose of those redirects is to allow links in the welcome pages to reference pages at the geronimo site instead of using links that may become stale. Since the patch for JIRA 1300 contained pending changes for the welcome pages the original plan was for the contributor of that patch to make the appropriate adjustments. http://issues.apache.org/jira/browse/GERONIMO-1300 However, the patch for 1300 was committed before the welcome pages were adjusted. The purpose of this JIRA is to update the welcome pages to use the redirects and to re-enable the links to the Confluence Wiki (routing the initial request through the HTTP redirects). A few typos are also corrected in the welcome application. -- 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: Java Adventure Builder Reference application, deployment/build issues
Jakob Færch (Trifork) wrote: I'll just continue working with the jetty-j2ee distribution I managed to build yesterday. At last I could build the latest version of Geronimo. It wasn't that easy as it should be. I remember having to run maven several times before all jars were in place and the build finished with no errors. I'm looking into getting AB up and running in it. Jakob Jacek
[jira] Created: (GERONIMO-1365) JSR-88 Manfest has incorrect Class-Path entries
JSR-88 Manfest has incorrect Class-Path entries --- Key: GERONIMO-1365 URL: http://issues.apache.org/jira/browse/GERONIMO-1365 Project: Geronimo Type: Bug Components: deployment Versions: 1.0 Reporter: Aaron Mulder Assigned to: David Jencks Fix For: 1.1 We used to use bin/deployer.jar as our JSR-88 implementation JAR. As a result, all the Class-Path entries had the form ../lib/foo.jar (resolving to geronimo/lib/...). At some point, that was switched so that repository/geronimo/jars/geronimo-deploy-jsr88-1.0.jar became the official JSR-88 implementation JAR. However, all the Class-Path entries are still ../lib even though that resolves to repository/geronimo/lib/... which is not valid. Either we need to switch JSR-88 back to bin/deployer.jar or else we need to update the Class-Path entries to be relative within the repository. Assigning this to David J since he mentioned updating the JSR-88 implementation JAR, so I suspect he has an opinion on which way to go with this issue. -- 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] Geronimo V1.0 Release binaries
Yanking my +1. The binaries are flawed. -David On Dec 13, 2005, at 9:53 PM, David Blevins wrote: Files uploaded! Here is my +1 baring any tck failures. -David On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt
[jira] Created: (GERONIMO-1366) Maven deployment plugin should use deployer stored username/password
Maven deployment plugin should use deployer stored username/password Key: GERONIMO-1366 URL: http://issues.apache.org/jira/browse/GERONIMO-1366 Project: Geronimo Type: Improvement Components: deployment, usability Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0 It would be nice if the geronimo-deployment-plugin would pick up your saved username/password so you didn't need to code them into your maven file. That would introduce a dependency on the geronimo-util module. -- 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-1367) Shutdown JAR should use deployer stored username/password
Shutdown JAR should use deployer stored username/password - Key: GERONIMO-1367 URL: http://issues.apache.org/jira/browse/GERONIMO-1367 Project: Geronimo Type: Improvement Components: startup/shutdown, usability Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1 It would be nice if the shutdown script used the username and password saved by the deployer so you didn't need to specify them or re-enter them. -- 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-1368) Remote deployment probably doesn't handle exploded JARs
Remote deployment probably doesn't handle exploded JARs --- Key: GERONIMO-1368 URL: http://issues.apache.org/jira/browse/GERONIMO-1368 Project: Geronimo Type: Bug Components: deployment Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1 If you pass an exploded JAR to the deploy tool when running on a remote machine, it should zip it on the fly when uploading to the server. -- 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-1363) DayTrader still using old geronimo-spec files
[ http://issues.apache.org/jira/browse/GERONIMO-1363?page=all ] Matt Hogstrom closed GERONIMO-1363: --- Resolution: Fixed Sendingdaytrader/ejb/project.xml Sendingdaytrader/streamer/project.xml Sendingdaytrader/web/project.xml Sendingdaytrader/wsappclient/project.xml Transmitting file data Committed revision 356990. DayTrader still using old geronimo-spec files - Key: GERONIMO-1363 URL: http://issues.apache.org/jira/browse/GERONIMO-1363 Project: Geronimo Type: Bug Components: sample apps Versions: 1.0 Environment: 1.0 branch Rev356751 Reporter: Donald Woods Priority: Minor A grep through the latest geronimo 1.0 branch shows that DayTrader is still using the old geronimo-spec files instead of the new ones in org.apache.geronimo.specs - applications\daytrader\ejb\project.xml 23 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\streamer\project.xml 25 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\web\project.xml 28 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\wsappclient\project.xml 13 19: artifactIdgeronimo-spec-j2ee/artifactId -- 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] Reopened: (GERONIMO-1363) DayTrader still using old geronimo-spec files
[ http://issues.apache.org/jira/browse/GERONIMO-1363?page=all ] Matt Hogstrom reopened GERONIMO-1363: - Assign To: Matt Hogstrom Re-opened...I applied this to head. Since we're going to have to re-spin 1.0 I'll apply the fix there after confirming what we're doing with that branch. DayTrader still using old geronimo-spec files - Key: GERONIMO-1363 URL: http://issues.apache.org/jira/browse/GERONIMO-1363 Project: Geronimo Type: Bug Components: sample apps Versions: 1.0 Environment: 1.0 branch Rev356751 Reporter: Donald Woods Assignee: Matt Hogstrom Priority: Minor Fix For: 1.0, 1.1 A grep through the latest geronimo 1.0 branch shows that DayTrader is still using the old geronimo-spec files instead of the new ones in org.apache.geronimo.specs - applications\daytrader\ejb\project.xml 23 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\streamer\project.xml 25 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\web\project.xml 28 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\wsappclient\project.xml 13 19: artifactIdgeronimo-spec-j2ee/artifactId -- 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-1363) DayTrader still using old geronimo-spec files
[ http://issues.apache.org/jira/browse/GERONIMO-1363?page=all ] Matt Hogstrom updated GERONIMO-1363: Fix Version: 1.0 1.1 DayTrader still using old geronimo-spec files - Key: GERONIMO-1363 URL: http://issues.apache.org/jira/browse/GERONIMO-1363 Project: Geronimo Type: Bug Components: sample apps Versions: 1.0 Environment: 1.0 branch Rev356751 Reporter: Donald Woods Assignee: Matt Hogstrom Priority: Minor Fix For: 1.0, 1.1 A grep through the latest geronimo 1.0 branch shows that DayTrader is still using the old geronimo-spec files instead of the new ones in org.apache.geronimo.specs - applications\daytrader\ejb\project.xml 23 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\streamer\project.xml 25 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\web\project.xml 28 19: artifactIdgeronimo-spec-j2ee/artifactId applications\daytrader\wsappclient\project.xml 13 19: artifactIdgeronimo-spec-j2ee/artifactId -- 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: Java Adventure Builder Reference application, status
Jacek Laskowski wrote: At last I could build the latest version of Geronimo. It wasn't that easy as it should be. I remember having to run maven several times before all jars were in place and the build finished with no errors. I'm looking into getting AB up and running in it. My status is that I have AB deploying without errors on the (broken) 1.0-prebuild. Compared to the plans/sql in the repository, so far I have: - Set up (more) correct references to web services - Added undefined web service endpoints - Started to get the autogenerated primary keys for CMP's working (using your work from the Pet Store as template) I feel that I'm getting nearer a working AB - having got past Geronimo build and deployment trouble brings me nearer to my usual (J2EE application) domain :-) To make best use of our time, maybe we should let me have a try at the application specific things? I haven't yet succeeden in having the maven script unpack a new server automatically, and the startup procedure I'm managed to get working is very clumsy. Maybe you could look into these issues some time? If you want it, I could distribute the diff on my sandbox/adventurebuilder directory now - if you don't need it, I'll wait until the application is working. Jakob
[jira] Created: (GERONIMO-1369) javax.ejb.NoSuchObjectLocalException in the ServletContextListener.contextInitialized() method
javax.ejb.NoSuchObjectLocalException in the ServletContextListener.contextInitialized() method -- Key: GERONIMO-1369 URL: http://issues.apache.org/jira/browse/GERONIMO-1369 Project: Geronimo Type: Bug Components: web Versions: 1.0 Environment: Windows XP (SP2), Sun JDK build 1.4.2_08-b03 Reporter: Alexander Korostov In my application, I lookup and invoke a session bean (via local interface) in the ServletContextListener.contextInitialized(). Sometimes application throws a NoSuchObjectLocalException in the ServletContextListener.contextInitialized(), sometimes all works fine. This bug is appeared on both Tomcat and Jetty. I can not reproduce this bug with the 100% probability on the latest snapshot. Even if I change the application a bit (rename the EJB or WEB project) this bug can disappear or appear again. It looks like some synchronization (racing conditions) problem: sometimes LocalHome of my bean is published before the ServletContextListener.contextInitialized() invoked, sometimes not. See the attached geronimo.log and a test application. Note that the geronimo.log contains both cases: 1. when the application starts fine 2. throws an exception. Sorry for the big size of the test application: I tried to minimize it, but only in the current state I receive this bug with the 50% probability. Note that on M5 this bug is 100% reproducible in my environment. -- 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-1369) javax.ejb.NoSuchObjectLocalException in the ServletContextListener.contextInitialized() method
[ http://issues.apache.org/jira/browse/GERONIMO-1369?page=all ] Alexander Korostov updated GERONIMO-1369: - Attachment: test.zip geronimo.log and test application. javax.ejb.NoSuchObjectLocalException in the ServletContextListener.contextInitialized() method -- Key: GERONIMO-1369 URL: http://issues.apache.org/jira/browse/GERONIMO-1369 Project: Geronimo Type: Bug Components: web Versions: 1.0 Environment: Windows XP (SP2), Sun JDK build 1.4.2_08-b03 Reporter: Alexander Korostov Attachments: test.zip In my application, I lookup and invoke a session bean (via local interface) in the ServletContextListener.contextInitialized(). Sometimes application throws a NoSuchObjectLocalException in the ServletContextListener.contextInitialized(), sometimes all works fine. This bug is appeared on both Tomcat and Jetty. I can not reproduce this bug with the 100% probability on the latest snapshot. Even if I change the application a bit (rename the EJB or WEB project) this bug can disappear or appear again. It looks like some synchronization (racing conditions) problem: sometimes LocalHome of my bean is published before the ServletContextListener.contextInitialized() invoked, sometimes not. See the attached geronimo.log and a test application. Note that the geronimo.log contains both cases: 1. when the application starts fine 2. throws an exception. Sorry for the big size of the test application: I tried to minimize it, but only in the current state I receive this bug with the 50% probability. Note that on M5 this bug is 100% reproducible in my environment. -- 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
