-
1. Re: JBDEPLOY-3 issues
alesj Mar 12, 2008 8:32 AM (in response to alesj)Regarding this:
- http://jira.jboss.com/jira/browse/JBDEPLOY-10
What kind of annotations should we scan for?
I currently just ported what is already in the real EARStructure (in AS5_trunk), which is just recognizing ear's children.
With annotation scanning, I really think we should do this in generic fashion, once for all utils/frameworks that depend on annotation existence - e.g. EJB3, Seam, ...
Providing the hooks for them to plug-in into our generic solution and get pre-scanned results. Or making this lazy, and let them trigger the initial scanning. -
2. Re: JBDEPLOY-3 issues
adrian.brock Mar 12, 2008 9:08 AM (in response to alesj)"alesj" wrote:
JBMICROCONT-185 is the old version of JBDEPLOY-3.
What's to do with the DeployerProtocolUnitTestCase's TODO?
If I uncomment the code, the test still works.
I guess this is the relevant discussion:
- http://www.jboss.com/?module=bb&op=viewtopic&t=123258
New JIRA for types removal?
The types should be somewhere in the Managed* api not the deployment api.
Especially since I don't want people doing hacky things in the deployers
based on getTypes() ;-) -
3. Re: JBDEPLOY-3 issues
adrian.brock Mar 12, 2008 9:09 AM (in response to alesj)"alesj" wrote:
Regarding this:
- http://jira.jboss.com/jira/browse/JBDEPLOY-10
What kind of annotations should we scan for?
I currently just ported what is already in the real EARStructure (in AS5_trunk), which is just recognizing ear's children.
With annotation scanning, I really think we should do this in generic fashion, once for all utils/frameworks that depend on annotation existence - e.g. EJB3, Seam, ...
Providing the hooks for them to plug-in into our generic solution and get pre-scanned results. Or making this lazy, and let them trigger the initial scanning.
Yes the deployers should provide a mechanism where relevant other deployers
can take part in a single annotation scan (or avoid the scan althogether
if everybody agrees the deployment is 'metadata" complete).
But create a different thread for different issues. -
4. Re: JBDEPLOY-3 issues
alesj Mar 12, 2008 9:12 AM (in response to alesj)"adrian@jboss.org" wrote:
The types should be somewhere in the Managed* api not the deployment api.
Especially since I don't want people doing hacky things in the deployers
based on getTypes() ;-)
OK, I'll go ahead and remove them from deployers.
And then discuss it with Scott where in Managed* he wants them. -
5. Re: JBDEPLOY-3 issues
alesj Mar 12, 2008 9:13 AM (in response to alesj)"adrian@jboss.org" wrote:
But create a different thread for different issues.
This is just the initial teaser, to see if the discussion spins off. :-) -
6. Re: JBDEPLOY-3 issues
alesj Mar 13, 2008 5:32 AM (in response to alesj)"alesj" wrote:
OK, I'll go ahead and remove them from deployers.
I removed it from Deployment(Unit|Context), but I still left Deployer::getType, since I guess that is what Scott will still need to hook up with Managed* api. -
7. Re: JBDEPLOY-3 issues
starksm64 Mar 13, 2008 5:51 AM (in response to alesj)Implementations of org.jboss.profileservice.spi.DeploymentRepository.getDeploymentNamesForType are looking to the VFSDeployment.getType, not Deployer.getType. There are some deployer beans.xml that are setting the type property, so they would need to be updated to remove Deployer.getType.
The org.jboss.managed.api.ManagedDeployment has a types notion, so support will have to be based on that. -
8. Re: JBDEPLOY-3 issues
alesj Mar 13, 2008 5:59 AM (in response to alesj)"scott.stark@jboss.org" wrote:
Implementations of org.jboss.profileservice.spi.DeploymentRepository.getDeploymentNamesForType are looking to the VFSDeployment.getType, not Deployer.getType.
Sure, but that's exactly what was asked to be removed.
The Deployment(Unit|Context) shouldn't have the types."scott.stark@jboss.org" wrote:
There are some deployer beans.xml that are setting the type property, so they would need to be updated to remove Deployer.getType.
So, you're saying you wont be needing Deployer::getType?"scott.stark@jboss.org" wrote:
The org.jboss.managed.api.ManagedDeployment has a types notion, so support will have to be based on that.
Yup, but I thought this would use Deployer::getType to build the ManagedDeployment with the right types. -
9. Re: JBDEPLOY-3 issues
starksm64 Mar 13, 2008 6:08 AM (in response to alesj)No, the org.jboss.deployers.spi.deployer.managed.ManagedDeploymentCreator relies on DeploymentUnit or the unit ManagedObject set:
public interface ManagedDeploymentCreator { /** * Build up the deployment management view. * @param unit - the deployment unit to process * @param md - the unit ManagedDeployment */ public ManagedDeployment build(DeploymentUnit unit, Map<String, ManagedObject> unitMOs, ManagedDeployment parent); }
If type is not part of DeploymentUnit, then a ManagementDeployment annotation would have to be added to use with the ManagedObjects. -
10. Re: JBDEPLOY-3 issues
adrian.brock Mar 13, 2008 9:18 AM (in response to alesj)"scott.stark@jboss.org" wrote:
If type is not part of DeploymentUnit, then a ManagementDeployment annotation would have to be added to use with the ManagedObjects.
That's what we agreed before isn't it?
The "type" is a notion used by the management layer for grouping,
it has no use in the deployers and is even probably difficult to
set effectively in some usecases. -
11. Re: JBDEPLOY-3 issues
alesj Mar 13, 2008 10:50 AM (in response to alesj)"adrian@jboss.org" wrote:
The "type" is a notion used by the management layer for grouping,
it has no use in the deployers and is even probably difficult to
set effectively in some usecases.
Drop it out of deployers then as well? -
-
13. Re: JBDEPLOY-3 issues
alesj Mar 14, 2008 6:47 AM (in response to alesj)"alesj" wrote:
Drop it out of deployers then as well?
This was removed.
A fair warning: all AS5 deployers that define type should get that removed from xml, since setType is not longer there ;-)
e.g. from bootstrap-beans.xml<bean name="BeanDeployer" class="org.jboss.deployers.vfs.deployer.kernel.BeanDeployer"> <!--<property name="type">beans</property>--> </bean>
-
14. Re: JBDEPLOY-3 issues
adrian.brock Mar 14, 2008 8:11 AM (in response to alesj)Can you put setType() back please, but re-implement it like this:
@Deprecated public void setType(...) { log.warn("Types should be set using <mechanism here/> for " + this); }
That is unless you want to go through all the deployers that exist
to get jboss-head to compile/boot. :-)