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

[JBoss OSGi Development] - Re: @Override and JDK5 usage

by thomas.diesler＠jboss.com

Set the Compliance level to 5.0 (Eclipse -> Window -> Preferences -> Java -> Compiler -> Compiler compliance level View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252183#4252183 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252183

15 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by alesj

"alesj" wrote : "adrian(a)jboss.org" wrote : | | The big problem with doing this now is that it would make it difficult to drop the OSGi | | layer into existing jboss releases since we can't change their MC implementations to do this. | | | | There's probably some compromise we can reach between the two extremes | | and leave the proper solution to a future major release of JBoss. | | | I don't understand what the big problem you see is? | Ah, scratch this. :-) Re-reading it once again, and actually using tiny part of the brain that is not asleep yet, helped. I wouldn't bother with previous releases. Or should we? As we're already using CL and Deployers snapshots, I guess we could fix Dependency and Kernel as well, still on the 2.0.x branch, to fit our needs. In the worst case making new 2.1.x branch, same as we did for VFS and Man, which could still be part of JBoss 5.x (aka "existing" jboss releases), leaving bigger MC 2.2.x refactorings for 6.x. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252153#4252153 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252153

15 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by alesj

"adrian(a)jboss.org" wrote : | The big problem with doing this now is that it would make it difficult to drop the OSGi | layer into existing jboss releases since we can't change their MC implementations to do this. | | There's probably some compromise we can reach between the two extremes | and leave the proper solution to a future major release of JBoss. | I don't understand what the big problem you see is? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252152#4252152 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252152

15 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Service integration with MC

by alesj

and vice versa. * Service --> MC "adrian(a)jboss.org" wrote : | The service layer is not so well integrated with the MC. It does just enough to | be "OSGi compliant" (of course that's not yet tested). So this is at the | moment very simple. | The OSGiServiceState which should eventually turn into an MC context implementation | has two "facades", the standard ServiceRegistration and ServiceReference interfaces. | * MC --> Service "adrian(a)jboss.org" wrote : | Services are also largely complete. What's missing is that we want to expose | MC pojos and JMX MBeans etc. as OSGi services. | | The proper way to do this would be to push the OSGi Filter into kernel project | and use the MDR INSTANCE scope as the attributes. | There would be a gotcha in that OSGi expect attributes to have case insensitive names, | but we would only have to enforce that for OSGi created services. | Unless you already started on this, I would like to have a crack at it once I return from JBW. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252151#4252151 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252151

15 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - @Override and JDK5 usage

by alesj

I'm getting compile errors since we're using @Override on interface impl methods. Afaik this is JDK6 feature, whereas we still wanna be JDK5 compatible. And Pete tells me this is auto feature of Eclipse if you're running JDK6. So, either use IDEA or turn this off. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252131#4252131 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252131

15 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Invalid delivery of framework events

by thomas.diesler＠jboss.com

https://jira.jboss.org/jira/browse/JBOSGI-140 Although a listener is associated with a bundle context (i.e. must get removed when the bundle gets uninstalled) the events must get delivered to the listeners that are associated with the framework. sysContext.addBundleListener(listenerA); Bundle bndA = sysContext.install("bundleA.jar"); bndA.getBundleContext()..addBundleListener(listenerB); Bundle bndB = sysContext.install("bundleB.jar"); bndB.uninstall(); Both listenerA and listenerB must see the BundleEvents for bundleB. This delivery pattern is the basis of the much used "Extender Pattern" View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252048#4252048 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252048

15 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Added proper handling of framework properties

by thomas.diesler＠jboss.com

Framework properties can now be configured on the OSGiBundleManager | <bean name="OSGiBundleManager" class="org.jboss.osgi.plugins.facade.bundle.OSGiBundleManager"> | <constructor><parameter><inject bean="MainDeployer" /></parameter></constructor> | <property name="properties"> | <map keyClass="java.lang.String" valueClass="java.lang.String"> | <entry><key>org.osgi.framework.storage</key><value>${log4j.output.dir}/osgi-store</value></entry> | <entry><key>org.osgi.framework.storage.clean</key><value>onFirstInit</value></entry> | <entry><key>org.osgi.framework.system.packages.extra</key><value> | org.jboss.logging;version=2.0, | org.jboss.osgi.spi.logging;version=1.0, | org.jboss.osgi.spi.management;version=1.0, | org.jboss.osgi.spi.service;version=1.0, | org.jboss.osgi.spi.util;version=1.0 | </value></entry> | </map> | </property> | <incallback method="addPlugin" /> | <uncallback method="removePlugin" /> | </bean> | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252022#4252022 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252022

15 years, 4 months

1
0
0 / 0

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

by thomas.diesler＠jboss.com

anonymous wrote : | This validation of the model should be done when we are asked to install the bundle | so that others can augment/vary the model. | ok View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252007#4252007 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252007

15 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - OSGi classloader system

by thomas.diesler＠jboss.com

Folks, I'd like to better understand how the classloader system works. Could you please talk me through the code below and explain what is being done here. Eventually, I'd like to be able to setup a Framework Classloader with the configured packages in 'org.osgi.framework.system.packages' and 'org.osgi.framework.system.packages.extra' | /** | * Create a new OSGiClassLoaderSystem. | * @param bundleManager the bundleManager | * @throws IllegalArgumentException for a null bundle manager | */ | public OSGiClassLoaderSystem(OSGiBundleManager bundleManager) | { | if (bundleManager == null) | throw new IllegalArgumentException("Null bundle manager"); | | ClassLoaderDomain domain = getDefaultDomain(); | | // Initialize the configured system packages | String sysPackageString = getSystemPackagesAsString(bundleManager); | PatternClassFilter filter = PackageClassFilter.createPackageClassFilterFromString(sysPackageString); | filter.setIncludeJava(true); | | domain.setParentPolicy(new ParentPolicy(filter, ClassFilter.NOTHING)); | AbstractJDKChecker.getExcluded().add(AbstractBundleState.class); | AbstractJDKChecker.getExcluded().add(OSGiBundleState.class); | } | | @Override | protected ClassLoaderDomain createDomain(String name) | { | return new ClassLoaderDomain(name); | } | | protected BaseClassLoader createClassLoader(ClassLoaderPolicy policy) | { | return new OSGiBundleClassLoader(policy); | } | when done, I could probably remove this hack | // [TODO] Should system packages be added as capabilities? | boolean isSystemPackage = syspackPlugin.isSystemPackage(packageName); | if (isSystemPackage == false) | { | OSGiPackageRequirement requirement = OSGiPackageRequirement.create(packageAttribute); | requirements.addRequirement(requirement); | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251995#4251995 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251995

15 years, 4 months

1
0
0 / 0

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

by thomas.diesler＠jboss.com

We now have OSGiSystemState extends AbstractBundleState OSGiBundleState extends AbstractBundleState View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251993#4251993 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251993

15 years, 4 months

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