[jira] Commented: (ODE-634) Event Handles not working
[ https://issues.apache.org/jira/browse/ODE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759055#action_12759055 ] Rafal Rusin commented on ODE-634: - Well, it would be great to migrate it to 1.X. But in current shape it may cause null pointer exceptions after upgrading ODE, since OutstandingRequestManager is binary serialized inside instance's execution state. So some work on it is needed. > Event Handles not working > - > > Key: ODE-634 > URL: https://issues.apache.org/jira/browse/ODE-634 > Project: ODE > Issue Type: Bug > Components: BPEL Runtime >Affects Versions: 1.3.2, 1.3.3, 2.0 >Reporter: William McCusker >Assignee: Rafal Rusin > Fix For: 2.0 > > Attachments: account-sa.zip, account-soapui-project.xml, > event_handler_1x.patch, event_handler_trunk.patch, IMAManager.diff > > > When attempting to send a message to an event handler one of two > possibilities occur: > 1.) Event Handler fails to receive message. > 2.) message is receive but conflicting receive fault triggered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-525) Thread synchronization / block (eg. XML manipulation ) slows ODE down dramaticly
[ https://issues.apache.org/jira/browse/ODE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759062#action_12759062 ] Mateusz Nowakowski commented on ODE-525: I've found the same during JProfiling and YourKit profiling. I've profiled ODE inside ServiceMix (Fuse to be more precise) and saw that the ODE threads are blocked most of the time on net.sf.saxon.om.NamePool monitor. I can't provide you precise data, but about 90% blocked time was on this monitor on both Java profilers. The issue is that how Saxon is used in ODE. ODE 1.2 uses Saxon in 8.7 version and I googled that it is possible to provide new NamePool object to each xPath evaluation. This causes that threads are no longer blocked on this monitor. Hovewer the issue may be solved inside Saxon library in 9.x, but I haven't tested it yet, because there are no working ServiceMix ODE 1.3.x release. I'll try to find time to test it against 1.3.4-SNAPSHOT and figure it out if the issue still occurs. > Thread synchronization / block (eg. XML manipulation ) slows ODE down > dramaticly > > > Key: ODE-525 > URL: https://issues.apache.org/jira/browse/ODE-525 > Project: ODE > Issue Type: Improvement > Components: BPEL Runtime >Affects Versions: 1.2 > Environment: ODE 1.2 > JAVA 5.0+ >Reporter: Shammy Chen > > Recently we've been profiling ODE by jProfiler and found thread > synchronization block ODE and AXIS2 threads so much. > For example,in our 16 minutes test,calss sun.misc.URLClassPath blocked 342282 > times and amounted to 30648 seconds. Class net.sf.saxon.om.NamePool has > similar problem, maybe there are other candidates. > I think, if we resolve thread synchronization problem, ODE can perform much > better. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ODE-JBI BPEL POJO SAMPLE
Hit to all, i'm looking for an example where a BPEL process, activated inside ode-jbi (servicemix) invoke a POJO (jsr181) can someone tell me where I can found one? Thank you. Massimiliano Andriotto
[jira] Created: (ODE-667) Simple type variables conversion between Java and Saxon in JaxpVariableResolver is not correct
Simple type variables conversion between Java and Saxon in JaxpVariableResolver is not correct -- Key: ODE-667 URL: https://issues.apache.org/jira/browse/ODE-667 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3.3, 2.0 Reporter: Rafal Rusin Assignee: Rafal Rusin For example, if we have declared variable: xsd:date d = '2009-01-01' And we want to insert it into xml message using assign: $d $msg/some-date we end up with msg containing: 2009-01-01T00:00:00Z This is because JaxpVariableResolver converts xsd:date and xsd:dateTime to Java Date, which are indistinguishable and converted to xsd:dateTime by Saxon. Moreover, for example xsd:integers are converted into Java Longs, which may cause data loss, because xsd:integer is defined in xsd to be of arbitrary length. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-605) ODE is based on OpenJPA snapshot release
[ https://issues.apache.org/jira/browse/ODE-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759069#action_12759069 ] Mateusz Nowakowski commented on ODE-605: > > Is there any concrete reason why this version is used? (in ODE 1.2 it was > > openjpa-1.1.0). > > > > Is it possible to fallback this dependency to openjpa-1.2.1? (most > current > > "blessed" version) > > > It was due to a bug in openjpa-1.2.0. I don't have the details right now. > Matthieu would know best. > > >Yeah, I don't remember what exactly but 1.2.0 was broken for us. I haven't >tried 1.2.1, it probably include the fixes that made 1.3 work for us so I >would give it a try. > >Matthieu Could you give a try before releasing 1.3.4? Thanks > ODE is based on OpenJPA snapshot release > > > Key: ODE-605 > URL: https://issues.apache.org/jira/browse/ODE-605 > Project: ODE > Issue Type: Wish > Components: Build System >Affects Versions: 1.3.2 > Environment: Fuse 3.4.0.2, WinXp >Reporter: Mateusz Nowakowski > Fix For: 1.3.4 > > > ODE is based on openjpa-1.3.0-SNAPSHOT.jar > Please upgrade OpenJPA dependency to an official release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Please unsubcribe me from the mailing list
[jira] Commented: (ODE-462) Deploying the ODE BPEL engine to smx4 ends up with the following
[ https://issues.apache.org/jira/browse/ODE-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759073#action_12759073 ] Mateusz Nowakowski commented on ODE-462: It seems to be done. Could you confirm that? BTW. Is there a plan for tighter SMX 4 integration? (bundles/features) > Deploying the ODE BPEL engine to smx4 ends up with the following > > > Key: ODE-462 > URL: https://issues.apache.org/jira/browse/ODE-462 > Project: ODE > Issue Type: Bug > Components: JBI Integration >Affects Versions: 1.2 > Environment: Deployment of Apaceh ode 1.2 fails in smx4(JBI Container) >Reporter: Surendar V > Original Estimate: 168h > Remaining Estimate: 168h > > 17:23:38,031 | ERROR | pool-1-thread-1 | OdeLifeCycle | > org.apache.ode.jbi.OdeLifeCycle 178 | Database configuration error. > java.lang.RuntimeException: TransactionManager is not recoverable. > at org.apache.ode.il.dbutil.Database.initInternalDb(Database.java:179) > at org.apache.ode.il.dbutil.Database.initEmbeddedDb(Database.java:232) > at org.apache.ode.il.dbutil.Database.initDataSource(Database.java:147) > at org.apache.ode.il.dbutil.Database.start(Database.java:99) > at org.apache.ode.jbi.OdeLifeCycle.initDataSource(OdeLifeCycle.java:175) > at org.apache.ode.jbi.OdeLifeCycle.init(OdeLifeCycle.java:113) > at > org.apache.servicemix.jbi.deployer.impl.ComponentImpl$ComponentWrapper.init(ComponentImpl.java:249) > at > org.apache.servicemix.jbi.runtime.impl.ComponentRegistryImpl.doRegister(ComponentRegistryImpl.java:97) > at > org.apache.servicemix.jbi.runtime.impl.ComponentRegistryImpl.doRegister(ComponentRegistryImpl.java:37) > at > org.apache.servicemix.nmr.core.ServiceRegistryImpl.register(ServiceRegistryImpl.java:47) > at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.springframework.osgi.util.internal.ReflectionUtils.invokeMethod(ReflectionUtils.java:108) > at > org.springframework.osgi.config.CustomListenerAdapterUtils.invokeCustomMethods(CustomListenerAdapterUtils.java:154) > at > org.springframework.osgi.config.OsgiServiceLifecycleListenerAdapter.bind(OsgiServiceLifecycleListenerAdapter.java:186) > at > org.springframework.osgi.service.importer.support.internal.util.OsgiServiceBindingUtils.callListenersBind(OsgiServiceBindingUtils.java:50) > at > org.springframework.osgi.service.importer.support.internal.collection.OsgiServiceCollection$Listener.serviceChanged(OsgiServiceCollection.java:106) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:765) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:623) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:554) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3612) > at org.apache.felix.framework.Felix.access$000(Felix.java:36) > at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:626) > at > org.apache.felix.framework.ServiceRegistry.fireServiceChanged(ServiceRegistry.java:559) > at > org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:75) > at org.apache.felix.framework.Felix.registerService(Felix.java:2702) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:254) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:232) > at > org.apache.servicemix.jbi.deployer.impl.Deployer.registerService(Deployer.java:463) > at > org.apache.servicemix.jbi.deployer.impl.Deployer.installComponent(Deployer.java:265) > at > org.apache.servicemix.jbi.deployer.impl.Deployer.register(Deployer.java:186) > at > org.apache.servicemix.jbi.deployer.impl.AbstractBundleWatcher.onBundleStarted(AbstractBundleWatcher.java:80) > at > org.apache.servicemix.jbi.deployer.impl.AbstractBundleWatcher.access$000(AbstractBundleWatcher.java:34) > at > org.apache.servicemix.jbi.deployer.impl.AbstractBundleWatcher$1.bundleChanged(AbstractBundleWatcher.java:53) > at > org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:690) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:619) > at > org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:532) > at org.apache.felix.
[jira] Commented: (ODE-666) Tests do not pass on Derby - locking issues
[ https://issues.apache.org/jira/browse/ODE-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759130#action_12759130 ] Rafal Rusin commented on ODE-666: - At least we should make possible to run all ODE tests without derby. Now a lot of test cases (those without @Test(dataProvider="configs") entries use default config. This yields to using Derby when tests are executed with mysql config and does hangs. Jbi tests now use hib derby too. IMO default DB settings for tests should be set to localhost hib mysql, because we support this config the most (I think). User/password/db name could be default too. > Tests do not pass on Derby - locking issues > --- > > Key: ODE-666 > URL: https://issues.apache.org/jira/browse/ODE-666 > Project: ODE > Issue Type: Test >Affects Versions: 1.3.4 >Reporter: Alexis Midon > Fix For: 1.3.4 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 1.3.x - 2.x Roadmap?
On Wed, Sep 23, 2009 at 8:52 PM, Kurt T Stam wrote: > Thanks Matthieu, > > We initially based the Riftsaw project on the trunk (2.0 codebase), but we > have since moved back to 1.3, as we need a stable codebase to build on. One > of the main areas of concern for us is the ability to swap out the WS stack, > and we're trying to use JAX-WS rather > then coding against another internal API (as is done with axis2). We're > making progress but I have to say things are pretty hairy in this module. If > we pull it off we sure think this would be good to contribute back > "upstream" to the ODE project. I'm hoping you would be interested to take it > back. > > I'm sure there's interest. Thanks, Matthieu > Thank you for giving such a great overview on the history of the 2.0 > branch. We will sure take a look at jira and start putting our votes in, and > hopefully we should be able to work on some of the issues that are important > to us (providing patches). Versioning is high on our list. > > --Kurt > > > Matthieu Riou wrote: > >> I realize this thread is pretty close to dead but I thought some >> perspective >> on the trunk could help. >> >> On Wed, Sep 9, 2009 at 7:00 AM, Kurt T Stam wrote: >> >> >> >>> Thanks Alex, >>> >>> 1. That is very helpful. Is there any expectation as to when the first >>> release 2.0 release will happen? >>> >>> >>> >>> >> When it's ready :) More seriously, you can make it happen. >> >> >> >> >>> 2. I see there are 85 jira for 2.0, so that may take a bit? >>> >>> >>> >>> >> 2.0 has been for a while the "future" release so there's a lot of issues >> there that actually belong to the wishlist. Some triage is required to see >> what's really necessary (like porting fixes from 1.X) and what's just >> "nice >> to have". It'd be pretty helpful if someone could do a first pass on all >> of >> those and assign them to the wishlist. >> >> I can also provide a more context regarding the current state of trunk. It >> all started as Alex described it, the need to reflect the QoS at the >> message >> exchange level. This is necessary to support transactional or reliable >> transports correctly and it allowed some optimizations for the classic >> async, non reliable case (HTTP). The most important optimization being the >> number of transactions, 1.X is pretty pessimistic and commits a lot, often >> unnecessarily when you keep in mind that HTTP is unreliable in the first >> place. In trunk there's the notion of a process-level work queue, so work >> gets done for as long as possible without committing. >> >> So that work got started and we realized it would break the serialized >> OModel backward compatibility. Which was another problem that needed >> tackling anyway. At this point we introduced runtime versioning which is >> also in the trunk (you'll notice 2 versions under runtime and compiler). >> The >> idea is that the older process definitions and their instances get loaded >> in >> the older runtime and the newer ones use the v2 runtime so everyone can >> continue business as usual. >> >> There's also been some work on RESTful support and a related message >> exchange and ODEProcess implementation. If you implement a RESTful >> integration API, you can have a full request/response interaction served >> without any WSDL or SOAP BS. An example of a RESTful integration layer >> implementation can be found in simplex >> (http://github.com/intalio/simplexunder the http and messaging >> packages). >> >> So that's a lot of good infrastructure work. To the best of my knowledge, >> everything implemented is functional. It's probably not as fine-tuned as >> the >> 1.X branch though, there's been a lot of maturation behind each 1.3.x >> release. The BART stuff runs nicely, the reliable and transactional parts >> are untested (no IL uses it) but the classic HTTP code path works well and >> the work queue is effective. My guess would be that trunk commits about >> 30% >> less often than 1.X on typical processes. Runtime versioning works too, >> we >> have test cases for it reloading older saved runtimes. Finally, the >> RESTful >> support is also well tested in SimPEL. >> >> So the 2 main things necessary before a 2.0 I think would be >> >> 1. some bug triage to see which important fixes could have been >> forgotten >> from 1.x >> 2. migration at the database level for people who will want to upgrade >> from 1.x >> 3. someone volunteering to push the release forward >> >> >> The second point mostly matters for folks who have or are supporting >> people >> with a 1.x production. >> >> Hope this helps, >> Matthieu >> >> >> >> >> >>> Some stuff we worked on: >>> ODE-225 - HowTo: JBoss & ODE - might prob just a link to the RiftSaw >>> project (https://www.jboss.org/riftsaw) >>> ODE-41 - CXF Implementation of the IAPI - In RiftSaw we're using the >>> JBossWS (spi), which allows plugging in CXF and JBossWS Native. I'm >>> guessing >>> this code will stay in RiftSaw since it will run easiest on J
[jira] Commented: (ODE-462) Deploying the ODE BPEL engine to smx4 ends up with the following
[ https://issues.apache.org/jira/browse/ODE-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759229#action_12759229 ] Greg Lucas commented on ODE-462: I'm working on creating a feature for ode-jbi (for the 1.x stable branch) right now. Initial plan is to define a single bundle that embeds the ode-* jars and wire the rest of the dependencies. > Deploying the ODE BPEL engine to smx4 ends up with the following > > > Key: ODE-462 > URL: https://issues.apache.org/jira/browse/ODE-462 > Project: ODE > Issue Type: Bug > Components: JBI Integration >Affects Versions: 1.2 > Environment: Deployment of Apaceh ode 1.2 fails in smx4(JBI Container) >Reporter: Surendar V > Original Estimate: 168h > Remaining Estimate: 168h > > 17:23:38,031 | ERROR | pool-1-thread-1 | OdeLifeCycle | > org.apache.ode.jbi.OdeLifeCycle 178 | Database configuration error. > java.lang.RuntimeException: TransactionManager is not recoverable. > at org.apache.ode.il.dbutil.Database.initInternalDb(Database.java:179) > at org.apache.ode.il.dbutil.Database.initEmbeddedDb(Database.java:232) > at org.apache.ode.il.dbutil.Database.initDataSource(Database.java:147) > at org.apache.ode.il.dbutil.Database.start(Database.java:99) > at org.apache.ode.jbi.OdeLifeCycle.initDataSource(OdeLifeCycle.java:175) > at org.apache.ode.jbi.OdeLifeCycle.init(OdeLifeCycle.java:113) > at > org.apache.servicemix.jbi.deployer.impl.ComponentImpl$ComponentWrapper.init(ComponentImpl.java:249) > at > org.apache.servicemix.jbi.runtime.impl.ComponentRegistryImpl.doRegister(ComponentRegistryImpl.java:97) > at > org.apache.servicemix.jbi.runtime.impl.ComponentRegistryImpl.doRegister(ComponentRegistryImpl.java:37) > at > org.apache.servicemix.nmr.core.ServiceRegistryImpl.register(ServiceRegistryImpl.java:47) > at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.springframework.osgi.util.internal.ReflectionUtils.invokeMethod(ReflectionUtils.java:108) > at > org.springframework.osgi.config.CustomListenerAdapterUtils.invokeCustomMethods(CustomListenerAdapterUtils.java:154) > at > org.springframework.osgi.config.OsgiServiceLifecycleListenerAdapter.bind(OsgiServiceLifecycleListenerAdapter.java:186) > at > org.springframework.osgi.service.importer.support.internal.util.OsgiServiceBindingUtils.callListenersBind(OsgiServiceBindingUtils.java:50) > at > org.springframework.osgi.service.importer.support.internal.collection.OsgiServiceCollection$Listener.serviceChanged(OsgiServiceCollection.java:106) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:765) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:623) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:554) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3612) > at org.apache.felix.framework.Felix.access$000(Felix.java:36) > at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:626) > at > org.apache.felix.framework.ServiceRegistry.fireServiceChanged(ServiceRegistry.java:559) > at > org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:75) > at org.apache.felix.framework.Felix.registerService(Felix.java:2702) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:254) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:232) > at > org.apache.servicemix.jbi.deployer.impl.Deployer.registerService(Deployer.java:463) > at > org.apache.servicemix.jbi.deployer.impl.Deployer.installComponent(Deployer.java:265) > at > org.apache.servicemix.jbi.deployer.impl.Deployer.register(Deployer.java:186) > at > org.apache.servicemix.jbi.deployer.impl.AbstractBundleWatcher.onBundleStarted(AbstractBundleWatcher.java:80) > at > org.apache.servicemix.jbi.deployer.impl.AbstractBundleWatcher.access$000(AbstractBundleWatcher.java:34) > at > org.apache.servicemix.jbi.deployer.impl.AbstractBundleWatcher$1.bundleChanged(AbstractBundleWatcher.java:53) > at > org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:690) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:619) > at > org.apache.felix.framework.util.EventDispatcher.fireBun
[jira] Updated: (ODE-586) Reuse And Reduce Process Memory
[ https://issues.apache.org/jira/browse/ODE-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexis Midon updated ODE-586: - Affects Version/s: (was: 1.2) 1.3.5 will do later > Reuse And Reduce Process Memory > --- > > Key: ODE-586 > URL: https://issues.apache.org/jira/browse/ODE-586 > Project: ODE > Issue Type: Improvement > Components: Axis2 Integration, BPEL Compilation/Parsing, BPEL Runtime >Affects Versions: 1.3.5 >Reporter: Karthick Sankarachary >Assignee: Karthick Sankarachary > Fix For: 1.3.4 > > > This is a meta issue to track all solutions geared towards reducing the > footprint of processes. Up until now, memory optimization of processes has > been an afterthought, and that calls for a change. There are a number of ways > in which we can reduce the in-memory size of processes, including but not > limited, to the following: > a) Employ a flyweight pattern to share identical resources within the process > model. This is analogous to the approach taken by string interning, only we > want to it to be more generic. > b) Refactor one or more parts of the process model in terms of a leaner and > meaner data structure. Since this may result in a structural change in the > serialized bytes of the process, care should be taken to maintain backwards > compatibility. > c) Reuse shared resources across different process models. This involves > determining whether or not a resource is shareable, and if so, storing them > in a system-wide cache. A reference counting mechanism may be used to manage > the lifecycle of the cache. > In the following comment, we will describe a solution based on approach (a). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-667) Simple type variables conversion between Java and Saxon in JaxpVariableResolver is not correct
[ https://issues.apache.org/jira/browse/ODE-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexis Midon updated ODE-667: - Fix Version/s: Wishlist > Simple type variables conversion between Java and Saxon in > JaxpVariableResolver is not correct > -- > > Key: ODE-667 > URL: https://issues.apache.org/jira/browse/ODE-667 > Project: ODE > Issue Type: Bug > Components: BPEL Runtime >Affects Versions: 1.3.3, 2.0 >Reporter: Rafal Rusin >Assignee: Rafal Rusin > Fix For: Wishlist > > > For example, if we have declared variable: > xsd:date d = '2009-01-01' > And we want to insert it into xml message using assign: > > $d > $msg/some-date > > we end up with msg containing: > 2009-01-01T00:00:00Z > This is because JaxpVariableResolver converts xsd:date and xsd:dateTime to > Java Date, which are indistinguishable and converted to xsd:dateTime by > Saxon. > Moreover, for example xsd:integers are converted into Java Longs, which may > cause data loss, because xsd:integer is defined in xsd to be of arbitrary > length. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-525) Thread synchronization / block (eg. XML manipulation ) slows ODE down dramaticly
[ https://issues.apache.org/jira/browse/ODE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexis Midon updated ODE-525: - Fix Version/s: Wishlist > Thread synchronization / block (eg. XML manipulation ) slows ODE down > dramaticly > > > Key: ODE-525 > URL: https://issues.apache.org/jira/browse/ODE-525 > Project: ODE > Issue Type: Improvement > Components: BPEL Runtime >Affects Versions: 1.2 > Environment: ODE 1.2 > JAVA 5.0+ >Reporter: Shammy Chen > Fix For: Wishlist > > > Recently we've been profiling ODE by jProfiler and found thread > synchronization block ODE and AXIS2 threads so much. > For example,in our 16 minutes test,calss sun.misc.URLClassPath blocked 342282 > times and amounted to 30648 seconds. Class net.sf.saxon.om.NamePool has > similar problem, maybe there are other candidates. > I think, if we resolve thread synchronization problem, ODE can perform much > better. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-666) Tests do not pass on Derby - locking issues
[ https://issues.apache.org/jira/browse/ODE-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexis Midon updated ODE-666: - Priority: Blocker (was: Major) > Tests do not pass on Derby - locking issues > --- > > Key: ODE-666 > URL: https://issues.apache.org/jira/browse/ODE-666 > Project: ODE > Issue Type: Test >Affects Versions: 1.3.4 >Reporter: Alexis Midon >Priority: Blocker > Fix For: 1.3.4 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-619) placeholders in endpoint properties
[
https://issues.apache.org/jira/browse/ODE-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexis Midon resolved ODE-619.
--
Resolution: Fixed
> placeholders in endpoint properties
> ---
>
> Key: ODE-619
> URL: https://issues.apache.org/jira/browse/ODE-619
> Project: ODE
> Issue Type: Improvement
> Components: Axis2 Integration
>Reporter: Alexis Midon
>Assignee: Alexis Midon
> Fix For: 1.3.4
>
>
> Endpoint properties [1] now support placeholders. These placeholders can be
> use in other property values to avoid repeating common values.
> The general placeholder pattern is ${placeholder.name}
> Three types of placeholders shall be separated:
> #1 environment placeholders: placeholders for environment variables.
> They follow the naming convention ala ANT: ${env.JAVA_HOME} will retrieve
> the JAVA_HOME env var.
> #2 system placeholders: placeholders for system properties
> They follow the naming convention: ${system.log4j.configuration} will access
> the system property "log4j.configuration"
> System placeholders might point to environment placeholders.
> #3 local placeholders: placeholders defined in one endpoint property file
> These do not use any prefixes: ${mytimeout} will be replaced by the value of
> "mytimeout" placeholder.
> Local placeholder values might themselves used the 2 previous placeholders
> types (env var and sys properties).
> mytimeout=${env.TIMEOUT} is valid, and will be replaced by the env variable
> TIMEOUT.
> Local placeholders can be defined in one file, and used in another. If
> defined twice, the last loaded value will have precedence.
> Here are a few examples:
> placeholder1=placeholder1-value
> test.placeholder1=${placeholder1}
> ns-alias.my-service.ode.http.socket.timeout=${system.TestSystemProperty}
> ns-alias.my-service.ode.mex.timeout=${env.TEST_DUMMY_ENV_VAR}
> See org.apache.ode.utils.HierarchicalPropertiesTest for more.
> [1] http://ode.apache.org/user-guide.html#UserGuide-EndpointConfiguration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-600) A process with active = false in its deploy.xml shows as active in process list
[ https://issues.apache.org/jira/browse/ODE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexis Midon updated ODE-600: - Fix Version/s: Wishlist > A process with active = false in its deploy.xml shows as active in process > list > --- > > Key: ODE-600 > URL: https://issues.apache.org/jira/browse/ODE-600 > Project: ODE > Issue Type: Bug > Environment: Ubuntu 8.10, JDK 1.5.0_15 >Reporter: Waruna Ranasinghe > Fix For: Wishlist > > Attachments: ODE-600.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-593) Running Apache ODE in JBoss AppServer 4.3 GA
[ https://issues.apache.org/jira/browse/ODE-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexis Midon updated ODE-593: - Fix Version/s: Wishlist > Running Apache ODE in JBoss AppServer 4.3 GA > > > Key: ODE-593 > URL: https://issues.apache.org/jira/browse/ODE-593 > Project: ODE > Issue Type: Bug > Components: Deployment >Affects Versions: 1.2 > Environment: RHEL 5.0, JDK Sun 1.6_9, JBoss 4.2.3.GA >Reporter: Edgar A Silva > Fix For: Wishlist > > > I am trying create a Todo for install ODE in JBoss 4.2.3, I already changed > the jboss-esb.xml for solving classloader issues: > > /ode > > jdbc/ode-ds > javax.sql.DataSource > java:OdeDS > > > > org.hibernate:archive=ode-hibernate > > java2ParentDelegation=true > > > > > Based on that jboss-web.xml, I removed the comments from web.xml about > Datasource on the following section: > > jdbc/ode-ds > javax.sql.DataSource > Container > Shareable > > This will match with mydatasource name and the declaration from > I added the property: -Dode.persistence=hibernate into my run.conf as well > as created my axis2-ode.properties with the information: > ode-axis2.db.mode=EXTERNAL > ode-axis2.db.ext.dataSource=java:OdeDS > ode-axis2.tx.factory.class=org.apache.ode.axis2.util.JBossFactory > I created a Datasource pointing for a Mysql database, seems to be fine > according the loggin message: > 20:41:48,331 INFO [SessionFactoryObjectFactory] Not binding factory to JNDI, > no JNDI name configured > 20:41:48,370 INFO [JdbcDelegate] Using database dialect: MYSQL > 20:41:48,430 INFO [BpelServerImpl] BPEL Server Started. > But, after I see the folliowing message in my log: > 20:41:48,475 ERROR [[/ode]] StandardWrapper.Throwable > java.lang.IllegalAccessError: tried to access class > org.apache.xmlbeans.XmlBeans$1 from class org.apache.xmlbeans.XmlBeans > at org.apache.xmlbeans.XmlBeans.(XmlBeans.java:85) > at > org.apache.ode.bpel.pmapi.TInstanceStatus.(TInstanceStatus.java:18) > at > org.apache.ode.bpel.engine.ProcessStatusConverter.cvtInstanceStatus(ProcessStatusConverter.java:84) > at > org.apache.ode.bpel.engine.ProcessStatusConverter.(ProcessStatusConverter.java:54) > at > org.apache.ode.bpel.engine.ProcessAndInstanceManagementImpl.(ProcessAndInstanceManagementImpl.java:143) > at > org.apache.ode.axis2.service.ManagementService.enableService(ManagementService.java:77) > at org.apache.ode.axis2.ODEServer.init(ODEServer.java:181) > at org.apache.ode.axis2.ODEServer.init(ODEServer.java:119) > at > org.apache.ode.axis2.hooks.ODEAxisServlet.init(ODEAxisServlet.java:53) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1161) > The ode web application works, but when I try see more information about the > WSDL I got an exception: > 20:46:24,854 ERROR [[/ode]] StandardWrapper.Throwable > java.lang.NoClassDefFoundError: Could not initialize class > org.apache.ode.bpel.engine.ProcessAndInstanceManagementImpl > at > org.apache.ode.axis2.service.ManagementService.enableService(ManagementService.java:77) > at org.apache.ode.axis2.ODEServer.init(ODEServer.java:181) > at org.apache.ode.axis2.ODEServer.init(ODEServer.java:119) > at > org.apache.ode.axis2.hooks.ODEAxisServlet.init(ODEAxisServlet.java:53) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1161) > at > org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:806) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:129) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) > at > org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at > org.apache.tomcat.util.net.JIoEnd
[jira] Created: (ODE-668) Library compilation conflicts on WebSphere 6.1
Library compilation conflicts on WebSphere 6.1 -- Key: ODE-668 URL: https://issues.apache.org/jira/browse/ODE-668 Project: ODE Issue Type: Bug Components: BPEL Compilation/Parsing Affects Versions: 1.3.3 Environment: OpenSuse, WebSphere 6.1.0.25 Reporter: Adam Lucarz I have deployed successfully ODE on WebSphere 6.1 after several hours. The main problem was, that there were two library "compilation" conflicts with WebSphere libraries because WebSphere runs on an IBM Java Runtime Machine. Everything was fine after adding the jaxp-api.jar and the serializer.jar from Xalan to the ODE WebApp library directory. Wouldn't it be a good idea to deliver those two libraries with ODE as standard? The WebApp was running in the "parent last" mode on WebSphere. The problem occurs first at starting the deployment poller. These were the exceptions: [23.09.09 18:13:06:691 CEST] 0065 DeploymentPol E org.apache.geronimo.kernel.log.GeronimoLog fatal Encountered an unexpected error. Exiting poller... java.lang.VerifyError: javax/xml/xpath/XPath.setNamespaceContext(Ljavax/xml/namespace/NamespaceContext;)V at org.apache.ode.bpel.elang.xpath20.compiler.XPath20ExpressionCompilerImpl.doJaxpCompile(XPath20ExpressionCompilerImpl.java:153) at org.apache.ode.bpel.elang.xpath20.compiler.XPath20ExpressionCompilerImpl._compile(XPath20ExpressionCompilerImpl.java:121) at org.apache.ode.bpel.elang.xpath20.compiler.XPath20ExpressionCompilerImpl.compile(XPath20ExpressionCompilerImpl.java:103) at org.apache.ode.bpel.compiler.BpelCompiler.compileExpr(BpelCompiler.java:558) at org.apache.ode.bpel.compiler.BpelCompiler.compileExpr(BpelCompiler.java:543) at org.apache.ode.bpel.compiler.AssignGenerator.compileFrom(AssignGenerator.java:188) at org.apache.ode.bpel.compiler.AssignGenerator.compile(AssignGenerator.java:76) at org.apache.ode.bpel.compiler.BpelCompiler$7.run(BpelCompiler.java:922) at org.apache.ode.bpel.compiler.BpelCompiler.compile(BpelCompiler.java:1086) at org.apache.ode.bpel.compiler.BpelCompiler.compileActivity(BpelCompiler.java:918) at org.apache.ode.bpel.compiler.BpelCompiler.compile(BpelCompiler.java:867) at org.apache.ode.bpel.compiler.SequenceGenerator.compileChildren(SequenceGenerator.java:54) at org.apache.ode.bpel.compiler.SequenceGenerator.compile(SequenceGenerator.java:45) at org.apache.ode.bpel.compiler.BpelCompiler$7.run(BpelCompiler.java:922) at org.apache.ode.bpel.compiler.BpelCompiler.compile(BpelCompiler.java:1086) at org.apache.ode.bpel.compiler.BpelCompiler.compileActivity(BpelCompiler.java:918) at org.apache.ode.bpel.compiler.BpelCompiler.compile(BpelCompiler.java:867) at org.apache.ode.bpel.compiler.BpelCompiler$5.run(BpelCompiler.java:732) at org.apache.ode.bpel.compiler.BpelCompiler$8.run(BpelCompiler.java:1176) at org.apache.ode.bpel.compiler.BpelCompiler.compile(BpelCompiler.java:1086) at org.apache.ode.bpel.compiler.BpelCompiler.compileScope(BpelCompiler.java:1126) at org.apache.ode.bpel.compiler.BpelCompiler.compile(BpelCompiler.java:712) at org.apache.ode.bpel.compiler.BpelC.compile(BpelC.java:263) at org.apache.ode.bpel.compiler.BpelC.compile(BpelC.java:333) at org.apache.ode.store.DeploymentUnitDir$5.run(DeploymentUnitDir.java:181) at org.apache.ode.utils.InternPool.runBlock(InternPool.java:57) at org.apache.ode.store.DeploymentUnitDir.compile(DeploymentUnitDir.java:178) at org.apache.ode.store.DeploymentUnitDir.compile(DeploymentUnitDir.java:142) at org.apache.ode.store.ProcessStoreImpl.deploy(ProcessStoreImpl.java:187) at org.apache.ode.store.ProcessStoreImpl.deploy(ProcessStoreImpl.java:169) at org.apache.ode.axis2.deploy.DeploymentPoller.check(DeploymentPoller.java:167) at org.apache.ode.axis2.deploy.DeploymentPoller.access$300(DeploymentPoller.java:60) at org.apache.ode.axis2.deploy.DeploymentPoller$PollingThread.run(DeploymentPoller.java:258) Caused by: java.lang.VerifyError: org/apache/xml/serializer/Serializer.asContentHandler()Lorg/xml/sax/ContentHandler; at org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:292) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:329) at org.apache.ws.commons.schema.XmlSchema.serialize_internal(XmlSchema.java:286) at org.apache.ws.commons.schema.XmlSchema.write(XmlSchema.java:226) at org.apache.axis2.description.AxisService2WSDL11.generateOM(AxisService2WSDL11.java:181) at org.apache.axis2.dataretrieval.WSDLDataLocator.outputInlineForm(
