[jira] Commented: (GERONIMO-677) Repeated login (after session invalidation) with different credentials results in incorrect role set. LOGIN MODULES ARE BEING REUSED
[ http://issues.apache.org/jira/browse/GERONIMO-677?page=comments#action_12317030 ] David Jencks commented on GERONIMO-677: --- Login modules were indeed being reused. I think it is fixed in M4: Sending modules/security/src/java/org/apache/geronimo/security/jaas/JaasLoginModuleConfiguration.java Sending modules/security/src/java/org/apache/geronimo/security/jaas/JaasLoginService.java Sending modules/security/src/java/org/apache/geronimo/security/jaas/JaasSecurityContext.java Sending modules/security/src/test/org/apache/geronimo/security/jaas/MultipleLoginDomainTest.java Transmitting file data Committed revision 225726. Repeated login (after session invalidation) with different credentials results in incorrect role set. LOGIN MODULES ARE BEING REUSED Key: GERONIMO-677 URL: http://issues.apache.org/jira/browse/GERONIMO-677 Project: Geronimo Type: Bug Components: security Versions: 1.0-M4 Reporter: Ivan Dubrov Assignee: David Jencks Priority: Blocker Fix For: 1.0-M4, 1.0-M5 Attachments: db_create.sql, geronimo-application.xml, my-changes.patch, test.zip Consider we have two users, user with role user and manager with role manager and two secured areas /user/* and /manager/*, so only user's can access pages with URL /user/* and only manager's can access pages with URL /manager/*. If we log in as user, we can access only /user/* pages, 403 Forbidden if we try to access /manager/* pages. It is OK. Now, if we clean the session (request.getSession().invalidate()), we will be logged out, so we cannot access nor /user/*, nor /manager/* pages - server redirects to the login page. It is OK. But if we login second time, as a manager, we can access both page sets - /user/* and /manager/*! It means that authenticated user owns both roles user and manager, but this is impossible combination! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
[ http://issues.apache.org/jira/browse/GERONIMO-693?page=comments#action_12317031 ] Bruce Snyder commented on GERONIMO-693: --- I just checked in the beginnings of a startup shell script in the scripts directory. I need to figure out how to copy it into the assembly/target/geronimo-1.0-SNAPSHOT/bin/ directory during the build process. Need startup scripts in bin directory - Key: GERONIMO-693 URL: http://issues.apache.org/jira/browse/GERONIMO-693 Project: Geronimo Type: New Feature Components: usability Environment: Windows, Linux, Mac OS X Reporter: Erin Mulder Assignee: John Sisson Priority: Minor It would be nice to have obvious startup.sh and startup.bat scripts in the bin directory so that the user doesn't need to look at the README file to figure out how to start the server. (java -jar bin/server.jar isn't hard -- it's just not quite as brainless as a script called startup). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-677) Repeated login (after session invalidation) with different credentials results in incorrect role set. LOGIN MODULES ARE BEING REUSED
[ http://issues.apache.org/jira/browse/GERONIMO-677?page=comments#action_12317033 ] David Jencks commented on GERONIMO-677: --- applied to M5: Sending modules/security/src/java/org/apache/geronimo/security/jaas/JaasLoginModuleConfiguration.java Sending modules/security/src/java/org/apache/geronimo/security/jaas/JaasLoginService.java Sending modules/security/src/java/org/apache/geronimo/security/jaas/JaasSecurityContext.java Sending modules/security/src/test/org/apache/geronimo/security/jaas/MultipleLoginDomainTest.java Transmitting file data Committed revision 225728. I'd appreciate it if Ivan (at least) could verify that this issue is fixed. Thanks again for discovering it!! Repeated login (after session invalidation) with different credentials results in incorrect role set. LOGIN MODULES ARE BEING REUSED Key: GERONIMO-677 URL: http://issues.apache.org/jira/browse/GERONIMO-677 Project: Geronimo Type: Bug Components: security Versions: 1.0-M4 Reporter: Ivan Dubrov Assignee: David Jencks Priority: Blocker Fix For: 1.0-M4, 1.0-M5 Attachments: db_create.sql, geronimo-application.xml, my-changes.patch, test.zip Consider we have two users, user with role user and manager with role manager and two secured areas /user/* and /manager/*, so only user's can access pages with URL /user/* and only manager's can access pages with URL /manager/*. If we log in as user, we can access only /user/* pages, 403 Forbidden if we try to access /manager/* pages. It is OK. Now, if we clean the session (request.getSession().invalidate()), we will be logged out, so we cannot access nor /user/*, nor /manager/* pages - server redirects to the login page. It is OK. But if we login second time, as a manager, we can access both page sets - /user/* and /manager/*! It means that authenticated user owns both roles user and manager, but this is impossible combination! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-677) Repeated login (after session invalidation) with different credentials results in incorrect role set. LOGIN MODULES ARE BEING REUSED
[ http://issues.apache.org/jira/browse/GERONIMO-677?page=comments#action_12317099 ] David Jencks commented on GERONIMO-677: --- Added a simple test, refurbished MultipleLoginDomains test M4: Sending modules/security/src/test/org/apache/geronimo/security/jaas/MultipleLoginDomainTest.java Adding modules/security/src/test/org/apache/geronimo/security/jaas/NoLoginModuleReuseTest.java Transmitting file data .. Committed revision 225798. M5: Sending modules/security/src/test/org/apache/geronimo/security/jaas/MultipleLoginDomainTest.java Adding modules/security/src/test/org/apache/geronimo/security/jaas/NoLoginModuleReuseTest.java Transmitting file data .. Committed revision 225801. Repeated login (after session invalidation) with different credentials results in incorrect role set. LOGIN MODULES ARE BEING REUSED Key: GERONIMO-677 URL: http://issues.apache.org/jira/browse/GERONIMO-677 Project: Geronimo Type: Bug Components: security Versions: 1.0-M4 Reporter: Ivan Dubrov Assignee: David Jencks Priority: Blocker Fix For: 1.0-M4, 1.0-M5 Attachments: db_create.sql, geronimo-application.xml, my-changes.patch, test.zip Consider we have two users, user with role user and manager with role manager and two secured areas /user/* and /manager/*, so only user's can access pages with URL /user/* and only manager's can access pages with URL /manager/*. If we log in as user, we can access only /user/* pages, 403 Forbidden if we try to access /manager/* pages. It is OK. Now, if we clean the session (request.getSession().invalidate()), we will be logged out, so we cannot access nor /user/*, nor /manager/* pages - server redirects to the login page. It is OK. But if we login second time, as a manager, we can access both page sets - /user/* and /manager/*! It means that authenticated user owns both roles user and manager, but this is impossible combination! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo logo contest
On 7/22/05, Vikrant [EMAIL PROTECTED] wrote: i came across this page about a logo for apache geronimo. i have designed a logo for that, but just wanted to know how i can upload it onto the site. Nice work Vikrant! You've got my vote so far. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: Geronimo logo contest
Outstanding #11...really nice work. Bruce Snyder wrote: On 7/22/05, Vikrant [EMAIL PROTECTED] wrote: i came across this page about a logo for apache geronimo. i have designed a logo for that, but just wanted to know how i can upload it onto the site. Nice work Vikrant! You've got my vote so far. Bruce
[jira] Commented: (GERONIMO-827) Change CMR mapping name elements to descriptions
[ http://issues.apache.org/jira/browse/GERONIMO-827?page=comments#action_12317104 ] Jeremy Boynes commented on GERONIMO-827: EJB supports non-navigable relationships that still require management by the container. These need to be mapped somehow and naming the relationship is one way of identifying them (the ID attribute is another). If we don't support these there is a bug in OpenEJB's mapping capabilities. Here's a somewhat contrived example: relationships !-- father-child relationship -- ejb-relation ejb-relationship-role multiplicityOne/multiplicity relationship-role-source ejb-namePerson/ejb-name /relationship-role-source /ejb-relationship-role ejb-relationship-role multiplicityMany/multiplicity relationship-role-source ejb-namePerson/ejb-name /relationship-role-source /ejb-relationship-role /ejb-relation !-- mother-child relationship -- ejb-relation ejb-relationship-role multiplicityOne/multiplicity relationship-role-source ejb-namePerson/ejb-name /relationship-role-source /ejb-relationship-role ejb-relationship-role multiplicityMany/multiplicity cascade-delete/ relationship-role-source ejb-namePerson/ejb-name /relationship-role-source /ejb-relationship-role /ejb-relation /relationships Change CMR mapping name elements to descriptions Key: GERONIMO-827 URL: http://issues.apache.org/jira/browse/GERONIMO-827 Project: Geronimo Type: Improvement Components: OpenEJB Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0-M5 Change the ejb-relation-name and ejb-relationship-role-name elements in openejb-jar.xml at: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ejb-relationship-role-name To be description elements instead, since they're not actually used by the server and are for documentation purposes only. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-827) Change CMR mapping name elements to descriptions
[ http://issues.apache.org/jira/browse/GERONIMO-827?page=comments#action_12317107 ] Aaron Mulder commented on GERONIMO-827: --- I agree that your conclusion follows your premise. But I'm not sure I agree with the premise. Do you have a spec reference that indicates that entirely non-navigable relationships should be supported? Thanks, Aaron Change CMR mapping name elements to descriptions Key: GERONIMO-827 URL: http://issues.apache.org/jira/browse/GERONIMO-827 Project: Geronimo Type: Improvement Components: OpenEJB Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0-M5 Change the ejb-relation-name and ejb-relationship-role-name elements in openejb-jar.xml at: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ejb-relationship-role-name To be description elements instead, since they're not actually used by the server and are for documentation purposes only. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-827) Change CMR mapping name elements to descriptions
[ http://issues.apache.org/jira/browse/GERONIMO-827?page=comments#action_12317112 ] Jeremy Boynes commented on GERONIMO-827: Do you have one that says they don't? The definition is valid and has semantic meaning (cascade-delete); we should either comply with the definition or reject the application. The name elements are not purely documentation - there are actually description elements built into the schema for all these elements that can be used for that. The schema has a unique constraint on the relation name to ensure there are no duplicates, the purpose of which is to allow mapping tools to clearly identify them. Change CMR mapping name elements to descriptions Key: GERONIMO-827 URL: http://issues.apache.org/jira/browse/GERONIMO-827 Project: Geronimo Type: Improvement Components: OpenEJB Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0-M5 Change the ejb-relation-name and ejb-relationship-role-name elements in openejb-jar.xml at: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ejb-relationship-role-name To be description elements instead, since they're not actually used by the server and are for documentation purposes only. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JavaMail and JAF available as Open Source!
On Jul 27, 2005, at 4:21 PM, Aaron Mulder wrote: Is there a build in a Maven repo? Are we allowed to distribute it as part of Geronimo, given that it's under the CDDL? What's wrong with ours? :) We should have no problem distributing CDDL binaries. At some point, I expect we'll have no problems taking in CDDL code into our repo either to continue with... geir Thanks, Aaron On Wed, 27 Jul 2005, Noel J. Bergman wrote: FYI. Do not cross-post replies. --- Noel -Original Message- From: A mailing list for discussion of the JavaMail(tm) API [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 27, 2005 14:28 To: [EMAIL PROTECTED] Subject: JavaMail and JAF available as Open Source! As we announced at JavaOne, Sun has released its J2EE (now called Java EE) application server as an open source project on java.net. The project is called GlassFish and you can find out more at http:// glassfish.dev.java.net. GlassFish is available under the CDDL open source license. GlassFish contains JavaMail and JAF, so the source code for both is available under CDDL as well. GlassFish currently contains JAF 1.1ea and a version of JavaMail slightly newer than 1.3.3ea. Right now, JavaMail and JAF are only built as part of a GlassFish build. Eventually I hope to improve the build system so that the standalone releases of JavaMail and JAF can be built from the GlassFish source base. (Unfortunately, I have about 100 other more important things to do before I get to that.) Those of you looking for source code for debugging purposes, or with a need to improve JavaMail for your own use, should start with the GlassFish source. You'll need to be a java.net member and you'll need to accept the terms of the CDDL license, but note that CDDL is an OSI-approved Open Source license (it's the same license used by OpenSolaris, and a derivative of the Mozilla Public License) so you're free to use it in many ways that were previously restricted. If you make improvements to JavaMail or JAF, and would like give those improvements back to Sun (which you're not required to do), you'll need to sign a Sun Contributor Agreement so that we're sure you have to rights to give us what you're giving us. (Signing the SCA once allows you to contribute to any Sun open source project, including GlassFish, OpenSolaris, NetBeans, etc.) Note that improvements to the JavaMail and JAF APIs (the javax.* APIs) need to be approved by the JCP. Enjoy the latest JavaMail and JAF source, and please be patient as we transition our build and release processes to java.net. The JavaMail Team -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: JavaMail and JAF available as Open Source!
Geir Magnusson Jr. wrote: On Jul 27, 2005, at 4:21 PM, Aaron Mulder wrote: Is there a build in a Maven repo? Are we allowed to distribute it as part of Geronimo, given that it's under the CDDL? What's wrong with ours? :) There are probably bugs and we don't have the transports (but I don't know GlassFish does either). OTOH, there is something to be said for having two independent implementations of the specification so that we can highlight ambiguities etc. -- Jeremy
[jira] Resolved: (GERONIMO-813) Corba interop problem
[ http://issues.apache.org/jira/browse/GERONIMO-813?page=all ] David Blevins resolved GERONIMO-813: Resolution: Cannot Reproduce Neither Dain nor Alan was able to reproduce this. Corba interop problem - Key: GERONIMO-813 URL: http://issues.apache.org/jira/browse/GERONIMO-813 Project: Geronimo Type: Bug Components: CORBA Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Assignee: Dain Sundstrom Fix For: 1.0-M4, 1.0-M5 When using corba to communicate with another app server, sometimes we see an exception like: org.omg.CORBA.MARSHAL: java.lang.ClassCastException thrown while marshaling the reply: null vmcid: 0x0 minor code: 0 completed: Yes at org.openejb.corba.CorbaApplicationServer.getEJBObject(CorbaApplicationServer.java:72) at org.openejb.server.ServerFederation.getEJBObject(ServerFederation.java:119) at org.openejb.proxy.ReplacementStrategy$1.writeReplace(ReplacementStrategy.java:81) at org.openejb.proxy.SerializationHandler.writeReplace(SerializationHandler.java:101) at org.openejb.proxy.EJBObjectImpl.writeReplace(EJBObjectImpl.java:115) at sun.reflect.GeneratedMethodAccessor107.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamClass.java:896) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1011) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) at org.openejb.proxy.SerializationHandler.copyObj(SerializationHandler.java:113) at org.openejb.corba.util.Util.writeObject(Util.java:453) at org.openejb.corba.StandardServant._invoke(StandardServant.java:342) at com.sun.corba.se.internal.POA.GenericPOAServerSC.dispatchToServant(GenericPOAServerSC.java:517) at com.sun.corba.se.internal.POA.GenericPOAServerSC.internalDispatch(GenericPOAServerSC.java:207) at com.sun.corba.se.internal.POA.GenericPOAServerSC.dispatch(GenericPOAServerSC.java:109) at com.sun.corba.se.internal.iiop.ORB.process(ORB.java:252) at com.sun.corba.se.internal.iiop.RequestProcessor.process(RequestProcessor.java:81) at com.sun.corba.se.internal.orbutil.ThreadPool$PooledThread.run(ThreadPool.java:106) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (GERONIMO-813) Corba interop problem
[ http://issues.apache.org/jira/browse/GERONIMO-813?page=all ] David Jencks reopened GERONIMO-813: --- Please be more careful. Dain and Alan could not reproduce the problems in interop-ejb, but Dain can reproduce the problems in csiv2 as of 2 days ago. I have not heard from Alan. In any case, it appears that it is jvm dependent, working on windows and not on linux. Corba interop problem - Key: GERONIMO-813 URL: http://issues.apache.org/jira/browse/GERONIMO-813 Project: Geronimo Type: Bug Components: CORBA Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Assignee: Dain Sundstrom Fix For: 1.0-M4, 1.0-M5 When using corba to communicate with another app server, sometimes we see an exception like: org.omg.CORBA.MARSHAL: java.lang.ClassCastException thrown while marshaling the reply: null vmcid: 0x0 minor code: 0 completed: Yes at org.openejb.corba.CorbaApplicationServer.getEJBObject(CorbaApplicationServer.java:72) at org.openejb.server.ServerFederation.getEJBObject(ServerFederation.java:119) at org.openejb.proxy.ReplacementStrategy$1.writeReplace(ReplacementStrategy.java:81) at org.openejb.proxy.SerializationHandler.writeReplace(SerializationHandler.java:101) at org.openejb.proxy.EJBObjectImpl.writeReplace(EJBObjectImpl.java:115) at sun.reflect.GeneratedMethodAccessor107.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamClass.java:896) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1011) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) at org.openejb.proxy.SerializationHandler.copyObj(SerializationHandler.java:113) at org.openejb.corba.util.Util.writeObject(Util.java:453) at org.openejb.corba.StandardServant._invoke(StandardServant.java:342) at com.sun.corba.se.internal.POA.GenericPOAServerSC.dispatchToServant(GenericPOAServerSC.java:517) at com.sun.corba.se.internal.POA.GenericPOAServerSC.internalDispatch(GenericPOAServerSC.java:207) at com.sun.corba.se.internal.POA.GenericPOAServerSC.dispatch(GenericPOAServerSC.java:109) at com.sun.corba.se.internal.iiop.ORB.process(ORB.java:252) at com.sun.corba.se.internal.iiop.RequestProcessor.process(RequestProcessor.java:81) at com.sun.corba.se.internal.orbutil.ThreadPool$PooledThread.run(ThreadPool.java:106) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-828) Add ability to detect if a server is already running to maven plugin
Add ability to detect if a server is already running to maven plugin Key: GERONIMO-828 URL: http://issues.apache.org/jira/browse/GERONIMO-828 Project: Geronimo Type: Improvement Components: deployment Reporter: Dain Sundstrom Priority: Minor Fix For: 1.1 It would be nice to be able to detect if a server is already running using the maven plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-512) non-reference gbean dependencies
[ http://issues.apache.org/jira/browse/GERONIMO-512?page=all ] Dain Sundstrom reassigned GERONIMO-512: --- Assign To: (was: Dain Sundstrom) non-reference gbean dependencies Key: GERONIMO-512 URL: http://issues.apache.org/jira/browse/GERONIMO-512 Project: Geronimo Type: New Feature Components: kernel Versions: 1.0-M3 Reporter: David Jencks Currently there is no way to make gbeans start in a particular order unless they have a reference to each other. This is unsatisfactory as for instance one might open a server socket the other wants to connect to. Also, jndi refs are not reflected in the gbean dependency graph. So far the best idea seems to be to add a list of dependencies (object names or their successors) to GBeanData, and add these to the dependency manager on startup (and presumably remove them on shutdown). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-785) Web services error on startup
[ http://issues.apache.org/jira/browse/GERONIMO-785?page=all ] David Blevins closed GERONIMO-785: -- Resolution: Fixed Should be fixed in the latest cvs Web services error on startup - Key: GERONIMO-785 URL: http://issues.apache.org/jira/browse/GERONIMO-785 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M3 Environment: Windows Java 1.4.2_08 Reporter: Stefan Schmidt Assignee: David Blevins Priority: Critical Fix For: 1.0-M4, 1.0-M5 I have a strange issue with Geronimo startup (I am working on the v1_0_M4-QA, checked out 19.07.05). What I observed: 1. I started Geronimo and deployed a database connection plan and my Application (.ear) 2. I started Geronimo again and it (obviously) tried to start my apps automatically. I am getting an error (pasted below) 3. If I undeploy these apps and deploy them again the error is gone and everything runs smoothly. Paste: 22:24:00,772 INFO [GenericEJBContainer] GenericEJBContainer 'geronimo.server:EJBModule=DWBookShop- ejb.jar,J2EEApplication=DWBookShop,J2EEServer=geronimo,j2eeType=Statele ssSessionBean,name=BookShopEJB' started 22:24:00,772 DEBUG [GBeanInstanceState] GBeanInstanceState for: geronimo.server:EJBModule=DWBookShop- ejb.jar,J2EEApplication=DWBookShop,J2EEServer=geronimo,j2eeType=Statele ssSessionBean,name=BookShopEJB State changed from starting to running 22:24:00,792 DEBUG [ProjectResourceBundle] org.apache.axis.i18n.resource::handleGetObject(implAlreadySet) 22:24:00,802 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=openejb:type=WSContainer,name=BookShopEJB java.lang.RuntimeException: java.lang.IllegalArgumentException: Attempt to set implementation class on a ServiceDesc which has already been configured at org.openejb.server.axis.WSContainer.init(WSContainer.java:100) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructor AccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCon structorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanIns tance.java:815) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(G BeanInstanceState.java:328) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanc eState.java:111) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.jav a:486) at org.apache.geronimo.gbean.runtime.GBeanSingleReference.attemptFullStart (GBeanSingleReference.java:154) at org.apache.geronimo.gbean.runtime.GBeanSingleReference.targetAdded(GBea nSingleReference.java:127) at org.apache.geronimo.gbean.runtime.AbstractGBeanReference.addTarget(Abst ractGBeanReference.java:242) at org.apache.geronimo.gbean.runtime.GBeanSingleReference$1.running(GBeanS ingleReference.java:163) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent (BasicLifecycleMonitor.java:155) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Basic LifecycleMonitor.java:38) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroa dcaster.fireRunningEvent(BasicLifecycleMonitor.java:231) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(G BeanInstanceState.java:352) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanc eState.java:111) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBe anInstanceState.java:133) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanIns tance.java:503) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicK ernel.java:207) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBe anInstanceState.java:141) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanIns tance.java:503) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicK ernel.java:207) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:247) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:81) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:320) Caused by: java.lang.IllegalArgumentException: Attempt to set implementation class on a ServiceDesc which has already been configured at org.apache.axis.description.JavaServiceDesc.setImplClass(JavaServiceDes c.java:244) at
[jira] Assigned: (GERONIMO-745) Move from Axis 1.3-SNAPSHOT to formal version
[ http://issues.apache.org/jira/browse/GERONIMO-745?page=all ] David Blevins reassigned GERONIMO-745: -- Assign To: David Blevins (was: Davanum Srinivas) Move from Axis 1.3-SNAPSHOT to formal version - Key: GERONIMO-745 URL: http://issues.apache.org/jira/browse/GERONIMO-745 Project: Geronimo Type: Task Components: webservices Versions: 1.0-M4 Reporter: John Sisson Assignee: David Blevins Fix For: 1.0-M4 Dims, is this possible? For the record, are we relying upon any APIs/features/bug fixes that aren't in Axis 1.2.1? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Closed: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
...meaning you want me to open 823 and close 824? On Jul 27, 2005, at 3:16 PM, Matt Hogstrom wrote: Oops...my JIRA was 824 :) - Original Message - From: David Blevins (JIRA) dev@geronimo.apache.org To: dev@geronimo.apache.org Sent: Wednesday, July 27, 2005 3:55 PM Subject: [jira] Closed: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file [ http://issues.apache.org/jira/browse/GERONIMO-823?page=all ] David Blevins closed GERONIMO-823: -- Resolution: Fixed Checked into OpenEJB by Matt Hogstrom. Closing the issue for him as he doesn't have Geronimo access. We should accept (and ignore) simple type mappings in a jaxrpc- mapping file - - - Key: GERONIMO-823 URL: http://issues.apache.org/jira/browse/GERONIMO-823 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Fix For: 1.0-M5 The IBM jaxrpc mapping generator likes to produce redundant unneccesary type mappings for built in simple types such as java-xml-type-mapping java-typejava.math.BigDecimal/java-type root-type-qname xmlns:rtq=http://www.w3.org/2001/XMLSchema;rtq:decimal/root-type- qname qname-scopesimpleType/qname-scope /java-xml-type-mapping The spec doesn't appear to mention or prohibit these. In the interests of portability we should ignore these rather than objecting to them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-820) CommandSupport does not adequately synchronize access to state
[ http://issues.apache.org/jira/browse/GERONIMO-820?page=all ]
David Jencks closed GERONIMO-820:
-
Resolution: Fixed
Fixed, in CommandSupport
M5 rev 225439
M4 rev 225438
CommandSupport does not adequately synchronize access to state
Key: GERONIMO-820
URL: http://issues.apache.org/jira/browse/GERONIMO-820
Project: Geronimo
Type: Bug
Components: deployment
Versions: 1.0-M4, 1.0-M5
Reporter: David Jencks
Assignee: David Jencks
Fix For: 1.0-M4, 1.0-M5
Changing state is synchronized, reading it should be also.
-public DeploymentStatus getDeploymentStatus() {
+public synchronized DeploymentStatus getDeploymentStatus() {
return new Status(command, action, state, message);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Geronimo logo contest
+10 - Matt - Original Message - From: Jeff Genender [EMAIL PROTECTED] To: dev@geronimo.apache.org Sent: Thursday, July 28, 2005 12:11 PM Subject: Re: Geronimo logo contest Outstanding #11...really nice work. Bruce Snyder wrote: On 7/22/05, Vikrant [EMAIL PROTECTED] wrote: i came across this page about a logo for apache geronimo. i have designed a logo for that, but just wanted to know how i can upload it onto the site. Nice work Vikrant! You've got my vote so far. Bruce
Potential Security Bug?
Hi, I have been trying to understand why I was not able to make the Java Pet Store Supplier Application to pass a security check and I think that I have discovered a potential bug. Prior to log it, I would like to confirm that this is not a code issue in PetStore. The scenario is rather simple: * the url /RcvrRequestProcessor is secured and only the administator role can access it; * a FORM based authentication is configured to log in the users; * the url /RcvrRequestProcessor plays the role of a dispatcher servlet and forwards to the jsp file /displayinventory.jsp; * within the jsp /displayinventory.jsp there is the following security check request.isUserInRole(administrator); and * this security check fails. I think that the security configuration is OK as I can log in and successfully access the url /RcvrRequestProcessor, which requires an administrator role. However, isUserInRole fails. This is the Permission which is tested: (javax.security.jacc.WebRoleRefPermission jsp administrator) Against the following Permissions: [EMAIL PROTECTED] ( (javax.security.jacc.WebResourcePermission /RcvrRequestProcessor GET,POST) (javax.security.jacc.WebRoleRefPermission PopulateServlet administrator) (javax.security.jacc.WebRoleRefPermission RcvrRequestProcessor administrator) ) The jsp portion of the Permission being tested is the name of the servlet being processed and comes from a JettyServletHolder automatically registered for the processing of jsp files. If I add to the web.xml DD the following elements to explicitly register the jsp /displayinventory.jsp, then isUserInRole works as expected: servlet servlet-name/displayinventory.jsp/servlet-name jsp-file/displayinventory.jsp/jsp-file /servlet servlet-mapping servlet-name/displayinventory.jsp/servlet-name url-pattern/displayinventory.jsp/url-pattern /servlet-mapping Indeed, with this explicit mapping, when isUserInRole is executed, the Permission to be tested is: (javax.security.jacc.WebRoleRefPermission /displayinventory.jsp administrator) And the Permissions is: [EMAIL PROTECTED] ( (javax.security.jacc.WebRoleRefPermission /displayinventory.jsp administrator) (javax.security.jacc.WebRoleRefPermission PopulateServlet administrator) (javax.security.jacc.WebRoleRefPermission RcvrRequestProcessor administrator) (javax.security.jacc.WebResourcePermission /RcvrRequestProcessor GET,POST) ) As a matter of fact, I am not sure if this is a bug in our implementation or in PetStore (FYI, I have found another configuration issue for an ejb-jar.xml DD). Any idea? Thanks, Gianny
[jira] Commented: (GERONIMO-827) Change CMR mapping name elements to descriptions
[ http://issues.apache.org/jira/browse/GERONIMO-827?page=comments#action_12317151 ] Gianny Damour commented on GERONIMO-827: Now, I see the purpose of these two optional elements. I knew that unique constraints were defined on them; yet I did not envisage that they were used for non-navigable relationships. I do not know if a lot of people are using this mechanism; yet, it seems fair to enhance our code to support this case. Change CMR mapping name elements to descriptions Key: GERONIMO-827 URL: http://issues.apache.org/jira/browse/GERONIMO-827 Project: Geronimo Type: Improvement Components: OpenEJB Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0-M5 Change the ejb-relation-name and ejb-relationship-role-name elements in openejb-jar.xml at: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ejb-relationship-role-name To be description elements instead, since they're not actually used by the server and are for documentation purposes only. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Potential Security Bug?
Yes...there might be a bug here... IIRC, the Jetty JACC code did not test for JACC v1.0 section B.19 which is an explicit test for JSPs under JACC. I am not sure if this is the case here...but it sounds like it. I would like to see what David Jencks or Alan thinks about this. Jeff Gianny Damour wrote: Hi, I have been trying to understand why I was not able to make the Java Pet Store Supplier Application to pass a security check and I think that I have discovered a potential bug. Prior to log it, I would like to confirm that this is not a code issue in PetStore. The scenario is rather simple: * the url /RcvrRequestProcessor is secured and only the administator role can access it; * a FORM based authentication is configured to log in the users; * the url /RcvrRequestProcessor plays the role of a dispatcher servlet and forwards to the jsp file /displayinventory.jsp; * within the jsp /displayinventory.jsp there is the following security check request.isUserInRole(administrator); and * this security check fails. I think that the security configuration is OK as I can log in and successfully access the url /RcvrRequestProcessor, which requires an administrator role. However, isUserInRole fails. This is the Permission which is tested: (javax.security.jacc.WebRoleRefPermission jsp administrator) Against the following Permissions: [EMAIL PROTECTED] ( (javax.security.jacc.WebResourcePermission /RcvrRequestProcessor GET,POST) (javax.security.jacc.WebRoleRefPermission PopulateServlet administrator) (javax.security.jacc.WebRoleRefPermission RcvrRequestProcessor administrator) ) The jsp portion of the Permission being tested is the name of the servlet being processed and comes from a JettyServletHolder automatically registered for the processing of jsp files. If I add to the web.xml DD the following elements to explicitly register the jsp /displayinventory.jsp, then isUserInRole works as expected: servlet servlet-name/displayinventory.jsp/servlet-name jsp-file/displayinventory.jsp/jsp-file /servlet servlet-mapping servlet-name/displayinventory.jsp/servlet-name url-pattern/displayinventory.jsp/url-pattern /servlet-mapping Indeed, with this explicit mapping, when isUserInRole is executed, the Permission to be tested is: (javax.security.jacc.WebRoleRefPermission /displayinventory.jsp administrator) And the Permissions is: [EMAIL PROTECTED] ( (javax.security.jacc.WebRoleRefPermission /displayinventory.jsp administrator) (javax.security.jacc.WebRoleRefPermission PopulateServlet administrator) (javax.security.jacc.WebRoleRefPermission RcvrRequestProcessor administrator) (javax.security.jacc.WebResourcePermission /RcvrRequestProcessor GET,POST) ) As a matter of fact, I am not sure if this is a bug in our implementation or in PetStore (FYI, I have found another configuration issue for an ejb-jar.xml DD). Any idea? Thanks, Gianny
[jira] Assigned: (GERONIMO-756) Move ServiceMix from 1.0-SNAPSHOT to a formal or dated/versioned release for Geronimo M4
[ http://issues.apache.org/jira/browse/GERONIMO-756?page=all ] David Blevins reassigned GERONIMO-756: -- Assign To: David Blevins (was: Hiram Chirino) Move ServiceMix from 1.0-SNAPSHOT to a formal or dated/versioned release for Geronimo M4 Key: GERONIMO-756 URL: http://issues.apache.org/jira/browse/GERONIMO-756 Project: Geronimo Type: Task Components: dependencies Versions: 1.0-M4 Reporter: John Sisson Assignee: David Blevins Fix For: 1.0-M4 Can you do this Hiram? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-755) Move from Scout (JAXR) version 1.0-SNAPSHOT to a formal version
[ http://issues.apache.org/jira/browse/GERONIMO-755?page=all ] David Blevins reassigned GERONIMO-755: -- Assign To: David Blevins (was: Geir Magnusson Jr) Move from Scout (JAXR) version 1.0-SNAPSHOT to a formal version --- Key: GERONIMO-755 URL: http://issues.apache.org/jira/browse/GERONIMO-755 Project: Geronimo Type: Task Components: dependencies Versions: 1.0-M4 Reporter: John Sisson Assignee: David Blevins Fix For: 1.0-M4 Doing a search it is referenced by: geronimo/assemblies/j2ee-server/project.xml geronimo/modules/assembly/project.xml geronimo/modules/webservices/project.xml geronimo/specs/jaxr/project.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-757) Move from jUDDI SNAPSHOT to formal version
[ http://issues.apache.org/jira/browse/GERONIMO-757?page=all ] David Blevins reassigned GERONIMO-757: -- Assign To: David Blevins (was: Geir Magnusson Jr) Move from jUDDI SNAPSHOT to formal version -- Key: GERONIMO-757 URL: http://issues.apache.org/jira/browse/GERONIMO-757 Project: Geronimo Type: Task Components: dependencies Versions: 1.0-M4 Reporter: John Sisson Assignee: David Blevins Fix For: 1.0-M4 Doing a search it is a dependency in the following files: geronimo/assemblies/j2ee-server/project.xml geronimo/modules/assembly/project.xml commented out in geronimo/modules/assembly/src/plan/j2ee-client-plan.xml used as a dependency in geronimo/applications/uddi-server/src/webapp/WEB-INF/geronimo-web.xml Is anything else using jUDDI at the moment? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Potential Security Bug?
I think our behavior is correct. I don't quite understand what the other possibilities are. FWIW, I don't think we should bend over backward to support jsp pages not mentioned web.xml. thanks david jencks On Jul 28, 2005, at 7:52 PM, Jeff Genender wrote: Yes...there might be a bug here... IIRC, the Jetty JACC code did not test for JACC v1.0 section B.19 which is an explicit test for JSPs under JACC. I am not sure if this is the case here...but it sounds like it. I would like to see what David Jencks or Alan thinks about this. Jeff Gianny Damour wrote: Hi, I have been trying to understand why I was not able to make the Java Pet Store Supplier Application to pass a security check and I think that I have discovered a potential bug. Prior to log it, I would like to confirm that this is not a code issue in PetStore. The scenario is rather simple: * the url /RcvrRequestProcessor is secured and only the administator role can access it; * a FORM based authentication is configured to log in the users; * the url /RcvrRequestProcessor plays the role of a dispatcher servlet and forwards to the jsp file /displayinventory.jsp; * within the jsp /displayinventory.jsp there is the following security check request.isUserInRole(administrator); and * this security check fails. I think that the security configuration is OK as I can log in and successfully access the url /RcvrRequestProcessor, which requires an administrator role. However, isUserInRole fails. This is the Permission which is tested: (javax.security.jacc.WebRoleRefPermission jsp administrator) Against the following Permissions: [EMAIL PROTECTED] ( (javax.security.jacc.WebResourcePermission /RcvrRequestProcessor GET,POST) (javax.security.jacc.WebRoleRefPermission PopulateServlet administrator) (javax.security.jacc.WebRoleRefPermission RcvrRequestProcessor administrator) ) The jsp portion of the Permission being tested is the name of the servlet being processed and comes from a JettyServletHolder automatically registered for the processing of jsp files. If I add to the web.xml DD the following elements to explicitly register the jsp /displayinventory.jsp, then isUserInRole works as expected: servlet servlet-name/displayinventory.jsp/servlet-name jsp-file/displayinventory.jsp/jsp-file /servlet servlet-mapping servlet-name/displayinventory.jsp/servlet-name url-pattern/displayinventory.jsp/url-pattern /servlet-mapping Indeed, with this explicit mapping, when isUserInRole is executed, the Permission to be tested is: (javax.security.jacc.WebRoleRefPermission /displayinventory.jsp administrator) And the Permissions is: [EMAIL PROTECTED] ( (javax.security.jacc.WebRoleRefPermission /displayinventory.jsp administrator) (javax.security.jacc.WebRoleRefPermission PopulateServlet administrator) (javax.security.jacc.WebRoleRefPermission RcvrRequestProcessor administrator) (javax.security.jacc.WebResourcePermission /RcvrRequestProcessor GET,POST) ) As a matter of fact, I am not sure if this is a bug in our implementation or in PetStore (FYI, I have found another configuration issue for an ejb-jar.xml DD). Any idea? Thanks, Gianny
