Am 8. März 2012 15:36 schrieb Richard S. Hall <[email protected]>: > On 3/8/12 07:14 , Benedikt Ritter wrote: >> >> Regarding the BundleTracker: If we want to use the OSGi BundleTracker, >> we will have to update the felix version, the example is using. >> Currently the example has a dependency to org.apache.felix.main 1.8.0. >> That's quite outdated :-) At the time of 1.8.0 there was no >> BundleTracker in OSGi... How about moving on to 4.0.2? > > > Definitely, we should move to the latest. >
Okay, I've implemented an OSGi BundleTracker using felix.main 4.0.2 in my workspace. I'll wait until you have reviewed the patch for the non-felix-specific application launch. If you agree with the patch, I can merge everything together once you have applied it and create a new patch for the BundleTracker. Benedikt > -> richard > > >> >> Benedikt >> >> Am 8. März 2012 03:26 schrieb Richard S. Hall<[email protected]>: >>> >>> On 3/7/12 18:22 , Benedikt Ritter wrote: >>>> >>>> Am 8. März 2012 00:03 schrieb Benedikt >>>> Ritter<[email protected]>: >>>>> >>>>> Am 7. März 2012 23:40 schrieb Richard S. Hall<[email protected]>: >>>>>> >>>>>> >>>>>> On 3/7/12 17:12 , Benedikt Ritter wrote: >>>>>>> >>>>>>> Am 7. März 2012 17:26 schrieb Richard S. Hall (Commented) (JIRA) >>>>>>> <[email protected]>: >>>>>>>> >>>>>>>> [ >>>>>>>> >>>>>>>> >>>>>>>> https://issues.apache.org/jira/browse/FELIX-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224477#comment-13224477 >>>>>>>> ] >>>>>>>> >>>>>>>> Richard S. Hall commented on FELIX-3376: >>>>>>>> ---------------------------------------- >>>>>>>> >>>>>>>> I committed these patches with only minor modifications. >>>>>>>> >>>>>>>> One thing I thought about was we could potentially replace the >>>>>>>> custom >>>>>>>> BundleTracker with the standard OSGi BundleTracker...although I'm >>>>>>>> torn >>>>>>>> on >>>>>>>> this a little since our custom BundleTracker is simpler and it does >>>>>>>> provide >>>>>>>> a good example of how to create such a thing. >>>>>>> >>>>>>> I agree with you about BundleTracker. We should try to reuse stuff >>>>>>> that's already out there, even if it is a little more complex. People >>>>>>> will tend to reuse the code they see in examples. So it's better to >>>>>>> show them "the right way". >>>>>>> >>>>>>> Speaking of reusing stuff: Java 6 has a nice solution for creating >>>>>>> the >>>>>>> FrameworkFactory >>>>>>> >>>>>>> >>>>>>> (http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html). >>>>>> >>>>>> >>>>>> I wouldn't go so far as calling it "nice", but it is a solution... ;-) >>>>>> >>>>>> >>>>>>> Looking at the bunch of code I've ridden to parse the >>>>>>> org.osgi.framework.launch.FrameworkFactory file, that would make >>>>>>> things easier. If you don't feel to comfortable about Java 6, I would >>>>>>> at least recommend to add a comment point users to the javadocs >>>>>>> above. >>>>>>> >>>>>>> What do you think? >>>>>> >>>>>> >>>>>> In the end, I don't care. The original approach was taken to allow it >>>>>> to >>>>>> work on older JVMs. Since we are breaking that now, it doesn't really >>>>>> matter >>>>>> any more if we use ServiceLoader. >>>>>> >>>>>> -> richard >>>>>> >>>>> Okay, I'm almost done with it. I can start up the framework, and >>>>> install all bundles using the BundleContext. But I'm having a problem >>>>> to start the host bundle the right way. Sure I could simply >>>>> instantiate the Activator myself and pass the bundleContext to its >>>>> start method, but then the framework does not know about the host >>>>> bundle (very ugly). >>>>> What I need is something like >>>>> FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, so that I can pass an >>>>> Activator instance to the framework. If I can accomplish that, I've >>>>> eliminated all dependencies to felix and the patch is ready to be >>>>> applied. >>>>> >>>>> Benedikt >>>>> >>>> I've inspected the bundles that get installed if the activator is >>>> passed via FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP. The host >>>> bundle is not a part of framework.getBundleContext().getBundles(). So >>>> I guess, my first approach is acceptable (manual instantiation). >>>> I'll do some clean up and upload the patch to JIRA tomorrow. >>> >>> >>> Yes, the host is not installed in the embedded scenario, by definition. >>> The >>> host is on the outside and the extension bundles are on the inside...this >>> is >>> pretty much the definition of the embedded scenario. Essentially, the >>> host >>> bundle is represented by the system bundle, since it is how packages are >>> exported from the host and how it can use services from the inner bundles >>> (i.e., via the system bundle context). >>> >>> -> richard >>> >>> >>>> Benedikt >>>> >>>>>>> Benedikt >>>>>>> >>>>>>>> Please close this issue if you are satisfied. Thanks. >>>>>>>> >>>>>>>>> Update extenderbased SimpleShapes example to use Java 5 Features >>>>>>>>> ---------------------------------------------------------------- >>>>>>>>> >>>>>>>>> Key: FELIX-3376 >>>>>>>>> URL: >>>>>>>>> https://issues.apache.org/jira/browse/FELIX-3376 >>>>>>>>> Project: Felix >>>>>>>>> Issue Type: Improvement >>>>>>>>> Reporter: Benedikt Ritter >>>>>>>>> Priority: Trivial >>>>>>>>> Attachments: FELIX-3376-extenderbased.circle.txt, >>>>>>>>> FELIX-3376-extenderbased.host.txt, >>>>>>>>> FELIX-3376-extenderbased.square.txt, >>>>>>>>> FELIX-3376-extenderbased.triangle.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> This follows up on FELIX-3375. >>>>>>>> >>>>>>>> -- >>>>>>>> This message is automatically generated by JIRA. >>>>>>>> If you think it was sent incorrectly, please contact your JIRA >>>>>>>> administrators: >>>>>>>> >>>>>>>> >>>>>>>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa >>>>>>>> For more information on JIRA, see: >>>>>>>> http://www.atlassian.com/software/jira >>>>>>>> >>>>>>>> >
