[jira] Created: (GERONIMO-611) Changes required to Geronimo to work with Log4j 1.3 (alpha-6)
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] Commented: (GERONIMO-611) Changes required to Geronimo to work with Log4j 1.3 (alpha-6)
[ 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] Commented: (GERONIMO-611) Changes required to Geronimo to work with Log4j 1.3 (alpha-6)
[ http://issues.apache.org/jira/browse/GERONIMO-611?page=comments#action_61046 ] John Sisson commented on GERONIMO-611: -- After reading the heated exchanges in http://issues.apache.org/bugzilla/show_bug.cgi?id=33143 , the comments regarding UGLI and commons-logging, I didn't know where things are heading. I thought I'd leave that as a separate task (shall we raise another issue to discuss it). Something as simple as logging has got so complicated these days.. 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] Commented: (GERONIMO-609) geronimo.log can be closed whilst distributing an EAR if the application uses log4j
[ http://issues.apache.org/jira/browse/GERONIMO-609?page=comments#action_61047 ] John Sisson commented on GERONIMO-609: -- Sorry, I was thinking of Servlet classloading, not standard classloading. I am at a bit of a loss as to how to solve this problem. I am hoping that the ContextJNDISelector in Log4j 1.3 may be a solution for EJB applications that read their own log4j configuration files, so they can do so without clobbering Geronimo's logging configurations ( http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/selector/ContextJNDISelector.java?hideattic=0 ). See the article http://www.qos.ch/logging/sc.jsp for some background info on Log4j repository selectors. FYI.. The ContextJNDISelector class has been moved from the log4j sandbox to log4j proper for the 1.3 release. The ContextClassLoaderSelector class that was in the log4j sandbox was retired because there was concern that it would cause headaches based upon classloader particularities. I have opened another issue for changes required for Log4j 1.3 ( http://issues.apache.org/jira/browse/GERONIMO-611 ). geronimo.log can be closed whilst distributing an EAR if the application uses log4j --- Key: GERONIMO-609 URL: http://issues.apache.org/jira/browse/GERONIMO-609 Project: Geronimo Type: Bug Components: deployment Reporter: John Sisson The following stack trace shows the geronimo.log file being closed as a result of static code being executed in a session bean whilst the configuration is being stored. The EAR has a geronimo-application.xml file that contains a dependencies element that adds log4j as a dependency, to ensure the application (when it initialises its logging) does not interfere with geronimo's logging. Well, that was the plan, but I wasn't expecting to see the application's code being executed without using the dependencies it was configured with. Here is the stack trace: System Thread [RMI TCP Connection(7)-172.21.35.170] (Suspended (breakpoint at line 171 in org.apache.log4j.FileAppender)) org.apache.log4j.RollingFileAppender(org.apache.log4j.FileAppender).closeFile() line: 171 org.apache.log4j.RollingFileAppender(org.apache.log4j.FileAppender).reset() line: 302 org.apache.log4j.RollingFileAppender(org.apache.log4j.WriterAppender).close() line: 195 org.apache.log4j.helpers.AppenderAttachableImpl.removeAllAppenders() line: 132 org.apache.log4j.spi.RootCategory(org.apache.log4j.Category).removeAllAppenders() line: 879 org.apache.log4j.PropertyConfigurator.parseCategory(java.util.Properties, org.apache.log4j.Logger, java.lang.String, java.lang.String, java.lang.String) line: 594 org.apache.log4j.PropertyConfigurator.configureRootCategory(java.util.Properties, org.apache.log4j.spi.LoggerRepository) line: 500 org.apache.log4j.PropertyConfigurator.doConfigure(java.util.Properties, org.apache.log4j.spi.LoggerRepository) line: 406 org.apache.log4j.PropertyConfigurator.configure(java.util.Properties) line: 340 snip - application code com.blah.server.ejb.ServerConfigPvtBean.clinit() line: 93 java.io.ObjectStreamClass.hasStaticInitializer(java.lang.Class) line: not available [native method] java.io.ObjectStreamClass.computeDefaultSUID(java.lang.Class) line: 1557 java.io.ObjectStreamClass.access$100(java.lang.Class) line: 47 java.io.ObjectStreamClass$1.run() line: 173 java.security.AccessController.doPrivileged(java.security.PrivilegedAction) line: not available [native method] java.io.ObjectStreamClass.getSerialVersionUID() line: 170 java.io.ObjectStreamClass.writeNonProxy(java.io.ObjectOutputStream) line: 557 java.io.ObjectOutputStream.writeClassDescriptor(java.io.ObjectStreamClass) line: 591 java.io.ObjectOutputStream.writeNonProxyDesc(java.io.ObjectStreamClass, boolean) line: 1142 java.io.ObjectOutputStream.writeClassDesc(java.io.ObjectStreamClass, boolean) line: 1100 java.io.ObjectOutputStream.writeClass(java.lang.Class, boolean) line: 1082 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 996 java.io.ObjectOutputStream.defaultWriteFields(java.lang.Object, java.io.ObjectStreamClass) line: 1332 java.io.ObjectOutputStream.writeSerialData(java.lang.Object, java.io.ObjectStreamClass) line: 1304 java.io.ObjectOutputStream.writeOrdinaryObject(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1247 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 1052 java.io.ObjectOutputStream.writeArray(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1224
Re: Change to AxisWebServiceContainer class in axis module?
Yap, Dims and David .. I will move the TestCase to the axis-builder Just a random thought .. the AxisWebServiceContainer not work with just any SOAPService and expect certain value to be set. Since the normal user do not see this details it is not critical. but it does not live up to the expecations one get whn he look at the method signatures. And when I tried with the most natural way to get a SOAPService (by parsing axis DD, deploy.wsdd) and run the AxisWebServiceContainer with that SOAP service it failed with NullPointers Any chance to fix it ? thanks Srinath On Wed, 16 Mar 2005 10:35:49 -0600, David Blevins [EMAIL PROTECTED] wrote: On Wed, Mar 16, 2005 at 08:14:47PM +0600, Srinath Perera wrote: Hi All; I wrote a TestCase for axis module and checked it in. But the soap invocation fails and send back a SOAPFault. This can be fixed by changing the line 63 of AxisWebServiceContainer org.apache.axis.MessageContext context = new org.apache.axis.MessageContext(null); to org.apache.axis.MessageContext context = new org.apache.axis.MessageContext(new AxisServer()); I do not do the change yet .. I remeber David Blevins mentioned he do the code without AxisEngine, not sure will it couse trouble thoughts? Hi Srinath, Thanks for the test case, looks like a great start. Your problem with the axis engine will go away if you use the AxisServiceBuilder to build the JavaServiceDesc instead of building it by hand in the test case. Since maven doesn't like circular dependencies, you'll probably have to move the test case to the axis-builder module to get that to compile. -David
Re: Change to AxisWebServiceContainer class in axis module?
On Thu, Mar 17, 2005 at 07:45:54AM +0600, Srinath Perera wrote: Yap, Dims and David .. I will move the TestCase to the axis-builder Cool. I have some pending changes, so it may fail in the meantime. If it does, just hang tight till I can get things checked in. Just a random thought .. the AxisWebServiceContainer not work with just any SOAPService and expect certain value to be set. Since the normal user do not see this details it is not critical. but it does not live up to the expecations one get whn he look at the method signatures. Not sure what you mean exactly. And when I tried with the most natural way to get a SOAPService (by parsing axis DD, deploy.wsdd) and run the AxisWebServiceContainer with that SOAP service it failed with NullPointers Any chance to fix it ? Well, we are purposely not letting Axis do some of the things it likes to do at runtime, like fill in extra data into your FooDesc objects. The WSDD file isn't as detailed as a jaxrpc mapping file and Axis will typically fill in the required detail at runtime using fairly intuitive algorithms. One example is that the WSDD file isn't able to say what method goes with an operation, so Axis will fill that in at runtime in a synchronized block the first time the service is invoked. After that, you still hit the synchronized block on every call, albeit just long enough to see that the initialized flag is true and return. We have all this detail up front and configure our JavaServiceDesc objects with more information than the WSDD stuff does and we very intentionally do not want Axis changing anything at runtime. We actually have code to stop Axis from doing some of it's usual guess work. -David thanks Srinath On Wed, 16 Mar 2005 10:35:49 -0600, David Blevins [EMAIL PROTECTED] wrote: On Wed, Mar 16, 2005 at 08:14:47PM +0600, Srinath Perera wrote: Hi All; I wrote a TestCase for axis module and checked it in. But the soap invocation fails and send back a SOAPFault. This can be fixed by changing the line 63 of AxisWebServiceContainer org.apache.axis.MessageContext context = new org.apache.axis.MessageContext(null); to org.apache.axis.MessageContext context = new org.apache.axis.MessageContext(new AxisServer()); I do not do the change yet .. I remeber David Blevins mentioned he do the code without AxisEngine, not sure will it couse trouble thoughts? Hi Srinath, Thanks for the test case, looks like a great start. Your problem with the axis engine will go away if you use the AxisServiceBuilder to build the JavaServiceDesc instead of building it by hand in the test case. Since maven doesn't like circular dependencies, you'll probably have to move the test case to the axis-builder module to get that to compile. -David
Re: Change to AxisWebServiceContainer class in axis module?
I have some pending changes, so it may fail in the meantime. If it does, just hang tight till I can get things checked in. cool And when I tried with the most natural way to get a SOAPService (by parsing axis DD, deploy.wsdd) and run the AxisWebServiceContainer with that SOAP service it failed with NullPointers Any chance to fix it ? Well, we are purposely not letting Axis do some of the things it likes to do at runtime, like fill in extra data into your FooDesc objects. The WSDD file isn't as detailed as a jaxrpc mapping file and Axis will typically fill in the required detail at runtime using fairly intuitive algorithms. One example is that the WSDD file isn't able to say what method goes with an operation, so Axis will fill that in at runtime in a synchronized block the first time the service is invoked. After that, you still hit the synchronized block on every call, albeit just long enough to see that the initialized flag is true and return. We have all this detail up front and configure our JavaServiceDesc objects with more information than the WSDD stuff does and we very intentionally do not want Axis changing anything at runtime. We actually have code to stop Axis from doing some of it's usual guess work. cool, that mean we are working on the WSDL and mapping files direct. understood the problem and why you give that solution :) Thanks Srinath
activemq
Hello, I just noticed that ActiveMQ moved from CVS to SVN. So I looked at geronimo's latest maven.xml and ActiveMQ checkout has been removed. So, I just wanted to know whether we just depend on the ActiveMQ jar file instead of building ActiveMQ. Thanks much! -Hari
Re: activemq
That is correct. The combined build of geronimo, openejb, and tranql is actually a rather bad idea although IMO required by the current module structure. I've been hoping for several months that we could move to a more sensible comprehensive build system but it may still not happen for some time. thanks david jencks On Mar 16, 2005, at 8:40 PM, Hari Kodungallur wrote: Hello, I just noticed that ActiveMQ moved from CVS to SVN. So I looked at geronimo's latest maven.xml and ActiveMQ checkout has been removed. So, I just wanted to know whether we just depend on the ActiveMQ jar file instead of building ActiveMQ. Thanks much! -Hari
[jira] Created: (GERONIMO-612) OpenORBStubClassLoader needs to track parent cl
OpenORBStubClassLoader needs to track parent cl --- Key: GERONIMO-612 URL: http://issues.apache.org/jira/browse/GERONIMO-612 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M3 Reporter: David Jencks Fix For: 1.0-M4 OpenORBStubClassloader currently only tracks stub classloader by name of stub class. If the interface is loaded by several different classloaders then each call will load the requested class with the same stub classloader, which is wrong for all but the first call. One solution is to track generated class jars by class name, and stub classloaders by parent classloader and class name. This always returns the same stub class for a given class name and parent classloader (assumed to be the TCCL). -- 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-612) OpenORBStubClassLoader needs to track parent cl
[ http://issues.apache.org/jira/browse/GERONIMO-612?page=history ] David Jencks closed GERONIMO-612: - Resolution: Fixed Fix Version: 1.0-M4 fixed. Openejb doesn't have revision numbers. Could use review. I think this class has a memory leak, perhaps we should use weak hashmaps. OpenORBStubClassLoader needs to track parent cl --- Key: GERONIMO-612 URL: http://issues.apache.org/jira/browse/GERONIMO-612 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M3 Reporter: David Jencks Fix For: 1.0-M4 OpenORBStubClassloader currently only tracks stub classloader by name of stub class. If the interface is loaded by several different classloaders then each call will load the requested class with the same stub classloader, which is wrong for all but the first call. One solution is to track generated class jars by class name, and stub classloaders by parent classloader and class name. This always returns the same stub class for a given class name and parent classloader (assumed to be the TCCL). -- 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
Re: activemq
Yes...we will depend on the jar. Jeff Hari Kodungallur wrote: Hello, I just noticed that ActiveMQ moved from CVS to SVN. So I looked at geronimo's latest maven.xml and ActiveMQ checkout has been removed. So, I just wanted to know whether we just depend on the ActiveMQ jar file instead of building ActiveMQ. Thanks much! -Hari
