Enterpriser Server Jar Naming - Fix

Stefan Negrea snegrea at redhat.com
Thu Jul 18 19:14:18 UTC 2013


Hello Everybody,

Glad to see that my email started an avalanche of emails; naming stuff is always a controversial topic :D 

Here is the summary of the thread so far against the initial proposal:

1) Change the server startup module name to rhq-server-startup
  - three clear yes votes (Jay, John Sanda, Heiko)


2) Leave the server jar module name as is rhq-enterprise-server
  - two clear yes votes (Jay and John Sanda)
  - one clear no vote (Heiko) - the concern here is the length of the name
  
* This is only proposal I am still unclear if we reached consensus. On one hand keeping this artifact name avoids confusion and make clear the purpose of the module. But there were some concerns about the length of the name even if the old post fix "-ejb3" will be dropped. So I am unclear if there is another naming proposal and how to proceed.  Please refer to my initial email for my arguments to keep the current artifact name.


3) Use the artifact names unchanged as the deployment names in the ear, dev container, and any other place.
  - two clear yes votes (Jay and John Sanda)


The thread was popular today but that I could not count more responses as clear yes or no. So I will wait a few more days for more feedback before proceeding. I hope I did not make mistakes counting the votes. If I did please reply and will be glad to correct the counts :)


Thank you,
Stefan Negrea



----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Thursday, July 18, 2013 10:25:39 AM
> Subject: Re: Enterpriser Server Jar Naming - Fix
> 
> > We could also move the ear to $RHQSERVER/rhq-deploy/ and tell the
> > deplyoment
> > scanner while installing to also scan that directory.
> > This should also help a lot with the length of paths.
> > Also all those rhq-downloads could also be put next to the rhq.ear
> > 
> > I mean now is a good point in time for such changes
> 
> I also want to be clear - since you used the term "deployment scanner" - we
> are explicitly not using the JBossAS deployment scanner mechanism to deploy
> the rhq.ear. We did this as per Brian Stansberry's recommendations (for a
> couple reasons).
> 
> In fact, this startup module code originated from a prototype written by
> Brian. This startup module is all about deploying the ear without going
> through the hot-deployment mechanism of the AS deployment scanner (i.e.
> putting ears and wars in the JBossAS's /deployments directory). Actually,
> our installer disables the deployment scanner - so no one can hot deploy
> anything in an RHQ Server.
> 
> As to why it is under the modules/ directory and not under, say,
> $RHQSERVER/rhq-deploy or whatever - it is because the startup extension uses
> the AS7 extension API to find the rhq.ear directory (similar to how
> ClassLoader.findResources() finds things in a classpath, AS7 has an API to
> find things under a particular module location - see
> org.rhq.enterprise.startup.StartupSubsystemAdd.populateModule and its use of
> PathAddress.pathAddress() and Module.getExportedResource()).
> 
> Not only that but in addition, having it under the module/ main directory
> makes it patchable using the new patch mechanism that will be introduced and
> used in future versions of EAP (this, again, is per Brian's recommendation).
> Moving it outside of that will probably make our stuff unpatchable using the
> new patch mechanism that will be coming in the future.
> 
> So, as you can see, I didn't just throw this stuff together arbitrarily
> without any thought put into it :-) There are reasons why the ear is where
> it is and why this startup module exists in the first place.
> _______________________________________________
> 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