Peter Williams wrote:
>
>
> Bill Shannon wrote:
>> Peter Williams wrote:
>>> The NetBeans plugin MUST have the process handle of the server
>>> process to manage it properly. This is simply not obtainable when
>>> starting the server via the asadmin command.
>>>
>>> I am quite happy to accept that in return for requirement, our plugin
>>> must take over launcher duties and properly interpret domain.xml to
>>> ensure the server is started correctly. The current V3 NetBeans
>>> plugin does this.
>>>
>>> The benefits of having the Java Process object for the server process
>>> more than outweigh the cost of writing a few lines of code to read
>>> XML and substitute a few variables.
>>
>> If NetBeans needs to do this, please tell me that it's using a
>> GlassFish-defined class to do this work. I think it's a bad idea
>> to duplicate the code that processes domain.xml and decides how to
>> launch the JVM for GlassFish into NetBeans.
> Philosophically speaking, I agree. In practice, the code is separate.
> I originally looked into code sharing in this area and have discussed it
> with Byron, but the GlassFish implementation requires a STAX parser.
> Not a big deal for GlassFish since the server ships with it. However,
> NetBeans does not have STAX available (maybe in the web service module,
> but we cannot have a dependency on that code) and this makes proper
> classloading of dynamically located shared code problematic.
>
> I have read through Byron's launcher code to ensure the result is as
> equivalent as possible. For development purposes, it has proven quite
> durable. It is not recommended that people use the IDE to launch
> production servers so from that perspective, this should not be a problem.
I guess I don't understand the constraints.
If you're starting a local version of GlassFish, don't you have access to
all the GlassFish classes you might need? Can't you find and load a
GlassFish library containing the launcher, and its dependencies?
I'm only slightly concerned about reading the domain.xml file to find
the port number; as others have said it's pretty close to a public
interface already. I was more concerned about the "substituting a
few variables" part. Getting that to behave exactly the same way it
does in the GlassFish code could be more problematic.
Just trying to bridge the gap between what we know is the right thing
to do and what we actually do... :-)