2.0.0-beta7 release

[adrian.brock]

I want to do a 2.0.0-beta7 release today (or over the weekend).

Speak now if you think I shouldn't or if you have something that needs to go in it.

I moved all the closed issues from CR1 into this release in JIRA.

[alesj]

I have some things that I didn't commit yet, but they can wait. :-)

My only concern regarding beta7 release is this issue:
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=124324

This one probably needs EJB resolution and not MC:
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=124292
And as such requires current changes/fixes to the deloyers.

[adrian.brock]

"alesj" wrote:
I have some things that I didn't commit yet, but they can wait. :-)

Are they changes required for JBossAS beta3?

[alesj]

Are they changes required for JBossAS beta3?

No.
I was waiting for some reply from the POJO forum.
And as such continued/started working on JBMICROCONT-217, 219, 220.

I also looked at the http://jira.jboss.com/jira/browse/JBMICROCONT-184, which seems to be better candidate for earlier inclusion into JBossAS.
But would need some guidance, specially with the current metadata rewrite, and how merging is/should be handled ...

[adrian.brock]

"alesj" wrote:

I also looked at the http://jira.jboss.com/jira/browse/JBMICROCONT-184, which seems to be better candidate for earlier inclusion into JBossAS.
But would need some guidance, specially with the current metadata rewrite, and how merging is/should be handled ...

That's to tidyup the stupid way the ejb-jar.xml and jboss.xml (and equivalents
for ears and wars) are parsed.

1) They're in seperate parsing deployers which isn't going to work
properly when you have predefined metadata. The hack Scott put in
will always reparse jboss.xml

2) Some of the behaviour (like the merging and initialization) shouldn't be in there.
Again, won't work properly with the profile service.

Related to those mistakes, I noticed somebody re-introduced
the hack of overridding createMetaData() again.
I've got a good mind to make that method final. Then people can't
keep doing it wrong. :-)

What it should do is parse the two together in one parsing deployer
but only if there is no metadata already preinstantiated.

The initialization like pulling out the loaderRepositoryConfig and "wrapping"
with standardjboss.xml should be in a seperate deployer since they are
done regardless of whether you are given metadata or you parse it.

I don't think this needs doing for beta3. It's just implementation detail
to make programmatic deployment work.

[starksm64]

"alesj" wrote:

I also looked at the http://jira.jboss.com/jira/browse/JBMICROCONT-184, which seems to be better candidate for earlier inclusion into JBossAS.
But would need some guidance, specially with the current metadata rewrite, and how merging is/should be handled ...

That's to tidyup the stupid way the ejb-jar.xml and jboss.xml (and equivalents
for ears and wars) are parsed.

1) They're in seperate parsing deployers which isn't going to work
properly when you have predefined metadata. The hack Scott put in
will always reparse jboss.xml

The reparse option should not be needed for any parsing deployer with the metadata rewrite because the metadata has one to one representations with the descriptors, and merged views into the jboss metadata. For cases where multiple descriptors are merged like standardjboss.xml, jboss.xml, there are wrapping proxy classes that combine the two views.

[alesj]

This is the change I was talking about (AbstractRealDeployer):

 public final void deploy(DeploymentUnit unit) throws DeploymentException
 {
 internalDeploy(unit);

 if (isControllerContextNameCandidate(unit))
 {
 addControllerContextName(unit);
 }
 }

 /**
 * Should we set controller context name on unit?
 *
 * @param unit the dpeloyment unit
 * @return true if we should use unit's name as controller context name
 */
 protected boolean isControllerContextNameCandidate(DeploymentUnit unit)
 {
 return useUnitName && unit.isComponent();
 }

 /**
 * Deploy a deployment
 *
 * @param unit the unit
 * @throws DeploymentException for any error
 */
 protected abstract void internalDeploy(DeploymentUnit unit) throws DeploymentException;

 /**
 * Add controller context name.
 *
 * @param unit the deployment unit
 */
 protected void addControllerContextName(DeploymentUnit unit)
 {
 unit.addControllerContextName(unit.getName());
 }

 /**
 * Remove controller context name.
 *
 * @param unit the deployment unit
 */
 protected void removeControllerContextName(DeploymentUnit unit)
 {
 unit.removeControllerContextName(unit.getName());
 }

 public final void undeploy(DeploymentUnit unit)
 {
 try
 {
 if (isControllerContextNameCandidate(unit))
 {
 removeControllerContextName(unit);
 }
 }
 catch (Throwable t)
 {
 if (log.isTraceEnabled())
 log.trace("Exception while removing unit name: " + t);
 }

 internalUndeploy(unit);
 }

 /**
 * Undeploy an deployment
 *
 * @param unit the unit
 */
 protected void internalUndeploy(DeploymentUnit unit)
 {
 // nothing
 }

 /**
 * Should we use unit name for controller context name.
 *
 * @return true if usage is allowed
 */
 public boolean isUseUnitName()
 {
 return useUnitName;
 }

 /**
 * Set use unit name for controller context name.
 *
 * @param useUnitName flag to allow unit name usage
 */
 public void setUseUnitName(boolean useUnitName)
 {
 this.useUnitName = useUnitName;
 }

Since I want to explicitly force this name registration on the real deployers - hence making the deploy/undeploy methods final.

[adrian.brock]

I couldn't do the maven release because of this issue:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107488#4107488

I've tagged it in svn and released it manually in the old repository for the appserver.