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/545502#545502
--------------------------------------------------------------
The draft version is committed to this branch:
http://anonsvn.jboss.org/repos/jbossas/projects/weld-int/branches/Deploym... http://anonsvn.jboss.org/repos/jbossas/projects/weld-int/branches/Deploym...
Now we finally have something concrete to use in our discussion. So, my draft version of WELDINT-1 is fully documented in order to make it easier for others to understand and to stimulate discussion :-)
Basically, I created an Archive class that maps to a Module and contains all the info necessary for creating a corresponding BeanDeploymentArchive. An Archive can reach other archives through Classpath, which maps one-to-one to ClassLoader domains and contains a list of archives/bdas. A Classpath can internaly point to another classpath, which corresponds to the parent domain relationship. This sets up the graph structure Pete suggested, which is actually a tree.
At first, when a deployment is created, BDAs are created only for those Archives that contain one or more CDI xml file. After that, as a result of Deployment.loadBeanDeploymentArchive, a BDA may be created by an Archive. Al lthe BDA collections are updated accordingly, mainly by the use of a BDALyfecycleListener.
Take a good look at the ClasspathImpl class. This is a very naïve but simple to understand implementation of the Classpath interface. It returns always a flat collection of all BDAs or archives visible, including
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/545502#545502]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Re: [jboss-dev-forums] [Management Development] - domain.xml work
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"domain.xml work"
To view the discussion, visit: http://community.jboss.org/message/545363#545363
--------------------------------------------------------------
> David Lloyd wrote:
>
> In addition, the presence of an EAR deployment in the domain *implies* that the appropriate subsystems must be made available in order to start the domain.
For example, Imagine the simple case of an EJB deployment. Making an EJB available remotely would imply that the remoting service is required. Thus we should have a default configuration which creates the remoting endpoint and adds the EJB service with *no*
XML, but *only* when an EJB deployment occurs. Instead this configuration is *implied* (in a well-defined, deterministic way) by the node name, the services being deployed, and possibly host-specific mapping of service to IP address. In today's world, the Remoting Endpoint can't exist (and thus can't be used for built-in services) unless it is explicitly defined.
In the doman model, the definition can be implied, but can be overrideable by way of explicit configuration. The service need not exist in reality until it is required by a subsystem (like EJB, JNDI, or JSR-160) *or* user deployment (like a custom user service).
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/545363#545363]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Re: [jboss-dev-forums] [Management Development] - domain.xml work
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"domain.xml work"
To view the discussion, visit: http://community.jboss.org/message/545362#545362
--------------------------------------------------------------
> David Lloyd wrote:
>
> So if you take that as a given, then the question isn't about too much detail in the domain model (which ultimately has to contain every detail, regardless of its relative relevance), it's more about too much detail in the *domain.xml file* itself, and how can we hide some of the less-likely-to-be-useful detail without crippling the administrators *or* us poor implementors.
Moving away the idea of mixing configuration with XML scripting with ad-hoc management with ad-hoc deployment descriptors will be a big help in this arena. No service shall be created that doesn't have (a) a management interface and (b) a concise domain.xml representation (directly or indirectly).
What do I mean by an indirect domain.xml representation? Take for example an EAR deployment. If you take as given all the crap from my past couple posts, you'd have something like this:
1. An EAR deployment which contains WARs, EJBs, etc.
2. A domain.xml file which includes the EAR listed something like this:
<!-- ...stuff... -->
<deployment name="my-deployment.ear" sha1="ab271b2...f58289" serverGroups="foo bar baz"/>
Now the deployment entry in the domain.xml file doesn't list every single EJB, thread pool, socket, web context, listener, etc. that is defined in the deployment. The deployment has a deterministic, predictible implied mapping to services created as a result of processing the deployment descriptor. Thus, the domain.xml remains the definitive and complete model of the domain, but it doesn't duplicate any information and it relies on the resources included therein to complete the picture.
In addition, the presence of an EAR deployment in the domain *implies* that the appropriate subsystems must be made available in order to start the domain. There is no need to explicitly list the subsystems that we need to kick off in order for the deployments to all work. However if a subsystem needs special configuration, we certainly can and should support explicity defining those parameters in the domain.
Implementation-wise this implies that the ability to *recognize* a deployment of a certain type is a separate concern from the code that actually *does* the deployment. In addition, even the code that does the deployment might actually be split into concerns - for example we need not pull in and initialize the clustering subsystem if no components are clustered. We can and should support lazy initialization of subsystems in this way.
This way the idea of profiles is something that happens invisibly to the developer and the administrator.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/545362#545362]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Re: [jboss-dev-forums] [Management Development] - domain.xml work
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"domain.xml work"
To view the discussion, visit: http://community.jboss.org/message/545361#545361
--------------------------------------------------------------
> David Lloyd wrote:
>
> If the domain.xml does, indeed, contain the authoritative representation of the domain, then it does indeed need to contain, directly or indirectly, definitions of all serivces available up to *and including* the list of active deployments. For example, as defined in the existing requirements, a deployment can be associated with one or more server groups, which are defined as part of the domain. If the domain doesn't map deployments to server groups, what will? In addition, adding deployments can very well imply other changes to domain.xml that are necessarily made at the same time. Everything I see in the requirements says to me that the current deployment listing must be a part of the domain model.
This opens the door to new ideas. If the domain.xml (including deployment listing) represents the current state of the domain, and server managers (SM) sync this down, why not make it a versioned database? Then, if a SM comes up after some changes were made on the domain controller (DC), the SM can pull down only the differences, just like database replication. This is good in the case of a very complex configuration with many deployments (the SM only has to pull down deployments that it needs [as defined by the domain.xml] *and* that it doesn't already have). It may also allow something like atomic deployment, where multiple deployment units *and/or* config changes are deployed as a single unit. Also, the coolest thing of all would be the ability to *revert* the whole domain to arbitrary previous states, by simply playing the log backwards.
If the differences prove too great (either in size or in age) to pull in diffs, then the whole state can always be pulled down into the SM.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/545361#545361]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Re: [jboss-dev-forums] [Management Development] - domain.xml work
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"domain.xml work"
To view the discussion, visit: http://community.jboss.org/message/545360#545360
--------------------------------------------------------------
> Scott Stark wrote:
>
> Some initial work on a collection of xml schema files to codify the notion of the domain metadata model have been uploaded here:
> http://community.jboss.org/wiki/JBossASDomainSchema http://community.jboss.org/wiki/JBossASDomainSchema
>
> I followed our http://community.jboss.org/wiki/DomainManagementModelDesign http://community.jboss.org/wiki/DomainManagementModelDesign for the structure and incorporated some of our existing schemas as a starting point to see how well these would pull together since the domain metadata ultimately needs to map onto this view where it exists.
>
> In general, the imported schemas expose too much detail, and there need to be better cross cutting configuration notions for common services such as security, threads, pools, remoting, logging, etc. We need alternate domain admin views similar to what I did with the profiles where it is very much simplified and only focused on the requirements the admin is looking for. There is no notion of deployments at this level.
>
> Of course there is a ton of configuration data to add for the various containers as well.
>
> I'm handing this off to Alexey, so good luck!
Getting more specific, this raises some questions.
The defined requirements around the domain.xml file are all very vague/general, for example "represents the primary and authoritative representation of the domain" [1] or "focused on the requirements the admin is looking for". I think it's time that we start getting specific about what the domain.xml needs to be, not just in terms of example schemas or in terms of broad strokes but in detail.
If the domain.xml does, indeed, contain the authoritative representation of the domain, then it does indeed need to contain, directly or indirectly, definitions of all serivces available up to *and including* the list of active deployments. For example, as defined in the existing requirements, a deployment can be associated with one or more server groups, which are defined as part of the domain. If the domain doesn't map deployments to server groups, what will? In addition, adding deployments can very well imply other changes to domain.xml that are necessarily made at the same time. Everything I see in the requirements says to me that the current deployment listing must be a part of the domain model.
So if you take that as a given, then the question isn't about too much detail in the domain model (which ultimately has to contain every detail, regardless of its relative relevance), it's more about too much detail in the *domain.xml file* itself, and how can we hide some of the less-likely-to-be-useful detail without crippling the administrators *or* us poor implementors.
For example, today the thread pool configuration is highly granular. Many of the things can have reasonable defaults; for example rather than specifying the thread factory for every thread pool, and the thread group for every thread factory, etc. we can have a default thread factory and group, or auto-create one with reasonable parameters which can be overridden in the case where the admin needs finer-grained control. Many of the quirks of jboss-threads in particular are due to JBossXB and MC, and just following the path of least resistance.
It might be helpful to break it down into categories, and for each category, formalize how it should be represented in the management view versus the domain.xml file.
[1] http://community.jboss.org/wiki/DomainRequirements http://community.jboss.org/wiki/DomainRequirements
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/545360#545360]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months