Re: Major flaws with pax-wicket?

[Brian Topping]

David,








Kind regards,

Brian

On Apr 7, 2008, at 2:45 AM, David Leangen wrote:

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.

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.



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


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 );
   }
}



return null if it comes across a class for which it should not take

resolve the class.

Anyway, this approach solves the issue in most respects except for one

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.



the line. Currently, it looks like the wrong classloader may be

for.


Thoughts?




_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general

Lately, I have been using a kind of library bundle with a widget factory 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: BTW, I noticed that the expected behaviour for the IClassResolver is to responsibility, and throw a CNFE if it should be responsible, but cannot major problem: there are classes that it should take responsibility for, 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 answering for the resolution of a class that it should not be answering

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general