DRDAServerStarter

[Jeremy Boynes <jb...@apache.org>]

The NetworkServerControlImpl starts its server using a DRDAServerStarter 
which constructs a NetworkServerControlImpl via reflection. The 
DRDAServerStarter is in the engine tree, the NetworkServerControlImpl is 
in the drda tree.

Can someone please give a little historical background here.

What problems will we see if we simplify this so that all the network 
server code is located in the drda tree?

--
Jeremy

Re: DRDAServerStarter

[Kathey Marsden <km...@sbcglobal.net>]

Jeremy Boynes wrote:

> Kathey Marsden wrote:
>
>> DRDAServerStarter  is there in support of the
>> derby.drda.startNetworkServer property, an easy way to embed network
>> server in your application when you start Derby.   
>
>
> Given the drda code needs to be there for this to work, can we just
> move this functionality into the drda module (and hence derbynet)?
>
I am not sure of the issues with moving it.  I wonder, for instance, 
would you still get reasonable error messages in the log if you set that
property and derbynet.jar wasn't in your classpath?    I am sure we
don't test for that because the DerbyNetAutoStart test depends on the
network server classes being in the classpath.   That said, it sounds OK
to  me if you want to move things around as long as it all still works #:)

> If I understand this correctly, there are two ways to start the
> network server:
> 1) create a NetworkServerControl with complete(*) control via code
> 2) use the properties and have it started by the monitor
>
That is correct.

Kathey

Re: DRDAServerStarter

[Kathey Marsden <km...@sbcglobal.net>]

Jeremy Boynes wrote:

> Kathey Marsden wrote:
>
>> Jeremy Boynes wrote:
>>
>>
>>> I think we get the equivalent behaviour by having the Monitor load the
>>> NetworkServerControlImpl directly; alternatively we could have
>>> JDBCBoot start it up explicitly.
>>
>
> That's not the intent - it would be through reflection through
> suitable definitions in modules.properties.
>
> What I am trying to avoid is NSCI calling DSS which then creates its
> another NSCI via reflection.
>
Yes, I misunderstood. I thought by "directly", you were saying not by
reflection.  Then  as long as  it all behaves properly and  gives
informative error messages if derbynet.jar is not there, sounds fine to me.

Kathey

Re: DRDAServerStarter

[Jeremy Boynes <jb...@apache.org>]

Kathey Marsden wrote:
> Jeremy Boynes wrote:
> 
> 
>>I think we get the equivalent behaviour by having the Monitor load the
>>NetworkServerControlImpl directly; alternatively we could have
>>JDBCBoot start it up explicitly.
>>
> 
> I might be misunderstanding what you are proposing, but wouldn't this
> cause the NetworkServerControlImpl and its dependencies to get pulled
> into derby.jar?
> 

That's not the intent - it would be through reflection through suitable 
definitions in modules.properties.

What I am trying to avoid is NSCI calling DSS which then creates its 
another NSCI via reflection.

If we go down the modules route as suggested by David then I thin we see 
a network-server module (aka. drda) with a dependency on the engine but 
not the other way around.

--
Jeremy

Re: DRDAServerStarter

[Kathey Marsden <km...@sbcglobal.net>]

Jeremy Boynes wrote:

>
> I think we get the equivalent behaviour by having the Monitor load the
> NetworkServerControlImpl directly; alternatively we could have
> JDBCBoot start it up explicitly.
>
I might be misunderstanding what you are proposing, but wouldn't this
cause the NetworkServerControlImpl and its dependencies to get pulled
into derby.jar?

Kathey

Re: DRDAServerStarter

[Jeremy Boynes <jb...@apache.org>]

Daniel John Debrunner wrote:
>>
>>Given the drda code needs to be there for this to work, can we just move
>>this functionality into the drda module (and hence derbynet)?
> 
> 
> Some code is needed in the engine to look at the property and decide if
> to boot the network server. I thought DRDAServerStarter was that code,
> hence it would need to be in the engine.
> 
> Or is there some way that it could be in the network server jar but
> still invoked automatically when the engine boots?
> 

AIUI DRDAServerStarter implements ModuleControl which allows it to be 
loaded and started based on info in modules.properties. The lifecyle is 
something like:
* construct service using no-arg constructor
* invoke boot()
* service initializes itself

The classname is defined in modules.properties but there is nothing that 
sets up a classpath so I would assume the class named needs to be 
available via the engine's classloader or the TCCL.

The implementation of DRDAServerStarter loads the serverClassName 
(hardcoded to NetworkServerControlImpl) using Class.forName() and then 
instantiates it and invokes it via reflection.

I think we get the equivalent behaviour by having the Monitor load the 
NetworkServerControlImpl directly; alternatively we could have JDBCBoot 
start it up explicitly.

--
Jeremy

Re: DRDAServerStarter

[Daniel John Debrunner <dj...@debrunners.com>]

Jeremy Boynes wrote:

> Kathey Marsden wrote:
> 
>> DRDAServerStarter  is there in support of the
>> derby.drda.startNetworkServer property, an easy way to embed network
>> server in your application when you start Derby.   
> 
> 
> Given the drda code needs to be there for this to work, can we just move
> this functionality into the drda module (and hence derbynet)?

Some code is needed in the engine to look at the property and decide if
to boot the network server. I thought DRDAServerStarter was that code,
hence it would need to be in the engine.

Or is there some way that it could be in the network server jar but
still invoked automatically when the engine boots?

Dan.

Re: DRDAServerStarter

[Jeremy Boynes <jb...@apache.org>]

Kathey Marsden wrote:
> DRDAServerStarter  is there in support of the
> derby.drda.startNetworkServer property, an easy way to embed network
> server in your application when you start Derby.   

Given the drda code needs to be there for this to work, can we just move 
this functionality into the drda module (and hence derbynet)?

If I understand this correctly, there are two ways to start the network 
server:
1) create a NetworkServerControl with complete(*) control via code
2) use the properties and have it started by the monitor

--
Jeremy

(*) almost complete control - the DRDAServerStarter needs access to
     the constructors for NetworkServerControlImpl and selects one
     depending on whether the InetAddress is null or not

Re: DRDAServerStarter

[Kathey Marsden <km...@sbcglobal.net>]

Jeremy Boynes wrote:

> The NetworkServerControlImpl starts its server using a
> DRDAServerStarter which constructs a NetworkServerControlImpl via
> reflection. The DRDAServerStarter is in the engine tree, the
> NetworkServerControlImpl is in the drda tree.
>
> Can someone please give a little historical background here.
>
> What problems will we see if we simplify this so that all the network
> server code is located in the drda tree?

DRDAServerStarter  is there in support of the
derby.drda.startNetworkServer property, an easy way to embed network
server in your application when you start Derby.   It just starts
network server in another thread.   It needs to be in the engine code so
that  it is processed when you start Derby. Reflection is needed so
there is no dependency on the derbynet.jar in the build.

http://db.apache.org/derby/docs/10.1/adminguide/radminconfigstartnetworkserver.html

The NetworkServerControl start api could launch it's own thread and
start network server without using DRDAServerStarter,  but just reuses
DRDAServerStarter since it is there.

Kathey