November 2009 - jboss-osgi-dev - Jboss List Archives

[JBoss OSGi Development] - Define non OSGi bundle handling by the Framework

by thomas.diesler＠jboss.com

https://jira.jboss.org/jira/browse/JBOSGI-203 There have been changes going forth and back with respect to non-osgi deployment handling. The objectives and scope of functionality still need to be defined. I had to roll-back recent changes in the handling of non-osgi deployemnts because those broke AS integration You can run the AS integration test using http://jbmuc.dyndns.org:8280/hudson/job/jbossosgi-jdk16/ The minimum requirement to verify the validity of AS integration related changes would be to startup AS and check that you can see the jboss-osgi console. http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapGettingStarted.html... Could you please present your ideas with respect to non-osgi bundle handling by the framework? cheer View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265143#4265143 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265143

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Don't leak implementation details

by thomas.diesler＠jboss.com

ok, thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265142#4265142 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265142

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Don't leak implementation details

by adrian＠jboss.org

The method getBundleState() on the OSGiBundleWrapper is package protected so that ordinary users can't get to the implementation details and do dangerous things. Making this method public defeats the point of having the wrapper in the first place. I've moved this mapping "feature" to the OSGiBundleManager, since anybody who can get access to that, can pretty much do what they like anyway. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265121#4265121 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265121

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - PROPERTY_AUTO_START

by adrian＠jboss.org

Further to the resolver discussion; I've removed the use of PROPERTY_AUTO_START since this is already available in the deployment layer as DeploymentUnit.getRequiredStage() Any processing done in OSGi, should respect what other apis choose for this flag, although AFAIK nobody else uses it? As far as I understand it, the purpose is to not "start" (resolve) bundles unless they are needed by classloading or something in persistent storage says they should be started. The setting of the RequiredStage is already done by the OSGiBundleStateDeployer when the bundle is installed, but there is currently no persistent state, so there is a TODO there. I've still yet to understand what all this extra processing is actually doing. >From what I described on a different thread, this processing is also broken: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160839 I don't mean the choice of wrapper versus extension which is just a choice of elegance and maintainability. NOTE: This is very different from the lazy start feature of OSGi where we should leave the deployment in the CLASSLOADER/RESOLVED stage until somebody loads a class. What is happening here is things are being moved to the INSTALLED/ACTIVE stage out of the normal sequence. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265118#4265118 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265118

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Handle potential bundle:// protocol with VFS

by alesj

"thomas.diesler(a)jboss.com" wrote : | Accessing a resources across bundles, you could do | | | | sysContext.getBundle(someId).getResource("/some-resource.txt") | | | | The return could be a VFS URL. I still don't quite understand the benefit of introducing/using an alternative URL representation. | | Do you have a specific use case in mind, that you could present here? 1) You're using code, not URL or plain string. Users != no OSGi api 2) With direct VFS usage, you're by-passing restrictions enforced by bundles With bundle:// approach, we handle both cases properly. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265112#4265112 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265112

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Adding binary dependencies

by thomas.diesler＠jboss.com

Folks, JBoss OSGi releases are QAed against a matrix of runtimes. For the MC based Framework, this is currently AS520 and AS600 http://jbmuc.dyndns.org:8280/hudson/job/jbossosgi-matrix-jbossmc Any binary dependency we introduce, must either be available already in AS or be installed by the installer. For core services this might not always be possible. For example, we cannot use a SNAPSHOT version of jboss-vfs if that cannot be used by the AS instances JBoss OSGi supports. As a consequence, I had to rollback the recent update to jboss-vfs. cheers View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265111#4265111 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265111

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Handle potential bundle:// protocol with VFS

by thomas.diesler＠jboss.com

anonymous wrote : | although this is not standard, osgi devs do use it quite a lot to find resources across bundles | Accessing a resources across bundles, you could do | sysContext.getBundle(someId).getResource("/some-resource.txt") | The return could be a VFS URL. I still don't quite understand the benefit of introducing/using an alternative URL representation. Do you have a specific use case in mind, that you could present here? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265109#4265109 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265109

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Handle potential bundle:// protocol with VFS

by david.lloyd＠jboss.com

"alesj" wrote : "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? | The problem was that the uuid in the host name field isn't a valid host name, so things that expect it to be one failed when they tried to do DNS lookups and so forth. This is the real abuse - the lesson is that for URLs, the host name field should only contain a host name, and the port field should only contain a port. If there is no host name or port, then the URL scheme-specific part should start with "///" and any additional data should be contained afterwards. Or, use a URI instead. "alesj" wrote : "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. | It's not an abuse, it's in line with the design (well, of VFS3 anyway). Also, using file: has the advantage of working with the default security manager policy parser without having to add yet more handler stubs to the boot classpath. I think there's a lot of power to be had by mounting OSGi bundles in a consistent file-based scheme for VFS3. It would make finding resources a snap, and it could potentially simplify bundle classloaders as well. Basically it solves all the problems that bundle: does, and it has additional benefits besides. Seems like a perfect fit to me. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265108#4265108 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265108

15 years, 1 month

1
0
0 / 0

[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

15 years, 1 month

1
0
0 / 0

[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

15 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-dev November 2009