[JBoss OSGi Development] - Re: Handle potential bundle:// protocol with VFS
by alesj
"dml" wrote :
| However this is done, it shouldn't use the host name field (recall the problems with vfsmemory URLs).
|
What was the vfsmemory problem again?
Or what do you suggest - apart from the below idea?
"dml" wrote :
| Personally I think the best solution would be to have a global VFS location where bundles can be found by ID, e.g. file:///osgi/bundles/by-id/[id]/[path] in VFS3 or the equivalent in VFS2.
|
I don't think we should abuse file protocol too much.
"thomas" wrote :
| Resources could be shared by the bundle root VirtualFile, no?
|
Sure, but like I said, that's too specific detail.
For some internal - cross-bundle - communication we should use bundles (actually its ids),
and leave the impl details to framework.
e.g. although this is not standard, osgi devs do use it quite a lot to find resources across bundles
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265105#4265105
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265105
16 years, 4 months
[JBoss OSGi Development] - Re: Service integration with MC
by adrian＠jboss.org
I think we're talking at cross purposes. Let's start again from scratch with the requirements.
What is required is to be able to do "service tracking".
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.
In MC terms that is getTarget() for get. But we don't currently invoke an ungetTarget()
at "uninjection" so that needs doing.
Of course the OSGiServiceStates become ControllerContexts and
delegate to the same api.
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).
We might choose to expand the queries to include things other than class and
filter for out private api, but this won't be available using the OSGi api.
Don't think of this as just for OSGi. It is something that is available for
other deployments as well. It's just motivated by OSGi since it comes from their api.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265098#4265098
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265098
16 years, 4 months
[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
16 years, 4 months
[Management Development] - Simple Example using ManagedObjects and ProfileService
by rareddy
Hi,
I am trying to write a simple example to see how a service defined with @ManagedObject annotation in the JBossAS and then access it using the ProfileService. I wrote below sample code
Service in JBoss AS
| @ManagementObject(name="MyService")
| @ManagementComponent(type="foo", subtype="service")
| public class MyService {
|
| private String value = "property value";
|
| public void start() {
| System.out.println("Myservice has been started");
| }
|
| public void stop() {
| System.out.println("Myservice has been shut down");
| }
|
| @ManagementProperty(name="Myservice.value")
| public String getValue() {
| return this.value;
| }
|
| @ManagementOperation(description="Call me", impact=Impact.ReadOnly, params={@ManagementParameter(name="message", description="message to invoke")})
| public String callMe(String msg) {
| System.out.println("Somebody called me = "+msg);
| return msg + "called";
| }
| }
|
I bundled the above in to jar file and deployed into JBossAS. Then to access it, I wrote a simple JSP page like this
| <%@ page import="org.jboss.deployers.spi.management.*, org.jboss.managed.api.*, javax.naming.*, java.util.*, org.jboss.metatype.api.values.*" %>
| <HTML>
| <BODY>
| <%
| InitialContext ic = new InitialContext();
| ManagementView mgtView = (ManagementView)ic.lookup("java:ManagementView");
| ManagedComponent mc = mgtView.getComponent("MyService", new ComponentType("foo", "service"));
|
| SimpleValueSupport result = null;
| Set<ManagedOperation> operations = mc.getOperations();
| for (ManagedOperation op:operations) {
| if (op.getName().equals("callMe")) {
| result = (SimpleValueSupport)op.invoke(SimpleValueSupport.wrap("*"));
| }
| }
| %>
| Response from call is = <%= result.getValue() %>
| </TABLE>
| </BODY>
| </HTML>
|
When I execute this, I always end up in NPE on the response. I see the metadata on the object like its operations and properties etc, but not seemed to access the property values or invoke operations. I think I may be missing some step, can somebody please help or point toward a example?
I looked in "admin-console" code, but I did not see any difference from above.
Thank you.
Ramesh..
Teiid Team.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265092#4265092
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265092
16 years, 4 months
[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
16 years, 4 months