Hi,
Wicket has a nice architecture in regards to resolve class and Resource finding.
Resolving class:
* Wicket has a concept call IClassResolver to resolve all classes
(pages, application specific component models (during deserialization
of wicket pages), application specific wicket component, etcs):
<code>
package wicket.application;
public interface IClassResolver {
Class resolveClass(String className);
}
</code>
The wicket application resolver can be set during initialization
process of wicket application.
What does pax wicket do is:
* Pax-wicket introduces DelegatingClassResolver concept, each bundle
that wants to "contribute" their specific component can do so by
registering IClassResolver with specific service property.
* DelegatingClassResolver tracks IClassResolver service that has the
same "pax.wicket.applicationname" service property. This ensure that
each DelegatingClassResolver instance only tracks IClassResolver
service specific for it's wicket application instance.
Resource finding:
Wicket assumes that the resources are accessible from the
page/component that requested it. Pax-wicket does not have to do much
in this regards.
However, in your context, It is entirely possible to do the same thing
as resolving class. Care must be taken when more than 1 bundle
providing the same resource with exactly the same path. I.e. Bundle A
and Bundle B provide "somewhere/somefile.ext" resource.
Hope this helps.
Regards,
Edward
On 10/20/06, Joe Toth <[EMAIL PROTECTED]> wrote:
> You are correct Niclas.
>
> I created 2 bundles, a client and a server to demonstrate the problem I am
> having.
>
> In the client...
>
> package client;
> public class ClientActivator implements BundleActivator {
>
> public void start(BundleContext context) throws Exception {
> ServiceTracker tracker = new ServiceTracker(context,
> ServerService.class.getName(), null);
> tracker.open();
>
> SystemService sys = (SystemService) tracker.getService();
>
> sys.init("applicationContext.xml",
> "client.ClientActivator");
> }
>
> public void stop(BundleContext context) throws Exception {
> }
>
> }
>
>
> In the server...
>
> package server;
> public class SystemServiceImpl implements SystemService {
>
> BundleContext bundleContext;
>
> public SystemServiceImpl(BundleContext context) {
> // This gets initialized with the BundleContext from the SystemActivator
> this.bundleContext = context;
> }
>
> public void init(String someFile, String someClass) {
>
> try {
> System.out.println("via bundle: "
> + bundleContext.getBundle().loadClass(someClass));
> System.out.println("via Class: " + Class.forName(someClass));
> System.out.println ("via bundle: "
> + bundleContext.getBundle().getEntry(someFile));
> System.out.println("via ClassLoader: "
> +
> getClass().getClassLoader().getResource(someFile));
> } catch (Exception e) {
> e.printStackTrace();
> }
>
> }
>
> }
>
>
> As normal it throws an exception on the first println. Which is what I
> expect.
>
> With Eclipse-RegisterBuddy/Eclipse-BuddyPolicy the first 2
> println statements work. But the 3rd does not find the file. It should,
> correct? This is one problem I'm trying to figure out.
>
> The next question is, is there a way to do this without the specialized
> Eclipse-RegisterBuddy.
>
> I'm going to take a look at Pax-wicket
>
> Thanks
>
>
>
> On 10/19/06, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > On 10/19/06, Benjamin Schmaus < [EMAIL PROTECTED]> wrote:
> > > > I knew about spring-osgi. I really wanted to know how to let an
> existing
> > > > class retrieve resources from another bundle
> > >
> > > Like Peter Kriens said, the Bundle object provides methods for
> > > retrieving resources from a given bundle, namely,
> > > Bundle.getEntry(String resource) and Bundle.findEntries(String path,
> > > String filePattern, boolean recurse).
> > >
> > > In the past I've used a BundleListener to inspect bundle's that have
> > > been INSTALLED to see if they provide a "conf/testng.xml" file, and if
> > > so add them to a datastructure that can be used to locate bundles that
> > > provide TestNG unit tests, which can later be run from a UI.
> > >
> >
> > Joe,
> > if I understand you correctly, you are essentially trying to grasp how to
> create bundles that are agnostic of future providers of resources (such as
> classes), yet use those resources as if they were available on the classpath
> as most legacy frameworks assumes.
> >
> > If so, Peter and Benjamin are very accurate, and if you want to check some
> actual code out, you could peek at Pax Wicket in
> https://scm.ops4j.org/repos/ops4j/projects/pax/wicket/service
> , which does exactly that. Can't quite remember what happens where, but if
> you want more precise pointers, I will look that up tomorrow, or perhaps
> Edward can point you in the right direction...
> >
> >
> > Cheers
> > Niclas
> >
> > _______________________________________________
> > general mailing list
> > [email protected]
> > http://lists.ops4j.org/mailman/listinfo/general
> >
> >
> >
>
>
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general
>
>
>
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
