Re: svn commit: r550613 - in /geronimo/sandbox/portals: pluto-container/pom.xml pluto-container/src/main/resources/META-INF/geronimo-plugin.xml pluto-portal/src/main/webapp/WEB-INF/geronimo-web.xml po
Paul, all of this is for a post-2.0 release, right? -Donald [EMAIL PROTECTED] wrote: Author: pmcmahan Date: Mon Jun 25 14:22:36 2007 New Revision: 550613 URL: http://svn.apache.org/viewvc?view=rev&rev=550613 Log: move pluto-driver's spring dependency to pluto-container. this gives portal webapps access to the pluto-driver's spring context, or they can use a hidden-classes filter if they want to use their own private copy of spring Modified: geronimo/sandbox/portals/pluto-container/pom.xml geronimo/sandbox/portals/pluto-container/src/main/resources/META-INF/geronimo-plugin.xml geronimo/sandbox/portals/pluto-portal/src/main/webapp/WEB-INF/geronimo-web.xml geronimo/sandbox/portals/pom.xml Modified: geronimo/sandbox/portals/pluto-container/pom.xml URL: http://svn.apache.org/viewvc/geronimo/sandbox/portals/pluto-container/pom.xml?view=diff&rev=550613&r1=550612&r2=550613 == --- geronimo/sandbox/portals/pluto-container/pom.xml (original) +++ geronimo/sandbox/portals/pluto-container/pom.xml Mon Jun 25 14:22:36 2007 @@ -76,6 +76,26 @@ pluto-taglib + +org.springframework +spring-beans + + + +org.springframework +spring-context + + + +org.springframework +spring-core + + + +org.springframework +spring-web + + Modified: geronimo/sandbox/portals/pluto-container/src/main/resources/META-INF/geronimo-plugin.xml URL: http://svn.apache.org/viewvc/geronimo/sandbox/portals/pluto-container/src/main/resources/META-INF/geronimo-plugin.xml?view=diff&rev=550613&r1=550612&r2=550613 == --- geronimo/sandbox/portals/pluto-container/src/main/resources/META-INF/geronimo-plugin.xml (original) +++ geronimo/sandbox/portals/pluto-container/src/main/resources/META-INF/geronimo-plugin.xml Mon Jun 25 14:22:36 2007 @@ -45,6 +45,10 @@ javax.portlet/portlet-api/1.0/jar org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1-SNAPSHOT/jar org.codehaus.castor/castor/1.1.1/jar +org.springframework/spring-beans/2.0.2/jar +org.springframework/spring-context/2.0.2/jar +org.springframework/spring-core/2.0.2/jar +org.springframework/spring-web/2.0.2/jar http://people.apache.org/repo/m2-snapshot-repository/ http://repo1.maven.org/maven2/ http://www.ibiblio.org/maven2/ Modified: geronimo/sandbox/portals/pluto-portal/src/main/webapp/WEB-INF/geronimo-web.xml URL: http://svn.apache.org/viewvc/geronimo/sandbox/portals/pluto-portal/src/main/webapp/WEB-INF/geronimo-web.xml?view=diff&rev=550613&r1=550612&r2=550613 == --- geronimo/sandbox/portals/pluto-portal/src/main/webapp/WEB-INF/geronimo-web.xml (original) +++ geronimo/sandbox/portals/pluto-portal/src/main/webapp/WEB-INF/geronimo-web.xml Mon Jun 25 14:22:36 2007 @@ -40,16 +40,7 @@ car - - org.springframework - - org.apache.cxf - org.apache.axis - + Modified: geronimo/sandbox/portals/pom.xml URL: http://svn.apache.org/viewvc/geronimo/sandbox/portals/pom.xml?view=diff&rev=550613&r1=550612&r2=550613 == --- geronimo/sandbox/portals/pom.xml (original) +++ geronimo/sandbox/portals/pom.xml Mon Jun 25 14:22:36 2007 @@ -58,6 +58,7 @@ 2.0-SNAPSHOT 3.8.2 1.2.0-SNAPSHOT +2.0.2 @@ -92,6 +93,26 @@ junit junit + +junit +junit + + +org.springframework +spring-beans + + +org.springframework +spring-context + + +org.springframework +spring-core + + +org.springframework +spring-web + @@ -124,6 +145,22 @@ junit junit + +org.springframework +spring-beans + + +org.springframework +spring-context + + +org.springframework +spring-core + + +
Re: [DISCUSS] 2.0 Release Criteria
I assume this will only be for the Jetty assembly, given WADI is not used for the Tomcat assembly? Also, you mention a CXF depend, but can your WADI changes be used if the user chooses Axis2 instead of CXF for the Jetty assembly? -Donald Gianny Damour wrote: On 22/06/2007, at 2:34 AM, Matt Hogstrom wrote: We've gone through the CTS grind and came out victorious http://java.sun.com/javaee/overview/compatibility.jsp OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is working that way too. All in all its been an excellent six months. So, what are we going to do for 2.0 and getting it out the door? Here are my thoughts and we can use this thread to gather everyone else's and come to a consensus. 2.0 Ship Criteria Date: mid to end of July (a target only...depends on content) Certified Assemblies Tomcat, Axis 2 and OpenJPA Jetty, CXF and OpenJPA Other assemblies would be the minimal assemblies but cert doesn't apply to them. Work on fit and finish stuff (cleaning up error messages, improving diagnostics, reducing footprint). Personally, I'd like to see the full G have a footprint of about 40MB (that's a little over 5MB larger than 1.1.1) and Minimal be around 20MB. Need to do some research on this (volunteers?) I'm not sure how the WADI clustering presents itself across the two different assemblies (Gianny, comments?) Sorry for this late reply. I would like to enable the WADI admin console for 2.0. I have some local changes that I will commit after having sorted out a problem with a cxf JAR. In a few words, I cannot start the admin console within Geronimo due to an IllegalArgumentException: "Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface". The console works fine in standalone Jetty, which is the out-of-the-box servlet container of grails (Groovy on Rails, which is the framework of the admin console). Unfortunately, I will not be able to complete field level and method level state replication. However, nothing will have to be done within Geronimo except adding the aspectj javaagent to benefit from load-time-weaving of aspects used to track POJO instantiation and modification. On this point, if people are interested to give me a hand, then please feel free to ask and I will check in the new wadi-aop module. Thanks, Gianny Post 2.0 Items What to do about OSGi? Seems like there has been discussion but no real movement in this area. Flexible Server (there has been some discussion on the list about allowing users without a PhD in G to create their own custom assemblies. Would be neat to Create a minimal assemblie that included ServiceMix for a lightweight ESB endpoint Better monitoring and diagnosis Thoughts? smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCE] Welcome Jay McHugh as Geronimo's latest committer
Congratulations Jay! Vamsi On 6/23/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I think everyone knows Jay and I have the honor of announcing that he recently accepted an invitation to join the Apache Geronimo project. Jay has been working with Geronimo for several months now and is one of those folks that brings a great perspective of someone who not only works on the server but uses it as well. It will be great to see the contributions Jay brings to the project. Matt
[jira] Commented: (GERONIMO-3148) ActiveMQ Broker config is missing some dependencies
[
https://issues.apache.org/jira/browse/GERONIMO-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508040
]
Donald Woods commented on GERONIMO-3148:
Committed revision 550660.
Fixed comment in the plan.xml on how to use brokerUri, but did not include the
missing Spring dependencies for now...
> ActiveMQ Broker config is missing some dependencies
> ---
>
> Key: GERONIMO-3148
> URL: https://issues.apache.org/jira/browse/GERONIMO-3148
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: ActiveMQ
>Affects Versions: 2.0-M6
>Reporter: Kristian Koehler
> Attachments: active-mq-broker.patch
>
>
> Hi
> I tried to use an external config file for the embedded ActiveMQ broker. For
> this scenario the BrokerServiceGBeanImpl provides an attribute called
> 'brokerUri' where you can give an activemq.xml ('spring based') configuration.
> By setting this value ClassNotFound Exceptions are thrown because some spring
> and xbean libs are not configured correctly within the ActiveMQ broker
> configuration.
> The attached patch fixes the dependency problem and a smaller typo within the
> plan.xml.
> Kristian
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3152) Cannot redeploy or undeploy/deploy webconsole-tomcat car on geronimo-tomcat6-jee5
[ https://issues.apache.org/jira/browse/GERONIMO-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-3152. -- Resolution: Invalid Fix Version/s: (was: 2.0-M6) 2.0-M7 The solution, was to deploy the updated CAR as a plugin by using the "deploy install-plugin" option. > Cannot redeploy or undeploy/deploy webconsole-tomcat car on > geronimo-tomcat6-jee5 > - > > Key: GERONIMO-3152 > URL: https://issues.apache.org/jira/browse/GERONIMO-3152 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0-M6 > Environment: WinXP >Reporter: Donald Woods > Fix For: 2.0-M7 > > > I could not replace the webconsole-tomcat config on the geronimo-tomcat6-jee5 > assembly from Rev537224 with a locally rebuilt version - > F:\geronimo-tomcat6-jee5-2.0-SNAPSHOT\bin>deploy redeploy > webconsole-tomcat-2.0- > SNAPSHOT.car > Using GERONIMO_BASE: F:\geronimo-tomcat6-jee5-2.0-SNAPSHOT > Using GERONIMO_HOME: F:\geronimo-tomcat6-jee5-2.0-SNAPSHOT > Using GERONIMO_TMPDIR: var\temp > Using JRE_HOME:C:\PROGRA~1\Java\jdk1.5.0_11\jre > No ModuleID or TargetModuleID provided. Attempting to guess based > on the content of the archive. > Unable to locate Geronimo deployment plan in archive. Calculating > default ModuleID from archive name. > Attempting to use ModuleID > 'default/webconsole-tomcat-2.0-SNAPSHOT//' > Error: default/webconsole-tomcat-2.0-SNAPSHOT// does not appear to > be a the name of a module available on the selected server. Perhaps > it has already been stopped or undeployed? If you're trying to > specify a TargetModuleID, use the syntax TargetName|ModuleName > instead. If you're not sure what's running, try the list-modules > command. > F:\geronimo-tomcat6-jee5-2.0-SNAPSHOT\bin>deploy redeploy > webconsole-tomcat-2.0- > SNAPSHOT.car webconsole-tomcat-2.0-SNAPSHOT.xml > Using GERONIMO_BASE: F:\geronimo-tomcat6-jee5-2.0-SNAPSHOT > Using GERONIMO_HOME: F:\geronimo-tomcat6-jee5-2.0-SNAPSHOT > Using GERONIMO_TMPDIR: var\temp > Using JRE_HOME:C:\PROGRA~1\Java\jdk1.5.0_11\jre > No ModuleID or TargetModuleID provided. Attempting to guess based > on the content of the plan. > Attempting to use ModuleID > 'org.apache.geronimo.configs/webconsole-tomcat/2.0-SNAPSHOT/car' > Stopped > org.apache.geronimo.configs/webconsole-tomcat/2.0-SNAPSHOT/car > Unloaded > org.apache.geronimo.configs/webconsole-tomcat/2.0-SNAPSHOT/car > Uninstalled > org.apache.geronimo.configs/webconsole-tomcat/2.0-SNAPSHOT/car > Error: Operation failed: Module was not a war: framework.war -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3191) Can not login the remote Geronimo server on Linux
[ https://issues.apache.org/jira/browse/GERONIMO-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508036 ] Donald Woods commented on GERONIMO-3191: Can you provide more details here. Does the machine have multiple network adapters active? Have you verified there are no OS provided firewalls blocking the connection attempt? I just ran "deploy --host list-modules" on a WinXP system against a recent build (last Friday) on a remote RHEL4 server and it worked for me. > Can not login the remote Geronimo server on Linux > - > > Key: GERONIMO-3191 > URL: https://issues.apache.org/jira/browse/GERONIMO-3191 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0-M6 > Environment: Linux >Reporter: YunFeng Ma > Fix For: 2.0-M6 > > > Login the remote Geronimo server on Linux and got the following error: > deploy --host 9.186.64.184 --user system --password manager login > Error: Unable to connect to server at > deployer:geronimo:jmx://9.186.64.184 -- no such object in table > A workaround for this is that starting geronimo uses the real IP for RMI > Naming server instead of 0.0.0.0 > On Windows, the remote login works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3259) Unuseful exception stack trace in TransactionImpl.java
[ https://issues.apache.org/jira/browse/GERONIMO-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-3259. Resolution: Fixed Fix Version/s: 2.0-M7 Committed revision 550656. Thanks YunFeng. > Unuseful exception stack trace in TransactionImpl.java > -- > > Key: GERONIMO-3259 > URL: https://issues.apache.org/jira/browse/GERONIMO-3259 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.0-M7 >Reporter: YunFeng Ma >Assignee: Donald Woods > Fix For: 2.0-M7 > > Attachments: GERONIMO-3259.patch > > > When ActiveMQ client accesses an MDB in geronimo, everything works fine > except the following exception trace: > java.lang.IllegalStateException: Cannot log transactions unles XAResources > are n > amed! [EMAIL PROTECTED] > at > org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBr > anch.getResourceName(TransactionImpl.java:711) > at > org.apache.geronimo.transaction.log.HOWLLog.prepare(HOWLLog.java:254) > at > org.apache.geronimo.transaction.log.HOWLLog$$FastClassByCGLIB$$7315be > 2e.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod > Invoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio > n.java:127) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. > java:828) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 > 7) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat > ionInvoker.java:35) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro > xyMethodInterceptor.java:96) > at > org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$cb5e751f.p > repare() > at > org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepa > re(TransactionImpl.java:443) > at > org.apache.geronimo.transaction.manager.TransactionImpl.commit(Transa > ctionImpl.java:315) > at > org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit > (TransactionManagerImpl.java:264) > at > org.apache.openejb.core.transaction.TransactionPolicy.commitTransacti > on(TransactionPolicy.java:139) > at > org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired > .java:75) > at > org.apache.openejb.core.mdb.MdbContainer.afterDelivery(MdbContainer.j > ava:375) > at > org.apache.openejb.core.mdb.EndpointHandler.afterDelivery(EndpointHan > dler.java:274) > at > org.apache.openejb.core.mdb.EndpointHandler.invoke(EndpointHandler.ja > va:164) > at $Proxy35.afterDelivery(Unknown Source) > at > org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afte > rDelivery(MessageEndpointProxy.java:126) > at > org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndp > ointProxy.java:65) > at > org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionI > mpl.java:216) > at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751) > at > org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:1 > 65) > at > org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.ja > va:290) > at > org.apache.geronimo.connector.work.pool.NamedRunnable.run(NamedRunnab > le.java:32) > at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201) > at > org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(Th > readPool.java:331) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec > utor.java:665) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor > .java:690) > at java.lang.Thread.run(Thread.java:803) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3259) Unuseful exception stack trace in TransactionImpl.java
[ https://issues.apache.org/jira/browse/GERONIMO-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3259: -- Assignee: Donald Woods > Unuseful exception stack trace in TransactionImpl.java > -- > > Key: GERONIMO-3259 > URL: https://issues.apache.org/jira/browse/GERONIMO-3259 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.0-M7 >Reporter: YunFeng Ma >Assignee: Donald Woods > Attachments: GERONIMO-3259.patch > > > When ActiveMQ client accesses an MDB in geronimo, everything works fine > except the following exception trace: > java.lang.IllegalStateException: Cannot log transactions unles XAResources > are n > amed! [EMAIL PROTECTED] > at > org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBr > anch.getResourceName(TransactionImpl.java:711) > at > org.apache.geronimo.transaction.log.HOWLLog.prepare(HOWLLog.java:254) > at > org.apache.geronimo.transaction.log.HOWLLog$$FastClassByCGLIB$$7315be > 2e.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod > Invoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio > n.java:127) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. > java:828) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 > 7) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat > ionInvoker.java:35) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro > xyMethodInterceptor.java:96) > at > org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$cb5e751f.p > repare() > at > org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepa > re(TransactionImpl.java:443) > at > org.apache.geronimo.transaction.manager.TransactionImpl.commit(Transa > ctionImpl.java:315) > at > org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit > (TransactionManagerImpl.java:264) > at > org.apache.openejb.core.transaction.TransactionPolicy.commitTransacti > on(TransactionPolicy.java:139) > at > org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired > .java:75) > at > org.apache.openejb.core.mdb.MdbContainer.afterDelivery(MdbContainer.j > ava:375) > at > org.apache.openejb.core.mdb.EndpointHandler.afterDelivery(EndpointHan > dler.java:274) > at > org.apache.openejb.core.mdb.EndpointHandler.invoke(EndpointHandler.ja > va:164) > at $Proxy35.afterDelivery(Unknown Source) > at > org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afte > rDelivery(MessageEndpointProxy.java:126) > at > org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndp > ointProxy.java:65) > at > org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionI > mpl.java:216) > at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751) > at > org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:1 > 65) > at > org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.ja > va:290) > at > org.apache.geronimo.connector.work.pool.NamedRunnable.run(NamedRunnab > le.java:32) > at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201) > at > org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(Th > readPool.java:331) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec > utor.java:665) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor > .java:690) > at java.lang.Thread.run(Thread.java:803) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] 2.0 Release Criteria
On 22/06/2007, at 2:34 AM, Matt Hogstrom wrote: We've gone through the CTS grind and came out victorious http:// java.sun.com/javaee/overview/compatibility.jsp OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is working that way too. All in all its been an excellent six months. So, what are we going to do for 2.0 and getting it out the door? Here are my thoughts and we can use this thread to gather everyone else's and come to a consensus. 2.0 Ship Criteria Date: mid to end of July (a target only...depends on content) Certified Assemblies Tomcat, Axis 2 and OpenJPA Jetty, CXF and OpenJPA Other assemblies would be the minimal assemblies but cert doesn't apply to them. Work on fit and finish stuff (cleaning up error messages, improving diagnostics, reducing footprint). Personally, I'd like to see the full G have a footprint of about 40MB (that's a little over 5MB larger than 1.1.1) and Minimal be around 20MB. Need to do some research on this (volunteers?) I'm not sure how the WADI clustering presents itself across the two different assemblies (Gianny, comments?) Sorry for this late reply. I would like to enable the WADI admin console for 2.0. I have some local changes that I will commit after having sorted out a problem with a cxf JAR. In a few words, I cannot start the admin console within Geronimo due to an IllegalArgumentException: "Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface". The console works fine in standalone Jetty, which is the out-of-the-box servlet container of grails (Groovy on Rails, which is the framework of the admin console). Unfortunately, I will not be able to complete field level and method level state replication. However, nothing will have to be done within Geronimo except adding the aspectj javaagent to benefit from load- time-weaving of aspects used to track POJO instantiation and modification. On this point, if people are interested to give me a hand, then please feel free to ask and I will check in the new wadi- aop module. Thanks, Gianny Post 2.0 Items What to do about OSGi? Seems like there has been discussion but no real movement in this area. Flexible Server (there has been some discussion on the list about allowing users without a PhD in G to create their own custom assemblies. Would be neat to Create a minimal assemblie that included ServiceMix for a lightweight ESB endpoint Better monitoring and diagnosis Thoughts?
Re: Components OdeBpelEngine are not installed yet:
As recommended here it sounds like using the sun bpel-ws is the way to go? What do I need to do to install in servicemix? I followed the link, and it was informative, but no instruction on deploying to servicemix. However, it sounds like I just drop it in like all the other components? gertvanthienen wrote: > > Jbi Joe, > > > If you downloaded the JBI distribution of ODE, your download will > contain a file named ode-jbi-1.0-incubating.zip. This is actually a JBI > SE, so you can deploy it as any other JBI component, e.g. by copying it > to the install directory in the standalone ServiceMix. > > > Gert > > jbi joe wrote: >> >> Is there a howto to get it installed? I pulled the apache ODE install >> and loaded the jars to the servicemix/lib/optional dir, not luck still >> get >> error message when I try to deploy the EXAMPLE loanbroker-bpel... >> >> > > -- View this message in context: http://www.nabble.com/Components-OdeBpelEngine-are-not-installed-yet%3A-tf3971851s12049.html#a11296726 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMODEVTOOLS-171) Remove hard-coded Geronimo name from launch console message and tool-tip
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Kirby updated GERONIMODEVTOOLS-171:
---
Component/s: eclipse-plugin
> Remove hard-coded Geronimo name from launch console message and tool-tip
>
>
> Key: GERONIMODEVTOOLS-171
> URL:
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-171
> Project: Geronimo-Devtools
> Issue Type: Improvement
> Components: eclipse-plugin
>Affects Versions: 2.0
>Reporter: Ted Kirby
> Attachments: GD-171.patch
>
>
> Replace:
> console=Geronimo Console
> consoleTooltip=Apache Geronimo Console
> with:
> console={0} Console
> consoleTooltip={0} Console
> in
> eclipse-plugin\plugins\org.apache.geronimo.st.ui\src\org\apache\geronimo\st\ui\internal\Messages.properties,
> and allow the server name to be determined by server.getName().
> This allows for an extensible approach, for servers based on Geronimo. No
> change is required to support other servers.
> In this particular case,
> plugins\org.apache.geronimo.st.ui\src\org\apache\geronimo\st\ui\actions\LaunchGeronimoConsoleAction.G_SERVER_PREFIX
> is hard-coded to "org.apache.geronimo". It would be nice if this could be
> paramterized in some fashion to avoid having to replace the class in its
> entirety, just to change this value to determine if the "Launch {ServerName}
> Console" menu item should be activated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-172) Enable customization of New/Edit Server Runtime Wizard screen
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Kirby updated GERONIMODEVTOOLS-172:
---
Attachment: GD-172.patch
> Enable customization of New/Edit Server Runtime Wizard screen
> -
>
> Key: GERONIMODEVTOOLS-172
> URL:
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-172
> Project: Geronimo-Devtools
> Issue Type: Improvement
> Components: eclipse-plugin
>Affects Versions: 2.0
>Reporter: Ted Kirby
> Attachments: GD-172.patch
>
>
> The installDir label and text box have hard-coded Geronimo values:
> tooltipLoc=A location of an existing Geronimo installation or a path to
> install to.
> tooltipInstall=Downloads the selected Geronimo distribution and installs it
> to the specified location.
> replace Geronimo above with {0}.
> Code must be updated to pass in the value as getRuntimeName()
> Also, the visibility of some methods should be changed from private to at
> least protected to allow flexibility in overriding this screen for
> extension/customization.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-172) Enable customization of New/Edit Server Runtime Wizard screen
Enable customization of New/Edit Server Runtime Wizard screen
-
Key: GERONIMODEVTOOLS-172
URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-172
Project: Geronimo-Devtools
Issue Type: Improvement
Components: eclipse-plugin
Affects Versions: 2.0
Reporter: Ted Kirby
Attachments: GD-172.patch
The installDir label and text box have hard-coded Geronimo values:
tooltipLoc=A location of an existing Geronimo installation or a path to install
to.
tooltipInstall=Downloads the selected Geronimo distribution and installs it to
the specified location.
replace Geronimo above with {0}.
Code must be updated to pass in the value as getRuntimeName()
Also, the visibility of some methods should be changed from private to at least
protected to allow flexibility in overriding this screen for
extension/customization.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3262) Invert Tree button in classloader debug portlet does not work properly
Invert Tree button in classloader debug portlet does not work properly -- Key: GERONIMO-3262 URL: https://issues.apache.org/jira/browse/GERONIMO-3262 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.0-M7 Environment: macos x, firefox 2.0.0.4 Reporter: Paul McMahan Bring up the classloader viewer portlet and click on the Invert Tree button. It should show the inverted classloader tree (i.e. leaf nodes first), but instead nothing happens. If you expand the tree a little bit and then click the invert button then the tree renders correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OpenJPA moved to JAXB 2.1 and this is gonna cause trouble
I think they need to push a SNAP...the current one is still stuck on JAXB 2.1. Jeff Jay D. McHugh wrote: > I think that they just added the dep within the past couple of weeks to > support having an xml datastore. > > I just saw on the OpenJPA list that they think that they could go back > to jaxb-2.0.2. > > Would that clear up questions on certification? > > Jay > > David Blevins wrote: >> I forwarded them your note and also went digging in scm archives as to >> why they added it. We'll see what they say. >> >> Have you tried adding an exclude on jaxb in the openjpa dep? And for >> the openejb dep we could exclude openjpa itself. >> >> -David >> >> On Jun 25, 2007, at 9:11 AM, Jeff Genender wrote: >> >>> Hi, >>> >>> I am sending this to the G and OEJB lists. >>> >>> We have dependencies on OpenJPA SNAPSHOT in trunk. Looks like they >>> moved to jaxb 2.1 and this is causing troubles with building. >>> >>> First its having trouble finding javax.xml.stream:stax-api:jar:1.0-2, >>> and second, I am fairly confident this is going to impact certification. >>> >>> Thoughts? >>> >>> Jeff >>> >> >> >> >> . >>
[jira] Updated: (GERONIMODEVTOOLS-171) Remove hard-coded Geronimo name from launch console message and tool-tip
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Kirby updated GERONIMODEVTOOLS-171:
---
Attachment: GD-171.patch
> Remove hard-coded Geronimo name from launch console message and tool-tip
>
>
> Key: GERONIMODEVTOOLS-171
> URL:
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-171
> Project: Geronimo-Devtools
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Ted Kirby
> Attachments: GD-171.patch
>
>
> Replace:
> console=Geronimo Console
> consoleTooltip=Apache Geronimo Console
> with:
> console={0} Console
> consoleTooltip={0} Console
> in
> eclipse-plugin\plugins\org.apache.geronimo.st.ui\src\org\apache\geronimo\st\ui\internal\Messages.properties,
> and allow the server name to be determined by server.getName().
> This allows for an extensible approach, for servers based on Geronimo. No
> change is required to support other servers.
> In this particular case,
> plugins\org.apache.geronimo.st.ui\src\org\apache\geronimo\st\ui\actions\LaunchGeronimoConsoleAction.G_SERVER_PREFIX
> is hard-coded to "org.apache.geronimo". It would be nice if this could be
> paramterized in some fashion to avoid having to replace the class in its
> entirety, just to change this value to determine if the "Launch {ServerName}
> Console" menu item should be activated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-171) Remove hard-coded Geronimo name from launch console message and tool-tip
Remove hard-coded Geronimo name from launch console message and tool-tip
Key: GERONIMODEVTOOLS-171
URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-171
Project: Geronimo-Devtools
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Ted Kirby
Replace:
console=Geronimo Console
consoleTooltip=Apache Geronimo Console
with:
console={0} Console
consoleTooltip={0} Console
in
eclipse-plugin\plugins\org.apache.geronimo.st.ui\src\org\apache\geronimo\st\ui\internal\Messages.properties,
and allow the server name to be determined by server.getName().
This allows for an extensible approach, for servers based on Geronimo. No
change is required to support other servers.
In this particular case,
plugins\org.apache.geronimo.st.ui\src\org\apache\geronimo\st\ui\actions\LaunchGeronimoConsoleAction.G_SERVER_PREFIX
is hard-coded to "org.apache.geronimo". It would be nice if this could be
paramterized in some fashion to avoid having to replace the class in its
entirety, just to change this value to determine if the "Launch {ServerName}
Console" menu item should be activated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3261) Modify pom.xml so that J2G automatically builds a deployable when the mvn install command is issued
[ https://issues.apache.org/jira/browse/GERONIMO-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507965 ] Sachin Patel commented on GERONIMO-3261: The current packaging mechanism isn't technically incorrect. Geronimo itself has a much more complex packaging mechanism, and thus some of the default maven assembly mechnism wouldn't work for it. The current mechanism takes advantage of moduleSet's in the assembly descriptor and thus it keeps the maintaince of that file to a minium. Everything in the plugins directory will be automatically be package for inclusion in the plugins directory and same goes for the feature. If you moved the assembly as its own module, then you cannot use moduleSet's and would have to use dependency sets which you'll have to specifiy every single plugin and feature in the assembly's pom as a dependency as well redefining which subset of those you want in the assembly descriptor. > Modify pom.xml so that J2G automatically builds a deployable when the mvn > install command is issued > --- > > Key: GERONIMO-3261 > URL: https://issues.apache.org/jira/browse/GERONIMO-3261 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: J2G >Reporter: Jason Warner >Assignee: Jason Warner >Priority: Minor > > J2G currently requires the use of the assembly:assembly command line argument > to build the deployable. This should be changed to work similar to other > parts of geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3261) Modify pom.xml so that J2G automatically builds a deployable when the mvn install command is issued
Modify pom.xml so that J2G automatically builds a deployable when the mvn install command is issued --- Key: GERONIMO-3261 URL: https://issues.apache.org/jira/browse/GERONIMO-3261 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: J2G Reporter: Jason Warner Assignee: Jason Warner Priority: Minor J2G currently requires the use of the assembly:assembly command line argument to build the deployable. This should be changed to work similar to other parts of geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2994) Apache Roller plugin
[ https://issues.apache.org/jira/browse/GERONIMO-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507948 ] Peter Petersson commented on GERONIMO-2994: --- I don't really know way you get that error I haven't seen it but thats probably because you actual manage to get a bit future into the load process in G v2.0 than I have. I think that your problem regarding "having to pull in things manually" may be that you 1) missed the jun 2 geronimo-plugins.xml file. 2) didn't change the last line in that file (easy to miss). For some reason I had to add path_to_your_local_repos into the plug-in file to get it to work. I am quite new to maven so It could be that there are some other solution to this but by tracing the PluginInstallerGBean i some how ended up adding it to keep the installer on the right track. I will check out your plug-in configuration changes but I doubt it has anything to do with the problem you encountered. One thing to do is to find out what the difference is between the known to be working roller12_070602.zip G v1.2 bundle, that are using tomcat and mysql, and the current G v2.0 configuration. > Apache Roller plugin > - > > Key: GERONIMO-2994 > URL: https://issues.apache.org/jira/browse/GERONIMO-2994 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.2 >Reporter: Peter Petersson >Assignee: David Jencks >Priority: Minor > Attachments: geronimo-plugins.xml, geronimo-plugins.xml, > geronimo-plugins_070602.xml, geronimo-web.xml, geronimo-web.xml, plan.xml, > PluginInstallerGBean.patch, pom.xml, pom.xml, roller-custom.properties, > roller-custom.properties, roller-custom.properties, > roller-derbydb-plan-g1_2.xml, roller-mysql-db-plan-1-2.xml, > roller070409.patch, roller12_070602.zip, roller_g20_svn_070602.patch, > roller_plugin.patch > > > Have been working on getting Apache Roller running under Geronimo I finally > got to the point where the roller application seems to be running smoothly in > Geronimo v1.2 (current snapshot). It would be great to eventually see this > application as a plugin in G so here are pointers to resources and attached > plans. > Apache Roller v3.1 Resources (soon to be released) > Apache roller home: http://rollerweblogger.org/project/ > The bundle: http://people.apache.org/~snoopdave/apache-roller-3.1/ (until it > will be available directly via roller home) > Required jars: > https://roller.dev.java.net/servlets/ProjectDocumentList?expandFolder=6959&folderID=0 > Path to database create scripts can be found in the bundle above under: > apache-roller-3.1/webapp/roller/WEB-INF/dbscripts/ > I have tested with the derby database and mysql 5. > There is currently a issue with G v1.2 and hibernates v3.1 (used by roller > 3.1) property loader that gets a > > FATAL [HibernateRollerImpl] Error initializing Hibernate > java.lang.ClassCastException: java.util.HashSet > at > org.hibernate.util.PropertiesHelper.resolvePlaceHolders(PropertiesHelper.java:88) > > Hibernate is expecting a String value (This issue is fixed in hibernate 3.2 > with a instanceOf check) > Fortunately David Jencks hit this problem in trunk and suggested turning off > the activemq and activemq-broker modules in config.xml, to test things out, > and after that everything was running smothly :). > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Fwd: Re: OpenJPA moved to JAXB 2.1 and this is gonna cause trouble]
OpenJPA reverted back to jaxb 2.0 Jay --- Begin Message --- David, The jaxb dependency is changed to jaxb 2.0 by David Wisneski. Catalina On 6/25/07, David Blevins <[EMAIL PROTECTED]> wrote: On Jun 25, 2007, at 10:08 AM, catalina wei wrote: > David, > My XMLMaping test cases run with jaxb 2.0.2. > Would jaxb dependency change to jaxb 2.0.2 work for you ? I think that will work, thanks. Geronimo is using 2.0.5. Not sure which version EasyBeans/JOnAS may be using. -David > Catalina > > On 6/25/07, David Blevins <[EMAIL PROTECTED]> wrote: >> >> Hey guys, figured this thread belonged here. See below. >> >> I looked through the archives to see what the change related to and >> it looks like OPENJPA-240 was it. If we found a way in Geronimo to >> force OpenJPA back onto jaxb 2.0 so we could continue to certify >> javaee6 would things still work sans this feature? >> >> Also, any idea how much longer it may be for a 1.0.0 release? >> >> I know it's tough to balance user and integrator needs, so thanks in >> advance for any help. >> >> -David >> >> >> Begin forwarded message: >> >> > Resent-From: <[EMAIL PROTECTED]> >> > From: Jeff Genender <[EMAIL PROTECTED]> >> > Date: June 25, 2007 9:11:11 AM PDT >> > To: [EMAIL PROTECTED], dev@geronimo.apache.org >> > Subject: OpenJPA moved to JAXB 2.1 and this is gonna cause trouble >> > Reply-To: dev@geronimo.apache.org >> > Reply-To: [EMAIL PROTECTED] >> > >> > Hi, >> > >> > I am sending this to the G and OEJB lists. >> > >> > We have dependencies on OpenJPA SNAPSHOT in trunk. Looks like they >> > moved to jaxb 2.1 and this is causing troubles with building. >> > >> > First its having trouble finding javax.xml.stream:stax-api:jar: >> 1.0-2, >> > and second, I am fairly confident this is going to impact >> > certification. >> > >> > Thoughts? >> > >> > Jeff >> > >> >> --- End Message ---
[jira] Updated: (GERONIMO-3258) ability to delete db pools
[ https://issues.apache.org/jira/browse/GERONIMO-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3258: --- Attachment: geronimo-3258.patch This new patch checks if the chosen db pool to be deleted is associated with the system database by checking the connection url. If it is, then nothing is done. Otherwise, it attempts to undeploy it. Thanks, Viet Nguyen > ability to delete db pools > -- > > Key: GERONIMO-3258 > URL: https://issues.apache.org/jira/browse/GERONIMO-3258 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console, databases, usability >Affects Versions: 2.0-M6 > Environment: windows xp >Reporter: Viet Hung Nguyen > Attachments: geronimo-3258.patch, geronimo-3258.patch > > > Right now, there is only the option to Edit a DB Pool. It will be useful if > we can delete a DB Pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3260) JettyFilterMapping needs to allow its servlets to start after it does
[ https://issues.apache.org/jira/browse/GERONIMO-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3260. -- Resolution: Fixed Fixed in rev 550559. > JettyFilterMapping needs to allow its servlets to start after it does > - > > Key: GERONIMO-3260 > URL: https://issues.apache.org/jira/browse/GERONIMO-3260 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Jetty >Affects Versions: 2.0-M6 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.0-M7 > > > JettyFilterMapping may be started before the servlets that it depends on are > added to its reference collection. So, it needs to respond to add/remove > events and update jetty appropriately. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3260) JettyFilterMapping needs to allow its servlets to start after it does
JettyFilterMapping needs to allow its servlets to start after it does - Key: GERONIMO-3260 URL: https://issues.apache.org/jira/browse/GERONIMO-3260 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Jetty Affects Versions: 2.0-M6 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0-M7 JettyFilterMapping may be started before the servlets that it depends on are added to its reference collection. So, it needs to respond to add/remove events and update jetty appropriately. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3257) gbean dependencies should be started after collection references are updated
[ https://issues.apache.org/jira/browse/GERONIMO-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-3257: --- Description: Some excellent debugging by jgawor revealed that JettyFilterMapping was often getting started before all the servlets it depends on are started. This was causing filters to sometimes not get applied to the correct servlets. JettyModuleBuilder is adding a dependency for each servlet gbean to the filter mapping gbean, so the filter mapping wont start until after all the servlets expected to be in the collection are started. However, the "dependency" notification is getting fired before the "add to reference collection" notification, so the collections of servlets is not always correct. I think we can put some more ordering into the system so that all the reference collections are updated before dependencies are notified. --- After the obvious fix didn't work I think a whole new reference collection might be needed to really fix this. was: Some excellent debugging by jgawor revealed that JettyFilterMapping was often getting started before all the servlets it depends on are started. This was causing filters to sometimes not get applied to the correct servlets. JettyModuleBuilder is adding a dependency for each servlet gbean to the filter mapping gbean, so the filter mapping wont start until after all the servlets expected to be in the collection are started. However, the "dependency" notification is getting fired before the "add to reference collection" notification, so the collections of servlets is not always correct. I think we can put some more ordering into the system so that all the reference collections are updated before dependencies are notified. Assignee: (was: David Jencks) Issue Type: Wish (was: Bug) > gbean dependencies should be started after collection references are updated > > > Key: GERONIMO-3257 > URL: https://issues.apache.org/jira/browse/GERONIMO-3257 > Project: Geronimo > Issue Type: Wish > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 2.0-M6 >Reporter: David Jencks > Fix For: 2.0-M7 > > > Some excellent debugging by jgawor revealed that JettyFilterMapping was often > getting started before all the servlets it depends on are started. This was > causing filters to sometimes not get applied to the correct servlets. > JettyModuleBuilder is adding a dependency for each servlet gbean to the > filter mapping gbean, so the filter mapping wont start until after all the > servlets expected to be in the collection are started. However, the > "dependency" notification is getting fired before the "add to reference > collection" notification, so the collections of servlets is not always > correct. > I think we can put some more ordering into the system so that all the > reference collections are updated before dependencies are notified. > --- After the obvious fix didn't work I think a whole new reference > collection might be needed to really fix this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-3257) gbean dependencies should be started after collection references are updated
[ https://issues.apache.org/jira/browse/GERONIMO-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reopened GERONIMO-3257: It turns out that this is not foolproof. Starting the jetty webconsole sometimes results in starting a filter mapping before it's servlet has been added to the reference collection. Looking at the stack trace it looks like there are 2 or 3 levels of dependency notification going on and this sneaks around the ordering somehow. I think a more frutiful approach would be some kind of multivalued required dependency. > gbean dependencies should be started after collection references are updated > > > Key: GERONIMO-3257 > URL: https://issues.apache.org/jira/browse/GERONIMO-3257 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 2.0-M6 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.0-M7 > > > Some excellent debugging by jgawor revealed that JettyFilterMapping was often > getting started before all the servlets it depends on are started. This was > causing filters to sometimes not get applied to the correct servlets. > JettyModuleBuilder is adding a dependency for each servlet gbean to the > filter mapping gbean, so the filter mapping wont start until after all the > servlets expected to be in the collection are started. However, the > "dependency" notification is getting fired before the "add to reference > collection" notification, so the collections of servlets is not always > correct. > I think we can put some more ordering into the system so that all the > reference collections are updated before dependencies are notified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OpenJPA moved to JAXB 2.1 and this is gonna cause trouble
I think that they just added the dep within the past couple of weeks to support having an xml datastore. I just saw on the OpenJPA list that they think that they could go back to jaxb-2.0.2. Would that clear up questions on certification? Jay David Blevins wrote: I forwarded them your note and also went digging in scm archives as to why they added it. We'll see what they say. Have you tried adding an exclude on jaxb in the openjpa dep? And for the openejb dep we could exclude openjpa itself. -David On Jun 25, 2007, at 9:11 AM, Jeff Genender wrote: Hi, I am sending this to the G and OEJB lists. We have dependencies on OpenJPA SNAPSHOT in trunk. Looks like they moved to jaxb 2.1 and this is causing troubles with building. First its having trouble finding javax.xml.stream:stax-api:jar:1.0-2, and second, I am fairly confident this is going to impact certification. Thoughts? Jeff .
[jira] Closed: (GERONIMO-1470) Our context root settings should take precedence over those from application.xml
[ https://issues.apache.org/jira/browse/GERONIMO-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-1470. -- Resolution: Fixed Fix Version/s: (was: 2.0-M5) 2.0-M7 This was implemented a long time ago. In rev 550551 I made the logic a little clearer. I've decided that only allowing override in the geronimo-web plans is sufficient. I recommend that people use a single ear-wide geronimo plan with all the geronimo-web stuff embedded in it so having a separate way to specify context-root directly in the geronimo-application.xml seems to me like overkill and too confusing. > Our context root settings should take precedence over those from > application.xml > > > Key: GERONIMO-1470 > URL: https://issues.apache.org/jira/browse/GERONIMO-1470 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.0-M7 > > > Someone on IRC pointed out that the context-root setting in application.xml > is an assembly-time setting and should be overridden by the deploy-time > setting in our web plans. At the moment the application.xml setting > overrides the web plan setting. This is a trivial change, but I want to make > sure there are no objections to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OpenJPA moved to JAXB 2.1 and this is gonna cause trouble
I forwarded them your note and also went digging in scm archives as to why they added it. We'll see what they say. Have you tried adding an exclude on jaxb in the openjpa dep? And for the openejb dep we could exclude openjpa itself. -David On Jun 25, 2007, at 9:11 AM, Jeff Genender wrote: Hi, I am sending this to the G and OEJB lists. We have dependencies on OpenJPA SNAPSHOT in trunk. Looks like they moved to jaxb 2.1 and this is causing troubles with building. First its having trouble finding javax.xml.stream:stax-api:jar:1.0-2, and second, I am fairly confident this is going to impact certification. Thoughts? Jeff
[jira] Closed: (GERONIMO-906) Component references involved in transaction recovery are too complicated
[ https://issues.apache.org/jira/browse/GERONIMO-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-906. - Resolution: Fixed Fix Version/s: (was: Wish List) 2.0-M7 Rev 550546 reversed the component references. This made the code somewhat simpler. Unfortunately I let IDEA optimize all the imports in the geronimo-connector module I hope this doesn't make the change too hard to review. > Component references involved in transaction recovery are too complicated > - > > Key: GERONIMO-906 > URL: https://issues.apache.org/jira/browse/GERONIMO-906 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 1.0-M5 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.0-M7 > > > The connection manager gets a reference to the TransactionContextManager, > which ought to be enough. However, the TransactionManagerImpl has a > reference collection that the MCFWrapper registers with, the TM then calls > the recovery methods. > We should be able to move the recovery methods to TCM and have the connection > manager call them after it has started. We'll also have to look into what to > do with the MDB/inbound recovery. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2994) Apache Roller plugin
[ https://issues.apache.org/jira/browse/GERONIMO-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507911 ] David Jencks commented on GERONIMO-2994: I applied roller_g20_svn_070602.patch in rev 550529 with some modifications to the dependencies. I haven't gotten to the hibernate system properties problem yet. I also note that I missed the june 2 geronimo-plugins.xml file I'll see if that makes a difference... Problems I'm having: 1. plugin installation doesn't pull any dependencies in from my local repo. I don't know if this is due to bad plugin.xml or a defect in the plugin installer. Anyway at the moment I have to copy all the dependencies in myself. 2. the roller plugin installs but does not start. I get this error some time after hibernate appears to have processed all the mapping files correctly.: 19:23:53,476 INFO [RollerFactory] Using Roller Impl: org.apache.roller.business.hibernate.HibernateRollerImpl 19:23:53,483 FATAL [HibernatePropertiesManagerImpl] Failed to initialize runtime configuration properties.Please check that the database has been upgraded! org.apache.roller.RollerException at org.apache.roller.business.hibernate.HibernatePropertiesManagerImpl.getProperties(HibernatePropertiesManagerImpl.java:115) at org.apache.roller.business.hibernate.HibernatePropertiesManagerImpl.init(HibernatePropertiesManagerImpl.java:147) at org.apache.roller.business.hibernate.HibernatePropertiesManagerImpl.(HibernatePropertiesManagerImpl.java:70) at org.apache.roller.business.hibernate.HibernateRollerImpl.getPropertiesManager(HibernateRollerImpl.java:199) at org.apache.roller.ui.core.RollerContext.setupRollerProperties(RollerContext.java:235) at org.apache.roller.ui.core.RollerContext.contextInitialized(RollerContext.java:172) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:530) at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1218) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:500) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.doStart(AbstractImmutableHandler.java:38) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.apache.geronimo.jetty6.JettyWebAppContext$StartCommand.lifecycleMethod(JettyWebAppContext.java:390) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:54) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.lifecycleCommand(ThreadClassloaderHandler.java:57) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:52) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.lifecycleCommand(InstanceContextHandler.java:81) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:52) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.lifecycleCommand(UserTransactionHandler.java:63) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:52) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.lifecycleCommand(ComponentContextHandler.java:57) at org.apache.geronimo.jetty6.JettyWebAppContext.doStart(JettyWebAppContext.java:359) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) 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:553) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:511) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastC
OpenJPA moved to JAXB 2.1 and this is gonna cause trouble
Hi, I am sending this to the G and OEJB lists. We have dependencies on OpenJPA SNAPSHOT in trunk. Looks like they moved to jaxb 2.1 and this is causing troubles with building. First its having trouble finding javax.xml.stream:stax-api:jar:1.0-2, and second, I am fairly confident this is going to impact certification. Thoughts? Jeff
[jira] Commented: (GERONIMO-3258) ability to delete db pools
[ https://issues.apache.org/jira/browse/GERONIMO-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507902 ] Jay D. McHugh commented on GERONIMO-3258: - I took a quick look at this and it does work to delete database pools. But, there should be some protection added to prevent the user from deleting one of the 'built in' pools (NoTxDatasource and SystemDatasource) otherwise the system can be made unusable. (BTW, there was a way to delete datasources - But it was in the un-obvious location of 'J2EE Connectors'. Being able to delete database pools from the database pool screen is much more user-friendly) > ability to delete db pools > -- > > Key: GERONIMO-3258 > URL: https://issues.apache.org/jira/browse/GERONIMO-3258 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console, databases, usability >Affects Versions: 2.0-M6 > Environment: windows xp >Reporter: Viet Hung Nguyen > Attachments: geronimo-3258.patch > > > Right now, there is only the option to Edit a DB Pool. It will be useful if > we can delete a DB Pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Why printStackTrace() in the source codes
On Jun 25, 2007, at 7:59 AM, YunFeng Ma wrote: I just had a search of "printStackTrace()" to the geronimo source codes and found some classes use this code. Why don't use org.apache.commons.logging.Log to trace the exception. org.apache.commons.logging.Log can print the exception stack trace in the console and at same time save it to geronimo.log. It will be very useful for users once he/she closed the geronimo console or he/she run geronimo as daemon process. What's your thought? If you think it's useful, I'll provide a patch. Not having looked, if the code is not junit/testsuite code and it's running after we've set up our logging config, then I'd agree that it should not be using printStackTrace to print to STDERR. Create a jira and attach your patch... --kevan
Re: [ANNOUNCE] Welcome Jay McHugh as Geronimo's latest committer
Congrats Jay! Best wishes, Paul On Jun 22, 2007, at 11:49 PM, Matt Hogstrom wrote: I think everyone knows Jay and I have the honor of announcing that he recently accepted an invitation to join the Apache Geronimo project. Jay has been working with Geronimo for several months now and is one of those folks that brings a great perspective of someone who not only works on the server but uses it as well. It will be great to see the contributions Jay brings to the project. Matt
Re: [ANNOUNCE] Welcome Lin Sun as our newest committer
Congrats Lin! Best wishes, Paul On Jun 21, 2007, at 2:32 PM, Davanum Srinivas wrote: Folks, We're pleased to let you know that we have a new committer in our midst. Lin Sun has been active on the Web Services integration for Geronimo for quite some time and has accepted our invitation to join the Geronimo project as a committer. Many Many apologies to Lin for the delay in announcing her as a committer!! thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com
Re: [ANNOUNCE] Welcome Tim McConnell as our newest committer
Congrats Tim! Best wishes, Paul On Jun 21, 2007, at 6:36 PM, David Blevins wrote: All, The Geronimo PMC is pleased to announce that Tim McConnell has recently accepted our invitation to become an Apache Geronimo committer. Tim has done some great work in 2.0 with regards to annotation processing and was a definite asset in completing the JavaEE 5 functionality. We're thrilled to hand him a committer hat and look forward to his continued contributions to the project and to other contributors who wish to walk the same road he did. Welcome aboard, Tim! -David
[jira] Updated: (GERONIMO-3259) Unuseful exception stack trace in TransactionImpl.java
[
https://issues.apache.org/jira/browse/GERONIMO-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
YunFeng Ma updated GERONIMO-3259:
-
Attachment: GERONIMO-3259.patch
Replaced the following line:
new IllegalStateException("Cannot log transactions unles XAResources are
named! " + committer).printStackTrace();
to:
log.warn( "Cannot log transactions unles XAResources are named! " +
committer );
> Unuseful exception stack trace in TransactionImpl.java
> --
>
> Key: GERONIMO-3259
> URL: https://issues.apache.org/jira/browse/GERONIMO-3259
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
>Affects Versions: 2.0-M7
>Reporter: YunFeng Ma
> Attachments: GERONIMO-3259.patch
>
>
> When ActiveMQ client accesses an MDB in geronimo, everything works fine
> except the following exception trace:
> java.lang.IllegalStateException: Cannot log transactions unles XAResources
> are n
> amed! [EMAIL PROTECTED]
> at
> org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBr
> anch.getResourceName(TransactionImpl.java:711)
> at
> org.apache.geronimo.transaction.log.HOWLLog.prepare(HOWLLog.java:254)
> at
> org.apache.geronimo.transaction.log.HOWLLog$$FastClassByCGLIB$$7315be
> 2e.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod
> Invoker.java:38)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
> n.java:127)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
> java:828)
> at
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5
> 7)
> at
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat
> ionInvoker.java:35)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro
> xyMethodInterceptor.java:96)
> at
> org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$cb5e751f.p
> repare()
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepa
> re(TransactionImpl.java:443)
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(Transa
> ctionImpl.java:315)
> at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit
> (TransactionManagerImpl.java:264)
> at
> org.apache.openejb.core.transaction.TransactionPolicy.commitTransacti
> on(TransactionPolicy.java:139)
> at
> org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired
> .java:75)
> at
> org.apache.openejb.core.mdb.MdbContainer.afterDelivery(MdbContainer.j
> ava:375)
> at
> org.apache.openejb.core.mdb.EndpointHandler.afterDelivery(EndpointHan
> dler.java:274)
> at
> org.apache.openejb.core.mdb.EndpointHandler.invoke(EndpointHandler.ja
> va:164)
> at $Proxy35.afterDelivery(Unknown Source)
> at
> org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afte
> rDelivery(MessageEndpointProxy.java:126)
> at
> org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndp
> ointProxy.java:65)
> at
> org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionI
> mpl.java:216)
> at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
> at
> org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:1
> 65)
> at
> org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.ja
> va:290)
> at
> org.apache.geronimo.connector.work.pool.NamedRunnable.run(NamedRunnab
> le.java:32)
> at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201)
> at
> org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(Th
> readPool.java:331)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
> utor.java:665)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> .java:690)
> at java.lang.Thread.run(Thread.java:803)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Why printStackTrace() in the source codes
I just had a search of "printStackTrace()" to the geronimo source codes and found some classes use this code. Why don't use org.apache.commons.logging.Log to trace the exception. org.apache.commons.logging.Log can print the exception stack trace in the console and at same time save it to geronimo.log. It will be very useful for users once he/she closed the geronimo console or he/she run geronimo as daemon process. What's your thought? If you think it's useful, I'll provide a patch. Thanks YunFeng Ma Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091
[jira] Created: (GERONIMO-3259) Unuseful exception stack trace in TransactionImpl.java
Unuseful exception stack trace in TransactionImpl.java -- Key: GERONIMO-3259 URL: https://issues.apache.org/jira/browse/GERONIMO-3259 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: transaction manager Affects Versions: 2.0-M7 Reporter: YunFeng Ma When ActiveMQ client accesses an MDB in geronimo, everything works fine except the following exception trace: java.lang.IllegalStateException: Cannot log transactions unles XAResources are n amed! [EMAIL PROTECTED] at org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBr anch.getResourceName(TransactionImpl.java:711) at org.apache.geronimo.transaction.log.HOWLLog.prepare(HOWLLog.java:254) at org.apache.geronimo.transaction.log.HOWLLog$$FastClassByCGLIB$$7315be 2e.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:828) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$cb5e751f.p repare() at org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepa re(TransactionImpl.java:443) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(Transa ctionImpl.java:315) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit (TransactionManagerImpl.java:264) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransacti on(TransactionPolicy.java:139) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired .java:75) at org.apache.openejb.core.mdb.MdbContainer.afterDelivery(MdbContainer.j ava:375) at org.apache.openejb.core.mdb.EndpointHandler.afterDelivery(EndpointHan dler.java:274) at org.apache.openejb.core.mdb.EndpointHandler.invoke(EndpointHandler.ja va:164) at $Proxy35.afterDelivery(Unknown Source) at org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afte rDelivery(MessageEndpointProxy.java:126) at org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndp ointProxy.java:65) at org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionI mpl.java:216) at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751) at org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:1 65) at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.ja va:290) at org.apache.geronimo.connector.work.pool.NamedRunnable.run(NamedRunnab le.java:32) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(Th readPool.java:331) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec utor.java:665) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:690) at java.lang.Thread.run(Thread.java:803) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-972) authenticationService is null - Several SA deployed on the same instance of Smx
[ https://issues.apache.org/activemq/browse/SM-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39510 ] Guillaume Nodet commented on SM-972: Fix at rev 550456. Please reopen the issue if the problem still exist. > authenticationService is null - Several SA deployed on the same instance of > Smx > --- > > Key: SM-972 > URL: https://issues.apache.org/activemq/browse/SM-972 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-soap >Affects Versions: 3.1 > Environment: Linux Redhat EL 4 >Reporter: Noseda Anne >Assignee: Guillaume Nodet >Priority: Blocker > Fix For: 3.2 > > > We've deployed 2 sa on the same instance of Smx. > There both work when they are deployed alone. > But when they are deployed together, the second sa returns the following > error : > > http://www.w3.org/2003/05/soap-envelope";> > > > > soapenv:Receiver > > > java.lang.IllegalArgumentException: > authenticationService is null > > > > > Then, we send a request to the first sa, it works then to the second sa and > the error changes : > > http://www.w3.org/2003/05/soap-envelope";> > > > > soapenv:Receiver > > > java.lang.SecurityException: Endpoint is not > authorized for this user > > > > > It seems something is overwrited ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-972) authenticationService is null - Several SA deployed on the same instance of Smx
[ https://issues.apache.org/activemq/browse/SM-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-972. Resolution: Fixed Fix Version/s: 3.2 Assignee: Guillaume Nodet > authenticationService is null - Several SA deployed on the same instance of > Smx > --- > > Key: SM-972 > URL: https://issues.apache.org/activemq/browse/SM-972 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-soap >Affects Versions: 3.1 > Environment: Linux Redhat EL 4 >Reporter: Noseda Anne >Assignee: Guillaume Nodet >Priority: Blocker > Fix For: 3.2 > > > We've deployed 2 sa on the same instance of Smx. > There both work when they are deployed alone. > But when they are deployed together, the second sa returns the following > error : > > http://www.w3.org/2003/05/soap-envelope";> > > > > soapenv:Receiver > > > java.lang.IllegalArgumentException: > authenticationService is null > > > > > Then, we send a request to the first sa, it works then to the second sa and > the error changes : > > http://www.w3.org/2003/05/soap-envelope";> > > > > soapenv:Receiver > > > java.lang.SecurityException: Endpoint is not > authorized for this user > > > > > It seems something is overwrited ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-979) Remove the mx4h dependency in org.apache.servicemix.jmx.PasswordAuthenticator
Remove the mx4h dependency in org.apache.servicemix.jmx.PasswordAuthenticator - Key: SM-979 URL: https://issues.apache.org/activemq/browse/SM-979 Project: ServiceMix Issue Type: Bug Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Question about getting two GBeans to talk with each other
You need to include a GBeanTwo reference in the GBeanOne gbean info
and in the plans, for gbean one assign it to the instance of gbean two.
Also you need to either put both gbeans in one plan (the easy way) or
have the gbean one plan depend on the gbean two plan (the hard way).
Studying the geronimo gbeans and plans may be more informative than
words.
thanks
david jencks
On Jun 24, 2007, at 7:05 PM, Ajay Panagariya wrote:
Hi,
I'm trying to get two GBeans to talk with eachother. This is the
place I got most of my information from...:
http://cwiki.apache.org/GMOxDEV/gbeansarticle1.html
Some of my code below draws on examples provided in a sample zip
file available on the site, which I was unable to compile.
As I understand it, two GBeans can be made to talk to eachother
through an interface.
So, in my code
GBeantwo implements an interface(called MyInterface.java) with a
single method called 'doit()'
I would like GBeanone to be able to call doit(). In the toy example
I'm trying to construct for myself, I deploy GBeantwo first
(because Gbeanone has dependency on GBeantwo).
Here is the code for GBeantwo:
public class GBeantwo implements MyInterface {
public static final GBeanInfo GBEAN_INFO;
private final ObjectName objectName;
static {
GBeanInfoBuilder infoBuilder = new GBeanInfoBuilder
("GBeantwo", GBeantwo.class);
// attributes
infoBuilder.addAttribute("objectName", String.class, false);
//interfaces
infoBuilder.addInterface(MyInterface.class);
// constructor
infoBuilder.setConstructor(new String[]{"objectName"});
GBEAN_INFO = infoBuilder.getBeanInfo();
}
public GBeantwo(String objectName){
this.objectName = ObjectNameUtil.getObjectName(objectName);
}
public static GBeanInfo getGBeanInfo() {
return GBEAN_INFO;
}
public void doit(){
System.out.println("[GBean2] inside doit()");
//Calc.add(2,3);
}
}
Here is the code for GBeanone:
public class GBeanone{
public static final GBeanInfo GBEAN_INFO;
private final ObjectName objectName;
private final MyInterface myInterface;
static {
GBeanInfoBuilder infoBuilder = new GBeanInfoBuilder
("GBeanone", GBeanone.class);
// attributes
infoBuilder.addAttribute("objectName", String.class, false);
//interfaces
infoBuilder.addReference("MyInterface",MyInterface.class );
// constructor
infoBuilder.setConstructor(new String[]
{"objectName","MyInterface"});
GBEAN_INFO = infoBuilder.getBeanInfo();
}
public GBeanone(String objectName,MyInterface myInterface) {
this.objectName = ObjectNameUtil.getObjectName(objectName);
this.myInterface = myInterface;
myInterface.doit();
}
public static GBeanInfo getGBeanInfo() {
return GBEAN_INFO;
}
}
Here is the code for MyInterface interface:
public interface MyInterface {
public void doit();
}
And these are the individual deployment plans:
For GBeanone:
http://geronimo.apache.org/xml/ns/deployment-1.2";>
example1.talking
gbeanone
2.0-SNAPSHOT
car
For GBeantwo:
http://geronimo.apache.org/xml/ns/deployment-1.2 ">
example1.talking
gbeantwo
2.0-SNAPSHOT
car
GBeantwo deploys with no problem. But when I deploy GBeanone, the
MyInterface.doit() call causes the following to show up on the
console:
$ target/geronimo-tomcat6-jee5-2.0-SNAPSHOT/bin/deploy.bat deploy
gbean1.jar example1/talking/gbeanone-plan.xml
Using GERONIMO_BASE: C:\g\target\geronimo- tomcat6-jee5-2.0-SNAPSHOT
Using GERONIMO_HOME: C:\g\target\geronimo-tomcat6-jee5-2.0-SNAPSHOT
Using GERONIMO_TMPDIR: var\temp
Using JRE_HOME:C:\Program Files\Java\jdk1.5.0_12\jre
org.apache.geronimo.kernel.config.LifecycleException : start of
example1.talking/gbeanone/2.0-SNAPSHOT/car failed
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf
iguration(SimpleConfigurationManager.java:547)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf
iguration (SimpleConfigurationManager.java:511)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager$
$FastClassByCGLIB$$ce77a924.invoke()
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:863)
at org.apache.geronimo.kernel.basic.BasicKernel.invoke
(BasicKernel.java:239)
at org.apache.geronimo.kernel.KernelGBean.invoke
(KernelGBean.java:342)
Re: Hello All
Thanks Nodet.
Freeman
Guillaume Nodet wrote:
The patch was good (except for a few tabs that slipped in) so I have
checked
it in.
Thanks !
On 6/25/07, Freeman Fang <[EMAIL PROTECTED]> wrote:
Ok, it's done.
Cheers
Freeman
Guillaume Nodet wrote:
> Could you please attach your patch to a JIRA issue ?
> You can reuse the existing one:
> http://issues.apache.org/activemq/browse/SM-939
> Thanks !
>
> On 6/25/07, Freeman Fang <[EMAIL PROTECTED]> wrote:
>>
>> Hi All,
>>
>> I'd like to provide my first patch as the start.
>>
>> This patch is based on Nodet's cxf bc module, and fix compile and
test
>> failure which is caused by cxf api changed.
>>
>> Please review and apply this patch for me.
>>
>> Tons of thanks
>>
>> Freeman
>>
>> Freeman Fang wrote:
>> > Hi all,
>> >
>> > I am from apache cxf team.
>> >
>> > I am going to add cxf binding component into servicemix which can
>> > support ws-*.
>> >
>> > In next several weeks there would be questions and patches.
>> >
>> > Thanks in advance for answering my questions and reviewing and
>> > applying the patches.
>> >
>> > Thanks again
>> >
>> > Freeman
>> >
>>
>>
>> Index:
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
>>
>> ===
>> ---
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
>>
>> (revision 550382)
>> +++
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
>>
>> (working copy)
>> @@ -37,8 +37,7 @@
>> public class JbiOperationInterceptor extends
>> AbstractPhaseInterceptor {
>>
>> public JbiOperationInterceptor() {
>> -super();
>> -setPhase(Phase.UNMARSHAL);
>> + super(Phase.UNMARSHAL);
>> addAfter(URIMappingInterceptor.class.getName());
>> }
>>
>> Index:
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
>>
>> ===
>> ---
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
>>
>> (revision 550382)
>> +++
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
>>
>> (working copy)
>> @@ -37,6 +37,7 @@
>> import org.apache.cxf.binding.soap.model.SoapBindingInfo;
>> import org.apache.cxf.binding.soap.model.SoapHeaderInfo;
>> import org.apache.cxf.endpoint.Endpoint;
>> +import org.apache.cxf.headers.Header;
>> import org.apache.cxf.interceptor.Fault;
>> import org.apache.cxf.message.Exchange;
>> import org.apache.cxf.message.Message;
>> @@ -56,7 +57,7 @@
>> public class JbiInWsdl1Interceptor extends AbstractSoapInterceptor {
>>
>> public JbiInWsdl1Interceptor() {
>> -setPhase(Phase.UNMARSHAL);
>> +super(Phase.UNMARSHAL);
>> addAfter(JbiOperationInterceptor.class.getName());
>> }
>>
>> @@ -104,7 +105,7 @@
>> }
>> Element body = getBodyElement(message);
>> List headers = wsdlMessage.getExtensors(
>> SoapHeaderInfo.class);
>> -Element headerElement = message.getHeaders(Element.class);
>> +List headerElement = message.getHeaders();
>> List parts = new ArrayList();
>> for (MessagePartInfo part : wsdlMessage.getMessageParts()) {
>> if ("document".equals(style)) {
>> @@ -129,10 +130,10 @@
>> if (headers != null) {
>> for (SoapHeaderInfo header : headers) {
>> MessagePartInfo part = header.getPart();
>> -Element param = findHeader(headerElement, part);
>> +Header param = findHeader(headerElement, part);
>> int idx = part.getIndex();
>> QName element = part.getElementQName();
>> -Element hdr = getHeaderElement(message, element);
>> +Header hdr = getHeaderElement(message, element);
>> if (hdr == null) {
>> throw new Fault(new Exception("Missing required
>> header element: "
>> + QNameUtil.toString(element)));
>> @@ -190,7 +191,7 @@
>> }
>> }
>>
>> -protected Element getHeaderElement(SoapMessage message, QName
>> name) {
>> +protected Header getHeaderElement(SoapMessage message, QName
>> name) {
>> Exchange exchange = message.getExchange();
>> BindingOperationInfo bop = exchange.get(
>> BindingOperationInfo.class);
>> if (bop.isUnwrapped()) {
>> @@ -206,11 +207,11 @@
>> if (headers == null || headers.size() == 0) {
>> return null;
>> }
>> -Element headerElement = message.getHeaders(Element.class
[jira] Assigned: (SM-969) JBIMarshaler doesn't copy Subject from NormalizedMessage to SoapMessage
[ https://issues.apache.org/activemq/browse/SM-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SM-969: -- Assignee: Adrian Co > JBIMarshaler doesn't copy Subject from NormalizedMessage to SoapMessage > --- > > Key: SM-969 > URL: https://issues.apache.org/activemq/browse/SM-969 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-soap >Reporter: Piotr Bzdyl >Assignee: Adrian Co > Attachments: JBIMarshaler.java.diff > > > JBIMarshaler doesn't copy Subject from NormalizedMessage to SoapMessage so > the information about the subject is lost. It does so in opposite way (from > SoapMessage to NormalizedMessage). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Hello All
The patch was good (except for a few tabs that slipped in) so I have checked
it in.
Thanks !
On 6/25/07, Freeman Fang <[EMAIL PROTECTED]> wrote:
Ok, it's done.
Cheers
Freeman
Guillaume Nodet wrote:
> Could you please attach your patch to a JIRA issue ?
> You can reuse the existing one:
> http://issues.apache.org/activemq/browse/SM-939
> Thanks !
>
> On 6/25/07, Freeman Fang <[EMAIL PROTECTED]> wrote:
>>
>> Hi All,
>>
>> I'd like to provide my first patch as the start.
>>
>> This patch is based on Nodet's cxf bc module, and fix compile and test
>> failure which is caused by cxf api changed.
>>
>> Please review and apply this patch for me.
>>
>> Tons of thanks
>>
>> Freeman
>>
>> Freeman Fang wrote:
>> > Hi all,
>> >
>> > I am from apache cxf team.
>> >
>> > I am going to add cxf binding component into servicemix which can
>> > support ws-*.
>> >
>> > In next several weeks there would be questions and patches.
>> >
>> > Thanks in advance for answering my questions and reviewing and
>> > applying the patches.
>> >
>> > Thanks again
>> >
>> > Freeman
>> >
>>
>>
>> Index:
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
>>
>> ===
>> ---
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
>>
>> (revision 550382)
>> +++
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
>>
>> (working copy)
>> @@ -37,8 +37,7 @@
>> public class JbiOperationInterceptor extends
>> AbstractPhaseInterceptor {
>>
>> public JbiOperationInterceptor() {
>> -super();
>> -setPhase(Phase.UNMARSHAL);
>> + super(Phase.UNMARSHAL);
>> addAfter(URIMappingInterceptor.class.getName());
>> }
>>
>> Index:
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
>>
>> ===
>> ---
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
>>
>> (revision 550382)
>> +++
>>
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
>>
>> (working copy)
>> @@ -37,6 +37,7 @@
>> import org.apache.cxf.binding.soap.model.SoapBindingInfo;
>> import org.apache.cxf.binding.soap.model.SoapHeaderInfo;
>> import org.apache.cxf.endpoint.Endpoint;
>> +import org.apache.cxf.headers.Header;
>> import org.apache.cxf.interceptor.Fault;
>> import org.apache.cxf.message.Exchange;
>> import org.apache.cxf.message.Message;
>> @@ -56,7 +57,7 @@
>> public class JbiInWsdl1Interceptor extends AbstractSoapInterceptor {
>>
>> public JbiInWsdl1Interceptor() {
>> -setPhase(Phase.UNMARSHAL);
>> +super(Phase.UNMARSHAL);
>> addAfter(JbiOperationInterceptor.class.getName());
>> }
>>
>> @@ -104,7 +105,7 @@
>> }
>> Element body = getBodyElement(message);
>> List headers = wsdlMessage.getExtensors(
>> SoapHeaderInfo.class);
>> -Element headerElement = message.getHeaders(Element.class);
>> +List headerElement = message.getHeaders();
>> List parts = new ArrayList();
>> for (MessagePartInfo part : wsdlMessage.getMessageParts()) {
>> if ("document".equals(style)) {
>> @@ -129,10 +130,10 @@
>> if (headers != null) {
>> for (SoapHeaderInfo header : headers) {
>> MessagePartInfo part = header.getPart();
>> -Element param = findHeader(headerElement, part);
>> +Header param = findHeader(headerElement, part);
>> int idx = part.getIndex();
>> QName element = part.getElementQName();
>> -Element hdr = getHeaderElement(message, element);
>> +Header hdr = getHeaderElement(message, element);
>> if (hdr == null) {
>> throw new Fault(new Exception("Missing required
>> header element: "
>> + QNameUtil.toString(element)));
>> @@ -190,7 +191,7 @@
>> }
>> }
>>
>> -protected Element getHeaderElement(SoapMessage message, QName
>> name) {
>> +protected Header getHeaderElement(SoapMessage message, QName
>> name) {
>> Exchange exchange = message.getExchange();
>> BindingOperationInfo bop = exchange.get(
>> BindingOperationInfo.class);
>> if (bop.isUnwrapped()) {
>> @@ -206,11 +207,11 @@
>> if (headers == null || headers.size() == 0) {
>> return null;
>> }
>> -Element headerElement = message.getHeaders(Element.class);
>> +List headerElement = message.getHeaders();
>>
[jira] Updated: (SM-939) CXF based Service Engine and Bnding Component
[ https://issues.apache.org/activemq/browse/SM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated SM-939: Attachment: patch.txt I'd like to provide my first patch as the start. This patch is based on Nodet's cxf bc module, and fix compile and test failure which is caused by cxf api changed. Please review and apply this patch for me. > CXF based Service Engine and Bnding Component > - > > Key: SM-939 > URL: https://issues.apache.org/activemq/browse/SM-939 > Project: ServiceMix > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Freeman Fang >Priority: Critical > Fix For: 3.2 > > Attachments: patch.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Hello All
Ok, it's done.
Cheers
Freeman
Guillaume Nodet wrote:
Could you please attach your patch to a JIRA issue ?
You can reuse the existing one:
http://issues.apache.org/activemq/browse/SM-939
Thanks !
On 6/25/07, Freeman Fang <[EMAIL PROTECTED]> wrote:
Hi All,
I'd like to provide my first patch as the start.
This patch is based on Nodet's cxf bc module, and fix compile and test
failure which is caused by cxf api changed.
Please review and apply this patch for me.
Tons of thanks
Freeman
Freeman Fang wrote:
> Hi all,
>
> I am from apache cxf team.
>
> I am going to add cxf binding component into servicemix which can
> support ws-*.
>
> In next several weeks there would be questions and patches.
>
> Thanks in advance for answering my questions and reviewing and
> applying the patches.
>
> Thanks again
>
> Freeman
>
Index:
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
===
---
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
(revision 550382)
+++
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
(working copy)
@@ -37,8 +37,7 @@
public class JbiOperationInterceptor extends
AbstractPhaseInterceptor {
public JbiOperationInterceptor() {
-super();
-setPhase(Phase.UNMARSHAL);
+ super(Phase.UNMARSHAL);
addAfter(URIMappingInterceptor.class.getName());
}
Index:
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
===
---
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
(revision 550382)
+++
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
(working copy)
@@ -37,6 +37,7 @@
import org.apache.cxf.binding.soap.model.SoapBindingInfo;
import org.apache.cxf.binding.soap.model.SoapHeaderInfo;
import org.apache.cxf.endpoint.Endpoint;
+import org.apache.cxf.headers.Header;
import org.apache.cxf.interceptor.Fault;
import org.apache.cxf.message.Exchange;
import org.apache.cxf.message.Message;
@@ -56,7 +57,7 @@
public class JbiInWsdl1Interceptor extends AbstractSoapInterceptor {
public JbiInWsdl1Interceptor() {
-setPhase(Phase.UNMARSHAL);
+super(Phase.UNMARSHAL);
addAfter(JbiOperationInterceptor.class.getName());
}
@@ -104,7 +105,7 @@
}
Element body = getBodyElement(message);
List headers = wsdlMessage.getExtensors(
SoapHeaderInfo.class);
-Element headerElement = message.getHeaders(Element.class);
+List headerElement = message.getHeaders();
List parts = new ArrayList();
for (MessagePartInfo part : wsdlMessage.getMessageParts()) {
if ("document".equals(style)) {
@@ -129,10 +130,10 @@
if (headers != null) {
for (SoapHeaderInfo header : headers) {
MessagePartInfo part = header.getPart();
-Element param = findHeader(headerElement, part);
+Header param = findHeader(headerElement, part);
int idx = part.getIndex();
QName element = part.getElementQName();
-Element hdr = getHeaderElement(message, element);
+Header hdr = getHeaderElement(message, element);
if (hdr == null) {
throw new Fault(new Exception("Missing required
header element: "
+ QNameUtil.toString(element)));
@@ -190,7 +191,7 @@
}
}
-protected Element getHeaderElement(SoapMessage message, QName
name) {
+protected Header getHeaderElement(SoapMessage message, QName
name) {
Exchange exchange = message.getExchange();
BindingOperationInfo bop = exchange.get(
BindingOperationInfo.class);
if (bop.isUnwrapped()) {
@@ -206,11 +207,11 @@
if (headers == null || headers.size() == 0) {
return null;
}
-Element headerElement = message.getHeaders(Element.class);
+List headerElement = message.getHeaders();
for (SoapHeaderInfo header : headers) {
if (header.getPart().getElementQName().equals(name)) {
MessagePartInfo mpi = header.getPart();
-Element param = findHeader(headerElement, mpi);
+Header param = findHeader(headerElement, mpi);
return param;
}
}
@@ -236,18 +237,16 @@
}
}
-private static Element findHeader(Element headerElement,
MessagePartInfo mpi) {
-NodeList nodeList =
Re: Hello All
Could you please attach your patch to a JIRA issue ?
You can reuse the existing one:
http://issues.apache.org/activemq/browse/SM-939
Thanks !
On 6/25/07, Freeman Fang <[EMAIL PROTECTED]> wrote:
Hi All,
I'd like to provide my first patch as the start.
This patch is based on Nodet's cxf bc module, and fix compile and test
failure which is caused by cxf api changed.
Please review and apply this patch for me.
Tons of thanks
Freeman
Freeman Fang wrote:
> Hi all,
>
> I am from apache cxf team.
>
> I am going to add cxf binding component into servicemix which can
> support ws-*.
>
> In next several weeks there would be questions and patches.
>
> Thanks in advance for answering my questions and reviewing and
> applying the patches.
>
> Thanks again
>
> Freeman
>
Index:
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
===
---
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
(revision 550382)
+++
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiOperationInterceptor.java
(working copy)
@@ -37,8 +37,7 @@
public class JbiOperationInterceptor extends
AbstractPhaseInterceptor {
public JbiOperationInterceptor() {
-super();
-setPhase(Phase.UNMARSHAL);
+ super(Phase.UNMARSHAL);
addAfter(URIMappingInterceptor.class.getName());
}
Index:
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
===
---
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
(revision 550382)
+++
deployables/bindingcomponents/servicemix-cxf-bc/src/main/java/org/apache/servicemix/cxfbc/interceptors/JbiInWsdl1Interceptor.java
(working copy)
@@ -37,6 +37,7 @@
import org.apache.cxf.binding.soap.model.SoapBindingInfo;
import org.apache.cxf.binding.soap.model.SoapHeaderInfo;
import org.apache.cxf.endpoint.Endpoint;
+import org.apache.cxf.headers.Header;
import org.apache.cxf.interceptor.Fault;
import org.apache.cxf.message.Exchange;
import org.apache.cxf.message.Message;
@@ -56,7 +57,7 @@
public class JbiInWsdl1Interceptor extends AbstractSoapInterceptor {
public JbiInWsdl1Interceptor() {
-setPhase(Phase.UNMARSHAL);
+super(Phase.UNMARSHAL);
addAfter(JbiOperationInterceptor.class.getName());
}
@@ -104,7 +105,7 @@
}
Element body = getBodyElement(message);
List headers = wsdlMessage.getExtensors(
SoapHeaderInfo.class);
-Element headerElement = message.getHeaders(Element.class);
+List headerElement = message.getHeaders();
List parts = new ArrayList();
for (MessagePartInfo part : wsdlMessage.getMessageParts()) {
if ("document".equals(style)) {
@@ -129,10 +130,10 @@
if (headers != null) {
for (SoapHeaderInfo header : headers) {
MessagePartInfo part = header.getPart();
-Element param = findHeader(headerElement, part);
+Header param = findHeader(headerElement, part);
int idx = part.getIndex();
QName element = part.getElementQName();
-Element hdr = getHeaderElement(message, element);
+Header hdr = getHeaderElement(message, element);
if (hdr == null) {
throw new Fault(new Exception("Missing required
header element: "
+ QNameUtil.toString(element)));
@@ -190,7 +191,7 @@
}
}
-protected Element getHeaderElement(SoapMessage message, QName name) {
+protected Header getHeaderElement(SoapMessage message, QName name) {
Exchange exchange = message.getExchange();
BindingOperationInfo bop = exchange.get(
BindingOperationInfo.class);
if (bop.isUnwrapped()) {
@@ -206,11 +207,11 @@
if (headers == null || headers.size() == 0) {
return null;
}
-Element headerElement = message.getHeaders(Element.class);
+List headerElement = message.getHeaders();
for (SoapHeaderInfo header : headers) {
if (header.getPart().getElementQName().equals(name)) {
MessagePartInfo mpi = header.getPart();
-Element param = findHeader(headerElement, mpi);
+Header param = findHeader(headerElement, mpi);
return param;
}
}
@@ -236,18 +237,16 @@
}
}
-private static Element findHeader(Element headerElement,
MessagePartInfo mpi) {
-NodeList nodeList = headerElement.getChildNodes();
-Element param = null;
-if (no
Re: servicemix-sca now compiling
Hi Jean-Sebastien !
The tuscany SE, as you said, is very old, and has never been finished
(that's why it is in the sandbox).
The idea was to be able to deploy SCA annotated POJOs onto it and leverage
Tuscany to host them.
I think there are some areas where I'd need a few explanations (see below).
We're investigating how SCA and JBI can be bridged. I'm thinking that one
way is to think about SCA as a
development designer and JBI as the runtime. So one goal is to investigate
how we could transform an SCA
assembly into a JBI Service Assembly: each java component would be deployed
onto the afore mentionned
Service Engine, a bpel implementation could be deployed onto the Ode Service
Engine (etc...) while wires / bindings
would lead to several Service Units for Binding Components (HTTP, JMS,
etc...).
So I have a few questions that you may help answering:
* where does SDO comes in ? is it mandatory, optional, unspecified ?
* how is the mapping between the soap call and the java method
invocation specified ?
I know how JAX-WS can be used to specify the web methods, xml
mapping, but how can
you configure this in SCA ? This is also needed when you want to
translate a java call
to an xml invocation (when using client proxies / references to other
components).
On 6/25/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Guillaume Nodet wrote:
> Copying tuscany dev list ...
>
> On 6/22/07, Bruce Snyder <[EMAIL PROTECTED]> wrote:
>>
>> On 6/22/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>> > Thanks, great work !
>> >
>> > Sorry about these problems, but I guess this is a direct
>> consequence of
>> it
>> > being sandboxed :-(
>> > So you'll find that the SE is not complete, but the idea was to
>> implement a
>> > JBI binding for tuscany
>> > so that you can deploy SCA annotated POJOs on this SE. IIRC, the
>> provider
>> > part was working
>> > somewhat but I think the consumer part is missing (being able to call
>> > external services through java
>> > proxies).
>> >
>> > I guess I stopped because I did not completely understood how the xml
>> > mapping and java / wsdl
>> > mapping were to be written. While I see how JAX-WS works, there is
>> > something that have escaped
>> > me somehow with SCA (or maybe this isn't specified and that could
>> be the
>> > reason I did not found it).
>>
>> We should invite some Tuscany folks to discuss this topic so we can
>> work though it. Is anyone subscribed to the Tuscany dev list already
>> who can CC that list? I'm at a client site right now and don't have
>> the time to do it ATM.
>>
>> Bruce
>> --
>> perl -e 'print
>> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E> );'
>>
>> Apache Geronimo - http://geronimo.apache.org/
>> Apache ActiveMQ - http://activemq.org/
>> Apache ServiceMix - http://servicemix.org/
>> Castor - http://castor.org/
>>
Hi,
I work on Tuscany, I may be able to help with some of these questions :)
The servicemix-sca module under [1] seems to use an old level of SCA and
Tuscany. The SCA programming model and the Tuscany SCA SPIs have evolved
since then but they are pretty stable now so it might be the right time
to port servicemix-sca to SCA 1.0 and the Tuscany 0.90 release (or the
upcoming 0.91 release, which provides the same SPIs).
Do you have specific Tuscany or SCA questions that we can help with?
Could you describe the type of application and scenario supported by
servicemix-sca? Is there a sample showing how an application developer
will use Tuscany and ServiceMix together?
[1]
http://svn.apache.org/repos/asf/incubator/servicemix/trunk/sandbox/servicemix-sca/
--
Jean-Sebastien
--
Cheers,
Guillaume Nodet
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
