Re: [VOTE] release specs-parent 1.5 and geronimo-servlet_2.5_spec-1.2

[Vamsavardhana Reddy]

+1

++Vamsi

On Thu, Mar 13, 2008 at 4:33 AM, David Jencks <[EMAIL PROTECTED]>
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] Commented: (GERONIMODEVTOOLS-294) Delete existing EMF plug-ins

[Shiva Kumar H R (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578160#action_12578160
 ] 

Shiva Kumar H R commented on GERONIMODEVTOOLS-294:
--

Oh! sorry didn't notice. Thanks for fixing.

> 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: (GERONIMO-3911) Get version 1.1 migration sample apps checked in from wiki and cleaned up

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

[jira] Commented: (GERONIMO-3833) Hard-coded gbean names and versions in monitoring code

[Viet Hung Nguyen (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

[BUILD] trunk: Failed for Revision: 636594

[gawor]

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] Resolved: (GERONIMO-3881) geronimo/stop-server dumps ConnectException: Connection refused: connect when server's stopped yet Shutdown request has been issued

[Jarek Gawor (JIRA)]

 [ 
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 
> o

[jira] Updated: (GERONIMO-3881) geronimo/stop-server dumps ConnectException: Connection refused: connect when server's stopped yet Shutdown request has been issued

[Jarek Gawor (JIRA)]

 [ 
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)
>   

Re: DayTrader build error

[seleshmaster]

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] Assigned: (GERONIMO-3881) geronimo/stop-server dumps ConnectException: Connection refused: connect when server's stopped yet Shutdown request has been issued

[Jarek Gawor (JIRA)]

 [ 
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)
>

[jira] Resolved: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected

[Jarek Gawor (JIRA)]

 [ 
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.

Re: [PROPOSAL] Indent 2 spaces in xml and vm files to match more common usage, especially maven.

[Jason Warner]

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

Re: [PROPOSAL] Indent 2 spaces in xml and vm files to match more common usage, especially maven.

[David Jencks]

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

[jira] Commented: (GERONIMO-3898) Provide handy way to configure log4j for a particular app

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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/.

-- 
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.

[Jason Warner]

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-3896) Error processing HEAD method by default HttpServlet#doHead()

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

[jira] Closed: (GERONIMO-3871) maven archetypes for modules and assemblies

[David Jencks (JIRA)]

 [ 
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-3871) maven archetypes for modules and assemblies

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

[PROPOSAL] Indent 2 spaces in xml and vm files to match more common usage, especially maven.

[David Jencks]

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] Resolved: (GERONIMODEVTOOLS-294) Delete existing EMF plug-ins

[Tim McConnell (JIRA)]

 [ 
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.

[jira] Resolved: (GERONIMODEVTOOLS-260) Branding for 2.1.0 WTP server adapter

[Tim McConnell (JIRA)]

 [ 
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] Reopened: (GERONIMODEVTOOLS-294) Delete existing EMF plug-ins

[Tim McConnell (JIRA)]

 [ 
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.

Re: [VOTE] release specs-parent 1.5 and geronimo-servlet_2.5_spec-1.2

[David Jencks]

+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

[VOTE] release specs-parent 1.5 and geronimo-servlet_2.5_spec-1.2

[David Jencks]

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: DayTrader build error

[seleshmaster]

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:
>> > 
>> >
>> >> 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

[Joseph Leong (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Joseph Leong (JIRA)]

 [ 
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.

Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[Alex Karasulu]

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
> or

Re: [VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[Alex Karasulu]

+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/samples
>
> +1
>
> --
> Thanks, Dan Becker
>

[jira] Created: (GERONIMO-3912) Get version 2.0 migration sample apps checked in from wiki and cleaned up

[Erik B. Craig (JIRA)]

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.

[jira] Created: (GERONIMO-3911) Get version 1.1 migration sample apps checked in from wiki and cleaned up

[Erik B. Craig (JIRA)]

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] Commented: (GERONIMO-3781) Plugin Installer, CRSF issue when attempting to install a new plugin

[Joseph Leong (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3910) Rename classes, remove IBM references

[Erik B. Craig (JIRA)]

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] Updated: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected

[Joseph Leong (JIRA)]

 [ 
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-3909) Make NamingBuilders/NamingBuilderCollection ordered

[Jarek Gawor (JIRA)]

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] 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.

[David Jencks (JIRA)]

 [ 
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-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.

[David Jencks (JIRA)]

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] Updated: (GERONIMO-3896) Error processing HEAD method by default HttpServlet#doHead()

[David Jencks (JIRA)]

 [ 
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.

Re: [VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[Dan Becker]

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

Re: [VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[Hernan Cunico]

+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: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[Hernan Cunico]

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: [DISCUSS] Geronimo 2.1.1 release

[Donald Woods]

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

[jira] Updated: (GERONIMO-3814) NPE in GBeanOverride

[Donald Woods (JIRA)]

 [ 
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.

[jira] Assigned: (GERONIMO-3814) NPE in GBeanOverride

[Donald Woods (JIRA)]

 [ 
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-3819) Update JMS Resources Portlet

[Donald Woods (JIRA)]

 [ 
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.

Re: [VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[Vamsavardhana Reddy]

+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/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
>

[jira] Updated: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar

[Donald Woods (JIRA)]

 [ 
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.

[jira] Updated: (GERONIMO-3811) EjbServer portlet

[Donald Woods (JIRA)]

 [ 
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-3906) start-server uses hard-coded credentials that cannot be overridden

[Donald Woods (JIRA)]

 [ 
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-3887) After installing with wrong configuration unable to proceed with any new plugin installs

[Donald Woods (JIRA)]

 [ 
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-3876) Allow configuring JMX over SSL

[Donald Woods (JIRA)]

 [ 
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] Commented: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected

[Jarek Gawor (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3893) When installing plugins, exception thrown when no plugins selected

[Joseph Leong (JIRA)]

 [ 
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] Updated: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected

[Joseph Leong (JIRA)]

 [ 
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] Commented: (GERONIMO-3781) Plugin Installer, CRSF issue when attempting to install a new plugin

[Donald Woods (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[David Jencks]

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 
(Simple

[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.

[Donald Woods (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
>  
> 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(JspMethodEx

Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[Vamsavardhana Reddy]

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

[jira] Commented: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected

[Joseph Leong (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Vamsavardhana Reddy]

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
org.apach

Re: module builders/deployers in plugins

[David Jencks]

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.




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

[Vamsavardhana Reddy]

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/
>
> 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

[David Jencks]

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: module builders/deployers in plugins

[Jarek Gawor]

>  >>  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: Gshell fails to launch on trunk

[Jason Warner]

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: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[Vamsavardhana Reddy]

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 Woods]

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: link to eclipse settings on coding standards page?

[Jarek Gawor]

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
>

[jira] Commented: (GERONIMO-3833) Hard-coded gbean names and versions in monitoring code

[Viet Hung Nguyen (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: [DISCUSS] Geronimo 2.1 samples

[Erik B. Craig]

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

Re: [DISCUSS] Geronimo 2.1 samples

[Jarek Gawor]

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

[Joe Bohn]

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.1 release

[David Jencks]

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).  I"m 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 samples

[David Jencks]

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

[Joe Bohn]

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.1 release

[Joe Bohn]

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

[Hernan Cunico]

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

[Joe Bohn]

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 plugin for Apache Directory 1.5.1 version 1.0

[Hernan Cunico]

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 samples

[Joe Bohn]

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: LDAP server in 2.1.1

[Dan Becker]

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

Re: DayTrader build error

[Joe Bohn]

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

[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.

[Ralf Baumhof (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterC

Re: DayTrader build error

[Jason Warner]

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:
> > 
> >
> >> 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

[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.

[Ralf Baumhof (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
 
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 
org.apache.geronimo.tomcat.GeronimoStandardC

Stoppage of message processing when instanceLimit < maxSessions

[Manu George]

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

Re: DayTrader build error

[seleshmaster]

Kevan Miller wrote:
> 
> 
> On Mar 11, 2008, at 6:52 AM, seleshmaster wrote:
> 
> 
>> 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.

[jira] Created: (GERONIMO-3907) Persistence Exception is not visible/lost for client.

[Ralf Baumhof (JIRA)]

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
 
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 javax.faces.webapp.FacesServlet.service(FacesServlet.java:148)

[DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[Vamsavardhana Reddy]

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: [VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[David Jencks]

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

Re: [VOTE] genesis 1.4 take 5

[David Jencks]

+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

[VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[David Jencks]

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

[jira] Created: (GERONIMODEVTOOLS-295) Delete redundant dependencies from runtime plug-ins - Make GEP thinner!

[Shiva Kumar H R (JIRA)]

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.