[VOTE] genesis 1.4 take 5
Hi, Changes in v5: legal files in all the jars (I hope) fix a typo in the NOTICE template make the generated site work better (parent link, maven feather) remove logging-config and checkstyle-config per jdillons advice. move modules to base pom, not a profile; change how bootstrap works. Changes in v4: make the legal-bundle version fixed rather than equal to the version of whatever subproject is trying to use it. Fix noise in DEPENDENCIES file generation Change legal verifier to expect LICENSE and NOTICE files by default add the rat plugin so you can run mvn rat:check for a project check (note that rat does not look inside jars so we still need the verifier) add some more commonly used plugins to the project-config and alphabetize them. Changes in v3: Change the legal-bundle to have really simple NOTICE file and put all the dependency info in a separate DEPENDENCIES file. This corresponds to what appears to be current thinking on legal-discuss about what should be in these files. We should be able to use this bundle with the maven-remote-resources-plugin everywhere now. Fiddle around with the maven site generation and site deployment so it more or less works. Add some instructions in the project-config site. Changes in v2: Change in the release plugin configuration to use the default tagBase in release profiles in projects that inherit from the project-config pom. It is also possible to override tagBase but this should not be necessary as we adhere to standard svn layout. There are also some plugin version upgrades. The new root pom includes a release profile that sets up the standard javadoc, source and gpg plugins and uses the default tagBase location. This sets us up for using the release process also now under vote described at http://cwiki.apache.org/confluence/display/GMOxPMGT/ Proposed+%28updated%29+release+process The only Jira I know about is https://issues.apache.org/jira/browse/ GERONIMO-3895 Staging repo: (note, this is a different location) http://people.apache.org/~djencks/staging-repo/genesis/org/apache/ geronimo/genesis/ site staging: http://people.apache.org/~djencks/staging-site/maven/genesis/1.4/ This time I was able to use mvn site site-deploy -Prelease to deploy the site all at once to the staging-site. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
[jira] Created: (GERONIMODEVTOOLS-294) Delete existing EMF plug-ins
Delete existing EMF plug-ins Key: GERONIMODEVTOOLS-294 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-294 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Fix For: 2.1.0 After the initial port to JAXB, the following EMF plug-ins/modules are now redundant and need to be deleted. 1) \plugins\org.apache.geronimo.v11.deployment.model 2) \plugins\org.apache.geronimo.v11.deployment.model.edit 3) \emf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-294) Delete existing EMF plug-ins
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577728#action_12577728 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-294: -- Completed: At revision: 636221 Delete existing EMF plug-ins Key: GERONIMODEVTOOLS-294 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-294 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Fix For: 2.1.0 After the initial port to JAXB, the following EMF plug-ins/modules are now redundant and need to be deleted. 1) \plugins\org.apache.geronimo.v11.deployment.model 2) \plugins\org.apache.geronimo.v11.deployment.model.edit 3) \emf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-294) Delete existing EMF plug-ins
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R closed GERONIMODEVTOOLS-294. Resolution: Fixed Delete existing EMF plug-ins Key: GERONIMODEVTOOLS-294 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-294 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Fix For: 2.1.0 After the initial port to JAXB, the following EMF plug-ins/modules are now redundant and need to be deleted. 1) \plugins\org.apache.geronimo.v11.deployment.model 2) \plugins\org.apache.geronimo.v11.deployment.model.edit 3) \emf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-295) Delete redundant dependencies from runtime plug-ins - Make GEP thinner!
Delete redundant dependencies from runtime plug-ins - Make GEP thinner! --- Key: GERONIMODEVTOOLS-295 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-295 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Fix For: 2.1.0 GEP is currently 13.3MB! Out of this ~11.6MB (87%) is from following four plug-ins! 1) \plugins\org.apache.geronimo.runtime.common 2) \plugins\org.apache.geronimo.runtime.v11 3) \plugins\org.apache.geronimo.runtime.v20 4) \plugins\org.apache.geronimo.runtime.v21 After GERONIMODEVTOOLS-294, many of the dependencies in above plug-ins might have become redundant. Identify the redundant ones and delete them to make GEP thinner :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
Hi, The directory plugin is finally ready to go. This vote includes the directory gbean and a plugin to install it. There's also a sample server that is not being voted on for release: i'm uploading it to http://people.apache.org/~djencks/samples Staging repo: http://people.apache.org/~djencks/staging-repo/plugins/directory/ Staging site: http://people.apache.org/~djencks/staging-site/plugins/directory/1.0/ index.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
Re: [VOTE] genesis 1.4 take 5
+1 david jencks On Mar 11, 2008, at 11:37 PM, David Jencks wrote: Hi, Changes in v5: legal files in all the jars (I hope) fix a typo in the NOTICE template make the generated site work better (parent link, maven feather) remove logging-config and checkstyle-config per jdillons advice. move modules to base pom, not a profile; change how bootstrap works. Changes in v4: make the legal-bundle version fixed rather than equal to the version of whatever subproject is trying to use it. Fix noise in DEPENDENCIES file generation Change legal verifier to expect LICENSE and NOTICE files by default add the rat plugin so you can run mvn rat:check for a project check (note that rat does not look inside jars so we still need the verifier) add some more commonly used plugins to the project-config and alphabetize them. Changes in v3: Change the legal-bundle to have really simple NOTICE file and put all the dependency info in a separate DEPENDENCIES file. This corresponds to what appears to be current thinking on legal-discuss about what should be in these files. We should be able to use this bundle with the maven-remote-resources-plugin everywhere now. Fiddle around with the maven site generation and site deployment so it more or less works. Add some instructions in the project-config site. Changes in v2: Change in the release plugin configuration to use the default tagBase in release profiles in projects that inherit from the project-config pom. It is also possible to override tagBase but this should not be necessary as we adhere to standard svn layout. There are also some plugin version upgrades. The new root pom includes a release profile that sets up the standard javadoc, source and gpg plugins and uses the default tagBase location. This sets us up for using the release process also now under vote described at http://cwiki.apache.org/confluence/display/GMOxPMGT/ Proposed+%28updated%29+release+process The only Jira I know about is https://issues.apache.org/jira/browse/ GERONIMO-3895 Staging repo: (note, this is a different location) http://people.apache.org/~djencks/staging-repo/genesis/org/apache/ geronimo/genesis/ site staging: http://people.apache.org/~djencks/staging-site/maven/genesis/1.4/ This time I was able to use mvn site site-deploy -Prelease to deploy the site all at once to the staging-site. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
Re: [VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
I forgot to note that this depends on the genesis 1.4 release vote passing. If we go on to take 6 there we'll need to redo this release. +1 david jencks On Mar 12, 2008, at 12:46 AM, David Jencks wrote: Hi, The directory plugin is finally ready to go. This vote includes the directory gbean and a plugin to install it. There's also a sample server that is not being voted on for release: i'm uploading it to http://people.apache.org/~djencks/samples Staging repo: http://people.apache.org/~djencks/staging-repo/plugins/directory/ Staging site: http://people.apache.org/~djencks/staging-site/plugins/directory/ 1.0/index.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
[DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
Took the liberty to create this thread for discussion on the release. How do I install it as a plugin in G 2.1 using the artifacts in the staging repo? I tried deploy install-plugin directory-1.0.car but ended up with a missing dependency exception. ++Vamsi
[jira] Created: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
Persistence Exception is not visible/lost for client. -- Key: GERONIMO-3907 URL: https://issues.apache.org/jira/browse/GERONIMO-3907 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: persistence Affects Versions: 2.1, 2.0.2 Environment: Linux, Windows Reporter: Ralf Baumhof Priority: Blocker I am trying an insert on a table. The Entity class is wrong annotated, one column was renamed in the table. Then the following situation occurs. The call to persist(entity) is successfully, no exception is thrown. On leaving the ejb container and returning to tomact a commit is performed (it's a managed datasource, so container performs commit). This leads to the insert on database. This insert fails, a rollback is performed. On return to the JSF bean no exception can be seen by the bean. In the same class i have got a query method. If i replace the call to persist with the call to the query method everything works ok. The exception is thrown and is visible at the client site. This is the geronimo console output. The last line comes from the JSB bean which reports a successful insert. 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.1-r420667:592145 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy75.anlegenBenutzer(Unknown Source) at de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54) at javax.faces.component.UICommand.broadcast(UICommand.java:121) at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292) at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:117) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at
Stoppage of message processing when instanceLimit maxSessions
Hi, I just checked opened a a defect in activemq as discussed with david jencks on IRC. This deals with Mdbs stopping processing if the instance limit is maxSessions. The defect is https://issues.apache.org/activemq/browse/AMQ-1618. It is present in all the versions of AMQ. I have also explained and tried out the fix that David suggested and it works absolutely fine Regards Manu
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577805#action_12577805 ] Ralf Baumhof commented on GERONIMO-3907: The same proble occurs, if i correct the annotations, but have an invalid foreign key in one column. The persist method is successfully, and later the commit fails. The call stack, the first line is from the DAO class which reports that the persist method was ok, the last line is from the JSF bean. [de.nrw.hagen.ggrz.bv.benutzer.db.BenutzerDAOImpl] $$ BenutzerDAO::generated id = 32 12:36:12,337 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.1-r420667:592145 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy78.anlegenBenutzer(Unknown Source) at de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54) at javax.faces.component.UICommand.broadcast(UICommand.java:121) at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292) at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:117) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at
Re: DayTrader build error
selesh, You could try using maven to install the jar into the repo. This would guarantee that the jar would be in the correct directory structure. Instructions on what command to use and how to use it can be found here: http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html Hope this helps, On Wed, Mar 12, 2008 at 7:31 AM, seleshmaster [EMAIL PROTECTED] wrote: Kevan Miller wrote: On Mar 11, 2008, at 6:52 AM, seleshmaster wrote: snip thx again I dont know what I am missing but I installed the jar file under maven/lib directory where other jar file exist but I am still getting the same error. by the way, i reverted back to maven 2.0.6 The maven-ejb-plugin needs to end up in your .m2 repository. For me, it's: /Users/kevan/.m2/repository/org/apache/maven/plugins/maven-ejb-plugin/ 2.1/maven-ejb-plugin-2.1.jar --kevan thx kevan; obviously I am still missing something else cause I am still getting the same error. here is what i did 0) I installed maven.2.0.7 Maven version: 2.0.7 Java version: 1.5.0_13 OS name: mac os x version: 10.5.2 arch: i386 1) I checked out the source. svn co 2) I put maven-ejb-plugin.jar under /Users/seleshmaster/.m2/repository/org/apache/maven/plugins/maven-ejb-plugin Note: for some reason, there was no directory name 2.1, so I just created it manually and put the .jar file there too 3) and from /Users/seleshmaster/workspace/trunk directory i run mvn install 4) and I am getting this error ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-ejb-plugin' does not exist or no valid version could be found thx for the help. -- View this message in context: http://www.nabble.com/DayTrader-build-error-tp15973242s134p16001762.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- ~Jason Warner
Re: DayTrader build error
Kevan Miller wrote: On Mar 11, 2008, at 6:52 AM, seleshmaster wrote: snip thx again I dont know what I am missing but I installed the jar file under maven/lib directory where other jar file exist but I am still getting the same error. by the way, i reverted back to maven 2.0.6 The maven-ejb-plugin needs to end up in your .m2 repository. For me, it's: /Users/kevan/.m2/repository/org/apache/maven/plugins/maven-ejb-plugin/ 2.1/maven-ejb-plugin-2.1.jar --kevan thx kevan; obviously I am still missing something else cause I am still getting the same error. here is what i did 0) I installed maven.2.0.7 Maven version: 2.0.7 Java version: 1.5.0_13 OS name: mac os x version: 10.5.2 arch: i386 1) I checked out the source. svn co 2) I put maven-ejb-plugin.jar under /Users/seleshmaster/.m2/repository/org/apache/maven/plugins/maven-ejb-plugin Note: for some reason, there was no directory name 2.1, so I just created it manually and put the .jar file there too 3) and from /Users/seleshmaster/workspace/trunk directory i run mvn install 4) and I am getting this error ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-ejb-plugin' does not exist or no valid version could be found thx for the help. -- View this message in context: http://www.nabble.com/DayTrader-build-error-tp15973242s134p16001762.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: DayTrader build error
seleshmaster wrote: 2) I put maven-ejb-plugin.jar under /Users/seleshmaster/.m2/repository/org/apache/maven/plugins/maven-ejb-plugin Note: for some reason, there was no directory name 2.1, so I just created it manually and put the .jar file there too I'm not sure why this isn't being pulled for you as part of the build for you ... but if you must manually place the jar in your local repo make sure that the name includes the version ... ie. maven-ejb-plugin-2.1.jar and not just maven-ejb-plugin.jar. You would also have to create the version directory path as you noted. One other thing to try before that is to rm -rf /Users/seleshmaster/.m2/repository/org/apache/maven/plugins/maven-ejb-plugin prior attempting the build. Perhaps something has become corrupted in the maven-ejb-plugin pom that is causing maven from not being able to download this. Hope that helps, Joe
Re: LDAP server in 2.1.1
Joe Bohn wrote: Were you able to get this working using the 2.1 released server and the plugin from branches/1.0? I'm thinking that we probably need to release a version of this directory plugin for Geronimo 2.1. Most users aren't going to want to build it locally and I don't see it listed when looking at the plugins for 2.1 on http://geronimo.apache.org/plugins/geronimo-2.1/ Hi Joe, For the sample I did not try the plugin route, but rather the standalone directory server, and updated the docs with that suggestion. I look forward to retesting it and updating the docs with David Jencks' plugin 1.0 for Apache Directory 1.5.1. -- Thanks, Dan Becker
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577846#action_12577846 ] Ralf Baumhof commented on GERONIMO-3907: More over. Two nearly identical situations. In both cases the insert fails because of invalid foreign keys. In both cases the persist method first does not throw an exception. But in the first case (the working case) there are some additional inserts and updates which may force that the data is written to database a little bit earlier. In this case the exception is visible and catchable at the level of the service fassace. In the second case (the case described above) it is not visible - neither at the service fassade, nor at the JSF bean. This works (the exception can be caught at the service fassade): javax.ejb.EJBTransactionRolledbackException: The transaction has been marked rollback only because the bean encountered a non-application exception :javax.ejb.EJBTransactionRolledbackException : The transaction has been marked rollback only because the bean encountered a non-application exception :org.apache.openjpa.persistence.PersistenceException : The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:348) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:323) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy97.anlegenSchuldnerEintrag(Unknown Source) at de.nrw.hagen.ggrz.vesuv.schuldner.services.SchuldnerServiceManagerImpl.AnlegenSchuldnerJuristischePersonZSV(SchuldnerServiceManagerImpl.java:49) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:146) at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:129) at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy96.AnlegenSchuldnerJuristischePersonZSV(Unknown Source) at de.nrw.hagen.ggrz.vesuv.schuldner.controler.SRegControlerBean.anlegenJPerson(SRegControlerBean.java:115) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54) at javax.faces.component.UICommand.broadcast(UICommand.java:121) at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292) at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:117) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148) at
Re: [DISCUSS] Geronimo 2.1 samples
Donald Woods wrote: Joe Bohn wrote: 2) When to release the samples? I think we should make an effort to release the samples concurrent with each Geronimo release. This is important because the jsp servlet examples are referenced from within the welcome page on Geronimo. I suppose we could remove that reference and eliminate the need to release concurrently. why not move the samples back under geronimo/server, so they are maintained and versioned with each release and can then be used as additional testsuite tests? If not, releasing right after a server release is fine. I was thinking about doing this. It seems everybody thinks we should release them together anyway so what is the real value with them being split out? Does anybody object to moving them back with the server? Joe
Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
make it two! I could use some guidance for installing it. I manually added the geronimo-directory-1.0.jar to the repo but then got another dep missing org.apache.directory.server/apacheds-server-jndi/1.5.1/jar Cheers! Hernan Vamsavardhana Reddy wrote: Took the liberty to create this thread for discussion on the release. How do I install it as a plugin in G 2.1 using the artifacts in the staging repo? I tried deploy install-plugin directory-1.0.car but ended up with a missing dependency exception. ++Vamsi
Re: [DISCUSS] Geronimo 2.1.1 release
Vasily Zakharov wrote: Is there a chance OpenEJB 3.0 release will make it to 2.1.1? It would be great if we could pick up an openejb 3.0 release (which would include fixes for some issues recently discussed on this list). Does anybody know the target for a 3.0 release of OpenEjb? Joe
Re: [DISCUSS] Geronimo 2.1 samples
No objection, it should be easier to maintain and as Donald mentioned, we could get some extra juice out of them as testsuite tests. My question is where would we put them now. Would they go into server/branches/2.1 so we make them available for 2.1.1? Cheers! Hernan Joe Bohn wrote: Donald Woods wrote: Joe Bohn wrote: 2) When to release the samples? I think we should make an effort to release the samples concurrent with each Geronimo release. This is important because the jsp servlet examples are referenced from within the welcome page on Geronimo. I suppose we could remove that reference and eliminate the need to release concurrently. why not move the samples back under geronimo/server, so they are maintained and versioned with each release and can then be used as additional testsuite tests? If not, releasing right after a server release is fine. I was thinking about doing this. It seems everybody thinks we should release them together anyway so what is the real value with them being split out? Does anybody object to moving them back with the server? Joe
Re: [DISCUSS] Geronimo 2.1.1 release
David Jencks wrote: There are a couple things I want to backport from trunk - archetypes - log4j app config gbean (would be good to find out if it works) - ? Also it would be great to use the genesis 1.4 if it ever gets released. On the other hand this might be too big a change we'll have to experiment. I assume you mean just upgrading to genesis 1.4 and not attempting to release using the maven-release-plugin ... right? Is it a big change to move up to genesis 1.4 without changing the release process? Joe
Re: [DISCUSS] Geronimo 2.1 samples
On Mar 12, 2008, at 7:12 AM, Joe Bohn wrote: Donald Woods wrote: Joe Bohn wrote: 2) When to release the samples? I think we should make an effort to release the samples concurrent with each Geronimo release. This is important because the jsp servlet examples are referenced from within the welcome page on Geronimo. I suppose we could remove that reference and eliminate the need to release concurrently. why not move the samples back under geronimo/server, so they are maintained and versioned with each release and can then be used as additional testsuite tests? If not, releasing right after a server release is fine. I was thinking about doing this. It seems everybody thinks we should release them together anyway so what is the real value with them being split out? Does anybody object to moving them back with the server? well, since I thought our next goal with the server build was to separate it into independently released plugins, I think putting the samples in with the main server build would be a big step backwards. thanks david jencks Joe
Re: [DISCUSS] Geronimo 2.1.1 release
On Mar 12, 2008, at 8:04 AM, Joe Bohn wrote: David Jencks wrote: There are a couple things I want to backport from trunk - archetypes - log4j app config gbean (would be good to find out if it works) - ? Also it would be great to use the genesis 1.4 if it ever gets released. On the other hand this might be too big a change we'll have to experiment. I assume you mean just upgrading to genesis 1.4 and not attempting to release using the maven-release-plugin ... right? Is it a big change to move up to genesis 1.4 without changing the release process? You get generated legal files included automatically unless you turn them off (not sure how). Im not sure how realistic it is for 2.1.1 to use genesis 1.4 but it turns out the car plugin is finicky and tends to pull in genesis 1.3 or earlier unless you do something tricky with profiles. thanks david jencks Joe
Re: [DISCUSS] Geronimo 2.1.1 release
Jason Warner wrote: I just opened https://issues.apache.org/jira/browse/GERONIMO-3902 the other day. I'd like to get a patch up for that and get it in. It's not really crucial as long as we note what the issue is, though. I agree that it would be good to include a fix for this. Joe
Re: [DISCUSS] Geronimo 2.1 samples
David Jencks wrote: On Mar 12, 2008, at 7:12 AM, Joe Bohn wrote: Donald Woods wrote: Joe Bohn wrote: 2) When to release the samples? I think we should make an effort to release the samples concurrent with each Geronimo release. This is important because the jsp servlet examples are referenced from within the welcome page on Geronimo. I suppose we could remove that reference and eliminate the need to release concurrently. why not move the samples back under geronimo/server, so they are maintained and versioned with each release and can then be used as additional testsuite tests? If not, releasing right after a server release is fine. I was thinking about doing this. It seems everybody thinks we should release them together anyway so what is the real value with them being split out? Does anybody object to moving them back with the server? well, since I thought our next goal with the server build was to separate it into independently released plugins, I think putting the samples in with the main server build would be a big step backwards. Well, I agree that it would appear to be a step backwards from that perspective. However, it would ensure the following: 1) The samples would get released (not forgotten as has been the case with 2.1) 2) The samples would be released concurrent with the Geronimo release so that they are available for use, education, and documentation from day 1. It seems almost everybody is in favor of this. 3) They could be leveraged in the testsuite tests (as Donald pointed out) to help validate our build and find problems earlier. I fail to see too many negatives from a practical perspective but I'm certainly open to discussion I want to do what is best. Perhaps we need to refine our plugin strategy. There are situations where it makes sense to split things apart but there are also situations where it might make sense to bundle things. Joe
Re: [DISCUSS] Geronimo 2.1 samples
I agree with David. There is no need to cram everything into server/trunk. Samples are now hooked up with the automatic Geronimo builds so I think that should be enough (as long as people will actaully pay attention if they fail to build ok). Jarek On Wed, Mar 12, 2008 at 11:16 AM, David Jencks [EMAIL PROTECTED] wrote: On Mar 12, 2008, at 7:12 AM, Joe Bohn wrote: Donald Woods wrote: Joe Bohn wrote: 2) When to release the samples? I think we should make an effort to release the samples concurrent with each Geronimo release. This is important because the jsp servlet examples are referenced from within the welcome page on Geronimo. I suppose we could remove that reference and eliminate the need to release concurrently. why not move the samples back under geronimo/server, so they are maintained and versioned with each release and can then be used as additional testsuite tests? If not, releasing right after a server release is fine. I was thinking about doing this. It seems everybody thinks we should release them together anyway so what is the real value with them being split out? Does anybody object to moving them back with the server? well, since I thought our next goal with the server build was to separate it into independently released plugins, I think putting the samples in with the main server build would be a big step backwards. thanks david jencks Joe
Re: [DISCUSS] Geronimo 2.1 samples
I also am in agreement with David on this, I think it would be a far better approach to not include them within trunk. While it may be a bit more work to release them separately from the actual server release, it would seem to be a big step backwards with what we have been working on. Perhaps we need a more thorough / checklist style release process to ensure certain requisites are always met (I.E. samples are ready as well) Thanks, Erik B. Craig [EMAIL PROTECTED] David Jencks wrote: On Mar 12, 2008, at 7:12 AM, Joe Bohn wrote: Donald Woods wrote: Joe Bohn wrote: 2) When to release the samples? I think we should make an effort to release the samples concurrent with each Geronimo release. This is important because the jsp servlet examples are referenced from within the welcome page on Geronimo. I suppose we could remove that reference and eliminate the need to release concurrently. why not move the samples back under geronimo/server, so they are maintained and versioned with each release and can then be used as additional testsuite tests? If not, releasing right after a server release is fine. I was thinking about doing this. It seems everybody thinks we should release them together anyway so what is the real value with them being split out? Does anybody object to moving them back with the server? well, since I thought our next goal with the server build was to separate it into independently released plugins, I think putting the samples in with the main server build would be a big step backwards. thanks david jencks Joe
[jira] Commented: (GERONIMO-3833) Hard-coded gbean names and versions in monitoring code
[ https://issues.apache.org/jira/browse/GERONIMO-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577898#action_12577898 ] Viet Hung Nguyen commented on GERONIMO-3833: Committed revision 636392 to trunk removing hard coded mbean name. dynamically fetches it instead. Hard-coded gbean names and versions in monitoring code -- Key: GERONIMO-3833 URL: https://issues.apache.org/jira/browse/GERONIMO-3833 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jarek Gawor Assignee: Viet Hung Nguyen Fix For: 2.1.1, 2.2 The monitoring code has hard-coded values in Java code and sql file: 1) The ./plugins/monitoring/mconsole-war/src/main/java/org/apache/geronimo/monitoring/console/MRCConnector.java contains the following constant: private static final String PATH = geronimo:ServiceModule=org.apache.geronimo.plugins.monitoring/agent-car-jmx/2.1-SNAPSHOT/car,J2EEServer=geronimo, name=MasterRemoteControlJMX,j2eeType=GBean; 2) The ./plugins/monitoring/mconsole-ear/src/main/resources/MonitoringClientDB.sql contains a bunch of the following values: 'geronimo:J2EEServer=geronimo,ServiceModule=org.apache.geronimo.configs/tomcat6/2.1/car,j2eeType=GBean,name=TomcatWebConnector' I'm not sure how these are used but in general these type of hardcoded values should be avoided. It's really hard to maintain and keep track of. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: link to eclipse settings on coding standards page?
Can we also add the following link to the coding-standards page: http://cwiki.apache.org/GMOxDEV/subversion-client-configuration.html Jarek On Thu, Mar 6, 2008 at 4:57 PM, Ted Kirby [EMAIL PROTECTED] wrote: From http://geronimo.apache.org/coding-standards.html, can you add some text and a link to http://cwiki.apache.org/GMOxDEV/developing-geronimo-in-eclipse.html, which is available from devtools page, developing geronimo in eclipse? I took a shot at it, but did not appear to have permission to do so. It's nice to describe the coding standards, but even better, I think, to tell how to configure them IDEs that support it. Thanks, Ted Kirby
Re: Gshell fails to launch on trunk
This should be fixed now. I updated - assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/gsh-classworlds.conf to use the same mina 1.1.5 version as the server in branches/2.1 and trunk. -Donald Jason Warner wrote: I checked out the latest trunk and tried to launch gshell, but found that it failed due to an error in plexus. The problem seems to be caused by the recent update to using mina 1.1.5. The 1.0-alpha-1 version of gshell that is being used is telling plexus to look for version 1.1.2 of mina-core. When it doesn't find it, it blows up and the console isn't launched. This can be fixed by changing the version of mina that it is searching for in the gsh-classworlds.conf file in the etc directory. What would be the proper fix for this? 1.0-alpha-1 is the latest tag. It looks like trunk was recently updated to use mina-1.1.6. I imagine we'd have the same problem using a snapshot build of trunk given that there's a version difference. Is there another way to fix this problem or do we need to move gshell trunk over to 1.1.5 and then include the snapshot build in geronimo trunk? Thanks, -- ~Jason Warner smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
I have built the plugin from http://svn.apache.org/repos/asf/geronimo/plugins/directory/tags/directory-parent-1.0/and then used my local m2repo in Plugins portlet to install the plugin. I have verified by creating an LDAP Realm and a sample application using that realm. Only problem I ran into with the realm is that I had to use User DN=uid=admin, ou=system where as earlier I could use User DN=uid=admin,ou=system (note: there is no space after admin, in the second entry). ++Vamsi On Wed, Mar 12, 2008 at 2:04 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Took the liberty to create this thread for discussion on the release. How do I install it as a plugin in G 2.1 using the artifacts in the staging repo? I tried deploy install-plugin directory-1.0.car but ended up with a missing dependency exception. ++Vamsi
Re: Gshell fails to launch on trunk
Donald, It looks good to me. Thanks! On Wed, Mar 12, 2008 at 12:42 PM, Donald Woods [EMAIL PROTECTED] wrote: This should be fixed now. I updated - assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/gsh- classworlds.conf to use the same mina 1.1.5 version as the server in branches/2.1 and trunk. -Donald Jason Warner wrote: I checked out the latest trunk and tried to launch gshell, but found that it failed due to an error in plexus. The problem seems to be caused by the recent update to using mina 1.1.5. The 1.0-alpha-1 version of gshell that is being used is telling plexus to look for version 1.1.2 of mina-core. When it doesn't find it, it blows up and the console isn't launched. This can be fixed by changing the version of mina that it is searching for in the gsh-classworlds.conf file in the etc directory. What would be the proper fix for this? 1.0-alpha-1 is the latest tag. It looks like trunk was recently updated to use mina-1.1.6. I imagine we'd have the same problem using a snapshot build of trunk given that there's a version difference. Is there another way to fix this problem or do we need to move gshell trunk over to 1.1.5 and then include the snapshot build in geronimo trunk? Thanks, -- ~Jason Warner -- ~Jason Warner
Re: module builders/deployers in plugins
2) The AdminObjectRefBuilder is always trying to process _all_ resource-env-ref entries (AdminObjectRefBuilder is just an example in this case). However, as things evolve (Java EE 5 - 6) and new resource env. types are added, it does not scale to keep updating the AdminObjectRefBuilder to handle these new types. So I think it would be nice to install a new builder that would handle these new types only. But that would require communicating with the AdminObjectRefBuilder and somehow telling it to ignore the new types. The question is, what would be the best way of doing it? Or maybe we need a different way of processing the DDs? This is kind of a tricky problem and I don't know the best way to handle it. I doubt you want to get into rewriting the entire way we resolve resource-env-refs at this point -- let me know if you do -- so I would look into exactly what is keeping the current AdminObjectRefBuilder from handling your new kinds of refs and whether there is an easy way to exclude them. Some possibilities - the AdminObjectRefBuilder.AdminObjectRefProcessor picks out the annotations we will look at. If the new stuff can only be referred to as @Resource you can have the AdminObjectRefProcessor skip the new kinds. - basically the AdminObjectRefBuilder works by finding a gbean that corresponds to the name information and type information supplied, around line 373. We could expand the choices for how we look for target gbeans. - we might be able to make the NamingBuilderCollection ordered and have the builders not try to deal with questionable items that have already been processed. I tried the last option. Specifically, I modified the AdminObjectRefBuilder to ignore elements that were already added to the jndi context map (assuming the NamingBuilderCollection would be ordered and that my builder would execute before the AdminObjectRefBuilder). However, since both Builders process the same type of elements in the DDs the NamingBuilderCollection did not like that and I got the following exception: 3:01:30,421 ERROR [ProxyCollection] Listener threw exception java.lang.IllegalArgumentException: Duplicate builderSpecQNames in builder set: QNameSet+([EMAIL PROTECTED]://java.sun.com/xml/ns/javaee, [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee) and duplicate builderPlanQNames in builder set : QNameSet+([EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2) So this option would work only if I disabled this check or returned some other qnames for builderSpecQNames and builderPlanQNames in my builder. Also, I could create a new switching builder for processing the resource-env-ref elements and have it just basically redirect the calls to the AdminObjectRefBuilder and my builder (to avoid the above error) and combine it with the last option you described. Jarek
Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
On Mar 12, 2008, at 1:34 AM, Vamsavardhana Reddy wrote: Took the liberty to create this thread for discussion on the release. How do I install it as a plugin in G 2.1 using the artifacts in the staging repo? I tried deploy install-plugin directory-1.0.car but ended up with a missing dependency exception. I created a geronimo-plugins.xml catalog for this plugin and put it in the staging-repo. Use this as your plugin repository location: http://people.apache.org/~djencks/staging-repo/plugins/directory/ and you should be able to install from the console or gshell. I was able to install from this repo using a fresh 2.1 framework assembly starting with ./bin/gsh deploy/list-plugins -r http://people.apache.org/~djencks/ staging-repo/plugins/directory/ and following the prompts. thanks david jencks ++Vamsi
Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
Was able to install using Admin Console. ++Vamsi On Wed, Mar 12, 2008 at 11:20 PM, David Jencks [EMAIL PROTECTED] wrote: On Mar 12, 2008, at 1:34 AM, Vamsavardhana Reddy wrote: Took the liberty to create this thread for discussion on the release. How do I install it as a plugin in G 2.1 using the artifacts in the staging repo? I tried deploy install-plugin directory-1.0.car but ended up with a missing dependency exception. I created a geronimo-plugins.xml catalog for this plugin and put it in the staging-repo. Use this as your plugin repository location: http://people.apache.org/~djencks/staging-repo/plugins/directory/http://people.apache.org/%7Edjencks/staging-repo/plugins/directory/ and you should be able to install from the console or gshell. I was able to install from this repo using a fresh 2.1 framework assembly starting with ./bin/gsh deploy/list-plugins -r http://people.apache.org/~djencks/http://people.apache.org/%7Edjencks/ staging-repo/plugins/directory/ and following the prompts. thanks david jencks ++Vamsi
Re: module builders/deployers in plugins
On Mar 12, 2008, at 10:45 AM, Jarek Gawor wrote: 2) The AdminObjectRefBuilder is always trying to process _all_ resource-env-ref entries (AdminObjectRefBuilder is just an example in this case). However, as things evolve (Java EE 5 - 6) and new resource env. types are added, it does not scale to keep updating the AdminObjectRefBuilder to handle these new types. So I think it would be nice to install a new builder that would handle these new types only. But that would require communicating with the AdminObjectRefBuilder and somehow telling it to ignore the new types. The question is, what would be the best way of doing it? Or maybe we need a different way of processing the DDs? This is kind of a tricky problem and I don't know the best way to handle it. I doubt you want to get into rewriting the entire way we resolve resource-env-refs at this point -- let me know if you do -- so I would look into exactly what is keeping the current AdminObjectRefBuilder from handling your new kinds of refs and whether there is an easy way to exclude them. Some possibilities - the AdminObjectRefBuilder.AdminObjectRefProcessor picks out the annotations we will look at. If the new stuff can only be referred to as @Resource you can have the AdminObjectRefProcessor skip the new kinds. - basically the AdminObjectRefBuilder works by finding a gbean that corresponds to the name information and type information supplied, around line 373. We could expand the choices for how we look for target gbeans. - we might be able to make the NamingBuilderCollection ordered and have the builders not try to deal with questionable items that have already been processed. I tried the last option. Specifically, I modified the AdminObjectRefBuilder to ignore elements that were already added to the jndi context map (assuming the NamingBuilderCollection would be ordered and that my builder would execute before the AdminObjectRefBuilder). However, since both Builders process the same type of elements in the DDs the NamingBuilderCollection did not like that and I got the following exception: 3:01:30,421 ERROR [ProxyCollection] Listener threw exception java.lang.IllegalArgumentException: Duplicate builderSpecQNames in builder set: QNameSet+([EMAIL PROTECTED]://java.sun.com/xml/ns/ javaee, [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee) and duplicate builderPlanQNames in builder set : QNameSet+([EMAIL PROTECTED]://geronimo.apache.org/xml/ns/ naming-1.2) So this option would work only if I disabled this check or returned some other qnames for builderSpecQNames and builderPlanQNames in my builder. Also, I could create a new switching builder for processing the resource-env-ref elements and have it just basically redirect the calls to the AdminObjectRefBuilder and my builder (to avoid the above error) and combine it with the last option you described. mumbles things about hoist by own petard, too clever by half, etc etc I think you can avoid this problem by cheating and not registering any qnames in your builder. This might be sort of plausible since its not the main builder for the qnames. However we might want to rethink the entire collision avoidance theory altogether. thanks david jencks Jarek
Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
The statement about the User DN may not be correct. Will reverify. Problem may not be with the directory plugin, but, when ever there is a login failure with the LDAP realm, the following error is logged (don't remember seeing this error earlier): 23:16:52,671 ERROR [UnbindHandler] failed to unbind session properly org.apache.directory.shared.ldap.exception.LdapNameNotFoundException: uid=admin,ou=system at org.apache.directory.server.core.partition.DefaultPartitionNexus.getPartition (DefaultPartitionNexus.java:1114) at org.apache.directory.server.core.partition.DefaultPartitionNexus.unbind( DefaultPartitionNexus.java:773) at org.apache.directory.server.core.interceptor.InterceptorChain$1.unbind( InterceptorChain.java:210) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind( BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain.unbind( InterceptorChain.java:794) at org.apache.directory.server.core.partition.PartitionNexusProxy.unbind (PartitionNexusProxy.java:684) at org.apache.directory.server.core.partition.PartitionNexusProxy.unbind (PartitionNexusProxy.java:701) at org.apache.directory.server.core.jndi.ServerLdapContext.ldapUnbind( ServerLdapContext.java:210) at org.apache.directory.server.ldap.support.UnbindHandler.messageReceived( UnbindHandler.java:58) at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived( DemuxingIoHandler.java:141) at org.apache.directory.server.ldap.LdapProtocolProvider$LdapProtocolHandler.messageReceived (LdapProtocolProvider.java:428) at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570) at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived (AbstractIoFilterChain.java:299) at org.apache.mina.common.support.AbstractIoFilterChain.access$1100( AbstractIoFilterChain.java:53) at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived (AbstractIoFilterChain.java:648) at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush( SimpleProtocolDecoderOutput.java:58) at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived( ProtocolCodecFilter.java:176) at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived (AbstractIoFilterChain.java:299) at org.apache.mina.common.support.AbstractIoFilterChain.access$1100( AbstractIoFilterChain.java:53) at
[jira] Commented: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577959#action_12577959 ] Joseph Leong commented on GERONIMO-3893: Implemented Javascript to ensure one item is at least checked before rendering parameters to prevent from the 500 error. Patch will be posted shortly! -Joseph Leong When installing plugins, exception thrown when no plugins selected -- Key: GERONIMO-3893 URL: https://issues.apache.org/jira/browse/GERONIMO-3893 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor In the administration console-plugin installer. When trying to install plugins, If no plugins are selected (check box), an exception is thrown and a 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
On Wed, Mar 12, 2008 at 11:25 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: The statement about the User DN may not be correct. Will reverify. Verified to be not correct. Got confused with the ERROR logged that time!! Problem may not be with the directory plugin, but, when ever there is a login failure with the LDAP realm, the following error is logged (don't remember seeing this error earlier): 23:16:52,671 ERROR [UnbindHandler] failed to unbind session properly org.apache.directory.shared.ldap.exception.LdapNameNotFoundException: uid=admin,ou=system at org.apache.directory.server.core.partition.DefaultPartitionNexus.getPartition (DefaultPartitionNexus.java:1114) at org.apache.directory.server.core.partition.DefaultPartitionNexus.unbind( DefaultPartitionNexus.java:773) at org.apache.directory.server.core.interceptor.InterceptorChain$1.unbind( InterceptorChain.java:210) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain.unbind( InterceptorChain.java:794) at org.apache.directory.server.core.partition.PartitionNexusProxy.unbind( PartitionNexusProxy.java:684) at org.apache.directory.server.core.partition.PartitionNexusProxy.unbind( PartitionNexusProxy.java:701) at org.apache.directory.server.core.jndi.ServerLdapContext.ldapUnbind( ServerLdapContext.java:210) at org.apache.directory.server.ldap.support.UnbindHandler.messageReceived( UnbindHandler.java:58) at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived( DemuxingIoHandler.java:141) at org.apache.directory.server.ldap.LdapProtocolProvider$LdapProtocolHandler.messageReceived (LdapProtocolProvider.java:428) at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570) at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived (AbstractIoFilterChain.java:299) at org.apache.mina.common.support.AbstractIoFilterChain.access$1100( AbstractIoFilterChain.java:53) at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived (AbstractIoFilterChain.java:648) at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush( SimpleProtocolDecoderOutput.java:58) at
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577961#action_12577961 ] Donald Woods commented on GERONIMO-3907: Have you tried one of the 2.1.1-SNAPSHOT or 2.2-SNAPSHOT daily builds from 20080312 or later? I upgraded both to use OpenJPA 1.0.2 yesterday, which had some bug fixes in it. Persistence Exception is not visible/lost for client. -- Key: GERONIMO-3907 URL: https://issues.apache.org/jira/browse/GERONIMO-3907 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0.2, 2.1 Environment: Linux, Windows Reporter: Ralf Baumhof Priority: Blocker Original Estimate: 0.08h Remaining Estimate: 0.08h I am trying an insert on a table. The Entity class is wrong annotated, one column was renamed in the table. Then the following situation occurs. The call to persist(entity) is successfully, no exception is thrown. On leaving the ejb container and returning to tomact a commit is performed (it's a managed datasource, so container performs commit). This leads to the insert on database. This insert fails, a rollback is performed. On return to the JSF bean no exception can be seen by the bean. In the same class i have got a query method. If i replace the call to persist with the call to the query method everything works ok. The exception is thrown and is visible at the client site. This is the geronimo console output. The last line comes from the JSB bean which reports a successful insert. 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.1-r420667:592145 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy75.anlegenBenutzer(Unknown Source) at de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54) at javax.faces.component.UICommand.broadcast(UICommand.java
Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
I believe I've seen this with standalone apacheds 1.5.1 as well, I don't think it is the plugin's fault. I don't see any geronimo- controlled classes in this stack trace. anyone able to verify? thanks david jencks On Mar 12, 2008, at 10:55 AM, Vamsavardhana Reddy wrote: The statement about the User DN may not be correct. Will reverify. Problem may not be with the directory plugin, but, when ever there is a login failure with the LDAP realm, the following error is logged (don't remember seeing this error earlier): 23:16:52,671 ERROR [UnbindHandler] failed to unbind session properly org.apache.directory.shared.ldap.exception.LdapNameNotFoundException: uid=admin,ou=system at org.apache.directory.server.core.partition.DefaultPartitionNexus.getPa rtition(DefaultPartitionNexus.java:1114) at org.apache.directory.server.core.partition.DefaultPartitionNexus.unbin d(DefaultPartitionNexus.java:773) at org.apache.directory.server.core.interceptor.InterceptorChain $1.unbind(InterceptorChain.java:210) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain $Entry$1.unbind(InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain.unbind (InterceptorChain.java:794) at org.apache.directory.server.core.partition.PartitionNexusProxy.unbind( PartitionNexusProxy.java:684) at org.apache.directory.server.core.partition.PartitionNexusProxy.unbind( PartitionNexusProxy.java:701) at org.apache.directory.server.core.jndi.ServerLdapContext.ldapUnbind (ServerLdapContext.java:210) at org.apache.directory.server.ldap.support.UnbindHandler.messageReceived (UnbindHandler.java:58) at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived (DemuxingIoHandler.java:141) at org.apache.directory.server.ldap.LdapProtocolProvider $LdapProtocolHandler.messageReceived(LdapProtocolProvider.java:428) at org.apache.mina.common.support.AbstractIoFilterChain $TailFilter.messageReceived(AbstractIoFilterChain.java:570) at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageRe ceived(AbstractIoFilterChain.java:299) at org.apache.mina.common.support.AbstractIoFilterChain.access $1100(AbstractIoFilterChain.java:53) at org.apache.mina.common.support.AbstractIoFilterChain $EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648) at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush
[jira] Commented: (GERONIMO-3781) Plugin Installer, CRSF issue when attempting to install a new plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577963#action_12577963 ] Donald Woods commented on GERONIMO-3781: Do we still have a Jetty issue here for 2.1.1? Plugin Installer, CRSF issue when attempting to install a new plugin Key: GERONIMO-3781 URL: https://issues.apache.org/jira/browse/GERONIMO-3781 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Fix For: 2.1.1 Plugin installer will not allow for you to install anymore plugins on a second attempt given that it threw an exception the first time. This is attributed to the exception thrown that doesn't properly exit and close off current sessions. So in the second attempt there is a cookie/session mismatch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3893: --- Attachment: GERONIMO-3893.patch Javascript added to check whether a plugin box is checked before submitting to prevent 500 render error. When installing plugins, exception thrown when no plugins selected -- Key: GERONIMO-3893 URL: https://issues.apache.org/jira/browse/GERONIMO-3893 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Attachments: GERONIMO-3893.patch In the administration console-plugin installer. When trying to install plugins, If no plugins are selected (check box), an exception is thrown and a 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3893: --- Patch Info: [Patch Available] When installing plugins, exception thrown when no plugins selected -- Key: GERONIMO-3893 URL: https://issues.apache.org/jira/browse/GERONIMO-3893 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Attachments: GERONIMO-3893.patch In the administration console-plugin installer. When trying to install plugins, If no plugins are selected (check box), an exception is thrown and a 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[
https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577972#action_12577972
]
Jarek Gawor commented on GERONIMO-3893:
---
One minor comment. You can optimize this by exiting as soon as one selected
thing is found. No need to go through the rest of the list in such case. So
something like the following might work better:
for (i = 0; i val.length; i++) {
if (val[i].checked == true) {
return true;
}
}
alert(You must choose at least one plugin to install.);
return false;
When installing plugins, exception thrown when no plugins selected
--
Key: GERONIMO-3893
URL: https://issues.apache.org/jira/browse/GERONIMO-3893
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 2.1
Reporter: Joseph Leong
Assignee: Joseph Leong
Priority: Minor
Attachments: GERONIMO-3893.patch
In the administration console-plugin installer. When trying to install
plugins, If no plugins are selected (check box), an exception is thrown and a
500 error occurs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3876) Allow configuring JMX over SSL
[ https://issues.apache.org/jira/browse/GERONIMO-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3876: --- Affects Version/s: 2.1.1 2.1 Fix Version/s: 2.1.1 Allow configuring JMX over SSL -- Key: GERONIMO-3876 URL: https://issues.apache.org/jira/browse/GERONIMO-3876 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: management, security Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.1, 2.2 Attachments: GERONIMO-3876.patch Currently JMX connections to Geronimo or non-SSL and Geronimo does not provide configuring SSL for JMX connections. It may be useful to provide configuration for JMX connections over SSL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3887) After installing with wrong configuration unable to proceed with any new plugin installs
[ https://issues.apache.org/jira/browse/GERONIMO-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3887: --- Affects Version/s: 2.2 2.1.1 Fix Version/s: 2.2 2.1.1 After installing with wrong configuration unable to proceed with any new plugin installs Key: GERONIMO-3887 URL: https://issues.apache.org/jira/browse/GERONIMO-3887 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Joseph Leong Assignee: Joseph Leong Fix For: 2.1.1, 2.2 The plugin installer located in the administration console fails to install new plugins once it runs into an install that throws an exception for being the wrong configuration type. IE. trying to install a Jetty piece on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3906) start-server uses hard-coded credentials that cannot be overridden
[ https://issues.apache.org/jira/browse/GERONIMO-3906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3906: --- Affects Version/s: 2.1 Fix Version/s: 2.2 2.1.1 start-server uses hard-coded credentials that cannot be overridden -- Key: GERONIMO-3906 URL: https://issues.apache.org/jira/browse/GERONIMO-3906 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jarek Gawor Fix For: 2.1.1, 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3811) EjbServer portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3811: --- Fix Version/s: 2.2 2.1.1 EjbServer portlet - Key: GERONIMO-3811 URL: https://issues.apache.org/jira/browse/GERONIMO-3811 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: OpenEJB Environment: All Reporter: Manu T George Fix For: 2.1.1, 2.2 Attachments: g3811_r632068.patch, g3811_r634213.patch, openejb.zip, screenshot-1.jpg, screenshot-2.jpg A portlet to show information about the OpenEJB container integrated in Geronimo. It should also allow configuration of some parameters like pool size etc -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods updated GERONIMO-3806:
---
Affects Version/s: 2.2
2.1.1
2.1
Fix Version/s: 2.2
2.1.1
CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
jar
-
Key: GERONIMO-3806
URL: https://issues.apache.org/jira/browse/GERONIMO-3806
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.0.2, 2.1, 2.1.1, 2.2
Environment: Windows XP SP2
Reporter: toby cabot
Assignee: Manu T George
Priority: Minor
Fix For: 2.1.1, 2.2
Attachments: bug3806-patch.txt
During deployment of one of my EJB jar files in my EAR, I get the following
WARN messages:
{code}
14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
object reference [jms/UnsequencedDestination, jms/MailQueue,
jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
jms/SequencedDestination, jms/InboundIntegrationQueue,
jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
deployment descriptor missing.
14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
corresponding entry in deployment descriptor missing.
{code}
This occurs at the point in the following point in the stack:
{code}
AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
{code}
The specDD that is passed in is a XML fragment for a specific session bean.
However, the plan that is passed in contains all the resource-ref and
resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
refMap variable does not get completely emptied out, since the specific
session bean will only contain a subset of the resource-env-refs that are
defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
+1 ++Vamsi On Wed, Mar 12, 2008 at 1:16 PM, David Jencks [EMAIL PROTECTED] wrote: Hi, The directory plugin is finally ready to go. This vote includes the directory gbean and a plugin to install it. There's also a sample server that is not being voted on for release: i'm uploading it to http://people.apache.org/~djencks/sampleshttp://people.apache.org/%7Edjencks/samples Staging repo: http://people.apache.org/~djencks/staging-repo/plugins/directory/http://people.apache.org/%7Edjencks/staging-repo/plugins/directory/ Staging site: http://people.apache.org/~djencks/staging-site/plugins/directory/1.0/index.htmlhttp://people.apache.org/%7Edjencks/staging-site/plugins/directory/1.0/index.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
[jira] Updated: (GERONIMO-3819) Update JMS Resources Portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3819: --- Fix Version/s: 2.2 2.1.1 Update JMS Resources Portlet Key: GERONIMO-3819 URL: https://issues.apache.org/jira/browse/GERONIMO-3819 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Reporter: Anish Pathadan Assignee: Anish Pathadan Fix For: 2.1.1, 2.2 Attachments: Browse Messages.jpg, JMS Resource Portlet_Main.jpg, JMSResource_portlet_1.0.patch, Send Message.jpg Update the JMS Resources portlet to include the following information from the JMS Provider 1.Count of messages send to each queue/topic ,pending messages 2.Option to send messages to messages to particular queues/topics 3.Purge messages from queues/topics 4.Browse and send messages to queues/topics -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3814) NPE in GBeanOverride
[ https://issues.apache.org/jira/browse/GERONIMO-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3814: -- Assignee: Donald Woods NPE in GBeanOverride Key: GERONIMO-3814 URL: https://issues.apache.org/jira/browse/GERONIMO-3814 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 2.0.2, 2.1, 2.1.1, 2.2 Environment: Apache Harmony Reporter: Vasily Zakharov Assignee: Donald Woods Fix For: 2.1.1, 2.2 There's a flaw in org.apache.geronimo.system.configuration.GBeanOverride: getValue(), lines 388-389: PropertyEditor editor = loadPropertyEditor(attribute, classLoader); editor.setAsText(value); loadPropertyEditor() may return null (lines 402, 407) and this can cause NPE. I didn't see this NPE on Sun, but it occurs on Harmony (clearly some other issue exists causing the loadPropertyEditor() to return null, investigating) and I think it's a problem anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3814) NPE in GBeanOverride
[ https://issues.apache.org/jira/browse/GERONIMO-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3814: --- Component/s: core Fix Version/s: 2.2 2.1.1 NPE in GBeanOverride Key: GERONIMO-3814 URL: https://issues.apache.org/jira/browse/GERONIMO-3814 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 2.0.2, 2.1, 2.1.1, 2.2 Environment: Apache Harmony Reporter: Vasily Zakharov Assignee: Donald Woods Fix For: 2.1.1, 2.2 There's a flaw in org.apache.geronimo.system.configuration.GBeanOverride: getValue(), lines 388-389: PropertyEditor editor = loadPropertyEditor(attribute, classLoader); editor.setAsText(value); loadPropertyEditor() may return null (lines 402, 407) and this can cause NPE. I didn't see this NPE on Sun, but it occurs on Harmony (clearly some other issue exists causing the loadPropertyEditor() to return null, investigating) and I think it's a problem anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Geronimo 2.1.1 release
Some JIRAs that I'd like to see in 2.l.1 - 3781, 3833, 3837, 3858, 3875, 3876, 3887, 3896, 3898, 3902, 3906 Nice to haves - 3432, 3503, 3719, 3759, 3783, 3806, 3811, 3814, 3819, 3823, 3871, 3879, 3900, 3901 -Donald Joe Bohn wrote: I think it's about time we got a 2.1.1 release out. The main motivation is to deliver a fix for the PortletSecurityException when using https on the admin console (https://issues.apache.org/jira/browse/GERONIMO-3855). but there are a lot of other fixes that have been integrated as well. The TCK looked good with a recent run ... so I think that should not be an issue. As far as snapshots go, it looks like we're now pulling in a snapshot for javamail that we would need to resolve (geronimo-javamail_1.4_mail-1.4-SNAPSHOT.jar). I think that's the only one. Are there any other changes/fixes that we should be looking to include prior to a release? I am willing to get my feet wet as the release manager unless somebody else wants to pick it up. Joe smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
Thanks for the update, I just tested big G ( both Tomcat and Jetty ) and got it working. Cheers! Hernan David Jencks wrote: On Mar 12, 2008, at 1:34 AM, Vamsavardhana Reddy wrote: Took the liberty to create this thread for discussion on the release. How do I install it as a plugin in G 2.1 using the artifacts in the staging repo? I tried deploy install-plugin directory-1.0.car but ended up with a missing dependency exception. I created a geronimo-plugins.xml catalog for this plugin and put it in the staging-repo. Use this as your plugin repository location: http://people.apache.org/~djencks/staging-repo/plugins/directory/ and you should be able to install from the console or gshell. I was able to install from this repo using a fresh 2.1 framework assembly starting with ./bin/gsh deploy/list-plugins -r http://people.apache.org/~djencks/staging-repo/plugins/directory/ and following the prompts. thanks david jencks ++Vamsi
Re: [VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
+1 Cheers! Hernan David Jencks wrote: Hi, The directory plugin is finally ready to go. This vote includes the directory gbean and a plugin to install it. There's also a sample server that is not being voted on for release: i'm uploading it to http://people.apache.org/~djencks/samples Staging repo: http://people.apache.org/~djencks/staging-repo/plugins/directory/ Staging site: http://people.apache.org/~djencks/staging-site/plugins/directory/1.0/index.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
Re: [VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
David Jencks wrote: The directory plugin is finally ready to go. This vote includes the directory gbean and a plugin to install it. There's also a sample server that is not being voted on for release: i'm uploading it to http://people.apache.org/~djencks/samples +1 -- Thanks, Dan Becker
[jira] Updated: (GERONIMO-3896) Error processing HEAD method by default HttpServlet#doHead()
[
https://issues.apache.org/jira/browse/GERONIMO-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks updated GERONIMO-3896:
---
Priority: Blocker (was: Major)
Fix Version/s: 2.2
2.1.1
will try to get servlet spec release out shortly.
Tomcat has agreed this is a bug and applied the fix in the patch.
Error processing HEAD method by default HttpServlet#doHead()
Key: GERONIMO-3896
URL: https://issues.apache.org/jira/browse/GERONIMO-3896
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: specs
Affects Versions: 2.0.2
Environment: Geronimo 2.0.2/Tomcat, Geronimo 2.1?
Reporter: Andrey Utkin
Assignee: David Jencks
Priority: Blocker
Fix For: 2.1.1, 2.2
Attachments: GERONIMO-3896.patch,
geronimo-servlet_2.5_spec-1.1.1-fake.jar
I have Servlet with use RequestDispatcher.include()/forward() to JSP.
My Servlet extends HttpServlet. I don`t overwrite doHead() method.
While processing HEAD method following exception throws:
{code}
09:18:57,647 ERROR [[SimpleDispatchServlet]] Servlet.service() for servlet
SimpleDispatchServlet threw exception
javax.servlet.ServletException: Original SevletResponse or wrapped original
ServletResponse not passed to
RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
at
org.apache.catalina.core.ApplicationDispatcher.checkSameObjects(ApplicationDispatcher.java:985)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:493)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
at
com.km.webapp.test.simple.SimpleDispatchServlet.doGet(SimpleDispatchServlet.java:26)
at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:274)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:353)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
{code}
Exploring code I found that Tomcat`s implementation of RequestDispatcher
expects that passed Response/Request objects is original objects or is
wrapped by ServletRequestWrapper/ServletResponseWrapper. But
geronimo-servlet_2.5_spec/HttpServlet.java#doHead() use NoBodyResponse class
which is not instance of ServletResponseWrapper. So, exception thrown.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3908) Spec parent pom should be in a specs-parent project so releasing it doesn't copy all the specs that happen to be in trunk.
Spec parent pom should be in a specs-parent project so releasing it doesn't copy all the specs that happen to be in trunk. -- Key: GERONIMO-3908 URL: https://issues.apache.org/jira/browse/GERONIMO-3908 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem, specs Affects Versions: 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 Releasing the specs 1.4 pom produced a copy of all the specs that happened to be in trunk at that moment in tags/specs-1.4/. This is dumb but hard to avoid with the current directory layout. I'm going to move the parent pom to a specs-parent directory and change its artifact id to specs-parent. This will make releasing it more clearly independent of any specs that may be using it. As an independent comment I think the idea of erasing released specs from trunk is too error prone. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3908) Spec parent pom should be in a specs-parent project so releasing it doesn't copy all the specs that happen to be in trunk.
[ https://issues.apache.org/jira/browse/GERONIMO-3908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3908. -- Resolution: Fixed rev 636516. Spec parent pom should be in a specs-parent project so releasing it doesn't copy all the specs that happen to be in trunk. -- Key: GERONIMO-3908 URL: https://issues.apache.org/jira/browse/GERONIMO-3908 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem, specs Affects Versions: 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 Releasing the specs 1.4 pom produced a copy of all the specs that happened to be in trunk at that moment in tags/specs-1.4/. This is dumb but hard to avoid with the current directory layout. I'm going to move the parent pom to a specs-parent directory and change its artifact id to specs-parent. This will make releasing it more clearly independent of any specs that may be using it. As an independent comment I think the idea of erasing released specs from trunk is too error prone. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3909) Make NamingBuilders/NamingBuilderCollection ordered
Make NamingBuilders/NamingBuilderCollection ordered --- Key: GERONIMO-3909 URL: https://issues.apache.org/jira/browse/GERONIMO-3909 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Affects Versions: 2.2 Reporter: Jarek Gawor Assignee: Jarek Gawor Sometimes it might be necessary for one NamingBuilder to run before another one. Right now, the NamingBuilderCollection is un-ordered and the NamingBuilder are invoked in random order. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3893: --- Affects Version/s: 2.1.1 Fix Version/s: 2.1.1 When installing plugins, exception thrown when no plugins selected -- Key: GERONIMO-3893 URL: https://issues.apache.org/jira/browse/GERONIMO-3893 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Fix For: 2.1.1 Attachments: GERONIMO-3893.patch In the administration console-plugin installer. When trying to install plugins, If no plugins are selected (check box), an exception is thrown and a 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3910) Rename classes, remove IBM references
Rename classes, remove IBM references - Key: GERONIMO-3910 URL: https://issues.apache.org/jira/browse/GERONIMO-3910 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: sample apps Affects Versions: 1.x Reporter: Erik B. Craig Assignee: Erik B. Craig Priority: Critical In the migration sample apps from the 1.0 branch, there are classes named com.ibm.x. These need to be renamed to o.a.g -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3781) Plugin Installer, CRSF issue when attempting to install a new plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578036#action_12578036 ] Joseph Leong commented on GERONIMO-3781: As far as I know I haven't implemented any changes for this yet, still working on it. Plugin Installer, CRSF issue when attempting to install a new plugin Key: GERONIMO-3781 URL: https://issues.apache.org/jira/browse/GERONIMO-3781 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Fix For: 2.1.1 Plugin installer will not allow for you to install anymore plugins on a second attempt given that it threw an exception the first time. This is attributed to the exception thrown that doesn't properly exit and close off current sessions. So in the second attempt there is a cookie/session mismatch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3911) Get version 1.1 migration sample apps checked in from wiki and cleaned up
Get version 1.1 migration sample apps checked in from wiki and cleaned up -- Key: GERONIMO-3911 URL: https://issues.apache.org/jira/browse/GERONIMO-3911 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Affects Versions: 1.1.x Reporter: Erik B. Craig Assignee: Erik B. Craig LICENCE.txt, NOTICE.txt, and ASF license headers need to be added, as well as all line endings converted to unix format and tabs converted to spaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3912) Get version 2.0 migration sample apps checked in from wiki and cleaned up
Get version 2.0 migration sample apps checked in from wiki and cleaned up -- Key: GERONIMO-3912 URL: https://issues.apache.org/jira/browse/GERONIMO-3912 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Affects Versions: 1.1.x Reporter: Erik B. Craig Assignee: Erik B. Craig LICENCE.txt, NOTICE.txt, and ASF license headers need to be added, as well as all line endings converted to unix format and tabs converted to spaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
+1 :) On Wed, Mar 12, 2008 at 3:19 PM, Dan Becker [EMAIL PROTECTED] wrote: David Jencks wrote: The directory plugin is finally ready to go. This vote includes the directory gbean and a plugin to install it. There's also a sample server that is not being voted on for release: i'm uploading it to http://people.apache.org/~djencks/sampleshttp://people.apache.org/%7Edjencks/samples +1 -- Thanks, Dan Becker
Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0
This is a minor and harmless bug in the server. It occurs on all unbinds and you might specifically want to make sure it is not allowed to log. We're aware of it and will fix this shortly over at Apache Directory. Alex On Wed, Mar 12, 2008 at 2:26 PM, David Jencks [EMAIL PROTECTED] wrote: I believe I've seen this with standalone apacheds 1.5.1 as well, I don't think it is the plugin's fault. I don't see any geronimo-controlled classes in this stack trace. anyone able to verify? thanks david jencks On Mar 12, 2008, at 10:55 AM, Vamsavardhana Reddy wrote: The statement about the User DN may not be correct. Will reverify. Problem may not be with the directory plugin, but, when ever there is a login failure with the LDAP realm, the following error is logged (don't remember seeing this error earlier): 23:16:52,671 ERROR [UnbindHandler] failed to unbind session properly org.apache.directory.shared.ldap.exception.LdapNameNotFoundException: uid=admin,ou=system at org.apache.directory.server.core.partition.DefaultPartitionNexus.getPartition (DefaultPartitionNexus.java:1114) at org.apache.directory.server.core.partition.DefaultPartitionNexus.unbind( DefaultPartitionNexus.java:773) at org.apache.directory.server.core.interceptor.InterceptorChain$1.unbind( InterceptorChain.java:210) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind (InterceptorChain.java:1412) at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind (BaseInterceptor.java:229) at org.apache.directory.server.core.interceptor.InterceptorChain.unbind( InterceptorChain.java:794) at org.apache.directory.server.core.partition.PartitionNexusProxy.unbind( PartitionNexusProxy.java:684) at org.apache.directory.server.core.partition.PartitionNexusProxy.unbind( PartitionNexusProxy.java:701) at org.apache.directory.server.core.jndi.ServerLdapContext.ldapUnbind( ServerLdapContext.java:210) at org.apache.directory.server.ldap.support.UnbindHandler.messageReceived( UnbindHandler.java:58) at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived( DemuxingIoHandler.java:141) at org.apache.directory.server.ldap.LdapProtocolProvider$LdapProtocolHandler.messageReceived (LdapProtocolProvider.java:428) at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570) at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived (AbstractIoFilterChain.java:299)
Re: DayTrader build error
thx guys again; I removed the whole repo directory and run mvn install command again. This seem to fix the problem I was getting in the past but now I am getting a new type of error message but still related to maven-ejb-plugin. here is the error message. - [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-ejb-plugin:2.1:ejb': Unable to find the mojo 'org.apache.maven.plugins:maven-ejb-plugin:2.1:ejb' in the plugin 'org.apache.maven.plugins:maven-ejb-plugin' org/codehaus/plexus/archiver/jar/ManifestException [INFO] - Jason Warner wrote: selesh, You could try using maven to install the jar into the repo. This would guarantee that the jar would be in the correct directory structure. Instructions on what command to use and how to use it can be found here: http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html Hope this helps, On Wed, Mar 12, 2008 at 7:31 AM, seleshmaster [EMAIL PROTECTED] wrote: Kevan Miller wrote: On Mar 11, 2008, at 6:52 AM, seleshmaster wrote: snip thx again I dont know what I am missing but I installed the jar file under maven/lib directory where other jar file exist but I am still getting the same error. by the way, i reverted back to maven 2.0.6 The maven-ejb-plugin needs to end up in your .m2 repository. For me, it's: /Users/kevan/.m2/repository/org/apache/maven/plugins/maven-ejb-plugin/ 2.1/maven-ejb-plugin-2.1.jar --kevan thx kevan; obviously I am still missing something else cause I am still getting the same error. here is what i did 0) I installed maven.2.0.7 Maven version: 2.0.7 Java version: 1.5.0_13 OS name: mac os x version: 10.5.2 arch: i386 1) I checked out the source. svn co 2) I put maven-ejb-plugin.jar under /Users/seleshmaster/.m2/repository/org/apache/maven/plugins/maven-ejb-plugin Note: for some reason, there was no directory name 2.1, so I just created it manually and put the .jar file there too 3) and from /Users/seleshmaster/workspace/trunk directory i run mvn install 4) and I am getting this error ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-ejb-plugin' does not exist or no valid version could be found thx for the help. -- View this message in context: http://www.nabble.com/DayTrader-build-error-tp15973242s134p16001762.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- ~Jason Warner -- View this message in context: http://www.nabble.com/DayTrader-build-error-tp15973242s134p16015060.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Commented: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578046#action_12578046 ] Joseph Leong commented on GERONIMO-3893: Silly me.. implemented.. Patch 2.. Thanks Jarek -Joseph Leong When installing plugins, exception thrown when no plugins selected -- Key: GERONIMO-3893 URL: https://issues.apache.org/jira/browse/GERONIMO-3893 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Fix For: 2.1.1 Attachments: GERONIMO-3893-2.patch, GERONIMO-3893.patch In the administration console-plugin installer. When trying to install plugins, If no plugins are selected (check box), an exception is thrown and a 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3893: --- Attachment: GERONIMO-3893-2.patch When installing plugins, exception thrown when no plugins selected -- Key: GERONIMO-3893 URL: https://issues.apache.org/jira/browse/GERONIMO-3893 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Fix For: 2.1.1 Attachments: GERONIMO-3893-2.patch, GERONIMO-3893.patch In the administration console-plugin installer. When trying to install plugins, If no plugins are selected (check box), an exception is thrown and a 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] release specs-parent 1.5 and geronimo-servlet_2.5_spec-1.2
Hi, (dependent on genesis 1.4 take 5 release vote passing). A user recently reported a bug in the servlet spec jar, see https:// issues.apache.org/jira/browse/GERONIMO-3896 Tomcat has accepted the proposed fix in their trunk. While working to upgrade to genesis-1.4 and thus release a new specs parent I realized the current layout was confusing during release. The changes in this release: update to use genesis-1.4 (thus this vote is dependent on the current genesis 1.4 vote passing) GERONIMO-3908 reorganize the specs layout so the parent pom is in a different directory, specs-parent, so tagging does not copy the entire set of specs that happen to be in trunk at that moment. GERONIMO-3896 make HEAD forward/include requests work. Also I am moving the spec release numbering back to what I consider more sensible, namely x.y rather than x.y.z where the need for z or not is entirely up to the releaser. specs-parent: Staging repo: http://people.apache.org/~djencks/staging-repo/specs/ Staging site: http://people.apache.org/~djencks/staging-site/specs/1.5/ geronimo-servlet_2.5_spec-1.2: Staging repo: http://people.apache.org/~djencks/staging-repo/specs/servlet-2.5/ Staging site: http://people.apache.org/~djencks/staging-site/specs/servlet-2.5/1.2/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
Re: [VOTE] release specs-parent 1.5 and geronimo-servlet_2.5_spec-1.2
+1 david jencks On Mar 12, 2008, at 4:03 PM, David Jencks wrote: Hi, (dependent on genesis 1.4 take 5 release vote passing). A user recently reported a bug in the servlet spec jar, see https:// issues.apache.org/jira/browse/GERONIMO-3896 Tomcat has accepted the proposed fix in their trunk. While working to upgrade to genesis-1.4 and thus release a new specs parent I realized the current layout was confusing during release. The changes in this release: update to use genesis-1.4 (thus this vote is dependent on the current genesis 1.4 vote passing) GERONIMO-3908 reorganize the specs layout so the parent pom is in a different directory, specs-parent, so tagging does not copy the entire set of specs that happen to be in trunk at that moment. GERONIMO-3896 make HEAD forward/include requests work. Also I am moving the spec release numbering back to what I consider more sensible, namely x.y rather than x.y.z where the need for z or not is entirely up to the releaser. specs-parent: Staging repo: http://people.apache.org/~djencks/staging-repo/specs/ Staging site: http://people.apache.org/~djencks/staging-site/specs/1.5/ geronimo-servlet_2.5_spec-1.2: Staging repo: http://people.apache.org/~djencks/staging-repo/specs/servlet-2.5/ Staging site: http://people.apache.org/~djencks/staging-site/specs/servlet-2.5/1.2/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
[jira] Reopened: (GERONIMODEVTOOLS-294) Delete existing EMF plug-ins
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell reopened GERONIMODEVTOOLS-294: Reopening since jaxbmodels are not included in the assemblies and updatesite causing other problems Delete existing EMF plug-ins Key: GERONIMODEVTOOLS-294 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-294 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Fix For: 2.1.0 After the initial port to JAXB, the following EMF plug-ins/modules are now redundant and need to be deleted. 1) \plugins\org.apache.geronimo.v11.deployment.model 2) \plugins\org.apache.geronimo.v11.deployment.model.edit 3) \emf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-260) Branding for 2.1.0 WTP server adapter
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell resolved GERONIMODEVTOOLS-260. Resolution: Fixed Resolved again with second fix to GERONIMODEVTOOLS-294 with revision 636573 Branding for 2.1.0 WTP server adapter - Key: GERONIMODEVTOOLS-260 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-260 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-294) Delete existing EMF plug-ins
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell resolved GERONIMODEVTOOLS-294. Resolution: Fixed Resolved with revision 636573. Delete existing EMF plug-ins Key: GERONIMODEVTOOLS-294 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-294 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Fix For: 2.1.0 After the initial port to JAXB, the following EMF plug-ins/modules are now redundant and need to be deleted. 1) \plugins\org.apache.geronimo.v11.deployment.model 2) \plugins\org.apache.geronimo.v11.deployment.model.edit 3) \emf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[PROPOSAL] Indent 2 spaces in xml and vm files to match more common usage, especially maven.
IIUC we have a coding standard of a 4 space indent for all files (documented at http://cwiki.apache.org/GMOxDEV/coding- standards.html). This can make working with maven difficult because its files and xml output generatiion use 2 space indent for xml and .vm files. I think we could make life a lot easier when using maven tooling to use a 2 space indent for xml and .vm and possibly other files. At least with IDEA its easy to have different indents for java and xml files. Comments? thanks david jencks
[jira] Commented: (GERONIMO-3871) maven archetypes for modules and assemblies
[ https://issues.apache.org/jira/browse/GERONIMO-3871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578082#action_12578082 ] David Jencks commented on GERONIMO-3871: rev 636578 added a couple of pom.sample.xml files that maven won't process since the normal maven processing strips out all the useful comments I put in the original poms. maven archetypes for modules and assemblies --- Key: GERONIMO-3871 URL: https://issues.apache.org/jira/browse/GERONIMO-3871 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1, 2.1.1, 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1.1, 2.2 Attachments: liferay-sample-project.jar Need a couple maven archetypes to make it easier to set up projects to build plugins and assemblies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3871) maven archetypes for modules and assemblies
[ https://issues.apache.org/jira/browse/GERONIMO-3871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3871. -- Resolution: Fixed Ported to 2.1 branch in rev 636584. these could undoubtedly use more cleanup but they do exist and more or less work. maven archetypes for modules and assemblies --- Key: GERONIMO-3871 URL: https://issues.apache.org/jira/browse/GERONIMO-3871 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1, 2.1.1, 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1.1, 2.2 Attachments: liferay-sample-project.jar Need a couple maven archetypes to make it easier to set up projects to build plugins and assemblies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3896) Error processing HEAD method by default HttpServlet#doHead()
[
https://issues.apache.org/jira/browse/GERONIMO-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578090#action_12578090
]
David Jencks commented on GERONIMO-3896:
Patch committed in rev 636511. Spec release vote pending, then we can get it
into the actual geronimo servers.
Error processing HEAD method by default HttpServlet#doHead()
Key: GERONIMO-3896
URL: https://issues.apache.org/jira/browse/GERONIMO-3896
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: specs
Affects Versions: 2.0.2
Environment: Geronimo 2.0.2/Tomcat, Geronimo 2.1?
Reporter: Andrey Utkin
Assignee: David Jencks
Priority: Blocker
Fix For: 2.1.1, 2.2
Attachments: GERONIMO-3896.patch,
geronimo-servlet_2.5_spec-1.1.1-fake.jar
I have Servlet with use RequestDispatcher.include()/forward() to JSP.
My Servlet extends HttpServlet. I don`t overwrite doHead() method.
While processing HEAD method following exception throws:
{code}
09:18:57,647 ERROR [[SimpleDispatchServlet]] Servlet.service() for servlet
SimpleDispatchServlet threw exception
javax.servlet.ServletException: Original SevletResponse or wrapped original
ServletResponse not passed to
RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
at
org.apache.catalina.core.ApplicationDispatcher.checkSameObjects(ApplicationDispatcher.java:985)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:493)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
at
com.km.webapp.test.simple.SimpleDispatchServlet.doGet(SimpleDispatchServlet.java:26)
at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:274)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:353)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
{code}
Exploring code I found that Tomcat`s implementation of RequestDispatcher
expects that passed Response/Request objects is original objects or is
wrapped by ServletRequestWrapper/ServletResponseWrapper. But
geronimo-servlet_2.5_spec/HttpServlet.java#doHead() use NoBodyResponse class
which is not instance of ServletResponseWrapper. So, exception thrown.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [PROPOSAL] Indent 2 spaces in xml and vm files to match more common usage, especially maven.
Do we know the reasoning for setting it to 4 spaces in the first place? Was it just arbitrary based on what we were doing for other files? On Wed, Mar 12, 2008 at 7:34 PM, David Jencks [EMAIL PROTECTED] wrote: IIUC we have a coding standard of a 4 space indent for all files (documented at http://cwiki.apache.org/GMOxDEV/coding- standards.html). This can make working with maven difficult because its files and xml output generatiion use 2 space indent for xml and .vm files. I think we could make life a lot easier when using maven tooling to use a 2 space indent for xml and .vm and possibly other files. At least with IDEA its easy to have different indents for java and xml files. Comments? thanks david jencks -- ~Jason Warner
[jira] Commented: (GERONIMO-3898) Provide handy way to configure log4j for a particular app
[ https://issues.apache.org/jira/browse/GERONIMO-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578092#action_12578092 ] David Jencks commented on GERONIMO-3898: ported to branches/2.1 in rev 636588. I would prefer to know this works before releasing it :-) Provide handy way to configure log4j for a particular app - Key: GERONIMO-3898 URL: https://issues.apache.org/jira/browse/GERONIMO-3898 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Logging Affects Versions: 2.1.1, 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1.1, 2.2 It may or may not be obvious to people how to configure log4j for their app without breaking geronimo's log setup. We can easily provide a gbean that reads a property file, removes stuff that applies to global logging, and feeds the rest to log4j. Then people can supply a properties file for their apps log4j configuration, either in the classpath or var/somewhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [PROPOSAL] Indent 2 spaces in xml and vm files to match more common usage, especially maven.
On Mar 12, 2008, at 5:23 PM, Jason Warner wrote: Do we know the reasoning for setting it to 4 spaces in the first place? Was it just arbitrary based on what we were doing for other files? that's my (faint) recollection. #mutters hobgoblins, small minds, etc etc thanks david jencks On Wed, Mar 12, 2008 at 7:34 PM, David Jencks [EMAIL PROTECTED] wrote: IIUC we have a coding standard of a 4 space indent for all files (documented at http://cwiki.apache.org/GMOxDEV/coding- standards.html). This can make working with maven difficult because its files and xml output generatiion use 2 space indent for xml and .vm files. I think we could make life a lot easier when using maven tooling to use a 2 space indent for xml and .vm and possibly other files. At least with IDEA its easy to have different indents for java and xml files. Comments? thanks david jencks -- ~Jason Warner
Re: [PROPOSAL] Indent 2 spaces in xml and vm files to match more common usage, especially maven.
I'm sitting here trying to think of some reason to not do this, but I can't come up with one. I'm all for it unless someone can come up with a reason not to. +1 On Wed, Mar 12, 2008 at 8:32 PM, David Jencks [EMAIL PROTECTED] wrote: On Mar 12, 2008, at 5:23 PM, Jason Warner wrote: Do we know the reasoning for setting it to 4 spaces in the first place? Was it just arbitrary based on what we were doing for other files? that's my (faint) recollection. #mutters hobgoblins, small minds, etc etc thanks david jencks On Wed, Mar 12, 2008 at 7:34 PM, David Jencks [EMAIL PROTECTED] wrote: IIUC we have a coding standard of a 4 space indent for all files (documented at http://cwiki.apache.org/GMOxDEV/coding- standards.html). This can make working with maven difficult because its files and xml output generatiion use 2 space indent for xml and .vm files. I think we could make life a lot easier when using maven tooling to use a 2 space indent for xml and .vm and possibly other files. At least with IDEA its easy to have different indents for java and xml files. Comments? thanks david jencks -- ~Jason Warner -- ~Jason Warner
[jira] Resolved: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3893. --- Resolution: Fixed Fix Version/s: 2.2 Assignee: Jarek Gawor (was: Joseph Leong) Committed the patch to trunk (revision 63660) and branches/2.1 (revision 636606). Thanks a lot! When installing plugins, exception thrown when no plugins selected -- Key: GERONIMO-3893 URL: https://issues.apache.org/jira/browse/GERONIMO-3893 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1 Reporter: Joseph Leong Assignee: Jarek Gawor Priority: Minor Fix For: 2.1.1, 2.2 Attachments: GERONIMO-3893-2.patch, GERONIMO-3893.patch In the administration console-plugin installer. When trying to install plugins, If no plugins are selected (check box), an exception is thrown and a 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3881) geronimo/stop-server dumps ConnectException: Connection refused: connect when server's stopped yet Shutdown request has been issued
[ https://issues.apache.org/jira/browse/GERONIMO-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3881: - Assignee: Jarek Gawor geronimo/stop-server dumps ConnectException: Connection refused: connect when server's stopped yet Shutdown request has been issued --- Key: GERONIMO-3881 URL: https://issues.apache.org/jira/browse/GERONIMO-3881 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Jacek Laskowski Assignee: Jarek Gawor The stack trace should not be printed out, but a error message. The Shutdown request has been issued message's a little misleading. [EMAIL PROTECTED] /cygdrive/c/geronimo-jetty6-javaee5-2.1 $ ./bin/gsh Apache Geronimo (2.1) Type 'help' for more information. [EMAIL PROTECTED]:/ geronimo/stop-server Stopping Geronimo server: localhost:1099 Username: systen Password: 23:22:20,156 WARN [ServerProxy] Unable to shutdown the server java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nes ted exception is: java.net.ConnectException: Connection refused: connect] at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:317) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.commands.ServerProxy.getConnection(ServerProxy.java:102) at org.apache.geronimo.commands.ServerProxy.invoke(ServerProxy.java:219) at org.apache.geronimo.commands.ServerProxy.invoke(ServerProxy.java:230) at org.apache.geronimo.commands.ServerProxy.invoke(ServerProxy.java:234) at org.apache.geronimo.commands.ServerProxy.shutdown(ServerProxy.java:202) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.groovy.reflection.CachedMethod.invokeByReflection(CachedMethod.java:107) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:127) at org.codehaus.groovy.runtime.metaclass.StdMetaMethod.invoke(StdMetaMethod.java:18) at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:538) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:749) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:589) at org.codehaus.groovy.runtime.Invoker.invokePojoMethod(Invoker.java:87) at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:75) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:74) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:158) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod0(ScriptBytecodeAdapter.java:201) at org.apache.geronimo.commands.StopServerCommand.doExecute(StopServerCommand.groovy:72) at org.apache.geronimo.gshell.command.CommandSupport.execute(CommandSupport.java:101) at org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute(PlexusCommandWrapper.java:71) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:209) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:96) at org.apache.geronimo.gshell.parser.ASTExpression.jjtAccept(ASTExpression.java:17) at org.apache.geronimo.gshell.parser.SimpleNode.childrenAccept(SimpleNode.java:57) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:79) at org.apache.geronimo.gshell.parser.ASTCommandLine.jjtAccept(ASTCommandLine.java:17) at org.apache.geronimo.gshell.DefaultCommandLineBuilder$1.execute(DefaultCommandLineBuilder.java:95) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:86) at org.apache.geronimo.gshell.DefaultShell.execute(DefaultShell.java:123) at org.apache.geronimo.gshell.DefaultShell$1.execute(DefaultShell.java:155) at org.apache.geronimo.gshell.console.Console.work(Console.java:187) at
Re: DayTrader build error
Thank you guys for your help, I finally got it to work. I pretty much removed everything and re-installed everything again and that seems to fix the problem. Joe Bohn wrote: seleshmaster wrote: 2) I put maven-ejb-plugin.jar under /Users/seleshmaster/.m2/repository/org/apache/maven/plugins/maven-ejb-plugin Note: for some reason, there was no directory name 2.1, so I just created it manually and put the .jar file there too I'm not sure why this isn't being pulled for you as part of the build for you ... but if you must manually place the jar in your local repo make sure that the name includes the version ... ie. maven-ejb-plugin-2.1.jar and not just maven-ejb-plugin.jar. You would also have to create the version directory path as you noted. One other thing to try before that is to rm -rf /Users/seleshmaster/.m2/repository/org/apache/maven/plugins/maven-ejb-plugin prior attempting the build. Perhaps something has become corrupted in the maven-ejb-plugin pom that is causing maven from not being able to download this. Hope that helps, Joe -- View this message in context: http://www.nabble.com/DayTrader-build-error-tp15973242s134p16020140.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMO-3881) geronimo/stop-server dumps ConnectException: Connection refused: connect when server's stopped yet Shutdown request has been issued
[ https://issues.apache.org/jira/browse/GERONIMO-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-3881: -- Affects Version/s: 2.2 2.1.1 2.1 geronimo/stop-server dumps ConnectException: Connection refused: connect when server's stopped yet Shutdown request has been issued --- Key: GERONIMO-3881 URL: https://issues.apache.org/jira/browse/GERONIMO-3881 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jacek Laskowski Assignee: Jarek Gawor The stack trace should not be printed out, but a error message. The Shutdown request has been issued message's a little misleading. [EMAIL PROTECTED] /cygdrive/c/geronimo-jetty6-javaee5-2.1 $ ./bin/gsh Apache Geronimo (2.1) Type 'help' for more information. [EMAIL PROTECTED]:/ geronimo/stop-server Stopping Geronimo server: localhost:1099 Username: systen Password: 23:22:20,156 WARN [ServerProxy] Unable to shutdown the server java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nes ted exception is: java.net.ConnectException: Connection refused: connect] at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:317) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.commands.ServerProxy.getConnection(ServerProxy.java:102) at org.apache.geronimo.commands.ServerProxy.invoke(ServerProxy.java:219) at org.apache.geronimo.commands.ServerProxy.invoke(ServerProxy.java:230) at org.apache.geronimo.commands.ServerProxy.invoke(ServerProxy.java:234) at org.apache.geronimo.commands.ServerProxy.shutdown(ServerProxy.java:202) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.groovy.reflection.CachedMethod.invokeByReflection(CachedMethod.java:107) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:127) at org.codehaus.groovy.runtime.metaclass.StdMetaMethod.invoke(StdMetaMethod.java:18) at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:538) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:749) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:589) at org.codehaus.groovy.runtime.Invoker.invokePojoMethod(Invoker.java:87) at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:75) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:74) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:158) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod0(ScriptBytecodeAdapter.java:201) at org.apache.geronimo.commands.StopServerCommand.doExecute(StopServerCommand.groovy:72) at org.apache.geronimo.gshell.command.CommandSupport.execute(CommandSupport.java:101) at org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute(PlexusCommandWrapper.java:71) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:209) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:96) at org.apache.geronimo.gshell.parser.ASTExpression.jjtAccept(ASTExpression.java:17) at org.apache.geronimo.gshell.parser.SimpleNode.childrenAccept(SimpleNode.java:57) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:79) at org.apache.geronimo.gshell.parser.ASTCommandLine.jjtAccept(ASTCommandLine.java:17) at org.apache.geronimo.gshell.DefaultCommandLineBuilder$1.execute(DefaultCommandLineBuilder.java:95) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:86) at org.apache.geronimo.gshell.DefaultShell.execute(DefaultShell.java:123) at org.apache.geronimo.gshell.DefaultShell$1.execute(DefaultShell.java:155)
[jira] Resolved: (GERONIMO-3881) geronimo/stop-server dumps ConnectException: Connection refused: connect when server's stopped yet Shutdown request has been issued
[ https://issues.apache.org/jira/browse/GERONIMO-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3881. --- Resolution: Fixed Fix Version/s: 2.2 2.1.1 Committed some updates to trunk (revision 636611) and branches/2.1 (revision 636614) that should make the stop-server command work a little better. geronimo/stop-server dumps ConnectException: Connection refused: connect when server's stopped yet Shutdown request has been issued --- Key: GERONIMO-3881 URL: https://issues.apache.org/jira/browse/GERONIMO-3881 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jacek Laskowski Assignee: Jarek Gawor Fix For: 2.1.1, 2.2 The stack trace should not be printed out, but a error message. The Shutdown request has been issued message's a little misleading. [EMAIL PROTECTED] /cygdrive/c/geronimo-jetty6-javaee5-2.1 $ ./bin/gsh Apache Geronimo (2.1) Type 'help' for more information. [EMAIL PROTECTED]:/ geronimo/stop-server Stopping Geronimo server: localhost:1099 Username: systen Password: 23:22:20,156 WARN [ServerProxy] Unable to shutdown the server java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nes ted exception is: java.net.ConnectException: Connection refused: connect] at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:317) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.commands.ServerProxy.getConnection(ServerProxy.java:102) at org.apache.geronimo.commands.ServerProxy.invoke(ServerProxy.java:219) at org.apache.geronimo.commands.ServerProxy.invoke(ServerProxy.java:230) at org.apache.geronimo.commands.ServerProxy.invoke(ServerProxy.java:234) at org.apache.geronimo.commands.ServerProxy.shutdown(ServerProxy.java:202) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.groovy.reflection.CachedMethod.invokeByReflection(CachedMethod.java:107) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:127) at org.codehaus.groovy.runtime.metaclass.StdMetaMethod.invoke(StdMetaMethod.java:18) at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:538) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:749) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:589) at org.codehaus.groovy.runtime.Invoker.invokePojoMethod(Invoker.java:87) at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:75) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:74) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:158) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod0(ScriptBytecodeAdapter.java:201) at org.apache.geronimo.commands.StopServerCommand.doExecute(StopServerCommand.groovy:72) at org.apache.geronimo.gshell.command.CommandSupport.execute(CommandSupport.java:101) at org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute(PlexusCommandWrapper.java:71) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:209) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:96) at org.apache.geronimo.gshell.parser.ASTExpression.jjtAccept(ASTExpression.java:17) at org.apache.geronimo.gshell.parser.SimpleNode.childrenAccept(SimpleNode.java:57) at org.apache.geronimo.gshell.ExecutingVisitor.visit(ExecutingVisitor.java:79) at org.apache.geronimo.gshell.parser.ASTCommandLine.jjtAccept(ASTCommandLine.java:17) at org.apache.geronimo.gshell.DefaultCommandLineBuilder$1.execute(DefaultCommandLineBuilder.java:95) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:86)
[BUILD] trunk: Failed for Revision: 636594
Geronimo Revision: 636594 built with tests included See the full build-2100.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080312/build-2100.log Download the binaries from http://geronimo.apache.org/maven/server/binaries/trunk/20080312 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 34 minutes 18 seconds [INFO] Finished at: Wed Mar 12 21:48:55 EDT 2008 [INFO] Final Memory: 308M/1010M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://geronimo.apache.org/maven/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080312/logs-2100-tomcat/test.log Assembly: jetty = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080312/logs-2100-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 73.178 sec FAILURE! Samples: trunk = Log: http://geronimo.apache.org/maven/server/binaries/trunk/20080312/samples-2100.log Build status: OK
[jira] Commented: (GERONIMO-3833) Hard-coded gbean names and versions in monitoring code
[ https://issues.apache.org/jira/browse/GERONIMO-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578142#action_12578142 ] Viet Hung Nguyen commented on GERONIMO-3833: Committed revision 636624 to 2.1 branch. Hard-coded gbean names and versions in monitoring code -- Key: GERONIMO-3833 URL: https://issues.apache.org/jira/browse/GERONIMO-3833 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jarek Gawor Assignee: Viet Hung Nguyen Fix For: 2.1.1, 2.2 The monitoring code has hard-coded values in Java code and sql file: 1) The ./plugins/monitoring/mconsole-war/src/main/java/org/apache/geronimo/monitoring/console/MRCConnector.java contains the following constant: private static final String PATH = geronimo:ServiceModule=org.apache.geronimo.plugins.monitoring/agent-car-jmx/2.1-SNAPSHOT/car,J2EEServer=geronimo, name=MasterRemoteControlJMX,j2eeType=GBean; 2) The ./plugins/monitoring/mconsole-ear/src/main/resources/MonitoringClientDB.sql contains a bunch of the following values: 'geronimo:J2EEServer=geronimo,ServiceModule=org.apache.geronimo.configs/tomcat6/2.1/car,j2eeType=GBean,name=TomcatWebConnector' I'm not sure how these are used but in general these type of hardcoded values should be avoided. It's really hard to maintain and keep track of. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3911) Get version 1.1 migration sample apps checked in from wiki and cleaned up
[ https://issues.apache.org/jira/browse/GERONIMO-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578153#action_12578153 ] David Jencks commented on GERONIMO-3911: if the projects are built with maven and derive from genesis-1.4 then the maven-remote-resources-plugin will take care of the basic legal files for you Get version 1.1 migration sample apps checked in from wiki and cleaned up -- Key: GERONIMO-3911 URL: https://issues.apache.org/jira/browse/GERONIMO-3911 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Affects Versions: 1.1.x Reporter: Erik B. Craig Assignee: Erik B. Craig LICENCE.txt, NOTICE.txt, and ASF license headers need to be added, as well as all line endings converted to unix format and tabs converted to spaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
