4:49 a.m.
looks like you forgot to cc the list.
> The biggest issue we still got is the isolation of dmr.jar - as
far as I can see you are putting dmr.jar into the core plugin. Doesn't this mean that
when the core plugin actually calls into our as7 services that this dmr.jar content
overshadows the dmr.jar found in as7 plugin ? (this becomes important/critical when we get
into the situation we were in during as71 dev time - as70 jars didn't work with as71
jars…this specific issue is solved now but once as8 comes we can't be sure).
I'm not aware of all details here but I'd doubt that this so
"shadowing" would happen. So far the as service bundle would not expose dmr to
the outside world and would only use the dmr within its bundle boundaries. I dont see why
the internal implementation within the service bundle should get anything different than
it's internal dmr bundle.
if that is true (AS7 service doesn't get affected by classes loaded by the callee)
then having dmr.jar as external bundle for use by others for string creation will be ok -
optimally we could just pass in a ModelNode but *then* we get the shadow problem, right ?
the passed in instance will be from dmrincore.jar and possibly not compatible with the
dmrinservice.jar if I see it right.
> Because of this we (Rob and I) was discussing if it would make
more sense to repackage/rename dmr (i.e. with something like jarjar) and provide that as
the way to create non-conflicting model node strings ? That for sure eliminates any
problem of client jars overshadowing - but of course leaves a problem if as8 changes their
dmr syntax….but I think that is unlikely. What can change is the actual
operation/subsystem names in as8 but that is possible to abstract out in code much easier
than abstracting out client jars. Another less "intrusive" approach was to put
the dmr.jar into an org.jboss.tools.as.dmr bundle that exports the dmr.jar api directly -
but I guess if having dmr.jar in .core overshadows then having it in an external plugin
that clients uses will result in same problem ?
I'd definitely opt for the dmr-version/bundle approach. That is what osgi was
invented for. If using bundles definied requirements properly things should work perfectly
well. I still dont see any potential for shadowing. Or what do I miss?
Well the left over problem is the day AS8 comes with some new api added to dmr.jar then
either that dmr.jar should be backwards compatible or we need an as.dmr and as.dmr8 bundle
- but then clients would have to choose which one.
But since we are relying on the string operations to be sane here then we *assume* we are
fine. Worth verifying with the AS7 team.
/max
http://about.me/maxandersen
5:59 a.m.
New subject: Extending the AS Server View
.
if that is true (AS7 service doesn't get affected by classes
loaded by the callee) then having dmr.jar as external bundle for use by others for string
creation will be ok - optimally we could just pass in a ModelNode but *then* we get the
shadow problem, right ?
oh, ok, got what I was missing: you plan to pass ModelNodes around. that
changes the whole game of course.
I think that
Without knowing how things would behave in all details by heart I think
that this would not end in a shadowing problem but in a
ClassDefNotFoundException: The reciever needs to be able to access the
bundle/classloader that was used to created the instance he'd get
passed. If he cannot (because his requirements dont allow him access to
the required bundle/version) he'd fail. Afaik this would be solved
pretty easily with an open version range. But I'm not completely sure at
100% about this. Would need to verify in a quick POC.
Do I miss something?
the passed in instance will be from dmrincore.jar and possibly not compatible with the
dmrinservice.jar if I see it right.
In the use case where we pass model nodes along, I'd pretend that we'd
have to offer dmr bundles so that both parties (the sender and the
consumer) are able to access the very same bundle/classloader that was
used to create the instances.
>> Because of this we (Rob and I) was discussing if it would make more sense to
repackage/rename dmr (i.e. with something like jarjar) and provide that as the way to
create non-conflicting model node strings ? That for sure eliminates any problem of client
jars overshadowing - but of course leaves a problem if as8 changes their dmr syntax….but I
think that is unlikely. What can change is the actual operation/subsystem names in as8 but
that is possible to abstract out in code much easier than abstracting out client jars.
Another less "intrusive" approach was to put the dmr.jar into an
org.jboss.tools.as.dmr bundle that exports the dmr.jar api directly - but I guess if
having dmr.jar in .core overshadows then having it in an external plugin that clients uses
will result in same problem ?
> I'd definitely opt for the dmr-version/bundle approach. That is what osgi was
invented for. If using bundles definied requirements properly things should work perfectly
well. I still dont see any potential for shadowing. Or what do I miss?
Well the left over problem is the day AS8 comes with some new api added to dmr.jar then
either that dmr.jar should be backwards compatible or we need an as.dmr and as.dmr8 bundle
- but then clients would have to choose which one.
But since we are relying on the string operations to be sane here then we *assume* we are
fine. Worth verifying with the AS7 team.
/max
http://about.me/maxandersen
6:45 a.m.
New subject: Extending the AS Server View
> if that is true (AS7 service doesn't get affected by classes
loaded by the callee) then having dmr.jar as external bundle for use by others for string
creation will be ok - optimally we could just pass in a ModelNode but *then* we get the
shadow problem, right ?
oh, ok, got what I was missing: you plan to pass ModelNodes around. that changes the
whole game of course.
Yes, thats why I'm suggesting just to use String for this case.
I think that
Without knowing how things would behave in all details by heart I think that this would
not end in a shadowing problem but in a ClassDefNotFoundException:
hmm - that *is* exactly what I call an overshadow problem IMO - well I guess the proper
term here would be mixed-classes.
The reciever needs to be able to access the bundle/classloader that
was used to created the instance he'd get passed. If he cannot (because his
requirements dont allow him access to the required bundle/version) he'd fail. Afaik
this would be solved pretty easily with an open version range. But I'm not completely
sure at 100% about this. Would need to verify in a quick POC.
Do I miss something?
For that to work the as library would have to do this for each method call - and mind you,
we would for sure not be able to have the management api use this same dmr dependency
since then it would for sure cause problems down the line.
> the passed in instance will be from dmrincore.jar and possibly
not compatible with the dmrinservice.jar if I see it right.
In the use case where we pass model nodes along, I'd pretend that we'd have to
offer dmr bundles so that both parties (the sender and the consumer) are able to access
the very same bundle/classloader that was used to create the instances.
Yes, which can't be done since then we haven't isolated enough for the case of as7
and as8 not being 100% compatible.
/max
http://about.me/maxandersen
9:51 a.m.
New subject: Extending the AS Server View
Re: DMR integration...
I don't think there are any problems here. The OSGi bundle class loader will load the
first class on its classpath. Since ModelNode exists in a private library within the AS7
management plugin, that class will be loaded and the class loader will stop searching
(i.e. it won't ever search its dependencies).
On the other side, consumers will only see the ModelNode exported by core, since the AS7
plugin doesn't export it. A bundle with a dependency on both plugins will only ever
see the ModelNode exported by core.
Using String in the execute interface decouples the caller from specific DMR
implementations. At this point, we're simply using DMR as a JSON factory/parser. We
don't even need to worry about type compatibility between the two DMR libraries as
everything is reduced to a JSON type (i.e. object, list, string). The only issues will be
the contents of the JSON, depending on whether or not the management structure changes
between releases of AS.
I really don't think there is any issue with this approach (other than the baggage of
converting to/from JSON on each call).
Best,
Rob
10:02 a.m.
New subject: Extending the AS Server View
Re: DMR integration...
I don't think there are any problems here. The OSGi bundle class loader will load
the first class on its classpath. Since ModelNode exists in a private library within the
AS7 management plugin, that class will be loaded and the class loader will stop searching
(i.e. it won't ever search its dependencies).
On the other side, consumers will only see the ModelNode exported by core, since the AS7
plugin doesn't export it. A bundle with a dependency on both plugins will only ever
see the ModelNode exported by core.
Using String in the execute interface decouples the caller from specific DMR
implementations. At this point, we're simply using DMR as a JSON factory/parser. We
don't even need to worry about type compatibility between the two DMR libraries as
everything is reduced to a JSON type (i.e. object, list, string). The only issues will be
the contents of the JSON, depending on whether or not the management structure changes
between releases of AS.
I really don't think there is any issue with this approach (other than the baggage of
converting to/from JSON on each call).
Yup, which is basically same conclusion I've gotten to and thus creating a dmr bundle
that clients that wishes to create json can use/depend on makes sense.
/max
http://about.me/maxandersen
10:25 a.m.
New subject: Extending the AS Server View
I added the code as required and tested to make sure it works. I also
double-checked that there's no 'overlap' in the classloading stuff
(printed class and class's hashcode to ensure no corruption).
I will leave the jira https://issues.jboss.org/browse/JBIDE-10799 open
until it's cleaned up a bit more. I look forward to additional patches
;) Please update your svn... :)
- Rob
On 02/07/2012 08:45 PM, Max Rydahl Andersen wrote:
>> if that is true (AS7 service doesn't get affected by
classes loaded by the callee) then having dmr.jar as external bundle for use by others for
string creation will be ok - optimally we could just pass in a ModelNode but *then* we get
the shadow problem, right ?
> oh, ok, got what I was missing: you plan to pass ModelNodes around. that changes the
whole game of course.
Yes, thats why I'm suggesting just to use String for this case.
> I think that
> Without knowing how things would behave in all details by heart I think that this
would not end in a shadowing problem but in a ClassDefNotFoundException:
hmm - that *is* exactly what I call an overshadow problem IMO - well I guess the proper
term here would be mixed-classes.
> The reciever needs to be able to access the bundle/classloader that was used to
created the instance he'd get passed. If he cannot (because his requirements dont
allow him access to the required bundle/version) he'd fail. Afaik this would be solved
pretty easily with an open version range. But I'm not completely sure at 100% about
this. Would need to verify in a quick POC.
> Do I miss something?
For that to work the as library would have to do this for each method call - and mind
you, we would for sure not be able to have the management api use this same dmr dependency
since then it would for sure cause problems down the line.
>> the passed in instance will be from dmrincore.jar and possibly not compatible
with the dmrinservice.jar if I see it right.
> In the use case where we pass model nodes along, I'd pretend that we'd have
to offer dmr bundles so that both parties (the sender and the consumer) are able to access
the very same bundle/classloader that was used to create the instances.
Yes, which can't be done since then we haven't isolated enough for the case of
as7 and as8 not being 100% compatible.
/max
http://about.me/maxandersen
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
11:12 a.m.
New subject: Extending the AS Server View
I added the code as required and tested to make sure it works. I also
double-checked that there's no 'overlap' in the classloading stuff
(printed class and class's hashcode to ensure no corruption).
so where did the dmr.jar for usage by clients end up living ? inside or outside core ?
(svn update is taking ages for me today)
I will leave the jira https://issues.jboss.org/browse/JBIDE-10799
open
until it's cleaned up a bit more. I look forward to additional patches
;) Please update your svn... :)
shouldn't we close this issue and open specific ones instead ?
/max
- Rob
On 02/07/2012 08:45 PM, Max Rydahl Andersen wrote:
>>> if that is true (AS7 service doesn't get affected by classes loaded by
the callee) then having dmr.jar as external bundle for use by others for string creation
will be ok - optimally we could just pass in a ModelNode but *then* we get the shadow
problem, right ?
>> oh, ok, got what I was missing: you plan to pass ModelNodes around. that changes
the whole game of course.
> Yes, thats why I'm suggesting just to use String for this case.
>
>> I think that
>> Without knowing how things would behave in all details by heart I think that this
would not end in a shadowing problem but in a ClassDefNotFoundException:
> hmm - that *is* exactly what I call an overshadow problem IMO - well I guess the
proper term here would be mixed-classes.
>
>> The reciever needs to be able to access the bundle/classloader that was used to
created the instance he'd get passed. If he cannot (because his requirements dont
allow him access to the required bundle/version) he'd fail. Afaik this would be solved
pretty easily with an open version range. But I'm not completely sure at 100% about
this. Would need to verify in a quick POC.
>> Do I miss something?
> For that to work the as library would have to do this for each method call - and mind
you, we would for sure not be able to have the management api use this same dmr dependency
since then it would for sure cause problems down the line.
>
>>> the passed in instance will be from dmrincore.jar and possibly not compatible
with the dmrinservice.jar if I see it right.
>> In the use case where we pass model nodes along, I'd pretend that we'd
have to offer dmr bundles so that both parties (the sender and the consumer) are able to
access the very same bundle/classloader that was used to create the instances.
> Yes, which can't be done since then we haven't isolated enough for the case
of as7 and as8 not being 100% compatible.
>
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
/max
http://about.me/maxandersen
5082
days inactive
5082
days old
jbosstools-dev@lists.jboss.org
6 comments
4 participants
participants (4)
-
André Dietisheim -
Max Rydahl Andersen -
Rob Cernich -
Rob Stryker