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

[JBoss OSGi Development] - Re: Proper system BundleContext implementation

by thomas.diesler＠jboss.com

I am working on https://jira.jboss.org/jira/browse/JBOSGI-133 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251809#4251809 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251809

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Performance problem

by alesj

"adrian(a)jboss.org" wrote : | I'll have a look at it later this week once I've finished working on my current stuff, | if you haven't already found it by then. :-) Don't count on me too much, as I was just pushed to some EAP docs. :-( View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251796#4251796 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251796

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Performance problem

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | The issue is why is there x4 performance degradation. | | | I still don't know what you changed, if you changed anything at all? | I'm saying if you can't work out what changed, try it from the other direction. What is causing the 24 seconds delay with and without that one line patch above? Once that is determined it should be obvious what changed? ;-) I'll have a look at it later this week once I've finished working on my current stuff, if you haven't already found it by then. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251781#4251781 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251781

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Proper system BundleContext implementation

by adrian＠jboss.org

The issue is not really that, it is what we were talking about on the other thread. The system bundle is not a real deployment, it effectively represents the bootstrap classloader so it needs to adopt that classloader and use it where the deployment gets used. This is what 3.4 calls the "Framework Classpath". But there are other considerations in the spec such as; 3.8.3 - Parent Delegation - which is actually already worked around by the JDKProvider stuff 3.8.5 - System packages 3.14 - Extension Bundles - although they are optional in the spec If you want to factor out the common code into an AbstractBundleState rather than having OSGiSystemBundle extend OSGiBundleState then go ahead, but do it quickly. ;-) I'm currently looking at the manifest parsing so you are not going to break what I'm working on. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251776#4251776 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251776

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Performance problem

by alesj

"adrian(a)jboss.org" wrote : | The issue is why is there x4 performance degradation. | I still don't know what you changed, if you changed anything at all? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251769#4251769 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251769

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Performance problem

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : But its not coming from there. Its using a transient dependency on deployers-vfs-spi which is currently at snapshot. | | | Sure, that's why I'm saying: | alesj wrote : | | as I'm pretty sure Kernel 2.0.6.GA and Deployers 2.0.8.GA use the latest one. | | | | "adrian(a)jboss.org" wrote : | | So who knows what it used before? ;-) | | | I know. ;-) | | Deployers' VFS update: | - http://fisheye.jboss.org/browse/JBossAS/projects/jboss-deployers/branches... | still being done on 2.0.7. | So, unless someone downgraded VFS in the meanwhile, 2.0.8. should have VFS 2.1.2.GA. Anyway, the real issue isn't trying to find out what Maven is/was doing, that was just to try to locate what code changed and might have introduced the problem. The issue is why is there x4 performance degradation. In particular why is it taking 24 seconds to parse some manifests when previously I could run the whole testsuite in less than half that time. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251765#4251765 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251765

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: HOWTO chage the behaviour of the CL policy

by adrian＠jboss.org

So let's do it the same way. I haven't really looked at this part of the spec yet but its certainly something I planned to address. There's no reason why the SystemBundle classloader couldn't be defined in the bootstrap to expose the osgi core packages (and maybe some services) instead of letting them bubble up to the "classpath" using the parent policy. The other services would just be deployed as bundles. i.e. just make the parent policy in OSGiClassLoaderSystem ParentPolicy.BEFORE_BUT_JAVA_ONLY then have the following in the bootstrap.xml to be the "system bundle classloader" | <deployment xmlns="urn:jboss:bean-deployer:2.0"> | | <classloader><inject bean="system-bundle:4.4.2" /></classloader> | | <classloader name="system-bundle" | version="4.4.2" | xmlns="urn:jboss:classloader:1.0" | > | <root>${jboss.lib.url}osgi-core.jar</root> | <root>${jboss.lib.url}jboss-osgi-impl.jar</root> | <capabilities> | <package name="org.osgi.framework" version="1.4.0"/> | <package name="org.osgi.service.packageadmin" version="1.2.0"/> | <etc./> | </capabilities> | </classloader> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251749#4251749 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251749

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Change in manifest parser breaks symbolic name

by adrian＠jboss.org

The parsing of ParameterAttribute(s) and its decendent classes was already broken. The issue is in the javacc generated code. The change I made was to parse the BundleSymbolicName as a ParameterAttribute instead of a plain string because it has directives and attributes, e.g. Bundle-Symbolic-Name=foo.bar;singleton=true The reason is that the grammer is ambigous so sometimes it thinks it is parsing a PATH when it should be parsing a QNAME. The "tokenizer" part of the code is generating a wrong token and then it fails to match in the parsing. There's a commented out test with a TODO in the package import testing because of this. Fixing this parsing problem is on my list of things to fix. P.S. This is an "anti-pattern" | public String getBundleSymbolicName() | { | | <snip/> | | if (symbolicName == null) | throw new IllegalStateException("Cannot obtain " + Constants.BUNDLE_SYMBOLICNAME); | | return symbolicName; | } | You shouldn't put validation logic in the metadata model. This validation of the model should be done when we are asked to install the bundle so that others can augment/vary the model. e.g. you could imagine a custom deployer that does for example | OSGiMetaData md = ...; | if (md.getBundleSymbolicName() == null) | // generate one | Instead your validation in the getter would mean it has to catch the exception which is counter intuitive. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251737#4251737 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251737

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Proper system BundleContext implementation

by thomas.diesler＠jboss.com

Please assign the issue to yourself and 'Start Progress' on it. Generally we can use this process to avoid duplicate work. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251723#4251723 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251723

15 years

1
0
0 / 0

[JBoss OSGi Development] - Proper system BundleContext implementation

by thomas.diesler＠jboss.com

https://jira.jboss.org/jira/browse/JBOSGI-138 Currently we have OSGiSystemBundle extends OSGiBundleState which initializes the OSGiBundleState with a null DeploymentUnit All Bundle and BundleContext methods that internally access the DU fail for the system bundle An improved abstraction would be OSGiSystemBundle extends AbstractBundle OSGiBundle extends AbstractBundle View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251722#4251722 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251722

15 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-dev August 2009