[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by Kevin.Conner＠jboss.com
"tfennelly" wrote : OK, so I implemented a bit of this so as we can have something concrete to discuss. It's not in any way complete and there are things in it that I plan on refactoring (e.g. removing the ability to reference a web.xml/jboss-web.xml, as requested), as well as there being bits which are not yet implemented at all.
I hope this means that you are keeping the set of changes as small as possible, remember that we are not into creating wonderful new frameworks here. We have two use cases for 4.x and that is it.
"tfennelly" wrote : Also, Kev has an issue with using the mep to decide whether or not a response is sent back from a Http Gateway. Plan on discussing that separately.
Kev has an issue in basing code on broken assumptions, but this has already been discussed to death. What else do you feel needs to be discussed?
"tfennelly" wrote : The main thing I wanted to look at was the common codebase for EBWS and the new HttpGateway. I have implemented the bones of a "WebModel" concept that gets built up at deploy time and is then used to construct a single war file for the .esb deployment.
|
| See SVN: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/tfennelly/htt...
|
| So the basic idea is simple... the Deployer:
| 1. Creates an instance of WebDeploymentArchive. (Implemented)
| 2. Calls EBWS specific code for it to add it's servlets etc to the model. (Not implemented).
| 3. Calls HttpGateway specific code for it to add servlets etc to the model. (Implemented)
| 4. Creates and deploys the war sub deployment. (Implemented)
I hope this is the minimalist approach :)
"tfennelly" wrote : Note that where I say "Implemented"... I'm not saying that part is complete and will not change!!! Really just saying "there's something there" for that part of the equation ;)
|
| The base context is based .esb name (as requested).
|
| For the Http Gateway, it's currently prefixing the urlPattern with the associated http provider bus name (and not hardcoded "http", as requested).
But you are going to change this to what was requested, right?
"tfennelly" wrote : This seem OK so far?
Please remember that this is supposed to be as small an impact as is possible for the current codebase, we will only have two use cases for 4.x. We need to retain some ability to move fixes between the current platform branches and future ones.
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246138#4246138
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246138
16 years, 8 months
[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by tfennelly
OK, so I implemented a bit of this so as we can have something concrete to discuss. It's not in any way complete and there are things in it that I plan on refactoring (e.g. removing the ability to reference a web.xml/jboss-web.xml, as requested), as well as there being bits which are not yet implemented at all. Also, Kev has an issue with using the mep to decide whether or not a response is sent back from a Http Gateway. Plan on discussing that separately.
The main thing I wanted to look at was the common codebase for EBWS and the new HttpGateway. I have implemented the bones of a "WebModel" concept that gets built up at deploy time and is then used to construct a single war file for the .esb deployment.
See SVN: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/tfennelly/htt...
So the basic idea is simple... the Deployer:
1. Creates an instance of WebDeploymentArchive. (Implemented)
2. Calls EBWS specific code for it to add it's servlets etc to the model. (Not implemented).
3. Calls HttpGateway specific code for it to add servlets etc to the model. (Implemented)
4. Creates and deploys the war sub deployment. (Implemented)
Note that where I say "Implemented"... I'm not saying that part is complete and will not change!!! Really just saying "there's something there" for that part of the equation ;)
The base context is based .esb name (as requested).
For the Http Gateway, it's currently prefixing the urlPattern with the associated http provider bus name (and not hardcoded "http", as requested). So for a provider and listener configured as follows:
| <http-provider name="http">
| <http-bus busid="ordermgt" />
| </http-provider>
|
| <http-listener name="oml" busidref="ordermgt" urlPattern="/in/*" />
|
The following requests will be filtered through to that listener....
| http://{host:port}/{.esbname}/ordermgt/in/*
|
This seem OK so far?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246131#4246131
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246131
16 years, 8 months
[Design of JBoss Transaction Services] - Re: beanifying the config
by jhalliday
1) No. The design of the code base pre-dates DI frameworks (and indeed Java) by quite a wide margin. It's not particularly DI friendly. On the other hand, it does not force you to pull in a DI framework you may not want when embedding TS.
2, 3, 4) Right now JBossTS does not link against, nor provide xml wiring for, any DI framework, with the partial exception of the atsintegration module hooking into JBossAS 5 via MC.
At this stage I don't plan on introducing any compile time dependency on MC or any other framework, other than for the AS integration module.
What I do want to accomplish it to have a more bean oriented configuration mechanism so that any DI container can use that in preference to the config file, which makes for a better embedding approach.
Over time we may embrace one or more framework more fully, but first we need to deal with the lifecycle issues - part of JBossTS don't cope well with being shutdown and restarted, much less reconfigured on the fly.
> > and the type conversion and default handling code will vanish from the point of consumption.
> nice
Well, yes and no. Centralising the type conversion code is good, but moving the default handling is less of a clear cut win. In cases where only a single bit of code uses a given property, it actually results in moving the decl of the default away from its point of use. Whilst this makes configuration easier for the end user, it makes life harder for the maintenance programmer. I'm inclined to go with a hybrid approach where the bean does
private int someProp = ClassThatUsesIt.DEFAULT_VALUE;
rather than removing the DEFAULT_VALUE from ClassThatUsesIt and having the config bean do
private int someProp = <default_value>
It means bi-directional linkage between the bean the the utilizing classes, but makes for greater clarity of intent when reading either.
The other problem the bean approach brings is one we just got rid of - you have to know where a property resides before you can set it. In the old hierarchic property file format, users frequently defined a property in the wrong section and then wondered why it had no effect. That's solved by moving to a flat format, but a similar issue arises when a slew of beans enter the picture.
It's not always intuitively clear which bean contains a relevant property. At least the method and type checking will cause exceptions if you get it wrong, unlike the property file problem. The only fix I can see for this is to put all the properties (100+ of them) on a single bean, a cure which is probably worse than the disease.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246123#4246123
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246123
16 years, 8 months