[jbossws-dev] AS7: Re-thinking WS container integration

[Jim Ma]

>
>>> I'm just saying that we can see this similarly, we need to think 
>>> about the deployment process in terms of a) something strictly 
>>> related to setting up the container for the ws deployment, b) 
>>> actually creating the endpoint and connecting it to the container. 
>>> Theoretically speaking (b) is pretty much what is going to the 
>>> service. This said, for sure we need to deal with the details, but 
>>> that comes after agreeing on a vision.
>> My vision is to support both AS 6 (CR1 or GA) & AS 7 in JBossWS 4.0.x 
>> series.
>> This is very important to track integration regressions we might 
>> introduce during the AS 7 integration process.
>> And we need to come to an agreement what we'll target with JBossWS 4 
>> series ASAP ;)
> This is one of the key points to discuss. To be honest, I'm wondering 
> if the pain of supporting both AS 6 and 7 is balanced by any real 
> benefit here.
> Do you think we can really proceed in steps such that each of them 
> allows to still pass the testsuites (considering the major changes to 
> spi, the completely different AS structures, classloading, ...)? I can 
> see major efforts being required for retro-fitting things to AS 6, for 
> supporting completely different installation steps, etc.
> This might even be possible, we need to evaluate pros and cons.

IMO, I'd say we should just focus on  AS 7 support in JBossWS 4.x . 
Given AS7 changed a lot : binary directory structure, MSC , domain 
model, subsystem  and new DeploymentUnitProcessor, we may need 
change/refactor a lot of things in SPI , framework and container, 
deployment script to integrate with AS7. 

I also agree with you guys all, this is a good opportunity to 
review/change/refactor in our side(JBWS4.x) to simplify something and 
make it faster
* deploy endpoints faster - review and simplify the old deployers or DAs 
with new AS7 Deployment api
* more manageable - provide interface/api to start/stop endpoints, or  
transport and monitor incoming message count etc..
* rich APIs -  as Alessio talked in the previous email to provide more 
SPI apis meant for actual user consumption
* enhance test suite running - there is embeded as7 for test use ?  and 
if run one test case we just build one war file not the whole test 
deployments ...

My 2 cents.

Cheers,
Jim