Here's a question that applies to datasources as well as any other resource defined at the domain level.  How do we actually map these into server groups?  By usage?  What if we want to define more than one datasource with a given name (or rather, with a given JNDI binding) in the domain and map them selectively to server groups?

For deployments we have the file name + sha1.  In this case we could restrict a server group such that only one deployment with a given name is allowed per server group, or disambiguate some other way.  But for general resources we don't really have any sort of policy.

Hi,

work on this area is going on: here you have the first draft of datasource_1_0.xsd

Even if it can be considered quite stable, it can change a bit in next future for usability reasons and/or...bugs

Here you have also all examples foundend in AS6 docs/examples/jca regarding datsource and xa-datasource rewritten according new xsd and used in our test suite.

Any comments are more than welcome

bye

S.

Fantastic.

There are a few of couple the schema brings up that we need to figure out

1. We need to figure out how security is going to look, and how it can be commonly referenced from multiple areas, this is something we need to work with Anily and Scott on.
2. We need to figure out how a datasource gets at the class-loading module which contains the jdbc drivers and conection classes. This could mean a module descriptor reference, or alternative some kind of special namespace that is shared for drivers and datasources.

Jesper Pedersen wrote:

 

Looks good. A couple of comments

I think we should remove the -settings suffix - f.ex. 'validation-settings' -> 'validation'.

Done in my last commit, with changes to metadatas interfaces and implementation according.

In this commit I've also changed a bit xsd to adhere xsd name comnvention of AS7 (mainly *Type for type definition instead of *ComplexType or *Value I've used before for complex and simple types) as I discussed in IRC with David.

Jesper Pedersen wrote:

 

Also we need a way to pass in configuration properties and their values to the user supplied classes like the validation connection checker and the exception sorter to allow user to override default values in the implementation. F.ex. overriding the timeout value for the database ping method:

 

<valid-connection-checker>

<class-name>com.mycompany.MyConnectionChecker</class-name>

  <property name="Timeout">1</property>
</valid-connection-checker>

 

And what about making class name an attribute? It wpuld results in a more compact xml in case of no property, and an easier to read one in case of multiple config property:

<valid-connection-checker class-name="com.mycompany.MyConnectionChecker" />

<valid-connection-checker class-name="com.mycompany.MyConnectionChecker">
     <property name="Timeout">1</property>
     <property name="OtherProperty">2</property>
</valid-connection-checker>

Jesper Pedersen wrote:

 

However, that can come later (post M1), as we need to enhance the JDBC resource adapter with this feature too.

Well, if we can agree at least on the xsd structure I'd prefer to change xsd now, to limit (as much as possible) changes in metadatas api.

best regards

S.

Hi all,

I've discussed a bit about this point with  Alexey Loubyansky on IRC channel. I was asking some feedback about the posted xsd.

I'm trying to write down the main contents of our discussion here to keep others post and then I'll try to resume our conclusion about how many xsd we need to have JCA stuffs included in domain.xml and also usable for standalone version of IronJacamar project. Please note here we are referring to a standalone JCA implementation and not standalone configuration of As for which we don't need anything different than domain.xml from a JCA config point of view.

Of course if I've missed and/or misunderstood something, Alexey please precise that points.

Feedback

The main points Alexey had about the xsd is:

• Name conventions (also David had pointed me out on this point). STATUS ON THIS POINT: I've already fixed type names in last committed version of xsd. I've tried to follow what I can see for example in /jboss-as-domain/src/main/resources/schema/jboss-domain-mod_cluster.xsd. Anyway have a look to the last committed xsd and let me know if something still missed/wrong.
• namespace: I need to define the namespace used for jca definition. Conventional namespace name is "urn:jboss:domain:whateveryouwant:1.0". STATUS ON THIS POINT: the namespace will be set in the top level xsd (let me call it jca.xsd) which will include other xsd (see conclusion)
• Number of xsd. I've explained I was planning to have different xsds for datasources (the committed one) and for connection-factories. Alexey thinks it's better to have just one xsd with multiple top-level element possible to limit the number of xsd, and much more important limit the number of namespaces. STATUS ON THIS POINT: see the next feedback and the conclusion. We agreed about an xs:include based solution giving multiple xsds file included in jca.xsd file with only one namespace used into the AS domain.xml
• I've explained to Alexey that IronJacamar (JCA project) needs these xsds too while it doesn't need a top level jca root tag with globla configuration. As Jesper explained in a previous post AS7 jca stuffs need some global configuartions (ArchiveValidation, ArchiveValidationFailOnWarn etc) exposing some of the attributes that IronJacamar currently have on its  deployer in order for users to setup their BootstrapContext's.  STATUS ON THIS POINT: see conclusions.

Conclusions

• We need at least 3 xsd: jca.xsd for AS7 and an xsd for ironJacamar stanalone. The first one will define  urn:jboss:domain:jca:1.0 namespace, tags for global configs and will include datasources and connectionfactories xsds (one containing both or 2 xsd at this level isn't a big difference). The second one just define a root tag, with its own namespace and will include DS and CF stuffs. The best solution we see (at xsd level) is to define DS and CF xsds without namesapce and then use in the 2 top level xsd (AS and JCAStandalone) xs:include directive to include all definition there. These solution should permit us to have in fact common definitions defined in DS&CF xsd (or 2 xsds as said, since using include it's just matter of number of files and not namespaces), and specific definitions in jca's AS xsd and ironJacamar standalone one. These is an advantage because we could have different life cycle for different configuaration levels, permitting in particular to add something at AS or standalone top level configs without impact each other.

Any comments are more than welcome

regards

S.

Jesper Pedersen wrote:

 

I have been thinking about the configuration for the JCA container - e.g. <jca-container>.

 

Hi I have completed the xsd design and service implementation for JCA-container (connector subsystem).

I have just requested the pull to mantainers, but if someone would have a look it will be found on my git space

http://github.com/maeste/jboss-as

under connector module.

just to keep everyone up to date on work going on in this area, and have some feedbacks too.

bye

S.