3:23 p.m.
Hi all:
We currently have two plugins containing client jars for the various
wildfly / as7 versions. One plugin is named
org.jboss.ide.eclipse.as.management.as71, the other
org.jboss.ide.eclipse.as.management.wildfly8
As currently implemented, org.jboss.ide.eclipse.as.management.as71 holds
client jars that are used with as70, 71, eap6x, etc.
org.jboss.ide.eclipse.as.management.wildfly8 is used to hold jars for
all wildflys, or, expectedly, eap7x.
A bug in deploying large projects has led me to investigate whether the
wildfly 9 jars work for all servers or not. It turns out, they work for
all except AS 7.0.x. With as71, though, a higher timeout is needed.
My PR to fix the issue creates a 71x service inside the
org.jboss.ide.eclipse.as.management.wildfly8 to live along side the wf8
service. Unfortunately, it seems strange now to have a plugin named
org.jboss.ide.eclipse.as.management.as71 which holds a service with
version=7.1.0.Beta1 which only works for AS 7.0.x =P Seems a bit
odd, no?
So I was planning on harmonizing these constants, plugin names,
versions, etc, in beta2, and was wondering if anyone else is using these
service names and constants directly, and how they're being used? I
expect to change them and clean them up, and need to know if this will
break anyone.
- Rob Stryker
4:47 a.m.
My PR to fix the issue creates a 71x service inside the
org.jboss.ide.eclipse.as.management.wildfly8 to live along side the
wf8
service. Unfortunately, it seems strange now to have a plugin named
org.jboss.ide.eclipse.as.management.as71 which holds a service with
version=7.1.0.Beta1 which only works for AS 7.0.x =P Seems a bit
odd, no?
eh - why would as71 not continue to work with AS 7.1, EAP etc. ?
Are you not just saying that you will start using management.as90 with
AS 7.1 and upwards
to make it behave better ?
seems to me like nothing changed/broken in this so not sure why you
think its broken
more than before where as71 was used for other versions than as7.1 ?
/max
http://about.me/maxandersen
11:56 a.m.
On 06/25/2015 05:47 AM, Max Rydahl Andersen wrote:
> My PR to fix the issue creates a 71x service inside the
> org.jboss.ide.eclipse.as.management.wildfly8 to live along side the wf8
> service. Unfortunately, it seems strange now to have a plugin named
> org.jboss.ide.eclipse.as.management.as71 which holds a service with
> version=7.1.0.Beta1 which only works for AS 7.0.x =P Seems a bit
> odd, no?
eh - why would as71 not continue to work with AS 7.1, EAP etc. ?
I'm saying that in my PR, the jars in the as71 management plugin would
only work for as70, while the jars in the wf8 plugin will work for as71
through wf9. 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.
Of course if a client were using the mgmt plugins properly, they'd have
an IServer already, and use the existing API (Extended properties, etc)
to get the management service. But if they're "hand-rolling" their own
solution by locating services with specific version strings, or
depending on specific plugins, this becomes more of an issue.
Ideally I'd like to rename the plugins to match better their
functionality. I'd also like to rename the constants to match what they
actually work for, so we don't have constants with strings including
"beta1" or other such nonesense... But in order to do this safely, I
need to know who our external users are of the IJBoss7ManagerService,
what constants they use, whether they depend on a given plugin name
directly (either in their manifests or features), or if they just depend
on my AS feature (and then I pull in all the management stuff).
Basically, I'd like to clean up the code, rename the things that make no
sense, and harmonize the situation ;)
Are you not just saying that you will start using management.as90 with
AS 7.1 and upwards
to make it behave better ?
seems to me like nothing changed/broken in this so not sure why you
think its broken
more than before where as71 was used for other versions than as7.1 ?
/max
http://about.me/maxandersen
5:41 p.m.
On 25 Jun 2015, at 18:56, Rob Stryker wrote:
On 06/25/2015 05:47 AM, Max Rydahl Andersen wrote:
>
>> My PR to fix the issue creates a 71x service inside the
>> org.jboss.ide.eclipse.as.management.wildfly8 to live along side the
>> wf8
>> service. Unfortunately, it seems strange now to have a plugin named
>> org.jboss.ide.eclipse.as.management.as71 which holds a service with
>> version=7.1.0.Beta1 which only works for AS 7.0.x =P Seems a bit
>> odd, no?
>
> eh - why would as71 not continue to work with AS 7.1, EAP etc. ?
I'm saying that in my PR, the jars in the as71 management plugin
would only work for as70,
Are you somehow going to make it impossible for use the as71 to work for
others but as70 ?
aren't you just going to start using newer management version with the
other server adapters ?
i.e. as71 is not changing from how it was before ? it is the as71 client
jars - that is it; and we choose in our server adapter which one we use
that fit best - currently that is now the as9.management jars, right ?
while the jars in the wf8 plugin will work for as71 through wf9.
in the first mail you said it was the wf9 jars that would make it
better, now you say wf8 ? which one is it ?
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".
Of course if a client were using the mgmt plugins properly,
they'd
have an IServer already, and use the existing API (Extended
properties, etc) to get the management service. But if they're
"hand-rolling" their own solution by locating services with specific
version strings, or depending on specific plugins, this becomes more
of an issue.
Ideally I'd like to rename the plugins to match better their
functionality.
I never seen them as what their functionality are, but what client jars
they contain.
Which then are selected by the server adapter to what they want to use ?
I'd also like to rename the constants to match what they actually
work
for, so we don't have constants with strings including "beta1" or
other such nonesense... But in order to do this safely, I need to
know who our external users are of the IJBoss7ManagerService, what
constants they use, whether they depend on a given plugin name
directly (either in their manifests or features), or if they just
depend on my AS feature (and then I pull in all the management stuff).
I don't know what those constants are and why we would ever have
such....you should just go look in teiid designer and fuse tools code
base - they are afaik the only one using us.
But seems like we are cleaning something up that dont need much cleaning
up...but seeing the PR could help answer that.
Basically, I'd like to clean up the code, rename the things that
make
no sense, and harmonize the situation ;)
show the PR.
For now, your description of management.asXY did not seem to need
harmonizing afaics - it already is harmonised.
/max
http://about.me/maxandersen
11:16 p.m.
I need to know what kind of patch to make, before I simply show a patch.
Please read below.
> while the jars in the wf8 plugin will work for as71 through wf9.
in the first mail you said it was the wf9 jars that would make it
better, now you say wf8 ? which one is it ?
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. So I mean just what I said: the jars
in the wf8 plugin (which, post-patch, would be jars from wf9).
> 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.
[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.
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.
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).
Maybe others find this logical... I find it very confusing... both the
current case and the post-patch case.
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".
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"
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.
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.
No matter what, the current situation makes no sense at all ;)
5:22 a.m.
>> 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
2:46 p.m.
On 06/29/2015 06:22 AM, Max Rydahl Andersen wrote:
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.
Perhaps I'm missing something here. I don't see how your example
prevents me from having to rename plugins.
If, for example, I have a plugin with jars from wf8, and the plugin is
named wf8.management, and then we decide to upgrade to wf9 jars, I
don't see how your solution fixes anything? It seems my migration path
is to then:
1) Rename the wf8 plugin to wf9, so that its name matches what jars are
inside it
2) Update feature, etc
3) Rename various classes to have wf9 in name instead of wf8
4) Add a new service component with version 9.0.0, with new service impl
class
5) Change existing 8.0.0 service component to delegate to 9.0.0
6) Add new version constant to IJBoss7ManagerService list of constants,
to ensure that any downstream adopter (teiid fuse etc) depending on
specific service versions (which they shouldn't do, but still might) are
not broken by a removed constant or a removed service corresponding to
that constant.
Or are you suggesting that I keep the wf8.management plugin with its
constants and jars and then add a new wf9.management plugin with new
constants / services / jars? Clearly then we'd experience a ballooning
of client jars...
5:14 a.m.
we talked on chat yesterday, but just to conclude on this thread.
I was simply suggesting that the management.xyz bundles got a consistent
name related to what they contain OR get some name not related to
specific version of libs.
from our chat what I got is we ended up with:
* management.xyz bundle names will match what libs they contain. ie.
management.as7 has jars from as7x, management.wf9 from wildfly 9
* service lookups targets which version to support (not what jars to
use), so adapters does not have to update their lookups - we just need
to repackage the management jars.
The rest we would take once PR was done to try/give more direct feedback
on.
/max
>
> 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.
Perhaps I'm missing something here. I don't see how your example
prevents me from having to rename plugins.
If, for example, I have a plugin with jars from wf8, and the plugin is
named wf8.management, and then we decide to upgrade to wf9 jars, I
don't see how your solution fixes anything? It seems my migration
path is to then:
1) Rename the wf8 plugin to wf9, so that its name matches what jars
are inside it
2) Update feature, etc
3) Rename various classes to have wf9 in name instead of wf8
4) Add a new service component with version 9.0.0, with new service
impl class
5) Change existing 8.0.0 service component to delegate to 9.0.0
6) Add new version constant to IJBoss7ManagerService list of
constants, to ensure that any downstream adopter (teiid fuse etc)
depending on specific service versions (which they shouldn't do, but
still might) are not broken by a removed constant or a removed service
corresponding to that constant.
Or are you suggesting that I keep the wf8.management plugin with its
constants and jars and then add a new wf9.management plugin with new
constants / services / jars? Clearly then we'd experience a
ballooning of client jars...
/max
http://about.me/maxandersen
3445
days inactive
3451
days old
jbosstools-dev@lists.jboss.org
7 comments
2 participants
participants (2)
-
Max Rydahl Andersen -
Rob Stryker