Comments inline
On 8/22/06, James Strachan <[EMAIL PROTECTED]> wrote:
I was wondering about the minimal amount of code required to write a
nicely behaving JBI component with proper component, endpoint,
deployer and URI/EPR handling etc.
e.g. if we were to refactor more of the components in the
servicemix-components module into their own module like the jms, http
and jsr181 modules - what new code would be required. Or rather how
little could we get away with :)
So I was wondering if we could do a little bit of refactoring to
reduce the amount of code that is really needed to be written on each
component. (Some of the other components are way simpler than jms,
http and JSR181 support too such as the file component so the code
should hopefully be even simpler).
Of course it would be nice.
I think all your following points came from the fact that I added features
to servicemix-http first (so not in servicemix-common / servicemix-soap)
and then duplicated them in servicemix-http instead of refactoring them
in some common code :( My mistake.
I've not had an coffee yet so please excuse any silly ideas but a
quick run through the code in the Jms and HTTP components with brief
looks at JSR181 led to the following thoughts...
* HttpBootstrap & JmsBootstrap are pretty much identical apart from
the configuration property (incidentally should HttpBootstrap use a
HttpConfiguration like JmsBootstrap?) so am wondering if we can push
more of its logic up to a base class - maybe allowing the
configuration object to be specified as a constructor argument?
At first, they were inheriting a base class (BaseBootstrap in
servicemix-common).
The problem is that shared libraries are not available at bootstrap
time according
to the jbi spec (hence to ServiceMix too). So we can not refactor much here :(
I'll take a look at the HttpBoostrap / HttpConfiguration problem.
* HttpLifecycle & JmsLifecycle have quite a few similarities. I wonder
could we refactor most of the code into the *Configuration and
*Endpoint classes so that we could basically share the same Lifecycle
classes in most components?
Yeah maybe. There are other ways too: refactor the component and the lifecycle
in the same class (this would lead to one class less to implement) and / or
have a base component for soap-enabled base component class which would
retrieve the needed additional components (AuthenticationService,
KeystoreManager).
* Jms/HttpExternalEndpoint look pretty identical - just dependent on
their Jms/HttpEndpoint classes
* Jms/HttpResolvedEndpoint pretty much the same bar some constants -
maybe moving those into the *Endpoint or *Component classes might make
the code simpler?
Agreed, we could have only two classes for these
* Jms/HttpSpringComponent - look about the same apart from the use of
Jms/HttpEndpoint - I wonder if generics could be used to share a
common base class? Basically the only real difference is the type of
the endpoint.
Not sure, as the configuration, enpoint resolution and lifecycles are different.
Also the use of generics will introduce a JDK 5 requirement, unless we
use retrotranslator ;)
* Jms/HttpXBeanDeployer - we could maybe use a generic XBeanDeployer
which is parameterized on the type of the Endpoint and then call
*Endpoint.validate() to avoid needing to write a new class for this
unless its absolutely necessary (like it is for JSR181)?
True also.
I was really just trying to avoid as much of the boiler plate code as
possible so we could make more fully-JBI compliant components with as
little code as possible.
Am thinking the bare minimum would be something like the bootstrap,
component, configuration & endpoint classes with reusable base classes
for most of the other stuff then the consumer/producer classes for
doing the actual work.
Any other thoughts on how to reduce/simplify the amount of code required?
We will also need to update the archetypes to reflect all this.
Note that usually, BC and SE have different features, where current BC all use
the servicemix-soap module. We could add some BC specific classes in
servicemix-common and make servicemix-common dependant on servicemix-soap.
Btw, both are packaged in servicemix-shared SharedLibrary, so there's no problem
in doing that.
I'd like to have 3.0 out asap, so I think it's time to create a 3.1
branch so that
new devs can happen there, and keep trunk for 3.0 until it is out.
I'll start a new
thread on that now.
--
James
-------
http://radio.weblogs.com/0112098/
--
Cheers,
Guillaume Nodet
