Peter Williams wrote:
>> 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.
What I was trying to avoid was the need to synchronize GlassFish and
NetBeans releases when anything in this area changes. It really would
be nice if I could update either GlassFish or NetBeans independently and
still have them work together. Ideally there would be a stable interface
between the two that would help with this. Maybe the only stable interface
here is the NetBeans plugin interface and we should just consider the
GlassFish support that plugs into NetBeans to be part of GlassFish rather
than part of NetBeans, so that it can safely embed intimate details of the
GlassFish implementation? As long as that plugin is provided for and works
with older versions of NetBeans, that might be ok.
I think later messages in this thread indicated just how much the NetBeans
plugin depends on implementation details of the current version of GlassFish.
I guess we just need to decide whether the plugin is on the "GlassFish" side
of the line or the "NetBeans" side of the line.