Have considered implementing your own HttpContext object? You can then do 
whatever custom lookup mechanism you want.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[email protected]

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





From:   Martin Petzold <[email protected]>
To:     OSGi Developer Mail List <[email protected]>
Date:   2011/06/07 13:57
Subject:        [osgi-dev] ZK Web Application Framework with OSGi
Sent by:        [email protected]



Hi osgi-devs,

we are working on the integration of ZK (http://www.zkoss.org) in an 
OSGi environment. We would like to have the two ZK servlet registrations 
seperated from the x web content/applications (xml files, classes and 
resources). We have got one ZK bundle that registeres the servlets 
(using PAX Web) and x other bundles with *.zol resource files, 
controller classes and other resources.

ZK looks up resources on the classpath, so we need some mechanism to add 
the resources of other bundles (dynamically) to this classpath. For now 
we have identified two possibilities:

1. Use fragment bundles (host is ZK bundle): Resources would be found 
and this works out. But we don't have that loose coupling and also no 
separat classloader and less powerful lifecycle.

2. Use regular bundles: Export all packages containing resources and use 
"Dynamic-ImportPackage" in the ZK bundle.

2b. I think it could be possible to use an extender pattern and track 
these bundles from the ZK bundle, then import packages/resources that 
have been declared somehow dynamically (in Manifest)?! Via resolver hook 
or what is capable of this?

What do you think is best and are there any other patterns we could use? 
Is this even somehow possible on service layer level?

Big thanks in advance,

Martin

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to