Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 329816

Summary:	Document differences between snaps and web fragments
Product:	[RT] Virgo	Reporter:	Glyn Normington <glyn.normington>
Component:	snaps	Assignee:	Project Inbox <virgo-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	dmitry, eclipse, hsiliev, kaloyan, pphelan
Version:	2.2.0.M01	Flags:	glyn.normington: documentation+
Target Milestone:	3.0.0.M02
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description Glyn Normington

2010-11-09 10:35:52 EST

Comment 1 Chris Frost

2010-11-10 12:25:55 EST

My initial comments will go in this bug until I have the time to write them up properly. Until then don't consider any of this gospel but do feel free to argue with me :)


1. Web-Fragments are not modular at deployment or runtime. Only at development time. The Servlet 3.0 Spec requires all libraries that include a Web-Fragment to be in the lib directory of the War file. 

2. Web-Fragments also have non-trivial rules about the resultant composite servlet context, in snaps, each snap is simply dealt with in isolation once the appropriate snap has been found from the requested context path. I think this shows better coupling. I'm certainly not disagreeing with the servlet spec, just pointing out it wasn't designed with the type of modularity that OSGi offers in mind.


I want to think a bit more about the differences here, snaps uses filters to separate the responsibility of dealing with requests while Web-Fragments get merged together at run time.

(One though that crosses my mind, what on earth will the servlet container do when web fragments are provided via OSGi and are not in the lib dir...)

Comment 2 Dmitry Sklyut

2010-11-11 12:07:49 EST

IMHO snaps and web-fragments fill different needs.

With web-fragments - it is more of a fragment bundle approach with all pluses and minuses.
Snaps - is a service based approach.

With snaps host and snap can have conflicting imports and that is fine because the are treated as different bundles.  Snaps are much more decoupled and do not impact host bundle lifecycle.

I think Snaps can be enhanced to use Web-Fragments descriptor in absence of web.xml for a snap.  Not sure if ordering rules make sense in context of OSGi dynamics.

I much more prefere service based approach.

Comment 3 Patsy Phelan

2010-11-12 09:58:58 EST

Hi Chris, 
 I haven't looked at web fragments at all but I would be in total agreement with Dmitry on this. The useful of SNAPS for me is the service orientation of it and the plug-n-play at deployment time. We do not intend to or event expect coordination with other developers for the "snaps" at development time at all. The development  will be completely independent and the overall console web front only plugged together at deployment time based on our plan files.

 The whole purpose of SNAPS for us is to allow 3rd party development of funtionality via bundles (that can be plug-n-play into the deployment plan) and now these same people can also provide 3rd party SNAPS at deployment time to extend the web console as needed.

 SNAPS really fits with what we are intending to do and have already begun. It brings modularity to the web front just like OSGI brings it to the application.

Comment 4 Chris Frost

2010-11-12 11:10:10 EST

Thanks for the comments guys. I might get time to type up something nice about Snaps next week and these comments will be really helpful.

Comment 5 Chris Frost

2010-11-26 12:07:32 EST

I have added some text to the wiki (http://wiki.eclipse.org/Virgo/Future) for now. I intend to produce a proper Blog post about Snaps when I have the time.