February 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: email templates

by kukeltje

It already works.... at least outside jBPM with the default JBoss EL. So the next step is to integrate it with the jBPM resolver. Ofcourse the code needs some cleaning up, at least one unittest (:-P) (there only is one method). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209651#4209651 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209651

15 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - JBossESB 4.5 GA is out

by Kevin.Conner＠jboss.com

The team are delighted to announce the availability of the latest release of the JBossESB project, 4.5 GA. It is now available from our project download page (http://www.jboss.org/jbossesb/downloads). This release rolls up many changes made during the productisation of the JBossESB 4.4 GA release, as well as new features. Please download the release and let us know what you think. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209649#4209649 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209649

15 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB3 enterprise module?

by camunda

Hi Alex. The hack couldn't be easily ported. And since the EJB Timer implementation in JBoss is quite limited to handle huge amounts of timers we now decided against it. So we are back to the JobExecutor, even if we extended it so execute the jobs via SLSB. Using the JobExecutor also means removing JMS from the game for async stuff, so everything remaining was the EJB3 SLSB :-/ So maybe it makes more sence to really move these stuff to jbpm 4 and create a working solution there. It is a bit a mess with the enterprise stuff not used in esb vs. JobExecutor scaling better than the enterprise stuff :-/ Cheers Bernd View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209632#4209632 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209632

15 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: email templates

by tom.baeyens＠jboss.com

keep me posted on your progress. i'm all ears. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209631#4209631 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209631

15 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB3 enterprise module?

by alex.guizar＠jboss.com

anonymous wrote : Damn, it seems that linking a Timer to an EJB3 Entity seems not to be possible like in EJB 2.1 (regarding https://jira.jboss.org/jira/browse/JBPM-886 ). In the current implementation the Timer POJO is flushed and loaded as an EJB2 entity bean. It works but looks and feels dirty. If the hack is not easily portable to EJB3 then we should just use two different tables. It does not make sense to sacrifice cleanliness just to save one table. Another thought: the EJB3 stuff should not go into jBPM3, it would mostly bring further maintenance burdens and would certainly not be accepted for inclusion into SOA-P. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209628#4209628 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209628

15 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by kabir.khan＠jboss.com

https://jira.jboss.org/jira/browse/JBAOP-704 for the AOP "resiliance" stuff I mentioned View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209625#4209625 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209625

15 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: email templates

by kukeltje

ok... bootstrapping works for 80% already... not realy that difficult with the seam mock, a small example from ICEFaces and some things from RichFaces.... Last thing to do seems to be getting the right EL resolvers in place... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209620#4209620 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209620

15 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by richard.opalka＠jboss.com

Follow up: JBAS-6496 for AS 5.0.1.GA JBAS-6497 for AS 5.1.0.Beta1 and AS 6.0.0.Alpha1 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209615#4209615 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209615

15 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: [JBMESSAGING-1367] Create JCA resource adapter for JBM 2

by jesper.pedersen

anonymous wrote : | 1) Did you make the change to enlist the session in the JTA tx *before* the message was received by the JBM session? | The enlistment is done in ra.inflow.JBMMessageHandler::setup() right before the handler is registered as a listener. anonymous wrote : | 2) I'm assuming you have some generic JCA tests for the JMS resource adapter? If so, could you copy them across to JBM? Or point me in the right direction so I can do so... | There are tests in the AS testsuite - but they require a JCA container and also an EJB container (testsuite/src/main/org/jboss/test/jmsra/). In order to do testing in the JBM project we need at least a standalone JCA container - which havn't been released yet - project is JBJCA. Once we have a release of that we can integrate test cases into JBM. For now we have to depend on the AS testsuite... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209612#4209612 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209612

15 years, 9 months

1
0
0 / 0

[Design of JBoss Identity] - Re: typed interface of identity api

by bdaw

"tom.baeyens(a)jboss.com" wrote : "bdaw" wrote : Maybe it would make sense to let use those information in API more directly? Something like: | | - associateGroups(GroupType parentType, String, parentName, GroupType childType, String childName) | | | | exactly. the default case should be a one-to-one mapping between the api-ID and the phisical identityStore-ID. | Here you mean the same like it is now? Not sure if I understand this part correctly "tom.baeyens(a)jboss.com" wrote : | only if the user wants to bind to some exotic identity store, then a mapping between the API-ID strings and the identity store IDs might be necessary. the API/SPI architecture would still allow that. | Open question is how to put changes into the API. So for egz. Approach A) We make methods duplicates like the one I described above whenever possible to use type/name information. One problem here is that for methods like: | void associateIdentities(Collection<Group> parents, Collection<Identity> members) | it's hard to find handy alternative :) Approach B) We have Identity.getId() and Group.getId() but the actual content of the returned String is some encoded value like [typeName];[name];[store_internal_id]. Last part could be optional Then we can utilize String like ID more in methods but main problem is that format can't be final - it shouldn't be allowed to assemble such id manually. It would require some dedicated method. Format can utilize something like basic xml to encode information. Then minimal required ID content would be name/type pair. Other info like realm id, repository id, store id and true object id inside the store is optional and applied by the SPI. Would it make sense? Something like | String PersistenceManager.getIdentityId(String name); | String PersistenceManager.getGroupId(String name, String type); | Then we make another version of methods with String ids like: | void associateGroupsAndIdentities(Collection<String> parentGroupIDs, Collection<String> memberIdentityIDs) | How does it look like? Obviously we could have both A) and B) concept. The main limitation here is to not triple number of methods.... "tom.baeyens(a)jboss.com" wrote : | i would even make the groupTypes plain strings in the api. | Indeed. In current shape both GroupType and RoleType could be changed into plain String . Other similar one is CredentialType but because of how Credential is implemented it can be left like this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209611#4209611 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209611

15 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009