[osgi-dev] Basic feedback on JAX-RS whiteboard spec

[Sergey Beryozkin]

Hi,
Sorry if it is not the right place to provide the feedback, I just 
wanted to share some basic feedback.


- The text is written well and is easy to understand
- May be worth distinguishing between PreMatch and PostMatch filters - 
the former are run before a resource method has been found
- JAX-RS 2.1 draft introduces a client support for CompletableFuture or 
other alternatives (such as RxJava) via an rx() as opposed to async() 
bridge, with an RxInvoker wrapping a specific Rx library/code.
- The use of List in the examples - the minor issue is that it 
is generally difficult to write an interoperable code in such cases for 
XML formats - every JAX-RS 2.0 impl or List handler may have its own 
idea on what the root name is.


That is it
Cheers, Sergey
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] JAX-RS Whiteboard spec link

[Sergey Beryozkin]

Hi David

Thanks, downloaded it,

Cheers, Sergey
On 10/11/16 16:33, David Bosschaert wrote:

Hi Sergey,

It doesn't exist yet as a spec. The latest documentation that for it is
in RFC 217 here: https://github.com/osgi/design/tree/master/rfcs/rfc0217

Cheers,

David

On 10 November 2016 at 16:26, Sergey Beryozkin <sberyoz...@gmail.com
<mailto:sberyoz...@gmail.com>> wrote:

Hi All

Where can I find a link to the JAX-RS whiteboard spec text ?

Thanks, Sergey
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>




___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev



___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] JAX-RS Whiteboard spec link

[Sergey Beryozkin]

Hi All

Where can I find a link to the JAX-RS whiteboard spec text ?

Thanks, Sergey
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] How do you use OSGi?

[Sergey Beryozkin]

Hi Ervin
Thanks for your comments
On 30/05/16 12:05, erwindl0 wrote:

Hi Sergey,

My 2cts : service interfaces should be seen as strict contracts.

If someone makes an incompatible interface change, by definition the
intention is to "break" client expectations/implementations ;-)

Then it's up to the provider to decide whether to maintain old and new
versions operational, or whether to force all clients to adapt/upgrade.

Indeed, any service system which has proxy-based clients needs to deal 
with it, though if clients are loosely typed then the service interface 
changes are easier to manage.

This is independent from the topic of allowing to implement a
"micro-services" approach locally (and remotely) as OSGi does, or
whether to lock-in to one particular remoting protocol as REST is.

You are right, OSGI (and other mechanisms) can be all embracing hiding 
the communication details. I was only commenting to an original remark 
that OSGI is more effective than REST - but I guess I indeed took it 
literally :-)


Thanks all
Sergey

cheers
erwin


Op 30/05/2016 om 12:46 schreef Sergey Beryozkin:

Hi Peter

On 30/05/16 11:38, Peter Kriens wrote:

REST or indeed other forms of designing the way the remote client and
servers communicate with each other is IMHO quite orthogonal to what
OSGI is about.

I think you take a too literal view in this case.

Both REST and OSGi services are about loosely connecting software blocks
using an explicit API and end-point. This architectural pattern is the
successor of object oriented technology and imho the biggest value. The
advantage of OSGi over REST is then that with OSGi there is no overhead
so you can leverage this powerful pattern for even the smallest of
problems.

A good proof-point of this pattern is the ease in which an OSGi service
can be mapped to REST without having to know anything about REST using
Distributed OSGi or, for example, OSGi enRoute REST support.


And then once an interface changes the client code gets broken. And to
avoid it people will go the super interfaces way. I'm sorry, I'm not
really after hijacking this thread with possibly off-topic remarks
:-), I'm only thinking that comparing OSGI vs REST is not very effective.

Thanks, Sergey



Kind regards,

Peter Kriens




On 30 mei 2016, at 11:07, Sergey Beryozkin <sberyoz...@gmail.com
<mailto:sberyoz...@gmail.com>> wrote:

Hi Peter

I only have one comment,
On 23/05/16 14:03, Peter Kriens wrote:

I think I agree with your analysis, despite the grains of salt. I find
the true innovation of OSGi the service model. To me, the service
oriented model truly allows you to decouple modules. It is hard
work to
take an existing application with all its hairball characteristics and
turn it into a clean architecture that the OSGi service model requires
as well enforces. Trying to adapt the old patterns of class loading
hacks and overuse of statics (global variables!!) to a modular world
requires an effort. (As Jigsaw will demonstrate to non-believers.)

The interesting things is that core aspect of this service model is
becoming highly popular in a different form: micro-services. OSGi
allows
you to reap the benefits of this architectural design primitive with a
MUCH lower cost (both performance and developer cost) than the rather
expensive REST services that are common outside OSGi.


REST or indeed other forms of designing the way the remote client and
servers communicate with each other is IMHO quite orthogonal to what
OSGI is about.
DOSGI would be the closest one here and indeed one can use arguably
expensive HTTP calls or more effective RMI/etc calls in between OSGI
consumers and services, but IMHO it is a rather different conversation
which communication style between remote parties works best :-)

Cheers, Sergey

This allows you to
reuse this design primitive in even the lowest layer of your
architecture, creating many synergies. It never ceases to amaze me how
little code you need to write significant functionality in a properly
setup OSGi system. Configuration Admin, Declarative services, Remote
Service Admin, Event Admin, and many other services are vertical
building blocks that can be used in an amazing number of applications.

That said, also the Capability model we’ve added over the years
provides
a software management model that I think is highly under-appreciated.

I’ve sold objects from the early 80’s until they became solidly
mainstream around 2000. I know I’ve tried to sell the service model
since that time because it addresses some scalability problems in
objects. (Transitive dependencies.) Its been a long time but I still
believe that OSGi services are a similar innovation as objects were in
the early 90’s. And I therefore still have hope that one day people
will
understand how much cleaner you can make your software systems by
embracing that service model.

Kind regards,

Peter Kriens




On 23 mei 2016, at 13:34, Craig Phillips <lcphi

Re: [osgi-dev] How do you use OSGi?

[Sergey Beryozkin]

Hi Peter

I only have one comment,
On 23/05/16 14:03, Peter Kriens wrote:

I think I agree with your analysis, despite the grains of salt. I find
the true innovation of OSGi the service model. To me, the service
oriented model truly allows you to decouple modules. It is hard work to
take an existing application with all its hairball characteristics and
turn it into a clean architecture that the OSGi service model requires
as well enforces. Trying to adapt the old patterns of class loading
hacks and overuse of statics (global variables!!) to a modular world
requires an effort. (As Jigsaw will demonstrate to non-believers.)

The interesting things is that core aspect of this service model is
becoming highly popular in a different form: micro-services. OSGi allows
you to reap the benefits of this architectural design primitive with a
MUCH lower cost (both performance and developer cost) than the rather
expensive REST services that are common outside OSGi.


REST or indeed other forms of designing the way the remote client and 
servers communicate with each other is IMHO quite orthogonal to what 
OSGI is about.
DOSGI would be the closest one here and indeed one can use arguably 
expensive HTTP calls or more effective RMI/etc calls in between OSGI 
consumers and services, but IMHO it is a rather different conversation 
which communication style between remote parties works best :-)


Cheers, Sergey

This allows you to
reuse this design primitive in even the lowest layer of your
architecture, creating many synergies. It never ceases to amaze me how
little code you need to write significant functionality in a properly
setup OSGi system. Configuration Admin, Declarative services, Remote
Service Admin, Event Admin, and many other services are vertical
building blocks that can be used in an amazing number of applications.

That said, also the Capability model we’ve added over the years provides
a software management model that I think is highly under-appreciated.

I’ve sold objects from the early 80’s until they became solidly
mainstream around 2000. I know I’ve tried to sell the service model
since that time because it addresses some scalability problems in
objects. (Transitive dependencies.) Its been a long time but I still
believe that OSGi services are a similar innovation as objects were in
the early 90’s. And I therefore still have hope that one day people will
understand how much cleaner you can make your software systems by
embracing that service model.

Kind regards,

Peter Kriens




On 23 mei 2016, at 13:34, Craig Phillips > wrote:


My response below does not necessarily apply to myself, but is what I
regard the reality of the situation (which I deem unfortunate):

  With OSGi, you have to be "all in" ;

I would be nice if OSGi were to have been built in to the Java
language from the very beginning. If that were the case, I would not
be making this post / reply.

As for myself, I have worked with the "boot delegation" aspects to
allow OSGi-based code and non-OSGi-based code to inter-operate
seamlessly. Unfortunately, the task of having OSGi and non-OSGi
code/componentry inter-operate is the very thing that causes OSGi to
be dropped as a viable framework in a variety of projects.  Again, I
emphasize the word "unfortunate" as I regard OSGi as one of my
favorite technologies.

On the other hand, I have seen -- both with OSGi and just about
anything else -- technologies misused/abused to the point of complete
and utter ruin (I can name a few OSGi based efforts where they were
"all in", but created a behemoth [in particular, misusing/abusing
Karaf] that was such a spaghetti-tangle-rubber-band-ball of bundles
that it not only fell apart, but created a bad not for the technology
-- OSGi in these cases).

So, even though I can make OSGi code and non-OSGi code work in
"harmony", the reality of the situation, over at least a decade of
attempted usage of the technology, is that you have to be "all in."

How ever many grains of salt...



*From:*osgi-dev-boun...@mail.osgi.org

[osgi-dev-boun...@mail.osgi.org
] on behalf of Balázs Zsoldos
[balazs.zsol...@everit.biz ]
*Sent:*Monday, May 23, 2016 3:59 AM
*To:*OSGi Developer Mail List
*Subject:*Re: [osgi-dev] How do you use OSGi?

Hi,

33 answers arrived till now. I would like to thank you. I will write a
short summary of responses here, soon.

Kind regards,
*Balázs **Zsoldos*
*
*


On Thu, May 19, 2016 at 6:09 PM, Balázs
Zsoldoswrote:

Hi,

I would like to ask you to fill our short survey. We develop
server-side applications based on OSGi and we try to release all
reusable modules and tools that we implemented for ourselves as
OpenSource modules. However, we would like to 

Re: [osgi-dev] remote services distribution provider recommendations?

[Sergey Beryozkin]

On 28/02/14 09:54, Holger Hoffstätte wrote:

On 28.02.2014 10:28, Mike Wilson wrote:

We're doing remote calls between OSGi containers on different servers
and I'm looking at Remote Services to do the job. I've noticed that
Apache CXF/DOSGi http://cxf.apache.org/distributed-osgi is the reference
implementation.


Unfortunately it's effectively unmaintained, unfixable and full of bugs.


While I'm not actively invoked in this project, I'm finding the above 
comment being negative and I'd say very far from the truth


Sergey

P.S. Sorry if it is off-topic




Can you recommend any Remote Service distribution provider
implementations that offer better support for keeping referential
integrity within the data transferred to the remote server?


I would love to hear what semantics of the consequently necessary
distributed GC you'd expect in the face of failures, netsplits and
stragglers. Once that is cleared up we can talk about why you think that
distributed globally consistent object networks with (almost guaranteed)
cycles are a good thing in reality to start with.

There's a reason (many actually) why nobody with half a brain (get it?!)
uses RMI any more.


Bonus question: What's a good setup for load balancing Remote Service
calls between multiple remote servers?


For stateless or stateful services? he asked, tongue in cheek.

In a nutshell: if you're looking for anything more than a
network-transparent extension of the Java method call semantics, you
are looking in the wrong place. Neither Java's (and hence OSGI's
service) method invocation model nor the RSA spec are expressive enough
for anything beyond that.

-h

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev



___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Blueprint schema blocks nested static class names

[Sergey Beryozkin]

Hello All,

I've recently reported an issue at the Apache Aries dev list [1] to do 
with the
Blueprint schema blocking the nested static class names and I'm moving 
the discussion to this list as recommended by Jeremy Hughes.


The fix proposed at [1] is to relax the schema for Java (or I guess 
other language VMs) to validate the class names as opposed to 
restricting the names at the higher level in Blueprint schema.


We came across the issue while working on migrating the application 
including many code-generated nested classes to Blueprint.


Any objections to me opening a bug at [2] ?

Thanks, Sergey

[1] 
http://mail-archives.apache.org/mod_mbox/aries-dev/201204.mbox/ajax/%3C4F7A03DE.4060603%40gmail.com%3E

[2] https://www.osgi.org/bugzilla/
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Blueprint schema blocks nested static class names

[Sergey Beryozkin]

Hi,
On 14/05/12 12:17, BJ Hargrave wrote:

Why don't you just say a.b.MyClass.MyNestedClass instead of
a.b.MyClass$MyNestedClass in the XML? The former is how you would
refer to it in java source code and also how javap expects it to be
referred to on the command line.

Then you don't need to change the specification (which will take time).
You can just modify the implementation to support inner class names in
the XML.

That sounds reasonable, but I guess it means the implementation will 
need to resort to relying on the convention that if the last two tokens 
start from an upper-case character then it must be a nested class name, etc,


example, is it the case of the nested static class or simply the package 
name not following the regular Java naming convention:


a.b.C.D.E ?

where we can have an 'a.b.C.D' package name.

Cheers, Sergey


--

*BJ Hargrave*
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the _OSGi Alliance_ http://www.osgi.org/_
__hargr...@us.ibm.com_ mailto:hargr...@us.ibm.com   

office: +1 386 848 1781
mobile: +1 386 848 3788







From: Sergey Beryozkin sberyoz...@gmail.com
To: osgi-dev@mail.osgi.org,
Date: 2012/05/14 07:05
Subject: [osgi-dev] Blueprint schema blocks nested static class names
Sent by: osgi-dev-boun...@mail.osgi.org





Hello All,

I've recently reported an issue at the Apache Aries dev list [1] to do
with the
Blueprint schema blocking the nested static class names and I'm moving
the discussion to this list as recommended by Jeremy Hughes.

The fix proposed at [1] is to relax the schema for Java (or I guess
other language VMs) to validate the class names as opposed to
restricting the names at the higher level in Blueprint schema.

We came across the issue while working on migrating the application
including many code-generated nested classes to Blueprint.

Any objections to me opening a bug at [2] ?

Thanks, Sergey

[1]
http://mail-archives.apache.org/mod_mbox/aries-dev/201204.mbox/ajax/%3C4F7A03DE.4060603%40gmail.com%3E
[2] https://www.osgi.org/bugzilla/
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev




___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Re: JAX-RS

[Sergey Beryozkin]

Hi,

Here is some more information about the DOSGI RI and Apache CXF JAX-RS 
implementation.

In DOSGI RI one can expose and consume RESTful service with the help of CXF 
JAX-RS with or without using JAX-RS annotations.

The latter option is more DOSGI-friendly given that it is less intrusive, as 
far as the actual user interfaces about to be exposed are concerned.
In this case, the CXF JAXRS runtime is still fully involved but the information 
on how to select and dispatch to a particlular method is provided out-of-band 
through the use of external user models.

Please see :

1. Configuration : 
http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiReference-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpointsandconsumers

2. greeter_rest demo : 
http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/
More specifically, see

http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/interface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterService.java
and
http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/interface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterService2.java

Note, GreeterService2 is exposed as a RESTful service with the help of

http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/interface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml

Both service are published and consumed as regular OSGI services :
http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/impl/src/main/java/org/apache/cxf/dosgi/samples/greeter/impl/rest/Activator.java
http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/client/src/main/java/org/apache/cxf/dosgi/samples/greeter/client/rest/Activator.java

3. No-annotations feature and the DOSGI RI and JAX-RS 
http://cwiki.apache.org/CXF20DOC/jax-rs.html#JAX-RS-RESTfulserviceswithoutannotations


Hope it helps, Sergey



___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev