Hi, Brian,
Thanks for your post and welcome to ops4j!
I've been using pax-wicket for a while now. Generally, it's an excellent
solution. We just need more users now so there is momentum and
motivation to iron out more wrinkles in the product.
So, very good to have you around. Spread the word!
Cheers,
Dave
On Mon, 2008-04-07 at 22:19 -0400, Brian Topping wrote:
> David,
>
> I'm new to pax-wicket and ops4j, so please consider my comments here
> accordingly.. :-) I've only been working with pax-wicket for the last
> few days to get my first OSGi environment set up with it, but am
> extremely excited to get something going!
>
> At this point, I don't have a anything valuable to add, I mostly just
> wanted to add $0.02 since there wasn't a response yet to your post. I
> have no local credential to offer advice on how to run the project,
> but out of self-interest, it would be great to see it come back to a
> more active status. If there's anything I can do as a part of that,
> I'd be happy to do what I can, and hopefully I'll have some
> contributions as I get my head around it as well.
>
> I'm also on #ops4j when I am logged in to IRC, if any readers see me
> around, please don't hesitate to say hi.
>
> Kind regards,
>
> Brian
>
> On Apr 7, 2008, at 2:45 AM, David Leangen wrote:
>
> >
> > Hello.
> >
> > My impression is that right now, there are not too many users of
> > pax-wicket (another problem in itself that should be discussed at some
> > point, but not the purpose of this thread).
> >
> > I suspect that there may be some classloading issues that will only
> > surface once people start really using the product in a system with a
> > lot of dynamic stuff going on.
> >
> >
> > Lately, I have been using a kind of library bundle with a widget
> > factory
> > that supplies my applications with a selection of widgets. I find this
> > more natural and especially much easier than having to register each
> > individual widget in pax-wicket.
> >
> > However, due to the way classloading works in this environment,
> > exceptions are being thrown by Wicket during deserialization of pages.
> > The reason is because the proper classes cannot be found for these
> > library widgets.
> >
> >
> > Edward suggested that I register an IClassResolver for these bundles.
> > There are a few issues with this approach, however.
> >
> > First, you need to make sure that the bundle is only supplying a
> > resolution for classes that it is responsible for. If it replies
> > anything other than null for classes outside its scope, then strange
> > things happen. The way I resolved this issue was to put a header in
> > the
> > library bundle's manifest for the packages for which it is
> > responsible:
> >
> > Resolver-Packages: com.mycompany.mypackage1,
> > com.mycompany.mypackage2,
> > com.mycompany.mypackage3
> >
> > I then have a resolve that I register for the bundle, which looks like
> > this:
> >
> > public class BundleClassResolver
> > implements IClassResolver
> > {
> > private final BundleContext m_bundleContext;
> > final List<String> m_resolverPackages;
> >
> > public BundleClassResolver( final BundleContext bundleContext )
> > {
> > m_bundleContext = bundleContext;
> > final Bundle bundle = m_bundleContext.getBundle();
> > @SuppressWarnings("unchecked")
> > final Dictionary<String, String> headers = bundle.getHeaders();
> > final String[] resolverPackages =
> > headers.get( "Resolver-Packages" ).split( "," );
> > m_resolverPackages = new ArrayList<String>();
> > for( final String resolverPackage : resolverPackages )
> > {
> > m_resolverPackages.add( resolverPackage );
> > }
> > }
> >
> > public Class<?> resolveClass( final String className )
> > throws ClassNotFoundException
> > {
> > final int dotIndex = className.lastIndexOf( '.' );
> > final String classPackage = className.substring( 0, dotIndex );
> > if( !m_resolverPackages.contains( classPackage ) )
> > return null;
> >
> > return m_bundleContext.getBundle().loadClass( className );
> > }
> > }
> >
> >
> > BTW, I noticed that the expected behaviour for the IClassResolver is
> > to
> > return null if it comes across a class for which it should not take
> > responsibility, and throw a CNFE if it should be responsible, but
> > cannot
> > resolve the class.
> >
> > Anyway, this approach solves the issue in most respects except for one
> > major problem: there are classes that it should take responsibility
> > for,
> > but are very difficult to determine in advance. There are imports into
> > this bundle, and imports of those imports, and so on, and so on.
> > Actually trying to manage the responsibility of this IClassResolver
> > sounds like a very complex task that will almost duplicate the OSGi
> > system itself.
> >
> >
> >
> > I'm not sure what the best way is to proceed with this. Any useful
> > suggestions would be really appreciated.
> >
> >
> > Anyway, this issue leads me to believe that even without using
> > libraries
> > like I am, the current mechanism in pax-wicket will cause problems
> > down
> > the line. Currently, it looks like the wrong classloader may be
> > answering for the resolution of a class that it should not be
> > answering
> > for.
> >
> >
> > Thoughts?
> >
> >
> >
> >
> > _______________________________________________
> > 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
