[jira] Commented: (SM-847) Old version of xml-apis in distribution
[ https://issues.apache.org/activemq/browse/SM-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38539 ] Guillaume Nodet commented on SM-847: Is this is a problem for JDK 1.4 compat ? If yes, it should also be fixed in 3.1.1 imo. Old version of xml-apis in distribution --- Key: SM-847 URL: https://issues.apache.org/activemq/browse/SM-847 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Fix For: 3.2 In the ServiceMix 3.1 distribution (lib folder) a very old version (1.0b2) of xml-apis is included. Replace it with version 1.3.03 or higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-846) Call to default constructor of JBIContainer changes log4j log level
[ https://issues.apache.org/activemq/browse/SM-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38541 ] Guillaume Nodet commented on SM-846: Philip, Is the IdGenerator the only issue ? I still don't understand why / how servicemix could change the log4j level ... What's the way to reproduce the problem ? Call to default constructor of JBIContainer changes log4j log level --- Key: SM-846 URL: https://issues.apache.org/activemq/browse/SM-846 Project: ServiceMix Issue Type: Bug Affects Versions: 3.0 Environment: Windows XP Professional, java version 1.5.0_09, JUnit 4.1 Reporter: Philipp Rossmanith Priority: Minor A call to the default constructor of org.apache.servicemix.jbi.container.JBIContainer sets the log4j log level to ERROR. See http://www.nabble.com/Default-constructor-for-JBIContainer-changes-log-level--tf3235243s12049.html Can be observed in org.apache.servicemix.jbi.security.SecuredBrokerTest, line 63: jbi = new JBIContainer(); JBIContainer doesn't seem to use org.apache.log4j, but makes calls to org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory: private static final Log log = LogFactory.getLog(JBIContainer.class); ... as well as to java.util.logging.Logger: public Logger getLogger(String suffix, String resourceBundleName) throws MissingResourceException, JBIException commons-logging is configured in ServiceMix. Which in turns, starts log4j if included in the classpath. It seems that org.apache.servicemix.id.IdGenerator calls the java.util.logging package. This is the only call afaik and it should be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-847) Old version of xml-apis in distribution
[ https://issues.apache.org/activemq/browse/SM-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-847. Resolution: Fixed Fix Version/s: 3.1.1 Assignee: Guillaume Nodet URL: http://svn.apache.org/viewvc?view=revrev=508539 URL: http://svn.apache.org/viewvc?view=revrev=508540 Old version of xml-apis in distribution --- Key: SM-847 URL: https://issues.apache.org/activemq/browse/SM-847 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 In the ServiceMix 3.1 distribution (lib folder) a very old version (1.0b2) of xml-apis is included. Replace it with version 1.3.03 or higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-850) Error starting ServiceMix on AIX
[ https://issues.apache.org/activemq/browse/SM-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen updated SM-850: --- Attachment: SM-850.patch Error starting ServiceMix on AIX Key: SM-850 URL: https://issues.apache.org/activemq/browse/SM-850 Project: ServiceMix Issue Type: Bug Components: servicemix-core Affects Versions: 3.1 Reporter: Gert Vanthienen Fix For: 3.1.1 Attachments: SM-850.patch After adding support for OS/400 to ServiceMix's startup script, the script no longer worked correctly for AIX. See also: http://www.nabble.com/Can%27t-start-on-aix-tf3056948s12049.html#a8985397 (sorry, mail-archives.apache.org seems to be down for the moment) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-850) Error starting ServiceMix on AIX
[ https://issues.apache.org/activemq/browse/SM-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38543 ] Gert Vanthienen commented on SM-850: The current script doesn't work correctly on AIX because: - the JVM on AIX was not correctly identified as an IBM JVM - the option -Xverify:none was not set for AIX, while it is required This patch file contains a fix for the startup script to solve both problems. Error starting ServiceMix on AIX Key: SM-850 URL: https://issues.apache.org/activemq/browse/SM-850 Project: ServiceMix Issue Type: Bug Components: servicemix-core Affects Versions: 3.1 Reporter: Gert Vanthienen Fix For: 3.1.1 Attachments: SM-850.patch After adding support for OS/400 to ServiceMix's startup script, the script no longer worked correctly for AIX. See also: http://www.nabble.com/Can%27t-start-on-aix-tf3056948s12049.html#a8985397 (sorry, mail-archives.apache.org seems to be down for the moment) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-848) ServiceMix 3.x with Java 1.4.x
[ https://issues.apache.org/activemq/browse/SM-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SM-848: --- Fix Version/s: (was: 3.2) 3.1.1 ServiceMix 3.x with Java 1.4.x -- Key: SM-848 URL: https://issues.apache.org/activemq/browse/SM-848 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.1 Environment: Java Runtime Environment 1.4.x Reporter: Juergen Mayrbaeurl Fix For: 3.1.1 Since ServiceMix 3.1 can only be used with Java 5 or higher, rework it to make it Java 1.4.x compatible -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-846) Call to default constructor of JBIContainer changes log4j log level
[ https://issues.apache.org/activemq/browse/SM-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-846. Resolution: Fixed Fix Version/s: 3.2 3.1.1 Assignee: Guillaume Nodet URL: http://svn.apache.org/viewvc?view=revrev=508541 URL: http://svn.apache.org/viewvc?view=revrev=508544 Call to default constructor of JBIContainer changes log4j log level --- Key: SM-846 URL: https://issues.apache.org/activemq/browse/SM-846 Project: ServiceMix Issue Type: Bug Affects Versions: 3.0 Environment: Windows XP Professional, java version 1.5.0_09, JUnit 4.1 Reporter: Philipp Rossmanith Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.1.1, 3.2 A call to the default constructor of org.apache.servicemix.jbi.container.JBIContainer sets the log4j log level to ERROR. See http://www.nabble.com/Default-constructor-for-JBIContainer-changes-log-level--tf3235243s12049.html Can be observed in org.apache.servicemix.jbi.security.SecuredBrokerTest, line 63: jbi = new JBIContainer(); JBIContainer doesn't seem to use org.apache.log4j, but makes calls to org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory: private static final Log log = LogFactory.getLog(JBIContainer.class); ... as well as to java.util.logging.Logger: public Logger getLogger(String suffix, String resourceBundleName) throws MissingResourceException, JBIException commons-logging is configured in ServiceMix. Which in turns, starts log4j if included in the classpath. It seems that org.apache.servicemix.id.IdGenerator calls the java.util.logging package. This is the only call afaik and it should be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-850) Error starting ServiceMix on AIX
[ https://issues.apache.org/activemq/browse/SM-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-850. Resolution: Fixed Fix Version/s: 3.2 Assignee: Guillaume Nodet Thanks a lot Gert to have taken care of that :-) URL: http://svn.apache.org/viewvc?view=revrev=508547 URL: http://svn.apache.org/viewvc?view=revrev=508550 Error starting ServiceMix on AIX Key: SM-850 URL: https://issues.apache.org/activemq/browse/SM-850 Project: ServiceMix Issue Type: Bug Components: servicemix-core Affects Versions: 3.1 Reporter: Gert Vanthienen Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 Attachments: SM-850.patch After adding support for OS/400 to ServiceMix's startup script, the script no longer worked correctly for AIX. See also: http://www.nabble.com/Can%27t-start-on-aix-tf3056948s12049.html#a8985397 (sorry, mail-archives.apache.org seems to be down for the moment) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Useing shared libraries from service units
Hi Juergen and all ! Starting this thread on dev list ... Not sure exactly what the best way would be, but I see several ways: * enhance the classpath / feature to reference SL somehow * use the jbi descriptor somehow, as done for components I haven't thought about it a lot yet. So any idea is welcome ... -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
[jira] Updated: (GERONIMO-2842) Geronimo Axis2 - JAXWS Web Services are not working for WSDL provided situation
[ https://issues.apache.org/jira/browse/GERONIMO-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lasantha Ranaweera updated GERONIMO-2842: - Attachment: GERONIMO-2842-2.patch Please ignore the patch number 1. Now wsdlDefinition has been removed from GBean level put it to the PortInfo class. It allows us to provide more than one WSDL in an archive. Thanks again to Jarek correcting me here :). Geronimo Axis2 - JAXWS Web Services are not working for WSDL provided situation --- Key: GERONIMO-2842 URL: https://issues.apache.org/jira/browse/GERONIMO-2842 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Lasantha Ranaweera Attachments: GERONIMO-2842-2.patch, GERONIMO-2842.patch JAXWS webservices are not working in WSDL provided situation. This has been working for a previous release missing right now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Default constructor for JBIContainer changes log level?
Japp, will do. Ciao, Philipp Rossmanith -Mensaje original- De: Guillaume Nodet [mailto:[EMAIL PROTECTED] Enviado el: jueves, 15 de febrero de 2007 19:57 Para: servicemix-dev@geronimo.apache.org Asunto: Re: Default constructor for JBIContainer changes log level? Sure, commons-logging is configured. Which in turns, starts log4j if included in the classpath. By default, log4j will load a log4j.properties file ... And you're right. It seems that o.a.s.id.IdGenerator calls the java.util.logging package. This is the only call afaik and it should be removed. Can you raise a JIRA for that ? On 2/15/07, Rossmanith, Philipp [EMAIL PROTECTED] wrote: P.s. JBIContainer doesn't seem to use org.apache.log4j, but makes calls to org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory: private static final Log log = LogFactory.getLog(JBIContainer.class); ... as well as to java.util.logging.Logger: public Logger getLogger(String suffix, String resourceBundleName) throws MissingResourceException, JBIException Ciao, Philipp Rossmanith This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/ This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
Re: [PROPOSAL] Coding standards
+1 On 2/15/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I propose the following coding standards (taken from the Geronimo web site) which are actually the most common in ServiceMix code base: http://cwiki.apache.org/SM/coding-standards.html Does anyone want to modify / add / change something ? -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/ -- James --- http://radio.weblogs.com/0112098/
[jira] Resolved: (SM-420) Setting maximum memory
[ https://issues.apache.org/activemq/browse/SM-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-420. Resolution: Fixed Fix Version/s: 3.2 Assignee: Guillaume Nodet URL: http://svn.apache.org/viewvc?view=revrev=508352 Setting maximum memory -- Key: SM-420 URL: https://issues.apache.org/activemq/browse/SM-420 Project: ServiceMix Issue Type: New Feature Reporter: Mike Gerdes Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.2 Attachments: smx420_java_mem.patch It should be possible to set the maximum memory that is available for ServiceMix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (XBEAN-75) xbean-spring depends on JDK 5
xbean-spring depends on JDK 5 - Key: XBEAN-75 URL: https://issues.apache.org/jira/browse/XBEAN-75 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.8 Reporter: Guillaume Nodet Starting Apache ServiceMix ESB: 3.1-incubating Loading Apache ServiceMix from servicemix.xml on the CLASSPATH Caught: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpect ed exception parsing XML document from class path resource [jmx.xml]; nested exc eption is java.lang.NoSuchMethodError: java.lang.IllegalStateException: method init(Ljava/lang/String;Ljava/lang/Throwable;)V not found org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected excep tion parsing XML document from class path resource [jmx.xml]; nested exception i s java.lang.NoSuchMethodError: java.lang.IllegalStateException: method init(Lj ava/lang/String;Ljava/lang/Throwable;)V not found Caused by: java.lang.NoSuchMethodError: java.lang.IllegalStateException: method init(Ljava/lang/String;Ljava/lang/Throwable;)V not found at org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate .internalParseNestedCustomElement(XBeanBeanDefinitionParserDelegate.java:99) at org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate .parsePropertySubElement(XBeanBeanDefinitionParserDelegate.java:51) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.pa rseMapElement(BeanDefinitionParserDelegate.java:1050) at org.springframework.beans.factory.xml.UtilNamespaceHandler$MapBeanDef initionParser.doParse(UtilNamespaceHandler.java:142) at org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionPar ser.parseInternal(AbstractSingleBeanDefinitionParser.java:66) at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.pa rse(AbstractBeanDefinitionParser.java:55) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(N amespaceHandlerSupport.java:75) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.pa rseCustomElement(BeanDefinitionParserDelegate.java:1147) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.pa rseCustomElement(BeanDefinitionParserDelegate.java:1137) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:143) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader. parseBeanDefinitions(XBeanBeanDefinitionDocumentReader.java:63) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:88) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registe rBeanDefinitions(XmlBeanDefinitionReader.java:499) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.regis terBeanDefinitions(XBeanXmlBeanDefinitionReader.java:79) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadB eanDefinitions(XmlBeanDefinitionReader.java:407) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea nDefinitions(XmlBeanDefinitionReader.java:357) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea nDefinitions(XmlBeanDefinitionReader.java:334) at org.springframework.beans.factory.support.AbstractBeanDefinitionReade r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:126) at org.springframework.beans.factory.support.AbstractBeanDefinitionReade r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:142) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.importBeanDefinitionResource(DefaultBeanDefinitionDocumentReader.java:185) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.parseDefaultElement(DefaultBeanDefinitionDocumentReader.java:155) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:140) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader. parseBeanDefinitions(XBeanBeanDefinitionDocumentReader.java:63) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:88) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registe rBeanDefinitions(XmlBeanDefinitionReader.java:499) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.regis terBeanDefinitions(XBeanXmlBeanDefinitionReader.java:79) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadB eanDefinitions(XmlBeanDefinitionReader.java:407) -- This message is automatically generated by JIRA. - You can reply to this email to
[jira] Created: (SM-846) Call to default constructor of JBIContainer changes log4j log level
Call to default constructor of JBIContainer changes log4j log level --- Key: SM-846 URL: https://issues.apache.org/activemq/browse/SM-846 Project: ServiceMix Issue Type: Bug Affects Versions: 3.0 Environment: Windows XP Professional, java version 1.5.0_09, JUnit 4.1 Reporter: Philipp Rossmanith Priority: Minor A call to the default constructor of org.apache.servicemix.jbi.container.JBIContainer sets the log4j log level to ERROR. See http://www.nabble.com/Default-constructor-for-JBIContainer-changes-log-level--tf3235243s12049.html Can be observed in org.apache.servicemix.jbi.security.SecuredBrokerTest, line 63: jbi = new JBIContainer(); JBIContainer doesn't seem to use org.apache.log4j, but makes calls to org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory: private static final Log log = LogFactory.getLog(JBIContainer.class); ... as well as to java.util.logging.Logger: public Logger getLogger(String suffix, String resourceBundleName) throws MissingResourceException, JBIException commons-logging is configured in ServiceMix. Which in turns, starts log4j if included in the classpath. It seems that org.apache.servicemix.id.IdGenerator calls the java.util.logging package. This is the only call afaik and it should be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (XBEAN-75) xbean-spring depends on JDK 5
[ https://issues.apache.org/jira/browse/XBEAN-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned XBEAN-75: Assignee: Guillaume Nodet xbean-spring depends on JDK 5 - Key: XBEAN-75 URL: https://issues.apache.org/jira/browse/XBEAN-75 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.8 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Starting Apache ServiceMix ESB: 3.1-incubating Loading Apache ServiceMix from servicemix.xml on the CLASSPATH Caught: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpect ed exception parsing XML document from class path resource [jmx.xml]; nested exc eption is java.lang.NoSuchMethodError: java.lang.IllegalStateException: method init(Ljava/lang/String;Ljava/lang/Throwable;)V not found org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected excep tion parsing XML document from class path resource [jmx.xml]; nested exception i s java.lang.NoSuchMethodError: java.lang.IllegalStateException: method init(Lj ava/lang/String;Ljava/lang/Throwable;)V not found Caused by: java.lang.NoSuchMethodError: java.lang.IllegalStateException: method init(Ljava/lang/String;Ljava/lang/Throwable;)V not found at org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate .internalParseNestedCustomElement(XBeanBeanDefinitionParserDelegate.java:99) at org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate .parsePropertySubElement(XBeanBeanDefinitionParserDelegate.java:51) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.pa rseMapElement(BeanDefinitionParserDelegate.java:1050) at org.springframework.beans.factory.xml.UtilNamespaceHandler$MapBeanDef initionParser.doParse(UtilNamespaceHandler.java:142) at org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionPar ser.parseInternal(AbstractSingleBeanDefinitionParser.java:66) at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.pa rse(AbstractBeanDefinitionParser.java:55) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(N amespaceHandlerSupport.java:75) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.pa rseCustomElement(BeanDefinitionParserDelegate.java:1147) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.pa rseCustomElement(BeanDefinitionParserDelegate.java:1137) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:143) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader. parseBeanDefinitions(XBeanBeanDefinitionDocumentReader.java:63) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:88) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registe rBeanDefinitions(XmlBeanDefinitionReader.java:499) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.regis terBeanDefinitions(XBeanXmlBeanDefinitionReader.java:79) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadB eanDefinitions(XmlBeanDefinitionReader.java:407) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea nDefinitions(XmlBeanDefinitionReader.java:357) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea nDefinitions(XmlBeanDefinitionReader.java:334) at org.springframework.beans.factory.support.AbstractBeanDefinitionReade r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:126) at org.springframework.beans.factory.support.AbstractBeanDefinitionReade r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:142) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.importBeanDefinitionResource(DefaultBeanDefinitionDocumentReader.java:185) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.parseDefaultElement(DefaultBeanDefinitionDocumentReader.java:155) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:140) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader. parseBeanDefinitions(XBeanBeanDefinitionDocumentReader.java:63) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:88) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registe
Re: windows build failure
Hello Kevan
I think you said that this error is fixed after you committed the changes in
trunk. I am working on trunk I checkout yesterday (rev 507910). and with my
bad luck I am facing the same exception even now.
Removing
dependency
groupIdorg.apache.openejb/groupId
artifactIdcontainer/artifactId
version${version}/version
typepom/type
scopecompile/scope
/dependency
from server-3.0-incubation-SNAPSHOT.pom solves the problem.
Am I missing something here.
Thanks
Rakesh
On 2/5/07, Hernan Cunico [EMAIL PROTECTED] wrote:
Thanks a bunch Kevan for this workaround, I finally get to build now !
Cheers!
Hernan
Kevan Miller wrote:
I've committed a change to trunk which should avoid this build failure.
The change is really a work-around. The problem seems to be an xmlbeans
bug. The work-around is to exclude the OpenEJB container. This avoids
the container pom error and compilation failures.
Hernan reported that he was now able to build without hacking the pom in
his repo.
--kevan
[jira] Closed: (XBEAN-75) xbean-spring depends on JDK 5
[ https://issues.apache.org/jira/browse/XBEAN-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-75. Resolution: Fixed Fix Version/s: 2.9 Committed revision 508358. xbean-spring depends on JDK 5 - Key: XBEAN-75 URL: https://issues.apache.org/jira/browse/XBEAN-75 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.8 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.9 Starting Apache ServiceMix ESB: 3.1-incubating Loading Apache ServiceMix from servicemix.xml on the CLASSPATH Caught: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpect ed exception parsing XML document from class path resource [jmx.xml]; nested exc eption is java.lang.NoSuchMethodError: java.lang.IllegalStateException: method init(Ljava/lang/String;Ljava/lang/Throwable;)V not found org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected excep tion parsing XML document from class path resource [jmx.xml]; nested exception i s java.lang.NoSuchMethodError: java.lang.IllegalStateException: method init(Lj ava/lang/String;Ljava/lang/Throwable;)V not found Caused by: java.lang.NoSuchMethodError: java.lang.IllegalStateException: method init(Ljava/lang/String;Ljava/lang/Throwable;)V not found at org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate .internalParseNestedCustomElement(XBeanBeanDefinitionParserDelegate.java:99) at org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate .parsePropertySubElement(XBeanBeanDefinitionParserDelegate.java:51) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.pa rseMapElement(BeanDefinitionParserDelegate.java:1050) at org.springframework.beans.factory.xml.UtilNamespaceHandler$MapBeanDef initionParser.doParse(UtilNamespaceHandler.java:142) at org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionPar ser.parseInternal(AbstractSingleBeanDefinitionParser.java:66) at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.pa rse(AbstractBeanDefinitionParser.java:55) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(N amespaceHandlerSupport.java:75) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.pa rseCustomElement(BeanDefinitionParserDelegate.java:1147) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.pa rseCustomElement(BeanDefinitionParserDelegate.java:1137) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:143) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader. parseBeanDefinitions(XBeanBeanDefinitionDocumentReader.java:63) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:88) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registe rBeanDefinitions(XmlBeanDefinitionReader.java:499) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.regis terBeanDefinitions(XBeanXmlBeanDefinitionReader.java:79) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadB eanDefinitions(XmlBeanDefinitionReader.java:407) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea nDefinitions(XmlBeanDefinitionReader.java:357) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea nDefinitions(XmlBeanDefinitionReader.java:334) at org.springframework.beans.factory.support.AbstractBeanDefinitionReade r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:126) at org.springframework.beans.factory.support.AbstractBeanDefinitionReade r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:142) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.importBeanDefinitionResource(DefaultBeanDefinitionDocumentReader.java:185) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.parseDefaultElement(DefaultBeanDefinitionDocumentReader.java:155) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:140) at org.apache.xbean.spring.context.v2.XBeanBeanDefinitionDocumentReader. parseBeanDefinitions(XBeanBeanDefinitionDocumentReader.java:63) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentRe ader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:88) at
[jira] Created: (SM-847) Old version of xml-apis in distribution
Old version of xml-apis in distribution --- Key: SM-847 URL: https://issues.apache.org/activemq/browse/SM-847 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Fix For: 3.2 In the ServiceMix 3.1 distribution (lib folder) a very old version (1.0b2) of xml-apis is included. Replace it with version 1.3.03 or higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Daytrader newbie
Wonderful... It works.. Thanks, Lasantha David Jencks wrote: On Feb 15, 2007, at 7:44 AM, Lasantha Ranaweera wrote: I am using java -jar server.jar. Does it really affects? yes. If the application uses PortableRemoteObject.narrow rather than casts you MUST start geronimo specifying the endorsed dirs java -Djava.endorsed.dirs=lib/endorsed -jar bin/server.jar --long (well, the --long isn't necessary but does give more info if something goes wrong during startup) thanks david jencks Lasantha What command are you using to start the server? startup.sh|bat? or are you starting it some other way? On 2/15/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Hi Chris, Thanks for the information but still it is getting failed for me. Following are the steps I have followed the current situation. May be you might have some more insight on it than me. 1. Get the latest source code from DT trunk (revision 507843). 2. Build the source code using mvn clean install. 3. Start the G 1.2 beta server. 4. Create the derby database using createDB.sh. (I have given it in the DAYTRADER-35 patch would be greately appriciated if someone can review it too) 5. Deploy the daytrader-ear-2.0-SNAPSHOT.ear dtTrunk_geronimo12-beta-plan.xml using G console. 6. Getting following error :(. Thanks Again, Lasantha 15:01:14,658 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs /j2ee-corba-yoko/1.2-beta/car?ServiceModule=org.apache.geronimo.configs /j2ee-corba-yoko/1.2-beta/car,j2eeType=CORBANameService,name=NameServer java.lang.NoSuchMethodError: org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_changed (Ljava/lang/String;S)V at org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange(PIManager.java :531) at org.apache.yoko.orb.OBPortableServer.POAManager_impl.activate (POAManager_impl.java:212) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.initialize( TransientNameService.java:129) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.run( TransientNameService.java:114) at org.apache.openejb.yoko.ORBConfigAdapter.createNameService( ORBConfigAdapter.java:167) at org.apache.openejb.yoko.ORBConfigAdapter$$FastClassByCGLIB$$c8ca5bf1.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java :820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke( RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept( ProxyMethodInterceptor.java:96) at org.apache.openejb.corba.security.config.ConfigAdapter$$EnhancerByCGLIB$$825d752c.createNameService (generated) at org.apache.openejb.corba.NameService.doStart(NameService.java:162) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance( GBeanInstance.java:984) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start( GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java :529) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart( GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget( GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running( GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent( BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300( BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent (BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start( GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive( GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive( GBeanInstance.java:543) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean( BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans (ConfigurationUtil.java:378) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start( KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration (SimpleConfigurationManager.java:527) at
Re: Context level clustering not supported in Tomcat it seems
Yep...I would update the Wiki and state Host/Engine only. Jeff Shiva Kumar H R wrote: As part of https://issues.apache.org/jira/browse/GERONIMO-2577 I had opened the following bug in Tomcat: Context level clustering on 3 or more nodes fails in Tomcat 5.5.20 http://issues.apache.org/bugzilla/show_bug.cgi?id=41620; They have closed the bug as Resolved Invalid with the following comments: --- /Additional Comment #7 http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#c7 From Mark Thomas mailto:[EMAIL PROTECTED] 2007-02-15 18:54 / [reply http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#add_comment] --- It is not possible to configure clustering in context.xml. It must be done at the Host level (with the jvmRoute defined at the Engine level) within server.xml That makes our default clustering article http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html invalid. Should we now remove it saying that Geronimo (Tomcat version) supports clustering at the Host/Engine level only? Dave Colasurdo and myself have already created a new article illustrating how to setup Geronimo (Tomcat version) clustering at the host/engine level: http://cwiki.apache.org/GMOxDOC11/clustering-sample-application-tomcat-host-level.html. Please suggest if we should retain only this and delete the other article on context level clustering? -- Shiva
Axis issue on deployment
Dims, or one of you Axis experts... Any ideas of why I would get the error shown below? Caused by: java.lang.ClassCastException: cannot assign instance of javax.wsdl.OperationType to field org.apache.axis.description.OperationDesc.mep of type javax.wsdl.OperationType in instance of org.apache.axis.description.OperationDesc It happens when I deploy a webservices application in G2. Thanks, Jeff
Re: Axis issue on deployment
Hi Jeff, Are you deploying a service with WSDL or without (with annotations) ? There are some features yet to be implemented if it is with the WSDL. Thanks, Lasantha Jeff Genender wrote: Dims, or one of you Axis experts... Any ideas of why I would get the error shown below? Caused by: java.lang.ClassCastException: cannot assign instance of javax.wsdl.OperationType to field org.apache.axis.description.OperationDesc.mep of type javax.wsdl.OperationType in instance of org.apache.axis.description.OperationDesc It happens when I deploy a webservices application in G2. Thanks, Jeff
Re: Axis issue on deployment
Oops it is Axis 1 related. Not Axis2. Just ignore previous mail. Lasantha Ranaweera wrote: Hi Jeff, Are you deploying a service with WSDL or without (with annotations) ? There are some features yet to be implemented if it is with the WSDL. Thanks, Lasantha Jeff Genender wrote: Dims, or one of you Axis experts... Any ideas of why I would get the error shown below? Caused by: java.lang.ClassCastException: cannot assign instance of javax.wsdl.OperationType to field org.apache.axis.description.OperationDesc.mep of type javax.wsdl.OperationType in instance of org.apache.axis.description.OperationDesc It happens when I deploy a webservices application in G2. Thanks, Jeff
SM Correlation ID vs. ebMS conversation ID
Hi, We're having a scenario where business processes leave SM boundaries into external systems in order to return later on. Interfaces to these systems are HTTP Web services (SOAP 1.1). Some of the processes involve human tasks. Therefore, estimates about the duration cannot be made. What we would like to have is a mechanism allowing relating incoming (HTTP SOAP) messages to flows that have previously occurred, as intended by the ebMS*) ConversationId element.**) Questions: - SM's correlation ID***) seems to be rather similar. Does it intend to provide the same thing? - Why is SM's correlationId set as ThreadLocal?) Why is it limited to [tracing] the flow of the messages inside a Service Assembly? - What about extending servicemix-http to look for an eb:ConversationId in the SOAP header and setting it as the correlation ID? Thanks in advance, Ciao, Philipp Rossmanith *) See http://www.oasis-open.org/specs/index.php#ebxmlmsgv2 **) 3.1.3 ConversationId Element The REQUIRED ConversationId element is a string identifying the set of related messages that make up a conversation between two Parties. It MUST be unique within the context of the specified CPAId. The Party initiating a conversation determines the value of the ConversationId element that SHALL be reflected in all messages pertaining to that conversation. The ConversationId enables the recipient of a message to identify the instance of an application or process that generated or handled earlier messages within a conversation. It remains constant for all messages within a conversation. The value used for a ConversationId is implementation dependent. An example of the ConversationId element follows: eb:ConversationId20001209-133003-28572/eb:ConversationId ***) See https://issues.apache.org/activemq/browse/SM-751, http://www.nabble.com/Flow-tracing-problem-tf2197129s12049.html ) See org.apache.servicemix.common.AsyncBaseLifeCycle This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
Re: Simple Web Service with JAX-WS sample on AG wiki
Lin, Before you update the online doc. Could you please post the modified samples in JIRA? Let me take a quick look? thanks, dims On 2/15/07, Lin Sun [EMAIL PROTECTED] wrote: Hi there, After making some changes to the sample[1], I am able to get it (slightly different versions of it for CXF and Axis2) working with this week's trunk. Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... 2) I developed an Axiom based web services client for Axis2 so that it doesn't require CXF specific jars at the runtime of the client. I'll begin updating the docs and send out another update. Initial thought is to use the same wiki page for both CXF and Axis2 (instead of creating a new page for Axis2) and highlight the differences. Lin [1]http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: Simple Web Service with JAX-WS sample on AG wiki
Lasantha, Jarek promised to write up a list of items implemented then we can make a check list and fix whatever is missing. We need to test all the code too. Since we don't know what works and what doesn't as we don't have full test coverage. thanks, dims On 2/15/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Hi Lin, Great work... We are getting closer closer to finish Axis2 with POJO support ... Dims do you any idea to add what are we missing right now ? Are you using latest version of trunk to build Geronimo? IMO in Axis2 there is a bug and I am submitting a patch for that too ;). Please see my in line comments too. Thanks, Lasantha Lin Sun wrote: Hi there, After making some changes to the sample[1], I am able to get it (slightly different versions of it for CXF and Axis2) working with this week's trunk. Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... It wasn't necessary to generate these files in CXF for WSDL provided situation before. I though it is only for Axis2 to necessary to do this step. Jarek do you have any idea ? :-) 2) I developed an Axiom based web services client for Axis2 so that it doesn't require CXF specific jars at the runtime of the client. I'll begin updating the docs and send out another update. Initial thought is to use the same wiki page for both CXF and Axis2 (instead of creating a new page for Axis2) and highlight the differences. Lin [1]http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
[jira] Created: (GERONIMO-2845) Axis2 JAXWS handle document style WSDLs
Axis2 JAXWS handle document style WSDLs --- Key: GERONIMO-2845 URL: https://issues.apache.org/jira/browse/GERONIMO-2845 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: webservices Reporter: Lasantha Ranaweera Following are the some highlights of the patch. 1. This will handle more generic way of Document style WSDLs for the when it is not given as annotations. 2. Remove some deprecated code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2845) Axis2 JAXWS handle document style WSDLs
[ https://issues.apache.org/jira/browse/GERONIMO-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lasantha Ranaweera updated GERONIMO-2845: - Attachment: GERONIMO-2845.patch Axis2 JAXWS handle document style WSDLs --- Key: GERONIMO-2845 URL: https://issues.apache.org/jira/browse/GERONIMO-2845 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: webservices Reporter: Lasantha Ranaweera Attachments: GERONIMO-2845.patch Following are the some highlights of the patch. 1. This will handle more generic way of Document style WSDLs for the when it is not given as annotations. 2. Remove some deprecated code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Simple Web Service with JAX-WS sample on AG wiki
Dims, Yes we need a good test coverage. Specially when it comes to WSDL provided situation, it reads WSDL and creating annotations by hand. Then we might miss some of the WSDLs. I think there is a good test codings for Axis1 implementation (AxisWebServiceContainerTest.java). Shall we create something like here too? Thanks, Lasantha Davanum Srinivas wrote: Lasantha, Jarek promised to write up a list of items implemented then we can make a check list and fix whatever is missing. We need to test all the code too. Since we don't know what works and what doesn't as we don't have full test coverage. thanks, dims On 2/15/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Hi Lin, Great work... We are getting closer closer to finish Axis2 with POJO support ... Dims do you any idea to add what are we missing right now ? Are you using latest version of trunk to build Geronimo? IMO in Axis2 there is a bug and I am submitting a patch for that too ;). Please see my in line comments too. Thanks, Lasantha Lin Sun wrote: Hi there, After making some changes to the sample[1], I am able to get it (slightly different versions of it for CXF and Axis2) working with this week's trunk. Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... It wasn't necessary to generate these files in CXF for WSDL provided situation before. I though it is only for Axis2 to necessary to do this step. Jarek do you have any idea ? :-) 2) I developed an Axiom based web services client for Axis2 so that it doesn't require CXF specific jars at the runtime of the client. I'll begin updating the docs and send out another update. Initial thought is to use the same wiki page for both CXF and Axis2 (instead of creating a new page for Axis2) and highlight the differences. Lin [1]http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
Two more Axis2 JAXWS patches available
Hi All, There are 2 more Axis2 JAXWS related patches are available under GERONIMO-2842 GERONIMO-2845. Thanks, Lasantha
Re: Axis issue on deployment
On Feb 16, 2007, at 6:19 AM, Jeff Genender wrote: Dims, or one of you Axis experts... Any ideas of why I would get the error shown below? I doubt that this is a problem internal to axis... Looks like we have a classloader/dependency issue. --kevan Caused by: java.lang.ClassCastException: cannot assign instance of javax.wsdl.OperationType to field org.apache.axis.description.OperationDesc.mep of type javax.wsdl.OperationType in instance of org.apache.axis.description.OperationDesc It happens when I deploy a webservices application in G2. Thanks, Jeff
Re: Axis issue on deployment
Jeff, Definitely a classloader issue like Kevan mentions. Please log a JIRA bug with the sample war. thanks, -- dims On 2/16/07, Kevan Miller [EMAIL PROTECTED] wrote: On Feb 16, 2007, at 6:19 AM, Jeff Genender wrote: Dims, or one of you Axis experts... Any ideas of why I would get the error shown below? I doubt that this is a problem internal to axis... Looks like we have a classloader/dependency issue. --kevan Caused by: java.lang.ClassCastException: cannot assign instance of javax.wsdl.OperationType to field org.apache.axis.description.OperationDesc.mep of type javax.wsdl.OperationType in instance of org.apache.axis.description.OperationDesc It happens when I deploy a webservices application in G2. Thanks, Jeff -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: Simple Web Service with JAX-WS sample on AG wiki
Sure. Please do. thanks, dims On 2/16/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Dims, Yes we need a good test coverage. Specially when it comes to WSDL provided situation, it reads WSDL and creating annotations by hand. Then we might miss some of the WSDLs. I think there is a good test codings for Axis1 implementation (AxisWebServiceContainerTest.java). Shall we create something like here too? Thanks, Lasantha Davanum Srinivas wrote: Lasantha, Jarek promised to write up a list of items implemented then we can make a check list and fix whatever is missing. We need to test all the code too. Since we don't know what works and what doesn't as we don't have full test coverage. thanks, dims On 2/15/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Hi Lin, Great work... We are getting closer closer to finish Axis2 with POJO support ... Dims do you any idea to add what are we missing right now ? Are you using latest version of trunk to build Geronimo? IMO in Axis2 there is a bug and I am submitting a patch for that too ;). Please see my in line comments too. Thanks, Lasantha Lin Sun wrote: Hi there, After making some changes to the sample[1], I am able to get it (slightly different versions of it for CXF and Axis2) working with this week's trunk. Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... It wasn't necessary to generate these files in CXF for WSDL provided situation before. I though it is only for Axis2 to necessary to do this step. Jarek do you have any idea ? :-) 2) I developed an Axiom based web services client for Axis2 so that it doesn't require CXF specific jars at the runtime of the client. I'll begin updating the docs and send out another update. Initial thought is to use the same wiki page for both CXF and Axis2 (instead of creating a new page for Axis2) and highlight the differences. Lin [1]http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: windows build failure
On Feb 16, 2007, at 4:44 AM, Rakesh Midha wrote:
Hello Kevan
I think you said that this error is fixed after you committed the
changes in trunk. I am working on trunk I checkout yesterday (rev
507910). and with my bad luck I am facing the same exception even now.
Removing
dependency
groupIdorg.apache.openejb/groupId
artifactIdcontainer/artifactId
version${version}/version
typepom/type
scopecompile/scope
/dependency
from server-3.0-incubation-SNAPSHOT.pom solves the problem.
Am I missing something here.
Strange. I don't see anything that would have unfixed my hack...
Hmm. Maybe it needs to be excluded in a different module/config.
Where are you hitting this error? Maybe corba enablement (or another
change is hitting the same basic issue...).
Anybody else seeing this?
--kevan
[jira] Created: (SM-848) ServiceMix 3.x with Java 1.4.x
ServiceMix 3.x with Java 1.4.x -- Key: SM-848 URL: https://issues.apache.org/activemq/browse/SM-848 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.1 Environment: Java Runtime Environment 1.4.x Reporter: Juergen Mayrbaeurl Fix For: 3.2 Since ServiceMix 3.1 can only be used with Java 5 or higher, rework it to make it Java 1.4.x compatible -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Daytrader: Closing out open JIRAs with patch3s
All... If there are no objections, I am going to commit the patches for the JIRAs listed below to branches/1.2. - DAYTRADER-25: DDL updates for indexes and decimal precision and an update to the quote price change logic - DAYTRADER-29: Remove Async 1-Phase mode - DAYTRADER-33: Add JMS close connection to TradeDirect.queueOrder I will hold off applying these to trunk until we can figure out why the current trunk revision will not deploy on Geronimo 2.0-M2 (Note: I was able to deploy it on M1 without a problem). Chris On 2/11/07, Davanum Srinivas [EMAIL PROTECTED] wrote: Matt, If you are a moderator for that list, you can add chri's apache email to the allow list. [EMAIL PROTECTED] where xyz is the mailing list. Alternatively, when you get the moderator message, make sure you click on reply all (and then ensure that the mail id with allow in it) and send it. thanks, dims On 2/10/07, Matt Hogstrom [EMAIL PROTECTED] wrote: Anyone know what the magic that needs to be done is? I'm happy to do it but not sure which bit needs to be twiddled. On Feb 10, 2007, at 11:55 AM, Kevan Miller wrote: I suspect that Chris's commit messages are not showing up in our SCM list. As I recall, we have to explicitly grant him access and we often forget to do this with new committers... Can someone with necessary karma address? --kevan On Feb 7, 2007, at 1:54 PM, Christopher Blythe wrote: All, In an effort to close out Daytrader 1.2 (branches/1.2) and and sync up any unwanted deltas between 1.2 and trunk, I am working my way through the open JIRAs and applying those with outstanding patches. Yesterday, I applied updates for the following JIRAs to trunk (since they had already been committed to 1.2). - DAYTRADER-17: Dojo UI - DAYTRADER-22: Config flag for publishQuotePrices When applying the changes for DAYTRADER-17 in truck, I forgot to update the pom.xml files with the correct Daytrader snapshot version. Matt took care of that, earlier this morning (DAYTRADER-34). In addition to these items, I would like to go ahead and apply patches that have been submitted for the following JIRAs... - DAYTRADER-25: DDL updates for indexes and decimal precision and an update to the quote price change logic - DAYTRADER-29: Remove Async 1-Phase mode - DAYTRADER-33: Add JMS close connection to TradeDirect.queueOrder Any objections, concerns, or comments? Thanks... Chris -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
Re: Conversion Tool
David/Dain... Did this information help narrow anything down? As an fyi, I tried to add an openejb-jar.xml file (based on the file Dain provided earlier in the email chain) to the location specified in the exception. Unfortunately, it resulted in the same error. openejb-jar.xml --- https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ container/openejb-core/src/test/resources/convert/oej2/cmp/daytrader/ daytrader-openejb-jar.xml Thanks... Chris On 2/15/07, Christopher Blythe [EMAIL PROTECTED] wrote: David... Here is the exception I get... Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml org.apache.geronimo.common.DeploymentException: Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:166) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:134) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$$FastClassByCGLIB$$cd80af20.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$d2a1ea22.createModule (generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:723) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:355) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:257) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$9cf6437.getDeploymentPlan(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java :232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:114) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:595) I have placed the plan file and ear that I am using at the following location... http://people.apache.org/~cjblythe/m2_deploy/http://people.apache.org/%7Ecjblythe/m2_deploy/ Thanks... Chris On 2/14/07, David Blevins [EMAIL PROTECTED] wrote: On Feb 14, 2007, at 1:59 PM, Christopher Blythe wrote: Dain and David... Took a swag at deploying Daytrader on Geronimo 2.0-M2... During deployment, it complained about the openejb-jar.xml file missing from the EJB module. I added the one you provided earlier in this chain, but for some reason it is still complaining that the openejb- jar.xml file is missing from the EJB module. I think Matt is probably running into the same issue... Does the or-mapping file also need to go in the ear/jar
Re: Simple Web Service with JAX-WS sample on AG wiki
Hi Jarek, good point - I dont have a good reason for that. :) It is just the examples I found are using Axiom. I'll let you know once I find out. Lin Jarek Gawor wrote: Great. A few comments inline: On 2/15/07, Lin Sun [EMAIL PROTECTED] wrote: Hi there, After making some changes to the sample[1], I am able to get it (slightly different versions of it for CXF and Axis2) working with this week's trunk. Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... 2) I developed an Axiom based web services client for Axis2 so that it doesn't require CXF specific jars at the runtime of the client. Hmm... is that different from the javax.xml.ws.Service API? Why couldn't you use the Axis2 implementation of the Service API? I'll begin updating the docs and send out another update. Initial thought is to use the same wiki page for both CXF and Axis2 (instead of creating a new page for Axis2) and highlight the differences. Right, there should be only one page. And eventually (and hopefully) those differences should disappear, so we should stress that these differences are temporary. Jarek
Re: Simple Web Service with JAX-WS sample on AG wiki
Hi Lasantha, I am using a geronimo build I built on Monday which is probably why I didn't see the bug you hit.:-) Re your inline comment below, seems there are sufficient changes in CXF recently to cause the previous example not working. I tried to run the war file without these generated classes but got some stack trace asking for something like getResquestWrapper from CXF... This can be easily recreated with the latest sample I have by just uncommenting out the java code generation portion in pom.xml if anyone is interested in more details. Thanks, Lin Lasantha Ranaweera wrote: Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... It wasn't necessary to generate these files in CXF for WSDL provided situation before. I though it is only for Axis2 to necessary to do this step. Jarek do you have any idea ? :-)
Re: Simple Web Service with JAX-WS sample on AG wiki
To make Jarek's job easier, I'll start a wiki write-up by creating a table with lists of functions we need to do for CXF and Axis2. I'll get this information from JSR109 which is the only spec we (geronimo) needs to implement IIUC. Then we can check items that we think is developed and/or tested. I'll have placeholders for stuff I don't know so that you guys can fill in the holes.:-) I'll begin working on this next week as soon as I finish up with the sample. Lin Davanum Srinivas wrote: Lasantha, Jarek promised to write up a list of items implemented then we can make a check list and fix whatever is missing. We need to test all the code too. Since we don't know what works and what doesn't as we don't have full test coverage. thanks, dims On 2/15/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Hi Lin, Great work... We are getting closer closer to finish Axis2 with POJO support ... Dims do you any idea to add what are we missing right now ? Are you using latest version of trunk to build Geronimo? IMO in Axis2 there is a bug and I am submitting a patch for that too ;). Please see my in line comments too. Thanks, Lasantha Lin Sun wrote: Hi there, After making some changes to the sample[1], I am able to get it (slightly different versions of it for CXF and Axis2) working with this week's trunk. Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... It wasn't necessary to generate these files in CXF for WSDL provided situation before. I though it is only for Axis2 to necessary to do this step. Jarek do you have any idea ? :-) 2) I developed an Axiom based web services client for Axis2 so that it doesn't require CXF specific jars at the runtime of the client. I'll begin updating the docs and send out another update. Initial thought is to use the same wiki page for both CXF and Axis2 (instead of creating a new page for Axis2) and highlight the differences. Lin [1]http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
[jira] Assigned: (DAYTRADER-25) Update decimal precision and indexes in ddl
[ https://issues.apache.org/jira/browse/DAYTRADER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe reassigned DAYTRADER-25: - Assignee: Christopher James Blythe Update decimal precision and indexes in ddl --- Key: DAYTRADER-25 URL: https://issues.apache.org/jira/browse/DAYTRADER-25 Project: DayTrader Issue Type: Improvement Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Minor Attachments: daytrader-25.code.patch, daytrader-25.schema.patch While working with previous versions of Trade, I found that the monetary values stored in the database could overrun the decimal precision defined in the schema (10,2) if allowed to run for an extended period of time. This would result in SQL exceptions related to data conversion. To prevent this we increased the decimal presion to (14,2) We also found that some of the indexs were not necessary and that others should be added. In addition to the primary keys, here are the indexes we found to be the most useful... CREATE INDEX a.profile_userid on accountejb(profile_userid); CREATE INDEX h.account_accountid on holdingejb(account_accountid); CREATE INDEX o.account_accountid on orderejb(account_accountid); CREATE INDEX o.holding_holdingid on orderejb(holding_holdingid); CREATE INDEX o.closed_orders on orderejb(account_accountid,orderstatus); Will wait to submit a patch until the fate of Daytrader-14 is determined. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DAYTRADER-29) Async 1-Phase mode should be removed
[ https://issues.apache.org/jira/browse/DAYTRADER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe reassigned DAYTRADER-29: - Assignee: Christopher James Blythe Async 1-Phase mode should be removed Key: DAYTRADER-29 URL: https://issues.apache.org/jira/browse/DAYTRADER-29 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Attachments: daytrader-29.patch Here are some comments that I added to DT-22... Since my involvement with Daytrader (and Trade), we've never been all that concerned with the Async 1-phase mode. Here is the lay of the land to my understanding... Sync mode - Uses JMS topics and TradeTopicMDB to publish changes to the quote prices - There is flag in the DDs to disable this but it doesn't seem to apply to direct mode (only EJB mode) Async 2-phase mode - This mode uses a JMS queue and the TradeBroker to handle order processing - Specifically, the buy and sell operations call a queueOrder method to place a message on the queue - The queueOrder is part of an XA transaction because two resource managers (JMS and database) are involved to create the order in the databse and place a message on the queue - The MDB starts a new transaction when the message is read from the queue. The MDB then executes the completeOrder method which updates the order in the database inside the original MDB transaction context Async 1-phase mode - Does the same as above, but does not involve an UserTransaction to provide XA - Since the MDB is container-managed, TradeEJB is used to complete the order and create a new transaction (avoiding XA) My guess is that the Async 1-phase mode was added to messure the overhead associated with handling the XA transaction. I have never found that much value in Async 1-phase mode. If you are using two different resources as part of a logical transaction, you should always use XA to ensure proper rollback handling. Honestly, I see very little need to keep it around... However, there might be some possiblities I have not considered. As an added benefit of removing this option, we would remove a dependency between the TradeDirect and TradeBean code. I also like the idea of splitting up the modes by category and doing a little renaming to make them more descriptive. Persistence Run-time Modes (one has to be selected) 1) Direct (or JDBC) 2) Stateless Session Bean to Direct 3) Full EJB (Stateless Session Bean to Entity Beans) JMS Support Enablement (any can be selected) - Publish Quote Updates (Publish quote price changes to a JMS topic) - Process Buy/Sell Orders using XA (Asychronously process buy/sell orders by placing them on a JMS queue. An MDB is then responsible for reading a message form the queue and completing the order) Thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Simple Web Service with JAX-WS sample on AG wiki
Sure - submitted G2846 for this. Thanks for reviewing it. Lin Davanum Srinivas wrote: Lin, Before you update the online doc. Could you please post the modified samples in JIRA? Let me take a quick look? thanks, dims On 2/15/07, Lin Sun [EMAIL PROTECTED] wrote: Hi there, After making some changes to the sample[1], I am able to get it (slightly different versions of it for CXF and Axis2) working with this week's trunk. Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... 2) I developed an Axiom based web services client for Axis2 so that it doesn't require CXF specific jars at the runtime of the client. I'll begin updating the docs and send out another update. Initial thought is to use the same wiki page for both CXF and Axis2 (instead of creating a new page for Axis2) and highlight the differences. Lin [1]http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
[jira] Updated: (GERONIMO-2846) modified jax-ws calculator sample to work with CXF and Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-2846: -- Attachment: jax-ws-calculator.zip modified jax-ws calculator sample to work with CXF and Axis2 Key: GERONIMO-2846 URL: https://issues.apache.org/jira/browse/GERONIMO-2846 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: sample apps Affects Versions: 2.0-M2 Environment: winxp + sun jsk 1.5 Reporter: Lin Sun Fix For: 2.0 Attachments: jax-ws-calculator.zip Hi Dims, Per your request, here's the modified version of the sample. Current issues: 1) I haven't been able to run the webservice client outside of my eclipse env. Getting CNF error if I ran the client as java -jar jaxws-calculator-1.0.jar. This could be fixed by providing an ant script or build the java execution into maven's pom.xml. 2) Running the Axis2 CalculatorClient client caused Caused by: java.lang.ClassNotFoundException: com.sun.xml.ws.spi.ProviderImpl at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:34) ... 6 more I just added this client back in this morning so I probably have missed the dependency for this one. There are so many Axis2 dependencies so if you know which one I need let me know.:) Running the Axis2 CalculatorClientAxiom client works fine. Thanks, Lin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-849) The web console fails when displaying an error
The web console fails when displaying an error -- Key: SM-849 URL: https://issues.apache.org/activemq/browse/SM-849 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 ERROR - [jsp] - Servlet.service() pour la servlet jsp a lancÚ une exception org.apache.jasper.JasperException: Le fichier /WEB-INF/tags/sitemesh-page.tld n'a pas ÚtÚ trouvÚ at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:50) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:114) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-849) The web console fails when displaying an error
[ https://issues.apache.org/activemq/browse/SM-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-849. Resolution: Fixed URL: http://svn.apache.org/viewvc?view=revrev=508449 URL: http://svn.apache.org/viewvc?view=revrev=508451 The web console fails when displaying an error -- Key: SM-849 URL: https://issues.apache.org/activemq/browse/SM-849 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 ERROR - [jsp] - Servlet.service() pour la servlet jsp a lancÚ une exception org.apache.jasper.JasperException: Le fichier /WEB-INF/tags/sitemesh-page.tld n'a pas ÚtÚ trouvÚ at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:50) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:114) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: outstanding patches
No problem and thanks for committing these! Jarek On 2/15/07, Davanum Srinivas [EMAIL PROTECTED] wrote: Am on it! sorry for the delay. -- dims On 2/15/07, Jarek Gawor [EMAIL PROTECTED] wrote: Hi, I was wondering if somebody could review/commit the following patches I submitted: 1) https://issues.apache.org/jira/browse/GERONIMO-2825 2) https://issues.apache.org/jira/browse/GERONIMO-2826 3) https://issues.apache.org/jira/browse/GERONIMO-2830 4) https://issues.apache.org/jira/browse/GERONIMO-2836 5) https://issues.apache.org/jira/browse/GERONIMO-2840 Most of them are pretty small so should be easy to review. Thanks, Jarek -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
[jira] Updated: (GERONIMO-2806) mail.null.host property not resolved by SMTPTransport class
[ https://issues.apache.org/jira/browse/GERONIMO-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GERONIMO-2806: --- Summary: mail.null.host property not resolved by SMTPTransport class (was: mail.null.host property not resolved my SMTPTransport class) mail.null.host property not resolved by SMTPTransport class --- Key: GERONIMO-2806 URL: https://issues.apache.org/jira/browse/GERONIMO-2806 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Affects Versions: 1.1.1 Reporter: Jason Warner Assigned To: Jason Warner There's a problem in the base class that's causing it to read the property mail.null.host rather than mail.smtp.host, like it should. There's also a secondary problem where the SMTPTransport class in its protocolConnect() method is not detecting a null host and reading the property itself -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-848) ServiceMix 3.x with Java 1.4.x
[ https://issues.apache.org/activemq/browse/SM-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38538 ] Guillaume Nodet commented on SM-848: Fix DescriptorFactory.java, line 249 URL: http://svn.apache.org/viewvc?view=revrev=508471 URL: http://svn.apache.org/viewvc?view=revrev=508484 ServiceMix 3.x with Java 1.4.x -- Key: SM-848 URL: https://issues.apache.org/activemq/browse/SM-848 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.1 Environment: Java Runtime Environment 1.4.x Reporter: Juergen Mayrbaeurl Fix For: 3.2 Since ServiceMix 3.1 can only be used with Java 5 or higher, rework it to make it Java 1.4.x compatible -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Context level clustering not supported in Tomcat it seems
Agreed. If Tomcat can't claim support for this scenario then neither should Geronimo. Feel free to remove the context clustering article. We may need Hernan to help here as I suspect there are two copies of the article.. One in actual source and one via export.. Thanks -Dave- Jeff Genender wrote: Yep...I would update the Wiki and state Host/Engine only. Jeff Shiva Kumar H R wrote: As part of https://issues.apache.org/jira/browse/GERONIMO-2577 I had opened the following bug in Tomcat: Context level clustering on 3 or more nodes fails in Tomcat 5.5.20 http://issues.apache.org/bugzilla/show_bug.cgi?id=41620; They have closed the bug as Resolved Invalid with the following comments: --- /Additional Comment #7 http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#c7 From Mark Thomas mailto:[EMAIL PROTECTED] 2007-02-15 18:54 / [reply http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#add_comment] --- It is not possible to configure clustering in context.xml. It must be done at the Host level (with the jvmRoute defined at the Engine level) within server.xml That makes our default clustering article http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html invalid. Should we now remove it saying that Geronimo (Tomcat version) supports clustering at the Host/Engine level only? Dave Colasurdo and myself have already created a new article illustrating how to setup Geronimo (Tomcat version) clustering at the host/engine level: http://cwiki.apache.org/GMOxDOC11/clustering-sample-application-tomcat-host-level.html. Please suggest if we should retain only this and delete the other article on context level clustering? -- Shiva
[jira] Assigned: (DAYTRADER-33) TradeDirect queueOrder fails to close JMS connection
[ https://issues.apache.org/jira/browse/DAYTRADER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe reassigned DAYTRADER-33: - Assignee: Christopher James Blythe TradeDirect queueOrder fails to close JMS connection Key: DAYTRADER-33 URL: https://issues.apache.org/jira/browse/DAYTRADER-33 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Attachments: daytrader-33.patch The queueOrder method in TradeDirect closes the session, but does not close the JMS connection and return it to the pool. Consequently, if asynch 2-phase mode is enabled, the JMS connection pool will eventually throw an exception indicating that no connections are available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Context level clustering not supported in Tomcat it seems
I already created a JIRA (INFRA-1166) for infra to remove the old HTML page. (that is the autoexported page for which I have no control on) I can delete any other Confluence native page if needed, just send me the link. Cheers! Hernan Dave Colasurdo wrote: Agreed. If Tomcat can't claim support for this scenario then neither should Geronimo. Feel free to remove the context clustering article. We may need Hernan to help here as I suspect there are two copies of the article.. One in actual source and one via export.. Thanks -Dave- Jeff Genender wrote: Yep...I would update the Wiki and state Host/Engine only. Jeff Shiva Kumar H R wrote: As part of https://issues.apache.org/jira/browse/GERONIMO-2577 I had opened the following bug in Tomcat: Context level clustering on 3 or more nodes fails in Tomcat 5.5.20 http://issues.apache.org/bugzilla/show_bug.cgi?id=41620; They have closed the bug as Resolved Invalid with the following comments: --- /Additional Comment #7 http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#c7 From Mark Thomas mailto:[EMAIL PROTECTED] 2007-02-15 18:54 / [reply http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#add_comment] --- It is not possible to configure clustering in context.xml. It must be done at the Host level (with the jvmRoute defined at the Engine level) within server.xml That makes our default clustering article http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html invalid. Should we now remove it saying that Geronimo (Tomcat version) supports clustering at the Host/Engine level only? Dave Colasurdo and myself have already created a new article illustrating how to setup Geronimo (Tomcat version) clustering at the host/engine level: http://cwiki.apache.org/GMOxDOC11/clustering-sample-application-tomcat-host-level.html. Please suggest if we should retain only this and delete the other article on context level clustering? -- Shiva
Re: Error when configuring JMS through Geronimo console
You already created a JIRA for it, need to get that issue taken care of first if it is preventing you from continuing. Does anybody know of a workaround for this issue? The good thing is that, in the mean time, there is still plenty of other areas to cover in the documentation ;-) Cheers! Hernan Karthiga Ratnam wrote: Hi Hernan, I am unable to complete the documentation on JMS configuring due to this reason. Any thoughts on how we can progress with this?? Regards Karthiga On 2/15/07, *Hernan Cunico* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Pls create a JIRA detailing the error. Cheers! Hernan Lasantha Ranaweera wrote: Hi Karthiga, I observed the same problem in the 1.2 beta release of Geronimo. But it works correctly in 2.x releases. I am not sure either what can we do for this kind of issue. Can somebody in the list please let us know whether we need to create a JIRA or not? It would be ideal if someone explain the future of 1.2 release. Thanks, Lasantha Karthiga Ratnam wrote: Hi All, I'm working on Configuring JMS document for v1.2 of Geronimo. I noticed an error when I try to deploy the JMS Resources or when I try to view its deployment plan. I tried on both Linux and Windows environments. Please find the error below: - 16:01:24,343 ERROR [AbstractHandler] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.create Configuration( JMXDeploymentManager.java:299) at org.apache.geronimo.console.jmsmanager.wizard.AbstractHandler.save(Ab stractHandler.java:471) at org.apache.geronimo.console.jmsmanager.wizard.DeployHandler.actionBef oreView(DeployHandler.java:40) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPageP ortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch (PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java :617) at javax.servlet.http.HttpServlet.service(HttpServlet.java :690) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle (JettyServletHolde r.java :103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter (JSR154Filter.java :170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java :471) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWe bApplicationHandler.java :58) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) at org.mortbay.jetty.servlet.Dispatcher.include (Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke rImpl.java :68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java :82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java :267) at javax.servlet.http.HttpServlet.service(HttpServlet.java :617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle (JettyServletHolde r.java:103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter ( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java :170 ) at
[jira] Updated: (GERONIMO-2816) @EJB/@EJBs annotation support
[ https://issues.apache.org/jira/browse/GERONIMO-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMO-2816: Attachment: GERONIMO-2816-3.patch EJBAnnotationHelper-3.java AnnotationHelper-3.java The final resting place for annotation processing in Geronimo is EARConfigBuilder.java @EJB/@EJBs annotation support - Key: GERONIMO-2816 URL: https://issues.apache.org/jira/browse/GERONIMO-2816 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Fix For: 2.0 Attachments: AnnotationHelper-3.java, AnnotationHelper.java, AnnotationHelper.java, EJBAnnotationHelper-3.java, EJBAnnotationHelper.java, EJBAnnotationHelper.java, GERONIMO-2816-2.patch, GERONIMO-2816-3.patch, GERONIMO-2816.patch Code and patches to support the @EJB and @EJBs annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2817) Parent/child classloader problem in EARConfigBuilder and AbstractWebModuleBuilder
[ https://issues.apache.org/jira/browse/GERONIMO-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMO-2817. --- Resolution: Invalid Not a problem--working as designed Parent/child classloader problem in EARConfigBuilder and AbstractWebModuleBuilder - Key: GERONIMO-2817 URL: https://issues.apache.org/jira/browse/GERONIMO-2817 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Blocker Fix For: 2.0 The WAR classloader should be a child of the EAR parent classloader when deploying an EAR file (per Dain/David). This is not the case and is preventing discovery of all the annotations when deploying EAR files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2847) @WebService annotation support
@WebService annotation support -- Key: GERONIMO-2847 URL: https://issues.apache.org/jira/browse/GERONIMO-2847 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Minor Fix For: 2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2847) @WebService annotation support
[ https://issues.apache.org/jira/browse/GERONIMO-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473805 ] Tim McConnell commented on GERONIMO-2847: - Code and patches to support the @WebService annotations @WebService annotation support -- Key: GERONIMO-2847 URL: https://issues.apache.org/jira/browse/GERONIMO-2847 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Minor Fix For: 2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-2816) @EJB/@EJBs annotation support
[ https://issues.apache.org/jira/browse/GERONIMO-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell resolved GERONIMO-2816. - Resolution: Fixed Resolved with last attached patch @EJB/@EJBs annotation support - Key: GERONIMO-2816 URL: https://issues.apache.org/jira/browse/GERONIMO-2816 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Fix For: 2.0 Attachments: AnnotationHelper-3.java, AnnotationHelper.java, AnnotationHelper.java, EJBAnnotationHelper-3.java, EJBAnnotationHelper.java, EJBAnnotationHelper.java, GERONIMO-2816-2.patch, GERONIMO-2816-3.patch, GERONIMO-2816.patch Code and patches to support the @EJB and @EJBs annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2848) @WebServiceRef annotation support
@WebServiceRef annotation support - Key: GERONIMO-2848 URL: https://issues.apache.org/jira/browse/GERONIMO-2848 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Tim McConnell Assigned To: Tim McConnell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-537) Define several endpoint implementations instead of having only one
[ https://issues.apache.org/activemq/browse/SM-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38546 ] Guillaume Nodet commented on SM-537: Author: gnodet Date: Fri Feb 16 13:20:05 2007 New Revision: 508584 URL: http://svn.apache.org/viewvc?view=revrev=508584 Log: SM-537, SM-724: split consumer / provider endpoints, and support pluggable marshalers Define several endpoint implementations instead of having only one -- Key: SM-537 URL: https://issues.apache.org/activemq/browse/SM-537 Project: ServiceMix Issue Type: Improvement Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Guillaume Nodet It would be much more easy to know which kind of endpoint is it and which attributes are mandatory. Having more specialized classes will also be easier to maintain. http:consumer ... http:provider ... jms:consumer .. jms:provider jms:jca-consumer ... jms:jca-provider .. jms:amq-consumer jms:amq-provider .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-724) able to write marshaller for JBI components
[ https://issues.apache.org/activemq/browse/SM-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38547 ] Guillaume Nodet commented on SM-724: Author: gnodet Date: Fri Feb 16 13:20:05 2007 New Revision: 508584 URL: http://svn.apache.org/viewvc?view=revrev=508584 Log: SM-537, SM-724: split consumer / provider endpoints, and support pluggable marshalers able to write marshaller for JBI components --- Key: SM-724 URL: https://issues.apache.org/activemq/browse/SM-724 Project: ServiceMix Issue Type: New Feature Components: servicemix-http, servicemix-jms Reporter: Alper Sogukpinar Assigned To: Guillaume Nodet Fix For: 3.2 I think it would be nice if we could write marshaller for JBI components like it is written lightweight components. If marshaller can be written for JBI components it may keep us from writing custom endpoints or JBI components to make small improvements on the available components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
dependency madness
Hi, I'm having some dependency issues. Here's the deal: My cxf-deployer/car has a dependency on cxf/car and openejb-deployer/car (openejb-deployer/car also pulls in openejb/car). In cxf-deployer plan.xml I deploy a EJBWebServiceGBean. That GBean lives in cxf/jar and has a following reference: infoFactory.addReference(EjbDeployment, EjbDeployment.class); During cxf-deployer/car install I get the following exception: java.lang.NoClassDefFoundError: org/apache/geronimo/openejb/EjbDeployment at org.apache.geronimo.cxf.ejb.EJBWebServiceGBean.clinit(EJBWebService GBean.java:102) I can fix that error by adding openejb/car dependency to cxf/car but I do not want to do that because for POJO web services I do not need the ejb dependency. Is there an easy way to fix that or some work-around? Or do I have to create separate configs for ejb with cxf combination? Thanks, Jarek
Re: Conversion Tool
On Feb 16, 2007, at 6:09 AM, Christopher Blythe wrote: David/Dain... Did this information help narrow anything down? Actually, yes. Seems your build is very old -- we don't even have that error message anymore. What version are you using? -David As an fyi, I tried to add an openejb-jar.xml file (based on the file Dain provided earlier in the email chain) to the location specified in the exception. Unfortunately, it resulted in the same error. openejb-jar.xml --- https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ container/openejb-core/src/test/resources/convert/oej2/cmp/daytrader/ daytrader-openejb-jar.xml Thanks... Chris On 2/15/07, Christopher Blythe [EMAIL PROTECTED] wrote: David... Here is the exception I get... Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml org.apache.geronimo.common.DeploymentException: Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule (EjbModuleBuilder.java:166) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule (EjbModuleBuilder.java:134) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$ $FastClassByCGLIB$$cd80af20.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$ $EnhancerByCGLIB$$d2a1ea22.createModule (generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules (EARConfigBuilder.java:723) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan (EARConfigBuilder.java:355) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan (EARConfigBuilder.java:257) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$ $FastClassByCGLIB$$38e56ec6.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$ $EnhancerByCGLIB$$9cf6437.getDeploymentPlan (generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java :232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$ $734a235d.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDe ploy (AbstractDeployCommand.java:114) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run (DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:595)I have placed the plan file and ear that I am using at the following location... http://people.apache.org/~cjblythe/m2_deploy/ Thanks... Chris On 2/14/07, David Blevins [EMAIL PROTECTED] wrote: On Feb 14, 2007, at 1:59 PM, Christopher Blythe wrote: Dain and David... Took a swag at deploying Daytrader on Geronimo 2.0-M2... During deployment, it complained about the openejb-jar.xml file missing from the EJB module. I added the one you provided earlier in this chain, but for some reason it is still complaining that the openejb- jar.xml file is missing from the EJB module. I think Matt is probably running into the same issue... Does the or-mapping file also need to go in the ear/jar somewhere? Should this work on M2? Is there anything else that needs to go into the
Re: Conversion Tool
How old do you consider very old? I got this on the Geronimo 2.0-M2 release that is out on the Geronimo website dated 1/30/2007.Deployed fine on M1 though... On 2/16/07, David Blevins [EMAIL PROTECTED] wrote: On Feb 16, 2007, at 6:09 AM, Christopher Blythe wrote: David/Dain... Did this information help narrow anything down? Actually, yes. Seems your build is very old -- we don't even have that error message anymore. What version are you using? -David As an fyi, I tried to add an openejb-jar.xml file (based on the file Dain provided earlier in the email chain) to the location specified in the exception. Unfortunately, it resulted in the same error. openejb-jar.xml --- https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ container/openejb-core/src/test/resources/convert/oej2/cmp/daytrader/ daytrader-openejb-jar.xml Thanks... Chris On 2/15/07, Christopher Blythe [EMAIL PROTECTED] wrote: David... Here is the exception I get... Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml org.apache.geronimo.common.DeploymentException: Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule (EjbModuleBuilder.java:166) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule (EjbModuleBuilder.java:134) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$ $FastClassByCGLIB$$cd80af20.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$ $EnhancerByCGLIB$$d2a1ea22.createModule (generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules (EARConfigBuilder.java:723) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan (EARConfigBuilder.java:355) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan (EARConfigBuilder.java:257) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$ $FastClassByCGLIB$$38e56ec6.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$ $EnhancerByCGLIB$$9cf6437.getDeploymentPlan (generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java :232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$ $734a235d.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDe ploy (AbstractDeployCommand.java:114) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run (DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:595)I have placed the plan file and ear that I am using at the following location... http://people.apache.org/~cjblythe/m2_deploy/ Thanks... Chris On 2/14/07, David Blevins [EMAIL PROTECTED] wrote: On Feb 14, 2007, at 1:59 PM, Christopher Blythe wrote: Dain and David... Took a swag at deploying Daytrader on Geronimo 2.0-M2... During deployment, it complained about the openejb-jar.xml file missing from the EJB module. I added the one you provided earlier in this chain, but for some reason it is still complaining that the
Re: ClassFinder questions/problems -- annotation processing
On Feb 15, 2007, at 9:25 PM, Tim McConnell wrote: Hi David/Dain, I finally see what's going on here now--and it really makes a lot of sense. I'm not so sure it's a bug with the classloading process so much as it's just the way the current code functions. I can't easily show a sequence diagram here but can briefly explain. It appears the the EarContext for a deployed EAR file is aggregated across successive calls from EARConfigBuilder.buildConfiguration() to the installModule() method on first the WebModuleBuilder class, and then second on the EjbModuleBuilder class. This explains why ClassFinder was working correctly in EjbRefBuilder (i.e. the deployed module's EarContext had been fully aggregated) but failed for me in AbstractWebModuleBuilder (i.e., the deployed module's EarContext had not yet been fully aggregated). That would explain a lot! Though, this does seem like an issue that should be fixed. I know DJ isn't fond of some of the hacks we've had to add in the builder process. Likely this may be the straw that broke the camels back. So, rather than fixing something that's not really broken in AbstractWebModuleBuilder, the best solution in my view is to push the Annotation processing out of the installModule processing of the module builder(s) up into the configuration builder. This would allow us to encapsulate the Annotation processing for deployed EJB applications, Web applications, App Client applications, and Connectors (not sure these would be annotated though) into a single class: EARConfigBuilder. Additionally, it would guarantee that we always have access to a fully aggregated EarContext, and thus a fully populated classloader to pass to ClassFinder. And finally, I think it would encapsulate most of the Geronimo annotation processing except for Web Services. This approach is somewhat in line with my original proposed plan for Annotation Processing for Geronimo, it's just the conduit has changed somewhat. Do either of you (or anyone else) have any thoughts, comments and/or concerns ?? That'd be fine for Web modules and App Clients -- there are no Connector annotations and EJB annotations are taken care of by OpenEJB. I know you keep wanting to do all the EJB-specific annotations, but there's no real reuse there. Web modules and Connectors pretty much both have the same stuff, which is really only the five or so JSR-250 annotations plus these from javax.ejb: @EJB (s), @PersistenceUnit, and @PersistenceContext. You can cross the rest off your list: i.e. javax.ejb @Remote, @RemoteHome, @Local, @LocalHome, @Stateless, @Stateful, @MessageDriven, @PrePassivate, @PreActivate, @Init, @Remove, @Timeout, etc. These are EJB specific and already implemented for the most part. -David Thanks, Tim McConnell Tim McConnell wrote: Hi Dain, What you suggest does make a lot of sense. But for the stateless-calculator ear file (i.e., calculator-stateless-ear-2[1]. 0-M2.ear) I would then expect to find the calculator-stateless- ear-2[1].0-M2.jar file on one of the parent classloaders for the WAR classloader in AbstractWebModuleBuilder. It's not, so I suspect there is a bug somewhere as you suggest. I shall investigate further tomorrow. Thanks for the pointer Dain Sundstrom wrote: On Feb 6, 2007, at 12:49 PM, David Blevins wrote: On Feb 4, 2007, at 7:19 PM, Tim McConnell wrote: Hi again Dave, after your recommendation below to do all the annotation discovery during the installModule phase of deployment ClassFinder is working much better for me. I do still have another scenario I'd appreciate some advice on. It seems that when an EJB EAR file (with embedded JAR and WAR files) gets deployed in Geronimo, there are two builders invoked: e.g., TomcatModuleBuilder/AbstractWebModuleBuilder and EJBModuleBuilder such that the embedded JAR file is not added to the ClassPath/ClassLoader when the WAR is deployed (I assume this is the way it should work since I haven't changed it-- yet). So, if there are annotations in the WAR class files pointing to classes in the JAR file, we'll still encounter NoClassDefException(s). I can just add the JAR files in the EAR to the classpath of the WAR, which is what I've done to get around the problem, but I'm not sure this is the best alternative. Do you have any thoughts?? Thanks much Those should be added automatically via the deployment system. Very puzzling. Dain, did you see anything like this when you did that hack for @EJB annotation support in Servlets? Nope. The WAR class loader is a child of the EAR class loader so the WAR should see all of the jars in the ear. If that is not the case, then there is a bug. -dain
Re: Conversion Tool
On Feb 16, 2007, at 2:11 PM, Christopher Blythe wrote: How old do you consider very old? I got this on the Geronimo 2.0-M2 release that is out on the Geronimo website dated 1/30/2007.Deployed fine on M1 though... The converter didn't make it into the M2 release. So just old enough :) I'd give it a try on trunk and see how far you get. -David On 2/16/07, David Blevins [EMAIL PROTECTED] wrote: On Feb 16, 2007, at 6:09 AM, Christopher Blythe wrote: David/Dain... Did this information help narrow anything down? Actually, yes. Seems your build is very old -- we don't even have that error message anymore. What version are you using? -David As an fyi, I tried to add an openejb-jar.xml file (based on the file Dain provided earlier in the email chain) to the location specified in the exception. Unfortunately, it resulted in the same error. openejb-jar.xml --- https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ container/openejb-core/src/test/resources/convert/oej2/cmp/ daytrader/ daytrader-openejb-jar.xml Thanks... Chris On 2/15/07, Christopher Blythe [EMAIL PROTECTED] wrote: David... Here is the exception I get... Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml org.apache.geronimo.common.DeploymentException: Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule (EjbModuleBuilder.java :166) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule (EjbModuleBuilder.java:134) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$ $FastClassByCGLIB$$cd80af20.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java :57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java :96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$ $EnhancerByCGLIB$$d2a1ea22.createModule (generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules (EARConfigBuilder.java:723) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan (EARConfigBuilder.java:355) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan (EARConfigBuilder.java:257) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$ $FastClassByCGLIB$$38e56ec6.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 :127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$ $EnhancerByCGLIB$$9cf6437.getDeploymentPlan (generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java :232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java : 124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$ $734a235d.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java :855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDe ploy (AbstractDeployCommand.java :114) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run (DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:595)I have placed the plan file and ear that I am using at the following location... http://people.apache.org/~cjblythe/m2_deploy/ Thanks... Chris On 2/14/07, David Blevins [EMAIL PROTECTED] wrote: On Feb 14, 2007, at 1:59 PM, Christopher Blythe wrote: Dain and David... Took a swag at deploying Daytrader on Geronimo
Spring 2.0 and XBean
This little error is causing me some fun: org.springframework.core.ConstantException: Field 'ISOLATION_' not found in class [org.springframework.transaction.TransactionDefinition] To explain, I am trying to use a POJO in a lightweight container and that POJO requires some injected dependencies that are configured using Spring 2.0. My lw-component is deployed in a service unit using the sm:serviceunit id=jbi notation and the Spring 2.0 config for the dependencies is then imported within the same servicemix.xml using import. This imported file is using AOP to wrap my injected bean in a transactional context and Spring is obviously getting close enough to doing this to generate the above error message. The reason for the error is that the Spring 2.0.1 version of TransactionDefinition declares ISOLATION_ but Spring 1.2.4 does not. Within ServiceMix, it appears that XBean defaults to Spring 1.2.4 classes rather than 2.0.1 and I cannot see how to prevent this. I have spent a pleasant evening trawling through the innards of XBean and can see that it acts as a pre-processor to Spring. Unfortunately, at the point at which a service unit is loaded in ServiceMix, the classpath for XBean is already defined and I can't see a way to influence the flavour of Spring to be used to process an individual service unit. I see that XBean has packages for a variety of Spring flavours, so I guess the question is how do I make it use the one I want?. Thanks, Terry
recent changes
Hi, In the last few days something has changed in CXF that caused invocations to stop working in Geronimo. I mean, the service got invoked ok but the HTTP response from the service was empty. I tracked relevant changes to the following classes: http://svn.apache.org/viewvc/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/soap/ After I switched both classes to their previous revisions the invocations started to work just like before. I was wondering if somebody can take a look at it. We are shooting for a milestone release of Geronimo next week and would be good to have basic invocations working right. Thanks, Jarek
Re: recent changes
Sorry, wrong list! :) Jarek On 2/16/07, Jarek Gawor [EMAIL PROTECTED] wrote: Hi, In the last few days something has changed in CXF that caused invocations to stop working in Geronimo. I mean, the service got invoked ok but the HTTP response from the service was empty. I tracked relevant changes to the following classes: http://svn.apache.org/viewvc/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/soap/ After I switched both classes to their previous revisions the invocations started to work just like before. I was wondering if somebody can take a look at it. We are shooting for a milestone release of Geronimo next week and would be good to have basic invocations working right. Thanks, Jarek
Re: Spring 2.0 and XBean
It is not possible to choose which version of spring to use. The reason is that you can't use both spring 1.x and 2.x at the same time, because there are too much classes that overlap and still are different. ServiceMix now uses spring 2, so the question is: why is there a spring 1.2.4 version in the classpath ? You need to remove it somehow. On Fri, 16 Feb 2007 22:26 + (GMT Standard Time), Terry Cox [EMAIL PROTECTED] wrote: This little error is causing me some fun: org.springframework.core.ConstantException: Field 'ISOLATION_' not found in class [org.springframework.transaction.TransactionDefinition] To explain, I am trying to use a POJO in a lightweight container and that POJO requires some injected dependencies that are configured using Spring 2.0. My lw-component is deployed in a service unit using the sm:serviceunit id=jbi notation and the Spring 2.0 config for the dependencies is then imported within the same servicemix.xml using import. This imported file is using AOP to wrap my injected bean in a transactional context and Spring is obviously getting close enough to doing this to generate the above error message. The reason for the error is that the Spring 2.0.1 version of TransactionDefinition declares ISOLATION_ but Spring 1.2.4 does not. Within ServiceMix, it appears that XBean defaults to Spring 1.2.4 classes rather than 2.0.1 and I cannot see how to prevent this. I have spent a pleasant evening trawling through the innards of XBean and can see that it acts as a pre-processor to Spring. Unfortunately, at the point at which a service unit is loaded in ServiceMix, the classpath for XBean is already defined and I can't see a way to influence the flavour of Spring to be used to process an individual service unit. I see that XBean has packages for a variety of Spring flavours, so I guess the question is how do I make it use the one I want?. Thanks, Terry -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
Re: recent changes
There are two XmlSchema jars from different groupId being used : A - axis2 configs - XmlSchema-1.2.jar Downloading: http://repo1.maven.org/maven2//org/apache/ws/commons/schema/XmlSchema/1.2/XmlSchema-1.2.jar 125K downloaded B - geronimo-cxf module - XmlSchema-1.1.jar Missing: -- 1) org.apache.ws.commons:XmlSchema:jar:1.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.ws.commons -DartifactId=XmlSchema \ -Dversion=1.1 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-cxf:jar:2.0-SNAPSHOT 2) org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.0-incubator-RC-SNAPSHOT 3) org.apache.cxf:cxf-api:jar:2.0-incubator-RC-SNAPSHOT 4) org.apache.ws.commons:XmlSchema:jar:1.1 Is this intentional? Thanks Anita Jarek Gawor [EMAIL PROTECTED] wrote: Hi, In the last few days something has changed in CXF that caused invocations to stop working in Geronimo. I mean, the service got invoked ok but the HTTP response from the service was empty. I tracked relevant changes to the following classes: http://svn.apache.org/viewvc/incubator/cxf/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/soap/ After I switched both classes to their previous revisions the invocations started to work just like before. I was wondering if somebody can take a look at it. We are shooting for a milestone release of Geronimo next week and would be good to have basic invocations working right. Thanks, Jarek - We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list.
Re: ClassFinder questions/problems -- annotation processing
Thanks for the info David. At times it's not obvious to me which annotations have already been implemented as part of other projects and which require Geronimo implementation changes. So I've been keeping track of them on the wiki below. The ones with a red-X or green-Checkmark in the far-right-hand column are those that I'm assuming will require Geronimo changes. I'm working on the JSR-250 set now so if you if you have a chance to review and/or verify my assumptions that would be helpful to me. http://cwiki.apache.org/confluence/display/GMOxDEV/Java+EE+5+Annotations Thanks, Tim McConnell David Blevins wrote: On Feb 15, 2007, at 9:25 PM, Tim McConnell wrote: Hi David/Dain, I finally see what's going on here now--and it really makes a lot of sense. I'm not so sure it's a bug with the classloading process so much as it's just the way the current code functions. I can't easily show a sequence diagram here but can briefly explain. It appears the the EarContext for a deployed EAR file is aggregated across successive calls from EARConfigBuilder.buildConfiguration() to the installModule() method on first the WebModuleBuilder class, and then second on the EjbModuleBuilder class. This explains why ClassFinder was working correctly in EjbRefBuilder (i.e. the deployed module's EarContext had been fully aggregated) but failed for me in AbstractWebModuleBuilder (i.e., the deployed module's EarContext had not yet been fully aggregated). That would explain a lot! Though, this does seem like an issue that should be fixed. I know DJ isn't fond of some of the hacks we've had to add in the builder process. Likely this may be the straw that broke the camels back. So, rather than fixing something that's not really broken in AbstractWebModuleBuilder, the best solution in my view is to push the Annotation processing out of the installModule processing of the module builder(s) up into the configuration builder. This would allow us to encapsulate the Annotation processing for deployed EJB applications, Web applications, App Client applications, and Connectors (not sure these would be annotated though) into a single class: EARConfigBuilder. Additionally, it would guarantee that we always have access to a fully aggregated EarContext, and thus a fully populated classloader to pass to ClassFinder. And finally, I think it would encapsulate most of the Geronimo annotation processing except for Web Services. This approach is somewhat in line with my original proposed plan for Annotation Processing for Geronimo, it's just the conduit has changed somewhat. Do either of you (or anyone else) have any thoughts, comments and/or concerns ?? That'd be fine for Web modules and App Clients -- there are no Connector annotations and EJB annotations are taken care of by OpenEJB. I know you keep wanting to do all the EJB-specific annotations, but there's no real reuse there. Web modules and Connectors pretty much both have the same stuff, which is really only the five or so JSR-250 annotations plus these from javax.ejb: @EJB(s), @PersistenceUnit, and @PersistenceContext. You can cross the rest off your list: i.e. javax.ejb @Remote, @RemoteHome, @Local, @LocalHome, @Stateless, @Stateful, @MessageDriven, @PrePassivate, @PreActivate, @Init, @Remove, @Timeout, etc. These are EJB specific and already implemented for the most part. -David Thanks, Tim McConnell Tim McConnell wrote: Hi Dain, What you suggest does make a lot of sense. But for the stateless-calculator ear file (i.e., calculator-stateless-ear-2[1].0-M2.ear) I would then expect to find the calculator-stateless-ear-2[1].0-M2.jar file on one of the parent classloaders for the WAR classloader in AbstractWebModuleBuilder. It's not, so I suspect there is a bug somewhere as you suggest. I shall investigate further tomorrow. Thanks for the pointer Dain Sundstrom wrote: On Feb 6, 2007, at 12:49 PM, David Blevins wrote: On Feb 4, 2007, at 7:19 PM, Tim McConnell wrote: Hi again Dave, after your recommendation below to do all the annotation discovery during the installModule phase of deployment ClassFinder is working much better for me. I do still have another scenario I'd appreciate some advice on. It seems that when an EJB EAR file (with embedded JAR and WAR files) gets deployed in Geronimo, there are two builders invoked: e.g., TomcatModuleBuilder/AbstractWebModuleBuilder and EJBModuleBuilder such that the embedded JAR file is not added to the ClassPath/ClassLoader when the WAR is deployed (I assume this is the way it should work since I haven't changed it--yet). So, if there are annotations in the WAR class files pointing to classes in the JAR file, we'll still encounter NoClassDefException(s). I can just add the JAR files in the EAR to the classpath of the WAR, which is what I've done to get around the problem, but I'm not sure this is the best alternative. Do you have any thoughts?? Thanks much
[jira] Created: (GERONIMO-2849) service-ref app client test
service-ref app client test --- Key: GERONIMO-2849 URL: https://issues.apache.org/jira/browse/GERONIMO-2849 Project: Geronimo Issue Type: Test Security Level: public (Regular issues) Components: webservices Reporter: Jarek Gawor The attached patch contains service-ref test for app client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2849) service-ref app client test
[ https://issues.apache.org/jira/browse/GERONIMO-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-2849: -- Attachment: GERONIMO-2849.patch service-ref app client test --- Key: GERONIMO-2849 URL: https://issues.apache.org/jira/browse/GERONIMO-2849 Project: Geronimo Issue Type: Test Security Level: public(Regular issues) Components: webservices Reporter: Jarek Gawor Attachments: GERONIMO-2849.patch The attached patch contains service-ref test for app client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2849) service-ref app client test
[ https://issues.apache.org/jira/browse/GERONIMO-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-2849: -- Attachment: GERONIMO-2849.patch Simplified the patch. service-ref app client test --- Key: GERONIMO-2849 URL: https://issues.apache.org/jira/browse/GERONIMO-2849 Project: Geronimo Issue Type: Test Security Level: public(Regular issues) Components: webservices Reporter: Jarek Gawor Attachments: GERONIMO-2849.patch, GERONIMO-2849.patch The attached patch contains service-ref test for app client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
