Mike, Could you open a bug at https://www.osgi.org/bugzilla/enter_bug.cgi?product=Document%20Feedback with your comments?
Thanks, -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mike Wilson <mike...@hotmail.com> To: "'OSGi Developer Mail List'" <osgi-dev@mail.osgi.org> Date: 2013/06/27 16:38 Subject: [osgi-dev] targeting different HttpServices (RFC189) Sent by: osgi-dev-boun...@mail.osgi.org While looking through http://www.osgi.org/Download/File?url=/download/osgi-early-draft-2013-03.pdf to my delight I found that it is adressing the possibility for a whiteboard to select between multiple HttpServices. And my main use case (separate HttpServices for Public and Admin tasks) is even given as example, great! If I've interpreted the spec text correctly, a given servlet can then request to be registered in a particular HttpService by specifying the "osgi.http.whiteboard.service.target" service property. If it doesn't specify this property, it may be registered in any of the available HttpServices. But this last part is actually making this feature less useful for the Public/Admin scenario. The problem is that if the target property is forgotten (by developer error) on VerySecretAdminService, it may randomly register in the Public HttpService. In this scenario, with two distinct HttpServices both aimed for targeting, I would rather have servlets without target specification not being registered at all. Better safe than sorry. There are several ways to solve this, two that come to mind are: 1) Add a "requireTarget" boolean property on HttpServices to say that only servlets with a matching target property may be registered in it. 2) Add the reverse target construction so that a HttpService can express a filter on service properties for services it will accept: HttpService1 osgi.http.whiteboard.service.target="(SecurityClass=Admin)" Servlet1 SecurityClass="Admin" Or are there other ways to solve this scenario? Thanks Mike Wilson _______________________________________________ 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