EWS jar
Srinath, Can you please reduce the size of the EWS jar? i see an extra ews-xmlbeans-DEV.jar and several xsd's (and their xmlbeans generated code which are already in Geronimo). Thanks, dims -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Build failure in Axis module
seems the ews build fail for soem reason and the old ews jar is out of
sync .. Will look in to it now. shall I make the ews depend on axis
rc2?
On Mon, 29 Nov 2004 18:55:01 -0500, Davanum Srinivas [EMAIL PROTECTED] wrote:
That was my nightly build script causing problemsplease try
maven under modules/axis now and let me know if you still have
problems. Sorry for the delay.
-- dims
On Mon, 29 Nov 2004 17:45:22 -0500, Davanum Srinivas [EMAIL PROTECTED]
wrote:
[17:40] dims folks: this is completely weird...i did not change
anything but running maven under modules\axis works fine (after i blow
up .maven/repository/axis and build ews)
[17:41] dims can someone verify this for me? (blow up
.maven/repository/axis and run maven under modules/axis)
-- dims
On Mon, 29 Nov 2004 09:41:14 -0800, Jeremy Boynes [EMAIL PROTECTED] wrote:
Is this an issue or just that EWS is out of sync?
java:compile:
[depend] Deleted 0 out of date files in 0 seconds
[echo] Compiling to
C:\apache\geronimo\trunk\modules\axis/target/classes
[javac] Compiling 10 source files to
C:\apache\geronimo\trunk\modules\axis\t
arget\classes
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:21: cannot find symbol
[javac] symbol : class Ws4J2eeDeployContextImpl
[javac] location: package org.apache.geronimo.ews.ws4j2ee.toWs.impl
[javac] import
org.apache.geronimo.ews.ws4j2ee.toWs.impl.Ws4J2eeDeployContex
tImpl;
[javac] ^
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:26: cannot find symbol
[javac] symbol: class Ws4J2eeDeployContextImpl
[javac] public class GeronimoWsDeployContext extends
Ws4J2eeDeployContextImp
l implements Ws4J2eeDeployContext {
[javac] ^
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:26:
org.apache.geronimo.axis.GeronimoWsDeployCo
ntext is not abstract and does not override abstract method
getModuleLocation()
in org.apache.geronimo.ews.ws4j2ee.toWs.Ws4J2eeDeployContext
[javac] public class GeronimoWsDeployContext extends
Ws4J2eeDeployContextImp
l implements Ws4J2eeDeployContext {
[javac]^
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:81: cannot find symbol
[javac] symbol : variable outputLocation
[javac] location: class
org.apache.geronimo.axis.GeronimoWsDeployContext
[javac] return outputLocation;
[javac]^
[javac] Note: * uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 4 errors
--
Davanum Srinivas - http://webservices.apache.org/~dims/
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Build failure in Axis module
I sync the axis jars versons in the geronimo axis module and the ews,
please cross check the does that fix the build
On Mon, 29 Nov 2004 16:56:39 -0800, Jeremy Boynes [EMAIL PROTECTED] wrote:
It now builds for me - thanks all.
--
Jeremy
Srinath Perera wrote:
seems the ews build fail for soem reason and the old ews jar is out of
sync .. Will look in to it now. shall I make the ews depend on axis
rc2?
On Mon, 29 Nov 2004 18:55:01 -0500, Davanum Srinivas [EMAIL PROTECTED]
wrote:
That was my nightly build script causing problemsplease try
maven under modules/axis now and let me know if you still have
problems. Sorry for the delay.
-- dims
On Mon, 29 Nov 2004 17:45:22 -0500, Davanum Srinivas [EMAIL PROTECTED]
wrote:
[17:40] dims folks: this is completely weird...i did not change
anything but running maven under modules\axis works fine (after i blow
up .maven/repository/axis and build ews)
[17:41] dims can someone verify this for me? (blow up
.maven/repository/axis and run maven under modules/axis)
-- dims
On Mon, 29 Nov 2004 09:41:14 -0800, Jeremy Boynes [EMAIL PROTECTED]
wrote:
Is this an issue or just that EWS is out of sync?
java:compile:
[depend] Deleted 0 out of date files in 0 seconds
[echo] Compiling to
C:\apache\geronimo\trunk\modules\axis/target/classes
[javac] Compiling 10 source files to
C:\apache\geronimo\trunk\modules\axis\t
arget\classes
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:21: cannot find symbol
[javac] symbol : class Ws4J2eeDeployContextImpl
[javac] location: package org.apache.geronimo.ews.ws4j2ee.toWs.impl
[javac] import
org.apache.geronimo.ews.ws4j2ee.toWs.impl.Ws4J2eeDeployContex
tImpl;
[javac] ^
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:26: cannot find symbol
[javac] symbol: class Ws4J2eeDeployContextImpl
[javac] public class GeronimoWsDeployContext extends
Ws4J2eeDeployContextImp
l implements Ws4J2eeDeployContext {
[javac] ^
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:26:
org.apache.geronimo.axis.GeronimoWsDeployCo
ntext is not abstract and does not override abstract method
getModuleLocation()
in org.apache.geronimo.ews.ws4j2ee.toWs.Ws4J2eeDeployContext
[javac] public class GeronimoWsDeployContext extends
Ws4J2eeDeployContextImp
l implements Ws4J2eeDeployContext {
[javac]^
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:81: cannot find symbol
[javac] symbol : variable outputLocation
[javac] location: class
org.apache.geronimo.axis.GeronimoWsDeployContext
[javac] return outputLocation;
[javac]^
[javac] Note: * uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 4 errors
--
Davanum Srinivas - http://webservices.apache.org/~dims/
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Build failure in Axis module
+1 to switch both to Axis-RC2. hop onto #geronimo channel on
irc.freenode.net when you get a chance.
-- dims
On Tue, 30 Nov 2004 06:42:29 +0600, Srinath Perera [EMAIL PROTECTED] wrote:
seems the ews build fail for soem reason and the old ews jar is out of
sync .. Will look in to it now. shall I make the ews depend on axis
rc2?
On Mon, 29 Nov 2004 18:55:01 -0500, Davanum Srinivas [EMAIL PROTECTED]
wrote:
That was my nightly build script causing problemsplease try
maven under modules/axis now and let me know if you still have
problems. Sorry for the delay.
-- dims
On Mon, 29 Nov 2004 17:45:22 -0500, Davanum Srinivas [EMAIL PROTECTED]
wrote:
[17:40] dims folks: this is completely weird...i did not change
anything but running maven under modules\axis works fine (after i blow
up .maven/repository/axis and build ews)
[17:41] dims can someone verify this for me? (blow up
.maven/repository/axis and run maven under modules/axis)
-- dims
On Mon, 29 Nov 2004 09:41:14 -0800, Jeremy Boynes [EMAIL PROTECTED]
wrote:
Is this an issue or just that EWS is out of sync?
java:compile:
[depend] Deleted 0 out of date files in 0 seconds
[echo] Compiling to
C:\apache\geronimo\trunk\modules\axis/target/classes
[javac] Compiling 10 source files to
C:\apache\geronimo\trunk\modules\axis\t
arget\classes
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:21: cannot find symbol
[javac] symbol : class Ws4J2eeDeployContextImpl
[javac] location: package org.apache.geronimo.ews.ws4j2ee.toWs.impl
[javac] import
org.apache.geronimo.ews.ws4j2ee.toWs.impl.Ws4J2eeDeployContex
tImpl;
[javac] ^
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:26: cannot find symbol
[javac] symbol: class Ws4J2eeDeployContextImpl
[javac] public class GeronimoWsDeployContext extends
Ws4J2eeDeployContextImp
l implements Ws4J2eeDeployContext {
[javac] ^
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:26:
org.apache.geronimo.axis.GeronimoWsDeployCo
ntext is not abstract and does not override abstract method
getModuleLocation()
in org.apache.geronimo.ews.ws4j2ee.toWs.Ws4J2eeDeployContext
[javac] public class GeronimoWsDeployContext extends
Ws4J2eeDeployContextImp
l implements Ws4J2eeDeployContext {
[javac]^
[javac]
C:\apache\geronimo\trunk\modules\axis\src\java\org\apache\geronimo\a
xis\GeronimoWsDeployContext.java:81: cannot find symbol
[javac] symbol : variable outputLocation
[javac] location: class
org.apache.geronimo.axis.GeronimoWsDeployContext
[javac] return outputLocation;
[javac]^
[javac] Note: * uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 4 errors
--
Davanum Srinivas - http://webservices.apache.org/~dims/
--
Davanum Srinivas - http://webservices.apache.org/~dims/
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Changes to GBeanInfo classes
Summary: I think we need to change the GBeanInfo classes so the constructors require all data be specified. This means that the GBeanInstance (the implementation class) will not try to figure things out such as accessor names. This change will not break Geronimo, OpenEJB or ActiveMQ, since all of these projects never work directly with the GBeanInfo classes directly. Instead they always work through the GBeanInfoBuilder class. This will break code that is building GBeanInfo objects directly (I don't know of any but there could be some out there). Problems: The lack of information in the GBeanInfo classes is leading to overly complex code. The GBeanInfo classes were originally designed to make it easy for programers to create the info objects by hand (in static code blocks). The classes were designed to take the minimum amount of information necessary to create a GBeanMBean. Information such as an accessor name could be left unspecified, and the GBeanMBean would guess the accessor name based on JavaBean naming conventions. This guessing is itself complex, and does not allow for user supplied algorithms for matching. This lack of information is also carried through the rest of the system. For example, the kernel has a getGBeanInfo method to retrieve the GBean info for any registered GBean. The problem is the GBeanInfo is not fully specified, which make it difficult to write things like a kernel based console and the MEJB (We currently have a pretty ugly hack that makes some of this possible). Solution: Change the GBeanInfo classes to require full specification and move the figure things out code from the GBeanInstance to the GBeanInfoBuilder. Impact: This direct creation of GBeanInfo objects has been discarded over time and has been replaced with the GBeanInfoBuilder class. There are very few classes that construct a GBeanInfo or deal with one directly, and most of those are internal to the Kernel. After checking, Geronimo, ActiveMQ, and OpenEJB, I only found one use of a GAttributeInfo constructor in ActiveMQ, which can trivially be converted to the equivalent GBeanInfoBuilder method. Quoting from above, this change will not break Geronimo, OpenEJB or ActiveMQ... This will break code that is building GBeanInfo objects directly (I don't know of any but there could be some out there). Benefits: GBean implementation becomes a lot less complex. Enables the ability to write more complex GBeanInfoBuilders. Validation of GBeanInfo is much easier, and happens at GBeanInfo creation time instead of when we attempt to instantiate a GBeanInstance. GBean browsers such as MEJB and consoles are much easier to write. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Re: Changes to GBeanInfo classes
+1 I think there is some dynamic attribute builder code in the connector module builder that may need enhancement david jencks On Nov 29, 2004, at 5:43 PM, Dain Sundstrom wrote: Summary: I think we need to change the GBeanInfo classes so the constructors require all data be specified. This means that the GBeanInstance (the implementation class) will not try to figure things out such as accessor names. This change will not break Geronimo, OpenEJB or ActiveMQ, since all of these projects never work directly with the GBeanInfo classes directly. Instead they always work through the GBeanInfoBuilder class. This will break code that is building GBeanInfo objects directly (I don't know of any but there could be some out there). Problems: The lack of information in the GBeanInfo classes is leading to overly complex code. The GBeanInfo classes were originally designed to make it easy for programers to create the info objects by hand (in static code blocks). The classes were designed to take the minimum amount of information necessary to create a GBeanMBean. Information such as an accessor name could be left unspecified, and the GBeanMBean would guess the accessor name based on JavaBean naming conventions. This guessing is itself complex, and does not allow for user supplied algorithms for matching. This lack of information is also carried through the rest of the system. For example, the kernel has a getGBeanInfo method to retrieve the GBean info for any registered GBean. The problem is the GBeanInfo is not fully specified, which make it difficult to write things like a kernel based console and the MEJB (We currently have a pretty ugly hack that makes some of this possible). Solution: Change the GBeanInfo classes to require full specification and move the figure things out code from the GBeanInstance to the GBeanInfoBuilder. Impact: This direct creation of GBeanInfo objects has been discarded over time and has been replaced with the GBeanInfoBuilder class. There are very few classes that construct a GBeanInfo or deal with one directly, and most of those are internal to the Kernel. After checking, Geronimo, ActiveMQ, and OpenEJB, I only found one use of a GAttributeInfo constructor in ActiveMQ, which can trivially be converted to the equivalent GBeanInfoBuilder method. Quoting from above, this change will not break Geronimo, OpenEJB or ActiveMQ... This will break code that is building GBeanInfo objects directly (I don't know of any but there could be some out there). Benefits: GBean implementation becomes a lot less complex. Enables the ability to write more complex GBeanInfoBuilders. Validation of GBeanInfo is much easier, and happens at GBeanInfo creation time instead of when we attempt to instantiate a GBeanInstance. GBean browsers such as MEJB and consoles are much easier to write. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Re: Changes to GBeanInfo classes
On Nov 29, 2004, at 6:00 PM, David Jencks wrote: +1 I think there is some dynamic attribute builder code in the connector module builder that may need enhancement That was one of the first things I checked, and it looks totally clean. -dain
[jira] Assigned: (GERONIMO-195) BLOB support for CMP entity bean
[ http://nagoya.apache.org/jira/browse/GERONIMO-195?page=history ] Gianny DAMOUR reassigned GERONIMO-195: -- Assign To: Gianny DAMOUR BLOB support for CMP entity bean Key: GERONIMO-195 URL: http://nagoya.apache.org/jira/browse/GERONIMO-195 Project: Apache Geronimo Type: Task Components: OpenEJB Versions: 1.0-M1 Reporter: Dain Sundstrom Assignee: Gianny DAMOUR OpenEJB 2.0M1 does not support cmp-fields mapped to BLOB database columns, or storage of generic Serializable objects. -- 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-224) EJB 2.1 Timer support
[ http://nagoya.apache.org/jira/browse/GERONIMO-224?page=comments#action_56037 ] David Jencks commented on GERONIMO-224: --- The ejb timer implementation is based on a generic timer implementation in geronimo, which uses pluggable persistence mechanisms. The default mechanism uses jdbc persistence, using xstream to save the timer info. EJB 2.1 Timer support - Key: GERONIMO-224 URL: http://nagoya.apache.org/jira/browse/GERONIMO-224 Project: Apache Geronimo Type: New Feature Components: OpenEJB Versions: 1.0-M1 Reporter: David Blevins Assignee: David Jencks Fix For: 1.0-M2 EJB 2.1 Timers are not supported or implemented. -- 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] Assigned: (GERONIMO-224) EJB 2.1 Timer support
[ http://nagoya.apache.org/jira/browse/GERONIMO-224?page=history ] David Jencks reassigned GERONIMO-224: - Assign To: David Jencks EJB 2.1 Timer support - Key: GERONIMO-224 URL: http://nagoya.apache.org/jira/browse/GERONIMO-224 Project: Apache Geronimo Type: New Feature Components: OpenEJB Versions: 1.0-M1 Reporter: David Blevins Assignee: David Jencks Fix For: 1.0-M2 EJB 2.1 Timers are not supported or implemented. -- 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-507) ConnectException occurs after MDB deployment and server restart. MDB deploying before Broker
ConnectException occurs after MDB deployment and server restart. MDB deploying before Broker - Key: GERONIMO-507 URL: http://nagoya.apache.org/jira/browse/GERONIMO-507 Project: Apache Geronimo Type: Bug Components: ActiveMQ Versions: 1.0-M3 Reporter: Hiram Chirino Assigned to: Hiram Chirino MDB deploys fine to the server. Server is restarted and you get the following error: 14:30:17,048 WARN [GBeanSingleReference] Exception occured while attempting to fully start: objectName=geronimo.server:EJBModule=activemq-itest-ejb-1.3-SNAPSHOT.jar,J2EEAppli Could not start the endpoint. at org.codehaus.activemq.ra.ActiveMQAsfEndpointWorker.start(ActiveMQAsfEndpointWorker.java:98) at org.codehaus.activemq.ra.ActiveMQResourceAdapter.endpointActivation(ActiveMQResourceAdapter.java:179) at org.apache.geronimo.connector.ResourceAdapterWrapper.endpointActivation(ResourceAdapterWrapper.java:96) at org.apache.geronimo.connector.ResourceAdapterWrapper$$FastClassByCGLIB$$4ab28e73.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) ... at org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:423) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:150) Caused by: javax.jms.JMSException: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused: connect at org.codehaus.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.codehaus.activemq.transport.tcp.TcpTransportChannel.init(TcpTransportChannel.java:102) at org.codehaus.activemq.transport.tcp.TcpTransportChannelFactory.create(TcpTransportChannelFactory.java:43) ... at org.codehaus.activemq.ra.ActiveMQBaseEndpointWorker.getPhysicalConnection(ActiveMQBaseEndpointWorker.java:117) at org.codehaus.activemq.ra.ActiveMQAsfEndpointWorker.start(ActiveMQAsfEndpointWorker.java:90) ... 76 more Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) ... at java.net.Socket.init(Socket.java:178) at org.codehaus.activemq.transport.tcp.TcpTransportChannel.createSocket(TcpTransportChannel.java:472) at org.codehaus.activemq.transport.tcp.TcpTransportChannel.init(TcpTransportChannel.java:98) It seems like the MDB is being deployed before the ActiveMQ broker is up and running. Since the message Broker is a remote resource that may be up or down, the Resource Adapter should support automatic recovery and should show a sincer error message when the message broker is down. -- 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
Re: GBeans, Kernel and JMX Exceptions
This was getting in my way, so I finished the work. All code should be updated an checked in. I didn't add type specific arguments to the classes, such as ObjectName, attribute name, operation signature, so if someone wants to take a stab at that please do. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 On Nov 24, 2004, at 10:39 AM, Dain Sundstrom wrote: One of the last areas of tight coupling to JMX in the Geronimo kernel and the GBean architecture is the use of JMX Exceptions. These the exceptions are normally not declared as part of the interface, but are thrown from the methods that declare throws Exception. I propose that we catch all JMX exceptions and convert them to the following Geronimo specific exceptions: KernelException - Base class for the following exceptions. Direct subclass of Exception. GBeanNotFoundException - Thrown from getAttribute, setAttribute, invoke, getGBeanInfo, getClassLoaderFor, startGBean, startRecursiveGBean, stopGBean, and unloadGBean. This replaces javax.management.InstanceNotFoundException. GBeanAlreadyExistsException - Thrown from loadGBean. This replaces javax.management.InstanceAlreadyExistsException. InvalidGBeanException - Thrown from loadGBean. This is used instead of javax.management.NotCompliantMBeanException. NoSuchAttributeException - Thrown from getAttribute and setAttribute. This replaces javax.management.AttributeNotFoundException NoSuchOperationException - Thrown from invoke. There is no equivalent exception in JMX. InternalKernelException - Extend runtime exception. Thrown from all methods on kernel. This exception will contain any java.lang.Exception (and for the improbable case of direct subclass of java.lang.Throwable) thrown from the kernel or gbean architecture itself. This allows callers to differentiate between kernel problems and exceptions from the GBean instance implementation. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
