November 2009 - jboss-dev-forums - 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

14 years, 11 months

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

14 years, 11 months

1
0
0 / 0

[EJB 3.0 Development] - Re: EJBTHREE-1670 - Quartz scheduler integration failing on

by svante.p

I know this is a very old thread, but is there any work-arounds to this issue? I've tried manually assigning the subscriptionDurability property both through annotations and xml but the problem persists. Is there no possibility to run Quartz jobs on JBoss 5.0.0-GA? We can't take the risk of upgrading to 5.1 at this point. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265126#4265126 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265126

14 years, 11 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

I have filled in the TODOs locally and have fixed those tests. Part of those failures was being caused by this bug https://jira.jboss.org/jira/browse/JBREFLECT-66. Ales was also right that RegisterModuleCallback shoudln't ignore modules of other types different than AbstractDeploymentClassLoaderPolicyModule and this was causing part of the failures. After fixing both issues, I still see some failures. The problem here is that these failures are random and cannot be reproduced from my Eclipse test case environment. These are the tests that fail sometimes: ClassPoolTestCase.testHierarchyNonDeploymentModule JavassistTypeInfoTestCase.testDomainHierarchy JavassistTypeInfoTestCase.testHierarchyNonDeploymentModule I'll continue investigating. Once I have all this sorted out, I'll commit the full version of those tests. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265123#4265123 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265123

14 years, 11 months

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

14 years, 11 months

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

14 years, 11 months

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

14 years, 11 months

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

14 years, 11 months

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

14 years, 11 months

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

14 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2009