Bill Shannon wrote:
> 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?
yes there is part of the plan that Byron discussed during the V3 design
reviews. I don't think we have completed the work but this should be the
prefered way for the plugin to start GlassFish (assuming we make the
started process handle available through APIs).
>
> 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... :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>