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