[jbossws-users] WS-Eventing: wsa:ReferenceParameters and multiple sources

Hi, I have two issues to discuss regarding the WS-Eventing extension to JBossWS. 1. Notifications don't reflect the wsa:ReferenceParameters provided with subscriptions' NotifyTo and EndTo wsa:EndpointReferences. If my understanding of WS-A is correct, each reference parameter should appear as a top-level element in the SOAP header of notifications. Is this not the case? I need it for a "SubscriptionID" field that allows a recipient to identify the subscription which resulted in the notification. The first patch, WSE-ReferenceParameters.patch, introduces the desired behavior. I have to admit, I'm fuzzy on the distinction between ReferenceParameters and ReferenceProperties. If it's only the latter which is meant to have this behavior (as it is in the examples in the WS-Eventing spec), then I can modify my implementation and this patch. 2. Deploying a single event source, as in the sample provided, worked fine. However, I ran into two problems with more than one event source in the same deployment. Both problems are addressed in the second patch, WSE-SourceInit.patch. The first initialization bug was in MetaDataBuilder::processEndpointMetaDataExtensions. This method is called for each endpoint, and goes through the service's WSDL looking for wsdl:portTypes with a wse:isEventSource attribute. For each such portType, a EventingEpMetaExt extension is added to a map in ServerEndpointMetadata indexed by the WS-E namespace. However, since the namespace is the same for all such portTypes, only the last one sticks around. Then during deployment, the EventingDeploymentAspect registers each event source with the SubscriptionManager, but the EventingEndpointDeployment has the wrong eventSourceNS for all but the last portType processed by the MetaDataBuilder. The SubscriptionManager depends on an eventSourceNS being registered exactly twice: once for the source endpoint and once for the subscription manager endpoint. But since the eventSourceNS for the last portType gets registered twice, neither of which is the subscription manager, the premature transition of the source to the STARTED state causes its assertConfiguration() to fail. My solution is to modify MetaDataBuilder::processEndpointMetaDataExtensions to not add the EventingEpMetaExt for event sources that don't correspond to the current endpoint's address. The SubscriptionManagerPort (identified by the same dodgy string-literal comparison used in the SubscriptionManager class) still gets all sources' EventingEpMetaExts. The second initialization bug was that SubscriptionManager's registerEventSource didn't ensure that all event sources went through CREATED and STARTED states. In my case, this manifested itself with a NullPointerException when an un-started EventSource tried to deliver a notification. The patch refactors registerEventSource (and its protected helper, updateManagerAddress). There's probably room for a little polish here, but it works and I've spent too much time on this already. :) On a design note, I'm finding it cumbersome to have the event source derive its URI from its WSDL portType QName. This, along with the annotation approach to creating a non-abstract endpoint class, requires a lot more configuration per event source than it feels like should be necessary: a new portType, a new binding, a new service port, a new servlet in web.xml, plus a new Java file that needs to be compiled. Right now I'm autocoding all of these from a single source XML (a custom annotated WSDL), but is this the best way? Does someone have a suggestion for me? Regards, Dan