July 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Web Services] - Re: JBossWS productization

by thomas.diesler＠jboss.com

Yes, we should see the above more like guide lines that help us to achieve predictability. We don't want strict rules that do not allow exceptions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960382#3960382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960382

19 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: 2.6 Usability Enhancements

by roy.russo＠jboss.com

So where are the new ones? I copied all the old ones to my local box, so feel free and lock them down. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960381#3960381 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960381

19 years, 8 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS productization

by darran.lofthouse＠jboss.com

I think this sounds good, if we can demonstrate that we release on the day we say we will release users can be confident when the fix they require will be available. We can also prioritise the tasks so that the scheduled items are based on the current demand. In general I think defining what is going to be in the release early is good so people can see what is going to be included but I don't think it should completely prevent additional tasks being added in weeks 3 to 6. Items should only be added in weeks 3 to 6 on the condition that they will not impact any other scheduled tasks and it can be comfortably be delivered by the end of week 6 if these two can not be guaranteed then they need to go into the next release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960371#3960371 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960371

19 years, 8 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS productization

by thomas.diesler＠jboss.com

The above is just a suggestion of how we could handle a more predicatable process. Other suggestions are of course welcome. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960361#3960361 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960361

19 years, 8 months

1
0
0 / 0

[Design of JBoss Web Services] - JBossWS productization

by thomas.diesler＠jboss.com

Folks, currently we have commited ourselves to a release cycle of eight weeks per minor release in jbossws . I'd like to improving the predictability of jbossws releases, therefore I suggest we follow the following rules: | --------------------------------- | W1 | W2 Define set of JIRA issues | ---------------------------------- | W3 | W4 | W5 | W6 Work on issues | ---------------------------------- | W7 | W8 QA, Docs, Packaging | ---------------------------------- | In other words, at the end of W2 there are no more JIRA issues added to a release. At the end of W6 there are no more code changes. Upcoming Relases --------------------- jbossws-1.0.3 => 31-Aug-2206 jbossws-1.0.4 => 31-Oct-2006 Heiko, will handle the following two releases. After that I think it be good if we rotate the responsibility. Cheers View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960356#3960356 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960356

19 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Content-based routing

by mark.little＠jboss.com

Dave, simple is good for a start and the requirements that you outlined are reasonable. I have a couple of questions on what you said. "ddunkin" wrote : In our inhouse system, we have many adapter components that plug into a core. These adapters may handle specific types of input documents (e.g. an Ariba OrderRequest document) or a range of documents. If you read the original requirements architecture document for JBossESB from March 2006, you'll notice that we have the concept of multiple buses. Each bus can be for a different requirement, e.g., SOAP/HTTP or JMS, lifecycle messages (start/stop a service etc.), or application content. So in our architecture, it would seem that the requirement you've just described could be modeled as a bus per type of document(s). Would that be a fair assessment? anonymous wrote : | Our system uses OAGIS, an XML "business language," as the common language for the system, so all messages are converted to OAGIS documents if they're not already in that format. | Sounds like a good candidate for one of the formats we could transform from/to once Tom gets up to speed. We currently don't have a default message format and I was wondering what the pros and cons are of OAGIS. Could you start a separate thread in the forum on that and just seed it with your impressions of using OAGIS? anonymous wrote : | Here's where the content-based routing comes in. The adapter components in our ESB are deployed with a set of routing rules. | How configurable is this? Is it static or can it be updated dynamically? anonymous wrote : These rules basically say "for a document matching this XPath expression, send the document to this location (an instance of an adapter component bound in the JNDI tree)." We use drools 2.1 and a simple custom DSL. | The dispatcher component within our ESB architecture has always been the place I've looked to add content-based routing. I think that's still the case, but would be interested in your feedback. anonymous wrote : | So for us, the requirement of content-based routing is pretty simple: be able to determine destination address of a message from an XPath expression. Does anyone else have examples of how they would like content-based routing to work? | Presumably it's not just addresses? I've seen examples of CBR where the routing algorithm is finer grained: for example address and payload ("operation"). I've also seen deployments that use stateful routing algorithms, e.g., "if the last interaction put us into state A, then route this msg here, otherwise route it here." There's an argument that stateful interactions should be dealt with at the higher level by a process flow component and I haven't had time to revisit this in enough depth. Certainly some transient stateful interactions may be better dealt with within the lower levels, e.g., fault tolerance. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960326#3960326 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960326

19 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JPDL Eclipse Graphical Editor - problem building.

by kukeltje

hmmm.... why do I need a command line ZIP tool as well? Doesn't ant all provide this??? (unzipping seems to work for the eclipse stuff ). So zip, ssh, and cvs are all needed on the commandline? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960316#3960316 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960316

19 years, 8 months

1
0
0 / 0

[Design of Kosmos] - Re: serviceResultUpdaterJob not traversing repository

by aron.gombas

This actually looks OK to me, this how the scheduler works: - the first time an item is queried, it gets delivered by the appropriate service and then put to the cache - when the scheduler invokes the job to update the content of the cache, only the items ALREADY in the cache will be reloaded In your case, for some reason, there is 0 item in the cache, that's why the update job is completed in 0 seconds. So, the question: how can be 0 items in your cache? What happens the first time when you display the appropriate SVN portlet? Can you see the repo processed and the result put to the cache? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960313#3960313 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960313

19 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JPDL Eclipse Graphical Editor - problem building.

by kukeltje

I downloaded and installed a command line CVS client, that IS needed (I thought the error was because of firewall issues). Besides that, the checkout.jbpm.repository is configured to have CVS commit rights. I think it should be changed to anoncvs. Otherwise a commandline SSH is also needed. One thing I observe again is the need to have a JAVA_HOME set for some tasks, when building from eclipse (3.2), which COULD point to a different JVM. Is this wanted behaviour? I think not. Another thing is that there is an unknown target all.doc in the userguid build.xml I Will set JAVA_HOME again and see what the result is View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960307#3960307 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960307

19 years, 8 months

1
0
0 / 0

[Nukes Development] - HotSeoTalk.com - SEO Forum Search Engine Optimization Rankin

by hotseotalk

SEO Forums Search Engine Optimization Techniques High Ranking on Google Yahoo MSN Search RSS Feed. Please visit our web site for more details at http://www.hotseotalk.com View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960298#3960298 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960298

19 years, 8 months

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 July 2006