PersistenceDeployer WAS Re: [jboss-dev] Deployment chains

[Carlo de Wolf]

Adrian Brock wrote:
> On Fri, 2008-10-03 at 16:42 +0200, Adrian Brock wrote:
>   
>> 5+) There could be others. Like I said this is just a quick scan.
>>     
>
> 5) JPA Deployer
>
> The PersistenceDeployer needs to specify that its output is
> PersistenceUnitMetaData.
>
> That is unless we change or extend the DeploymentVisitor 
> interface to let it specify an optional output and do it automatically
> in setDeploymentVisitor().
>
> But more importantly...
>
> I don't understand why this isn't setting the ComponentVisitor
> which would do that without you having to think about it?
>   
That because I don't understand why we should set one. :-)

What is AbstractComponentDeployer?

For the EJB3 Embeddable deployers I've switched back to 
AbstractRealDeployerWithInput.
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/src/main/java/org/jboss/ejb3/embedded/deployers/

What I don't want to see (yet) is having both the module deployer and 
component deployer in one class. That maybe a nice optimization, but I 
first want to know what's going on.
> It is commented out, so some problem must have been encountered?
>   
I couldn't get the ComponentVisitor to fire off in any test scenario, so 
I commented it. :-P
>    public PersistenceDeployer()
>    {
>       //setComponentVisitor(new PersistenceUnitDeploymentVisitor());
>       setDeploymentVisitor(new PersistenceDeploymentVisitor());
>    }
>
> Instead there is a class in the jpa project called
> AbstractDeploymentVisitor which looks like it should be
> in the deployer project and really called
> AbstractComponentVisitor?
>   
Yes, that was the plan. This is the precursor for that class. I dropped 
the ball there.
And no, it's an AbstractDeploymentVisitor because it's an implementation 
on DeploymentVisitor meant for setDeploymentVisitor. The fact that 
setComponentVisitor takes the 'same' thing is another mind boggler to 
me. If we're doing an AbstractComponentVisitor it shouldn't have 
getComponents, but getComponent.
> Finally, shouldn't there be a way for somebody to create
> a PersistenceUnitDeployment that doesn't come from
> a PersistenceDeployment?
> i.e. like you can create a ServiceMetaData or BeanMetaData
> from any other deployer.
>
> Currently this can only be done if you wrap it in a
> PersistenceDeployment which looks incredibly ugly to me
> and certainly isn't compatible with the Profile Service
> persisting overrides to it somewhere.
>   
I don't see why there should be a way, but I'm as creative as a piece of 
rock. ;-)

There shouldn't be any problem to have that function. Scoping needs to 
be taken into account. And maybe the resolver needs a change.

So correct me if I'm wrong: the AbstractComponentDeployer creates the MC 
component and stuffs the component meta data into it. Then the 
PersistenceUnitDeployer still creates the JavaEE component? (I feel a 
javadoc moment coming. :-) )

Carlo