Hi Richard,

[removed the section on records mngmt, as that's going OT - we'll get back to that later and in any case -as said- it's not a priority]

API REVIEW

In the process of revisiting the JBossWS SPI, we need to properly split the current jbossws-spi project contents into:
- a set of classes/interfaces required for proper abstraction of jbossws components (pretty much what we have today, 2 stacks, perhaps multiple supported target container[3], ...) and to have a defined interface towards other related jboss projects (EJB3 for instance)

This is what we have today. But I definitely agree this needs further/proper cleanup!
BTW there's EJB3 integration review on my plate. Hopefully this will be fixed with AS7 integration.

Yes. This is one of the reason I'd like to get started with this jbws 4 work asap, Carlo is needing any changes to the interface with WS well before AS 7 goes Beta1 (as EJB3 is meant for Beta1 as far as I understood)

I can do some EJB3 dependencies cleanup in AS 6 trunk to clarify it before AS 6 goes final?
Or I can use custom 3.4.0 JBossWS branches against AS CR1?

Frankly, atm I'd say neither of the 2 options above. The jbws 3.4.0 branches are meant only for changes required due to last minute changes in CXF 2.3.1. The trunk (aimed at 3.4.1) is just for the minimun required to have in AS6 final the same good tck6 results we have with AS 6 CR1. The freeze for AS 6 final is in few weeks from now and the ejb3 team is not going to have time for dealing with jbws spi changes for AS6.
We're already reasoning in terms of AS7 / JBWS 4 here.

Please note that anything not really make use of the AS facilities properly is not going to be pulled upstream
Well U need some JBossWS AS7 baseline first
which will help U to learn basic AS 7 architecture rapidly.
AS 7 team cannot expect/force others to be AS 7 experts first
(before contributing anything to AS7)
and doing "everything" right in first pull request.

Sure, what I meant is that -oversimplifying this a bit- it's not probably acceptable to have an initial integration that is just an "adaptor" to AS7 of what we had in AS6, but the solution should be thought in terms of the AS7 design. Things went differently in the past -I know- but I wouldn't like to re-write the AS integration layer in -let's say- 7.1 like we had to with AS 5.x. I'd rather have a proper solution from the beginning. Not saying it needs to be perfect, but...
Anyway, this is just philosophy at this point ;-)

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.

Regarding JAXRPC, it's legacy stuff, so it's acceptable to treat that differently if we need to (meaning no domain / public available service & api for that). Just the "minimum" required for certification.

Yes, but this legacy staff needs some minimal cleanup too.

Yes, probably

Cheers
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss