[jbossws-dev] Endpoint configuration - jbossws descriptors

[Richard Opalka]

Comments inlined,

Rio

On 04/28/2011 04:28 PM, Alessio Soldano wrote:
> Folks,
> jbossws-native comes with the @org.jboss.ws.annotation.EndpointConfig
> annotation for referencing a given endpoint configuration file. The
> schema for that configuration file (well, it's actually for both clients
> and endpoints, but let's stick to the endpoint case for now) is at [1] .
> Basically, the configuration covers handlers, features and properties
> (plus some native specific ws-rm stuff) and is used both for the
> "default" configurations [2] and for custom user provided
> configurations, perhaps even coming within a deployment. The same
> configurations files can also be referenced on client side through
> jbossws-native specific api. As of today, the most common usage is
> probably for enabling WS-Security on native stack.
>
> Now, as part of [3] and considering the AS7 efforts around isolating
> APIs from implementation stuff at runtime, I'm thinking about what to do
> with @EndpointConfig.
The same question I asked U few days back ;)
> Moreover, we currently have a feature request regarding the need for
> defining global endpoint handlers [4] as well as the will for allowing
> WS-Security endpoint configuration with JBossWS-CXF stack without the
> need of spring bean descriptors. Especially after my changes for using
> Apache CXF 2.4 [5], the latter basically means being able to simply set
> string properties into the endpoint, as CXF / its policy engine / WSS4J
> are then able to deal with everything else.
>
> So, considering this all, with the aim of further unifying the jbossws
> configuration, I'm proposing to:
>
> - add @EndpointConfig annotation to the public api in jbossws-api;
> extend the jaxws endpoint "configuration" that was a native aspect only
> to be a stack agnostic jbossws one instead
+1
> - refactor the client/endpoint configuration schemas, pruning the native
> specific stuff (basically ws-rm) and perhaps moving that to a native
> stack specific extension of the schema;
I'm saying it always & I'll repeat it once again.
I'd remove our Native WS-RM & WS-Eventing staff, COMPLETELY.
Both specs. don't fit JAX-WS spec.
Even more both are not supported in EAP.
JBossWS Native is also considered dead project.
The AS7 is targeted with CXF.
Native will be there (hidden) only for JAX-RPC functionalities.

> we might even have a cxf stack
> specific extension for cxf interceptors, but that's not strictly
> required now (jaxws handlers should be enough for now)
I'd say no schema extensions, just handlers hooks should be supported.
> - add the default endpoint configuration to the AS7 domain model: after
> all, this is a global configuration aspect of the application server and
> hence should be manageable
+1
> - modify our jbossws-cxf stack deployment aspects: when building the
> endpoint model, they will consider the endpoint configuration either
> from the default conf in the domain model or from a user provided
> descriptor in the deployment and referenced through @EndpointConfig
+1
> With this solution we'd clean a inconsistency in the api
> (@EndpointConfig for native only till now), add a mean for having global
> handlers configured by administrators [4] and allow providing security
> keystore/trustore/etc. info and use WS-Security(policy) with jbossws-cxf
> without any need for Spring.
Go ahead ;)
> Any comments?
> Cheers
> Alessio
>
> [1]
> http://anonsvn.jboss.org/repos/jbossws/stack/native/trunk/modules/core/src/main/resources/schema/jaxws-config_2_0.xsd
> [2]
> http://anonsvn.jboss.org/repos/jbossws/stack/native/trunk/modules/core/src/main/resources/META-INF/standard-jaxws-endpoint-config.xml
> [3] https://issues.jboss.org/browse/JBWS-2709
> [4] https://issues.jboss.org/browse/JBWS-3109
> [5] https://issues.jboss.org/browse/JBWS-3272
>

-- 
Richard Opalka
ropalka at redhat.com
JBoss, by Red Hat

Office: +420 222 365 200
Mobile: +420 731 186 942