Sorry, I meant Rule and not FunctionThrowsException On Fri, Sep 9, 2016 at 9:47 AM, David Daniel <[email protected]> wrote:
> For me I don't think it is the change to new that is concerning but I am > also concerned with the departure from the OSGI dependencies and way of > doing things. I would prefer an implementation that does something like > includes FunctionThrowsException from a whiteboard pattern with a prototype > scope to determine the standard rules in the felix implementation (I can > understand why you are not doing this in the current implementation because > then it be dependent on osgi). I can see how I can expose a converter as a > service and add the rules I want but it would not be very standard. > Libraries that I use for stuff like rest or something else would not use my > converter service. If I wanted libraries to use my converter > implementation I would have to write my own custom converter bundle but > then I would lose out on having a well tested bundle that is used in many > applications. I can understand the new route but I personally prefer the > old one and am a fan of OSGI. > > David Daniel > > On Thu, Sep 8, 2016 at 11:00 PM, David Leangen <[email protected]> wrote: > >> >> :-) >> >> “new” (or static) for non OSGi code, the usual service acquisition for >> OSGi environments. The basic idea was to separate API from Implementation. >> Is that no longer the objective? >> >> Or, if things start to get messy, OSGi only? Why the sudden desire to >> take a turn away from OSGi? >> >> Or maybe this project should not even be part of OSGi? >> >> I just find it a bit confusing. Am I missing something? Maybe OSGi is >> starting to lose its way?? >> >> Cheers, >> =David >> >> >> > On Sep 9, 2016, at 11:51 AM, Benson Margulies <[email protected]> >> wrote: >> > >> > And then you need 'new' for the Factory, or a static method? Somewhere, >> the >> > chain of abstraction has to stop. If you don't have any parameters that >> > modify the creation, 'new' is just as good as any sort of Factory or >> > Builder. >> > >> > On Thu, Sep 8, 2016 at 10:21 PM, David Leangen <[email protected]> >> wrote: >> > >> >> >> >> Hi David B., >> >> >> >> Thank for your this explanation. Much of this makes sense, but again, >> just >> >> out of curiosity… >> >> >> >> I do understand the benefit of having this type of functionality >> outside >> >> of an OSGi environment. Perhaps the same could even be said for many >> other >> >> services, too, I’m not sure. >> >> >> >> To do that, instead of using “new” (which for me is a bit of a shock; I >> >> don’t recall even having used “new” to obtain a “service” from a >> different >> >> bundle), why not use a factory? Actually, the previous way that you >> wrote >> >> the util package with the publicly available Factory seems like a good >> >> approach to me. >> >> >> >> I’m not married to it, I’m just trying to understand why… Why is “new” >> >> better than a factory, if both achieve the same objective? >> >> >> >> >> >> Cheers, >> >> =David >> >> >> >> >> >> >> >>> On Sep 9, 2016, at 9:53 AM, David Bosschaert < >> [email protected]> >> >> wrote: >> >>> >> >>> Hi David L, >> >>> >> >>> Well, I have to say that I've always thought that the Converter should >> >> be a >> >>> service as well, but where services really come to shine is where you >> >>> potentially have different implementations that might provide >> different >> >>> features. For the Converter there is very little room for difference >> in >> >>> implementations. The converters should behave exactly like the spec >> will >> >>> describe. Any variation on that can be added via the adapters. There >> is >> >>> still the possibility of distinguishing between implementations from a >> >>> performance point of view, but from a behavioural point of view all >> >>> converters should behave the same to that they are entirely >> predictable. >> >> Of >> >>> course, this is still possible to do with services, and there are many >> >>> services already of which you would only typically have one at >> runtime. >> >>> >> >>> The difference here is that the converter is such a generally useful >> >> thing, >> >>> that it can also be really useful outside of an OSGi framework. The >> API >> >>> itself has no dependency on any other OSGi classes. The thinking is >> that >> >>> with a simple constructor this makes the converter really easy to use >> in >> >>> any environment Java environment. >> >>> >> >>> Services are still one of the best features of OSGi IMHO, and for the >> >>> Serializers (what used to be called Codecs) we'll still use services. >> >> This >> >>> especially makes sense since there can be more than one Serializer, >> there >> >>> is a lot of implementation freedom there (can support any kind of >> format >> >>> you like) and they are selected based on service properties. >> >>> >> >>> So I agree, services are generally the best choice, however in some >> >>> specific cases, using a simple constructor (or factory method) can >> make >> >>> sense, especially if there is little room for variation. >> >>> >> >>> Cheers, >> >>> >> >>> David >> >>> >> >>> On 8 September 2016 at 16:42, David Leangen <[email protected]> wrote: >> >>> >> >>>> >> >>>> Hi, >> >>>> >> >>>> Just out of pure curiosity… what is the reason for moving away from >> >>>> services like this? This seems like quite a departure from the way >> >> things >> >>>> used to be done… >> >>>> >> >>>> Cheers, >> >>>> =David >> >>>> >> >>>> >> >>>> >> >>>>> On Sep 9, 2016, at 8:14 AM, David Daniel < >> [email protected]> >> >>>> wrote: >> >>>>> >> >>>>> Yes I understand. Thank you >> >>>>> >> >>>>> On Sep 8, 2016 7:10 PM, "David Bosschaert" < >> [email protected] >> >>> >> >>>>> wrote: >> >>>>> >> >>>>>> Hi David D, >> >>>>>> >> >>>>>> The pattern that is being followed here is similar to what is done >> for >> >>>> OSGi >> >>>>>> Promises of which an implementation exists in Apache Aries [1]. >> There >> >>>> the >> >>>>>> Deferred, a class in the org.osgi.service... namespace instantiates >> >> the >> >>>>>> Aries implementation. Other implementations can replace the >> Deferred >> >>>> class >> >>>>>> to instantiate their own implementations. >> >>>>>> Similarly here constructing a new >> >>>>>> org.osgi.service.converter.StandardConverter will instantiate the >> >> Felix >> >>>>>> implementation. The org.osgi.service.converter package is embedded >> in >> >>>> the >> >>>>>> bundle. Other implementations will also embed the >> >>>>>> org.osgi.service.converter package but provide a different >> >>>>>> StandardConverter class, which instantiates a different >> >> implementation. >> >>>>>> >> >>>>>> Changed in the recent refactoring is that the Converter is not a >> >> service >> >>>>>> any more. The StandardConverter is a converter instance that is >> >> exactly >> >>>>>> doing what it says in the spec. Anyone who wants a converter simply >> >>>> creates >> >>>>>> one by calling new StandardConverter(). >> >>>>>> If you want to add customization rules, you simply obtain an >> Adapter >> >> by >> >>>>>> calling >> >>>>>> Adapter a = new StandardConverter().newAdapter(); >> >>>>>> Then you can add your rules to a. The Adapter a is also a >> Converter - >> >> it >> >>>>>> implements the Converter interface just like the >> StandardConverter. So >> >>>> you >> >>>>>> can call a.convert(something).to(SomethingElse.class) which >> triggers >> >>>> your >> >>>>>> rules if applicable. >> >>>>>> This allows you to create different adapters for different parts of >> >> your >> >>>>>> application. Its up to the application to decide how to share these >> >>>>>> adapters with other parts of the application. You could use the >> >> service >> >>>>>> registry for that but that's up to you. >> >>>>>> >> >>>>>> Hope this helps, >> >>>>>> >> >>>>>> David >> >>>>>> >> >>>>>> [1] see https://svn.apache.org/viewvc/aries/trunk/async/ >> >>>>>> promise-api/src/main/java/org/osgi/util/promise/Deferred. >> >>>> java?view=markup >> >>>>>> >> >>>>>> On 8 September 2016 at 07:00, David Daniel < >> >> [email protected] >> >>>>> >> >>>>>> wrote: >> >>>>>> >> >>>>>>> I am guessing the stuff in the org.osgi.service namespace is going >> >>>> into a >> >>>>>>> separate bundle similar to how the other services were taken out >> of >> >>>>>>> compendium. Right now the StandardConverter in source control >> news >> >> up >> >>>> an >> >>>>>>> apache impl converter object. Is that code going to change to >> get a >> >>>>>>> converterfactory from the service registry and get a converter >> >> instance >> >>>>>>> from there or something like that. The reason I am asking is that >> >>>> right >> >>>>>>> now I have different bundles that add rules to the adapter for the >> >>>>>> objects >> >>>>>>> that they manage. It happens one time on activate. Should I be >> >>>> changing >> >>>>>>> how I do things for instance, should my "Search" service have a >> >>>> function >> >>>>>>> that gets a converter with the rules added and inside the get >> >> converter >> >>>>>>> function it news up a standard converter and then adds the rules >> or >> >>>>>> should >> >>>>>>> I be adding rules to some global service or adapter that >> >>>>>> StandardConverter >> >>>>>>> will eventually get an object from. >> >>>>>>> >> >>>>>>> Thanks for any help, >> >>>>>>> David Daniel >> >>>>>>> >> >>>>>>> On Thu, Sep 8, 2016 at 9:30 AM, David Bosschaert < >> >>>>>>> [email protected] >> >>>>>>>> wrote: >> >>>>>>> >> >>>>>>>> Hi all, >> >>>>>>>> >> >>>>>>>> The Converter API was recently discussed in the OSGi Expert >> Groups >> >> and >> >>>>>>>> based on the feedback the API has been refactored a bit. >> >>>>>>>> One change is how the converter is obtained in a standard way. >> >>>>>> Previously >> >>>>>>>> this was done by calling ConverterFactory.standardConverter() >> but >> >>>> this >> >>>>>>> is >> >>>>>>>> now done by calling 'new StandardConverter()'. >> >>>>>>>> The converter can be used inside an OSGi framework but also >> outside >> >> of >> >>>>>>> OSGi >> >>>>>>>> in the same way. This follows a pattern used by the OSGi >> Promises as >> >>>>>>> well. >> >>>>>>>> The Codecs will remain an OSGi service (also obtainable via >> >>>>>>>> ServiceLoader.load()) but they are renamed to 'Serializer'. >> >>>>>>>> I've made these changes to the Felix Converter codebase. >> >>>>>>>> >> >>>>>>>> This is a component that is still very much under development >> until >> >>>> the >> >>>>>>>> OSGi R7 specs are released so changes like this can happen. For >> >> those >> >>>>>> who >> >>>>>>>> already use the convert it should not be too hard to update their >> >> code >> >>>>>> - >> >>>>>>>> hopefully :) >> >>>>>>>> >> >>>>>>>> Cheers, >> >>>>>>>> >> >>>>>>>> David >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>> >> >>>> >> >> >> >> >> >> >
