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

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

by alesj

WRT https://jira.jboss.org/jira/browse/JBOSGI-201 "alesj" wrote : | We should be able to handle bundle:// protocol. | e.g. bundle://<bundle_id>/<resource_path> | "thomas" wrote : | Could you perhaps give a use case for this functionality? | "alesj" wrote : | Instead of sharing resources among bundles with full resource path, | you can simply reference bundles directly (currently via id), hence hiding the details. | "dml" wrote : | However this is done, it shouldn't use the host name field (recall the problems with vfsmemory URLs). 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. | "thomas" wrote : | Resources could be shared by the bundle root VirtualFile, no? | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264921#4264921 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264921

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Use Drools for the Bundle Resolver

by tirelli

If you want to check that there is no other WireCandidate besides the one matched, you could use "not": | rule "Use WireCandidate" | when | $import : ImportPackage( exporter == null ) | $wc : WireCandidate( importPackage == $import ) | not( WireCandidate( this != $wc, importPackage == $import ) ) | then | System.out.println("Use WireCandidate " + $wc.getImportPackage() + " --> " + $wc.getExportPackage()); | modify ( $wc.getImportPackage() ) { setExporter( $wc.getExportPackage() ) }; | retract ( $wc ); | end | Now, if you want a more general way of counting instances, use the count() function on accumulate: | rule "Use WireCandidate" | when | $import : ImportPackage( exporter == null ) | $wc : WireCandidate( importPackage == $import ) | // checks if the is exactly 1 instance | Number( intValue == 1 ) from accumulate( | $c : WireCandidate( importPackage == $import ), | count($c) ) | then | System.out.println("Use WireCandidate " + $wc.getImportPackage() + " --> " + $wc.getExportPackage()); | modify ( $wc.getImportPackage() ) { setExporter( $wc.getExportPackage() ) }; | retract ( $wc ); | end | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264895#4264895 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264895

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Use Drools for the Bundle Resolver

by thomas.diesler＠jboss.com

I currently investigate the use of Drools for the OSGi Bundle Resolver algorithm. To that respect I wonder what is the recommended way to count a certain fact. I'd like to fire an action if there is exactly one fact for a given constraint | rule "Use WireCandidate" | when | $import : ImportPackage( exporter == null ) | $wc : WireCandidate( importPackage == $import ) | // TODO: only do this if there is exactly one WireCandidate | then | System.out.println("Use WireCandidate " + $wc.getImportPackage() + " --> " + $wc.getExportPackage()); | modify ( $wc.getImportPackage() ) { setExporter( $wc.getExportPackage() ) }; | retract ( $wc ); | end | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264893#4264893 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264893

14 years, 6 months

1
0
0 / 0

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

by alesj

"alesj" wrote : | * Service --> MC | What to do about tracking this "OSGi --> MC" injection? If we add this service to bundle's inUse, then there is no proper callback to decrease inUse count. Which in the case of ServiceFactory (SF) means SF::ungetService might never be called. We can completely ignore bundle service count + serviceCache, but potentially some service unregister could invoke SF::ungetService, although we would still be using it in MC bean. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264791#4264791 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264791

14 years, 6 months

1
0
0 / 0

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

by alesj

I'm actually wondering what's the best or proper way to expose or use this services in MC. What should be the keys that we expose or match. "alesj" wrote : | * Service --> MC | In OSGi service we expose classes and properties. Probably the key could look something like this: * org.jboss.acme.X,org.jboss.acme.Y;(a=b) a set of FQNs and a filter. Only matching services that expose all the FQNs and match the filter. Perhaps if there are no properties, we could directly expose service under registered classes? "alesj" wrote : | * MC --> Service | This looks easier from matching pov - simply do an intersection on the contexts that type match given FQNs (classes). But how to mock (or even get) beans bundle? Where this mock could be done, what about its "using bundles"? Only count this in previous mock bundle, but ignore plain MC bean injection / usage? "adrian(a)jboss.org" wrote : | 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. | Or what exactly did you have in mind here? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264706#4264706 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264706

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - JBoss OSGi logging policy

by thomas.diesler＠jboss.com

Logging in JBoss OSGi is done through multiple logging frameworks. There are bundles that use commons-logging, slf4j and of course jboss-logging. Ultimately all logging is routed to log4j. For surefire tests this is the same. Every (reactor) module contains a log4j configuration in | src/test/resources/log4j.xml | All surefire tests MUST write their their test log to | target/test.log | This file is processed by hudson jobs after the surefire test run. The log4.xml files contain these settings | <appender name="FILE" class="org.apache.log4j.FileAppender"> | <param name="File" value="${log4j.output.dir}/test.log"/> | ... | </appender> | | <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> | <param name="Target" value="System.out" /> | <param name="Threshold" value="INFO" /> | ... | </appender> | | <root> |  | <appender-ref ref="FILE"/> | </root> | There are many projects under the JBoss OSGi umbrella. For log file consistency and meaningful hudson console output, please respect this policy and do not change the log configuration light heartedly. cheers View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4264426#4264426 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4264426

14 years, 6 months

1
0
0 / 0

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

by adrian＠jboss.org

This has been done, but I've still got https://jira.jboss.org/jira/browse/JBOSGI-200 TODO View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263738#4263738 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263738

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Thread safety and collections

by adrian＠jboss.org

https://jira.jboss.org/jira/browse/JBOSGI-199 I spotted while I was looking at how the osgi-framework code uses the metadata that there are a number of places using unsynchronized HashMap, ArrayList, etc. for mutable data. The original one I spotted was a cache of attributes, but searching for HashMap I found others introduced in the BundleManager and the Resolver. Besides not being thread safe - for things like HashMap or LinkedList this can cause the code to go into a infinite loop when links end up pointing at themselves due to concurrent modification. I've only looked at and corrected the framework code. But there's obviously other places that have this problem, e.g. /jboss-osgi-deployment/src/main/java/org/jboss/osgi/deployment/internal/DeploymentRegistryServiceImpl.java has an unsynchronized HashMap to track deployments. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263690#4263690 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263690

14 years, 6 months

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