[jetty-dev] deeper OSGi support

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[jetty-dev] deeper OSGi support

Raymond Auge
Hello All,

This is my first email to this community. So first I would like to thank you all for your hard work and incredible deliverables. Jetty is an awesome project.

Ok.

Jetty is used in OSGi projects around the world because a) it's super powerful b) it's natively setup for OSGi which makes it relatively barrier free.

However, there are many secondary or "wrapper" projects which all build "front ends" for bootstrapping jetty in OSGi. Most are more or less successful. However, I feel that there is a knowledge gap about how this should best be done, there is no oversight by the jetty developers. Nor do limitations in jetty coming from the OSGi side really make it back to the jetty developers because you know... people are lazy, and if a problem can easily be solved by a hack then you know what generally happens. In essence, I feel there are limitations among all the current wrappers.

1) So, I'd like to ask if the jetty community would be willing to host a canonical Http Whiteboard implementation directly. I'm sure I could bring along with me a few skilled and interested OSGi experts, but we could sure use jetty devs to guide the way from their side.

2) In addition to this, in recent months I've designed a websocket whiteboard, optional but complimentary to the http whiteboard, but I noted several limitations in the Java EE websocket API for which I wasn't able to find an elegant solution, nor in the jetty impl... this is primarily around programmatic destruction of endpoints, unloading. I would love to find a real solution for this and I think that jetty devs are the key here.

3) Another feature I would love is to teach such a whiteboard to provide factory-like bootstrapping mechanism such that new jetty sockets/servers could be opened with new configurations in an OSGi "service factory" way.

4) Lastly, I would love to add the latest state of the art OSGi metadata to jetty bundles such that it can be easily consumed using the OSGi resolver to "calculate" and generate uncompromising web runtimes.

If you are not familiar with this approach there is an tiny project here [1] which illustrates using this model to produce fully resolved applications (in this case web applications) starting with only a set of requirements (namely your code), a repository, and the resolver (using a process defined in the OSGi enRoute [2] project). From this we get super small but useful applications with no unnecessary cruft. Jetty could be a lynch pin in this because of its relevance to the web.

Sorry for the super long email. But if you have thoughts I'd love to hear them.

[1] https://github.com/rotty3000/osgi.web.boot.http.example
[2] http://enroute.osgi.org/
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] deeper OSGi support

Jesse McConnell
Hi Raymond,

Thanks for the note!  We'll chat a bit internally and get back to you asap on this.  It might make sense to have a google hangout to discuss as well. :)

cheers,
Jesse

--
jesse mcconnell
[hidden email]

On Fri, Nov 18, 2016 at 11:50 AM, Raymond Auge <[hidden email]> wrote:
Hello All,

This is my first email to this community. So first I would like to thank you all for your hard work and incredible deliverables. Jetty is an awesome project.

Ok.

Jetty is used in OSGi projects around the world because a) it's super powerful b) it's natively setup for OSGi which makes it relatively barrier free.

However, there are many secondary or "wrapper" projects which all build "front ends" for bootstrapping jetty in OSGi. Most are more or less successful. However, I feel that there is a knowledge gap about how this should best be done, there is no oversight by the jetty developers. Nor do limitations in jetty coming from the OSGi side really make it back to the jetty developers because you know... people are lazy, and if a problem can easily be solved by a hack then you know what generally happens. In essence, I feel there are limitations among all the current wrappers.

1) So, I'd like to ask if the jetty community would be willing to host a canonical Http Whiteboard implementation directly. I'm sure I could bring along with me a few skilled and interested OSGi experts, but we could sure use jetty devs to guide the way from their side.

2) In addition to this, in recent months I've designed a websocket whiteboard, optional but complimentary to the http whiteboard, but I noted several limitations in the Java EE websocket API for which I wasn't able to find an elegant solution, nor in the jetty impl... this is primarily around programmatic destruction of endpoints, unloading. I would love to find a real solution for this and I think that jetty devs are the key here.

3) Another feature I would love is to teach such a whiteboard to provide factory-like bootstrapping mechanism such that new jetty sockets/servers could be opened with new configurations in an OSGi "service factory" way.

4) Lastly, I would love to add the latest state of the art OSGi metadata to jetty bundles such that it can be easily consumed using the OSGi resolver to "calculate" and generate uncompromising web runtimes.

If you are not familiar with this approach there is an tiny project here [1] which illustrates using this model to produce fully resolved applications (in this case web applications) starting with only a set of requirements (namely your code), a repository, and the resolver (using a process defined in the OSGi enRoute [2] project). From this we get super small but useful applications with no unnecessary cruft. Jetty could be a lynch pin in this because of its relevance to the web.

Sorry for the super long email. But if you have thoughts I'd love to hear them.

[1] https://github.com/rotty3000/osgi.web.boot.http.example
[2] http://enroute.osgi.org/
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] deeper OSGi support

Raymond Auge

Also note I'm already an eclipse committer and the present maintainer of the current Equinox http.servlet (which is Equinox's OSGi http service/http whiteboard implementation).

In case that matters...

Sincerely,
- Ray


On Nov 18, 2016 1:27 PM, "Jesse McConnell" <[hidden email]> wrote:
Hi Raymond,

Thanks for the note!  We'll chat a bit internally and get back to you asap on this.  It might make sense to have a google hangout to discuss as well. :)

cheers,
Jesse

--
jesse mcconnell
[hidden email]

On Fri, Nov 18, 2016 at 11:50 AM, Raymond Auge <[hidden email]> wrote:
Hello All,

This is my first email to this community. So first I would like to thank you all for your hard work and incredible deliverables. Jetty is an awesome project.

Ok.

Jetty is used in OSGi projects around the world because a) it's super powerful b) it's natively setup for OSGi which makes it relatively barrier free.

However, there are many secondary or "wrapper" projects which all build "front ends" for bootstrapping jetty in OSGi. Most are more or less successful. However, I feel that there is a knowledge gap about how this should best be done, there is no oversight by the jetty developers. Nor do limitations in jetty coming from the OSGi side really make it back to the jetty developers because you know... people are lazy, and if a problem can easily be solved by a hack then you know what generally happens. In essence, I feel there are limitations among all the current wrappers.

1) So, I'd like to ask if the jetty community would be willing to host a canonical Http Whiteboard implementation directly. I'm sure I could bring along with me a few skilled and interested OSGi experts, but we could sure use jetty devs to guide the way from their side.

2) In addition to this, in recent months I've designed a websocket whiteboard, optional but complimentary to the http whiteboard, but I noted several limitations in the Java EE websocket API for which I wasn't able to find an elegant solution, nor in the jetty impl... this is primarily around programmatic destruction of endpoints, unloading. I would love to find a real solution for this and I think that jetty devs are the key here.

3) Another feature I would love is to teach such a whiteboard to provide factory-like bootstrapping mechanism such that new jetty sockets/servers could be opened with new configurations in an OSGi "service factory" way.

4) Lastly, I would love to add the latest state of the art OSGi metadata to jetty bundles such that it can be easily consumed using the OSGi resolver to "calculate" and generate uncompromising web runtimes.

If you are not familiar with this approach there is an tiny project here [1] which illustrates using this model to produce fully resolved applications (in this case web applications) starting with only a set of requirements (namely your code), a repository, and the resolver (using a process defined in the OSGi enRoute [2] project). From this we get super small but useful applications with no unnecessary cruft. Jetty could be a lynch pin in this because of its relevance to the web.

Sorry for the super long email. But if you have thoughts I'd love to hear them.

[1] https://github.com/rotty3000/osgi.web.boot.http.example
[2] http://enroute.osgi.org/
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev

_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev