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

[Design of Kosmos] - Re: SvnMonitoringPortlet

by lamerbot

Can anybody help me? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979665#3979665 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979665

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: extending form / task functionality

by andyredhead

"david.lloyd(a)jboss.com" wrote : | I disagree. People who don't want the added features, won't use them. And I think the general expectation is that people will use the GPD for building jpdl processes, so they probably won't see the XML at all anyway. Designing an XML document to be human-readable is, at best, an exercise in futility. | At the moment I use the visual diagram part of the GPD to draw the flows and then either the xml source view in the GPD or the eclipse xml editor direct to add actions to events in jBPM. Some events have multiple actions and the order in which the actions are fired can be important... So I have to deal with the xml direct - or is there a better way? ;) Another way of putting my point forward is to say that jBPM cannot solve all problems for all applications, so instead it should do its bit well. If there are problems with the way some other part of an application calls it, it should be the responsibility of the other part of the application to deal with it - not jBPM. Would it not be better to move core parts of jBPM forward (such as the use of JMS for asynch processing or maybe using the ejb timer service for scheduled things within a process) rather than "fiddling around" with non-core things? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979660#3979660 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979660

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How to store EPRs in the registry?

by mark.little＠jboss.com

I think that all makes perfect sense. A good way to start. Once we get deployments in the real world, we'll get feedback soon enough. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979658#3979658 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979658

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How to store EPRs in the registry?

by kurt.stam＠jboss.com

Actually I was thinking the findServiceBinding could be Collection findEPRs(Service service) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979656#3979656 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979656

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How to store EPRs in the registry?

by kurt.stam＠jboss.com

I think that when we agree on the structures, we can hide it all from the users. In fact we can probably define that right now. I think it will probably be something like this: | Class EPRRegistry { | | publish(String serviceName. EPR epr) | | Collection<Services> findServices(); | Collection<Services> findServices(String serviceType); | Collection<ServiceBindings> findServiceBindings(Service service); | ... more finders | | I'm assuming we will publish all Services under the same "JBossESB Organization". So we could hardcode that (or not..) We'll see, but this is what I was thinking of. I do think the user will usually get a collection of Services back, so he or she will have to decide which one to use, and then for that Service there may be multiple Bindings (each continaing an EPR), so again the user will have to figure out which one to use. Does that make sense? Or do you see clear rules on how to narrow down the results? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979654#3979654 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979654

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: extending form / task functionality

by david.lloyd＠jboss.com

"andyredhead" wrote : At the moment, the process definition xml contains infomation about the process. | | The more different kinds of things you put into that file, the harder it becomes to understand that file and the more likely you are to put people off from ever using jBPM. I disagree. People who don't want the added features, won't use them. And I think the general expectation is that people will use the GPD for building jpdl processes, so they probably won't see the XML at all anyway. Designing an XML document to be human-readable is, at best, an exercise in futility. However, I agree that adding information pertaining to one specific GUI implementation type is probably not appropriate. Perhaps a better approach is to have an attribute that holds a generic XML block as presentation information, and leave it up to the GUI implementation to interpret the block. For the forms designer, this block could be facelets-style xhtml, or some other XML schema with xhtml inside of it. As long as the XML namespaces are properly provided, pretty much anything is possible. Or maybe that's getting too complicated and we should just have a separate file. And again, if you don't want the GUI information, just don't provide it, and you won't have to look at it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979653#3979653 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979653

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: POJOization of config elements

by manik.surtani＠jboss.com

anonymous wrote : | We still want to support creation of a config using the old 1.x format and XmlConfigurationParser, don't we? Otherwise we require use of the MC and a -beans.xml file, even outside the AS. The XmlConfigurationParser approach can't handle arbitrary sets of XML elements (at least not without a lot of work), hence the use of Properties as a workaround. | | Even if we decide to require use of the MC in 2.0.0.GA, leaving in Properties support for now makes it easier to transition. We can strip it out later (e.g. after alpha). | Good point, +1. The rest sounds good, I'm for it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979649#3979649 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979649

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How to store EPRs in the registry?

by mark.little＠jboss.com

Sounds good. How much of this will be hidden from users (services when they publish and clients when they search and use) and how much of it will they need to know? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979648#3979648 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979648

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How to store EPRs in the registry?

by kurt.stam＠jboss.com

I'm working on the RegsitryUnitTest as an example on how to store and retreive one of our EPRs. I'm playing with how to classify and categorise them so that we have maximum flexibily and search capability. That work shouldn't really go much beyond today, which makes us ready for integration next week, or whenever we merge in the latest architectural changes into the trunk. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979647#3979647 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979647

19 years, 5 months

1
0
0 / 0

[Design of JBoss Reporting] - Re: run jasper report from JBoss

by noel.rocher＠jboss.com

Take a look at http://labs.jboss.com/reportingservices A snapshot should be available soon. --noel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979646#3979646 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979646

19 years, 5 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 October 2006