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?
>
> 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 actually think reading the http, ssl, and admin port numbers correctly
is more difficult than locating and patching the JVM config options.
The parsing code I wrote is quite flexible so if the rules on how to
locate this information changed, it ought to require only a minor update
to fix.
> 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.
I'm not sure what you mean unless it's ensuring we have the same
definitions for the variables.
The list so far is merely
${com.sun.aas.javaRoot}
${com.sun.aas.installRoot}
${com.sun.aas.derbyRoot}
${path.separator}
which are all well defined. If the user adds additional fields the
plugin does not recognize, there is a way to provide that information to
the plugin so things still work correctly. A single method is
responsible for handling arbitrary substitutions on each config
parameter and is easily unit tested.
I'm not averse to an API (e.g. the interface based pattern suggested
later in this subthread) though it will be a more overhead and I
honestly wonder if the cost of maintaining it is worth the problem being
solved. We will have to design it. It will have to be tested against
at least two platforms (launcher and NetBeans). If it needs to be
changed between versions (and it will), there is a compatibility issue
of old plugins vs new servers and new plugins vs. old servers that will
have to solved. Running such shared code in NetBeans requires creating
a classloader dynamically, loading the classes and calling into it. We
know how to do this (it's done extensively in the V2 plugin -- too
extensively really), but it's still a bit ugly and has been painful to
maintain. As we've seen on this list, jar dependency rules seem to be
subject to change without notice but we have to give the classloader the
right set of jars, or the command api will not run.
After 6.5 ships, I can take a crack at what such an api would need to
look like to be as simple as possible yet still useful.
On the original topic of "why do we need/want to invoke java -jar
directly), here's further information:
It is helpful (and relied upon currently, or will be as soon as Vince
fixes it) to use an arbitrary debug port defined by the plugin for JVM
debugging rather than the setting hard coded into domain.xml.
Otherwise, we will have to either (a) possibly update domain.xml with a
new debug port just before starting the server if the current
designation is busy or (b) ensure all registered server instances have
unique debug ports (and then we still have a problem (a) if the port is
busy for other reasons). The alternative is (c) debugging fails because
the port is in use, which is a poor excuse on our part.
We also add additional JVM -J-D options beyond what is in domain.xml.
For example, injecting ruby debug parameters for use by the JRuby
Adapter to enable ruby debugging.
-Peter
>
> 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
>