[equinox-dev] Project meta data is out of date for rt.equinox

[portal on behalf of emo]

Jeff, Thomas,
Projects are required to keep meta data up to date using the MyFoundation
Portal (http://portal.eclipse.org/).  The following problems were found
with this project's meta-data:

* Project home page (projecturl = http://www.eclipse.org/equinox/) does not
have an "About ","About This Project" or "Information about
" link. Projects are required to provide that standard link on
their home page (see
http://www.eclipse.org/projects/standard-link-on-home-page.php) .

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Re: [GSoC] Restlet integration with Equinox

[Scott Lewis]

Hi Rob,

Thanks for the comments.  A couple of reactions inline below:

Rob Heittman wrote:
Restlet is already fairly far down the road of "bundleization" (sounds 
German).  The project delivers many bundles which provide different 
extension capabilities and compatibilities, and at least at the 
fundamental level, these all behave just fine in OSGi.


However, the bundles require some additional work to really talk, as 
by default they rely on Java service discovery (anti) patterns to 
discover, select, and use the present extensions.  There is still some 
contention between different approaches for doing this in OSGi (see 
this long -- and aging -- 
thread: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1322152 
) 
but there are really two sane paths:


  - Repackage some Restlet bundles as fragments (David Fogel 
likes/uses this approach)
  - Override the service discovery stuff programmatically (My company 
likes/uses this approach)


There is an option 3, involving hacking META-INF/services in each 
bundle to rig the discovery the way you want it, and yes I have a few 
places where I still have to do that, but it doesn't really dignify 
further discussion  :-)


My only comment about discovery is that ECF also has a discovery API 
(org.eclipse.ecf.discovery), and that discovery API is also implemented 
by multiple providers...like zeroconf/bonjour, slp, apache zookeeper, 
and others (I believe that Bryan Hunt has done a discovery provider 
also, but am not certain of that).  Like the remote services stuff I 
described before, the ECF OSGI remote services implementation only uses 
the abstract discovery API...meaning that any providers (no matter what 
protocol they use) will automatically be spec compliant.




So this is one area of further study and action: how, canonically 
speaking, should one compose a set of Restlet extensions in an OSGi 
container and indicate which combination should be used for a 
particular application?  If I am using Restlet as my OSGi HttpService 
-- or via any other OSGi service interface -- what is the canonical 
path to indicate that I want it to use Jackson for JSON-based 
representations and run over the Jetty connector?


The OSGi remote services spec defines a thing called a 'config 
type'...which is just a String that uniquely identifies a type of remote 
service provider.  ECF maps this 'config type' to identify an ECF 
IContainer type/factory...and this string identified the provider used 
underneath (e.g. ecf.r-osgi.peer, ecf.generic.client, ecf.xmpp.client, 
etc)...so to use a particular provider/protocol to register/publish a 
remote service all one has to do is create a provider with new name, 
specify it as the config type to use when registering a remote service, 
and that provider will be used.  Some providers would use Jackson, or 
json.org json parsing (which we already have as a bundle in ECF SDK), 
and use the Jetty http service.


Does this answer your question?



Next ...

The routing-level plumbing of Restlet 2.x involves concrete classes 
which are wired together in a fairly static way.  (I am thinking here 
of Restlet and its subclasses: especially, VirtualHost, Component, 
Filter, Guard, Router, Route).  There is an inchoate desire to make 
this more dynamic and to leverage interfaces in a future Restlet 
release; interfaces here make me think naturally of OSGi services. 
 For example, we have a number of different Guards which do 
authentication against different types of authorities.  At present, 
these have to concretely extend the Guard class and I must define my 
own interfaces around them, then extra code to discover them and plug 
them into the application at the appropriate place.  It would be nice 
if all this was more OSGi-native.  Again -- nothing here is really at 
the fully formed specification level, just a hint at an area where 
valuable work could be done.


I see.  I agree that the use of OSGi services for dynamicity is a very 
useful thing...and another thing that would make sense to do within 
Restlet...assuming OSGi runtime environment.


Scott


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Re: [GSoC] Restlet integration with Equinox

[Scott Lewis]

Hi Jerome,

Thanks kindly for the summary...it's excellent.

My main follow-up question about '1' is:  given Equinox/OSGi as it 
exists now and the Restlet API/framework as it exists now...what is 
actually left to do to realize/complete 1? 

That is, as I understand it (and please forgive and correct if I'm 
wrong), the Restlet framework is essentially a set of java classes, 
distributed as a jar library, that depends upon the servlet API 
(presumably there are Restlet classes that implement Servlet and/or 
extend HttpServlet) and therefore is intended to run in the context of a 
servlet container (e.g. Jetty). 

If this is right, then I can think of a couple of things that 
would/could be part of 1:  e.g. 

a) 'bundlizing' the Restlet API ...i.e. doing to the Restlet API what 
the Orbit project does with other (e.g. Apache, etc) java-based 
libraries...i.e. turning them into OSGi bundles
b)  changing the Restlet use of the servlet API to use the OSGi 
HttpService (for dynamic creation/removal of servlets within an OSGi 
runtime)


Is this a correct interpretation of what work on '1' would actually 
consist of?  Or are there additional things that I'm not 
getting/understanding?


If these are the main things, then I would see the accomplishment of 
these things (i.e. 1) as a prerequisite/aid to accomplishing 2.  Just 
for context...to accomplish '2' what is required is the creation of ECF 
remote service provider bundle(s).  This provider would use the Restlet 
API to support registering (making available) a Restlet-based remote 
service (as you say in your summary...implementing the OSGI remote 
services specification...via a Restlet-enabled http server).  I think 
it's a happy situation, though, that to create such an ECF remote 
services provider, it's going to be helpful to do 1a and 1b...in fact 
doing those two things (1a and 1b) will make creating such a provider 
rather easy...as we have now a fair amount of support for implementing 
either rest-based and/or non-rest-based remote service providers. 

Further, given the way ECF's impl of OSGi remote services works, such a 
provider would immediately and without further work be fully OSGi spec 
compliant.  This is true because ECF's impl of OSGi remote services spec 
can use *any/all* providers that implement the abstract ECF remote 
services API (in org.eclipse.ecf.remoteservice bundle).  So any/all 
Restlet-based providers would be fully OSGi-spec compliant simply by 
implementing the ECF remote services API).


But I would like to verify or disconfirm my interpretation of '1' as 
consisting of 'a' and 'b' above...as it may not be right.  Are there 
other things there that I'm not understanding?


Thanks,

Scott


Jerome Louvel wrote:

Hi all,

Sorry for the late reply, I'm on vaccations... well sort of :)

Let me try to summarize the situation. It seems to me that we have two 
starting points:


1) The Restlet community which has expressed a recurrent need for OSGi 
in order to offer a more dynamic Restlet runtime. This project was 
summarized over time on this wiki page:

http://wiki.restlet.org/developers/172-restlet/124-restlet.html

2) The ECF community which sees the value of Restlet as a way to 
implement and support the "remote declarative OSGi services" features. 
This project was summarized recently on this wiki page:

http://wiki.restlet.org/developers/172-restlet/350-restlet.html

The goal of 1) is to leverage all/most features of the Restlet 
Framework (Restlet API + engine + extensions) and, in addition, to 
leverage OSGi/Equinox core features to bring support for dynamic 
Restlet applications deployment/replacement and versionning.


The goal of 2) is to leverage all/most features of OSGi (Core + 
declarative remote services) and, in addition, to leverage the Restlet 
Framework to provide better REST coverage on the server-side (and 
maybe on the client-side as well).


It is important to note that the Restlet API has its own containment 
model, with concepts of component, connector, virtual host, 
application and resource as illustrated here:
http://wiki.restlet.org/docs_2.0/13-restlet/21-restlet/318-restlet/321-restlet.html 



From 1) point of view, it wouldn't be acceptable for the Restlet 
community to be constrained to systematically use OSGi declarative 
remote services API to build their dynamic Restlet applications. 
However, many users would love to leverage some core OSGi/Equinox 
features to add more dynamicity to their Restlet applications -> First 
GSoC project proposition.


From 2) point of view, it wouldn't be acceptable for the Equinox/ECF 
community to be constrained to systematically use the Restlet API to 
build or consume RESTful web services either. However, some users 
might like to leverage some Restlet advanced features (like content 
negotiation, conditional method processing, rich Java API mapping to 
HTTP semantics, etc.) in their distributed OSGi applications -> Second 
GSoc project proposition.


Reg

Re: [equinox-dev] Re: [p2-dev] who should declare dependencies on ds?

[Jeff McAffer]

Bingo!  You can setup a feature and a p2.inf in that feature to create/include 
another IU that sets the start level and has the bundle started. good point.

Having said that, it makes the feature less reusable (e.g., if you want the 
same function but less things started etc.).  Note also that PDE *may* not 
notice the start-level and start settings. I know there has been work in the 
are of using p2 to provision the launched system but am not sure if it included 
this capability.  I've not tried this lately.

Jeff

On 2010-04-03, at 6:17 PM, O'Flynn, Dennis wrote:

> Re: features and start levels, I thought this could be accomplished via p2 
> with CUs.
> 
> (Sent from my Droid)
> 
> -Original Message- 
> From: Jeff McAffer [j...@eclipsesource.com]
> Received: 4/3/10 3:49 PM
> To: Equinox development mailing list [equinox-...@eclipse.org]
> Subject: Re: [equinox-dev] Re: [p2-dev] who should declare dependencies on ds?
> 
> 
> yes, partially.  Features do not allow you ot set start levels, properties 
> and command line args.  So, they are part of the story certainly but products 
> are the tasty recipe.
> 
> Jeff
> 
> On 2010-04-03, at 12:29 PM, O'Flynn, Dennis wrote:
> 
>> In your analog, sounds like the pancakes would be a "feature" while the eggs 
>> and flour are "plug-ins".
>> 
>> (Sent from my Droid)
>> 
>> -Original Message- 
>> From: Neil Bartlett [njbartl...@gmail.com]
>> Received: 4/2/10 6:51 PM
>> To: Equinox development mailing list [equinox-...@eclipse.org]
>> CC: P2 developer discussions [p2-...@eclipse.org]
>> Subject: Re: [equinox-dev] Re: [p2-dev] who should declare dependencies on 
>> ds?
>> 
>> 
>> This is the thing about decoupling bundles with services...
>> 
>> Eggs do not depend on flour; they know nothing about flour. Flour knows 
>> nothing about eggs. We need some kind of knowledge that lives outside of the 
>> ingredients -- i.e., a recipe -- in order to make pancakes.
>> 
>> Rgds,
>> Neil
>> 
>> On Fri, Apr 2, 2010 at 9:57 PM, Jeff McAffer  wrote:
>> Good point Jason.  I would generalize it even more and say that it is not 
>> just DI but the decoupling that comes with services (or the extension 
>> registry for that matter).  We decouple bundles to they don't depend on 
>> specific implementations but then do not have a mechanism for spec'ing that 
>> they actually need an implementation. There is the component definition in 
>> DS etc but p2 or someone else has to read/understand that.  The unique thing 
>> about DS is that it is even more removed.
>> 
>> You could say , "hey, the bundle has DS markup so it must need DS" While 
>> that is likely true in many cases, it is also possible that the same bundle 
>> could be used with and without DS.  It may contain other markup for other DI 
>> mechanisms.  These have to be dealt with at a higher level as you say.
>> 
>> Jeff
>> 
>> On 2010-04-02, at 4:40 PM, Jason Barkanic wrote:
>> 
>>> In general this is a problem with any kind of dependency injection, 
>>> although in this case nothing is actually being injected, but it is being 
>>> set up and managed by an outside component.  
>>> 
>>> Do you set up a dependency on the dependency injector?  How do you best 
>>> notify clients that they need the dependency injection framework with your 
>>> config, or else they'll have to set things up themselves?  It's not even 
>>> different implementations of DS, but you could substitute in Blueprint, or 
>>> Spring, without changing the API (that is if you don't define API to 
>>> include one particular set of bundles over another).
>>> 
>>> This kind of thing is annoying though (I've been a victim).  I'm interested 
>>> to see what solutions present themselves as more and more people move to DI 
>>> and Services paradigms.  I think good error messages can help, since that 
>>> might have alleviated your 6 week search in the first place, but that is 
>>> easier said than done.  The error message could make suggestions about why 
>>> a service lookup failed, but it's hard [impossible] to really know.
>>> 
>>>  -Jason
>>> 
>>> 
>>> Phil Wrote: 
>>> =
>>> 
>>> I can appreciate the desire to allow different DS implementations but the 
>>> bottom line is that DS is going to break any RCP application that uses P2 
>>> (there may be other fall out as well).  My RCP app uses P2 so I thought 
>>> that I should download 3.6M5 so that I had time to make comments about the 
>>> API before the API freeze.  When I updated not only did my auto update 
>>> functionality break, but my build server broke also (PDE build with P2).  
>>> It took 6 weeks of googling before I figured out that there was this new DS 
>>> bundle that I not only had to include, but I also had to be responsible for 
>>> starting.
>>> 
>>> All is well for me now, but I fear that this change is going to have a big 
>>> impact when 3.6 releases.  At a minimum thi

[equinox-dev] Re: [GSoC] Restlet integration with Equinox

[Jerome Louvel]

Hi all,

Sorry for the late reply, I'm on vaccations... well sort of :)

Let me try to summarize the situation. It seems to me that we have two 
starting points:


1) The Restlet community which has expressed a recurrent need for OSGi 
in order to offer a more dynamic Restlet runtime. This project was 
summarized over time on this wiki page:

http://wiki.restlet.org/developers/172-restlet/124-restlet.html

2) The ECF community which sees the value of Restlet as a way to 
implement and support the "remote declarative OSGi services" features. 
This project was summarized recently on this wiki page:

http://wiki.restlet.org/developers/172-restlet/350-restlet.html

The goal of 1) is to leverage all/most features of the Restlet Framework 
(Restlet API + engine + extensions) and, in addition, to leverage 
OSGi/Equinox core features to bring support for dynamic Restlet 
applications deployment/replacement and versionning.


The goal of 2) is to leverage all/most features of OSGi (Core + 
declarative remote services) and, in addition, to leverage the Restlet 
Framework to provide better REST coverage on the server-side (and maybe 
on the client-side as well).


It is important to note that the Restlet API has its own containment 
model, with concepts of component, connector, virtual host, application 
and resource as illustrated here:

http://wiki.restlet.org/docs_2.0/13-restlet/21-restlet/318-restlet/321-restlet.html

From 1) point of view, it wouldn't be acceptable for the Restlet 
community to be constrained to systematically use OSGi declarative 
remote services API to build their dynamic Restlet applications. 
However, many users would love to leverage some core OSGi/Equinox 
features to add more dynamicity to their Restlet applications -> First 
GSoC project proposition.


From 2) point of view, it wouldn't be acceptable for the Equinox/ECF 
community to be constrained to systematically use the Restlet API to 
build or consume RESTful web services either. However, some users might 
like to leverage some Restlet advanced features (like content 
negotiation, conditional method processing, rich Java API mapping to 
HTTP semantics, etc.) in their distributed OSGi applications -> Second 
GSoc project proposition.


Regarding Jetty, it can be used with Restlet in two ways. First, as a 
regular Servlet container as pointed out by Scott, or as a standalone 
Restlet connector (bypassing the Servlet layers) to directly use the 
Restlet layers, providing a lighter solution. Note that while Restlet 
applications can be deployed into Servlet containers if needed, many 
users prefer standalone deployment of Restlet applications in Restlet 
components, using Restlet connectors (such as Jetty).


I hope this helped to clarified :)

Best regards,
Jerome

PS: I've put in copy the various persons interested in this 
Equinox/Restlet GSoC project(s) as I'm not sure how many follow this 
list. Sorry for any duplicate email.



Le 29/03/2010 19:33, Scott Lewis a écrit :

Hi Jerome,

Jerome Louvel wrote:

Hi Scott, Rajeev and all,

Thanks for your interest Rajeev in this GSoC project.

Scott, it seems that the integration of Restlet with ECF could give
you with fully-featured server-side REST support. This would also be a
nice use case for the GSoC "Restlet integration with Equinox" project.


I agree.



I've recently created a wiki page for this project. Maybe we could
propose another GSoC project for this specific topic?

"ECF integration"
http://wiki.restlet.org/developers/172-restlet/350-restlet.html


I think that would be a great idea. One point of
information/interest...there are already several ECF committers and
contributors that would probably also be interested in this 'second
step'...i.e. of using Restlet API on Equinox/OSGi server to implement an
ECF remote services host provider. Actually, Bryan Hunt is one such ECF
contributor, and he may be interested in this sort of use case as well.

Thanks,

Scott




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev