|
Great, sounds like we have a common understanding now of what needs to/should be done.
Looking forward to your contributions :-)
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: cf-dev-bounces@xxxxxxxxxxx <cf-dev-bounces@xxxxxxxxxxx> on behalf of Fauth Dirk (AA-AS/EIS2-EU) <Dirk.Fauth@xxxxxxxxxxxx>
Sent: Thursday, March 23, 2017 13:30
To: Californium (Cf) developer discussions
Subject: Re: [cf-dev] Californium on OSGi
1.
Yes PR for proper OSGi meta-data is created
2.
Well it would make the world easier for Eclipse developers. But yes, it is not required. It even would not help if you work with Bndtools. I will write a blog post
to show how you can easily set up a workspace with either PDE or Bndtools. But that will only work if my PR is merged.
3.
I will provide an alternative implementation based on Declarative Services. The usage of a ServiceTracker that is registered in an Activator is not wrong by default.
Several default OSGi services are using that approach to avoid a dependency to DS. But from my point of view DS has become a standard that is widely used in OSGi applications, and it makes the implementation much easier. For sure that is not a mandatory thing.
I will try to implement a DS based solution I can share with you.
4.
OK, simply a documentation thing.
J
5.
Yes, the automatic start is something discussable. From what I see in code it looks like you need to decide what you need before starting the server. This could
be also done dynamically, as you are using the ConfigurationAdmin. And using DS the change of the EndpointFactory could affect also a restart of the server. Something we can look at with my upcoming proposal.
And yes a managed service should be created and started with a configuration, but starting a server with providing null feels incorrect. ;-)
If there is no hard deadline at the moment I can try to work on a proposal to change californium-osgi, or at least provide an alternative.
Mit freundlichen Grüßen / Best regards
Dirk Fauth
Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen |
GERMANY |
www.bosch.com
Tel. +49(7153)666-1155 | Dirk.Fauth@xxxxxxxxxxxx
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Dr. Werner Struth, Peter Tyroller
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Kai
Gesendet: Donnerstag, 23. März 2017 10:02
An: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
Betreff: Re: [cf-dev] Californium on OSGi
See my comments below
Hi,
I am evaluating Californium for usage inside an OSGi application. I stumbled across several issues I would like to discuss:
1.
Inconsistent providing of OSGi meta-data
Some bundles provide proper OSGi meta-data, some not. IMHO all provided bundles should provide proper OSGi meta-data
I agree, as long as that does not introduce any mandatory dependencies on any OSGi artifacts.
californium-core-2.0.0-M3 – no OSGi meta-data
californium-proxy-2.0.0-M3 – no OSGi meta-data
element-connector-2.0.0-M3 –OSGi meta-data provided
scandium-2.0.0-M3 – OSGi meta-data provided
IMHO also core and proxy should provide proper OSGi meta-data
I do not see why they shouldn't (assuming the constraint above is met).
I see that you have already created a PR for that. Thanks :-)
2.
Californium bundles not available for installation in Eclipse
To include Californium in an OSGi bundle, it needs to be downloaded from Maven Central and manually included in the target platform. I’m not sure how good it would work with Bndtools, as they have a different repository approach. But
for Eclipse PDE this is not very elegant. For this the Californium bundles should be provided via p2 Update Site. Of course that also means that all projects are provided with proper OSGi information.
IMHO that is not entirely true. This might be an issue if you want to do OSGi development based on Eclipse's PDE. However, many Cf users do not even use the Eclipse IDE. We currently do not see any particular demand for distributing Cf
artifacts by means of an Eclipse p2 repository. In fact, you are the first person even mentioning it :-) I have no idea what setting up and maintaining a p2 update site requires initially and continuously. Maybe you can shed some light on the required steps?
Does it simply require another step in the build process?
3.
californium-osgi not modular
That bundle is not really modular in the sense of OSGi. It contains the contents of core and element-connector aswell as the OSGi extension. element-connector already provides OSGi meta-data. core would need the OSGi meta-data as said
in 1. Then it should be possible to put things together on the bundle level, not putting things together in one big bundle. But I’m not sure if there are some Classloader operations inside that would avoid the clear bundle separation.
That's true. I didn't like this from the beginning :-) Matthias' concern was that he didn't want to introduce any dependency on OSGi to the original californium library artifact. However, FMPOV this problem (or risk) does not exist as
adding the OSGi metadata to the manifest does not require anybody to use OSGi in the first place. We are not doing any "fancy classloader" stuff so personally I wouldn't have a problem with doing it "the right way", i.e. turining californium-core into a bundle
and keep the stuff that depends on OSGi classes in the californium-osgi bundle.
4.
Netty dependency (almost) nowhere mentioned
I nowhere found Netty being mentioned as a dependency. Well it is mentioned in the MANIFEST of element-connector. Without the io.netty bundles in place, californium-osgi is not starting. If I follow the Hands-on tutorial Netty is now
mentioned and not needed to start the server. So I wonder if io.netty is really required or an optional dependency.
It is defined as a dependency in the pom.xml. And yes, it is required by element-connector because it is used for implementing the TcpConnector. However, the corresponding imports are probably in place on element-connector ...
5.
ManagedServer not started automatically
californium-osgi contains a ManagedServer, which is a managed service that can be configured via ConfigurationAdmin and provides the white-board-pattern for registering Resources dynamically. A good idea so far, but the service is not
registered automatically and therefore the server is not started. Users need to know that they have to do this manually and of course also how to do this.
When I originally wrote the managed service I put some thought into the question whether it would make sense to automatically start the server. I explicitly decided against doing so but I cannot recall what the main reasons actually where.
I guess they revolved around keeping the user in control of what gets started and what not.
IMHO the ManagedServer should be an Immediate Component, with a required configuration.
This would enable to create multiple servers in one runtime with different configurations. Not sure if that makes sense, otherwise it should be a singleton service. It should have a service reference to EndPointFactory. DYNAMIC GREEDY to support dynamic exchange
of it. Does that make sense?
I haven't been working with OSGi over the last 15 months so I somewhat lost track of the current developments and best practices in that area. Consequently, I do not know what an "Immediate Component" is. If you feel that we should change
something, I would be open for discussion but I am afraid you would need to educate us a little more about the plans you have and what that means.
I also noticed that there is no way to start the server. In its current state I need to create the ManagedServer
instance and call update(null) to start it. It therefore requires a configuration to be set although it says it can start with a default configuration. This is also not very consistent.
Isn't that the way it is supposed to work when using ConfigurationAdmin?
For the last point I think I can try to provide something via PR. Need to test what I am able to do. But for the other topics I’m
unsure. The first point looks like it could be solved easily by updating the pom.xml. The second is a bit more complicated, not sure if Eclipse Bundle Recipes could help here. 3. is dependent on whether core is doing some Classloader stuff or not, otherwise
also a pom.xml point. And 4. is more a question in first place. If it is optional it is also a pom.xml topic.
Would be great if I could get some response on this. As far as it is possible for me, I would be also glad if I could help. Actually
I’m even planning to write a small blog post about using Californium in OSGi, to give people some advice.
Additionally I have another question. When is the planned release date of 2.0.0? I see and test currently with a 2.0.0-M3. The Eclipse
project page doesn’t mention a 2.0.0 release with a release date. Is M3 already so close to the release that the needed OSGi changes can’t be added anymore?
There is no release date yet. There are some issues we think need to fixed as part of 2.0.0, though. So, the best estimate would be: as soon as the "bucket list" [1] has been processed, we will do a 2.0.0 release :-) This also means that
there still is time enough for you to create PRs that you would like to see going into 2.0.0...
Mit freundlichen Grüßen / Best regards
Dirk Fauth
Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen |
GERMANY | www.bosch.com
Tel. +49(7153)666-1155 |
Dirk.Fauth@xxxxxxxxxxxx
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Dr. Werner Struth, Peter Tyroller
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
|
