[jira] Commented: (ODE-686) ODE on Derby cannot recover from out of space error
[ https://issues.apache.org/jira/browse/ODE-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770475#action_12770475 ] Alex Boisvert commented on ODE-686: --- And from the stacktrace, it appears you are using a bpel:wait activity which are not supported by in-memory processes. (Granted, it would be better if the engine would report this during deployment/activation). ODE on Derby cannot recover from out of space error --- Key: ODE-686 URL: https://issues.apache.org/jira/browse/ODE-686 Project: ODE Issue Type: Bug Components: BPEL Runtime, JBI Integration Affects Versions: 1.2 Environment: Linux, Fuse 3.4.0.4+ ODE 1.2 JBI Reporter: Mateusz Nowakowski Assignee: Rafal Rusin Fix For: 1.3.4 Attachments: stacktraces.txt When the free space on disk is running out, ODE fails on SQLs, but when the free space on disk increases, ODE cannot recover. (attached stack traces) PS. All the processes are in memory, why is database used for saving persistent jobs? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-686) ODE on Derby cannot recover from out of space error
[ https://issues.apache.org/jira/browse/ODE-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770542#action_12770542 ] Alex Boisvert commented on ODE-686: --- I was under the impression we had decided to not support bpel:wait but apparently we do it in a somewhat broken way. If we support it, the schedule created should be in-memory instead of persistent. We should open a separate issue for this. The two dangers of long-running in-memory processes are 1) memory consumption since we don't do hydration/dehydration of in-memory instances and 2) increased exposure to a node failure. Nothing inherently wrong here except that those are important design considerations. ODE on Derby cannot recover from out of space error --- Key: ODE-686 URL: https://issues.apache.org/jira/browse/ODE-686 Project: ODE Issue Type: Bug Components: BPEL Runtime, JBI Integration Affects Versions: 1.2 Environment: Linux, Fuse 3.4.0.4+ ODE 1.2 JBI Reporter: Mateusz Nowakowski Assignee: Rafal Rusin Fix For: 1.3.4 Attachments: stacktraces.txt When the free space on disk is running out, ODE fails on SQLs, but when the free space on disk increases, ODE cannot recover. (attached stack traces) PS. All the processes are in memory, why is database used for saving persistent jobs? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ODE-688) In-memory processes should create in-memory schedule jobs during bpel:wait
In-memory processes should create in-memory schedule jobs during bpel:wait Key: ODE-688 URL: https://issues.apache.org/jira/browse/ODE-688 Project: ODE Issue Type: Bug Components: BPEL Runtime Reporter: Alex Boisvert Fix For: 1.3.5, 2.0 In-memory processes should create in-memory schedule jobs during bpel:wait. See ODE-686 for a sample stacktrace illustrating the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-686) ODE on Derby cannot recover from out of space error
[ https://issues.apache.org/jira/browse/ODE-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770544#action_12770544 ] Alex Boisvert commented on ODE-686: --- Created issue ODE-688 to track the schedule job persistence issue. ODE on Derby cannot recover from out of space error --- Key: ODE-686 URL: https://issues.apache.org/jira/browse/ODE-686 Project: ODE Issue Type: Bug Components: BPEL Runtime, JBI Integration Affects Versions: 1.2 Environment: Linux, Fuse 3.4.0.4+ ODE 1.2 JBI Reporter: Mateusz Nowakowski Assignee: Rafal Rusin Fix For: 1.3.4 Attachments: stacktraces.txt When the free space on disk is running out, ODE fails on SQLs, but when the free space on disk increases, ODE cannot recover. (attached stack traces) PS. All the processes are in memory, why is database used for saving persistent jobs? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] HISE Proposal
+1 On Fri, Oct 23, 2009 at 2:29 AM, Rafal Rusin rafal.ru...@gmail.com wrote: Please vote on HISE proposal. Voting will remain open until 2009-10-29 00:00 GMT http://wiki.apache.org/incubator/HISEProposal Proposal was presented on Apache Incubator: http://markmail.org/thread/sbq4e73iaa76e4ny http://markmail.org/thread/zt2aqqpicshd23sy --- Abstract HISE will be an implementation of WS-Human-Task Specification. It will stand for Human Interactions Service Engine. Proposal HISE is to provide a deployable component ready to interpret human interactions defined in xml files, as specified in WS-Human-Task 1.0 Spec, as well as expose taskOperations Web Service for tasks management. Note that this proposal covers only services implementation, not including any web consoles. So it will contact with external world using Web Services. Background WSHT project is beeing developed at TouK. It is currently used in other projects by wiring up Spring beans provided by WSHT. In current version, there is implemented about 20% of spec, which includes task creation, assigning, retrieval. Persistence is implemented. Currently, there are no task escalations and notifications. WSHT project is beeing donated to Apache Incubator to become HISE project at Apache. Rationale There's a need for an engine which will interpret high level people interactions definitions. There's no need to reimplement human interactions in various projects from scratch (handling notifications, escalations, tasks lifecycles, tasks reassigning). So such project will follow DRY rule in SOA world. There was some discussion before, which pointed that this kind of project would be desired at Apache (http://markmail.org/thread/es3h3yprjrttxhlu). There was also Agila project in Apache Incubator, which was meant to implement Human Workflow solution, but it's abandoned (probably because of too broad scope - it included BPEL engine implmentation and web console for management, details are here: http://svn.apache.org/repos/asf/incubator/agila/trunk). So in HISE there's aim to shorten this scope and implement only services for WS Human Tasks spec. This would consist of 2 distributions (war and jbi) which would expose web services for tasks management. There was some interest on ServiceMix mailing list too, so jbi distribution would be desired (http://markmail.org/thread/svyxd6xrm2tbwnsz). Initial Goals Currently, there's only POJO based possibility for connecting with WSHT services. The goal is to add Web Services based distributions. Those will include WAR and JBI distribution. Second thing is to implement remaining WS-Human-Task spec. It will include adding scheduler, implementing time notifications and adding tasks escalations. Third thing is to migrate Hibernate JPA to OpenJPA for licensing reasons. Future plans (after 1.0 release) include OSGi bundle distribution to increase wide adoption of HISE. Current Status Meritocracy WSHT project originally was developed at TouK company by a set of committers. All of those committers did a contribution to this project, so they have required merit. TouK currently has one committer in Apache ODE project, which is expected to share knowledge about meritocracy inside community. Community WSHT has currently a small community consisting of developers inside TouK company. This is due to short life of this product. It was recently exposed to public and there's a plan to expand community at Apache Incubator. Core Developers The core developers of WSHT are from TouK company. One of the committers is already an Apache ODE committer. All developers from initial committer's list are experienced in open source development, since they all built this project to current usable status. There's a plan to increase diversity of developers among various companies. This is planned to be done at Apache Incubator in the meritocratic way. Alignment The current code base is targetted for use inside Spring by creating specific beans. But the goal is to add WAR and JBI distributions, which will increase possibility to adopt HISE in J2EE and JBI SOA worlds. Potential projects benefiting from HISE are Apache ODE (by combining BPEL processes with human interactions), Apache ServiceMix (by using service for human interactions in ESB), Apache CXF and Apache Axis (by using human interactions services from other deployed Web Services). It's also expected to migrate from Hibernate JPA to OpenJPA for underlying storage. Known Risks Orphaned products Initial contributors are vendors of this product. So there's no risk or warnings for abandoning this project. Moreover there's already an interest from external communities to join this project for development when it enters Apache Incubator. Inexperience with Open Source WSHT was started as a closed source project. Core
Re: Filter instances
Yes, you just need to use the pid in the filter, e.g.,
pid={ns}ProcessName-VersionNumber
alex
On Tue, Oct 27, 2009 at 10:37 AM, Waruna Ranasinghe waruna...@gmail.comwrote:
hi all,
Is it possible to filter instances according to the version number?
Thanks,
Waruna
Re: buildr _1.2.10_ eclipse fails
Try with JDK 1.5. RJB has issues on some systems with JDK 1.6. Or use JRuby instead of C-Ruby. alex On Fri, Oct 23, 2009 at 8:30 AM, Jens Müller b...@tessarakt.de wrote: Hi, I have a 64bit Ubuntu system. I somehow managed to get buildr 1.2.10 installed. I ran $ buildr _1.2.10_ eclipse in the directory of an ode-1.3.3 checkout. It starts just fine, downloading tons of stuff vom Intalio's Maven repo. But then it consistently throws a segfault after downloading derbytools-10.1.2.1.pom, with Segmentation fault. $ buildr _1.2.10_ ode:package complains about something deprectated (please use Java.wrapper() instead at derby.rake:22 and then, too, exits with Segfault. Any ideas?
Re: Building ODE
Two workarounds: 1) Install Subversion and make sure the command 'svn' is available in your PATH 2) Run buildr ode:package instead of buildr package (this will package everything but will not produce a distro) alex On Sun, Oct 18, 2009 at 4:46 PM, artursli...@inbox.lv wrote: Hello all, Wanted to build Apache Ode, but I'm new to Ruby world. I followed the instructions found on Apache Ode page, but when building the trunk with latest buildr, I get the error message found below (also tried setting up buildr 1.3.1, and removing other versions, and even some more combinations..) Thanks in advance for any hints, Arturs D:ODE-srcbuildr package (in D:/ODE-src, development) ←[34mD:/ODE-src/buildfile:549:in `__instance_exec0': Deprecated: We c hanged the way package_as methods are implemented.#160; See the package method docum entation for more details.←[0m Buildr aborted! ←[31mNo such file or directory - svn status -v←[0m ←[31mD:/ODE-src/buildfile:734:in ``'←[0m ←[31mD:/ODE-src/buildfile:734:in `__instance_exec0'←[0m ←[31mD:/ODE-src/buildfile:732:in `__instance_exec0'←[0m ←[31mc:/ruby/lib/ruby/gems/1.8/gems/buildr-1.3.5-x86-mswin32/lib/buildr/core/app lication.rb:400:in `raw_load_buildfile'←[0m ←[31mc:/ruby/lib/ruby/gems/1.8/gems/buildr-1.3.5-x86-mswin32/lib/buildr/core/app lication.rb:218:in `load_buildfile'←[0m ←[31mc:/ruby/lib/ruby/gems/1.8/gems/buildr-1.3.5-x86-mswin32/lib/buildr/core/app lication.rb:213:in `load_buildfile'←[0m (See full trace by running task with --trace)
[jira] Created: (ODE-682) Compress data stored in the LARGE_DATA table
Compress data stored in the LARGE_DATA table Key: ODE-682 URL: https://issues.apache.org/jira/browse/ODE-682 Project: ODE Issue Type: Improvement Components: BPEL Runtime Reporter: Alex Boisvert Fix For: 1.3.4 For better performance (since the engine's bottleneck is often database write throughput), a good tradeoff is to compress the data stored in the LARGE_DATA table. (Trading off CPU usage for increased transaction throughput). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ODE-665) Publish / Subscribe unit test throws error
[
https://issues.apache.org/jira/browse/ODE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Boisvert reassigned ODE-665:
-
Assignee: Karthick Sankarachary
Publish / Subscribe unit test throws error
--
Key: ODE-665
URL: https://issues.apache.org/jira/browse/ODE-665
Project: ODE
Issue Type: Bug
Affects Versions: 1.3.3
Environment: ODE unit tests
Reporter: Rafal Rusin
Assignee: Karthick Sankarachary
buildr _1.2.10_ test:PubSubTest
gives sometimes NPE and sometimes a following exception. Sometimes there's no
sign of test error, but those exceptions show up in logs.
[junit] messageTestPartHello World/TestPart/message
[junit] ERROR - JacobVPU$JacobThreadImpl.run(463) | Method run in class
org.apache.ode.bpel.runtime.REPLY threw an unexpected exception.
[junit] java.lang.IllegalStateException: Not in REQUEST state!
[junit] at
org.apache.ode.bpel.engine.MessageExchangeImpl.setResponse(MessageExchangeImpl.java:166)
[junit] at
org.apache.ode.bpel.engine.PartnerRoleMessageExchangeImpl.reply(PartnerRoleMessageExchangeImpl.java:83)
[junit] at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.reply(BpelRuntimeContextImpl.java:551)
[junit] at org.apache.ode.bpel.runtime.REPLY.run(REPLY.java:64)
[junit] at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:585)
[junit] at
org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451)
[junit] at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
[junit] at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:849)
[junit] at
org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.invokeNewInstance(PartnerLinkMyRoleImpl.java:203)
[junit] at
org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java:202)
[junit] at
org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:370)
[junit] at
org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:419)
[junit] at
org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:373)
[junit] at
org.apache.ode.il.MockScheduler.doExecute(MockScheduler.java:261)
[junit] at
org.apache.ode.il.MockScheduler.access$000(MockScheduler.java:46)
[junit] at
org.apache.ode.il.MockScheduler$3$1.call(MockScheduler.java:110)
[junit] at
org.apache.ode.il.MockScheduler.execTransaction(MockScheduler.java:134)
[junit] at
org.apache.ode.il.MockScheduler$4.call(MockScheduler.java:147)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
[junit] at java.util.concurrent.FutureTask.run(FutureTask.java:123)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
[junit] at java.lang.Thread.run(Thread.java:595)
[junit] ERROR - BpelEngineImpl.onScheduledJob(428) | Scheduled job
failed; jobDetail={type=INVOKE_INTERNAL, inmem=true,
mexid=4611686018427387905, pid={http://ode/bpel/unit-test}HelloWorld1-1}
[junit] java.lang.RuntimeException: java.lang.IllegalStateException: Not
in REQUEST state!
[junit] at
org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:464)
[junit] at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
[junit] at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:849)
[junit] at
org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.invokeNewInstance(PartnerLinkMyRoleImpl.java:203)
[junit] at
org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java:202)
[junit] at
org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:370)
[junit] at
org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:419)
[junit] at
org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:373)
[junit] at
org.apache.ode.il.MockScheduler.doExecute(MockScheduler.java:261)
[junit] at
org.apache.ode.il.MockScheduler.access$000(MockScheduler.java:46)
[junit] at
org.apache.ode.il.MockScheduler$3$1.call(MockScheduler.java:110)
[junit] at
org.apache.ode.il.MockScheduler.execTransaction(MockScheduler.java:134)
[junit] at
org.apache.ode.il.MockScheduler$4.call(MockScheduler.java:147)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
[junit
[jira] Commented: (ODE-665) Publish / Subscribe unit test throws error
[
https://issues.apache.org/jira/browse/ODE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12758351#action_12758351
]
Alex Boisvert commented on ODE-665:
---
Actually, by design we should not support request-response patterns over
pub-sub endpoints. It doesn't make much sense -- it's non-deterministic and
dealing with special cases like zero subscribers (no possible response) is not
worth the trouble. Better to adopt a different design (at the process level)
to avoid these issues entirely.
Publish / Subscribe unit test throws error
--
Key: ODE-665
URL: https://issues.apache.org/jira/browse/ODE-665
Project: ODE
Issue Type: Bug
Affects Versions: 1.3.3
Environment: ODE unit tests
Reporter: Rafal Rusin
Assignee: Karthick Sankarachary
buildr _1.2.10_ test:PubSubTest
gives sometimes NPE and sometimes a following exception. Sometimes there's no
sign of test error, but those exceptions show up in logs.
[junit] messageTestPartHello World/TestPart/message
[junit] ERROR - JacobVPU$JacobThreadImpl.run(463) | Method run in class
org.apache.ode.bpel.runtime.REPLY threw an unexpected exception.
[junit] java.lang.IllegalStateException: Not in REQUEST state!
[junit] at
org.apache.ode.bpel.engine.MessageExchangeImpl.setResponse(MessageExchangeImpl.java:166)
[junit] at
org.apache.ode.bpel.engine.PartnerRoleMessageExchangeImpl.reply(PartnerRoleMessageExchangeImpl.java:83)
[junit] at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.reply(BpelRuntimeContextImpl.java:551)
[junit] at org.apache.ode.bpel.runtime.REPLY.run(REPLY.java:64)
[junit] at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:585)
[junit] at
org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451)
[junit] at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
[junit] at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:849)
[junit] at
org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.invokeNewInstance(PartnerLinkMyRoleImpl.java:203)
[junit] at
org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java:202)
[junit] at
org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:370)
[junit] at
org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:419)
[junit] at
org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:373)
[junit] at
org.apache.ode.il.MockScheduler.doExecute(MockScheduler.java:261)
[junit] at
org.apache.ode.il.MockScheduler.access$000(MockScheduler.java:46)
[junit] at
org.apache.ode.il.MockScheduler$3$1.call(MockScheduler.java:110)
[junit] at
org.apache.ode.il.MockScheduler.execTransaction(MockScheduler.java:134)
[junit] at
org.apache.ode.il.MockScheduler$4.call(MockScheduler.java:147)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
[junit] at java.util.concurrent.FutureTask.run(FutureTask.java:123)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
[junit] at java.lang.Thread.run(Thread.java:595)
[junit] ERROR - BpelEngineImpl.onScheduledJob(428) | Scheduled job
failed; jobDetail={type=INVOKE_INTERNAL, inmem=true,
mexid=4611686018427387905, pid={http://ode/bpel/unit-test}HelloWorld1-1}
[junit] java.lang.RuntimeException: java.lang.IllegalStateException: Not
in REQUEST state!
[junit] at
org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:464)
[junit] at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
[junit] at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:849)
[junit] at
org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.invokeNewInstance(PartnerLinkMyRoleImpl.java:203)
[junit] at
org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java:202)
[junit] at
org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:370)
[junit] at
org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:419)
[junit] at
org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:373)
[junit] at
org.apache.ode.il.MockScheduler.doExecute(MockScheduler.java:261)
[junit] at
org.apache.ode.il.MockScheduler.access$000(MockScheduler.java:46
[jira] Resolved: (ODE-653) OdeSUManager produces component-task-result strings that are not fully compliant.
[ https://issues.apache.org/jira/browse/ODE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert resolved ODE-653. --- Resolution: Fixed Applied 2nd patch. boisv...@sixtine:~/svn/ode/1.1$ svn commit -m ODE-653: OdeSUManager produces component-task-result strings that are not fully compliant (2nd patch) Sendingjbi/src/main/java/org/apache/ode/jbi/OdeSUManager.java Transmitting file data . Committed revision 817355. OdeSUManager produces component-task-result strings that are not fully compliant. -- Key: ODE-653 URL: https://issues.apache.org/jira/browse/ODE-653 Project: ODE Issue Type: Bug Components: JBI Integration Affects Versions: 1.3.3 Reporter: Greg Lucas Priority: Minor Fix For: 1.3.4 Attachments: ODE-653-1.x-patch.txt, ODE-653-1.x-patch2.txt The JBI spec specifies that a ServiceUnitMnager must return an XML string of the component-task-result for the deploy/undeploy methods. The component-task-result must conform to the http://java.sun.com/xml/ns/jbi/management-message schema. The OdeSUManager currently returns component-task-result strings that do not declare the namespace, so parsing these strings produces an XML document that does actually conform to the schema in the spec. ServiceMix will treat these result strings as invalid and ignore them. I've submitted an SMX4 patch to handle the case where no namespace is declared, but think that ODE should fully conform to the spec regardless of whether that patch gets applied. (Note that the ServiceUnitManager javadoc is a bit misleading as the example it shows has the xmlns declaration on the wrong node. I think the text of the JBI spec is more authoritative and would consider the example in the javadoc incorrect as well. The ODE result string doesn't match the example either.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-653) OdeSUManager produces component-task-result strings that are not fully compliant.
[ https://issues.apache.org/jira/browse/ODE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12757976#action_12757976 ] Alex Boisvert commented on ODE-653: --- Applied to trunk as well, boisv...@sixtine:~/svn/ode/trunk$ svn commit -m ODE-653: OdeSUManager produces component-task-result strings that are not fully compliant (2nd patch) Sendingjbi/src/main/java/org/apache/ode/jbi/OdeSUManager.java Transmitting file data . Committed revision 817356. OdeSUManager produces component-task-result strings that are not fully compliant. -- Key: ODE-653 URL: https://issues.apache.org/jira/browse/ODE-653 Project: ODE Issue Type: Bug Components: JBI Integration Affects Versions: 1.3.3 Reporter: Greg Lucas Priority: Minor Fix For: 1.3.4 Attachments: ODE-653-1.x-patch.txt, ODE-653-1.x-patch2.txt The JBI spec specifies that a ServiceUnitMnager must return an XML string of the component-task-result for the deploy/undeploy methods. The component-task-result must conform to the http://java.sun.com/xml/ns/jbi/management-message schema. The OdeSUManager currently returns component-task-result strings that do not declare the namespace, so parsing these strings produces an XML document that does actually conform to the schema in the spec. ServiceMix will treat these result strings as invalid and ignore them. I've submitted an SMX4 patch to handle the case where no namespace is declared, but think that ODE should fully conform to the spec regardless of whether that patch gets applied. (Note that the ServiceUnitManager javadoc is a bit misleading as the example it shows has the xmlns declaration on the wrong node. I think the text of the JBI spec is more authoritative and would consider the example in the javadoc incorrect as well. The ODE result string doesn't match the example either.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (ODE-662) Process-to-process invocation does not go into activity recovery if no reply is sent from child process
[ https://issues.apache.org/jira/browse/ODE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ODE-662 started by Alex Boisvert. Process-to-process invocation does not go into activity recovery if no reply is sent from child process --- Key: ODE-662 URL: https://issues.apache.org/jira/browse/ODE-662 Project: ODE Issue Type: Bug Affects Versions: 1.3.3 Reporter: Alex Boisvert Assignee: Alex Boisvert Fix For: 1.3.4 When a process invokes another process, there's currently no invoke check performed afterwhile to force the invoke into activity recovery if no reply comes back. Need to add the invoke check. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-662) Process-to-process invocation does not go into activity recovery if no reply is sent from child process
[ https://issues.apache.org/jira/browse/ODE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert resolved ODE-662. --- Resolution: Fixed Fixed. boisv...@sixtine:~/svn/ode/1.1$ svn commit -m ODE-662: Process-to-process invocation does not go into activity recovery if no reply is sent from child process Sending bpel-runtime/src/main/java/org/apache/ode/bpel/engine/BpelRuntimeContextImpl.java Transmitting file data . Committed revision 814777. Process-to-process invocation does not go into activity recovery if no reply is sent from child process --- Key: ODE-662 URL: https://issues.apache.org/jira/browse/ODE-662 Project: ODE Issue Type: Bug Affects Versions: 1.3.3 Reporter: Alex Boisvert Assignee: Alex Boisvert Fix For: 1.3.4 When a process invokes another process, there's currently no invoke check performed afterwhile to force the invoke into activity recovery if no reply comes back. Need to add the invoke check. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-662) Process-to-process invocation does not go into activity recovery if no reply is sent from child process
[ https://issues.apache.org/jira/browse/ODE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12755188#action_12755188 ] Alex Boisvert commented on ODE-662: --- Yes, I considered this feature as well and you can still have internal communication between processes that can last more than 3 minutes by using endpoint configuration and configuring the MEX timeout to some higher value (up to Integer.MAX_VALUE milliseconds). For transacted invokes, we don't need an INVOKE_CHECK... there's already a timeout for the transaction and if the invoke hasn't succeeded before the timeout, then the transaction should be rolled back. Having a database-persistent scheduled job for this case would be pointless. We could have an in-memory schedule for the MEX timeout, however I would strongly advise keeping a model where everything in a transaction executes within a single thread. Transactions executing in multiple threads are hairy and not worth the complexity, IMO. And keeping everything in a single thread has other efficiency/performance benefits. Process-to-process invocation does not go into activity recovery if no reply is sent from child process --- Key: ODE-662 URL: https://issues.apache.org/jira/browse/ODE-662 Project: ODE Issue Type: Bug Affects Versions: 1.3.3 Reporter: Alex Boisvert Assignee: Alex Boisvert Fix For: 1.3.4 When a process invokes another process, there's currently no invoke check performed afterwhile to force the invoke into activity recovery if no reply comes back. Need to add the invoke check. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn:eol-style native
thanks! On Fri, Sep 11, 2009 at 8:09 AM, Rafal Rusin rafal.ru...@gmail.com wrote: Hello devs, I saw there was a lot of files in ODE without svn:eol-style native property set. This property helps decreasing end-of line mess in code. Please configure your clients as described here: http://www.apache.org/dev/version-control.html#https-svn-config. And don't forget to add *.bpel rule :-) Regards, -- Rafał Rusin http://www.touk.pl http://top.touk.pl http://www.mimuw.edu.pl/~rrusin http://www.mimuw.edu.pl/%7Errusin
Re: ODE and Rampart
No, it's not currently possible. I have been working with Tammo on specifying a BPEL extension that would ultimately support this kind of use-cases very cleanly. The spec is posted at: http://ode.apache.org/process-contexts.html However, there's been some spec changes since this was posted so the page needs updating. It should give you the gist, though. alex On Thu, Sep 10, 2009 at 5:16 AM, Butterfield, Brian butterfi...@aware.comwrote: I'm using Rampart WS-Security with username authentication to protect ODE BPEL scripts. I'm also using Rampart to add WS-Security username headers when I'm invoking another web service. I would like to forward the incoming username/password to the service being invoked. To do this I need to get access to the incoming Message Context, is it possible to access this from ODE BPEL? Thanks, -Brian
Re: 1.3.x - 2.x Roadmap?
The trunk has a reworked engine-to-IL contract that supports BART (blocking, async, reliable, transacted) invokes. The engine part is mostly done; the IL parts are still a work in progress. The trunk also supports extension activities and includes support for Javascript E4X assignments. Some fixes/improvements that went into 1.X branch still have to be ported to trunk. We have Jira trackers for these if you want details. alex On Tue, Sep 8, 2009 at 10:02 AM, Alexis Midon mi...@intalio.com wrote: Hi Kurt, ODE trunk has two new big features compare to 1.3: - support for multiple bpel runtimes: ODE 2.0 supports all its previous runtime verisons so that running process instances are not affected by upgrades. - atomic transactions: http://ode.apache.org/atomic-scopes-extension-for-bpel.html On the roadmap as well: - RESTful bpel part 2 - Tuscany integration anything I'm omitting guys? Alexis On Wed, Sep 2, 2009 at 7:26 AM, Kurt T Stam kurt.s...@gmail.com wrote: Hi guys, 1. What are currently the differences between the 1.3 branch and the 2.0 branch? 2. When is the expectation there is going to be a release from the 2.0 branch? Any RC being planned? Thx, --Kurt
[jira] Commented: (ODE-653) OdeSUManager produces component-task-result strings that are not fully compliant.
[ https://issues.apache.org/jira/browse/ODE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745504#action_12745504 ] Alex Boisvert commented on ODE-653: --- Rolled back the previous changes, boisv...@sixtine:~/svn/ode/1.1$ svn commit -m Rollback changeset r805931; ODE-653: OdeSUManager produces component-task-result strings that are not fully compliant Sendingjbi/src/main/java/org/apache/ode/jbi/OdeSUManager.java Transmitting file data . Committed revision 806257. boisv...@sixtine:~/svn/ode/trunk$ svn commit -m Rollback changeset r805932; ODE-653: OdeSUManager produces component-task-result strings that are not fully compliant Sendingjbi/src/main/java/org/apache/ode/jbi/OdeSUManager.java Transmitting file data . Committed revision 806260. OdeSUManager produces component-task-result strings that are not fully compliant. -- Key: ODE-653 URL: https://issues.apache.org/jira/browse/ODE-653 Project: ODE Issue Type: Bug Components: JBI Integration Affects Versions: 1.3.3 Reporter: Greg Lucas Priority: Minor Fix For: 1.3.4 Attachments: ODE-653-1.x-patch.txt The JBI spec specifies that a ServiceUnitMnager must return an XML string of the component-task-result for the deploy/undeploy methods. The component-task-result must conform to the http://java.sun.com/xml/ns/jbi/management-message schema. The OdeSUManager currently returns component-task-result strings that do not declare the namespace, so parsing these strings produces an XML document that does actually conform to the schema in the spec. ServiceMix will treat these result strings as invalid and ignore them. I've submitted an SMX4 patch to handle the case where no namespace is declared, but think that ODE should fully conform to the spec regardless of whether that patch gets applied. (Note that the ServiceUnitManager javadoc is a bit misleading as the example it shows has the xmlns declaration on the wrong node. I think the text of the JBI spec is more authoritative and would consider the example in the javadoc incorrect as well. The ODE result string doesn't match the example either.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ODE 1.x: bin not included in distro?
Fixed. I goofed last time I fixed the inclusion of .sql files in the distro. Added a test case this time around. thanks for reporting, alex On Thu, Aug 20, 2009 at 10:10 AM, Greg Lucas greg.lu...@gmail.com wrote: When I build the 1.x branch using 'buildr package', the resulting: ./distro/target/apache-ode-war-1.3.2-SNAPSHOT.zip ./distro/target/apache-ode-jbi-1.3.2-SNAPSHOT.zip archives do not contain the bin directory that is referenced in the examples ant scripts. Perhaps I'm not using the right build targets? -- Greg Lucas
Compile error on Ode trunk
Anybody getting the same? Packaging apache-ode-docs-2.1-SNAPSHOT.zip Compiling ode-extensions:e4x into /home/boisvert/svn/ode/trunk/extensions/e4x/target/classes Compiling ode-extensions:e4x:test into /home/boisvert/svn/ode/trunk/extensions/e4x/target/test/classes /home/boisvert/svn/ode/trunk/extensions/e4x/src/test/java/org/apache/ode/extension/e4x/JSOperationTest.java:49: run(java.lang.Object,java.lang.String,org.w3c.dom.Element) in org.apache.ode.bpel.rtrep.common.extension.AbstractSyncExtensionOperation cannot be applied to (org.apache.ode.test.MockExtensionContext,org.w3c.dom.Element) jso.run(c, e); alex
Re: Compile error on Ode trunk
Thanks for the fix. It appears buildr only packages the first project (ode) by default; I'm not sure if this is by design. In any case, I've just updated the Buildfile to also package ode-extensions by default so we're covered now. alex On Thu, Aug 20, 2009 at 2:07 PM, Tammo van Lessen tvanles...@gmail.comwrote: Hi Alex, should be fixed now, sorry. For some reason, buildr is skipping the extensions directory by default, at least in my install. Do you have any idea why? Tammo Alex Boisvert wrote: Anybody getting the same? Packaging apache-ode-docs-2.1-SNAPSHOT.zip Compiling ode-extensions:e4x into /home/boisvert/svn/ode/trunk/extensions/e4x/target/classes Compiling ode-extensions:e4x:test into /home/boisvert/svn/ode/trunk/extensions/e4x/target/test/classes /home/boisvert/svn/ode/trunk/extensions/e4x/src/test/java/org/apache/ode/extension/e4x/JSOperationTest.java:49: run(java.lang.Object,java.lang.String,org.w3c.dom.Element) in org.apache.ode.bpel.rtrep.common.extension.AbstractSyncExtensionOperation cannot be applied to (org.apache.ode.test.MockExtensionContext,org.w3c.dom.Element) jso.run(c, e); alex -- Tammo van Lessen - http://www.taval.de
Re: No svn tag for ODE 1.3.3
I just fixed both. alex On Wed, Aug 19, 2009 at 8:30 AM, Nowakowski, Mateusz mateusz.nowakow...@sabre-holdings.com wrote: I'll tried to download a svn tag for ODE 1.3.3, but I couldn't find it. It isn't here: http://svn.apache.org/repos/asf/ode/tags/APACHE_ODE_1.3.3 What is more JIRA says that ODE 1.3.3 is not a released version. -- Regards Mateusz Nowakowski
[jira] Updated: (ODE-624) HttpExternalService fails if message has no part
[ https://issues.apache.org/jira/browse/ODE-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-624: -- Fix Version/s: (was: 1.3.3) 1.3.4 HttpExternalService fails if message has no part Key: ODE-624 URL: https://issues.apache.org/jira/browse/ODE-624 Project: ODE Issue Type: Bug Components: Axis2 Integration Affects Versions: 1.3.2 Reporter: Alexis Midon Assignee: Alexis Midon Fix For: 1.3.4 HttpExternalService throws an exception if the request message has no part. This can be workarounded by creating a dummy part. The guilty is code is: Element authenticatePart = message == null ? null : DOMUtils.findChildByName(message, new QName(null, WWW-Authenticate)); If no parts exist, the message is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-618) system properties to set ports used by test cases
[
https://issues.apache.org/jira/browse/ODE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Boisvert updated ODE-618:
--
Fix Version/s: (was: 1.3.3)
1.3.4
system properties to set ports used by test cases
--
Key: ODE-618
URL: https://issues.apache.org/jira/browse/ODE-618
Project: ODE
Issue Type: Test
Components: Test environment
Reporter: Alexis Midon
Assignee: Alexis Midon
Fix For: 1.3.4
Ports and 7070 are hardcoded in axis2-war test suite. This prevents from
running multiple builds concurrently.
Ports used by test cases should be configurable through system properties for
instance.
The system proprety test.ports accepts a coma separated list of ports that
might be used by test cases. Based on this list Axis2TestBase creates a set
of properties named:
test,port.0, test.port.1, and so on
For instance test.ports=,7070 creates test.port.0= and
test.port.1=7070.
When building ODE, test.ports can be set from the command line by using the
TEST_PORTS env variable.
Like: $ buildr test TEST_P0RTS=,
Test cases must then use these properties to start their services. For
instance Axis2TestBase starts axis2 webapp on port test.port.0, a Jetty
instance runs on test.port.1.
Samples processes do not have to worry about the port they are deployed on.
This is handled by Axis2. However the url of external services must be set
through endpoint properties like:
alias.sample-ns=http://sample04.policy.samples.rampart.apache.org
sample-ns.sample04-policy.ode.address=http://localhost:${test.port.0}/axis2/processes/sample04-policy
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-616) create host and port properties for endpoint config
[ https://issues.apache.org/jira/browse/ODE-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-616: -- Fix Version/s: (was: 1.3.3) 1.3.4 create host and port properties for endpoint config --- Key: ODE-616 URL: https://issues.apache.org/jira/browse/ODE-616 Project: ODE Issue Type: Improvement Components: Axis2 Integration Reporter: Alexis Midon Assignee: Alexis Midon Fix For: 1.3.4 Let's assume you have a wsdl with multiple ports running on localhost:8080. Today if you migrate this service to another machine myserver:, the only way to specify the new machine (without changing the wsdl) is to use the 'address' property once per port, repeating the url paths from the wsdl file. For instance: alias.arithmetics-ns=http://ode/bpel/test/arithmetics arithmetics-ns.ArithmeticsService.GET_httpport.ode.address=http://myserver:/HttpBindingTest/ArithmeticsService/GET arithmetics-ns.ArithmeticsService.POST_httpport.ode.address=http://myserver:/HttpBindingTest/ArithmeticsService/POST Having two new properties 'host' and 'port' would allow to specify the new machine only once for all ports, without repeating the url paths. The previous example would become: alias.arithmetics-ns=http://ode/bpel/test/arithmetics arithmetics-ns.ArithmeticsService.ode.host=myserver arithmetics-ns.ArithmeticsService.ode.port= One edge case is when (host or port) and address are set. The address property must take precedence over host or port properties. So for instance, with the following endpoint file: alias.arithmetics-ns=http://ode/bpel/test/arithmetics arithmetics-ns.ArithmeticsService.ode.host=myserver arithmetics-ns.ArithmeticsService.ode.port= arithmetics-ns.ArithmeticsService.GET_httpport.ode.address=http://localhost:9090/HttpBindingTest/ArithmeticsService/GET All service port addresses will point to the mahcine myserver: except GET_httpport that would be invoked with the above url. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-612) ActivityRecovery failureOnFault
[ https://issues.apache.org/jira/browse/ODE-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-612: -- Fix Version/s: (was: 1.3.3) 1.3.4 ActivityRecovery failureOnFault --- Key: ODE-612 URL: https://issues.apache.org/jira/browse/ODE-612 Project: ODE Issue Type: New Feature Components: BPEL Runtime Reporter: Rafal Rusin Priority: Minor Fix For: 1.3.4 Attachments: failureOnFault.diff, test.zip It's nice to have a switch failureOnFault similar to faultOnFailure. ext:failureHandling xmlns:ext=http://ode.apache.org/activityRecovery; ext:failureOnFaulttrue/ext:failureOnFault /ext:failureHandling It's helpful when: - there are external variables errors (like constraint violations) and we want to repeat operation - we want to treat invoke fault responses as failures (to repeat) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-619) placeholders in endpoint properties
[
https://issues.apache.org/jira/browse/ODE-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Boisvert updated ODE-619:
--
Fix Version/s: (was: 1.3.3)
1.3.4
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-596) update paths in org.apache.ode.ql.SyntaxTest
[ https://issues.apache.org/jira/browse/ODE-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-596: -- Fix Version/s: (was: 1.3.3) 1.3.4 update paths in org.apache.ode.ql.SyntaxTest Key: ODE-596 URL: https://issues.apache.org/jira/browse/ODE-596 Project: ODE Issue Type: Sub-task Reporter: Alexis Midon Fix For: 1.3.4 buildr 1.3 has a slightly different layout -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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 ] Alex Boisvert updated ODE-586: -- Fix Version/s: (was: 1.3.3) 1.3.4 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.2 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-595) SimpleScheduler#stop does not cancel jobs
[ https://issues.apache.org/jira/browse/ODE-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-595: -- Fix Version/s: (was: 1.3.3) 1.3.4 SimpleScheduler#stop does not cancel jobs - Key: ODE-595 URL: https://issues.apache.org/jira/browse/ODE-595 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3.2 Reporter: Alexis Midon Assignee: Alexis Midon Fix For: 1.3.4 The current implementation of org.apache.ode.scheduler.simple.SimpleScheduler#stop does not try to interrupt the jobs that are actively executed nor to cancel jobs already in queue waiting to be executed. This is contradictory with the goal of the stop method. The stop method must do its best effort to interrupt any on going executions and cancel jobs in queue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-567) Improve process versioning in JBI
[ https://issues.apache.org/jira/browse/ODE-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-567: -- Fix Version/s: (was: 1.3.3) 1.3.4 Improve process versioning in JBI - Key: ODE-567 URL: https://issues.apache.org/jira/browse/ODE-567 Project: ODE Issue Type: Improvement Components: JBI Integration Affects Versions: 1.3.2 Reporter: Rafal Rusin Fix For: 1.3.4 Attachments: processVersionFromDUDirName.diff, versioning-not-recompiling-cpbs.diff Each time you redeploy a service assembly in servicemix, there's a new process version registered in ODE. Also an old entry (old cbp) is deleted, which causes old instances to throw 'error reloading compiled process' error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-560) Job failed during WAIT for incorrect date
[
https://issues.apache.org/jira/browse/ODE-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Boisvert updated ODE-560:
--
Fix Version/s: (was: 1.3.3)
1.3.4
Job failed during WAIT for incorrect date
-
Key: ODE-560
URL: https://issues.apache.org/jira/browse/ODE-560
Project: ODE
Issue Type: Bug
Components: BPEL Runtime
Affects Versions: 1.3.2
Reporter: Rafal Rusin
Fix For: 1.3.4
Attachments: jobFailedDuringWait.diff, jobFailedDuringWait.txt,
jobFailedDuringWaitTest.diff
There's a job failed exception during execution of such wait:
wait
forxsd:double('')/for
/wait
I'd expect something like selectionFailure fault to be thrown, but I'm not
sure.
I did a test case + fix (but a fix needs to throw something better than
'evaluationException' fault).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-563) Clustering
[ https://issues.apache.org/jira/browse/ODE-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-563: -- Fix Version/s: (was: 1.3.3) 1.3.4 Clustering -- Key: ODE-563 URL: https://issues.apache.org/jira/browse/ODE-563 Project: ODE Issue Type: Bug Components: Deployment Affects Versions: 1.2 Reporter: Sabir Ahamed Fix For: 1.3.4 We need to deploy Apache ODE in clustered environment to meet requirements for one of our projects. Per FAQ, the clustering support is under development, but it is not listed in the Roadmap. We need to know if clustering support will be provided in the next release i.e. 1.3. We will greatly appreciate if you let us know when this support will be added or if there is any workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-571) Instance work done within newest process version after receiving request to a retired instance
[ https://issues.apache.org/jira/browse/ODE-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-571: -- Fix Version/s: (was: 1.3.3) 1.3.4 Instance work done within newest process version after receiving request to a retired instance -- Key: ODE-571 URL: https://issues.apache.org/jira/browse/ODE-571 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3.2 Reporter: Rafal Rusin Fix For: 1.3.4 Attachments: executeInstanceInProperProcessVersion.diff I did following: 1. deployed process X version 1 2. started instance A 3. deployed process X version 2 4. continued instance A 5. instance A tried to read external variable, but it caused error, because it took definition from X version 2 I did some investigation and saw that in PartnerLinkMyRoleImpl.java, there is a runtime context created for my role partner link, which points to process X version 2. I did a patch, which took BpelProcess object from process instance's dao for execution and this solved problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-555) Error handling in-out operations while WAIT is put inside process
[ https://issues.apache.org/jira/browse/ODE-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-555: -- Fix Version/s: (was: 1.3.3) 1.3.4 Error handling in-out operations while WAIT is put inside process - Key: ODE-555 URL: https://issues.apache.org/jira/browse/ODE-555 Project: ODE Issue Type: Bug Components: Axis2 Integration Affects Versions: 1.3.2 Environment: tomcat 6.6, standard Derby configuration Reporter: Rafal Rusin Fix For: 1.3.4 Attachments: npe.log, rejectingInvocation-soapui-project.xml, rejectingInvocationScenario1.zip, rejectingInvocationScenario2.zip Scenario 1: receive initiate reply to initiate wait 10 sec. (here comes request for op1, it's saved to db) receive op1 reply to op1 After reply I got ERROR - GeronimoLog.error(108) | java.lang.NullPointerException at org.apache.ode.axis2.ODEService.onAxisMessageExchange(ODEService.java:186) (see npe.log) Scenario 2: receive initiate reply to initiate receive op1 (here comes request for op1, it's dispatched immediately) wait 10 sec. reply to op1 Here, I had process completion, but timeout waiting for response in client For both scenarios, please use the same soapui test case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-556) Rejecting in-out operations immediately when there's no route found
[ https://issues.apache.org/jira/browse/ODE-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-556: -- Fix Version/s: (was: 1.3.3) 1.3.4 Rejecting in-out operations immediately when there's no route found --- Key: ODE-556 URL: https://issues.apache.org/jira/browse/ODE-556 Project: ODE Issue Type: Improvement Components: BPEL Runtime Affects Versions: 1.3.2 Reporter: Rafal Rusin Fix For: 1.3.4 Attachments: handleInOutInstantly-soapui-project.xml, handleInOutInstantly.diff, handleInOutInstantly.zip A related discussion is here: http://markmail.org/thread/ethxp3y7373x72h3 A goal is to implement handling in-out operations immediately - resulting in failure when there's no route registered. But in-only operation should queue messages for later dispatching (just like before). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-528) Modifying tables from other schemas than default via extVar
[ https://issues.apache.org/jira/browse/ODE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-528: -- Fix Version/s: (was: 1.3.3) 1.3.4 Modifying tables from other schemas than default via extVar --- Key: ODE-528 URL: https://issues.apache.org/jira/browse/ODE-528 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3.2 Environment: All Reporter: Rafal Rusin Fix For: 1.3.4 Attachments: addSchemaToSelectInsertUpdate.diff I did a following entry for extVar in deploy.xml xvar:externalVariable id=var1 jdbc:jdbc jdbc:datasource-jndimyds/jdbc:datasource-jndi jdbc:tableMYSCHEMA1.MYTABLE/jdbc:table /jdbc:jdbc /xvar:externalVariable My default schema from JDBC connection is MYSCHEMA2. When I insert, select or update values in DB, there's a following sql generated: insert into MYTABLE values (...) however it ought to be: insert into MYSCHEMA1.MYTABLE values (...) then a table doesn't exist error is issued at runtime (note that extVar initialization completes successfully). I did some research and fixed it in bpel-runtime/src/main/java/org/apache/ode/bpel/extvar/jdbc/DbExternalVariable.java for ode1x. I run extvar test, which completed successfully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-552) Process instance did not continue after invoked process returned fault during P2P communication
[
https://issues.apache.org/jira/browse/ODE-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Boisvert updated ODE-552:
--
Fix Version/s: (was: 1.3.3)
1.3.4
Process instance did not continue after invoked process returned fault during
P2P communication
---
Key: ODE-552
URL: https://issues.apache.org/jira/browse/ODE-552
Project: ODE
Issue Type: Bug
Components: BPEL Runtime
Affects Versions: 1.3.2
Environment: Tomcat 6, Servicemix
Reporter: Rafal Rusin
Fix For: 1.3.4
Attachments: bpelex-sa-1.0-SNAPSHOT.jar, bpelex.zip,
incorrectInternalCommunication-soapui-project.xml,
incorrectInternalCommunication.diff, log-smx.txt, log-tomcat.txt, request.soap
There are 2 processes
A:
invoke B
B:
throw fault
A stops and logs show something like this:
11:49:34,708 | WARN | pool-4-thread-4 | OdeService |
org.apache.ode.jbi.OdeService 187 | Ignoring unknown async reply:
{MyRoleMex#hqejbhcnphr44dfq3nre56 [Client hqejbhcnphr44dfq3nre55] calling
{http://ftang.org/hello}HelloWorld2.process(...)}
I'm providing reproduction processes for JBI Tomcat.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-527) Failure recovery doesn't work while no serviceendpoint is registered
[
https://issues.apache.org/jira/browse/ODE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Boisvert updated ODE-527:
--
Fix Version/s: (was: 1.3.3)
1.3.4
Failure recovery doesn't work while no serviceendpoint is registered
Key: ODE-527
URL: https://issues.apache.org/jira/browse/ODE-527
Project: ODE
Issue Type: Bug
Components: JBI Integration
Affects Versions: 1.3.2
Environment: Servicemix 3.3
Reporter: Rafal Rusin
Fix For: 1.3.4
Attachments: failurerecovery.diff
Given a process, which INVOKEs some unregistered service endpoint, I had an
exception, which was occurring endlessly not regarding any activityRecovery
settings, such as faultOnFailure=true.
12:10:01,683 | ERROR | pool-4-thread-1 | SimpleScheduler |
duler.simple.SimpleScheduler$4 410 | Error while executing transaction
org.apache.ode.bpel.iapi.Scheduler$JobProcessorException:
java.lang.RuntimeException: org.apache.ode.bpel.iapi.ContextException:
Unknown endpoint: {ABC}Abc:default
at
org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:425)
at
org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:377)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:386)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:380)
at
org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:208)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:379)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:376)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException:
org.apache.ode.bpel.iapi.ContextException: Unknown endpoint: {ABC}ABC:default
at
org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:464)
at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:840)
at
org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.invokeNewInstance(PartnerLinkMyRoleImpl.java:206)
at
org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java:211)
at
org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:384)
at
org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:415)
... 11 more
Caused by: org.apache.ode.bpel.iapi.ContextException: Unknown endpoint:
{ABC}ABC:default
at
org.apache.ode.jbi.JbiEndpointReference.getServiceEndpoint(JbiEndpointReference.java:99)
at
org.apache.ode.jbi.JbiEndpointReference.toXML(JbiEndpointReference.java:64)
at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.invoke(BpelRuntimeContextImpl.java:759)
at org.apache.ode.bpel.runtime.INVOKE.run(INVOKE.java:100)
at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451)
... 17 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-535) conflictingReceive fault is thrown where no error is expected
[ https://issues.apache.org/jira/browse/ODE-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-535: -- Fix Version/s: (was: 1.3.3) 1.3.4 conflictingReceive fault is thrown where no error is expected - Key: ODE-535 URL: https://issues.apache.org/jira/browse/ODE-535 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3.2 Reporter: Rafal Rusin Fix For: 1.3.4 Attachments: conflictingReceive-reproduction.diff I made a following process: bpws:receive createInstance=yes operation=initiate bpws:correlations bpws:correlation initiate=yes/ /bpws:correlations /bpws:receive bpws:reply operation=initiate/ bpws:scope bpws:eventHandlers bpws:onEvent operation=initiate bpws:correlations bpws:correlation initiate=no/ /bpws:correlations bpws:scope bpws:sequence bpws:reply operation=initiate/ /bpws:sequence /bpws:scope /bpws:onEvent /bpws:eventHandlers bpws:sequence bpws:wait bpws:for![CDATA['PT30M']]/bpws:for /bpws:wait /bpws:sequence /bpws:scope Then I sent two requests with delay 1 second: initiate 101 wait 1 second initiate 101 A delay is for not causing conflictingRequest fault (which is not distinguished by ODE and thrown as conflictingReceive according to this: http://cwiki.apache.org/confluence/display/ODExSITE/WS-BPEL+2.0+Specification+Compliance). For second request I got a conflictingReceive fault. However, here, no error should be thrown. Here's a stacktrace for throwing conflictingReceive: 17:18:44,223 | ERROR | ODEServer-1 | BpelRuntimeContextImpl | eronimo.kernel.log.GeronimoLog 108 | conflictingReceive java.lang.Exception at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.select(BpelRuntimeContextImpl.java:333) at org.apache.ode.bpel.runtime.EH_EVENT$SELECT.run(EH_EVENT.java:137) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451) at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139) at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:870) at org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.invokeInstance(PartnerLinkMyRoleImpl.java:240) at org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java:224) at org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:392) at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:391) at org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:388) at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:386) at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:380) at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:208) at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:379) at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:376) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) So, I think an OutstandingRequestManager may incorrectly throw an exception on select registration, while there should be an error later on receiving an actual request. This will allow to dispatch a request via reply during onevent without any fault. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-438) Provide a migration script for 1.2 to 1.3 Hibernate and JPA databases
[ https://issues.apache.org/jira/browse/ODE-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-438: -- Fix Version/s: (was: 1.3.3) 1.3.4 Provide a migration script for 1.2 to 1.3 Hibernate and JPA databases - Key: ODE-438 URL: https://issues.apache.org/jira/browse/ODE-438 Project: ODE Issue Type: Task Components: Documentation Reporter: Alex Boisvert Fix For: 1.3.4 Related to ODE-377: alter table BPEL_SELECTORS add ROUTE_POLICY varchar(16) not null; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-460) Improve InstanceManagement.listInstancesSummary() to include failure information
[ https://issues.apache.org/jira/browse/ODE-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-460: -- Fix Version/s: (was: 1.3.3) 1.3.4 Improve InstanceManagement.listInstancesSummary() to include failure information Key: ODE-460 URL: https://issues.apache.org/jira/browse/ODE-460 Project: ODE Issue Type: Improvement Components: Management API Reporter: Alex Boisvert Fix For: 1.3.4 Attachments: ode-460.1x.patch Improve InstanceManagement.listInstancesSummary() to include failure information -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-479) Evaluate Exit Activity Eagerly
[ https://issues.apache.org/jira/browse/ODE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-479: -- Fix Version/s: (was: 1.3.3) 1.3.4 Evaluate Exit Activity Eagerly -- Key: ODE-479 URL: https://issues.apache.org/jira/browse/ODE-479 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3.2 Environment: platform-independent Reporter: Karthick Sankarachary Fix For: 1.3.4 As per section 10.10 of the BPEL 2.0 specification, a business process instance must evaluate the exit activity eagerly (as opposed to lazily). In particular, it must forcefully terminate all other running or pending activities, no questions asked. It has been insinuated that the implementation of the exit activity might not be as eager as it ought to be. This calls for a review of that piece of code, specifically to make sure that the reaction queue is flushed in a timely manner. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-491) ODE throws exception process is retired after restarting JBI container
[ https://issues.apache.org/jira/browse/ODE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-491: -- Fix Version/s: (was: 1.3.3) 1.3.4 ODE throws exception process is retired after restarting JBI container Key: ODE-491 URL: https://issues.apache.org/jira/browse/ODE-491 Project: ODE Issue Type: Bug Components: JBI Integration Affects Versions: 1.3.2 Environment: JBI Reporter: Rafal Rusin Fix For: 1.3.4 Attachments: process-register-in-any-order-test.diff, process-register-in-any-order.diff When two service assemblies with the same process (2 versions) are deployed and stopped / started in bad order (newer version first), ODE throws exception on each incoming message Process is retired. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-240) Upgrade to Buildr 1.3.0
[ https://issues.apache.org/jira/browse/ODE-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-240: -- Fix Version/s: (was: 1.3.3) 1.3.4 Upgrade to Buildr 1.3.0 --- Key: ODE-240 URL: https://issues.apache.org/jira/browse/ODE-240 Project: ODE Issue Type: Task Components: Build System Affects Versions: 1.1.1 Reporter: Alex Boisvert Assignee: Alex Boisvert Fix For: 1.3.4 Attachments: patch.txt Here's my current patch to make Ode 1.1 branch build work with Buildr 1.3.0 (trunk; unreleased yet) and Rake 0.8.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-456) Add configuration options for enabling dehydration in JBI
[ https://issues.apache.org/jira/browse/ODE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-456: -- Fix Version/s: (was: 1.3.3) 1.3.4 Add configuration options for enabling dehydration in JBI - Key: ODE-456 URL: https://issues.apache.org/jira/browse/ODE-456 Project: ODE Issue Type: Improvement Affects Versions: 1.3.2 Reporter: Vittorio Ballestra Fix For: 1.3.4 Attachments: patch.txt JBI Integration missed the possibility to enable dehydration of process. Added and added two new configuration options to configure it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-331) make the fault name explicit
[ https://issues.apache.org/jira/browse/ODE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-331: -- Fix Version/s: (was: 1.3.3) 1.3.4 make the fault name explicit Key: ODE-331 URL: https://issues.apache.org/jira/browse/ODE-331 Project: ODE Issue Type: Bug Affects Versions: 1.3.2 Reporter: Alexis Midon Assignee: Alexis Midon Priority: Minor Fix For: 1.3.4, 2.0 rename faultType into faultName whereever it makes sense. org.apache.ode.bpel.iapi.PartnerRoleMessageExchange#replyWithFault is a good start point. rename table column BPEL_MESSAGE_EXCHANGE.FAULT_TYPE into BPEL_MESSAGE_EXCHANGE.FAULT_NAME (see HMessageExchange) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-653) OdeSUManager produces component-task-result strings that are not fully compliant.
[ https://issues.apache.org/jira/browse/ODE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert resolved ODE-653. --- Resolution: Fixed Fix Version/s: 1.3.4 Patch applied to 1.x branch and trunk. Thanks! boisv...@sixtine:~/svn/ode/1.1$ svn commit -m ODE-653: OdeSUManager produces component-task-result strings that are not fully compliant (courtesy of Greg Lucas) Sendingjbi/src/main/java/org/apache/ode/jbi/OdeSUManager.java Transmitting file data . Committed revision 805931. boisv...@sixtine:~/svn/ode/trunk$ svn commit -m ODE-653: OdeSUManager produces component-task-result strings that are not fully compliant (courtesy of Greg Lucas) Sendingjbi/src/main/java/org/apache/ode/jbi/OdeSUManager.java Transmitting file data . Committed revision 805932. OdeSUManager produces component-task-result strings that are not fully compliant. -- Key: ODE-653 URL: https://issues.apache.org/jira/browse/ODE-653 Project: ODE Issue Type: Bug Components: JBI Integration Affects Versions: 1.3.3 Reporter: Greg Lucas Priority: Minor Fix For: 1.3.4 Attachments: ODE-653-1.x-patch.txt The JBI spec specifies that a ServiceUnitMnager must return an XML string of the component-task-result for the deploy/undeploy methods. The component-task-result must conform to the http://java.sun.com/xml/ns/jbi/management-message schema. The OdeSUManager currently returns component-task-result strings that do not declare the namespace, so parsing these strings produces an XML document that does actually conform to the schema in the spec. ServiceMix will treat these result strings as invalid and ignore them. I've submitted an SMX4 patch to handle the case where no namespace is declared, but think that ODE should fully conform to the spec regardless of whether that patch gets applied. (Note that the ServiceUnitManager javadoc is a bit misleading as the example it shows has the xmlns declaration on the wrong node. I think the text of the JBI spec is more authoritative and would consider the example in the javadoc incorrect as well. The ODE result string doesn't match the example either.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-652) When ODE gets an runtime exception it doesn't handle it properly
[
https://issues.apache.org/jira/browse/ODE-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Boisvert resolved ODE-652.
---
Resolution: Invalid
When ODE gets an runtime exception it doesn't handle it properly
Key: ODE-652
URL: https://issues.apache.org/jira/browse/ODE-652
Project: ODE
Issue Type: Bug
Components: BPEL Runtime, JBI Integration
Affects Versions: 1.3.3
Environment: WinXP, Fuse-3.4.0.4,Apache ODE 1.3.3 JBI
Reporter: Mateusz Nowakowski
Fix For: 1.3.4
When NullPointer was thrown from WHILE.checkCondition() (JIRA ODE-651)
it is only logged and isn't handled at all.
This extension is configured
ext:faultOnFailuretrue/ext:faultOnFailure
but this NullPointer is not considered as failure and BPEL script simply
hangs
It doesn't return to JBI at all as well as an MessageExchange ERROR or fault.
What is more, this is written to logs a bit later:
2009-08-19 17:01:19,525 [pool-5-thread-48] WARN
org.apache.ode.bpel.memdao.ProcessDaoImpl - Discarding in-memory instance 3
because it exceeded its time-to-live:
mem.instance(type={https://webservices.sabre.com/websvc}Enhanced_AirBookProcess1.0.1
iid=3)
PS. What is time-to-live for BPEL processes? Is it configurable?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-652) When ODE gets an runtime exception it doesn't handle it properly
[
https://issues.apache.org/jira/browse/ODE-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745201#action_12745201
]
Alex Boisvert commented on ODE-652:
---
This behavior is as designed. Java exceptions occuring inside the engine
are never visible to processes.
The time-to-live was discussed here:
http://ode.markmail.org/search/?q=inmem.ttl#query:inmem.ttl+page:1+mid:7ldgsgjuprk7itvl+state:results)
I'll add a mention of it in the documentation.
When ODE gets an runtime exception it doesn't handle it properly
Key: ODE-652
URL: https://issues.apache.org/jira/browse/ODE-652
Project: ODE
Issue Type: Bug
Components: BPEL Runtime, JBI Integration
Affects Versions: 1.3.3
Environment: WinXP, Fuse-3.4.0.4,Apache ODE 1.3.3 JBI
Reporter: Mateusz Nowakowski
Fix For: 1.3.4
When NullPointer was thrown from WHILE.checkCondition() (JIRA ODE-651)
it is only logged and isn't handled at all.
This extension is configured
ext:faultOnFailuretrue/ext:faultOnFailure
but this NullPointer is not considered as failure and BPEL script simply
hangs
It doesn't return to JBI at all as well as an MessageExchange ERROR or fault.
What is more, this is written to logs a bit later:
2009-08-19 17:01:19,525 [pool-5-thread-48] WARN
org.apache.ode.bpel.memdao.ProcessDaoImpl - Discarding in-memory instance 3
because it exceeded its time-to-live:
mem.instance(type={https://webservices.sabre.com/websvc}Enhanced_AirBookProcess1.0.1
iid=3)
PS. What is time-to-live for BPEL processes? Is it configurable?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-649) Incorrect NPE check in JPA MessageDAOImpl
[ https://issues.apache.org/jira/browse/ODE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert resolved ODE-649. --- Resolution: Fixed Fix Version/s: 2.0 Thanks. A little code review never hurts... Patch applied. boisv...@sixtine:~/svn/ode/trunk$ svn commit -m ODE-649: Incorrect NPE check in JPA MessageDAOImpl Sendingdao-jpa/src/main/java/org/apache/ode/dao/jpa/MessageDAOImpl.java Transmitting file data . Committed revision 804147. Incorrect NPE check in JPA MessageDAOImpl - Key: ODE-649 URL: https://issues.apache.org/jira/browse/ODE-649 Project: ODE Issue Type: Bug Affects Versions: 2.0 Reporter: William McCusker Fix For: 2.0 Attachments: MessageDAOImpl.dff In the JPA MessageDAOImpl a NPE check was added to the constructor, however the instance variable is being checked for null instead of the method argument on which the actual NPE can occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ODE-645) Possible connection leak during JdbcExternalVariableModule if initialization fails
Possible connection leak during JdbcExternalVariableModule if initialization
fails
--
Key: ODE-645
URL: https://issues.apache.org/jira/browse/ODE-645
Project: ODE
Issue Type: Bug
Components: BPEL Runtime
Affects Versions: 1.3.2
Reporter: Alex Boisvert
Same exception stack that demonstrates an possible error during initialization:
13:38:26,139 ERROR [ExternalVariableManager] External variable subsystem
configuration error.
org.apache.ode.bpel.evar.ExternalVariableModuleException: Unable to open
database connection for external variable
{http://example.com/Allocations/Cost_Allocation_Process}Cost_Allocation_Process-5#db_cost_t_alloc_clist-_vjMgGC5wEd6TcMWz-L7Zyw
at
org.apache.ode.bpel.extvar.jdbc.JdbcExternalVariableModule.configure(JdbcExternalVariableModule.java:119)
at
org.apache.ode.bpel.engine.extvar.ExternalVariableManager.init(ExternalVariableManager.java:87)
at
org.apache.ode.bpel.engine.BpelProcess.initExternalVariables(BpelProcess.java:164)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.doHydrate(BpelProcess.java:862)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.access$100(BpelProcess.java:777)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch$2.run(BpelProcess.java:787)
at org.apache.ode.bpel.engine.NStateLatch.latch(NStateLatch.java:89)
at
org.apache.ode.bpel.engine.BpelProcess.getEndpointToMyRoleMap(BpelProcess.java:707)
at
org.apache.ode.bpel.engine.BpelProcess.initMyRoleMex(BpelProcess.java:292)
at
org.apache.ode.bpel.engine.BpelEngineImpl.createNewMyRoleMex(BpelEngineImpl.java:173)
at
org.apache.ode.bpel.engine.BpelEngineImpl.createMessageExchange(BpelEngineImpl.java:143)
at
org.apache.ode.bpel.engine.BpelEngineImpl.createMessageExchange(BpelEngineImpl.java:196)
at
org.apache.ode.axis2.ODEService.onAxisMessageExchange(ODEService.java:114)
at
org.apache.ode.axis2.hooks.ODEMessageReceiver.invokeBusinessLogic(ODEMessageReceiver.java:69)
at
org.apache.ode.axis2.hooks.ODEMessageReceiver.invokeBusinessLogic(ODEMessageReceiver.java:52)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.sql.SQLException: You cannot set autocommit during a managed
transaction!
at
org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.setJdbcAutoCommit(BaseWrapperManagedConnection.java:482)
at
org.jboss.resource.adapter.jdbc.WrappedConnection.setAutoCommit(WrappedConnection.java:322
[jira] Resolved: (ODE-645) Possible connection leak during JdbcExternalVariableModule if initialization fails
[
https://issues.apache.org/jira/browse/ODE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Boisvert resolved ODE-645.
---
Resolution: Fixed
Fix Version/s: 2.0
1.3.3
Fixed in trunk,
boisv...@sixtine:~/svn/ode/trunk$ svn commit -m ODE-645: Possible connection
leak during JdbcExternalVariableModule if initialization fails
Sending
engine/src/main/java/org/apache/ode/bpel/extvar/jdbc/JdbcExternalVariableModule.java
Transmitting file data .
Committed revision 802135.
Fixed in 1.1 branch,
boisv...@sixtine:~/svn/ode/1.1$ svn commit -m ODE-645: Possible connection
leak during JdbcExternalVariableModule if initialization fails
Sending
bpel-runtime/src/main/java/org/apache/ode/bpel/extvar/jdbc/JdbcExternalVariableModule.java
Transmitting file data .
Committed revision 802136.
Possible connection leak during JdbcExternalVariableModule if initialization
fails
--
Key: ODE-645
URL: https://issues.apache.org/jira/browse/ODE-645
Project: ODE
Issue Type: Bug
Components: BPEL Runtime
Affects Versions: 1.3.2
Reporter: Alex Boisvert
Fix For: 1.3.3, 2.0
Same exception stack that demonstrates an possible error during
initialization:
13:38:26,139 ERROR [ExternalVariableManager] External variable subsystem
configuration error.
org.apache.ode.bpel.evar.ExternalVariableModuleException: Unable to open
database connection for external variable
{http://example.com/Allocations/Cost_Allocation_Process}Cost_Allocation_Process-5#db_cost_t_alloc_clist-_vjMgGC5wEd6TcMWz-L7Zyw
at
org.apache.ode.bpel.extvar.jdbc.JdbcExternalVariableModule.configure(JdbcExternalVariableModule.java:119)
at
org.apache.ode.bpel.engine.extvar.ExternalVariableManager.init(ExternalVariableManager.java:87)
at
org.apache.ode.bpel.engine.BpelProcess.initExternalVariables(BpelProcess.java:164)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.doHydrate(BpelProcess.java:862)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.access$100(BpelProcess.java:777)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch$2.run(BpelProcess.java:787)
at org.apache.ode.bpel.engine.NStateLatch.latch(NStateLatch.java:89)
at
org.apache.ode.bpel.engine.BpelProcess.getEndpointToMyRoleMap(BpelProcess.java:707)
at
org.apache.ode.bpel.engine.BpelProcess.initMyRoleMex(BpelProcess.java:292)
at
org.apache.ode.bpel.engine.BpelEngineImpl.createNewMyRoleMex(BpelEngineImpl.java:173)
at
org.apache.ode.bpel.engine.BpelEngineImpl.createMessageExchange(BpelEngineImpl.java:143)
at
org.apache.ode.bpel.engine.BpelEngineImpl.createMessageExchange(BpelEngineImpl.java:196)
at
org.apache.ode.axis2.ODEService.onAxisMessageExchange(ODEService.java:114)
at
org.apache.ode.axis2.hooks.ODEMessageReceiver.invokeBusinessLogic(ODEMessageReceiver.java:69)
at
org.apache.ode.axis2.hooks.ODEMessageReceiver.invokeBusinessLogic(ODEMessageReceiver.java:52)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156
[jira] Updated: (ODE-645) Possible connection leak during JdbcExternalVariableModule if initialization fails
[
https://issues.apache.org/jira/browse/ODE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Boisvert updated ODE-645:
--
Description:
Here's a sample exception stacktrace that demonstrates a possible error during
initialization:
13:38:26,139 ERROR [ExternalVariableManager] External variable subsystem
configuration error.
org.apache.ode.bpel.evar.ExternalVariableModuleException: Unable to open
database connection for external variable
{http://example.com/Allocations/Cost_Allocation_Process}Cost_Allocation_Process-5#db_cost_t_alloc_clist-_vjMgGC5wEd6TcMWz-L7Zyw
at
org.apache.ode.bpel.extvar.jdbc.JdbcExternalVariableModule.configure(JdbcExternalVariableModule.java:119)
at
org.apache.ode.bpel.engine.extvar.ExternalVariableManager.init(ExternalVariableManager.java:87)
at
org.apache.ode.bpel.engine.BpelProcess.initExternalVariables(BpelProcess.java:164)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.doHydrate(BpelProcess.java:862)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.access$100(BpelProcess.java:777)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch$2.run(BpelProcess.java:787)
at org.apache.ode.bpel.engine.NStateLatch.latch(NStateLatch.java:89)
at
org.apache.ode.bpel.engine.BpelProcess.getEndpointToMyRoleMap(BpelProcess.java:707)
at
org.apache.ode.bpel.engine.BpelProcess.initMyRoleMex(BpelProcess.java:292)
at
org.apache.ode.bpel.engine.BpelEngineImpl.createNewMyRoleMex(BpelEngineImpl.java:173)
at
org.apache.ode.bpel.engine.BpelEngineImpl.createMessageExchange(BpelEngineImpl.java:143)
at
org.apache.ode.bpel.engine.BpelEngineImpl.createMessageExchange(BpelEngineImpl.java:196)
at
org.apache.ode.axis2.ODEService.onAxisMessageExchange(ODEService.java:114)
at
org.apache.ode.axis2.hooks.ODEMessageReceiver.invokeBusinessLogic(ODEMessageReceiver.java:69)
at
org.apache.ode.axis2.hooks.ODEMessageReceiver.invokeBusinessLogic(ODEMessageReceiver.java:52)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.sql.SQLException: You cannot set autocommit during a managed
transaction!
at
org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.setJdbcAutoCommit(BaseWrapperManagedConnection.java:482)
at
org.jboss.resource.adapter.jdbc.WrappedConnection.setAutoCommit(WrappedConnection.java:322)
at
org.apache.ode.bpel.extvar.jdbc.JdbcExternalVariableModule.configure(JdbcExternalVariableModule.java:116)
... 39 more
13:38:26,245 ERROR [NStateLatch] Latch error, was releasing
[jira] Resolved: (ODE-644) INTERNAL ERROR: No ENTRY for RESPONSE CHANNEL [xy]
[ https://issues.apache.org/jira/browse/ODE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert resolved ODE-644. --- Resolution: Fixed Fix Version/s: 2.0 1.3.3 Patches applied. Thanks Bill!! boisv...@sixtine:~/svn/ode/1.1$ svn commit -m ODE-644: INTERNAL ERROR: No ENTRY for RESPONSE CHANNEL [xy] Sending dao-hibernate/src/main/java/org/apache/ode/daohib/bpel/CorrelatorDaoImpl.java Sending dao-jpa/src/main/java/org/apache/ode/dao/jpa/CorrelatorDAOImpl.java Transmitting file data .. Committed revision 802257. boisv...@sixtine:~/svn/ode/trunk$ svn commit -m ODE-644: INTERNAL ERROR: No ENTRY for RESPONSE CHANNEL [xy] Sending dao-hibernate/src/main/java/org/apache/ode/daohib/bpel/CorrelatorDaoImpl.java Sending dao-jpa/src/main/java/org/apache/ode/dao/jpa/CorrelatorDAOImpl.java Transmitting file data .. Committed revision 802258. INTERNAL ERROR: No ENTRY for RESPONSE CHANNEL [xy] -- Key: ODE-644 URL: https://issues.apache.org/jira/browse/ODE-644 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3.2, 2.0 Reporter: William McCusker Fix For: 1.3.3, 2.0 Attachments: responsechannel_hib_1x.diff, responsechannel_hib_trunk.diff, responsechannel_jpa_1x.diff, responsechannel_trunk_jpa.diff When a receive activity is repeated for the same partner link and operation (for example a pick activity inside of a while loop) the second message with often result inINTERNAL ERROR: No ENTRY for RESPONSE CHANNEL [xy] where xy ends up being the id of the old channel used for the first receive. In the JPA case this is because org.apache.ode.dao.jpa.CorrelatorDAOImpl removeLocalRoutes calls EntityManager remove but since it is using managed transactions these changes are not necessarily committed immediately. The mem dao should be unaffected by this, still need to test hibernate but it appears safe. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-634) Event Handles not working
[ https://issues.apache.org/jira/browse/ODE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-634: -- Comment: was deleted (was: I will be out of the office from August 5th 2009 until August 10th 2009. If you have questions regarding BPEL Maestro, please send an email to bpelsupp...@parasoft.com. Otherwise, I will answer your email upon my return. ) 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 Attachments: account-sa.zip, account-soapui-project.xml, event_handler_1x.patch, event_handler_trunk.patch 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] Updated: (ODE-634) Event Handles not working
[ https://issues.apache.org/jira/browse/ODE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-634: -- Comment: was deleted (was: I will be out of the office from August 5th 2009 until August 10th 2009. If you have questions regarding BPEL Maestro, please send an email to bpelsupp...@parasoft.com. Otherwise, I will answer your email upon my return. ) 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 Attachments: account-sa.zip, account-soapui-project.xml, event_handler_1x.patch, event_handler_trunk.patch 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] Updated: (ODE-634) Event Handles not working
[ https://issues.apache.org/jira/browse/ODE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-634: -- Comment: was deleted (was: I will be out of the office from August 5th 2009 until August 10th 2009. If you have questions regarding BPEL Maestro, please send an email to bpelsupp...@parasoft.com. Otherwise, I will answer your email upon my return. ) 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 Attachments: account-sa.zip, account-soapui-project.xml, event_handler_1x.patch, event_handler_trunk.patch 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] Updated: (ODE-634) Event Handles not working
[ https://issues.apache.org/jira/browse/ODE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-634: -- Comment: was deleted (was: I will be out of the office from August 5th 2009 until August 10th 2009. If you have questions regarding BPEL Maestro, please send an email to bpelsupp...@parasoft.com. Otherwise, I will answer your email upon my return. ) 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 Attachments: account-sa.zip, account-soapui-project.xml, event_handler_1x.patch, event_handler_trunk.patch 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] Created: (ODE-642) ProcessManagement.listInstances() returns duplicate failures element
ProcessManagement.listInstances() returns duplicate failures element
Key: ODE-642
URL: https://issues.apache.org/jira/browse/ODE-642
Project: ODE
Issue Type: Bug
Components: Axis2 Integration
Affects Versions: 1.3.2
Reporter: Alex Boisvert
Fix For: 2.0
Here is an example of current response from ProcessManagement.listInstances()
soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
soapenv:Body
axis2ns4766:listInstancesResponse
xmlns:axis2ns4766=http://www.apache.org/ode/pmapi;
instance-info-list
---
ns:instance-info
xmlns:ns=http://www.apache.org/ode/pmapi/types/2006/08/02/;
ns:iid21815/ns:iid
ns:pid{http://example.com/ChangeNotification/Change_Notification}Change_Notification-23/ns:pid
ns:process-name
xmlns:chan=http://example.com/ChangeNotification/Change_Notification;chan:Change_Notification/ns:process-name
ns:root-scope siid=21818 status=ACTIVE
name=__PROCESS_SCOPE:Change_Notification modelId=3/
ns:statusACTIVE/ns:status
ns:dt-started2009-08-05T11:24:17.247+02:00/ns:dt-started
ns:dt-last-active2009-08-05T11:24:17.953+02:00/ns:dt-last-active
ns:event-info
ns:count58/ns:count
ns:first-dtime2009-08-05T11:24:17.248+02:00/ns:first-dtime
ns:last-dtime2009-08-05T11:24:17.943+02:00/ns:last-dtime
/ns:event-info
ns:failures
ns:dt-failure2009-08-05T11:24:17.943+02:00/ns:dt-failure
ns:count1/ns:count
/ns:failures
ns:failures
ns:dt-failure2009-08-05T11:24:17.943+02:00/ns:dt-failure
ns:count1/ns:count
/ns:failures
/ns:instance-info
---
/instance-info-list
/axis2ns4766:listInstancesResponse
/soapenv:Body
/soapenv:Envelope
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-642) ProcessManagement.listInstances() returns duplicate failures element
[
https://issues.apache.org/jira/browse/ODE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Boisvert resolved ODE-642.
---
Resolution: Fixed
Fixed in 1.1 branch,
boisv...@sixtine:~/svn/ode/1.1$ svn commit -m ODE-642:
ProcessManagement.listInstances() returns duplicate failures element
Sending
bpel-runtime/src/main/java/org/apache/ode/bpel/engine/ProcessAndInstanceManagementImpl.java
Transmitting file data .
Committed revision 801353.
And trunk,
boisv...@sixtine:~/svn/ode/trunk$ svn commit -m ODE-642:
ProcessManagement.listInstances() returns duplicate failures element
Sending
engine/src/main/java/org/apache/ode/bpel/engine/ProcessAndInstanceManagementImpl.java
Transmitting file data .
Committed revision 801355.
ProcessManagement.listInstances() returns duplicate failures element
Key: ODE-642
URL: https://issues.apache.org/jira/browse/ODE-642
Project: ODE
Issue Type: Bug
Components: Axis2 Integration
Affects Versions: 1.3.2
Reporter: Alex Boisvert
Fix For: 2.0
Here is an example of current response from ProcessManagement.listInstances()
soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
soapenv:Body
axis2ns4766:listInstancesResponse
xmlns:axis2ns4766=http://www.apache.org/ode/pmapi;
instance-info-list
---
ns:instance-info
xmlns:ns=http://www.apache.org/ode/pmapi/types/2006/08/02/;
ns:iid21815/ns:iid
ns:pid{http://example.com/ChangeNotification/Change_Notification}Change_Notification-23/ns:pid
ns:process-name
xmlns:chan=http://example.com/ChangeNotification/Change_Notification;chan:Change_Notification/ns:process-name
ns:root-scope siid=21818 status=ACTIVE
name=__PROCESS_SCOPE:Change_Notification modelId=3/
ns:statusACTIVE/ns:status
ns:dt-started2009-08-05T11:24:17.247+02:00/ns:dt-started
ns:dt-last-active2009-08-05T11:24:17.953+02:00/ns:dt-last-active
ns:event-info
ns:count58/ns:count
ns:first-dtime2009-08-05T11:24:17.248+02:00/ns:first-dtime
ns:last-dtime2009-08-05T11:24:17.943+02:00/ns:last-dtime
/ns:event-info
ns:failures
ns:dt-failure2009-08-05T11:24:17.943+02:00/ns:dt-failure
ns:count1/ns:count
/ns:failures
ns:failures
ns:dt-failure2009-08-05T11:24:17.943+02:00/ns:dt-failure
ns:count1/ns:count
/ns:failures
/ns:instance-info
---
/instance-info-list
/axis2ns4766:listInstancesResponse
/soapenv:Body
/soapenv:Envelope
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-637) Embedded Derby db not shutdown
[ https://issues.apache.org/jira/browse/ODE-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert resolved ODE-637. --- Resolution: Fixed Fix Version/s: 1.3.3 Patches applied. Thanks! boisv...@sixtine:~/svn/ode/1.1$ svn commit -m ODE-637: Embedded Derby db not shutdown Sendingbpel-epr/src/main/java/org/apache/ode/il/dbutil/Database.java Transmitting file data . Committed revision 798320. boisv...@sixtine:~/svn/ode/trunk$ svn commit -m ODE-637: Embedded Derby db not shutdown Sendingil-common/src/main/java/org/apache/ode/il/dbutil/Database.java Transmitting file data . Committed revision 798321. Embedded Derby db not shutdown -- Key: ODE-637 URL: https://issues.apache.org/jira/browse/ODE-637 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3.2 Reporter: William McCusker Fix For: 1.3.3 Attachments: derby_shutdown_1x.patch, derby_shutdown_trunk.patch When undeploying and redeploying the ode jbi service unit while using the embedded derby db the following exception occurred. It seems the _needDerbyShutdown variable is never being set in org.apache.ode.il.dbutil.Database. Not sure if this affects the trunk. Caused by: ERROR XSDB6: Another instance of Derby may have already booted the database C:\apache-servicemix-4.1.0\data\jbi\OdeBpelEngine\install\jpadb. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.privGetJBMSLockOnDB(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.getJBMSLockOnDB(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.boot(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source) at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source) at org.apache.derby.impl.store.access.RAMAccessManager.boot(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source) at org.apache.derby.impl.db.BasicDatabase.bootStore(Unknown Source) at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown Source -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-635) Propagate DeploymentException when SA deployment fails.
[ https://issues.apache.org/jira/browse/ODE-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert resolved ODE-635. --- Resolution: Won't Fix Propagate DeploymentException when SA deployment fails. --- Key: ODE-635 URL: https://issues.apache.org/jira/browse/ODE-635 Project: ODE Issue Type: Improvement Components: JBI Integration Affects Versions: 1.3.2, 1.3.3, 2.0 Environment: ServiceMix 4 Reporter: Daniel Dominguez Attachments: ODE-635.patch I'm working on deployment tooling for ServiceMix4 / FUSE. The deploy and undeploy method in OdeSUManager does not throw a DeploymentException when there is a problem with a service assembly (i.e. bad deploy.xml). In contrast the start and stop methods both throw DeploymentException when appropriate. The problem this causes for me is that when I attempt to deploy and start a service assembly, the deploy appears to succeed but the start returns an unrelated error which is difficult to diagnose. I've created a simple patch which will throw the DeploymentException instead of an error string which is ignored by smx4. Is this a reasonable approach? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-635) Propagate DeploymentException when SA deployment fails.
[ https://issues.apache.org/jira/browse/ODE-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12730576#action_12730576 ] Alex Boisvert commented on ODE-635: --- The JBI spec is not very good at clarifying what the behavior should be... It says among other things, A failed deployment of the service unit must be reported using the component-task-result element as well; the task-result must be set to FAILED. (page 131) but also says that the deploy() method, Throws: javax.jbi.management.DeploymentException141 - if the deployment operation is unsuccessful. (page 132) As well as, Components supply status/result strings as XML strings that conform to the component-task-result-details type from the above schema. For example, the ServiceUnitManager.deploy() method returns such a status/ result string. The JBI implementation MUST combine the status/result strings supplied by components into the the overall status/result document defined above. (page 86) So it's difficult to determine which behavior is correct... Propagate DeploymentException when SA deployment fails. --- Key: ODE-635 URL: https://issues.apache.org/jira/browse/ODE-635 Project: ODE Issue Type: Improvement Components: JBI Integration Affects Versions: 1.3.2, 1.3.3, 2.0 Environment: ServiceMix 4 Reporter: Daniel Dominguez Attachments: ODE-635.patch I'm working on deployment tooling for ServiceMix4 / FUSE. The deploy and undeploy method in OdeSUManager does not throw a DeploymentException when there is a problem with a service assembly (i.e. bad deploy.xml). In contrast the start and stop methods both throw DeploymentException when appropriate. The problem this causes for me is that when I attempt to deploy and start a service assembly, the deploy appears to succeed but the start returns an unrelated error which is difficult to diagnose. I've created a simple patch which will throw the DeploymentException instead of an error string which is ignored by smx4. Is this a reasonable approach? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Expression validation interface in ODE BPEL compiler
Sounds good! On Thu, Jul 9, 2009 at 1:03 PM, Rafal Rusin rafal.ru...@gmail.com wrote: Hello, I'm planning to add an interface for external expression validator into ODE compiler. That way there could appear 3rd party plugins, which do validation using any tools. I'm also planning to write an example implementation, which makes use of Saxon SA (Schema Aware commercial version) and publish it as open source 3rd party plugin. Saxon SA does well job of finding schema related problems in expressions - xpaths and xqueries, so it may be useful. There was also a discussion some time ago about providing Psycho XPath schema aware validation. It was about substituting Saxon in ODE, which ended up as a bad idea. But implementing it as an external plugin for ODE can be a good idea. Regards, -- Rafał Rusin http://www.touk.pl http://top.touk.pl http://www.mimuw.edu.pl/~rrusin http://www.mimuw.edu.pl/%7Errusin
Re: Is there any way how to get bpmn:id?
The sequence should be roughly as follows,
OdeManagedConnectionFactory mcf = new OdeManagedConnectionFactory();
mcf.setURL(url);
OdeConnectionFactory cf = (OdeConnectionFactory)
mcf.createConnectionFactory();
ProcessManagementConnection pmc = cf.getConnection();
alex
On Wed, Jul 8, 2009 at 4:56 AM, Karel Gardas karel.gar...@centrum.czwrote:
Hi Alex,
it took me some time to figure out needed changes in buildr
infrastructure, but it's finally compiling and I'm getting into
following issue.
Alex Boisvert wrote:
Indeed... BpelManagementFactory is a proprietary class (not in Apache
Ode)
which hides the lookup of the ProcessManagement API remote interface. I
didn't realize when I cut pasted the code, sorry. The class is tied
to
other stuff (e.g. loading of configuration, etc.) so I can't share it
easily.
Take a look at the following classes for facilities to connect to the PM
API
via RMI:
org.apache.ode.bpel.jca.clientapi.ProcessManagementConnection;
org.apache.ode.ra.OdeConnectionFactory;
org.apache.ode.ra.OdeManagedConnectionFactory;
both ProcessManagementConnection and OdeConnectionFactory are just
interfaces so I started digging into OdeManagedConnectionFactory with
the following testing code:
OdeManagedConnectionFactory fact = new
OdeManagedConnectionFactory();
try {
OdeConnectionFactory con_fact =
(OdeConnectionFactory)fact.createConnectionFactory();
System.err.println(con_fact.getClass().getName());
javax.resource.cci.Connection con = con_fact.getConnection();
System.err.println(con.getClass().getName());
}
catch (Exception e) {
e.printStackTrace();
}
the intention is what can I get from it?. The problem is on the line:
javax.resource.cci.Connection con = con_fact.getConnection();
I get following exception:
Unable to create connection: Protocol error: unexpected remote object
type!; nested exception is:
java.lang.ClassCastException: sun.rmi.registry.RegistryImpl_Stub
cannot
be cast to org.apache.ode.ra.transports.rmi.OdeRemote
at
org.apache.ode.ra.OdeManagedConnectionFactory.createManagedConnection(OdeManagedConnectionFactory.java:100)
at
org.apache.ode.ra.OdeConnectionManager.allocateConnection(OdeConnectionManager.java:34)
at
org.apache.ode.ra.OdeConnectionFactoryImpl.getConnection(OdeConnectionFactoryImpl.java:46)
at org.apache.ode.bpel.runtime.ASSIGN.run(ASSIGN.java:95)
at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451)
at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:875)
at
org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.invokeNewInstance(PartnerLinkMyRoleImpl.java:206)
at
org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java:237)
at
org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:408)
at
org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:439)
at
org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:441)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:411)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:404)
at
org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:218)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:404)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:400)
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.rmi.RemoteException: Protocol error: unexpected remote
object type!; nested exception is:
java.lang.ClassCastException: sun.rmi.registry.RegistryImpl_Stub
cannot
be cast to org.apache.ode.ra.transports.rmi.OdeRemote
at
org.apache.ode.ra.transports.rmi.RMITransport.createPipe(RMITransport.java:45)
at
org.apache.ode.ra.OdeManagedConnectionFactory.createManagedConnection(OdeManagedConnectionFactory.java:98)
... 24 more
Caused by: java.lang.ClassCastException:
sun.rmi.registry.RegistryImpl_Stub cannot be cast to
org.apache.ode.ra.transports.rmi.OdeRemote
Re: Is there any way how to get bpmn:id?
Did you try rmi://localhost:2099/jcaServer ?
alex
On Wed, Jul 8, 2009 at 4:55 PM, Karel Gardas karel.gar...@centrum.czwrote:
Alex,
I'm not sure which URL to use. I've tried simple
http://localhost:8080/ode , various rmi://x but no way. BTW: is this
JCA connector listening on 0.0.0.0:8009 when ODE is running inside
tomcat/axis container?
Do you have any idea what url to use to set OdeManagedConnectionFactory?
Thanks,
Karel
Alex Boisvert wrote:
The sequence should be roughly as follows,
OdeManagedConnectionFactory mcf = new OdeManagedConnectionFactory();
mcf.setURL(url);
OdeConnectionFactory cf = (OdeConnectionFactory)
mcf.createConnectionFactory();
ProcessManagementConnection pmc = cf.getConnection();
alex
On Wed, Jul 8, 2009 at 4:56 AM, Karel Gardas karel.gar...@centrum.cz
wrote:
Hi Alex,
it took me some time to figure out needed changes in buildr
infrastructure, but it's finally compiling and I'm getting into
following issue.
Alex Boisvert wrote:
Indeed... BpelManagementFactory is a proprietary class (not in Apache
Ode)
which hides the lookup of the ProcessManagement API remote interface.
I
didn't realize when I cut pasted the code, sorry. The class is tied
to
other stuff (e.g. loading of configuration, etc.) so I can't share it
easily.
Take a look at the following classes for facilities to connect to the
PM
API
via RMI:
org.apache.ode.bpel.jca.clientapi.ProcessManagementConnection;
org.apache.ode.ra.OdeConnectionFactory;
org.apache.ode.ra.OdeManagedConnectionFactory;
both ProcessManagementConnection and OdeConnectionFactory are just
interfaces so I started digging into OdeManagedConnectionFactory with
the following testing code:
OdeManagedConnectionFactory fact = new
OdeManagedConnectionFactory();
try {
OdeConnectionFactory con_fact =
(OdeConnectionFactory)fact.createConnectionFactory();
System.err.println(con_fact.getClass().getName());
javax.resource.cci.Connection con = con_fact.getConnection();
System.err.println(con.getClass().getName());
}
catch (Exception e) {
e.printStackTrace();
}
the intention is what can I get from it?. The problem is on the line:
javax.resource.cci.Connection con = con_fact.getConnection();
I get following exception:
Unable to create connection: Protocol error: unexpected remote object
type!; nested exception is:
java.lang.ClassCastException: sun.rmi.registry.RegistryImpl_Stub
cannot
be cast to org.apache.ode.ra.transports.rmi.OdeRemote
at
org.apache.ode.ra.OdeManagedConnectionFactory.createManagedConnection(OdeManagedConnectionFactory.java:100)
at
org.apache.ode.ra.OdeConnectionManager.allocateConnection(OdeConnectionManager.java:34)
at
org.apache.ode.ra.OdeConnectionFactoryImpl.getConnection(OdeConnectionFactoryImpl.java:46)
at org.apache.ode.bpel.runtime.ASSIGN.run(ASSIGN.java:95)
at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451)
at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:875)
at
org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.invokeNewInstance(PartnerLinkMyRoleImpl.java:206)
at
org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java:237)
at
org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:408)
at
org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:439)
at
org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:441)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:411)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:404)
at
org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:218)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:404)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:400)
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused
Re: Is there any way how to get bpmn:id?
Hi Karel,
Here's a code fragment that does roughtly what you want:
ProcessManagementConnection conn =
BpelManagementFactory.getInstance().createConnection();
try {
ActivityExtInfoListDocument s =
conn.getExtensibilityElements(pid, aiid);
TActivitytExtInfoList l = s.getActivityExtInfoList();
ListTActivityExtInfo ll = l.getActivityExtInfoList();
for (TActivityExtInfo info : ll) {
NodeList nl = ((Element)
info.getDomNode()).getElementsByTagNameNS(BPMN_NS, BPMN_ID);
for (int i = 0; i nl.getLength(); i++) {
Node n = nl.item(i);
result.add(n.getFirstChild().getNodeValue());
}
}
} catch (Exception e) {
...
}
As you can see, you mostly need to use the Process Management API and the
BPEL object model.
alex
On Tue, Jul 7, 2009 at 6:07 AM, Karel Gardas karel.gar...@centrum.czwrote:
Hello,
I'm trying to find out but so far unsuccessful hence the question: is
there any way how to get bpmn:id which is assigned to some action
directly in action's code? i.e. I do have following code:
bpel:sequence
bpel:scope bpmn:label=SubProcess name=SubProcess
bpmn:id=_KddAgBq8Ed6g-K1VcIMszw
and I would like to get bpmn:id's value, i.e. _KddAgBq8Ed6g-K1VcIMszw
somehow in SCOPE.java code. I'm currently using ODE from 1.X branch.
Thanks,
Karel
Re: suggestion for building ode
Fixed. The update will be mirrored within 24 hours. alex On Mon, Jun 22, 2009 at 6:24 AM, Naoki Okitsu okit...@m2.gyao.ne.jp wrote: Hi! Can I suggest my opinion about bulding eclipse? There is build command buildr eclipse and buildr test. http://ode.apache.org/building-ode.html But I think that it is better to type below at build time. buildr _1.2.10_ eclipse buildr _1.2.10_ test Because you might update buildr version. To type command specifically ,I build successfully. What do you think about my opinion?
Re: assessing ODE for Billing Application
You can take a look here for a sample of companies using Intalio|BPM which is based on Apache Ode. http://www.intalio.com/customers/ alex On Fri, Jun 19, 2009 at 8:09 PM, Joshua Zeidner jjzeid...@gmail.com wrote: Hello, I am currently assessing ODE for use in a complex billing system. I am familiar with the functional and historical aspects of workflow engines and I see specific opportunities for using ODE. I do have some concerns however, primarily stability. Basic workflow/BPEL support is all I am looking for. Are there any major commercial projects that use ODE for a billing application in ie. Insurance or Financial services industry? Can anyone offer advice as to the current state of ODE? Is it ready to be used by a commercial web based services vendor? Thank you, Joshua Zeidner
Re: Passing Custom SOAP Headers
Hi JP, There's no clean and simple way to do this right now with Ode. We've discussed it a few times on the mailing list (most notably herehttp://markmail.org/message/7iozv6r55mprv3ej#query:JBI%20and%20correlation%20of%20MessageExchange%20ode+page:1+mid:gfxq2kpz4bgtpwiu+state:results), however no concrete design has been proposed and nothing has been implemented towards supporting such implicit assignments (from the message to the process and back). It's been on the project's wishlist for a while now and I've had discussions with Tammo van Lessen recently about getting it done sooner rather than later. You can contact me privately if you're interested in providing some form financial support for such effort. Design suggestions and patches are also very welcome :) I think your best alternative at this time would be to add explicit header assignments. alex On Thu, Jun 18, 2009 at 8:55 AM, j.p.r...@accenture.com wrote: Have already posted this to the user mailing list but on reflection expect that the hard core technical heads on ODE would be better placed to comment. Currently on our project when external services invoke an ODE BPEL process they provide a customised SOAP:Header in the web service call. The BPEL process invokes other external web services as part of the business process. My requirement is to pass the value from the inbound SOAP:Header request to all external services that are invoked as a SOAP:Header. Ideally I want to do this transparently without having to code mapping the data, particularly as the value passed in is not business data and is required for all services. Is using a custom MessageExchangeInterceptor together with using the ode-axis2.mex.interceptors property the correct approach to solving this problem? Any direction on the approach or other solutions greatly appreciated. Thanks in advance, James This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: Unpack job details blob in database
My suggestion would be to develop it on trunk, test it there and then assess whether it can easily be backported to 1.X, taking into consideration migration of existing deployments. I'm wondering if there is a need for migration on trunk. Does anyone know of people running 2.x (trunk) in production? alex 2009/6/15 Rafal Rusin rafal.ru...@gmail.com Which versions do we choose for implementation (1X or trunk, or maybe both)? 2009/6/10 Alex Boisvert boisv...@intalio.com: 2009/6/10 Sean Ahn a...@intalio.com +1 on making instance id, job type, retry count, etc to separate columns To convert the blob to a varchar or text, I'm not sure if a comma-separated name-value would be enough though, since it's a map of string to object(any object). We should make it a map of string to string then... I don't see a need to store arbitrary binary objects in the job details. alex -- Rafał Rusin http://www.touk.pl http://top.touk.pl http://www.mimuw.edu.pl/~rrusin http://www.mimuw.edu.pl/%7Errusin
Re: validate activity
Yes, it's up for grabs. Methinks I need to start keeping a tab for the amount of beer I will owe you :) alex 2009/6/15 Rafal Rusin rafal.ru...@gmail.com Hello, what's the status for: https://issues.apache.org/jira/browse/ODE-121 It looks like abandoned. Can I take it over? If you have some other ways of doing transport validation, please let me know. -- Rafał Rusin http://www.touk.pl http://top.touk.pl http://www.mimuw.edu.pl/~rrusin http://www.mimuw.edu.pl/%7Errusin
Re: Stability / time frame for 2.0
I don't think 2.x (trunk) has been used enough to yet to qualify it as production-ready for a wide audience. This being said, it may be suitable for new projects that can afford enough testing and some hiccups during development and QA phases. Intalio's intention is to migrate to 2.x (trunk) in our next major product release which will probably be released sometime in the first half of 2010. To this end, we will ramp-up testing of 2.x during the second half of 2009. alex 2009/6/13 Guillaume Nodet gno...@gmail.com Hi everybody. Is there any information about the time frame for a 2.0 release ? Also, what's the stability of 2.0 wrt the latest 1.x ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: broken trunk build?
Yes, there was a bug https://issues.apache.org/jira/browse/BUILDR-253 in buildr 1.3.3 and before where jars were created without compression. Can you give us more details on what's not working with ode.war? alex On Fri, Jun 12, 2009 at 7:12 AM, Kurt T Stam kurt.s...@gmail.com wrote: BTW, I tried this on both OSX as well as Centos-5.3, jdk5_19, buildr-1.3.4. It runs all the unittests. It looks like the compression of the ode jars changed. --Kurt Kurt T Stam wrote: Hi guys, I tried building the trunk today and noticed that the size of my ode.war dropped from 52426305 Apr 29 15:26 ode.war to 34306632 Jun 11 23:47 ode.war and the current war is not working for me. No processes get deployed when I copy the examples to ode/WEB-INF/processes, while that works fine in the Apr 29 build. Is the current code base simply not working, or is it me? Thx, --Kurt
Re: Unpack job details blob in database
+1 we should eliminate the blob column. I think we should at least have a column that can be used to correlate the job with something else, such as an instance id, and possibly a column for the job type. Both of these should narrow down the number of entries to a manageable size for querying and then loading all the matches in memory for inspection. Retry count is generally applicable to all schedules so I'd make it a column as well. I don't recall if there are other fields that are generally applicable... and I think we'll still need a job-specific details column but it could be a string (varchar) with comma-deliminate name-value pairs instead of a blob. We could also get rid of the 'scheduled' and 'transacted' columns which are no longer of any use, IIRC. alex On Wed, Jun 10, 2009 at 12:41 AM, Rafal Rusin rafal.ru...@gmail.com wrote: I suggest an improvement for ODE_JOB database table. There's a blob column job details, which is hard to maintain. For example, there's no way of doing selects on details entries. It'd be great to have those details extracted into separate columns instead. What do think about this? -- Rafał Rusin http://www.touk.pl http://top.touk.pl http://www.mimuw.edu.pl/~rrusin http://www.mimuw.edu.pl/%7Errusin
Re: Unpack job details blob in database
2009/6/10 Sean Ahn a...@intalio.com +1 on making instance id, job type, retry count, etc to separate columns To convert the blob to a varchar or text, I'm not sure if a comma-separated name-value would be enough though, since it's a map of string to object(any object). We should make it a map of string to string then... I don't see a need to store arbitrary binary objects in the job details. alex
Re: Really need help with soap namespace mismatch
I agree, the ServiceMix HTTP binding component should know to use SOAP 1.1.I don't have any good suggestion for you Did you ask the ServiceMix mailing list? alex On Wed, Jun 3, 2009 at 7:57 AM, Ian Harrigan ianharri...@hotmail.comwrote: Hi All, Im trying to invoke an axis2 web service deployed inside tomcat, heres the basic definition of it: xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; wsdl:binding name=EchoServiceSOAP11Binding type=ns0:EchoServicePortType soap:binding transport=http://schemas.xmlsoap.org/soap/http; style=document/ wsdl:operation name=echo soap:operation soapAction=urn:echo style=document/ wsdl:input soap:body use=literal/ /wsdl:input wsdl:output soap:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:port name=EchoServiceSOAP11port_http binding=ns0:EchoServiceSOAP11Binding soap:address location= http://localhost:8080/axis2/services/EchoService/ smix:endpoint role=provider defaultMep=in-out/ /wsdl:port I would have though that this would mean that service mix would have to use SOAP1.1 to invoke it (because of the 'soap' namespace), however, when i try to invoke it service mix shows the soap request as having a namespace of http://www.w3.org/2003/05/soap-envelope which is SOAP 1.2, i then get the error from tomcat/axis2 saying there is a mismatch, ie, im trying to send a soap1.2 request to a soap1.1 port/binding. Can anyone help me with this??? I reall dont see what else i can try. Thanks, Ian
[jira] Commented: (ODE-612) ActivityRecovery failureOnFault
[ https://issues.apache.org/jira/browse/ODE-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712749#action_12712749 ] Alex Boisvert commented on ODE-612: --- External variable errors should always be failures. Do you have a case where it produces a fault? If so, please open a separate issue for that. ActivityRecovery failureOnFault --- Key: ODE-612 URL: https://issues.apache.org/jira/browse/ODE-612 Project: ODE Issue Type: New Feature Components: BPEL Runtime Reporter: Rafal Rusin Priority: Minor Fix For: 1.3.3 Attachments: failureOnFault.diff, test.zip It's nice to have a switch failureOnFault similar to faultOnFailure. ext:failureHandling xmlns:ext=http://ode.apache.org/activityRecovery; ext:failureOnFaulttrue/ext:failureOnFault /ext:failureHandling It's helpful when: - there are external variables errors (like constraint violations) and we want to repeat operation - we want to treat invoke fault responses as failures (to repeat) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ODE-608) NPE during ONE-WAY-invoke because of clean-up category 'messages'
[ https://issues.apache.org/jira/browse/ODE-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert reassigned ODE-608: - Assignee: Sean Ahn NPE during ONE-WAY-invoke because of clean-up category 'messages' -- Key: ODE-608 URL: https://issues.apache.org/jira/browse/ODE-608 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 2.0 Environment: Linux, Jetty/Tomcat5.5 Reporter: heiko rath Assignee: Sean Ahn Fix For: 2.0 We've defined some invokes. The last invoke is a ONE-WAY-invoke. Also we've defined the following cleanup: cleanup on=success categoryinstance/category categoryvariables/category categorymessages/category categorycorrelations/category categoryevents/category /cleanup Wenn the ONE-WAY-invoke is called we get a java.lang.NullPointerException at org.apache.ode.il.epr.WSAEndpoint.init(WSAEndpoint.java:49) at org.apache.ode.axis2.soapbinding.SoapExternalService.writeHeader(SoapExternalService.java:270) at org.apache.ode.axis2.soapbinding.SoapExternalService.invoke(SoapExternalService.java:144) at org.apache.ode.axis2.MessageExchangeContextImpl.invokePartnerUnreliable(MessageExchangeContextImpl.java:68) at org.apache.ode.bpel.engine.PartnerLinkPartnerRoleImpl$UnreliableInvoker.run(PartnerLinkPartnerRoleImpl.java:345) at org.apache.ode.bpel.engine.ODEProcess$ProcessRunnable.run(ODEProcess.java:1215) at org.apache.ode.bpel.engine.BpelServerImpl$ServerRunnable.run(BpelServerImpl.java:927) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) If we're removing the category 'messages' in the cleanup-tag, we don't get the NPE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (ODE-601) *MY* dynamic endpoint references have suddenly stopped working :(
Speaking for the Intalio crew, we've been swamped in work recently putting Apache Ode and other technologies in the clouds... http://www.intalio.com/news/blog-posts/mad-rush/ http://www.intalio.com/news/press-releases/intalio-acquires-bpm-and-crm-companies-launches-intalio-cloud/ We'll get back to your issue soon after we land back on terra firma. alex On Tue, May 19, 2009 at 2:58 AM, Ciaran ciar...@gmail.com wrote: I would really appreciate some feedback, just anything really on this issue I *cannot* use ODE currently, and I would rather like to given the time I've invested in investigating the memory issues previously :( Many thanks. -cj. On Thu, May 14, 2009 at 8:27 PM, Ciaran ciar...@gmail.com wrote: Hi Folks,Has anyone had a chance to look at this issue at all? I still cannot use ODE with this issue in the code (or in my BPEL wherever the fault is), which is a shame :( -cj. On Tue, May 12, 2009 at 4:47 PM, Ciaran Jessup (JIRA) j...@apache.org wrote: *MY* dynamic endpoint references have suddenly stopped working :( - Key: ODE-601 URL: https://issues.apache.org/jira/browse/ODE-601 Project: ODE Issue Type: Bug Affects Versions: 1.3.2, 1.3.3 Environment: n/a Reporter: Ciaran Jessup My BPEL flows (I *think*, although its possible this hasn't been function as expected) used to work before changeset [765432] (on the ODE 1_XXX branch), they no longer do (and continue to work when I rever that changeset out. I think its something to do with the 'location' property now being set on the variable reference where it previously wasn't, but I'm very very out of depth. I've attached what I think is the relevant snipped of BPEL that I'm using for doing my invoke: !-- in the bpel:variables section -- bpel:variable name=DynamicEndpointRef element=wsa:EndpointReference / !--- Trying to invoke a service call -- bpel:assign name=proxyPreparation bpel:copy bpel:from bpel:literal wsa:EndpointReference xmlns:swsdl=uri:swsdl wsa:Address / wsa:ServiceName PortName=PPSSoapswsdl:PPS/wsa:ServiceName /wsa:EndpointReference /bpel:literal /bpel:from bpel:to variable=DynamicEndpointRef / /bpel:copy bpel:copy bpel:frombpel:doXslTransform(GetNextAddress.xsl,$DynamicEndpointRef/wsa:Address)/bpel:from bpel:to variable=ProxyAddress / /bpel:copy bpel:copy bpel:from variable=ProxyAddress / bpel:to variable=DynamicEndpointRef bpel:querywsa:Address/bpel:query /bpel:to /bpel:copy bpel:copy bpel:from variable=DynamicEndpointRef / bpel:to partnerLink=PPS / /bpel:copy bpel:copy bpel:from bpel:literal swsdl:PPI swsdl:processId9f538fdb-ca36-4d5d-a056-d6bf92632f75/swsdl:processId /swsdl:PPI /bpel:literal /bpel:from bpel:to variable=ppIn part=parameters / /bpel:copy /bpel:assign bpel:invoke name=InvokePPS partnerLink=PPS portType=swsdl:PPSSoap operation=PPI inputVariable=ppIn outputVariable=ppOut / And when the flow executes I see an error along the lines of : ERROR - GeronimoLog.error(104) | Couldn't find endpoint for partner EPR ?xml version=1.0 encoding=UTF-8? service-ref xmlns=http://docs.oasis-open.org/wsbpel/2.0/serviceref; Address xmlns= http://schemas.xmlsoap.org/ws/2003/03/addressing; http://server/myaddress.asmx?wsdl/Address wsa:ServiceName xmlns:wsa= http://schemas.xmlsoap.org/ws/2003/03/addressing; PortName=PPSSoapswsdl:PPS/wsa:ServiceName /service-ref I do not get this error, and the correct web service seems to get called when I revert the change.. any ideas, is my BPEL flawed, or has an issue been introduced? Please find attached a fully deployed process, this will require you to mock a service that adheres to the wsdl in proxy.wsdl. A request such as : soapenv:Envelope xmlns:soapenv= http://schemas.xmlsoap.org/soap/envelope/; xmlns:wor=http://www.myco.com/xml/sa/4.0/Workflow/; xmlns:smf=http://www.myco.com/xml/sa/4.0/smf; soapenv:Header/ soapenv:Body wor:ExecuteWorkflow wor:userCredentials smf:userId03d27fc0-5ede-4cb8-89d7-6bf7510e16c6/smf:userId smf:applicationNameNA/smf:applicationName /wor:userCredentials wor:workItem version=54 smf:stateBECE5689-A575-4531-86B6-15176D827C08/smf:state /wor:workItem /wor:ExecuteWorkflow /soapenv:Body /soapenv:Envelope Will cause the error to occur on trunk head, but the error won't occur if you revert changeset [765432] I do believe its to dow with the dynamic addressing breaking the partnerlink stuff, but I'm not clever enough to pin it down :( -- This
Re: ODE 1.3.2 issues
2009/5/13 Nowakowski, Mateusz mateusz.nowakow...@sabre-holdings.com I've changed the subject because it was misleading. I did a build and I see there is an issue with duplicated Manifest-Versions. I think this may warrant an upgrade to Buildr 1.3.4 on the 1.X branch. What is more I have another question. I saw that both bundles: war and JBI binding component rely on openjpa-1.3.0-SNAPSHOT.jar. I don't know what are the reasons, but it causes that the official stable ODE release is based on unstable library. It may disqualify this release for production purposes. SNAPSHOT doesn't necessarily imply unstable, although I can understand the discomfort of running on something that's not officially blessed. If you're running Ode in production, I would suggest running on the Hibernate DAOs at this time. We can upgrade to an official OpenJPA version in the next release. Can you file bugs for both of these issues? alex
Re: Saxon Dependencies in ODE 1.3.2
From the Rakefile, here are the repositories we use: repositories.remote http://www.intalio.org/public/maven2; repositories.remote http://people.apache.org/repo/m2-incubating-repository; repositories.remote http://repo1.maven.org/maven2; repositories.remote http://people.apache.org/repo/m2-snapshot-repository repositories.remote http://download.java.net/maven/2; repositories.remote http://ws.zones.apache.org/repository2; and you can find the Saxon 9.x dependencies here: http://www.intalio.org/public/maven2/net/sf/saxon/ alex On Wed, May 13, 2009 at 8:44 PM, Luciano Resende luckbr1...@gmail.comwrote: I'm updating the Tuscany BPEL extensions to use the latest ODE release, and I need to find the saxon-9.x dependencies from a maven repo. I understand you guys does not use maven, but would you know about a public maven repo that would have the saxon-9.x dependencies available. -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: [VOTE] ODE 1.3.2 release
+1 On Wed, Apr 29, 2009 at 3:00 PM, Alexis Midon mi...@intalio.com wrote: Here we go again, I cut another ODE release, ODE-1.3.2. Since the last attempt, 2 issues were fixed: https://issues.apache.org/jira/browse/ODE-591 https://issues.apache.org/jira/browse/ODE-597 Other issues included in this release are listed here: https://issues.apache.org/jira/browse/ODE/fixforversion/12313906 The distribution artifacts are available here: http://people.apache.org/~midon/ode/dist/1.3.2http://people.apache.org/%7Emidon/ode/dist/1.3.2 http://people.apache.org/%7Emidon/ode/dist/1.3.2 Specifically: http://people.apache.org/~midon/ode/dist/1.3.2/apache-ode-jbi-1.3.2.ziphttp://people.apache.org/%7Emidon/ode/dist/1.3.2/apache-ode-jbi-1.3.2.zip http://people.apache.org/%7Emidon/ode/dist/1.3.2/apache-ode-jbi-1.3.2.zip http://people.apache.org/~midon/ode/dist/1.3.2/apache-ode-war-1.3.2.ziphttp://people.apache.org/%7Emidon/ode/dist/1.3.2/apache-ode-war-1.3.2.zip http://people.apache.org/%7Emidon/ode/dist/1.3.2/apache-ode-war-1.3.2.zip http://people.apache.org/~midon/ode/dist/1.3.2/apache-ode-sources-1.3.2.ziphttp://people.apache.org/%7Emidon/ode/dist/1.3.2/apache-ode-sources-1.3.2.zip http://people.apache.org/%7Emidon/ode/dist/1.3.2/apache-ode-sources-1.3.2.zip http://people.apache.org/~midon/ode/dist/1.3.2/apache-ode-docs-1.3.2.ziphttp://people.apache.org/%7Emidon/ode/dist/1.3.2/apache-ode-docs-1.3.2.zip http://people.apache.org/%7Emidon/ode/dist/1.3.2/apache-ode-docs-1.3.2.zip I hope we'll have plenty of +1 when I'll get back from my paternity leave. So cast your vote! Here is my +1. Alexis
Re: Deployment of a process with an erroneous deploy.xml
It's a bug. The property should be validated early and deployment should be
rejected if it's invalid. Right now, it looks like things fail after
deployment (due to the invalid property).
alex
On Thu, Apr 23, 2009 at 5:10 AM, Denis Weerasiri ddweeras...@gmail.comwrote:
Hi,
I tried to deploy a process with a following deploy.xml. Here I'm tring to
test deploy a process with an incomplete property element. Here the
property has no name attribute
?xml version=1.0 encoding=UTF-8?
deploy xmlns=http://www.apache.org/ode/schemas/dd/2007/03;
xmlns:helloWorld=http://helloWorld;
process name=helloWorld:HelloWorldNew
activetrue/active
process-events generate=all/
provide partnerLink=client
service name=helloWorld:HelloWorldProcessService
port=HelloWorldProcessPort/
/provide
cleanup on=always /
*propertyabcd1234/property *
/process
/deploy
While deploying the process it gives the following stack.
ERROR - GeronimoLog.error(108) | Error persisting deployment record for {
http://helloWorld}HelloWorldNew-1; process will not be available after
restart!
java.lang.NullPointerException
at
org.apache.ode.store.jpa.ProcessConfDaoImpl.setProperty(ProcessConfDaoImpl.java:134)
at
org.apache.ode.store.ProcessStoreImpl$2.call(ProcessStoreImpl.java:281)
at
org.apache.ode.store.ProcessStoreImpl$2.call(ProcessStoreImpl.java:255)
at
org.apache.ode.store.ProcessStoreImpl$Callable.call(ProcessStoreImpl.java:719)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
DEBUG - GeronimoLog.debug(66) | Process store event:
{ProcessStoreEvent#DEPLOYED:{http://helloWorld}HelloWorldNew-1}
DEBUG - GeronimoLog.debug(66) | Ignoring store event:
{ProcessStoreEvent#DEPLOYED:{http://helloWorld}HelloWorldNew-1}.
But after restarting the ODE, the same process is still there. Is this a
bug.?
Or as the deploy.xml is erroneous, why the deploy.xml is not discarded at
the deployment time?
Best Regards,
Denis Weerasiri.
Re: Two Google Summer of Code project for ODE
Congratulations to the students and mentors for getting these projects under way! alex On Thu, Apr 23, 2009 at 11:27 AM, Tammo van Lessen tvanles...@gmail.comwrote: Hi ODEers, I'm a bit late with this mail, but nevertheless I'm happy to announce that Google has accepted two students for Apache ODE within this years GSOC. Please join me to welcome Denis and Chamith in our community. Congratulation! Here are some (brief) details about the projects: - Apache ODE Integration in BPELUnit (Chamith) As you can guess, the goal is integrate BPELUnit with ODE to have a more powerful testing environment (for both, ODE itself and BPEL processes) http://wiki.apache.org/general/BuddhikaChamith/BPELUnit_GSOC2009_Proposal_BuddhikaChamith - Web-based BPEL debugger for Apache ODE (Denis) This project aims at integrating Oryx into ODE's web console that enables debugging running process instances in a graphical (BPMN) fashion. http://wiki.apache.org/general/ddweerasiri/GSOC2009Proposals/WebBasedBPELDebuggerForApacheODE I believe we have a good mentoring team (consisting of Oryx, BPELUnit and ODE guys, and of course the respective communities :)) for both students, so I'm very optimistic that both projects will succeed. I'm looking forward to seeing both projects evolving towards a more successful and convincing open source BPEL solution. Best, Tammo -- Tammo van Lessen - http://www.taval.de
[jira] Updated: (ODE-589) Clean up the process hydration logic
[ https://issues.apache.org/jira/browse/ODE-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-589: -- Fix Version/s: 1.3.1 Clean up the process hydration logic Key: ODE-589 URL: https://issues.apache.org/jira/browse/ODE-589 Project: ODE Issue Type: Improvement Reporter: Sean Ahn Fix For: 1.3.1 During the process hydration, we check if the signature(guid) of the process has been changed. This was to support different store implementations to dynamically pick up any process changes. Other store implementations should now send down the UNDEPLOY event to the engine to get the new process definition picked up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Apache ODE- building to get eclipse project files
Works fine for me using:
export JAVA_OPTS=-Xms64m -Xmx768m
Are you using a 64-bit JVM?
alex
On Mon, Apr 20, 2009 at 9:25 AM, Ernestina Martel Jordán
emar...@iuma.ulpgc.es wrote:
Hi,
I tried building ode but I have problems. First, my operating system is
Windows Vista
and I am using JDK 1.5.
I have installed Ruby 1.8 and buildr 1.2.10 to build the stable ode release
(ode-1.x). I
have also set the JAVA_OPTS variable to -Xms1g -Xmx 1g to increase the heap
size.
However when I execute buildr _1.2.10_ TEST=no ode:package
I get the following error:
C:\Users\emartel\ode-1.Xbuildr _1.2.10_ TEST=no ode:package
(in C:/Users/emartel/ode-1.X)
C:/Users/emartel/ode-1.X/rakefile:515: warning: don't put space before
argument
parentheses
C:/Users/emartel/ode-1.X/tasks/derby.rake:22: Deprecated: please use
Java.wrappe
r() instead
C:/Users/emartel/ode-1.X/tasks/derby.rake:22: Deprecated: use setup {
|wrapper|
... } instead
Error occurred during initialization of VM
Could not reserve enough space for object heap
rake aborted!
can't create Java VM
C:/Users/emartel/ode-1.X/rakefile:143:in `manifest'
(See full trace by running task with --trace)
I look through the development mailing list but I haven't found any
solution.
I do appreciate any help.
Thanks in advance.
--
Ernestina Martel Jordán
Despacho 211. Pabellón C.
Tfno: 34-928-452876 Fax: 34-928-451243
Departamento de Ingeniería Telemática
Campus Universitario de Tafira, s/n. Tafira Baja
35017 Las Palmas de Gran Canaria
CANARY ISLANDS. SPAIN
[jira] Assigned: (ODE-570) Integer to string conversion does not work as expected
[ https://issues.apache.org/jira/browse/ODE-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert reassigned ODE-570: - Assignee: Karthick Sankarachary Integer to string conversion does not work as expected -- Key: ODE-570 URL: https://issues.apache.org/jira/browse/ODE-570 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 2.0 Environment: N/A Reporter: Serkan Camurcuoglu Assignee: Karthick Sankarachary Priority: Minor Attachments: HelloWorld2.zip Original Estimate: 48h Remaining Estimate: 48h According to XPath 1.0 specification section 4.2 (http://www.w3.org/TR/xpath#section-String-Functions) the string() function should work this way for integers: if the number is an integer, the number is represented in decimal form as a Number with no decimal point and no leading zeros, preceded by a minus sign (-) if the number is negative but for example using the string() function on an integer with value 2 results in the string 2.0 which is not correct according to the specification. The result should be the string 2 according to the specification. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 'enableSharing' in deploy.xml
It relates to publish-subscribe semantic on endpoints.
https://issues.apache.org/jira/browse/ODE-364
Karthick, could you update the documentation at
http://ode.apache.org/user-guide.html#UserGuide-DeploymentDescriptor ?
thanks,
alex
On Wed, Apr 1, 2009 at 11:22 PM, Ciaran ciar...@gmail.com wrote:
Hi folks,
I notice that Alexis references an 'enableSharing' element in deploy.xml in
this issue comment, but I can't find any definition in the documentation as
to what this element actually means, can anyone explain why I might want
this on or off for my deployments ?
Sorry folks! :)
-cj.
On Wed, Apr 1, 2009 at 11:50 PM, Alexis Midon (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/ODE-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694809#action_12694809
]
Alexis Midon commented on ODE-568:
--
It appears we don't need the unique name introduced by ODE-345 as the key
of the service map.
Actually, if a service is shared by multiple processes (i.e.
enableSharing/ set in deploy.xml), only one single instance of
ODEService
is created. [1]
In other cases, the assumption that different processes hava different
service name/port name is valid.
So {service name, port name} is a valid key for the service map.
[1]
http://fisheye6.atlassian.com/browse/ode/branches/APACHE_ODE_1.X/bpel-runtime/src/main/java/org/apache/ode/bpel/engine/BpelProcess.java?r=APACHE_ODE_1.X#l561
Undeploying a process does not remove corresponding service from ODE
axis2
--
Key: ODE-568
URL: https://issues.apache.org/jira/browse/ODE-568
Project: ODE
Issue Type: Bug
Components: Axis2 Integration
Affects Versions: 1.3
Reporter: Alexis Midon
Assignee: Alexis Midon
Undeploying a process does not remove corresponding service from axis2
You can see that webservice in Axis2 service list view.
http://localhost:8080/ode/axis2-admin/listService
It requires login. Default login details: admin/axis2
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-424) SimpleScheduler creates duplicate jobs when job execution fails
[ https://issues.apache.org/jira/browse/ODE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-424: -- Fix Version/s: (was: 2.0) SimpleScheduler creates duplicate jobs when job execution fails --- Key: ODE-424 URL: https://issues.apache.org/jira/browse/ODE-424 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.2 Reporter: Alex Boisvert Assignee: Alex Boisvert Fix For: 1.3 SimpleScheduler create duplicate jobs when job execution fails -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Anyone @ ApacheCon?
On Wed, Mar 25, 2009 at 11:15 PM, Senaka Fernando senaka...@gmail.comwrote: Is anyone from ODE attending ApacheCon? Not to my knowledge. Many of us are in US and we've skipped ApacheCon EU this year. We should have good representation in ApacheCon US (Oakland). alex
[jira] Updated: (ODE-561) Process hydration/dehydration improvements to better control memory footprint
[ https://issues.apache.org/jira/browse/ODE-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert updated ODE-561: -- Summary: Process hydration/dehydration improvements to better control memory footprint (was: Bandwidth Throttling For BPEL Server) Process hydration/dehydration improvements to better control memory footprint - Key: ODE-561 URL: https://issues.apache.org/jira/browse/ODE-561 Project: ODE Issue Type: Improvement Components: Axis2 Integration, BPEL Compilation/Parsing, BPEL Runtime, JBI Integration Affects Versions: 1.2 Reporter: Karthick Sankarachary Assignee: Karthick Sankarachary Fix For: 1.3 Original Estimate: 336h Remaining Estimate: 336h At present, the BPEL server stashes the metadata of deployed processes in an in-memory, unbounded cache. Given the unbounded nature of the cache, the server is bound to eventually run out of memory when presented with a sufficiently large process set. The graceful way to handle this situation would be to place bounds on the cache, either in terms of the total size or number of processes that it may contain at any given point in time. While throttling the server this way may effectively reduce its throughput, it is certainly the far lesser evil compared to the alternative. To that end, we define the following configurable properties for the benefit of the administrator: a) process.hydration.throttled.maximum.size: The value of this property specifies the maximum size of the metadata of all processes that are currently in-use and may be cached in-memory. If the process metadata was hydrated at least once by the server instance, then its size is calculated once by traversing its object model. If not, then we estimate its in-memory size based on the size of the (.cbp) file where its serialized bytes are persisted. b) process.hydration.throttled.maximum.count: The value of this property specifies the maximum number of processes that are currently in-use and whose metadata may be cached in-memory. A process that is stored on disk but is not loaded in-memory is said to be unhydrated. When the server receives a message that is targeted at an unhydrated process, we must decide whether or not there is sufficient free memory in the cache for it. If not, then we select the least recently used process as our victim and evict (or dehydrate) it. This check and balance is performed until there is sufficient memory, in which case we may hydrate the process. On the other hand, if the cache capacity is exceeded, then we process the message based on its exchange pattern, as described below: i) If the message is one-way (asynchronous), then we queue it back with the job scheduler so that it can be retried later. The hope is that, given a sufficient amount of delay and number of retries, the cache will have enough room for the targeted process. ii) If the message is two-way (synchronous), then we cannot simply re-schedule it back, because the client will no doubt timeout. The logical thing to do here is to just return a SOAP fault message that forces the client to handle retries itself, if it so desires. Furthermore, the administrator may use the following properties to enable and control lazy-loading: c) process.hydration.lazy: The value of this property specifies whether or not a process metadata is to be lazy-loaded. If so, then the server will not immediately load process metadata upon startup or deployment. In fact, the process is not hydrated until the server receives a message that demands that that process be loaded in-memory. This is a global property that may be overriden on a process-by-process basis by specifying a value for its namesake in the process' deployment descriptor (deploy.xml) file. d) process.hydration.lazy.minimum.size: The value of this property specifies the approximate minimum size of the process metadata for which lazy-loading should be enabled. If the server calculates the approximate size of the process metadata (based on its serialized file size) to be less than the value specified herein, then it will load the process eagerly. This way, you don't suffer the time delay on hydration for messages that don't deal with large-sized processes. Lastly, we introduce the following property to throttle the number of instances that a process may handle: e) process.instance.throttled.maximum.count: The value of this property specifies the maximum number of instances that may be simultaneously active for any given process. This is a global property that may be overriden on a process-by-process basis by specifying a value for its namesake in the process' deployment descriptor
[jira] Commented: (ODE-557) NPE in Job.equals() when doing process-to-process invocations
[ https://issues.apache.org/jira/browse/ODE-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12683512#action_12683512 ] Alex Boisvert commented on ODE-557: --- There's a good chance the issues are related but the fixes are different. (I didn't notice ODE-422 before... but my preference would be to prevent the creation of Jobs with a null id to catch errors early (fail-fast) instead of silently ignoring an invalid state. NPE in Job.equals() when doing process-to-process invocations - Key: ODE-557 URL: https://issues.apache.org/jira/browse/ODE-557 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3, 1.3.1 Reporter: Alex Boisvert When executing process-to-process invocation, the following may occur: 09:41:41,873 ERROR [org.apache.ode.scheduler.simple.SimpleScheduler] [ODEServer-16] Error while executing transaction org.apache.ode.bpel.iapi.Scheduler$JobProcessorException: java.lang.RuntimeException: java.lang.NullPointerException at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:425) at org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:377) at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:390) at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:384) at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:208) at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:383) at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:380) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.RuntimeException: java.lang.NullPointerException at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:464) at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139) at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:844) at org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:414) at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:415) ... 11 more Caused by: java.lang.NullPointerException at org.apache.ode.scheduler.simple.Job.equals(Job.java:55) at java.util.PriorityQueue.indexOf(PriorityQueue.java:287) at java.util.PriorityQueue.remove(PriorityQueue.java:305) at java.util.concurrent.PriorityBlockingQueue.remove(PriorityBlockingQueue.java:313) at org.apache.ode.scheduler.simple.SchedulerThread.dequeue(SchedulerThread.java:123) at org.apache.ode.scheduler.simple.SimpleScheduler.cancelJob(SimpleScheduler.java:175) at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.releasePartnerMex(BpelRuntimeContextImpl.java:1241) at org.apache.ode.bpel.runtime.INVOKE$2.onResponse(INVOKE.java:168) at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451) ... 15 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-557) NPE in Job.equals() when doing process-to-process invocations
[ https://issues.apache.org/jira/browse/ODE-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert resolved ODE-557. --- Resolution: Fixed Fixed in 1.x branch, boisv...@sixtine:~/svn/ode/1.1$ svn commit -m ODE-557: NPE in Job.equals() when doing process-to-process invocations bpel-runtime/src/main/java/org/apache/ode/bpel/engine/BpelRuntimeContextImpl.java Sending bpel-runtime/src/main/java/org/apache/ode/bpel/engine/BpelRuntimeContextImpl.java Transmitting file data . Committed revision 755800. NPE in Job.equals() when doing process-to-process invocations - Key: ODE-557 URL: https://issues.apache.org/jira/browse/ODE-557 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3, 1.3.1 Reporter: Alex Boisvert When executing process-to-process invocation, the following may occur: 09:41:41,873 ERROR [org.apache.ode.scheduler.simple.SimpleScheduler] [ODEServer-16] Error while executing transaction org.apache.ode.bpel.iapi.Scheduler$JobProcessorException: java.lang.RuntimeException: java.lang.NullPointerException at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:425) at org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:377) at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:390) at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:384) at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:208) at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:383) at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:380) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.RuntimeException: java.lang.NullPointerException at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:464) at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139) at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:844) at org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:414) at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:415) ... 11 more Caused by: java.lang.NullPointerException at org.apache.ode.scheduler.simple.Job.equals(Job.java:55) at java.util.PriorityQueue.indexOf(PriorityQueue.java:287) at java.util.PriorityQueue.remove(PriorityQueue.java:305) at java.util.concurrent.PriorityBlockingQueue.remove(PriorityBlockingQueue.java:313) at org.apache.ode.scheduler.simple.SchedulerThread.dequeue(SchedulerThread.java:123) at org.apache.ode.scheduler.simple.SimpleScheduler.cancelJob(SimpleScheduler.java:175) at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.releasePartnerMex(BpelRuntimeContextImpl.java:1241) at org.apache.ode.bpel.runtime.INVOKE$2.onResponse(INVOKE.java:168) at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451) ... 15 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-557) NPE in Job.equals() when doing process-to-process invocations
[ https://issues.apache.org/jira/browse/ODE-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12683256#action_12683256 ] Alex Boisvert commented on ODE-557: --- Also fixed in trunk, boisv...@sixtine:~/svn/ode/trunk/engine$ svn commit -m ODE-557: NPE in Job.equals() when doing process-to-process invocations . Sendingengine/src/main/java/org/apache/ode/bpel/engine/ODEProcess.java Transmitting file data . Committed revision 755801. NPE in Job.equals() when doing process-to-process invocations - Key: ODE-557 URL: https://issues.apache.org/jira/browse/ODE-557 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3, 1.3.1 Reporter: Alex Boisvert When executing process-to-process invocation, the following may occur: 09:41:41,873 ERROR [org.apache.ode.scheduler.simple.SimpleScheduler] [ODEServer-16] Error while executing transaction org.apache.ode.bpel.iapi.Scheduler$JobProcessorException: java.lang.RuntimeException: java.lang.NullPointerException at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:425) at org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:377) at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:390) at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:384) at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:208) at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:383) at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:380) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.RuntimeException: java.lang.NullPointerException at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:464) at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139) at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:844) at org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:414) at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:415) ... 11 more Caused by: java.lang.NullPointerException at org.apache.ode.scheduler.simple.Job.equals(Job.java:55) at java.util.PriorityQueue.indexOf(PriorityQueue.java:287) at java.util.PriorityQueue.remove(PriorityQueue.java:305) at java.util.concurrent.PriorityBlockingQueue.remove(PriorityBlockingQueue.java:313) at org.apache.ode.scheduler.simple.SchedulerThread.dequeue(SchedulerThread.java:123) at org.apache.ode.scheduler.simple.SimpleScheduler.cancelJob(SimpleScheduler.java:175) at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.releasePartnerMex(BpelRuntimeContextImpl.java:1241) at org.apache.ode.bpel.runtime.INVOKE$2.onResponse(INVOKE.java:168) at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451) ... 15 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-557) NPE in Job.equals() when doing process-to-process invocations
[ https://issues.apache.org/jira/browse/ODE-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12683323#action_12683323 ] Alex Boisvert commented on ODE-557: --- Yes, because there is no InvokeCheck job created for process-to-process communication; it is assumed to be reliable. I'm not sure why we didn't catch this earlier, but I suspect we didn't test the specific combination of process-to-process, request-response mex, and persistent processes. NPE in Job.equals() when doing process-to-process invocations - Key: ODE-557 URL: https://issues.apache.org/jira/browse/ODE-557 Project: ODE Issue Type: Bug Components: BPEL Runtime Affects Versions: 1.3, 1.3.1 Reporter: Alex Boisvert When executing process-to-process invocation, the following may occur: 09:41:41,873 ERROR [org.apache.ode.scheduler.simple.SimpleScheduler] [ODEServer-16] Error while executing transaction org.apache.ode.bpel.iapi.Scheduler$JobProcessorException: java.lang.RuntimeException: java.lang.NullPointerException at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:425) at org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:377) at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:390) at org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:384) at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:208) at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:383) at org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:380) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.RuntimeException: java.lang.NullPointerException at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:464) at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139) at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:844) at org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:414) at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:415) ... 11 more Caused by: java.lang.NullPointerException at org.apache.ode.scheduler.simple.Job.equals(Job.java:55) at java.util.PriorityQueue.indexOf(PriorityQueue.java:287) at java.util.PriorityQueue.remove(PriorityQueue.java:305) at java.util.concurrent.PriorityBlockingQueue.remove(PriorityBlockingQueue.java:313) at org.apache.ode.scheduler.simple.SchedulerThread.dequeue(SchedulerThread.java:123) at org.apache.ode.scheduler.simple.SimpleScheduler.cancelJob(SimpleScheduler.java:175) at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.releasePartnerMex(BpelRuntimeContextImpl.java:1241) at org.apache.ode.bpel.runtime.INVOKE$2.onResponse(INVOKE.java:168) at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451) ... 15 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-553) Reference to external axis web services
[ https://issues.apache.org/jira/browse/ODE-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Boisvert resolved ODE-553. --- Resolution: Invalid Reference to external axis web services --- Key: ODE-553 URL: https://issues.apache.org/jira/browse/ODE-553 Project: ODE Issue Type: Task Components: Axis2 Integration Environment: Windows Visa Reporter: Nawaz Khurshid I have a BPEL process which invokes two partner links provided by external axis web services. Can you please tell me how can I put these external webservices [Deployed WSDL references] in deploy.xml. The namespace as shown below are vtaW [targetnamespace of WSDL file locally present in the project] vtaP [targnet namespace of BPEL file locally present in the project] flightW [tareget namespace of service located on external server] hotelW[tareget namespace of service located on external server] ?xml version=1.0 encoding=UTF-8? deploy xmlns=http://ode.fivesight.com/schemas/2006/06/27/dd; xmlns:vtaP=http://test.org/BusinessProcesses/VTA; xmlns:vtaW=http://test.org/BusinessProcesses/VTA; xmlns:flightW=http://test.org/BusinessProcesses/Flight; xmlns:hotelW=http://test.org/BusinessProcesses/Hotel; !-- VTA PROCESS -- process name=vtaP:VTA activetrue/active provide partnerLink=VTA_PLT service name=vtaW:User_VTAService port=VTA_PLTServicePort / /provide provide partnerLink=Flight_PLT service name=flightW:FlightService port=FlightServicePort / /provide provide partnerLink=Hotel_PLT service name=hotelW:HotelService port=HotelServicePort / /provide invoke partnerLink=VTA_PLT service name=vtaW:VTAService port=VTAServicePort / /invoke invoke partnerLink=Flight_PLT service name=flightW:VTA_FlightService port=VTA_FlightServicePort / /invoke invoke partnerLink=Hotel_PLT service name=hotelW:VTA_HotelService port=VTA_HotelServicePort / /invoke /process /deploy Please guide how can i add or import the references to hotelW and fligthW external axis services within this deploy.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
