[jbosstools-dev] Question on all external users of IJBoss7ManagerService

Max Rydahl Andersen manderse at redhat.com
Mon Jun 29 06:22:14 EDT 2015


>>> This is pretty confusing, since someone might expect the jars in the 
>>> as71 plugin are the one being used for as71, which won't be the 
>>> case.
>>
>> no, but I do not think this is a problem. the management.as71 means 
>> the "management jars from as71", right ? Not "the management jars 
>> used only for as71".
>
> At this point, the various management plugins names have absolutely no 
> logical meaning. It doesn't mean "jars that work for server-X" and it 
> doesn't mean "jars FROM server-X".
>
> As of right now, the as71.management plugin's jars are from eap6.1, 
> and works for as70 through eap6x (except for the one bug we found).

> As of right now, the wf8.management plugin's jars are from wf8.2, and 
> work with all wildfly versions.

Is it not up to the server adapters to state what management library 
they use ?

Then have the management plugin state which version their libraries are 
*from*, not what version they are used with.

Then the server adapters state which management version they 
wish/want/need to use.

Then there is no ambiguity and no need to rename the plugins everytime 
we need to update.

>> [sic]
>> I never seen them as what their functionality are, but what client 
>> jars they contain.
>
> As mentioned above, this isn't true.  The as71.management plugin has 
> jars from EAP6.1.   In the past we had two plugins for as7x vs wf, and 
> would just try to find the best jars to fit there, regardless of where 
> they were from.

So stop doing that and make their name match what they contain.

> The suggested patch is to change the wf8.management plugin's jars to 
> use wf9 jars, and change as7.1 and later (and all eap6.x) to use the 
> wf9 jars in the wf8.management plugin.

I think that is the wrong direction. This will imply you will have to 
keep update the management plugins instead of have them actually stay 
consistent.

> After the patch, the as70 adapter would use the as71.management 
> plugin's jars, which are actually from eap6.1 (usecase is unchanged 
> from previous).

> After the patch, the as71 adapter would use the "wf8.management" 
> plugin's jars, which are actually jars from wf9 (after this PR).

why not wf9.management and then have as71 use that ?

> Maybe others find this logical... I find it very confusing... both the 
> current case and the post-patch case.

It is completely illogical - which is why I suggest to have the 
management plugin name match what it actually is.

Having AS7 adapter using a wf9.management since they are known to be 
compatible is more sane than having as7 use wf8.management with wf9 jars 
in them.

> At this point, the various management plugins names have absolutely no 
> logical meaning. It doesn't mean "jars that work for server-X", it 
> doesn't mean "jars currently being used for server-adapter-X", and it 
> doesn't mean "jars FROM server-X".

Make it jars from server-X and things are lot less confusing.

> The only way to give them a meaning that's consistent is one of the 
> following:
> 1) Stick to "plugin names means jars FROM server-version-X"
> 2) Stick to "plugin names means jars that work FOR server version X"

Current situation is closer to #1 than it is #2.

> Both have their own problems.
>
> Option 1 means I must rename plugins every time I get a set of jars 
> from a newer version of the app-server.

no, it means you add a new plugin when needed and only for major 
versions.

> Option 2 is still kinda vague. Post-patch, technically, the eap6.1 
> jars (in the as71.management plugin) WILL work for as71, but, as71 
> won't be using them, as it'd be using the wf9 jars in the 
> wf8.management plugin to fix the above bug.

option 2 is just weird imo ;)

> No matter what, the current situation makes no sense at all ;)

go for option 1.

Or have an option 3 where the names are more descriptive (I don't have a 
good suggestion for those ;)

/max
http://about.me/maxandersen


More information about the jbosstools-dev mailing list