[wildfly-dev] JCA service/model names a.k.a WFLY-1656

[Stefano Maestri]

Hi,

I've started to review this patch and at a first look can't work as is. 
It needs at a first look at least changes to resource-adapters xsd, 
because it bases service names on "id" attribute, but actually this 
attribute is not mandatory in xsd. In case you define a resource-adapter 
configuration in standalone.xml for a rar having an internal config with 
ironjacamar.xml It drives to runtime error like this:

14:47:27,561 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) 
MSC000001: Failed to start service jboss.ra.deployment."ra16outij.rar": 
org.jboss.msc.service.StartException in service 
jboss.ra.deployment."ra16outij.rar": 
org.jboss.msc.service.DuplicateServiceException: Service 
jboss.ra.ra16outij is already registered

Or even defining 2 resource-adapter in standaole xml on the same rar 
archive, w/o defining id as xsd permit:
14:49:59,574 ERROR [org.jboss.as.controller.management-operation] 
(ServerService Thread Pool -- 11) JBAS014613: Operation ("add") failed - 
address: ([
     ("subsystem" => "resource-adapters"),
     ("resource-adapter" => "ra16outij.rar")
]) - failure description: "JBAS014803: Duplicate resource [
     (\"subsystem\" => \"resource-adapters\"),
     (\"resource-adapter\" => \"ra16outij.rar\")
]"

Both this use case are normal and very frequent because resource-adapter 
defined in standalone.xml should be considered multiple configuration 
(activation in jca slang) on the same deployed rar. I still have to 
cover all use cases, but those 2 at least needs to be fixed. Probably 
the easiest solution is to make "id" mandatory, but I have to double 
check it is sufficient for programmatic activations (explicit call of 
service like HornetQ is doing) and ironjacamar.xml ones.
If you agree I'll take the issue and I'll merge your patch on my branch 
and rework it a bit to cover all those use cases and possibly to solve 
also WFLY-1776 (the problem here could be that xsd changes can't be 
backported and it is a EAP case)

regards
S.


On 08/06/2013 03:29 PM, Bartosz Baranowski wrote:
> Hey
>
> Finally I was able ( I think ) to nail the problem and forge fix. There are still some intermittent CI failures, but other than that CI looks clear.
> While I polish last parts it would be good to get feedback on changes, since impact on JCA integration is quite big.
>
> Fix removes all static/leaky code from ConnectorServices ( add relevant code to MSC service ), move away from static hashmap checks in favor of MSC service present/deployment/dependency and remove ability to create more than one activation for distinct model address.
>
> Branch:
> https://github.com/baranowb/wildfly/tree/WFLY-1656
>
> Relevant issues:
> https://issues.jboss.org/browse/WFLY-1656
> https://issues.jboss.org/browse/WFLY-1492  -> https://bugzilla.redhat.com/show_bug.cgi?id=964202
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev