[jira] Commented: (GERONIMO-1011) HTTPS Connectors fail on IBM JDK

2005-09-16 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-1011?page=comments#action_12329604
 ] 

Jeremy Boynes commented on GERONIMO-1011:
-

Fixed in a slightly different way
Sendingmodules/assembly/src/plan/j2ee-jetty-plan.xml
Sendingmodules/assembly/src/plan/j2ee-tomcat-plan.xml
Sending
modules/jetty/src/java/org/apache/geronimo/jetty/connector/HTTPSConnector.java
Sending
modules/tomcat/src/java/org/apache/geronimo/tomcat/HttpsConnectorGBean.java
Transmitting file data 
Committed revision 289691.

This change allows the user to specify a value of Default for the algorithm 
which causes the connector to obtain the platform default from the 
KeyManagerFactory. This is standard Java and should work on any JVM.

This does not affect the client-side behaviour.

 HTTPS Connectors fail on IBM JDK
 

  Key: GERONIMO-1011
  URL: http://issues.apache.org/jira/browse/GERONIMO-1011
  Project: Geronimo
 Type: Bug
   Components: JVM-compatibility
 Versions: 1.0-M5
  Environment: WinXP or Win2003 Server w/ IBM 1.4.2 JDK
 Reporter: Donald Woods
  Attachments: IBMJUnit.patch, IBMSSL.patch

 HTTPS connectors for Jetty and Tomcat fail to load when starting the server 
 using the IBM 1.4.2 JDK.
 This worked with M4, but was broken sometime in the last several weeks by 
 changes in M5.
 The IBM JDK supplies its own HTTPS handler - com.ibm.net.ssl.www.protocol, 
 which must be manually loaded in addition to the default sun.net.www.protocol.
 Also, the IBM JDK provides a different implementation of the X059 algorithm, 
 which is IbmX509 instead of SunX509.
 The required code changes to recognize that an IBM JDK is being used and 
 initialize the algorithm and protocol handler correctly, are confined to the 
 Jetty and Tomcat HttpsConnector classes and the GeronimoURLFactory.
 The resolution of this bug will only allow a Geronimo server built with the 
 Sun JDK to run on an IBM JDK - it does not resolve the other known build and 
 Orb problems with using non-Sun JVMs.

-- 
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-982) After GBean changes some JSR77 objects don't have a statisticsProvider attribute

2005-09-14 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-982?page=all ]
 
Jeremy Boynes closed GERONIMO-982:
--

Resolution: Fixed

Resolved in various commits

 After GBean changes some JSR77 objects don't have a statisticsProvider 
 attribute
 

  Key: GERONIMO-982
  URL: http://issues.apache.org/jira/browse/GERONIMO-982
  Project: Geronimo
 Type: Bug
   Components: management
 Reporter: Jeremy Boynes
 Assignee: Jeremy Boynes
 Priority: Blocker
  Fix For: 1.0-M5


 Ones that I think may be affected are:
 javamailresource
 jcamanagedconnectionfactory
 jcaresource
 jtaresource
 resourceadapter
 jcaconnectionfactory
 statefulsessionbean
 statelesssessionbean

-- 
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-982) After GBean changes some JSR77 objects don't have a statisticsProvider attribute

2005-09-12 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-982?page=all ]

Jeremy Boynes reassigned GERONIMO-982:
--

Assign To: Jeremy Boynes

 After GBean changes some JSR77 objects don't have a statisticsProvider 
 attribute
 

  Key: GERONIMO-982
  URL: http://issues.apache.org/jira/browse/GERONIMO-982
  Project: Geronimo
 Type: Bug
   Components: management
 Reporter: Jeremy Boynes
 Assignee: Jeremy Boynes
 Priority: Blocker
  Fix For: 1.0-M5


 Ones that I think may be affected are:
 javamailresource
 jcamanagedconnectionfactory
 jcaresource
 jtaresource
 resourceadapter
 jcaconnectionfactory
 statefulsessionbean
 statelesssessionbean

-- 
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-1001) Derby NetworkServer does not use TCCL

2005-09-10 Thread Jeremy Boynes (JIRA)
Derby NetworkServer does not use TCCL
-

 Key: GERONIMO-1001
 URL: http://issues.apache.org/jira/browse/GERONIMO-1001
 Project: Geronimo
Type: Bug
  Components: databases  
Versions: 1.0-M5
 Environment: Derby 10.1
Reporter: Jeremy Boynes


When calling stored procedures, the Derby engine locates the implementation 
using three sources:
* the Thread's context classloader (TCCL)
* the database class path (jars that have been loaded in)
* the classpath of the engine classes themselves

When embedded in Geronimo as a RAR, we initialize the TCCL to that of the RAR 
which allows procedure code to be located in the RAR itself.

However, if the RAR defines a NetworkServer the TCCL is not inherited by the 
worker threads it spawns to service requests from clients and as a result calls 
to procedures whose implementation is located in the war will fail with a 
ClassNotFoundException


-- 
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-1001) Derby NetworkServer does not use TCCL

2005-09-10 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-1001?page=comments#action_12323128
 ] 

Jeremy Boynes commented on GERONIMO-1001:
-

A workaround is to load the classes for the procedures into the database as 
described here:
http://db.apache.org/derby/docs/10.1/devguide/cdevdeploy30736.html

I don't know if this is a permanent link so the relevant commands are:
CALL sqlj.install_jar('procs.jar', 'APP.Sample1', 0);
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.classpath', 
'APP.Sample1');

 Derby NetworkServer does not use TCCL
 -

  Key: GERONIMO-1001
  URL: http://issues.apache.org/jira/browse/GERONIMO-1001
  Project: Geronimo
 Type: Bug
   Components: databases
 Versions: 1.0-M5
  Environment: Derby 10.1
 Reporter: Jeremy Boynes


 When calling stored procedures, the Derby engine locates the implementation 
 using three sources:
 * the Thread's context classloader (TCCL)
 * the database class path (jars that have been loaded in)
 * the classpath of the engine classes themselves
 When embedded in Geronimo as a RAR, we initialize the TCCL to that of the RAR 
 which allows procedure code to be located in the RAR itself.
 However, if the RAR defines a NetworkServer the TCCL is not inherited by the 
 worker threads it spawns to service requests from clients and as a result 
 calls to procedures whose implementation is located in the war will fail with 
 a ClassNotFoundException

-- 
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-990) Remove external SNAPSHOT dependencies

2005-09-09 Thread Jeremy Boynes (JIRA)
Remove external SNAPSHOT dependencies
-

 Key: GERONIMO-990
 URL: http://issues.apache.org/jira/browse/GERONIMO-990
 Project: Geronimo
Type: Bug
Versions: 1.0-M5
Reporter: Jeremy Boynes
Priority: Blocker


Remove dependencies on external SNAPSHOTs so release is consistently rebuildable

-- 
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-991) Remove SNAPSHOT dependency on TranQL

2005-09-09 Thread Jeremy Boynes (JIRA)
Remove SNAPSHOT dependency on TranQL


 Key: GERONIMO-991
 URL: http://issues.apache.org/jira/browse/GERONIMO-991
 Project: Geronimo
Type: Sub-task
Versions: 1.0-M5
Reporter: Jeremy Boynes
 Assigned to: Jeremy Boynes 


Switch to a released version of TranQL

-- 
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-992) Remove SNAPSHOT dependency on ActiveMQ

2005-09-09 Thread Jeremy Boynes (JIRA)
Remove SNAPSHOT dependency on ActiveMQ
--

 Key: GERONIMO-992
 URL: http://issues.apache.org/jira/browse/GERONIMO-992
 Project: Geronimo
Type: Sub-task
Reporter: Jeremy Boynes
 Assigned to: Hiram Chirino 




-- 
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-993) Remove SNAPSHOT dependency on Driectory

2005-09-09 Thread Jeremy Boynes (JIRA)
Remove SNAPSHOT dependency on Driectory
---

 Key: GERONIMO-993
 URL: http://issues.apache.org/jira/browse/GERONIMO-993
 Project: Geronimo
Type: Sub-task
Reporter: Jeremy Boynes
 Assigned to: Jeff Genender 




-- 
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-994) Remove SNAPSHOT dependency on Axis

2005-09-09 Thread Jeremy Boynes (JIRA)
Remove SNAPSHOT dependency on Axis
--

 Key: GERONIMO-994
 URL: http://issues.apache.org/jira/browse/GERONIMO-994
 Project: Geronimo
Type: Sub-task
Reporter: Jeremy Boynes
 Assigned to: David Blevins 




-- 
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-995) Remove SNAPSHOT dependency on jUUI and Scout

2005-09-09 Thread Jeremy Boynes (JIRA)
Remove SNAPSHOT dependency on jUUI and Scout


 Key: GERONIMO-995
 URL: http://issues.apache.org/jira/browse/GERONIMO-995
 Project: Geronimo
Type: Sub-task
Reporter: Jeremy Boynes
 Assigned to: Geir Magnusson Jr 




-- 
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-996) Remove SNAPSHOT dependency on ServiceMix

2005-09-09 Thread Jeremy Boynes (JIRA)
Remove SNAPSHOT dependency on ServiceMix


 Key: GERONIMO-996
 URL: http://issues.apache.org/jira/browse/GERONIMO-996
 Project: Geronimo
Type: Sub-task
Reporter: Jeremy Boynes
 Assigned to: Hiram Chirino 




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



[jira] Updated: (GERONIMO-993) Remove SNAPSHOT dependency on Directory

2005-09-09 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-993?page=all ]

Jeremy Boynes updated GERONIMO-993:
---

Summary: Remove SNAPSHOT dependency on Directory  (was: Remove SNAPSHOT 
dependency on Driectory)
Description: 
Environment: 

 Remove SNAPSHOT dependency on Directory
 ---

  Key: GERONIMO-993
  URL: http://issues.apache.org/jira/browse/GERONIMO-993
  Project: Geronimo
 Type: Sub-task
 Reporter: Jeremy Boynes
 Assignee: Jeff Genender




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



[jira] Updated: (GERONIMO-995) Remove SNAPSHOT dependency on jUDDI and Scout

2005-09-09 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-995?page=all ]

Jeremy Boynes updated GERONIMO-995:
---

Summary: Remove SNAPSHOT dependency on jUDDI and Scout  (was: Remove 
SNAPSHOT dependency on jUUI and Scout)
Description: 
Environment: 

 Remove SNAPSHOT dependency on jUDDI and Scout
 -

  Key: GERONIMO-995
  URL: http://issues.apache.org/jira/browse/GERONIMO-995
  Project: Geronimo
 Type: Sub-task
 Reporter: Jeremy Boynes
 Assignee: Geir Magnusson Jr




-- 
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-997) Remove SNAPSHOT dependency on Pluto

2005-09-09 Thread Jeremy Boynes (JIRA)
Remove SNAPSHOT dependency on Pluto
---

 Key: GERONIMO-997
 URL: http://issues.apache.org/jira/browse/GERONIMO-997
 Project: Geronimo
Type: Sub-task
Reporter: Jeremy Boynes
 Assigned to: Aaron Mulder 




-- 
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-998) Remove SNAPSHOT depedency on ActiveCluster

2005-09-09 Thread Jeremy Boynes (JIRA)
Remove SNAPSHOT depedency on ActiveCluster
--

 Key: GERONIMO-998
 URL: http://issues.apache.org/jira/browse/GERONIMO-998
 Project: Geronimo
Type: Sub-task
Reporter: Jeremy Boynes
 Assigned to: Hiram Chirino 




-- 
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-995) Remove SNAPSHOT dependency on jUDDI and Scout

2005-09-09 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-995?page=all ]
 
Jeremy Boynes reopened GERONIMO-995:



The installer directory still contains a SNAPSHOT version of jaxr (but the 
normal assembly does not) - I have no idea why

 Remove SNAPSHOT dependency on jUDDI and Scout
 -

  Key: GERONIMO-995
  URL: http://issues.apache.org/jira/browse/GERONIMO-995
  Project: Geronimo
 Type: Sub-task
 Reporter: Jeremy Boynes
 Assignee: Geir Magnusson Jr




-- 
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-310) Support extension directory

2005-09-06 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-310?page=all ]

Jeremy Boynes reassigned GERONIMO-310:
--

Assign To: (was: Jeremy Boynes)

I don't think its implemented although it would be worth checking; I think 
Class-Path references are supported within a module but not the general 
Extension mechanism

 Support extension directory
 ---

  Key: GERONIMO-310
  URL: http://issues.apache.org/jira/browse/GERONIMO-310
  Project: Geronimo
 Type: Task
 Reporter: Jeremy Boynes
  Fix For: 1.0-M5


 Geronimo should support an extension directory where packages can be stored 
 and then referenced by applications using the standard package extenstion 
 mechanism. Something like this is needed to support J2EE8.2

-- 
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-977) Stack Trace During OpenEJB iTest Deployment

2005-09-04 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-977?page=all ]
 
Jeremy Boynes closed GERONIMO-977:
--

Fix Version: (was: 1.0-M5)
 Resolution: Fixed

Security beans need a reference to the login service so they can initialize the 
login module correctly

Checking in modules/itests/src/plan/security-plan.xml;
/home/projects/openejb/scm/openejb/modules/itests/src/plan/security-plan.xml,v  
--  security-plan.xml
new revision: 1.2; previous revision: 1.1
done
Mailing the commit message...

 Stack Trace During OpenEJB iTest Deployment
 ---

  Key: GERONIMO-977
  URL: http://issues.apache.org/jira/browse/GERONIMO-977
  Project: Geronimo
 Type: Bug
   Components: OpenEJB, security
 Versions: 1.0-M5
 Reporter: Aaron Mulder


 java.lang.NullPointerException
 at 
 org.apache.geronimo.security.jaas.ServerRealmConfigurationEntry.generateConfiguration(ServerRealmConfigurationEntry.java:69)
 at 
 org.apache.geronimo.security.jaas.ServerRealmConfigurationEntry$$FastClassByCGLIB$$1503fb71.invoke(generated)
 at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
 at 
 org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
 at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:760)
 at 
 org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
 at 
 org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
 at 
 org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
 at 
 org.apache.geronimo.security.jaas.ConfigurationEntryFactory$$EnhancerByCGLIB$$e5befdcb.generateConfiguration(generated)
 at 
 org.apache.geronimo.security.jaas.GeronimoLoginConfiguration.addConfiguration(GeronimoLoginConfiguration.java:107)
 ...

-- 
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-870) Invalid sigantures in JavaMail API jar (trunk)

2005-09-03 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-870?page=all ]

Jeremy Boynes reassigned GERONIMO-870:
--

Assign To: Jeremy Boynes  (was: Davanum Srinivas)

 Invalid sigantures in JavaMail API jar (trunk)
 --

  Key: GERONIMO-870
  URL: http://issues.apache.org/jira/browse/GERONIMO-870
  Project: Geronimo
 Type: Bug
   Components: specs
 Versions: 1.0-M5
 Reporter: David Blevins
 Assignee: Jeremy Boynes
 Priority: Blocker
  Fix For: 1.0-M5


 Recent changes to the JavaMail API classes affect the package signatures:
 javax.mail.internet.MimeMultipart has an additional public inner class 
 MimeBodyPartInputStream
 javax.mail.internet.ParameterList has an additional public method 
 split(java.lang.String,char)

-- 
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-870) Invalid sigantures in JavaMail API jar (trunk)

2005-09-03 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-870?page=all ]
 
Jeremy Boynes closed GERONIMO-870:
--

Resolution: Fixed

Sendingspecs\javamail\src\java\javax\mail\internet\MimeMultipart.java
Sendingspecs\javamail\src\java\javax\mail\internet\ParameterList.java
Transmitting file data ..
Committed revision 267505.

 Invalid sigantures in JavaMail API jar (trunk)
 --

  Key: GERONIMO-870
  URL: http://issues.apache.org/jira/browse/GERONIMO-870
  Project: Geronimo
 Type: Bug
   Components: specs
 Versions: 1.0-M5
 Reporter: David Blevins
 Assignee: Jeremy Boynes
 Priority: Blocker
  Fix For: 1.0-M5


 Recent changes to the JavaMail API classes affect the package signatures:
 javax.mail.internet.MimeMultipart has an additional public inner class 
 MimeBodyPartInputStream
 javax.mail.internet.ParameterList has an additional public method 
 split(java.lang.String,char)

-- 
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-972) SSL keystore attributes should be manageable

2005-09-03 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-972?page=all ]
 
Jeremy Boynes closed GERONIMO-972:
--

Fix Version: 1.0-M5
 Resolution: Fixed

Sending
modules\jetty\src\java\org\apache\geronimo\jetty\connector\HTTPSConnector.java
Sending
modules\tomcat\src\java\org\apache\geronimo\tomcat\HttpsConnectorGBean.java
Transmitting file data ..
Committed revision 267512.

 SSL keystore attributes should be manageable
 

  Key: GERONIMO-972
  URL: http://issues.apache.org/jira/browse/GERONIMO-972
  Project: Geronimo
 Type: Bug
   Components: Tomcat, web
 Versions: 1.0-M5
  Environment: Jetty and Tomcat
 Reporter: Jeremy Boynes
 Assignee: Jeremy Boynes
  Fix For: 1.0-M5


 Keystore password etc. are not manageable so don't get initialized properly

-- 
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-958) Error in console data source when using DB2

2005-09-02 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-958?page=all ]
 
Jeremy Boynes closed GERONIMO-958:
--

Resolution: Fixed

Closed at Matt's request

 Error in console data source when using DB2
 ---

  Key: GERONIMO-958
  URL: http://issues.apache.org/jira/browse/GERONIMO-958
  Project: Geronimo
 Type: Bug
   Components: console
 Versions: 1.0-M5
  Environment: When DB2 is the underlying datasource the Console Blows its 
 brains out...
 Reporter: Matt Hogstrom
  Fix For: 1.0-M5


 Stack trace too large to communicate via the Internet re: Intl Law.  Looking 
 into it.
 But here is a snippet:
 Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
 range: 0
 at java.lang.String.charAt(String.java:444)
 at 
 org.apache.geronimo.console.databasemanager.DataSourceInfo.setJndiName(DataSourceInfo.java:59)
 at 
 org.apache.geronimo.console.databasemanager.AbstractConnectionFactoryManagerPortlet.renderList(AbstractConnectionFactoryManagerPortlet.java:213)
 ... 121 more
 Nested Exception is
 java.lang.StringIndexOutOfBoundsException: String index out of range: 0
 at java.lang.String.charAt(String.java:444)
 at 
 org.apache.geronimo.console.databasemanager.DataSourceInfo.setJndiName(DataSourceInfo.java:59)
 at 
 org.apache.geronimo.console.databasemanager.AbstractConnectionFactoryManagerPortlet.renderList(AbstractConnectionFactoryManagerPortlet.java:213)
 at 
 org.apache.geronimo.console.databasemanager.AbstractConnectionFactoryManagerPortlet.doView(AbstractConnectionFactoryManagerPortlet.java:186)
 at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250)
 Looking into it.

-- 
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-959) JaasLoginService object name should not be hard coded

2005-08-31 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-959?page=all ]
 
Jeremy Boynes closed GERONIMO-959:
--

Resolution: Fixed

 JaasLoginService object name should not be hard coded
 -

  Key: GERONIMO-959
  URL: http://issues.apache.org/jira/browse/GERONIMO-959
  Project: Geronimo
 Type: Bug
   Components: security
 Versions: 1.0-M4, 1.0-M5
 Reporter: Jeremy Boynes
  Fix For: 1.0-M5


 The name of the JaasLoginService should not be a hard-coded object name 
 containing e.g. the server config id

-- 
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-959) JaasLoginService object name should not be hard coded

2005-08-31 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-959?page=comments#action_12320669 
] 

Jeremy Boynes commented on GERONIMO-959:


Replace by having a reference back to the login service that the 
GenericSecurityRealm can use to initialize an option passed to the login module

Sendingmodules\assembly\src\plan\j2ee-secure-plan.xml
Sendingmodules\assembly\src\plan\j2ee-server-plan.xml
Sendingmodules\assembly\src\plan\tomcat-config.xml
Sending
modules\jetty\src\test\org\apache\geronimo\jetty\AbstractWebModuleTest.java
Sending
modules\security\src\java\org\apache\geronimo\security\jaas\JaasLoginCoordinator.java
Sending
modules\security\src\java\org\apache\geronimo\security\jaas\JaasLoginService.java
Sending
modules\security\src\java\org\apache\geronimo\security\jaas\JaasLoginServiceMBean.java
Sending
modules\security\src\java\org\apache\geronimo\security\jaas\ServerRealmConfigurationEntry.java
Sending
modules\security\src\java\org\apache\geronimo\security\realm\GenericSecurityRealm.java
Sending
modules\security\src\java\org\apache\geronimo\security\remoting\jmx\JaasLoginServiceRemotingServer.java
Sending
modules\security\src\test\org\apache\geronimo\security\AbstractTest.java
Sending
modules\security\src\test\org\apache\geronimo\security\jaas\ConfigurationEntryTest.java
Sending
modules\security\src\test\org\apache\geronimo\security\jaas\LoginPropertiesFileTest.java
Sending
modules\security\src\test\org\apache\geronimo\security\jaas\LoginSQLTest.java
Sending
modules\security\src\test\org\apache\geronimo\security\jaas\TimeoutTest.java
Sending
modules\tomcat\src\test\org\apache\geronimo\tomcat\AbstractWebModuleTest.java
Sending
modules\tomcat\src\test\org\apache\geronimo\tomcat\ContainerTest.java
Transmitting file data .
Committed revision 264948.

 JaasLoginService object name should not be hard coded
 -

  Key: GERONIMO-959
  URL: http://issues.apache.org/jira/browse/GERONIMO-959
  Project: Geronimo
 Type: Bug
   Components: security
 Versions: 1.0-M4, 1.0-M5
 Reporter: Jeremy Boynes
  Fix For: 1.0-M5


 The name of the JaasLoginService should not be a hard-coded object name 
 containing e.g. the server config id

-- 
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-956) Remove global JNDI space

2005-08-31 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-956?page=comments#action_12320671 
] 

Jeremy Boynes commented on GERONIMO-956:


There are quite a few applications out there that access the global JNDI 
directly to lookup resources. This is non-standard behaviour but for them we 
can either force them to change or provide a context they can use - this was 
meant to support them.

This is probalby less essential now that we have a directory integrated, but on 
the other hand it probably is a lot lighter in weight.

 Remove global JNDI space
 --

  Key: GERONIMO-956
  URL: http://issues.apache.org/jira/browse/GERONIMO-956
  Project: Geronimo
 Type: Improvement
   Components: connector, naming
 Versions: 1.0-M4
 Reporter: Aaron Mulder
  Fix For: 1.0


 Geronimo has a global JNDI space under geronimo:.  However:
  - it's only used by connectors, not EJBs
  - it's not visible outside the current VM
 It doesn't seem like this is really benefitting anyone.  The effort necessary 
 to make it behave like JNDI behaves in other popular app servers seems to be 
 significant.  After talking on IRC, David J and I are soliciting feedback on 
 removing this feature entirely for now.
 Note: this is different than the JNDI space that OpenEJB uses to expose EJBs 
 to remote clients, which takes EJBs only and is obviously accessible to 
 remote clients.  We are not proposing to change that at this time.

-- 
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-963) Derby classes must be loaded from common classloader

2005-08-31 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-963?page=comments#action_12320736 
] 

Jeremy Boynes commented on GERONIMO-963:


Fixed by moving the Derby classes to the server classloader. Consider moving to 
a dedicated loader when the multi-parent stuff is finished.

Sendingmodules\assembly\src\plan\j2ee-server-plan.xml
Sendingmodules\assembly\src\plan\system-database-plan.xml
Transmitting file data ..
Committed revision 265599.

 Derby classes must be loaded from common classloader
 

  Key: GERONIMO-963
  URL: http://issues.apache.org/jira/browse/GERONIMO-963
  Project: Geronimo
 Type: Bug
   Components: connector
 Reporter: Jeremy Boynes
  Fix For: 1.0-M5


 The derby classes are currently being loaded by the system-database-plan but 
 that leads to a problem when multiple applications access the same database 
 server using different resources. If the classes get loaded from different 
 classloaders, derby thinks that attempts are being made to access the 
 database from two different engines (which they are) and the second attempt 
 fails. This can also happen if access is attempted from both the server 
 (embedded) and via the network server (from a client).

-- 
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-963) Derby classes must be loaded from common classloader

2005-08-31 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-963?page=all ]
 
Jeremy Boynes closed GERONIMO-963:
--

Resolution: Fixed

 Derby classes must be loaded from common classloader
 

  Key: GERONIMO-963
  URL: http://issues.apache.org/jira/browse/GERONIMO-963
  Project: Geronimo
 Type: Bug
   Components: connector
 Reporter: Jeremy Boynes
  Fix For: 1.0-M5


 The derby classes are currently being loaded by the system-database-plan but 
 that leads to a problem when multiple applications access the same database 
 server using different resources. If the classes get loaded from different 
 classloaders, derby thinks that attempts are being made to access the 
 database from two different engines (which they are) and the second attempt 
 fails. This can also happen if access is attempted from both the server 
 (embedded) and via the network server (from a client).

-- 
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-950) JVM portlet shouid display all system property values

2005-08-30 Thread Jeremy Boynes (JIRA)
JVM portlet shouid display all system property values
-

 Key: GERONIMO-950
 URL: http://issues.apache.org/jira/browse/GERONIMO-950
 Project: Geronimo
Type: Bug
  Components: console  
Versions: 1.0-M5
 Reporter: Jeremy Boynes


Only selected system properties are displayed. The etc section should display 
all remaining properties.
E.g. if you start the server with java -Dfoo=bar then there should be a row 
|foo|bar|

-- 
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-959) JaasLoginService object name should not be hard coded

2005-08-30 Thread Jeremy Boynes (JIRA)
JaasLoginService object name should not be hard coded
-

 Key: GERONIMO-959
 URL: http://issues.apache.org/jira/browse/GERONIMO-959
 Project: Geronimo
Type: Bug
  Components: security  
Versions: 1.0-M4, 1.0-M5
 Reporter: Jeremy Boynes
 Fix For: 1.0-M5


The name of the JaasLoginService should not be a hard-coded object name 
containing e.g. the server config id

-- 
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-935) ManagedAttribute injection should work when multiple stores are present

2005-08-28 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-935?page=comments#action_12320355 
] 

Jeremy Boynes commented on GERONIMO-935:


I'm going to fix this initially by replacing the lookup with a GBean reference 
so that an appropriate proxy gets injected. Longer term I think we should 
separate out the initialization of these attributes so that the actual values 
are injected rather than a locator.

 ManagedAttribute injection should work when multiple stores are present
 ---

  Key: GERONIMO-935
  URL: http://issues.apache.org/jira/browse/GERONIMO-935
  Project: Geronimo
 Type: Bug
 Versions: 1.0-M5
 Reporter: Jeremy Boynes
 Assignee: Jeremy Boynes
  Fix For: 1.0-M5


 The implementation of setManagedAttribute in Configuration uses a proxy to 
 the ManagedAttributeStore that is obtained by querying the kernel and using 
 the first one found. This is problematic as more than one GBean implementing 
 that interface may be present in the kernel, leading to results that are 
 inconsistent at best but which may prevent a configuraton from starting at 
 all if the selected target is not running.

-- 
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-935) ManagedAttribute injection should work when multiple stores are present

2005-08-28 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-935?page=comments#action_12320362 
] 

Jeremy Boynes commented on GERONIMO-935:


Sendingconfigs/j2ee-server/project.xml
Sendingconfigs/j2ee-server/src/plan/plan.xml
Sendingconfigs/j2ee-system/src/plan/plan.xml
Adding configs/rmi-naming
Adding configs/rmi-naming/LICENSE.txt
Adding configs/rmi-naming/NOTICE.txt
Adding configs/rmi-naming/maven.xml
Adding configs/rmi-naming/project.properties
Adding configs/rmi-naming/project.xml
Adding configs/rmi-naming/src
Sendingconfigs/rmi-naming/src/plan/plan.xml
Sendingmodules/assembly/src/plan/client-system-plan.xml
Sendingmodules/assembly/src/plan/deployer-system-plan.xml
Sendingmodules/assembly/src/plan/system-plan.xml
Sending
modules/kernel/src/java/org/apache/geronimo/kernel/config/Configuration.java
Sending
modules/kernel/src/java/org/apache/geronimo/kernel/config/ManageableAttributeStore.java
Sending
modules/system/src/java/org/apache/geronimo/system/configuration/LocalAttributeManager.java
Sending
modules/system/src/java/org/apache/geronimo/system/configuration/LocalConfigStore.java
Adding 
plugins/geronimo-packaging-plugin/src/java/org/apache/geronimo/plugin/packaging/MavenAttributeStore.java
Sending
plugins/geronimo-packaging-plugin/src/java/org/apache/geronimo/plugin/packaging/MavenConfigStore.java
Sending
plugins/geronimo-packaging-plugin/src/java/org/apache/geronimo/plugin/packaging/PackageBuilder.java
Transmitting file data 
Committed revision 263902.


 ManagedAttribute injection should work when multiple stores are present
 ---

  Key: GERONIMO-935
  URL: http://issues.apache.org/jira/browse/GERONIMO-935
  Project: Geronimo
 Type: Bug
 Versions: 1.0-M5
 Reporter: Jeremy Boynes
 Assignee: Jeremy Boynes
  Fix For: 1.0-M5


 The implementation of setManagedAttribute in Configuration uses a proxy to 
 the ManagedAttributeStore that is obtained by querying the kernel and using 
 the first one found. This is problematic as more than one GBean implementing 
 that interface may be present in the kernel, leading to results that are 
 inconsistent at best but which may prevent a configuraton from starting at 
 all if the selected target is not running.

-- 
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-938) Added support to TranQL to support DB2 Syntax Generation

2005-08-28 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-938?page=all ]
 
Jeremy Boynes closed GERONIMO-938:
--

Fix Version: 1.0-M5
 Resolution: Fixed

Thanks!

 Added support to TranQL to support DB2 Syntax Generation
 

  Key: GERONIMO-938
  URL: http://issues.apache.org/jira/browse/GERONIMO-938
  Project: Geronimo
 Type: New Feature
 Versions: 1.0-M5
  Environment: All
 Reporter: Matt Hogstrom
  Fix For: 1.0-M5


 I added support to generate SQL more friendly for DB2 with regards to the 
 WHEN predicate.  (DB2 only supports WHEN with an lvalue.  To use this 
 alternate version add the following xml to your openejb-jar.xml under the 
 cmp-connection-factory clause:
 
 ejb-ql-compiler-factoryorg.tranql.ejbqlcompiler.DB2EJBQLCompilerFactory/ejb-ql-compiler-factory
 
 db-syntax-factoryorg.tranql.sql.db2.DB2DBSyntaxtFactory/db-syntax-factory
 SNAPSHOT for TranQL 1.1 has been distributed.

-- 
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-876) console-standard change doesn't make it into console-ear

2005-08-14 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-876?page=comments#action_12318777 
] 

Jeremy Boynes commented on GERONIMO-876:


I am not seeing the application.xml problem:

C:\apache\geronimo\trunk\applications\console-earmaven
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

Attempting to download geronimo-console-framework-1.0-SNAPSHOT.war.
Artifact /geronimo/wars/geronimo-console-framework-1.0-SNAPSHOT.war doesn't 
exists in remote repository, but it exists locally
Attempting to download geronimo-console-standard-1.0-SNAPSHOT.war.
Artifact /geronimo/wars/geronimo-console-standard-1.0-SNAPSHOT.war doesn't 
exists in remote repository, but it exists locally
Attempting to download pluto-1.0.1-SNAPSHOT.jar.
Attempting to download geronimo-console-core-1.0-SNAPSHOT.jar.
Artifact /geronimo/jars/geronimo-console-core-1.0-SNAPSHOT.jar doesn't exists 
in remote repository, but it exists locally
build:start:

ear:init:

ear:ear:
[mkdir] Created dir: 
C:\apache\geronimo\trunk\applications\console-ear\target\plan
[copy] Copying 1 file to 
C:\apache\geronimo\trunk\applications\console-ear\target
[echo] Building EAR geronimo-console-1.0-SNAPSHOT with appxml 
C:\apache\geronimo\trunk\applications\console-ear/target/applicat
ion.xml
[echo] Bundling: war - geronimo:geronimo-console-framework - 1.0-SNAPSHOT
[echo] Dependency geronimo-console-framework-1.0-SNAPSHOT.war will be 
bundled as /geronimo-console-framework-1.0-SNAPSHOT.war
[copy] Copying 1 file to 
C:\apache\geronimo\trunk\applications\console-ear\target\tmpEarDeps
[echo] Bundling: war - geronimo:geronimo-console-standard - 1.0-SNAPSHOT
[echo] Dependency geronimo-console-standard-1.0-SNAPSHOT.war will be 
bundled as /geronimo-console-standard-1.0-SNAPSHOT.war
[copy] Copying 1 file to 
C:\apache\geronimo\trunk\applications\console-ear\target\tmpEarDeps
[mkdir] Created dir: 
C:\apache\geronimo\trunk\applications\console-ear\target\ear
[ear] Building ear: 
C:\apache\geronimo\trunk\applications\console-ear\target\geronimo-console-1.0-SNAPSHOT.ear
[delete] Deleting directory 
C:\apache\geronimo\trunk\applications\console-ear\target\tmpEarDeps

ear:install:
[echo] Installing...
Uploading to geronimo/ears/geronimo-console-1.0-SNAPSHOT.ear:
 (5769K)
Uploading to geronimo/poms/geronimo-console-1.0-SNAPSHOT.pom:
 (12K)
BUILD SUCCESSFUL
Total time: 13 seconds
Finished at: Sun Aug 14 19:20:41 PDT 2005

C:\apache\geronimo\trunk\applications\console-earjar tvf 
target\geronimo-console-1.0-SNAPSHOT.ear
 0 Sun Aug 14 19:20:40 PDT 2005 META-INF/
   413 Sun Aug 14 19:20:38 PDT 2005 META-INF/MANIFEST.MF
  3037 Sun Aug 14 19:20:38 PDT 2005 META-INF/geronimo-application.xml
2485511 Sun Aug 14 19:20:38 PDT 2005 geronimo-console-framework-1.0-SNAPSHOT.war
3516105 Sun Aug 14 19:20:40 PDT 2005 geronimo-console-standard-1.0-SNAPSHOT.war
   742 Sun Aug 14 19:20:38 PDT 2005 META-INF/application.xml

C:\apache\geronimo\trunk\applications\console-ear

 console-standard change doesn't make it into console-ear
 

  Key: GERONIMO-876
  URL: http://issues.apache.org/jira/browse/GERONIMO-876
  Project: Geronimo
 Type: Bug
   Components: buildsystem, console
 Versions: 1.0-M5
 Reporter: Aaron Mulder


 If code in the console-standard module is changed, a new artifact for that 
 module is built.  However, the console-ear module does not consider itself 
 out of date as a result of that, so the change is not reflected in the new 
 assembly until the console-ear module is manually cleaned and rebuilt.  It 
 should be that a normal build of Geronimo recreates the console-ear if the 
 console-standard has been updated.  As a shortcut, we could recreate 
 console-ear every time since it's quite fast.

-- 
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-876) console-standard change doesn't make it into console-ear

2005-08-14 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-876?page=comments#action_12318779 
] 

Jeremy Boynes commented on GERONIMO-876:


I upgraded to V1.7 of the EAR plugin and am still not having any problems (Sun 
JDK1.4.2_08 on WinXP)

 console-standard change doesn't make it into console-ear
 

  Key: GERONIMO-876
  URL: http://issues.apache.org/jira/browse/GERONIMO-876
  Project: Geronimo
 Type: Bug
   Components: buildsystem, console
 Versions: 1.0-M5
 Reporter: Aaron Mulder


 If code in the console-standard module is changed, a new artifact for that 
 module is built.  However, the console-ear module does not consider itself 
 out of date as a result of that, so the change is not reflected in the new 
 assembly until the console-ear module is manually cleaned and rebuilt.  It 
 should be that a normal build of Geronimo recreates the console-ear if the 
 console-standard has been updated.  As a shortcut, we could recreate 
 console-ear every time since it's quite fast.

-- 
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-874) Deployer should not throw exceptions that cannot be deserialized

2005-08-10 Thread Jeremy Boynes (JIRA)
Deployer should not throw exceptions that cannot be deserialized


 Key: GERONIMO-874
 URL: http://issues.apache.org/jira/browse/GERONIMO-874
 Project: Geronimo
Type: Bug
  Components: deployment  
Versions: 1.0-M4
Reporter: Jeremy Boynes


When invoked remotely (e.g. over JMX) the deployer should not throw exceptions 
that cannot be deserialized, for example a DeploymentException with a nested 
Exception whose class is not available to the client. An example of this just 
reported on the user list occurs when a QueryException is raised by TranQL.

One solution may be to log the exception on the server and just throw a 
DeploymentException with the message and no inner cause.

-- 
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-821) Invalid sigantures in JavaMail API jar

2005-08-07 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-821?page=all ]
 
Jeremy Boynes reopened GERONIMO-821:



Both M4 and trunk say they produce rc5 version of JavaMail but the source trees 
are different (one includes Dims' change, the other doesn't).

This means we may have inconsistent version of the the spec jar in different 
repos.

 Invalid sigantures in JavaMail API jar
 --

  Key: GERONIMO-821
  URL: http://issues.apache.org/jira/browse/GERONIMO-821
  Project: Geronimo
 Type: Bug
   Components: specs
 Versions: 1.0-M4
 Reporter: Jeremy Boynes
 Assignee: Davanum Srinivas
 Priority: Blocker
  Fix For: 1.0-M4


 Recent changes to the JavaMail API classes affect the package signatures:
 javax.mail.internet.MimeMultipart has an additional public inner class 
 MimeBodyPartInputStream
 javax.mail.internet.ParameterList has an additional public method 
 split(java.lang.String,char)

-- 
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-857) Console links are incorrect

2005-08-06 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-857?page=all ]
 
Jeremy Boynes closed GERONIMO-857:
--

Resolution: Fixed

Fix ConfigService properties to include the servlet mappings - this matches a 
change made in the old pluto-portal.jar file

Sending
applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties
Transmitting file data .
Committed revision 230572.


 Console links are incorrect
 ---

  Key: GERONIMO-857
  URL: http://issues.apache.org/jira/browse/GERONIMO-857
  Project: Geronimo
 Type: Bug
   Components: console
 Versions: 1.0-M5
 Reporter: Jeremy Boynes
  Fix For: 1.0-M5


 Links on the left hand side of the console have the form:
 http://localhost:8080/consolenull/server/server_info
 The null in the middle should be /portal

-- 
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-858) Clean up dependencies in console application

2005-08-06 Thread Jeremy Boynes (JIRA)
Clean up dependencies in console application


 Key: GERONIMO-858
 URL: http://issues.apache.org/jira/browse/GERONIMO-858
 Project: Geronimo
Type: Bug
  Components: console  
Versions: 1.0-M5
Reporter: Jeremy Boynes
 Fix For: 1.0-M5


The console application contains a LOT of dependencies that will be resolved by 
the parent configuration or by the WAR classloader. This is inefficient and may 
lead to unexpected classloading issues. These should be reduced to the minimum 
set.

-- 
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-859) Remove SNAPSHOT dependency on Pluto

2005-08-06 Thread Jeremy Boynes (JIRA)
Remove SNAPSHOT dependency on Pluto
---

 Key: GERONIMO-859
 URL: http://issues.apache.org/jira/browse/GERONIMO-859
 Project: Geronimo
Type: Bug
  Components: console  
Versions: 1.0-M5
Reporter: Jeremy Boynes
 Fix For: 1.0-M5


Replace the dependency on a SNAPSHOT version of Pluto with a release version.
Currently using a SNAPSHOT version as that supports upload of its artifacts to 
a maven repo.

-- 
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-861) Investigate warning from Pluto portal

2005-08-06 Thread Jeremy Boynes (JIRA)
Investigate warning from Pluto portal
-

 Key: GERONIMO-861
 URL: http://issues.apache.org/jira/browse/GERONIMO-861
 Project: Geronimo
Type: Bug
  Components: console  
Versions: 1.0-M5
Reporter: Jeremy Boynes
 Assigned to: Jeremy Boynes 
Priority: Blocker
 Fix For: 1.0-M5


1) Provide pluto-portal-1.0.1-SNAPSHOT.jar (currently only the WAR is on 
Jeremy's home dir, but the build wants a JAR built from WEB-INF/classes in the 
WAR)

2) Investigate the following message:

14:31:22,763 WARN  [Servlet] org.apache.pluto.portalImpl.Servlet#init(): 
Couldn't read property pluto.allowSetBufferSize from config file 
ConfigService.properties


-- 
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-860) Update console fully for Pluto 1.0.1-rc4

2005-08-06 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-860?page=all ]
 
Jeremy Boynes closed GERONIMO-860:
--

Resolution: Fixed

Uploaded the JAR file - that's why two artifacts per project is a bad idea :-(

 Update console fully for Pluto 1.0.1-rc4
 

  Key: GERONIMO-860
  URL: http://issues.apache.org/jira/browse/GERONIMO-860
  Project: Geronimo
 Type: Bug
   Components: console
 Versions: 1.0-M5
 Reporter: Aaron Mulder
 Assignee: Jeremy Boynes
 Priority: Blocker
  Fix For: 1.0-M5


 1) Provide pluto-portal-1.0.1-SNAPSHOT.jar (currently only the WAR is on 
 Jeremy's home dir, but the build wants a JAR built from WEB-INF/classes in 
 the WAR)
 2) Investigate the following message:
 14:31:22,763 WARN  [Servlet] org.apache.pluto.portalImpl.Servlet#init(): 
 Couldn't read property pluto.allowSetBufferSize from config file 
 ConfigService.properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



[jira] Updated: (GERONIMO-861) Investigate warning from Pluto portal

2005-08-06 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-861?page=all ]

Jeremy Boynes updated GERONIMO-861:
---

Description: 
Investigate the following message:

14:31:22,763 WARN  [Servlet] org.apache.pluto.portalImpl.Servlet#init(): 
Couldn't read property pluto.allowSetBufferSize from config file 
ConfigService.properties


  was:
1) Provide pluto-portal-1.0.1-SNAPSHOT.jar (currently only the WAR is on 
Jeremy's home dir, but the build wants a JAR built from WEB-INF/classes in the 
WAR)

2) Investigate the following message:

14:31:22,763 WARN  [Servlet] org.apache.pluto.portalImpl.Servlet#init(): 
Couldn't read property pluto.allowSetBufferSize from config file 
ConfigService.properties


  Assign To: (was: Jeremy Boynes)
   Priority: Major  (was: Blocker)

 Investigate warning from Pluto portal
 -

  Key: GERONIMO-861
  URL: http://issues.apache.org/jira/browse/GERONIMO-861
  Project: Geronimo
 Type: Bug
   Components: console
 Versions: 1.0-M5
 Reporter: Jeremy Boynes
  Fix For: 1.0-M5


 Investigate the following message:
 14:31:22,763 WARN  [Servlet] org.apache.pluto.portalImpl.Servlet#init(): 
 Couldn't read property pluto.allowSetBufferSize from config file 
 ConfigService.properties

-- 
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-857) Console links are incorrect

2005-08-05 Thread Jeremy Boynes (JIRA)
Console links are incorrect
---

 Key: GERONIMO-857
 URL: http://issues.apache.org/jira/browse/GERONIMO-857
 Project: Geronimo
Type: Bug
Versions: 1.0-M5
Reporter: Jeremy Boynes
 Fix For: 1.0-M5


Links on the left hand side of the console have the form:

http://localhost:8080/consolenull/server/server_info

The null in the middle should be /portal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



[jira] Updated: (GERONIMO-857) Console links are incorrect

2005-08-05 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-857?page=all ]

Jeremy Boynes updated GERONIMO-857:
---

Component: console

Assign to console component

 Console links are incorrect
 ---

  Key: GERONIMO-857
  URL: http://issues.apache.org/jira/browse/GERONIMO-857
  Project: Geronimo
 Type: Bug
   Components: console
 Versions: 1.0-M5
 Reporter: Jeremy Boynes
  Fix For: 1.0-M5


 Links on the left hand side of the console have the form:
 http://localhost:8080/consolenull/server/server_info
 The null in the middle should be /portal

-- 
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-848) Deployer ignores Geronimo URL host/port

2005-08-03 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-848?page=comments#action_12317535 
] 

Jeremy Boynes commented on GERONIMO-848:


I thought we just passed the URL down to the JMX connector - do you know if 
this is a problem with the deployer or a problem with MX4J?

 Deployer ignores Geronimo URL host/port
 ---

  Key: GERONIMO-848
  URL: http://issues.apache.org/jira/browse/GERONIMO-848
  Project: Geronimo
 Type: Bug
   Components: deployment
 Versions: 1.0-M4
 Reporter: Aaron Mulder
  Fix For: 1.0-M5


 When the deployer connects to a server, it uses a URL of the form:
 deployer:geronimo:jmx:rmi://host:port/jndi/rmi:/JMXConnector
 Under the covers, this strips off the beginning and uses a connection of the 
 form:
 jmx:rmi://host:port/jndi/rmi:/JMXConnector
 However, no matter what you use as the host and port, it connects to the 
 standard port on localhost.  It should actually attempt to connect to the 
 host and port specified and give an error if they are not valid.

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

2005-07-28 Thread Jeremy Boynes (JIRA)
[ 
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

2005-07-28 Thread Jeremy Boynes (JIRA)
[ 
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



[jira] Created: (GERONIMO-821) Invalid sigantures in JavaMail API jar

2005-07-27 Thread Jeremy Boynes (JIRA)
Invalid sigantures in JavaMail API jar
--

 Key: GERONIMO-821
 URL: http://issues.apache.org/jira/browse/GERONIMO-821
 Project: Geronimo
Type: Bug
  Components: specs  
Versions: 1.0-M4
Reporter: Jeremy Boynes
 Assigned to: Davanum Srinivas 
Priority: Blocker
 Fix For: 1.0-M4


Recent changes to the JavaMail API classes affect the package signatures:

javax.mail.internet.MimeMultipart has an additional public inner class 
MimeBodyPartInputStream

javax.mail.internet.ParameterList has an additional public method 
split(java.lang.String,char)

-- 
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-826) Added support to configure min and max threads to the Jetty Container

2005-07-27 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-826?page=all ]

Jeremy Boynes reassigned GERONIMO-826:
--

Assign To: Jeremy Boynes

 Added support to configure min and max threads to the Jetty Container
 -

  Key: GERONIMO-826
  URL: http://issues.apache.org/jira/browse/GERONIMO-826
  Project: Geronimo
 Type: Improvement
  Environment: All
 Reporter: Matt Hogstrom
 Assignee: Jeremy Boynes
  Attachments: jetty.diff

 The Jetty WebContainer cannot be configured for min and max threads.  Added 
 attributes to the JettyConnector to set min / max threads as well as query 
 threads and idle threads.

-- 
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-254) ServerInfo is too darned useful

2005-07-26 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-254?page=all ]
 
Jeremy Boynes reopened GERONIMO-254:



Reopened as a placeholder until we know what the root cause is. Perhaps then 
we can close this and link to the issue that is fixing that problem.

 ServerInfo is too darned useful
 ---

  Key: GERONIMO-254
  URL: http://issues.apache.org/jira/browse/GERONIMO-254
  Project: Geronimo
 Type: Improvement
   Components: general
 Versions: 1.0-M2
 Reporter: Jeremy Boynes
 Assignee: Dain Sundstrom
 Priority: Minor


 This GBean provides information on the system including the location of the 
 install which is used to find data files. The location itself is transient 
 (so installs can be moved) but needs to be injected early.
 It seems reasonable to have a reference to this available by magic, which 
 means moving it to the kernel.

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

2005-07-23 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-757?page=all ]

Jeremy Boynes reassigned GERONIMO-757:
--

Assign To: Geir Magnusson Jr  (was: Jeremy Boynes)

Geir is going to test with jUDDI 0.9rc4 before upgrading

 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: Geir Magnusson Jr
  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



[jira] Assigned: (GERONIMO-755) Move from Scout (JAXR) version 1.0-SNAPSHOT to a formal version

2005-07-23 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-755?page=all ]

Jeremy Boynes reassigned GERONIMO-755:
--

Assign To: Geir Magnusson Jr  (was: Jeremy Boynes)

After discussion on Scout Dev we think we're ready for a release but Geir is 
going to a final test of HEAD with jUDDI 0.9rc4 before cutting the release. 
Once that is done we will roll the new release into Geronimo

 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: Geir Magnusson Jr
  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] Commented: (GERONIMO-341) Including jdo-spec

2005-07-22 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-341?page=comments#action_12316519 
] 

Jeremy Boynes commented on GERONIMO-341:


This may be available from the Apache JDO project (currently in incubator)

 Including jdo-spec
 --

  Key: GERONIMO-341
  URL: http://issues.apache.org/jira/browse/GERONIMO-341
  Project: Geronimo
 Type: Wish
   Components: specs
 Versions: 1.0-M3
 Reporter: KIKUCHI Kousuke
 Priority: Minor


 I want to include jdo-spec.
 http://access1.sun.com/jdo/

-- 
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-777) Deployment files not removed on Windows

2005-07-22 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-777?page=comments#action_12316557 
] 

Jeremy Boynes commented on GERONIMO-777:


I think an attempt is made to delete them (well most of the time) but can't 
resulting in File.delete() returning false which is ignored. My guess is that 
the URLClassLoader has a lock on the file (as it is treating it as executable) 
which prevents it being deleted; if that is true then something needs to get 
the classloader to shut down and close its files before deleting the temporary 
files/archives. Or we need a different type of classloader that does not lock 
the file.

 Deployment files not removed on Windows
 ---

  Key: GERONIMO-777
  URL: http://issues.apache.org/jira/browse/GERONIMO-777
  Project: Geronimo
 Type: Bug
 Versions: 1.0-M3, 1.0-M4, 1.0-M5
  Environment: Windows
 Reporter: Jeremy Boynes
 Assignee: John Sisson
  Fix For: 1.0


 When running on Windows, deployment leaves behind files and directories in 
 the user's temp directory. Due to the way temp file names are allocated, this 
 can result in deployment failures with an unintuitive AccessDenied 
 IOException. These files cannot be removed without shutting down the server.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



[jira] Created: (GERONIMO-777) Deployment files not removed on Windows

2005-07-18 Thread Jeremy Boynes (JIRA)
Deployment files not removed on Windows
---

 Key: GERONIMO-777
 URL: http://issues.apache.org/jira/browse/GERONIMO-777
 Project: Geronimo
Type: Bug
 Environment: Windows
Reporter: Jeremy Boynes


When running on Windows, deployment leaves behind files and directories in the 
user's temp directory. Due to the way temp file names are allocated, this can 
result in deployment failures with an unintuitive AccessDenied IOException. 
These files cannot be removed without shutting down the server.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



[jira] Created: (GERONIMO-776) Support user-specific properties through an individual property file

2005-07-18 Thread Jeremy Boynes (JIRA)
Support user-specific properties through an individual property file


 Key: GERONIMO-776
 URL: http://issues.apache.org/jira/browse/GERONIMO-776
 Project: Geronimo
Type: New Feature
Reporter: Jeremy Boynes


A user should be able to define their own properties in a secure file probably 
in their home directory. For example, the file 
${user.home}/.geronimo/client.properties could be used to supply the default 
username and password used to connect to a running server, or 
${user.home}/.geronimo/server.properties could contain the password to use for 
opening the server-side keystore.

-- 
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-769) TCL not correct when setting connector properties

2005-07-17 Thread Jeremy Boynes (JIRA)
TCL not correct when setting connector properties
-

 Key: GERONIMO-769
 URL: http://issues.apache.org/jira/browse/GERONIMO-769
 Project: Geronimo
Type: Bug
  Components: connector  
Reporter: Jeremy Boynes
 Assigned to: David Jencks 


I have a connector which has a property that takes a classname. When that 
property's setter is called it attempts to load the class using the TCL and 
gets a ClassNotFoundException even when the class is present in the connector 
and is loadable with Class.forName().

The connector is able to load classes using the TCL when creating managed 
connections.

-- 
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-770) java.lang.IllegalStateException: More then one configuration mananger was found in kernel

2005-07-17 Thread Jeremy Boynes (JIRA)
java.lang.IllegalStateException: More then one configuration mananger was found 
in kernel
-

 Key: GERONIMO-770
 URL: http://issues.apache.org/jira/browse/GERONIMO-770
 Project: Geronimo
Type: Bug
  Components: deployment  
Reporter: Jeremy Boynes


Seems to occur after unsuccessful deployment of an application client. Could be 
that the org/apache/geronimo/Client configuration is left running so that two 
GBeans are present.

Once this occurs, the deployment tools are unable to locate the correct 
configuration manager causing all deployment attempts to fail.

-- 
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-724) Nested transactions do not work correctly

2005-07-07 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-724?page=comments#action_12315214 
] 

Jeremy Boynes commented on GERONIMO-724:


TranQL does contain some logic to order insertions so that FK constraints like 
this are respected. It could be we got over-optimistic on deferring the insert 
until the end of the transaction and this ordering is not being enforced. We 
used to always insert between ejbCreate and ejbPostCreate when defining the 
identity to make sure this was reflected in the database so that FK constraints 
we may not know about still get respected if the application creates entities 
in the right order; however, this often results in two database operations 
(insert on create followed by update on commit) which is not desirable.

I agree that this is more likely related to insert ordering rather than 
transaction demarcation; I think the change when switching from RequiresNew to 
Required is a red herring and it works just because the order in which rows are 
being flushed changes (it is not ordered except by constraint enforcement). At 
least, that's where I'd start looking :-)

 Nested transactions do not work correctly
 -

  Key: GERONIMO-724
  URL: http://issues.apache.org/jira/browse/GERONIMO-724
  Project: Geronimo
 Type: Bug
   Components: transaction manager
 Versions: 1.0-M4
  Environment: Geronimo snapshot built on the 2005/06/30
 Embedded Derby
 Reporter: Ivan Dubrov
 Priority: Critical


 I have the following code in my business logic EJB stateless bean:
 // Create User entity and Account entity
 UserLocal user = userHome.create(group, data);
 AccountLocal account = accountHome.create(user);
 This is the ejbCreate and ejbPostCreate for the Account EJB:
 public Long ejbCreate(UserLocal user) {
 try {
 Long id = new Long(IdGeneratorUtil.getHome().create().generateId());
 setId(id);
 return id;
 } catch (Exception e) {
 throw new EJBException(e);
 }
 }
   
 public void ejbPostCreate(UserLocal user) {
 setUser(user); // Set reference to the User entity
 }
 This is the snippet from the DDL, note that account references the USERS 
 table:
 CREATE TABLE ACCOUNTS (
   ACCOUNT_ID BIGINT NOT NULL PRIMARY KEY,
   USER_ID BIGINT REFERENCES USERS(USER_ID),
...
 );
 The IdGenerator is the standard EJB pattern for generating identifiers - 
 Entity with counter behind Session. I have the following trasnactions 
 attributes (TA):
 All entities (User and Account) have TA = Mandatory.
 Business logic (that creates Users and Accounts) EJB has TA = Required
 IdGenerator EJB have TA = RequiresNew, so the identifier is generated in 
 the nested transaction.
 This should work, since creation of both entities is done in single 
 transaction (that is suspended several times when identifier generation is 
 invoked). So, this transaction contains two database inserts - for User and 
 for Account. Since both rows should be commited at once, the reference in the 
 Account table is satisfied.
 But I get the exception (sometimes, sometimes it just works)). Here is the 
 snippet from it:
 Caused by: SQL Exception: INSERT on table 'ACCOUNTS' caused a violation of 
 foreign key constraint 'SQL050705051513661' for key (72).  The statement has 
 been rolled back.
 at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java)
 at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java)
 It looks like the row into the ACCOUNTS table is inserted (and commited) not 
 in the same transaction as row inserted into the USERS table, and even before 
 the row inserted (and commited) into the USERS.
 If I change transaction attribute for the IdGenerator stateless bean from 
 RequiresNew to Required everything it alway works, so the problem seems like 
 due to the nested transactions (maybe, the Account creation is associated 
 with incorrect transaction)

-- 
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-725) Patch to support new PK Generator syntax

2005-07-07 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-725?page=all ]
 
Jeremy Boynes closed GERONIMO-725:
--

Resolution: Fixed

applied

 Patch to support new PK Generator syntax
 

  Key: GERONIMO-725
  URL: http://issues.apache.org/jira/browse/GERONIMO-725
  Project: Geronimo
 Type: Improvement
   Components: OpenEJB
 Reporter: Aaron Mulder
  Attachments: pkgen.patch

 The new PKGenerator code constructs some PK generators directly instead of 
 using GBeans and delegates.  This patch changes the TranQL EJB class to use 
 the PrimaryKeyGenerator interface instead of the PrimaryKeyGeneratorDelegate 
 class, which means it works for both new and old PKGenerator construction 
 routines.

-- 
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-716) Sun JVM specific argument -XX:MaxPermSize used for JMXConnector system config

2005-07-06 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-716?page=all ]
 
Jeremy Boynes closed GERONIMO-716:
--

Resolution: Fixed

These flags should not be needed here.

Sendingmodules\assembly\maven.xml
Transmitting file data .
Committed revision 209488.

 Sun JVM specific argument -XX:MaxPermSize used for JMXConnector system config
 -

  Key: GERONIMO-716
  URL: http://issues.apache.org/jira/browse/GERONIMO-716
  Project: Geronimo
 Type: Bug
   Components: buildsystem
 Versions: 1.0-M4
  Environment: Windows with IBM JDK 1.4.2 SR2
 Reporter: Donald Woods


 Problem: Build fails when using the IBM JDK 1.4.2 SR2 on a Windows machine, 
 due to the usage of Sun specific JVM flag of -XX:MaxPermSize=128m in 
 modules\assembly\maven.xml at line 374.
 Fix:  Remove usage of the Sun specific JVM cmdline argument of 
 -XX:MaxPermSize from line 374.

-- 
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-718) Assembly Plugin using 1.0-SNAPSHOT

2005-07-06 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-718?page=comments#action_12315179 
] 

Jeremy Boynes commented on GERONIMO-718:


plugins can't extend ../../etc/project.xml as that is not available after 
installation (it is a reference to the source tree)

They need to reference a specific version before being distributed but it needs 
to be defined in the POM for the plugin.

 Assembly Plugin using 1.0-SNAPSHOT
 --

  Key: GERONIMO-718
  URL: http://issues.apache.org/jira/browse/GERONIMO-718
  Project: Geronimo
 Type: Bug
   Components: buildsystem
 Versions: 1.0-M4
  Environment: Clean build
 Reporter: Donald Woods
  Attachments: Geronimo-718.diff

 Problem: Build fails when starting with a clean source tree and Maven 
 repository and not allowing Maven to use previous Geronimo builds, due to 
 plugins/geronimo-assembly-plugin/project.xml using hardcoded version number 
 for geronimo-kernel and geronimo-system of 1.0-SNAPSHOT.  This file will have 
 to be updated either before or right after 1.0 is released, so why not update 
 them now?
 Fix: Update project.xml file to use the default ../../etc/project.xml like 
 the other plugins to pick-up the current Geronimo version and to use that in 
 the geronimo-kernel and geronimo-system dependency.
 Fix Diff -
 Index: project.xml
 ===
 --- project.xml   (revision 209498)
 +++ project.xml   (working copy)
 @@ -20,21 +20,28 @@
  project
  pomVersion3/pomVersion
  groupIdgeronimo/groupId
 +extend../../etc/project.xml/extend
 +
 +!-- = --
 +!-- Module Identification --
 +!-- = --
  idgeronimo-assembly-plugin/id
  nameGeronimo Assembly Plugin/name
  descriptionA plugin used to assemble a distribution of 
 Geronimo/description
 -currentVersionSNAPSHOT/currentVersion
  
 +!--  --
 +!-- Dependencies --
 +!--  --
  dependencies
  dependency
  groupIdgeronimo/groupId
  artifactIdgeronimo-kernel/artifactId
 -version1.0-SNAPSHOT/version
 +version${pom.currentVersion}/version
  /dependency
  dependency
  groupIdgeronimo/groupId
  artifactIdgeronimo-system/artifactId
 -version1.0-SNAPSHOT/version
 +version${pom.currentVersion}/version
  /dependency
  /dependencies

-- 
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-719) external-rar definitions should work for EARs as well as app-clients

2005-07-06 Thread Jeremy Boynes (JIRA)
external-rar definitions should work for EARs as well as app-clients


 Key: GERONIMO-719
 URL: http://issues.apache.org/jira/browse/GERONIMO-719
 Project: Geronimo
Type: New Feature
Reporter: Jeremy Boynes




-- 
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-721) Add jUDDI server

2005-07-06 Thread Jeremy Boynes (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-721?page=comments#action_12315198 
] 

Jeremy Boynes commented on GERONIMO-721:


Added as of r209551
This uses the SystemDatabase default schema and includes the happyjuddi test 
page.
Still need to test with the JAXR client.

 Add jUDDI server
 

  Key: GERONIMO-721
  URL: http://issues.apache.org/jira/browse/GERONIMO-721
  Project: Geronimo
 Type: Improvement
 Reporter: Jeremy Boynes
 Assignee: Jeremy Boynes


 Add a jUDDI server into the default assembly.
 J2EE 1.4. requires that we provide a JAXR client; we should also include a 
 repository server with the assembly

-- 
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-722) Relocate jUDDI tables to their own schema

2005-07-06 Thread Jeremy Boynes (JIRA)
Relocate jUDDI tables to their own schema
-

 Key: GERONIMO-722
 URL: http://issues.apache.org/jira/browse/GERONIMO-722
 Project: Geronimo
Type: Sub-task
Reporter: Jeremy Boynes


The tables for the repositories database currently reside in the default schema.
These should be moved to their own schema (suggestion JUDDI) to avoid conflict 
with future applications.
This may involve creating a new DataSource definition.

-- 
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-723) Allow jUDDI configuration via a GBean

2005-07-06 Thread Jeremy Boynes (JIRA)
Allow jUDDI configuration via a GBean
-

 Key: GERONIMO-723
 URL: http://issues.apache.org/jira/browse/GERONIMO-723
 Project: Geronimo
Type: Sub-task
Reporter: Jeremy Boynes


Currently the jUDDI RegistryEngine is started by servlet contained in the web 
applications and configured by reading juddi.properties
The engine should be converted to a GBean with its properties exposed as 
managed attributes. This will also avoid the need for a startup servlet.

-- 
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-709) Upgrade to Derby 10.1

2005-07-05 Thread Jeremy Boynes (JIRA)
Upgrade to Derby 10.1
-

 Key: GERONIMO-709
 URL: http://issues.apache.org/jira/browse/GERONIMO-709
 Project: Geronimo
Type: Improvement
  Components: general  
Reporter: Jeremy Boynes
 Attachments: derby-10.1.1.0.patch

Upgrade Geronimo to use Derby 10.1 when available

10.1 includes a redistributable client jar as well as the original embedded 
server

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



[jira] Updated: (GERONIMO-709) Upgrade to Derby 10.1

2005-07-05 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-709?page=all ]

Jeremy Boynes updated GERONIMO-709:
---

Attachment: derby-10.1.1.0.patch

Patch to upgrade server to derby 10.1

 Upgrade to Derby 10.1
 -

  Key: GERONIMO-709
  URL: http://issues.apache.org/jira/browse/GERONIMO-709
  Project: Geronimo
 Type: Improvement
   Components: general
 Reporter: Jeremy Boynes
  Attachments: derby-10.1.1.0.patch

 Upgrade Geronimo to use Derby 10.1 when available
 10.1 includes a redistributable client jar as well as the original embedded 
 server

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



[jira] Created: (GERONIMO-712) web deployment fails silently with missing resource ref

2005-07-05 Thread Jeremy Boynes (JIRA)
web deployment fails silently with missing resource ref
---

 Key: GERONIMO-712
 URL: http://issues.apache.org/jira/browse/GERONIMO-712
 Project: Geronimo
Type: Bug
Reporter: Jeremy Boynes


I have a war file that is missing a resource ref

When I distribute this file using java -jar $bin/deployer.jar distribute 
build/foo.war an error is printed out.
However, when I use the deploy option nothing is reported.


-- 
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-701) Can't set listen host/IP for Jetty Connectors

2005-07-04 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-701?page=all ]

Jeremy Boynes reassigned GERONIMO-701:
--

Assign To: Jeremy Boynes

 Can't set listen host/IP for Jetty Connectors
 -

  Key: GERONIMO-701
  URL: http://issues.apache.org/jira/browse/GERONIMO-701
  Project: Geronimo
 Type: Bug
   Components: web
 Versions: 1.0-M3
 Reporter: Aaron Mulder
 Assignee: Jeremy Boynes


 The Jetty network Connector GBeans allow you to set the port but not the 
 listen address (IP or host).  Both should be configurable.  The class that 
 has the port and (read-only) host property is:
 geronimo/modules/jetty/org/apache/geronimo/jetty/connector/JettyConnector
 However it looks like the actual listener is initialized in one of the 
 subclasses
  - HTTPConnector
  - HTTPSConnector
  - AJP13Connector

-- 
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-701) Can't set listen host/IP for Jetty Connectors

2005-07-04 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-701?page=all ]
 
Jeremy Boynes closed GERONIMO-701:
--

Fix Version: 1.0-M4
 Resolution: Fixed

Sending
modules\jetty\src\java\org\apache\geronimo\jetty\connector\JettyConnector.java
Adding modules\jetty\src\test\org\apache\geronimo\jetty\connector
Adding 
modules\jetty\src\test\org\apache\geronimo\jetty\connector\HTTPConnectorTest.java
Transmitting file data ..
Committed revision 209163.

Also added an address attribute for returning the host/port combination

 Can't set listen host/IP for Jetty Connectors
 -

  Key: GERONIMO-701
  URL: http://issues.apache.org/jira/browse/GERONIMO-701
  Project: Geronimo
 Type: Bug
   Components: web
 Versions: 1.0-M3
 Reporter: Aaron Mulder
 Assignee: Jeremy Boynes
  Fix For: 1.0-M4


 The Jetty network Connector GBeans allow you to set the port but not the 
 listen address (IP or host).  Both should be configurable.  The class that 
 has the port and (read-only) host property is:
 geronimo/modules/jetty/org/apache/geronimo/jetty/connector/JettyConnector
 However it looks like the actual listener is initialized in one of the 
 subclasses
  - HTTPConnector
  - HTTPSConnector
  - AJP13Connector

-- 
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-687) j2eeType of ConnectionTracker is JCAResource but strictly it isn't one

2005-06-28 Thread Jeremy Boynes (JIRA)
j2eeType of ConnectionTracker is JCAResource but strictly it isn't one
--

 Key: GERONIMO-687
 URL: http://issues.apache.org/jira/browse/GERONIMO-687
 Project: Geronimo
Type: Bug
  Components: connector  
Reporter: Jeremy Boynes
 Assigned to: Jeremy Boynes 


The j2eeType key for the ConnectionTracker is set to JCAResource but it isn't 
one and does not have the attributes defined by JSR77

-- 
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-687) j2eeType of ConnectionTracker is JCAResource but strictly it isn't one

2005-06-28 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-687?page=all ]
 
Jeremy Boynes closed GERONIMO-687:
--

Resolution: Fixed

Fixed in revision 202303 - concurrent changes to openejb too

 j2eeType of ConnectionTracker is JCAResource but strictly it isn't one
 --

  Key: GERONIMO-687
  URL: http://issues.apache.org/jira/browse/GERONIMO-687
  Project: Geronimo
 Type: Bug
   Components: connector
 Reporter: Jeremy Boynes
 Assignee: Jeremy Boynes


 The j2eeType key for the ConnectionTracker is set to JCAResource but it isn't 
 one and does not have the attributes defined by JSR77

-- 
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-685) Too many open files from CORBA compiler

2005-06-25 Thread Jeremy Boynes (JIRA)
Too many open files from CORBA compiler
---

 Key: GERONIMO-685
 URL: http://issues.apache.org/jira/browse/GERONIMO-685
 Project: Geronimo
Type: Bug
Reporter: Jeremy Boynes
 Assigned to: Dain Sundstrom 


[java] Caused by: org.openejb.corba.compiler.CompilerException: Problem 
creating jar: Too many open files
[java]  at 
org.openejb.corba.compiler.OpenORBSkeletonGenerator.generateSkeletons(OpenORBSkeletonGenerator.java:194)
[java]  at 
org.openejb.corba.compiler.OpenORBSkeletonGenerator$$FastClassByCGLIB$$491f3452.invoke(generated)
[java]  at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
[java]  at 
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
[java]  at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
[java]  at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:719)
[java]  at 
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
[java]  at 
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
[java]  at 
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:94)
[java]  at 
org.openejb.corba.compiler.SkeletonGenerator$$EnhancerByCGLIB$$77cbc8f8.generateSkeletons(generated)
[java]  at 
org.openejb.deployment.OpenEJBModuleBuilder.initContext(OpenEJBModuleBuilder.java:328)

-- 
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-670) Use of undocumented fields with setAccessible

2005-06-10 Thread Jeremy Boynes (JIRA)
Use of undocumented fields with setAccessible
-

 Key: GERONIMO-670
 URL: http://issues.apache.org/jira/browse/GERONIMO-670
 Project: Geronimo
Type: Bug
Reporter: Jeremy Boynes


The classes below use setAccessible to access internal state of VM classes. 
This is likely to lead to non-portable behaviour between JVMs and requires 
dangerous permissions be granted to the server. Other ways of handling this 
should be found.

./modules/interop/src/java/org/apache/geronimo/interop/rmi/iiop/FinalFieldSetterJdk14.java
./modules/interop/src/java/org/apache/geronimo/interop/rmi/iiop/GetField.java
./modules/interop/src/java/org/apache/geronimo/interop/rmi/iiop/PutField.java
./modules/interop/src/java/org/apache/geronimo/interop/rmi/iiop/ValueType.java
./modules/kernel/src/java/org/apache/geronimo/kernel/config/ConfigurationClassLoader.java
./modules/system/src/java/org/apache/geronimo/system/main/ToolsJarHack.java
./modules/system/src/java/org/apache/geronimo/system/url/GeronimoURLFactory.java


-- 
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-644) Serialized form of GBeans objects must each declare SUID

2005-05-15 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-644?page=all ]

Jeremy Boynes reassigned GERONIMO-644:
--

Assign To: Jeremy Boynes

 Serialized form of GBeans objects must each declare SUID
 

  Key: GERONIMO-644
  URL: http://issues.apache.org/jira/browse/GERONIMO-644
  Project: Geronimo
 Type: Bug
 Reporter: Tim Ellison
 Assignee: Jeremy Boynes


 Since Geronimo exchanges config information via serialized form of Java 
 objects, its imperative that the serializable classes declare a 
 serialVersionUID.  If they don't then the serialized form is not necessarily 
 compatible across Java implementations (or even Java compilers) [1].
 The case in point is the wire format classes in ActiveMQ (e.g. 
 org.codehaus.activemq.message.DefaultWireFormat) which are marked 
 serializable and do not declare a static ID.  I've tried raising this with 
 ActiveMQ [2] but without success.
 I can provide the required SUID in each case, but it looks like I might need 
 help to get it into the ActiveMQ code.
 [1] 
 http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html#4100
 [2] http://article.gmane.org/gmane.comp.java.activemq.devel/486

-- 
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-630) Allow for exclusion dependencies

2005-04-14 Thread Jeremy Boynes (JIRA)
Allow for exclusion dependencies


 Key: GERONIMO-630
 URL: http://issues.apache.org/jira/browse/GERONIMO-630
 Project: Geronimo
Type: New Feature
  Components: kernel  
Reporter: Jeremy Boynes
Priority: Minor


Currently a configuration will not start until the thing it depends on. It 
would be useful to add a mechanism that prevented a configuration starting if 
some other configuration or GBean was already running. This could be used to 
prevent two incompatible configurations from running at the same time (for 
example, because they both need exclusive access to some system resource like a 
file or port).

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Assigned: (GERONIMO-616) Wrong package statement for DoubleKeyedHashMap

2005-03-23 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-616?page=history ]

Jeremy Boynes reassigned GERONIMO-616:
--

Assign To: Jeremy Boynes

 Wrong package statement for DoubleKeyedHashMap
 --

  Key: GERONIMO-616
  URL: http://issues.apache.org/jira/browse/GERONIMO-616
  Project: Geronimo
 Type: Bug
   Components: transaction manager
 Reporter: Kristian Koehler
 Assignee: Jeremy Boynes
  Attachments: doubleKey.patch

 the file DoubleKeyedHashMap.java contains a wrong package statement.
 included statement: org.apache.geronimo.transaction
 should be:  org.apache.geronimo.transaction.context
 patch attached

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Commented: (GERONIMO-616) Wrong package statement for DoubleKeyedHashMap

2005-03-23 Thread Jeremy Boynes (JIRA)
 [ 
http://issues.apache.org/jira/browse/GERONIMO-616?page=comments#action_61426 ]
 
Jeremy Boynes commented on GERONIMO-616:


Rather than change the code and risk breaking other things using it I moved the 
source file to the right directory for the package. Once we can confirm that 
this is not used elsewhere we can apply Kristian's patch. I'm leaving this 
issue open until then.

 Wrong package statement for DoubleKeyedHashMap
 --

  Key: GERONIMO-616
  URL: http://issues.apache.org/jira/browse/GERONIMO-616
  Project: Geronimo
 Type: Bug
   Components: transaction manager
 Reporter: Kristian Koehler
 Assignee: Jeremy Boynes
  Attachments: doubleKey.patch

 the file DoubleKeyedHashMap.java contains a wrong package statement.
 included statement: org.apache.geronimo.transaction
 should be:  org.apache.geronimo.transaction.context
 patch attached

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Created: (GERONIMO-614) Deployment user error should not vomit stacktraces

2005-03-21 Thread Jeremy Boynes (JIRA)
Deployment user error should not vomit stacktraces
--

 Key: GERONIMO-614
 URL: http://issues.apache.org/jira/browse/GERONIMO-614
 Project: Geronimo
Type: Improvement
  Components: deployment  
Reporter: Jeremy Boynes


The command line deployer dumps a full stacktrace for some common user error 
conditions (e.g. trying to deploy a RAR without a plan) which is confusing for 
the user. It should just print an appropriate error 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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Commented: (GERONIMO-611) Changes required to Geronimo to work with Log4j 1.3 (alpha-6)

2005-03-17 Thread Jeremy Boynes (JIRA)
 [ 
http://issues.apache.org/jira/browse/GERONIMO-611?page=comments#action_61043 ]
 
Jeremy Boynes commented on GERONIMO-611:


Are you also investigating UGLI?

 Changes required to Geronimo to work with Log4j 1.3 (alpha-6)
 -

  Key: GERONIMO-611
  URL: http://issues.apache.org/jira/browse/GERONIMO-611
  Project: Geronimo
 Type: Task
 Reporter: John Sisson


 Changes are required to Geronimo in the in the 
 org.apache.geronimo.system.logging.log4j package to compile against the 
 upcoming Log4j version 1.3.  In particular, the method of implementing custom 
 PatternLayouts has changed.  See http://www.qos.ch/logging/PatternLayout.jsp 
 I am investigating further.  
 Also see related OpenEJB patch in http://jira.codehaus.org/browse/OPENEJB-20

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Created: (GERONIMO-597) Access failure ,message does not need to log stacktrace

2005-02-27 Thread Jeremy Boynes (JIRA)
Access failure ,message does not need to log stacktrace
---

 Key: GERONIMO-597
 URL: http://issues.apache.org/jira/browse/GERONIMO-597
 Project: Geronimo
Type: Improvement
  Components: OpenEJB  
Reporter: Jeremy Boynes
 Assigned to: Alan Cabrera 
Priority: Minor


EJBSecurityInterceptor currently logs a full stacktrace when it denies access - 
it should just log a warning 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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Created: (GERONIMO-560) MailcapCommandMap.getCommand() should handle wildcards

2005-01-31 Thread Jeremy Boynes (JIRA)
MailcapCommandMap.getCommand() should handle wildcards
--

 Key: GERONIMO-560
 URL: http://issues.apache.org/jira/browse/GERONIMO-560
 Project: Apache Geronimo
Type: Bug
  Components: specs  
Reporter: Jeremy Boynes
 Assigned to: Jeremy Boynes 


The pattern matching for getCommand() is too strict.
RFC1524 allows mailcap files with wildcard mime types e.g.
multipart/related
multipart/*
multipart

I'm not clear on exactly how multiple mappings get resolved but right now we 
match directly which is too strict.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Resolved: (GERONIMO-560) MailcapCommandMap.getCommand() should handle wildcards

2005-01-31 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-560?page=history ]
 
Jeremy Boynes resolved GERONIMO-560:


Resolution: Fixed

Support implicit and explicit wildcards
Also we now strip parameters from the mimeType we are looking up

 MailcapCommandMap.getCommand() should handle wildcards
 --

  Key: GERONIMO-560
  URL: http://issues.apache.org/jira/browse/GERONIMO-560
  Project: Apache Geronimo
 Type: Bug
   Components: specs
 Reporter: Jeremy Boynes
 Assignee: Jeremy Boynes


 The pattern matching for getCommand() is too strict.
 RFC1524 allows mailcap files with wildcard mime types e.g.
 multipart/related
 multipart/*
 multipart
 I'm not clear on exactly how multiple mappings get resolved but right now we 
 match directly which is too strict.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Commented: (GERONIMO-560) MailcapCommandMap.getCommand() should handle wildcards

2005-01-31 Thread Jeremy Boynes (JIRA)
 [ 
http://issues.apache.org/jira/browse/GERONIMO-560?page=comments#action_58337 ]
 
Jeremy Boynes commented on GERONIMO-560:


Fixed rev 149311 and 149312

 MailcapCommandMap.getCommand() should handle wildcards
 --

  Key: GERONIMO-560
  URL: http://issues.apache.org/jira/browse/GERONIMO-560
  Project: Apache Geronimo
 Type: Bug
   Components: specs
 Reporter: Jeremy Boynes
 Assignee: Jeremy Boynes


 The pattern matching for getCommand() is too strict.
 RFC1524 allows mailcap files with wildcard mime types e.g.
 multipart/related
 multipart/*
 multipart
 I'm not clear on exactly how multiple mappings get resolved but right now we 
 match directly which is too strict.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-560) MailcapCommandMap.getCommand() should handle wildcards

2005-01-31 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-560?page=history ]
 
Jeremy Boynes closed GERONIMO-560:
--


Been told it works :-)

 MailcapCommandMap.getCommand() should handle wildcards
 --

  Key: GERONIMO-560
  URL: http://issues.apache.org/jira/browse/GERONIMO-560
  Project: Apache Geronimo
 Type: Bug
   Components: specs
 Reporter: Jeremy Boynes
 Assignee: Jeremy Boynes


 The pattern matching for getCommand() is too strict.
 RFC1524 allows mailcap files with wildcard mime types e.g.
 multipart/related
 multipart/*
 multipart
 I'm not clear on exactly how multiple mappings get resolved but right now we 
 match directly which is too strict.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Assigned: (GERONIMO-540) Unable to login to server when using jdk 1.5

2005-01-20 Thread Jeremy Boynes (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-540?page=history ]

Jeremy Boynes reassigned GERONIMO-540:
--

Assign To: Jeremy Boynes

 Unable to login to server when using jdk 1.5
 

  Key: GERONIMO-540
  URL: http://issues.apache.org/jira/browse/GERONIMO-540
  Project: Apache Geronimo
 Type: Bug
   Components: deployment, security
 Versions: 1.0-M4
  Environment: Windows XP / JDK 1.5
 Reporter: Mark DeLaFranier
 Assignee: Jeremy Boynes
  Attachments: my-changes-to-MBeanServerDelegate.patch

 1. Get the latest codeline (Jan 7/2005)
 2. Do a build
 3. Open a command prompt with JDK 1.5
   java -version
 java version 1.5.0
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
 Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)
 4. Start the server
 java -jar bin\server.jar org/apache/geronimo/RuntimeDeployer 
 org/apache/geronimo/DebugConsole
 5. Open a second command prompt and setup the same jdk 1.5 environment
 6. Deploy a sample EJB (dead simple hello world ejb)
   java -jar bin\deployer.jar deploy myejb.jar
 Username: system
 Password: manager
 Error: Unable to connect to server: Invalid login.
 I didn't notice any exceptions on the server side and nothing new is sent to 
 the console or the server log file.
 If I used jdk 1.4 to start the server and run the client deployment tool then 
 it works.
   java -jar bin\deployer.jar deploy myejb.jar
 Username: system
 Password: manager
 Deployed myejb
 java version 1.4.2_04
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
 Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Assigned: (GERONIMO-533) Removed the TomcatSecureWebAppContext and placed code in TomcatWebAppContext

2004-12-28 Thread Jeremy Boynes (JIRA)
 [ http://nagoya.apache.org/jira/browse/GERONIMO-533?page=history ]

Jeremy Boynes reassigned GERONIMO-533:
--

Assign To: Alan Cabrera

 Removed the TomcatSecureWebAppContext and placed code in TomcatWebAppContext
 

  Key: GERONIMO-533
  URL: http://nagoya.apache.org/jira/browse/GERONIMO-533
  Project: Apache Geronimo
 Type: Improvement
   Components: Tomcat
 Versions: 1.0-M4
  Environment: MacOSX
 Reporter: Jeff Genender
 Assignee: Alan Cabrera
 Priority: Minor
  Attachments: tomcat.diff

 Removed the TomcatSecureWebAppContext and instead placed the security code in 
 TomcatWebAppContext, similarly to Jetty.  Updated the unit tests to reflect 
 this change.  Also changed the TomcatModuleBuilder to use the GbeanData 
 instead of the deprecated GBeanMbean.
 Diff is included below.
 Index: src/test/org/apache/geronimo/tomcat/AbstractWebModuleTest.java
 ===
 --- src/test/org/apache/geronimo/tomcat/AbstractWebModuleTest.java
 (revision 123364)
 +++ src/test/org/apache/geronimo/tomcat/AbstractWebModuleTest.java
 (working copy)
 @@ -132,7 +132,7 @@
  // securityRoles, Map legacySecurityConstraintMap) throws Exception {
  protected ObjectName setUpSecureAppContext(SecurityConstraint[] 
 securityConstraints, String[] securityRoles)
  throws Exception {
 -GBeanData app = new GBeanData(webModuleName, 
 TomcatSecureWebAppContext.GBEAN_INFO);
 +GBeanData app = new GBeanData(webModuleName, 
 TomcatWebAppContext.GBEAN_INFO);
  app.setAttribute(webAppRoot, new 
 File(target/var/catalina/webapps/war3/).toURI());
  app.setAttribute(webClassPath, new URI[] {});
  app.setAttribute(configurationBaseUrl, new 
 File(target/var/catalina/webapps/war3/WEB-INF/web.xml).toURL());
 Index: src/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java
 ===
 --- src/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java   
 (revision 123364)
 +++ src/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java   
 (working copy)
 @@ -38,7 +38,7 @@
  import org.apache.geronimo.deployment.util.DeploymentUtil;
  import org.apache.geronimo.gbean.GBeanInfo;
  import org.apache.geronimo.gbean.GBeanInfoBuilder;
 -import org.apache.geronimo.gbean.jmx.GBeanMBean;
 +import org.apache.geronimo.gbean.GBeanData;
  import org.apache.geronimo.j2ee.deployment.EARContext;
  import org.apache.geronimo.j2ee.deployment.Module;
  import org.apache.geronimo.j2ee.deployment.ModuleBuilder;
 @@ -97,9 +97,9 @@
  throw new DeploymentException(Could not construct module name, 
 e);
  }
  
 -GBeanMBean gbean;
 +GBeanData gbean;
  try {
 -gbean = new GBeanMBean(TomcatWebAppContext.GBEAN_INFO);
 +gbean = new GBeanData(webModuleName, 
 TomcatWebAppContext.GBEAN_INFO);
  
  gbean.setAttribute(webAppRoot, baseUri);
  gbean.setAttribute(webClassPath, webClassPath);
 @@ -110,7 +110,7 @@
  } catch (Exception e) {
  throw new DeploymentException(Unable to initialize webapp 
 GBean, e);
  }
 -earContext.addGBean(webModuleName, gbean);
 +earContext.addGBean(gbean);
  return null;
  }
  
 Index: src/java/org/apache/geronimo/tomcat/TomcatSecureWebAppContext.java
 ===
 --- src/java/org/apache/geronimo/tomcat/TomcatSecureWebAppContext.java
 (revision 123364)
 +++ src/java/org/apache/geronimo/tomcat/TomcatSecureWebAppContext.java
 (working copy)
 @@ -1,142 +0,0 @@
 -/**
 - *
 - * Copyright 2003-2004 The Apache Software Foundation
 - *
 - *  Licensed under the Apache License, Version 2.0 (the License);
 - *  you may not use this file except in compliance with the License.
 - *  You may obtain a copy of the License at
 - *
 - * http://www.apache.org/licenses/LICENSE-2.0
 - *
 - *  Unless required by applicable law or agreed to in writing, software
 - *  distributed under the License is distributed on an AS IS BASIS,
 - *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 - *  See the License for the specific language governing permissions and
 - *  limitations under the License.
 - */
 -package org.apache.geronimo.tomcat;
 -
 -import java.net.URI;
 -import java.net.URL;
 -
 -import org.apache.catalina.Realm;
 -import org.apache.catalina.deploy.LoginConfig;
 -import org.apache.catalina.deploy.SecurityConstraint;
 -import org.apache.commons.logging.Log;
 -import org.apache.commons.logging.LogFactory;
 -
 -import org.apache.geronimo.gbean.GBeanInfo;
 -import org.apache.geronimo.gbean.GBeanInfoBuilder;
 -import 

[jira] Closed: (GERONIMO-530) Test during migration

2004-12-24 Thread Jeremy Boynes (JIRA)
 [ http://issues.eu.apache.org/jira/browse/GERONIMO-530?page=history ]
 
Jeremy Boynes closed GERONIMO-530:
--

Resolution: Invalid

Close of dummy case

 Test during migration
 -

  Key: GERONIMO-530
  URL: http://issues.eu.apache.org/jira/browse/GERONIMO-530
  Project: Apache Geronimo
 Type: Test
   Components: buildsystem
 Reporter: Jeremy Boynes
 Priority: Trivial


 Test during migration

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.eu.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Created: (GERONIMO-530) Migration test - please ignore

2004-12-24 Thread Jeremy Boynes (JIRA)
Migration test - please ignore
--

 Key: GERONIMO-530
 URL: http://nagoya.apache.org/jira/browse/GERONIMO-530
 Project: Apache Geronimo
Type: Test
Reporter: Jeremy Boynes


Opened in real instance to avoid confusion with id

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-530) Migration test - please ignore

2004-12-24 Thread Jeremy Boynes (JIRA)
 [ http://nagoya.apache.org/jira/browse/GERONIMO-530?page=history ]
 
Jeremy Boynes closed GERONIMO-530:
--

Resolution: Invalid

 Migration test - please ignore
 --

  Key: GERONIMO-530
  URL: http://nagoya.apache.org/jira/browse/GERONIMO-530
  Project: Apache Geronimo
 Type: Test
 Reporter: Jeremy Boynes


 Opened in real instance to avoid confusion with id

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Created: (GERONIMO-508) Invalid dd results in No deployer found

2004-12-03 Thread Jeremy Boynes (JIRA)
Invalid dd results in No deployer found
-

 Key: GERONIMO-508
 URL: http://nagoya.apache.org/jira/browse/GERONIMO-508
 Project: Apache Geronimo
Type: Improvement
Reporter: Jeremy Boynes


If the DD for a module is invalid, the deployers disclaim knowledge of the 
module type ultimately resulting in a No deployer found error. The deployer 
should be able to handle this and report I tried to deploy this but the XML is 
invalid instead.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Commented: (GERONIMO-504) dependencies defined by plan are not validated

2004-11-27 Thread Jeremy Boynes (JIRA)
 [ 
http://nagoya.apache.org/jira/browse/GERONIMO-504?page=comments#action_55900 ]
 
Jeremy Boynes commented on GERONIMO-504:


I can see merit in validating during deployment as it would avoid the 
possibility of ClassNotFoundExceptions as we try to create GBean instances. 
However, this means that all dependencies would need to be present during 
deployment whereas in reality they may not actually be needed to deploy the 
module - for example, dependencies could be used to make classes available for 
application use (e.g. struts) but we would not need those to actually create 
the target configuration.

Regardless of whether we check during deployment, the possibility of missing 
dependencies will always exist at configuration start time. For example, 
someone could have removed the dependency from the target server after the 
configuration had been installed.

Given this, I would suggest we fix this by checking dependencies during normal 
deployment but that we also add an option to the deployer that would allow this 
check to be disabled.

 dependencies defined by plan are not validated
 

  Key: GERONIMO-504
  URL: http://nagoya.apache.org/jira/browse/GERONIMO-504
  Project: Apache Geronimo
 Type: Wish
   Components: deployment
 Versions: 1.0-M3, 1.0-M2, 1.0-M1
 Reporter: Gianny DAMOUR
 Priority: Minor


 dependency elements defined by the various deployment plans are not 
 validated. It is possible to deploy successfully plans defining dependencies, 
 which are not defined by the installed repositories.
 When such configurations are started, the Kernel throws as expected a 
 MissingDependencyException identifying the missing dependency.
 This should be done upfront during deployment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-499) JMSException not compliant with JMS 1.1 spec

2004-11-24 Thread Jeremy Boynes (JIRA)
 [ http://nagoya.apache.org/jira/browse/GERONIMO-499?page=history ]
 
Jeremy Boynes closed GERONIMO-499:
--


 JMSException not compliant with JMS 1.1 spec
 

  Key: GERONIMO-499
  URL: http://nagoya.apache.org/jira/browse/GERONIMO-499
  Project: Apache Geronimo
 Type: Bug
   Components: specs
 Reporter: Michael Gaffney
 Priority: Blocker
  Attachments: jms_exception.patch

 The serialized form of Geronimo's javax.jms.JMSException is not compatible 
 with the serialized form of the javax.jms.JMSException defined in the JMS 1.1 
 specification.
 Using the serialver tool I obtained the serialVersionUID for the 
 javax.jms.JMSException class from the three sources.  Here are the sources 
 along with their serialVersionUID values: 
 JMS Spec: serialVersionUID = 8951994251593378324L;
 JBoss   : serialVersionUID = 8951994251593378324L;
 geronimo: serialVersionUID = 2368476267211489441L;
 OK, I know this may seem trivial but while I was working on integrating 
 ActiveMQ with JBoss this problem popped up over and over again.  The problem 
 is that the 'setLinkedException(..)' method needs to be declared 
 'synchronized'.  
 I will attach a patch immediately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Resolved: (GERONIMO-428) Jetty HTTPS Connector doesn't resolve relative keystore path correctly

2004-11-13 Thread Jeremy Boynes (JIRA)
 [ http://nagoya.apache.org/jira/browse/GERONIMO-428?page=history ]
 
Jeremy Boynes resolved GERONIMO-428:


Resolution: Fixed

Added ability to resolve path relative to ServerInfo (base dir) rather than 
current working directory.

 Jetty HTTPS Connector doesn't resolve relative keystore path correctly
 --

  Key: GERONIMO-428
  URL: http://nagoya.apache.org/jira/browse/GERONIMO-428
  Project: Apache Geronimo
 Type: Bug
   Components: web
 Versions: 1.0-M2
 Reporter: Aaron Mulder


 The Jetty HTTPS Connector should resolve the keystore path relative to the 
 base Geronimo directory using a ServerInfo reference, like other things do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-428) Jetty HTTPS Connector doesn't resolve relative keystore path correctly

2004-11-13 Thread Jeremy Boynes (JIRA)
 [ http://nagoya.apache.org/jira/browse/GERONIMO-428?page=history ]
 
Jeremy Boynes closed GERONIMO-428:
--


 Jetty HTTPS Connector doesn't resolve relative keystore path correctly
 --

  Key: GERONIMO-428
  URL: http://nagoya.apache.org/jira/browse/GERONIMO-428
  Project: Apache Geronimo
 Type: Bug
   Components: web
 Versions: 1.0-M2
 Reporter: Aaron Mulder


 The Jetty HTTPS Connector should resolve the keystore path relative to the 
 base Geronimo directory using a ServerInfo reference, like other things do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Created: (GERONIMO-481) HTTPS Connector should work with a keystore GBean

2004-11-13 Thread Jeremy Boynes (JIRA)
HTTPS Connector should work with a keystore GBean
-

 Key: GERONIMO-481
 URL: http://nagoya.apache.org/jira/browse/GERONIMO-481
 Project: Apache Geronimo
Type: Improvement
Reporter: Jeremy Boynes


It currently looks directly at the keystore file.

We should have a GBean manage the certificates just using the file for 
persistence if necessary. The HTTPS connector should then get its certs from 
the GBean.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Created: (GERONIMO-478) Deployer must not echo password when prompting

2004-11-12 Thread Jeremy Boynes (JIRA)
Deployer must not echo password when prompting
--

 Key: GERONIMO-478
 URL: http://nagoya.apache.org/jira/browse/GERONIMO-478
 Project: Apache Geronimo
Type: Bug
  Components: deployment  
Reporter: Jeremy Boynes


When no password is specified on the command line the deployer prompts the user 
for one.
When this is being entered it is echoed onto the screen.

On a windows machine the value entered is also displayed if up-arrow is pressed 
when being prompted.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Commented: (GERONIMO-470) Online deployer locks module file

2004-11-11 Thread Jeremy Boynes (JIRA)
 [ 
http://nagoya.apache.org/jira/browse/GERONIMO-470?page=comments#action_55354 ]
 
Jeremy Boynes commented on GERONIMO-470:


This appears to be because the jar: URL handler locks the file and does not 
release its lock when a stream to one of the entries is closed. So

URL url = new URL(jar: + fileURL.toString() + !/WEB-INF/web.xml);
InputStream is = url.openStream();
// read dd
is.close();

will leave the file locked.

I have not found a way of forcing it to release the lock.

 Online deployer locks module file
 -

  Key: GERONIMO-470
  URL: http://nagoya.apache.org/jira/browse/GERONIMO-470
  Project: Apache Geronimo
 Type: Bug
   Components: deployment
 Reporter: Jeremy Boynes


 If I distribute a war file using the maven plugin and the online deployer, 
 the server locks the input file. The means that a second build of my app 
 fails as maven cannot delete the old war.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



  1   2   >