Bug 1050014 - Cannot deploy bundle to EAP domain mode

Lukas Krejci lkrejci at redhat.com
Tue Jun 10 13:04:29 UTC 2014


On Tuesday, June 10, 2014 08:57:43 John Mazzitelli wrote:
> What about a third option :)
> 
> Could we add new ANT tasks the bundle writer can use? We'd write ANT tasks
> that can talk to EAP over the CLI (using http perhaps, or ModelController)
> so the recipe can have ANT tasks in the post-deploy target? So they could
> write in the recipe something like <eap-deploy ....>
> 
> Just a thought. This would be limited to an EAP only solution, which is a
> con.
>

You would have to find a way of passing configuration to such task so that it 
can connect to the EAP instance. In PR#39 I add such possibility using 
explicit markup in the plugin descriptor. In your case though, I think having 
the configuration available would have to be on-demand of the bundle handler 
if it finds it needs one when it parses the recipe file.

And as you said, this would be a task limited only to EAP but I think it'd 
have to be included in the generic tasks jar we have, creating an ugly 
coupling between an ant task available to any ant bundle and 1 resource type 
from 1 particular plugin.
 
> ----- Original Message -----
> 
> > Hi everyone,
> > 
> > I'm writing to talk about a feature request: Bug 1050014 - Cannot deploy
> > bundle to EAP domain mode [1]
> > 
> > The problem is that the ANT and FileTemplate bundle types are file
> > based, and domain deployments are only possible through the management
> > API or the EAP CLI.
> > 
> > The requirements of this RFE are as follows:
> > * being able to deploy an application archive to a domain controller
> > * being able to execute EAP CLI scripts
> > * the implementation should work with standalone servers
> > 
> > The solution should take into account that we are also trying to solve
> > the EAP patching problem (see Bug 1069547 - Support EAP 6.2/6.3 style
> > patching [2] and PR39 on GitHub [3]).
> > 
> > We discussed the RFE with Lukas and Jay some time ago but I wasn't able
> > to write up the conclusions until now. So here it goes.
> > 
> > 
> > 
> > 
> > 
> > 
> > 1. Extend ANT bundle type to communicate with resource components
> > 
> > Resource component would implement a new facet (name to be defined), and
> > the methods of this facet would let the user pass some content. The
> > resource component would do whatever it needs to and the bundle agent
> > plugin wouldn't try to lay down this content on the system.
> > 
> > Here's how an ANT bundle would look like:
> > 
> > <rhq:deployment-unit name="xxxxxx">
> > 
> >   <rhq:file name="myapp.war" handover="deploy"/>
> >   <rhq:file name="myscript.cli" handover="executeCLI"/>
> > 
> > </rhq:deployment-unit>
> > 
> > or
> > 
> > <rhq:deployment-unit name="xxxxxx">
> > 
> >   <rhq:file name="patch-eap-6.xxx" handover="patch"/>
> > 
> > </rhq:deployment-unit>
> > 
> > 
> > See? The key here is the new "handover" attribute that users could add
> > to rhq:file, rhq:url-file, rhq:archive and rhq:url-archive.
> > 
> > Pros:
> > * General purpose solution, could be applied to EAP patching as well
> > 
> > Cons:
> > * For patching, a recipe and bundle file would have to be created
> > instead of just the patch zip file
> > 
> > 
> > 
> > 
> > 
> > 
> > 2. Create a new bundle type
> > 
> > This is what Lukas started when he wrote his pull request for EAP
> > patching  support
> > 
> > Pros:
> > * The concept is already proven by PR39
> > 
> > Cons:
> > * Yet another bundle type, and only applicable to a specific resource type
> > * Less powerful than an ANT bundle: users will be able to deploy apps
> > and execute CLI scripts but nothing else
> > 
> > 
> > 
> > 
> > 
> > 
> > We'd be very happy to hear from you on this topic. Which solution do you
> > prefer? Hopefully you don't find both solutions ugly...
> > 
> > Regards,
> > Thomas
> > 
> > 
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1050014
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1069547
> > [3] https://github.com/rhq-project/rhq/pull/39
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list