"jesper.pedersen" wrote : | The goal of Papaki is to provide a simple API for developers and thereby being able to deploy the library in any environment (like one of the current users on WebSphere). | Sure, but why re-invent the wheel? * your Reflection vs. Javassist abstraction == JBoss Reflect * your split between jar or directory == JBoss VFS e.g. if you wanna add a restriction check (e.g. exclude any non-exported class by OSGi manifest), you have to do it in 4 diff places: * Reflect + jar * Reflect + directory * Javassist + jar * Javassist + directory With VFS this is a simple filter; recursion or plain resource. Reflection abstraction is a single TypeInfoFactory change; via setter. "jesper.pedersen" wrote : | If the current API and scope of the project doesn't fit into the MC project I welcome a fork of the code into a new project where we can share ideas across the projects. Yup, that's what I think I'll do. But I'm still confused by where your version of Papaki really can be used. As it clearly lacks proper integration layer with existing environments, be it MC, JBossAS, WebsFear, ... While building repo, either from existing papaki.ser or runtime, you should be able to hook into existing restriction mechanisms. Otherwise you can potentially load a bunch of code user restricted at runtime; jboss-clasloading.xml, jboss-scanning.xml, ... (and its matching metadata instances) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261288#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...