Re: [jboss-dev-forums] [JBoss AS7 Development] - JCA / Datasources in domain.xml
by Stefano Maestri
Stefano Maestri [http://community.jboss.org/people/maeste] replied to the discussion
"JCA / Datasources in domain.xml"
To view the discussion, visit: http://community.jboss.org/message/557508#557508
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/557508#557508]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 9 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - JCA / Datasources in domain.xml
by Stefano Maestri
Stefano Maestri [http://community.jboss.org/people/maeste] replied to the discussion
"JCA / Datasources in domain.xml"
To view the discussion, visit: http://community.jboss.org/message/557500#557500
--------------------------------------------------------------
> 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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/557500#557500]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 9 months
Re: [jboss-dev-forums] [JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration
by Flavia Rainone
Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] replied to the discussion
"Implementing a non-flat deployment for Weld Integration"
To view the discussion, visit: http://community.jboss.org/message/557388#557388
--------------------------------------------------------------
With a temporary workaround to the beanManager issue (simply replaced "entry.getKey().getId().equals("flat"))" by "entry.getKey().getClass().getName().contains("org.jboss.weld.integration.")") I ran into an issue involving the service registry. I'm not sure if this is related to the beanManager issue or not, but the problem is that Weld complains if a new BDA created by Deployment.loadBDA method has a clean service registry:
DEPLOYMENTS IN ERROR:
Deployment "vfs:///home/fla/Development/projects/jbossas-trunk/testsuite/output/lib/weld-translator.ear_WeldBootstrapBean" is in error due to the following reason(s):
org.jboss.weld.exceptions.ForbiddenStateException: WELD-000117 Required service org.jboss.weld.injection.spi.EjbInjectionServices has not been specified, **ERROR**
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1370) [:2.2.0.Alpha6]
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1316) [:2.2.0.Alpha6]
So, I created a workaround to populate the loaded BDA service registry, just to see if the error would go away. DeploymentImpl initializes the loaded BDA service registry with a copy of the service registries of the BDAs contained in the DeploymentImpl (only services added during bootstrap).
This makes WeldNumberguessExampleUnitTestCase to pass, but WeldTranslatorExampleUnitTestCase still fails, stating that TranslatorControllerBean is ambigously defined:
DEPLOYMENTS IN ERROR:
Deployment "vfs:///home/fla/Development/projects/jbossas-trunkLATEST/testsuite/output/lib/weld-translator.ear_WeldBootstrapBean" is in error due to the
following reason(s): org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name translator resolves to beans
[org.jboss.weld.bean-BaseClassLoader@62b92dc2{vfs:///home/fla/Development/projects/jbossas-trunkLATEST/build/target/jboss-6.0.0-SNAPSHOT/server/all/deployers/resteasy.deployer}-SessionBean-TranslatorControllerBean, org.jboss.weld.bean-BaseClassLoader@7e7186b{vfs:///home/fla/Development/projects/jbossas-trunkLATEST/testsuite/output/lib/weld-translator.ear}-SessionBean-TranslatorControllerBean],
**ERROR**
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1370) [:2.2.0.Alpha6]
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1316) [:2.2.0.Alpha6]
at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:968) [:2.2.0.Alpha6]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.checkComplete(MainDeployerPlugin.java:82) [:6.0.0-SNAPSHOT]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.checkComplete(ProfileControllerContext.java:125) [:0.1.0.Alpha1]
at org.jboss.profileservice.plugins.deploy.actions.DeploymentStartAction.doPrepare(DeploymentStartAction.java:104) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:100) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.1.0.Alpha1]
So, the problem is that Weld finds two EjbDescriptors of the same bean. One in the BDA that represents weld-translator.ear, included in the corresponding DeploymentImpl, and another one in the bda that has been loaded by the Deployment, representing resteasy.deployer.
If I still initialize the loaded BDA service registry with a copy of the other BDAs service registry, but this time adding a new, clean, JBossEJBServices to the loaded BDA serviceRegistry, and putting no EjbInjectionServices in it, I get a message complaining that the injection point has unsatisfied dependencies:
DEPLOYMENTS IN ERROR:
Deployment "vfs:///home/fla/Development/projects/jbossas-trunkLATEST/testsuite/output/lib/weld-translator.ear_WeldBootstrapBean" is in error due to the following reason(s): org.jboss.weld.exceptions.DeploymentException: WELD-001408 Injection point has unsatisfied dependencies. Injection point: field org.jboss.test.deployers.weld.translator.ejb.TranslatorControllerBean.translator; Qualifiers: [@javax.enterprise.inject.Default()], **ERROR**
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1370) [:2.2.0.Alpha6]
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1316) [:2.2.0.Alpha6]
If anybody wants to retrace my steps, there is a https://jira.jboss.org/browse/JBAS-8250 patch attached to Jira that can be applied to JBoss AS trunk. You can check loadBDA implementation http://anonsvn.jboss.org/repos/jbossas/trunk/weld-int/deployer/src/main/j... here.
So, what is expected from the ServiceRegistry of a newly created BDA? Should it be initialized with some services? Which ones?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/557388#557388]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 9 months