[jbosstools-dev] Extending the AS Server View

[Max Rydahl Andersen]

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