DConfigBean Confusion

[David Jencks <da...@yahoo.com>]

I'm trying to straighten out some classpath problems with the  
deployment code and dconfigbeans and am pretty confused about some of  
the code.

The main thing I'm confused about is that in the geronimo-connector- 
builder module there seem to be two partial sets of DConfigBeans, in  
dconfigbean and in jsr88.  There's some overlap... and a bunch of big  
differences.  It looks to me as if the console is using the stuff in  
jsr88 to build connector plans.

Does anyone know what is going on here and which is more correct?   
Does the connector 1.0 stuff in dconfigbean work?  I think we should  
try to get all these consistent and in one directory.  It would also  
be great to have the console support deploying connector 1.0 rars....  
there's at least one (jaybird) that is only available as a 1.0  
connector.

---------------------

There's another longstanding problem with dconfigbeans which is that  
they've never been able to work from any reasonable standalone  
situation, such as the spec scenario where you get them from a  
DeploymentManager.createConfiguration call since you'd need a large  
fraction of the geronimo server on the classpath to make it work.  I  
think that any solution for this is going to have to use the geronimo  
repository since thats where the zillion jars needed are and are  
likely to stay.  So, I think we have to start a kernel and load a  
configuration and have the Configurers register  with something that  
the DeploymentManagers can get at.

Anyone have a better idea?

thanks
david jencks

Re: DConfigBean Confusion

[Tim McConnell <ti...@gmail.com>]

Hi David, I spent a lot of time looking at all the various module and configuration builders when I 
was getting Sachin's new deployable module interface to work with the Release 1.1.1 source code. I 
ran into similar problems and/or questions with many of the builders because it is so difficult to 
figure out who is doing what when and why. The best way that I could figure out what was going on 
during runtime was to capture JProbe traces for many of the deployment scenarios and look through 
the call traces (our logging/trace capability should really provide this level of information, but 
unfortunately it does not). I saved some of them and an example snapshot is attached if you are 
interested (you can see that ConnectorModuleBuilder is getting invoked numerous times I believe by 
the FastMethodInvoker.invoke() method). That really doesn't help answer your first question (other 
than the fact that it's getting invoked--whether it's working correctly is another story) but if 
you'd like for me to get some new snapshots for some new console and CLI deployment scenarios I'd be 
glad to and it might help clear up some of this confusion. I know it was very confusing for me to 
look through the code and attempt to figure it out. Thanks
Tim

David Jencks wrote:
> I'm trying to straighten out some classpath problems with the deployment 
> code and dconfigbeans and am pretty confused about some of the code.
> 
> The main thing I'm confused about is that in the 
> geronimo-connector-builder module there seem to be two partial sets of 
> DConfigBeans, in dconfigbean and in jsr88.  There's some overlap... and 
> a bunch of big differences.  It looks to me as if the console is using 
> the stuff in jsr88 to build connector plans.
> 
> Does anyone know what is going on here and which is more correct?  Does 
> the connector 1.0 stuff in dconfigbean work?  I think we should try to 
> get all these consistent and in one directory.  It would also be great 
> to have the console support deploying connector 1.0 rars.... there's at 
> least one (jaybird) that is only available as a 1.0 connector.
> 
> ---------------------
> 
> There's another longstanding problem with dconfigbeans which is that 
> they've never been able to work from any reasonable standalone 
> situation, such as the spec scenario where you get them from a 
> DeploymentManager.createConfiguration call since you'd need a large 
> fraction of the geronimo server on the classpath to make it work.  I 
> think that any solution for this is going to have to use the geronimo 
> repository since thats where the zillion jars needed are and are likely 
> to stay.  So, I think we have to start a kernel and load a configuration 
> and have the Configurers register  with something that the 
> DeploymentManagers can get at.
> 
> Anyone have a better idea?
> 
> thanks
> david jencks
> 
>