[Design of JBoss Web Services] - Re: Simplify deploy/undeploy cycles for different stacks
by adrian@jboss.org
"thomas.diesler(a)jboss.com" wrote :
| AFAICS, your comments relates to AS50 only and how the AS decides to provide the WS funtionality. Much of it I understand and would agree.
|
The same problem exists in all versions. I was using AS5.0 as an example.
As for the correct way to do it, look at how the MC/deployers are integrated.
The jars are provided with suitable integration hooks
- a SPI (system programmer interface) e.g. MainDeployer, classloading, parsing, etc.
These are well defined and "stable" interfaces, implementations and helpers
(I quote stable because we still haven't done our CR1 release yet :-)
The AS project (system and system-jmx) then uses (and extends them
in some places - e.g. legacy jmx integration) them.
The deployments (the configuration files) are created by the appserver project
where it can modify the behaviour to suit its own requirements.
In principle your project should not have to change. Instead what changes
is the way it is integrated into the different releases of the appserver
(using the mechanism defined by that version/release).
For your "community updates" this should just be case of replacing the jars
if you have paid any attention to the backwards (and forwards) compatibility
of your spi.
ANOTHER ASIDE:
In principle, going forward, the jboss-integration project should define
a webservices spi (interfaces and helpers) which you (or anybody
else) can implement to provide webservices for any jboss project that
integrates using our standard spi (e.g. AS, embedded, esb, etc.)
It would then be a case of writing a JBoss4 subdeployer or a JBoss5 deployer
on top of that spi. (I doubt it will ever get done for JBoss4 ;-)
This would then embody the three different roles
(currently you do all three yourself):
* Policy - what needs doing (the user - e.g. JBossAS)
* Wiring - How to go about doing it (the api/spi - e.g. jboss-integration)
* Implementation - Do it (you - JBossWS)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130728#4130728
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130728
16 years, 3 months
[Design of JBoss Web Services] - Re: Simplify deploy/undeploy cycles for different stacks
by adrian@jboss.org
Guys, why are you writing the deployment framework in the JBossWS project?
I've said this many times before, concentrate on webservices
and let the AS handle deployment/integration
If you have an issue with deployment that needs addressing then deal with
it in the deployment project, don't reinvent the wheel in an incompatible way
yourself.
e.g. in JBoss5 which deployments get deployed (and how they are configured/managed)
with be a property of the profile service not some internal hackery by you.
Choosing and redeploying the WS stack must be doable there
(which is potentially a remote management console managing and
provisiong a cluster).
All that will happen in the long term is that we will have to unpick your hackery.
ASIDE:
You're still providing your own as integration in the webservices project.
The responsibility of the webservices project is to provide the services
the AS project should do the integration that's what it is for.
If you don't understand what I mean then consider whether it is upto the webservices
project to define the configuration and packaging (a sar) for webservices
or whether you should provide the functionality and let the appserver
define its own configuration.
http://repository.jboss.com/jboss/jbossws-native50/2.0.3.GA/lib/
A few obvious examples of why this is broken:
1) The sar includes thirdparty jars that are not chosen by the AS project
2) The "sar" is in deploy mixing deployment and runtime configuration
in its beans.xml
The deployers should be the in the deployers folder not the runtime,
it should not require runtime dependencies to get the deployers in place
they should only deal with metadata (for validation purposes
inside a management console the runtime will be mocked or the alternatively
the runtime maybe "on-demand" dependent on whether there is a relevant
deployment).
3) You have your own "deployer" which means we can't use the AS deployers
to "interleave" new behaviour (modification of metadata to change/introduce
semantics)
The aop and messaging projects have similar problems, although I recently
decided to ignore aop's delivery of a sar and recreated it with the configuration
required INSIDE THE AS's ASPECT PROJECT
(which is only really a partial solution).
These complaints will probably fall on deaf ears again? :-(
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130705#4130705
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130705
16 years, 3 months