[jbosstools-dev] Extending the AS Server View

[André Dietisheim]

.

> 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
>
>
>