[JBoss OSGi Development] - Re: Service integration with MC
by alesj
"adrian(a)jboss.org" wrote :
| The service tracking needs moving into the MC as part of this integration.
| The issue is what you track against.
|
Actually I had more fine grained tracking in mind.
Like I tried to explain, and I probably failed, I was thinking about OSGi service unget callbacks.
In MC we simply nullify injections at un-configure.
But in case the injected service is an OSGi service, we should also somehow invoke the unget.
We need something like ValueMetaData:release,
which in InjectionMetaData impl it would call ControllerContext::releaseTarget.
Or something like that ...
"adrian(a)jboss.org" wrote :
| As part of the OSGi stuff, I've made the DeploymentUnit part of the MDR's
| deployment level metadata. You should extend this concept so that the
| dependency project can look for a "ServiceTracker" in the MDR rather than
| a DeploymentUnit. The deployers project would then add the ServiceTracker
| attachment by the default to the deployment level metadata.
|
| If there is no such data (e.g. for MC contexts created by the bootstrap)
| then you should track against the "SystemBundle", i.e. a shared default deployment.
|
| The OSGi stuff would then just delegate to those items for service tracking
| instead of having to do it itself in the AbstractBundleState.
|
What's the use of this vs. KernelController's contextual tracking?
Since this would already be part of dependency whereas that is part of kernel?
If we use this, what would we gain by putting this in deployment level
instead of server level - which should be available for bootstrap beans as well?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265095#4265095
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265095
15 years, 1 month
[JBoss OSGi Development] - Re: Service integration with MC
by alesj
"adrian(a)jboss.org" wrote :
| What do you mean by key?
|
Both "keys".
What to register against and how to do lookup.
Register against:
Exposing classes when there are also properties doesn't seem right.
Lookup against:
Same as "register against", doing lookup just on registered classes when there are existing properties, shouldn't match.
Or should we treat this just as a MatchAllFilter lookup and type/class matching is actually enough / the right way?
"adrian(a)jboss.org" wrote :
| The name of the OSGi service context should be something generated that won't change
| or interfere with other names
| e.g. a UID or $OSGiService + serviceID
|
That's already done - it's GUID.
"adrian(a)jboss.org" wrote :
| Ideally you need an index (rather than a key) by class name to optimize the search
| but we don't currently do that in the OSGi prototype.
| You should already have something similar for the anonymous injection
| and the install callbacks which should be more efficient than what is currently used?
|
We have such mechanism already in KernelController, but it requires KernelControllerContext.
I'll see if (or how) I can make that less restrictive.
"adrian(a)jboss.org" wrote :
| The only thing that is probably missing is the security check?
|
The whole MC is missing this. ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265089#4265089
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265089
15 years, 1 month
[JBoss OSGi Development] - Tests no longer work in eclipse
by adrian＠jboss.org
After the lastest round of refactoring the tests now don't run in eclipse.
And this is not just the usual log4j mess again.
The root cause is an eclipse/maven problem with the classpath, i.e. it is now looking
for /META-INF/jboss-osgi-bootstrap.xml but it is finding a META-INF in some jar
instead of src/test/resources and so not find the xml.
I'm moving this back to the bootstrap subfolder so there can be no confusion.
Another broken part is because the following method has been removed from FrameworkTest extensions
e.g.
| public static Test suite()
| {
| return suite(OSGiSmokeTestCase.class);
| }
|
This construction of the TestSuite is what sets up and tears down the whole testcase
rather than reconstructing it for every method. See junit's TestSetup mechanism.
As I've said before, I don't see the point of all this refactoring.
Especially when it is to "standards" that are not traditional jboss, e.g.
* internal instead of plugins? (in some cases both :-)
* tests no longer go in a "test" subfolder and don't end in TestCase?
etc.
But at least don't change the semantics and break things.
On a related issue, the "no manifest" tests are there for a reason.
As are some other ones I'm going to add now I see what an abortion has been
made of this.
i.e. it should be possible to install NORMAL deployments using the OSGi api.
They don't have to be osgi bundles, they could be wars or any other type
of deployment.
Part of the reason for implementing OSGi is for users to have a standardized
framework for installing and controlling their deployments.
OSGi implementation details should go in the OSGi deployers not the bundle manager
which is just a facade for the MainDeployer. You only do OSGi processing when
it has OSGiMetaData and you only know that once it is deployed through the
deployers.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265069#4265069
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265069
15 years, 1 month
[JBoss OSGi Development] - ResolverPlugin is just Wrong
by adrian＠jboss.org
RESOLVER PLUGIN IS INOPERABLE WITH OTHER CLASSLOADING
Thomas, can you stop working on the ResolverPlugin, it is just plain wrong.
One of the major points of developing the MC based OSGi facade is that
OSGi bundles should be able to play nicely with other JBoss deployments.
What are doing breaks that requirement.
Besides that, the resolver plugin is incomplete compared to all the things that
JBoss ClassLoading can do and is broken in other ways
e.g. like the way it processes RequireBundle re-exports which can have
additional filters on what is exported for non-osgi deployments.
What I did for the original work was introduce the OSGi*Requirement/Capability
as a way to add the OSGi features without distribuing the jboss-cl code initially.
i.e. determine what is required before changing the classloader code.
But all those features should and will "bubble up" into jboss-cl project making them
redundant in the osgi code.
WHAT IS REQUIRED
The way to make the resolving work is to do what I said in at least two previous
posts and you've ignored. That is to have "on-demand" classloading requirements
handled automatically. This could be done in the OSGi code now, but it would be
messy, so it needs doing properly in the jboss-cl code.
There are additional requirements for osgi, which your resolver doesn't handle either.
1) Introduce a ClassNotFoundException handler
This will allow dynamic imports to force a resolution of a bundle that isn't in the
resolved state rather than throwing an error
2) Introduce a repository api
This will allow both the normal and dynamic imports to load a requirement
from a repository. i.e. a bundle/deployment that isn't even installed.
Both of the above need to be completed in jboss-cl for the OSGi classloading
work that I'm doing.
There is some additional work to the ClassLoading/Module api so that the PackageAdmin
api can be implemented on top it, and finally fragments and extension bundles
need to be supported.
The current resolver plugin certainly can't handle some of these and in most cases,
we want these features in the core classloading - it shouldn't be OSGi specific.
Remember the OSGi framework should just be a facade on JBoss MC features.
If the JBossMC feature doesn't exist, it should be added. The only reason
to do it in the OSGi project is to determine what is required before it goes in the main
codebase.
I'm working on doing all this, or at least putting the mechanisms in place so
they can be done - so you are just wasting your time, trying to do duplicate
stuff that can't possibly be implemented/extended in the way you are doing it.
DROOLS PLUGIN
On a further topic, the osgi-mc integration project (reactor/framework) is not the place
to put things like the drools plugin.
As a matter of of general policy, it should live in a seperate project so you don't
force an optional plugin (along with all it dependencies - it's a lot for drools) on all users.
But, the MC/ClassLoading already has mechanisms such as being able to write your own
Requirement/Capability to handle things like this. It doesn't need a "plugin".
e.g. something like:
| <classloading ...>
| <requirements>
| <drools-requirement>
| rule:
| etc.
| </drools-requirement>
| ...
|
Even if that is not the level you want to do it at, the extension mechanism belongs in
jboss-cl not the osgi facade, so it can be used for everything.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265057#4265057
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265057
15 years, 1 month
[JBoss OSGi Development] - Re: Service integration with MC
by adrian＠jboss.org
"alesj" wrote : "alesj" wrote :
| | * Service --> MC
| |
| What to do about tracking this "OSGi --> MC" injection?
|
| If we add this service to bundle's inUse, then there is no proper callback to decrease inUse count.
| Which in the case of ServiceFactory (SF) means SF::ungetService might never be called.
|
| We can completely ignore bundle service count + serviceCache,
| but potentially some service unregister could invoke SF::ungetService,
| although we would still be using it in MC bean.
|
The service tracking needs moving into the MC as part of this integration.
The issue is what you track against.
As part of the OSGi stuff, I've made the DeploymentUnit part of the MDR's
deployment level metadata. You should extend this concept so that the
dependency project can look for a "ServiceTracker" in the MDR rather than
a DeploymentUnit. The deployers project would then add the ServiceTracker
attachment by the default to the deployment level metadata.
If there is no such data (e.g. for MC contexts created by the bootstrap)
then you should track against the "SystemBundle", i.e. a shared default deployment.
The OSGi stuff would then just delegate to those items for service tracking
instead of having to do it itself in the AbstractBundleState.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265003#4265003
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265003
15 years, 1 month
[JBoss OSGi Development] - Re: Service integration with MC
by adrian＠jboss.org
"alesj" wrote : I'm actually wondering what's the best or proper way to expose or use this services in MC.
| What should be the keys that we expose or match.
|
| "alesj" wrote :
| | * Service --> MC
| |
| In OSGi service we expose classes and properties.
|
| Probably the key could look something like this:
| * org.jboss.acme.X,org.jboss.acme.Y;(a=b)
| a set of FQNs and a filter.
| Only matching services that expose all the FQNs and match the filter.
|
| Perhaps if there are no properties, we could directly expose service under registered classes?
|
What do you mean by key?
The name of the OSGi service context should be something generated that won't change
or interfere with other names
e.g. a UID or $OSGiService + serviceID
Ideally you need an index (rather than a key) by class name to optimize the search
but we don't currently do that in the OSGi prototype.
You should already have something similar for the anonymous injection
and the install callbacks which should be more efficient than what is currently used?
The only thing that is probably missing is the security check?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265000#4265000
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265000
15 years, 1 month