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/557705#557705
--------------------------------------------------------------
> Ales Justin wrote:
>
> > Ales, why should I add it to bootstrap?I mean, can't I just scan the lib dirs as part of the first weld deployment instead of doing it on bootstrap? What are the advantages of doing otherwise?
> Exactly for the reason you have a 2nd question. :-)
>
>
Indeed, currently I'm invoking DefaultDomain.loadClass so I can figure out the ClassLoader, which is awful. I also thought on applying some rule to determine the module name, but I wanted to hear from you what would be a good way of retriveing the CL.
> Ales Justin wrote:
>
> > Another question: once I determine that a specific jar in lib has the META-INF/beans.xml file, what is the cleanest way of retrieving the corresponding lib ClassLoader?
> Adding some "listener" service at bootstrap would mean we could somehow
> add a mechanism that would, for every lib added to cl domain, check if there is some beans.xml.
>
>
Cool. That would easily give access to the ClassLoader/module that corresponds to the lib IIUC.
> Ales Justin wrote:
>
>
> I can look into it what would be the best way to do this.
> Unless you wanna do it yourself.
Thanks! You can go ahead. :-) In the meantime, I'll try Pete's suggestion to fix the duplicate ejb descriptor issue.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/557705#557705]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 4 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - JCA / Datasources in domain.xml
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] replied to the discussion
"JCA / Datasources in domain.xml"
To view the discussion, visit: http://community.jboss.org/message/557687#557687
--------------------------------------------------------------
> 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)
We will need to see where it fits into the overall AS 7 domain.xml picture -- configuration of the JCA container, setting up datasources and activating resource adapters are very different things, so I don't think putting them under a single XSD is a good idea.
> 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
No, those are separate because of the reasons stated above. Each piece will fit into a certain area in the domain.xml and not under a single tag.
We have
* The actual deployment (part of domain.xml which identifies the resource adapter archive)
* The configuration of the JCA container (settings for the JCA deployers and the container itself based on the JCA container XSD)
* Datasources (specification of datasources based on the datasources XSD)
* Activation of resource adapters (activation of resource adapter instances with their configuration based on the resource adapter XSD)
The question is if the "system" resource adapter such as jdbc-local.rar and jdbc-xa.rar should be hidden from the domain.xml and be a mandatory deployment. I think so, as <datasource> wouldn't work otherwise.
> jca.xsd for AS7 and an xsd for ironJacamar standalone
No, and IronJacamar standalone issues should be discussed in the JCA Devel forum - they don't belong here.
> 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.
IronJacamar have a strict release cycle, so don't make that the first overall design goal. Remember that AS 7 will consume an IronJacamar tag which maps to certain functionality - the integration will live in AS 7.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/557687#557687]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 4 months