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

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

"tfennelly" wrote : So that was some basic configuration. How about adding security etc? Yes, security has to be included. It needs to cover authentication, transport guarantees, security constraints and integrate into the security work done by Daniel. "tfennelly" wrote : 1. Add a strict config model inside the ESB config file whereby we only allow certain configurations and we manually map those appropriately to the web.xml going into the generated .war sub deployment. This allows us to remain in control of what we support and is the preferred method. "tfennelly" wrote : 2. We allow the user to specify a suplemental web.xml that gets merged into the generated web.xml. The user would define the "extra" configs as per the web.xml schema. We could allow them specify this inline in the esb config, or externally. We might want to restrict the config types we allow in this e.g. you can't define any servlet/filter configs etc?? This is likely to lead to problems unless the restrictions are so strict as to end up with the equivalent of the first suggestion. Adding explicit support, especially under our control, is much easier than disabling parts. "tfennelly" wrote : The existing http gateway also supports configuration of allowed http methods. Do we need to bring this along? Yes, we need to retain support for the following verbs, DELETE, HEAD, GET, POST and PUT. We also need to provide automatic support for OPTIONS so that someone can determine what capabilities are present. Only TRACE, as currently implemented, is not required. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238130#4238130 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238130

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Status / Documentation of gwt-console & report-server

by heiko.braun＠jboss.com

That's right, the docs are still missing. Some of the functionality is only available in particular situations, i.e: - depending on the process itself (i.e task forms) - the type & contents of process deployments (i.e. process image) - plugin functionality (forms) Before you go ahead a d discuss UI elements, it would make more sense to think about meaningful constraints, that can be applied to process deployments. Currently the console has to cope with a lot of unknowns, which derive from the "everything possible, but nothing mandatory" style of coding that jbpm4 reflects. Up to now I tried to include functionality in the console that is applicable to most of the use cases, but of course there is much more do add. However if it only applies to a small percentage of use cases and furthermore isn't even constrained to a certain degree we cannot simply add it. I'll give you an example: Process variable inspection is one of those cases. There is currently no constraint on variables whatsoever. The "hashmap" style of design allows for everything and nothing at the same time. Of course it would be useful have that feature in the console, but without any type descriptions associated with the process it will only work in particular situations and break in others. I can list plenty of other features that have been hold back, because the core codebase doesn't allow for reliable hook into runtime inspection. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238129#4238129 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238129

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

"tfennelly" wrote : <http-provider name="myhttp" host="localhost" port="9999"> | | <http-bus busid="http1" context="/orders" /> | | </http-provider> The context would not be part of this as the requirement is to keep this to a single deployment. It would share the same context as the EBWS, i.e. based on the esb deployment name by default. "tfennelly" wrote : That works fine I think. One downside is that it seems to mean that we're restricted to a 1:1 bus:listener relationship for http. What if we added a "urlPattern" type config (mapping to the same in the web.xml) option on the listener (or provider perhaps?). That would allow a single bus to be used across multiple listeners e.g. URL patterns should definitely be supported. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238123#4238123 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238123

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

"tfennelly" wrote : Exactly the same as EBWS again, or should we try and create a new mechanism that abstracts this type of thing (creating sub deployments) away from the deployer and then use this as an opportunity to start evolving the EBWS specific code out of the deployer (where I would think it doesn't belong)? EBWS and the http gateway are essentially the same animal and should be shared. There are very few differences between the two, especially once we extend EBWS to support what will be available to HTTP. We should definitely take this code out of the deployer but going to the extent of a fully extensible framework is not required. We only need to support HTTP and EBWS. "tfennelly" wrote : Do we want to merge deployments of the same type as in this case, where the EBWS and the new HttpGateway both require war deployments? What would that gain and would the added complexity be worth it? Yes, these should be merged into the same war file so that we have a single deployment. Even with the current EBWS code we already have an issue where we conflict with other deployments, Expanding the number of these deployments, especially when not necessary, seems strange to me. BTW what added complexity do you get from adding more servlets into a deployment? Can you expand on where you think the issue lies? "tfennelly" wrote : Apart from potential implementation similarities, what else should the new HttpGateway have in common with the EBWS functionality? I'll try and cover this later when I post about the original plans. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238121#4238121 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238121

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

There are quite a lot of comments on this thread but we seem to be straying away from what we were originally after in the work for the FP release. Let me go through these postings first, then I will follow up with a summary of what we were originally after. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238118#4238118 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238118

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JBPM4 - singleton object from wirecontext

by tom.baeyens＠jboss.com

that is not a target functionality for our environment / wirecontext View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238107#4238107 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238107

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Extending jBPM, Plugging in custom IdentityService imple

by tom.baeyens＠jboss.com

here's pointers on how to plug your own identity service in jbpm.cfg.xml, remove the line <import resource="jbpm.identity.cfg.xml" /> and add <transaction-context> | <object class="your.package.YourIdentitySessionImpl" /> | </transaction-context> | YourIdentitySessionImpl should implement org.jbpm.pvm.internal.identity.spi.IdentitySession Making this identity pluggable is not our first target, but it was taken into the design. Let us know how it goes. I'll add these notes to the developers guide. And update them with your feedback. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238106#4238106 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238106

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - JBPM4 - singleton object from wirecontext

by galanfish

Hello, All! In the same environment, the same object should be returned when we request with the same objectName; But now I want to receive newly created object(as consumable) from the wireContext every time I request for, Is this configurable or I have to modify the source code or? thx in advanced! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238104#4238104 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238104

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Extending jBPM, Plugging in custom IdentityService implement

by shekharv

I was trying to identify how one could extend the current jbpm identity implementation or plugin one's own IdentityServiceImpl. I dug around in the code a bit and noticed that there are a couple of bindings.xml files that really are responsible for configuring what Implementation classes are responsible for each of the high level Service interfaces that we have in jBPM. TaskService, ExecutionService, etc. jbpm.wire.bindings.xml jbpm.user.bindings.xml Had a few points to note about the approach mentioned above, 1.) Is this the intent of the designers of the system and the api developers to provide extension points into the engine in this manner? 2.) There is also the jbpm.user.bindings.xml. From the looks of how the bindings are being stored(as a list) it does not seem that any bindings that we add to this file would override the bindings in the jbpm.wire.bindings.xml. So it seems to be more of an additive nature than overriding. So you could add new bindings, but you cannot replace/override the ones that the engine sets up by itself(default wire.bindings.xml) 3.)Taking the above point into consideration, should the jbpm.wire.bindings.xml be user configurable option? If needed? So that there is a more straightforward way to 'register' one's custom implementations for Identity and other Services(If needed). Or should the jbpm.user.bindings.xml be loaded in such a manner that it can override the existing ones. So store the bindings in a Map rather than a List? All this is based on my understanding of the way things are being setup within the engine, we have really been working with jbpm4 for a little over a week now. So I could be really miles away from the truth and the bigger picture. Excuse me if that is the case. Plugging in a custom IdentityServiceImpl would be a big gain if we are able to hook it up seamlessly to work with our own auth mechanism. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238088#4238088 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238088

16 years, 9 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: EJB3 managed component names and types

by ALRubinger

I've pushed another alpha release of the metrics deployer, this one: * Includes the MetaMapper for the invocation statistics * Updates the component subtypes as requests SLSB and SFSB tests now passing again. There are some TODOs in the tests themselves I haven't yet done anything with; where those intended for me or were you marking it for yourself for later, Ian? MDB and Entity tests still not passing as no MDBs or Entities are deployed. ;) These should be pretty trivial, but I've got to call it a night and stop here for now. Outstanding question: "invocationStatsLastResetTime" is a managed property upon the MOs themselves, but is also available via the "invocationStats" mapped property. Which would you like (I'm assuming not both)? I believe the weekly Jopr confcall is tomorrow, though I'll be unavailable by voice I'll try to pop into IRC if I can. S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238085#4238085 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238085

16 years, 9 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 June 2009