Bill Shannon wrote:
> 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.
Agreed. This would be great.
What we do today is to match the NetBeans schedule and track GlassFish
releases as closely as possible. If GlassFish FCS dates are too far
away, we release update modules to the NetBeans update center when that
release is available. We also try to keep the NetBeans nightly builds
working with both the latest GlassFish builds as well as all prior FCS
releases.
Note this discussion only covered the plugin's administration
capabilities. There are other areas of integration (web service support
for example) that also have implied dependencies (jar names, etc.) that
impact this.
> 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.
The plugin in general is far more dependent on NetBeans than anything in
GlassFish and I think it should remain part of NetBeans. Otherwise, we
are limited in our ability to track evolving api's and cutting edge
capabilities and such deficiencies are usually more visible to the end
users.
That said, it's composed of multiple NetBeans modules. I've wondered
about wrapping the AMX client stubs up in an additional module (this may
have already happened but in a limited scope), 1 for each server version
(V1, V2, V3, etc), so that there is a piece of the plugin that either
"comes with the server" or at least is a binary match to a specific
server install. I don't think we've ever had the time to investigate
this approach to any depth. There would still be a bunch of other
problems though, there's no silver bullet here.
I will examine the server dependencies in more depth after 6.5 ships and
see if some of the ideas expressed here are applicable. There are other
reasons this could be very helpful (Open ESB support I think requested
something and Identity has also made requests).
-Peter
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>