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

[jBPM Development] - Feature proposal: Availability and Reliability Overlay

by alaiksei.yanchuk

Hi Community, I would like to contribute a workflow execution mechanism intended for applications having availability and / or reliability requirements. The mechanism is intended to be complimentary to existing jBPM code base. For further details please refer to the white paper available at http://sites.google.com/site/jbpmhq/links-library/articles-and-papers/ava.... I'd be delighted to hear your opinion, questions and comments. With kindest regards, Aliaksei Yanchuk View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262523#4262523 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262523

16 years, 2 months

1
0
0 / 0

[Tomcat Integration Development] - Re: jbossweb-tomcat.sar upgrade to Tomcat 5.5.28

by jriesenberg

Jean-Frederic, Thank you for the link to the Tomcat patch repository however I did not see the exact version that I was looking for. I am using JBoss 4.0.5GA which shipped with JBoss Tomcat 5.5.20 and my customer is requiring me to upgrade Tomcat to 5.5.28. Can you provide me the instructions to replace the bundled JBoss Tomcat 5.5.20 with the new Tomcat release 5.5.28? Thanks. John View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262494#4262494 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262494

16 years, 2 months

1
0
0 / 0

[Embedded JBoss Development] - Re: Embedded and Bootstrap Development

by ALRubinger

Cool. The reason for the Maven lockdown is because there were dependency resolution differences between 2.0.8 and 2.0.9, and I haven't yet had a chance to certify anything greater worked reliably. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262488#4262488 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262488

16 years, 2 months

1
0
0 / 0

[Embedded JBoss Development] - Re: Embedded and Bootstrap Development

by manuel.chinea

Hi ALR: I was able to download and compile the code. I had some trouble with the maven version requisite (i had installed 2.2.1, but in the project there is this [2.0.9,2.1) maven version requirement. Changed the range to [2.0.9,2.2.1] and worked fine). I also ran the tests succesfully. I haven't looked the code in detail, though. I'll be checking the code and issue tracker soon. Any advice will be helpful. Thnxs. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262484#4262484 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262484

16 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by alesj

Just a simple note. Currently we have a failing Deployers test, due to ongoing Classpool work / fixes. | public void testHierarchyCLUsage() throws Exception | { | AssembledDirectory directory = createBasicEar(); | DeploymentUnit unit = assertDeploy(directory); | try | { | TypeInfoFactory typeInfoFactory = new JavassistTypeInfoFactory(); | DeploymentUnit child = getDeploymentUnit(unit, "simple.war"); | ClassLoader cl = getClassLoader(child); | TypeInfo ti = typeInfoFactory.getTypeInfo(AnyServlet.class.getName(), cl); | ClassInfo ci = assertInstanceOf(ti, ClassInfo.class); | MethodInfo mi = ci.getDeclaredMethod("getBean"); | assertNotNull("No such 'getBean' method on " + ci, mi); | TypeInfo rt = mi.getReturnType(); | TypeInfo cti = typeInfoFactory.getTypeInfo(PlainJavaBean.class.getName(), getClassLoader(unit)); | assertSame(rt, cti); // current failure! | } | finally | { | undeploy(unit); | } | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262474#4262474 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262474

16 years, 2 months

1
0
0 / 0

[JBoss Messaging Development] - OpenOffice widgets for HornetQ component

by jmesnil

fyi, I have added to the trunk an OpenOffice document with drawings representing HornetQ components (in doc/diagrams/widgets.odg) There are drawings for: * server * acceptor * connector * address * queue * core bridge * jms bridge * divert * journal The idea is to use common images across our doc/example/blog. As I rewrite the HA chapter, I'm using these widgets to draw the different HA mode (shared store vs replicated store) and configuration setting (live-backup pair) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262462#4262462 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262462

16 years, 2 months

1
0
0 / 0

[JBoss ESB Development] - Dynamic Routing by code via HttpRouter without ConfigTree po

by h.wolffenbuttel

Hi, The JBoss ESB has various routing possibilities, but no dynamicaly configurated HTTPRouter (as far as I know). I need contentbased message routing without having to declare each and every http-endpoint in the jboss-esb.xml. There are two options I see here without any ESB changes: - Rewrite HttpRouter class and others to accept Properties instead of a ConfigTree. - Rewrite ConfigTree class making it possible to programmaticaly add nodes - Instantiate the HttpRouter with a hard coded xmlstring (See code example) | public Message sendAnswer(Message message) throws ActionProcessingException{ | String responseUrl = (String)message.getBody().get("ResponseUrl"); | String responseOperation = (String)message.getBody().get("ResponseOperation"); | String responseSoapAction = (String)message.getBody().get("ResponseSoapAction"); | String xml = | "<action class=\"nl.gouwit.esb.actions.HttpDynamicRouter\" name=\"SendAnswerAction\" endpointUrl=\"" + responseUrl + "\"" | + " method=\"POST\" responseType=\"STRING\"\">" | + "<header name=\"SOAPAction\" value=\""+responseSoapAction+"\"/>" | + "<header name=\"operation\" value=\""+responseOperation +"\"/>" | + "</action>"; | try { | ConfigTree config = ConfigTree.fromXml(xml); | HttpRouter router = new HttpRouter(config ); | router.process(message); | } | catch (ConfigurationException e) { | throw new ActionProcessingException(e); | } | catch (SAXException e) { | throw new ActionProcessingException(e); | } | return message; | } | This code works, but I prefer have a solution where I do not need to create a config by converting XML. I also don't prefer to write my own httprouter because I want to use the ESB functionality as much as possible. Also I don't want to miss out on any newly added functionality to the ESB. Regards, Hans View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262428#4262428 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262428

16 years, 2 months

1
0
0 / 0

[jBPM Development] - Re: feature suggestion: add a description for transitions

by camunda

It may be clear for you, and even for people reading the docs... So for the others (the most people ;-)) it may get confusing, especially if the UI switches what it shows... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262414#4262414 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262414

16 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Deployers Ordering Issue Reopened

by richard.opalka＠jboss.com

"alesj" wrote : We've been down this road before, only to find out you had one valid argument. | And that was implemented as part of domino ordering. | | Wrt P1), we've already discussed that, and my decision still stands. | Doing across stages checks is nothing more to me than supporting | someone else's laziness by not taking the time to do proper check or testing before. | We (i.e. JBossWS) don't need cross deployers stages to be taken into account. I've been just wondering universal solution that would work for all the usecases. IOW I've been thinking about your code trying to help you to make it generic and covering not just trivial usecases. "alesj" wrote : | As for P2) why would you even need to compare two deployers? | CompareTo code really comes in use when you as a user | actually get a hold of two instances and try to compare them. | Users/devs should never have to explicitly compare two deployers. | Just FYI we don't compare deployers. It's deployers impl job. The above compareTo was just an abstraction of your DominoOrdering.init() method (the abstration you're executing in every cycle). Again I was talking about your code ;) "alesj" wrote : | Wrt "suggestions". You came up with a clear case of cycle dependency, proposed some fuzzy logic solution, | put "bugs" label on existing code and you now expect us to drop everything to support your claims? | Why is our usecase so special? We're expecting/providing e.g. JBossWebMetadata in both inputs/outputs because we're reading web MD and modifying MD. There's nothing wrong with it. It's exactly deployer inputs/outputs are intended for, don't they? "alesj" wrote : | The reality is that apart from you we haven't had any deployers ordering issues. | And? Does it mean deployers ordering is correct? This is strange implication:( "alesj" wrote : | I do give you credit for previous example and suggestion for a fix, | but in this case, not only you're repeating yourself, I think you're just plain wrong. | Thanks for the credits. We've been using the workaroud suggestion already for months. We know about relative order workaround and we don't like it. We'd rather to see it fixed in deployers impl code where it should be fixed. Why we should do workarounds in our code if we're regularly using deployers and doing nothing special with them? If you don't wanna fix this issue, just mark JBDEPLOY-201 as WON'T FIX and I won't waste my free time trying to help you. For me deployers are "key abstraction" of AS and the fact is its input/output based ordering doesn't work for non trivial usecases. PS: If you can live with it then you're lucky man. My problem is I'm perfectionist and thus I don't like partial solutions :( View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262411#4262411 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262411

16 years, 2 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Extender Patter vs. LifecycleInterceptors

by alesj

"thomas.diesler(a)jboss.com" wrote : | In case of of the MC Framework the interceptor attachment API delegates to the DeploymentUnit, so that interceptor attachments are visible by the deployers and vice versa. So this means you have those two adapters we talked about? * OSGi interceptors --> VDF deployers * VDF deployers --> OSGi interceptors And one can easily (to some extent) port/exchange the two? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262396#4262396 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262396

16 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2009