Jerome Dochez wrote:
> 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?
Hum...
We are talking about the NetBeans plugin code which is in the NetBeans
mercurial repository, that needs to be built and shipped in the NetBeans
product (with or without GlassFish)...Currently, to use NB external
APIs, those APIs have to be reviewed (OSR), and integrated into the Nb
hg repo (no dynamic maven download).
So the shared implementation of the domain parsing code should become
1/ an api
2/ provided in a jar in a published/maintained repository
3/ OSR reviewed and approved to be used by NetBeans
4/ integrated inside the Nb product build process (Or Eclipse GlassFish
Plugin, etc)
The API could just be interfaces, and the impl would be taken from the
GlassFish bits themselve, but the Nb build process would need these
interfaces
Ludo
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>