Hi Jim,
let me agree with Alessio. We really don't need to introduce
another DD (jbossws-endpoints.xml namely). There are two reasons for that:
* XML configuration duplicity (as Alessio properly said users can just provide jbossws-cxf.xml with all the configuration)
* simplicity (our current SPI facade should be enough for you to do the job).
What you're doing (providing jbossws-endpoints.xml) is just creating WS stack agnostic configuration.
But our SPI is intended exactly for that purpose.
Providing additional DD is the same thing like our SPI (just different XML-ized form of it).
If you will follow my suggestions I wrote few days before you shoudn't face "real" problems.
Another thing/issue is our SPI is not perfect (and we know that).
We will improve/rewrite our SPI once we'll be done with all the
highier priority tasks we have these days.
Jim Ma wrote:
I evaluated to make new SPI metadata to extend the current SPI Endpoint. But I did not find benifit from it, as our DeploymentAspects was intended to process the SPI HttpEndpoint. It can not be reused to process JMSEndpoint too.
Let me disagree. This is the way you had to go IMHO ;)
We need these abstractions in our SPI:
* Endpoint
- ServletEndpoint -> url address
- JMSEndpoint -> jms address
* DA
- ServletDA
- JMSDA
Our ASIL deployers will accept DA abstraction
and will be able to distinguish between HTTP and JMS.
In deployer, before specifying inputs/outputs,
you should have code like this:
// pseudocode ensuring proper deployers ordering
if (DA instanceof ServletDA) {
this.addInput(WebMetaData.class);
...
} else if (DA instanceof JMSDA) {
this.addInput(JMSMetaData.class);
...
}
Both HTTP and JMS endpoints should use the same deployers flow.
Don't create another deployer flow just for JMS endpoints.
but reuse our current architeture.