June 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: Refactoring access to JBPM database

by rjoachim

You are right, but that target does not fit to my requirements and I therefore will not spend time to work on it. On the other hand would my target have made it much easier for someone else to add support for a JPA persistence layer. As it seamed to me that I wouldn't get the required support from the JBPM team to succeed with my task I changed my mind and moved on to other targets. What I can offer is to share 2 small patches of the refactoring that I have finished until now. Having said that still all tests execute without failures that have not been broken by other commits from end of last week. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055044#4055044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055044

19 years

1
0
0 / 0

[Design of JBoss jBPM] - dataflow integration

by msandoz

i'm working on a custom extension to the editor to support dataflow and more custom nodes. my first thought for a direction is to create a new semantic element for a dataflow node which i would then extend with custom nodes and provide custom editors - as property tabs. Concerning mapping: is this the right way to go? i also considered adding mapping support through an extra mapping element for the existing node class and then extending that with the custom node classes. the mapping extension would provide a mechanism for mapping the handler variables to inputs and outputs which would be configurable through a simple property editor. Concerning custom editors: i think it would be nice to be able to construct custom handler editors by creating a mapping from the handler class to the editor class and then simply bringing up the appropriate editor in a property tab. to help differentiate the various custom nodes in the designer it would also be nice to have the mapping provide an icon and to have a palette entry for it. is this a reasonable direction? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055036#4055036 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055036

19 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Refactoring access to JBPM database

by kukeltje

Tom said nothing about not wanting a plugable architecture... What he said was the making jBPM use JPA would make it pluggable with regard to the JPA implementation (hibernate or whatever) Correct me if I'm wrong View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055004#4055004 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055004

19 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Thinking about transition attrs

by kukeltje

Yep, good suggestion. In some cases I do not see the 'added value' of storing it in the db, but it could be implemented that way (not before 3.3, since it requires db changes) We *could* implement it *now* with access to the xml file and change the implementation later on. one question though... the jpldElementId is the internal id of a mapped xml element from the pd? What method would you suggest? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055002#4055002 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055002

19 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Invalid JORAM Test

by clebert.suconic＠jboss.com

"timfox" wrote : "clebert.suconic(a)jboss.com" wrote : | | | | I don't know if this is legal on JORAM, but it is certainly not legal on JBossMessaging. You are required to clear the previous receiver before assign a new one on the same queue, because of that I will be changing the JORAM test accordingly. (Unless anyone has anything against the change) | | Clebert | | Actually, it's perfectly legal to create more than one receiver on the same queue. | | It's just that it's not specified in the JMS spec which receiver would get the message. | | In the case of JBM they would be round-robined. | | However, if the test is expecting the the latest receiver to get the message, then I accept the test is probably flawed. Yep.. that's what I meant... but I think it's odd the test was passing on JORAM (originally written to) and JBossMQ. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054968#4054968 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054968

19 years

1
0
0 / 0

[Design of JBossCache] - Re: Need to make enhacements to CacheListener API

by vincent.marquez

Just my two cents, I see nothing wrong with the current API, maybe adding a AbstractPojoCacheListener to make life a little more convenient. I do think CachedFieldInterceptor needs to be removed before the data is actually taken out of the cache, and not in a seperate thread if that is being considered. As it stands now, after a pojo is detached from a remote cache instance, it still tries to retrieve values from the cache, so you get a null value. I threw a quick unit test up under http://jira.jboss.com/jira/browse/JBCACHE-713 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054928#4054928 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054928

19 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Invalid JORAM Test

by timfox

"clebert.suconic(a)jboss.com" wrote : | | I don't know if this is legal on JORAM, but it is certainly not legal on JBossMessaging. You are required to clear the previous receiver before assign a new one on the same queue, because of that I will be changing the JORAM test accordingly. (Unless anyone has anything against the change) | Clebert Actually, it's perfectly legal to create more than one receiver on the same queue. It's just that it's not specified in the JMS spec which receiver would get the message. In the case of JBM they would be round-robined. However, if the test is expecting the the latest receiver to get the message, then I accept the test is probably flawed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054901#4054901 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054901

19 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Invalid JORAM Test

by clebert.suconic＠jboss.com

The test I'm changing is org.objectweb.jtests.jms.conform.connection.ConnectionTest::testAcknowledge at our CVS repository. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054893#4054893 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054893

19 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Invalid JORAM Test

by clebert.suconic＠jboss.com

On the integration testsuite from JBossAS (trunk) which I'm moving to Branch_4_x, there is one invalid JORAM Test, which is doing something like this: | | public void testStopStartConnection() throws Exception | { | Queue queue = (Queue)ic.lookup("/queue/TestQueue"); | Queue receiverQueue = (Queue)ic.lookup("/queue/TestQueue"); | | QueueConnectionFactory qcf = (QueueConnectionFactory)cf; | | QueueConnection connProducer = qcf.createQueueConnection(); | QueueSession senderSession = connProducer.createQueueSession(false, Session.CLIENT_ACKNOWLEDGE); | QueueSender sender = senderSession.createSender(queue); | | QueueConnection receiverConnection = qcf.createQueueConnection(); | QueueSession receiverSession = receiverConnection.createQueueSession(false, Session.CLIENT_ACKNOWLEDGE); | QueueReceiver receiver = receiverSession.createReceiver(receiverQueue); | | connProducer.start(); | receiverConnection.start(); | | | receiverConnection.stop(); | receiverSession = receiverConnection.createQueueSession(false, Session.CLIENT_ACKNOWLEDGE); | // receiver.close(); /// This would fix the test | receiver = receiverSession.createReceiver(receiverQueue); | receiverConnection.start(); | | | Message message = senderSession.createMessage(); | sender.send(message); | | Message m = receiver.receive(30000); | | | m.acknowledge(); | } | | (The above is a simplification of what was happening on the JORAM test.. since it was playing with setup, and opening the receivers again on the test itself) The test creates a receiver... and later creates the receiver again without closing the previous one. I don't know if this is legal on JORAM, but it is certainly not legal on JBossMessaging. You are required to clear the previous receiver before assign a new one on the same queue, because of that I will be changing the JORAM test accordingly. (Unless anyone has anything against the change) Clebert View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054892#4054892 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054892

19 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Exposing JBossWS Webservice Endpoints...

by tfennelly

Ups, hit send by accident. Anyway... One thing you might notice about the configuration is that it supports regular expressions in the class, method and field names. This means you can write more generalised configurations e.g. introducing a namespace @XmlElement annotation on all getter methods (or fields) from all classes in a particular package. Here's the XSD for the config. The webservice_bpel quickstart is a good example of where this is in use. BTW: I've posted a request for other alternatives to this approach on the JAXB forums, but haven't received any feedback as yet. I'm off to enjoy a week off now :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054880#4054880 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054880

19 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2007