.
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