[JBoss OSGi Development] - Re: Service integration with MC
by adrian＠jboss.org
"alesj" wrote : "adrian(a)jboss.org" wrote :
| | e.g. The OSGi api is at the deployment level
| | by passing in the Bundle to getService(Bundle).
| |
| Wouldn't this be DeploymentControllerContext?
|
But that's just an implementation detail. ;-)
The actual answer is yes for normal bundles, because they always represent
top level deployments. OSGi bundles can't have subdeployments.
But its also not for the SystemBundle which doesn't have a DeploymentUnit, it should use
the SYSTEM level.
I can imagine other cases where you might not have a specific ControllerContext but
you do know what your ServiceTracker is (or something else does and can "hide" the
link through its own api).
Or as I described above, you may want to do tracking at subdeployment level.
The DeploymentControllerContext is no use there because it maps to the top level
deployment.
DeploymentControllerContext.getScope() -> APPLICATION scope
DeploymentUnit.getTopLevel().getScope() -> APPLICATION scope
(Sub)DeploymentUnit.getScope() -> DEPLOYMENT scope
So you can see that using the implement detail actually can give you the wrong answer.
Because you are writing to the wrong api. ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267036#4267036
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267036
14 years, 5 months
[JBoss OSGi Development] - Re: Service integration with MC
by alesj
"adrian(a)jboss.org" wrote : It should be done on the calls to (un)getTarget()
|
|
| | // Mixin interface for service tracking
| | public interface ServiceTracking
| | {
| | ...
| |
| | if (me instanceOf ServiceTracking)
| | {
| | ServiceTracker otherTracker = me.getServiceTracker();
| | if (otherTracker != null)
| | otherTracker.incrementUsing(this);
| | }
| | }
| | return result;
| | }
| |
|
| The instanceOf ServiceTracking is for backwards compatibilty in case
| some old ControllerContext doesn't know about ServiceTracking.
|
I don't get this "instance of"?
Wouldn't ControllerContext implement this ServiceTracking mixin?
OK, I guess since you called it mixin, it should be just AbstractControllerContext that impls it.
But this makes lookup code ugly ... checking every context in metadata if it's ServiceTracking interface.
Oh well, some copy pasting won't kill me ... :-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267033#4267033
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267033
14 years, 5 months
[JBoss OSGi Development] - Re: Service integration with MC
by adrian＠jboss.org
It should be done on the calls to (un)getTarget()
Having the calling code do all this work would inefficient and error prone.
And besides a context may want to change the way this work, e.g. by providing
a specific ServiceTracker rather than using the one determined from the MDR.
You need a signature like I suggested above,
i.e. something like the following:
| // Mixin interface for service tracking
| public interface ServiceTracking
| {
| /**
| * Get the service tracker associated with this context
| *
| * @return the tracker or null if it doesn't have one
| */
| ServiceTracker getServiceTracker();
|
| /**
| * Get the target and update the service tracking
| *
| * @param me the controller context that will use the target
| * @return the object
| * @throws Exception for any error
| */
| Object getTarget(ControllerContext me) throws Exception;
|
| /**
| * Unget the target and update the service tracking
| *
| * @param me the controller context that used the target
| */
| void ungetTarget(ControllerContext me);
| }
|
| public Object ControllerContext::getTarget(ControllerContext me) throws Exception
| {
| Object result = getTarget();
| if (result != null)
| {
| ServiceTracker myTracker = getServiceTracker();
| if (myTracker != null)
| myTracker.incrementInUse(me, this);
| if (me instanceOf ServiceTracking)
| {
| ServiceTracker otherTracker = me.getServiceTracker();
| if (otherTracker != null)
| otherTracker.incrementUsing(this);
| }
| }
| return result;
| }
|
| public void ControllerContext::ungetTarget(ControllerContext me)
| {
| Object result = getTarget();
| if (result != null)
| {
| ServiceTracker myTracker = getServiceTracker();
| if (myTracker != null)
| myTracker.decrementInUse(me, this);
| if (me instanceOf ServiceTracking)
| {
| ServiceTracker otherTracker = me.getServiceTracker();
| if (otherTracker != null)
| otherTracker.decrementUsing(this);
| }
| }
| }
|
The instanceOf ServiceTracking is for backwards compatibilty in case
some old ControllerContext doesn't know about ServiceTracking.
You should make AbstractControllerContext implement the getServiceTracker() by
looking in the MDR (probably during the original install for performance and
consistency - or you could do it lazily on first request?).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267018#4267018
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267018
14 years, 5 months
[JBoss OSGi Development] - Re: Service integration with MC
by adrian＠jboss.org
"alesj" wrote :
| I fail to see why I would need two different levels of ServiceTracker.
| As I also always have to check the "global" list.
|
| When would I check just deployment level ServiceTracker?
| For non-system bundle, to lookup non-osgi services that belong just to this bundle / jar / deployment?
|
It is the stats that are at different levels.
* The queries are global.
* The inuse tracking is at system/application/deployment level, i.e. this deployment
uses a service from some other deployment and the some other deployment's service
has its "in use" count integrated.
See the current OSGi code. The queries run against the OSGiBundleManager (should be Controller).
The other statistics are at BundleState level (should be ServiceTracker at whatever
level the deployers setup for that context).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266980#4266980
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266980
14 years, 5 months
[JBoss OSGi Development] - Re: Define non OSGi bundle handling by the Framework
by adrian＠jboss.org
"thomas.diesler(a)jboss.com" wrote :
| What we do with the OSGi example and functional test is a specific solution to the general problem of Maven integration testing
|
| http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing
|
| Anyhow, the MC framework needs to work in AS and the OSGi examples must run in AS. This is not something you can do in an Eclipse unit test.
|
| I realize, that building the installer, installing the framework, starting the target container, running the examples against the target container is not a practical prerequisite for an SVN commit.
|
| However, everybody should at least be aware of the functionality that already works and is being tested. One click on the public hudson instance can pickup potential integration issues, which can then be looked at and fixed locally.
|
That's not what I'm saying. I mean why isn't this feature being properly unit tested in
framework/reactor?
The FrameworkTest lets you setup a "minimal" JBoss instance (without all
the other JavaEE services - just the basic OSGi stuff).
So it should be possible to write a unit test for something that is broken in the integration
tests so it won't regress in future by a bad commit in framework/reactor.
On the thirdparty library stuff. The integration tests should not be running off
reactor/framework trunk. The version used there should only be updated
when the AS and osgi framework agree about thirdparty dependencies.
i.e. once the thirdparty stuff has been updated into the AS at the end of the
latest changes (once they are stable).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266979#4266979
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266979
14 years, 5 months
[JBoss OSGi Development] - Re: Service integration with MC
by alesj
"adrian(a)jboss.org" wrote :
| So we add a "ServiceTracker" to the MDR which for deployments will be in the deployment level (really the application/top level deployment)
| for others it will be as you say a default one at the Server level, what osgi calls the "SystemBundle".
| You can imagine others might choose to track at some other level. e.g.
| for JavaEE we might choose to track at sub-deployment level, what MDR
| confusingly calls the deployment level. :-)
|
| When you do any type of injection (or the api is invoked from somewhere else)
| this should invoke the equivalent of get/unget of the ServiceTracker for that context.
|
| Once that is done, the queries can go through the ServiceTracker at the relevant level.
| The deployment level for normal OSGiBundleState and the server level for the SystemBundle.
|
| You still need a "global" list of services for the getXXXServiceXXX() queries.
| That should primarily be based on an index by class (it doesn't have to be
| its a performance optimization and only available when you have been asked
| to query by class). But once you've subsetted by class then you do a
| "read and skip" over those contexts to locate the ones that match any passed filter on the properties (instance level MDR).
|
I fail to see why I would need to different levels of ServiceTracker.
As I also always have to check the "global" list.
When would I check just deployment level ServiceTracker?
For non-system bundle, to lookup non-osgi services that belong just to this bundle / jar / deployment?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266790#4266790
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266790
14 years, 5 months