lairtonb / jspf Goto Github PK

java.lang.ClassCastException: $Proxy29 cannot be cast to 
net.xeoh.plugins.base.Plugin
    at net.xeoh.plugins.base.impl.PluginManagerImpl.hookPlugin(PluginManagerImpl.java:421)
    at net.xeoh.plugins.base.impl.loader.AbstractLoader.processPending(AbstractLoader.java:264)
    at net.xeoh.plugins.base.impl.loader.AbstractLoader.tryToLoadClassAsPlugin(AbstractLoader.java:207)
    at net.xeoh.plugins.base.impl.loader.InternalClasspathLoader.loadAllClasspathPluginClasses(InternalClasspathLoader.java:102)
    at net.xeoh.plugins.base.impl.loader.InternalClasspathLoader.loadFrom(InternalClasspathLoader.java:70)
    at net.xeoh.plugins.base.impl.PluginManagerImpl.doAddPluginsFrom(PluginManagerImpl.java:226)
    at net.xeoh.plugins.base.impl.PluginManagerImpl.addPluginsFrom(PluginManagerImpl.java:208)
    at net.xeoh.plugins.core.PluginManagerDisablingPlugins.setUp(PluginManagerDisablingPlugins.java:67)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
    at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

(see summary)

What steps will reproduce the problem?
1. add a method with the @Thread annotation
2. throw an exception in this thread

What is the expected output? What do you see instead?
expected: stack trace and exception message in the console
actual output:
17.06.2010 12:13:23 net.xeoh.plugins.base.impl.Spawner$2 run
WARNUNG: Error invoking requested thread on plugin 
de.dfki.plugins.implementations.EpocRawDataPluginImplementation
17.06.2010 12:13:23 net.xeoh.plugins.base.impl.Spawner$2 run
WARNUNG: null

What version of the product are you using? On what operating system?
Win XP, latest version

Please provide any additional information below.

I created a jar containing a class TestPlugin implementing IPlugin which 
extends the Plugin interface from jspf. This jar is deployed within an EAR.  I 
call an EJB method which starts the PluginManager and tries to add plugins from 
the classpath via 

pm.addPluginsFrom(new URI("classpath://*"));

This results in "ERROR [STDERR] java.util.zip.ZipException: error in opening 
zip file". The jar file has the following content:

$ jar tf lib/plugintest.jar
META-INF/
META-INF/MANIFEST.MF
com/
com/company/
com/company/app/
com/company/app/examples/
com/company/app/examples/plugintest/
com/company/app/examples/plugintest/IPlugin.class
com/company/app/examples/plugintest/TestPlugin.class

- jspf-0.9.0
- latest Java 1.6
- latest Mac OS X 10.6
- jboss 5.1.0.GA

Is this an issue or just me not seeing the problem?

-

Cite Groups-Entry 'Loading nested jars':

I'm trying to load jars from that are nested in a big jar on my class (made 
using one-jar). It has pretty much this layout: 
bigjar 
   - lib 
       - jar1.jar 
       - jar2.jar 
   - main 
       - main.jar 
   - META-INF 
However, I saw this information on the documentation: 
"JSPF doesn't inspect ZIP files (or nested JARs) and I am undecided if this 
feature will be implemented in the future. For the moment, please put all 
plugin JARs into a plain vanilla folder." 
There is a way to go around this? Why exactly this functionality is not 
planned to be implemented? 

When I do:

PluginManager pm = PluginManagerFactory.createPluginManager();
pm.addPluginsFrom(ClassURI.CLASSPATH)

This error is thrown:

java.lang.VerifyError: Cannot inherit from final class
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
    at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2889)
    at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1170)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1678)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
    at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:128)
    at org.codehaus.classworlds.DefaultClassRealm.loadClassDirect(DefaultClassRealm.java:242)
    at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:222)
    at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:145)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:249)
    at net.xeoh.plugins.base.impl.classpath.ClassPathManager.findSubclassesFor(ClassPathManager.java:218)
    at net.xeoh.plugins.base.impl.classpath.loader.InternalClasspathLoader.loadAllClasspathPluginClasses(InternalClasspathLoader.java:129)
    at net.xeoh.plugins.base.impl.classpath.loader.InternalClasspathLoader.loadFrom(InternalClasspathLoader.java:77)
    at net.xeoh.plugins.base.impl.classpath.ClassPathManager.addFromLocation(ClassPathManager.java:142)
    at net.xeoh.plugins.base.impl.PluginManagerImpl.addPluginsFrom(PluginManagerImpl.java:128)

NOTE: Using JDK 1.6 + Tomcat 7

And do NOT name the whole remote package as XMLRPC ...

What steps will reproduce the problem?
1. I add plugins from a path that contains plugins in JARs:
PluginManager pm = PluginManagerFactory.createPluginManager();
pm.addPluginsFrom((new File(getPluginsPath())).toURI());
2. JSPF throws an no class def found error.

The problem is:
I see the FileLoader tried to init plugin after it found plugin location. If 
that, when a plugin is at top of location list, but use @InjectPlugin plugin 
that places at the last position of location list, then the class loader could 
not found code for that @InjectPlugin and throw an error.

Hope this issue will be fixed soon.
Sorry for my bad English, thanks.

What steps will reproduce the problem?
UNKNOWN
1.Create common project
2.Include project in several plugins 
3.Load plugins
4.Run from IDE -works
5.Run from CMD one of the plugins cannot find common class.

What is the expected output? What do you see instead?
Recently added a plugin to my solution and it does not see the class like 
others do

What version of the product are you using? On what operating system?
JSPF 1.0.0 -Windows 7 -NetBeans 7.1 -Java 1.7

Please provide any additional information below.
It happened a while before but I can't remember what fixed it. I can't remember 
if I even did something to fix it.

Take any plugin (f.i. CoolPlugin) and move all its contents into an inner class:
public class MyPlugin {
   @PluginImplementation
   public static class MyInnerPlugin implements Plugin {
    // everything goes here
   }
}

I expected this inner class to be discovered/loaded, but it is not.

I am using RC4 on Ubuntu 9.10/java "1.6.0_24"

Reason for doing this:
My plugin is a trivial factory for a specific type of object Thingy. Here, 
Thingy is the important class containing the relevant coed. ThingyFactory is 
trivial and I would like to keep these trivial classes 'stuffed away' in Thingy 
to reduce the number of files.

Thanks for the nice framework!

Yesterday while profiling my application in NetBeans and VisualVM I discovered 
that no plugins classes profiled at all. They are invisible to profilers.
Possible due to separate classloader or some black magic during instantiating.

Are these results predictable or I just use wrong tools for profiling?

NetBeans 6.9, VisualVM 1.3
JSPF 0.9

Thanks,
Maxim

I use jspf.core-1.0.2.jar in my Android project.

I have an interface "RDMAddin" with "getData():String" method who extend Plugin.

I have an interface implementation "RDMAddinDevice" who implement RDMAddin.

In my Activity, I have this:

PluginManager pluginManager = PluginManagerFactory.createPluginManager();
pluginManager.addPluginsFrom(new ClassURI(RDMAddinDevice.class).toURI());
RDMAddin addinDevice = pluginManager.getPlugin(RDMAddinDevice.class);
Log.d(this.getClass().getName(), addinDevice.getData());

My problem:
When I run my activity, I have a nullpointerexception in last line 
(addinDevice.getData()) and I don't understand why.

I followed the tutorial and the RunningOnAndroid subject in wiki but I don't 
understand my error.

Thanks for your help.

Not possible to do the following if we are behind a proxy where we need to 
provide user/pw to authenticate



pm.addPluginsFrom(new URI("http://jspf.googlecode.com/files/coolplugin.jar"));

Please upload jspf to the common OSS repository. More information can be found 
in the provided link[1]. That link also has information for doing a manual 
upload if the project is not a maven project.

[1] http://maven.apache.org/guides/mini/guide-central-repository-upload.html

I just want to point you to james.apache.org/jspf, a java implementation of the 
SPF protocol.

jSPF exists since 2006, and I am one of the authors.

As they are both java open source projects I don't think it is good to have 
this name clash for the community.

WDYT?

First step should be a small diagnosis -> text converter. 

Excerpt from mail

> Now, we're actually probably going to be generating a list of explicit URIs
> to jar files in a defined location (similar to how Jenkins loads plugins
> from $HUDSON_HOME/plugins), so this won't really affect how we do the plugin
> loading, but I'd like to understand what's going on with JSPF's handling of
> the classpath to keep from getting bitten by it in the future (e.g. if we

Could it be that the web server / application runtime adds the code where the 
PluginManager is being created (i.e., PluginService) dynamically. In that case, 
JSPF wouldn't 'see' anything about where it is right now, and also wouldn't be 
able to find the other plugins. 

--> Should also check the classloader source of PluginManager.

Hello Ralf,

Is it possible to group several plugins with one classloader?

In my real-life case each plugin has several cross-dependent Apache Cayenne 
(database persistence engine) classes. When one class tries to resolve another 
it failes as doesn't recognize second because the second came from another 
classloader.
I had to write several helper methods in each plugin to load Apache Cayenne 
class from plugin when it required by main application, so in such "snowflake" 
scheme it's ok. But when I try to convert "snowflake" to "web" the problem 
arises.


So I propose a grouping (based on "codeword" or other plugin dependency) for 
loading plugins with one classloder.

Your opinion?

Thanks,
Maxim

Maven repository is not available for this description.

<repository>
     <id>jspf</id>
     <name>JSPF</name>                            <url>http://jspf.googlecode.com/svn/trunk/JSPF/repository/</url>
</repository>

E.g. by using in v2.RemoteDiscoveryImpl and v3.RemoteDiscoveryImpl

There should be an interface with simple yet powerful debugging and diagnosis 
information, with status reports

- if there were problems loading plugins
- if plugins behave badly
- if plugins don't stick to certain standards
- ...

The description to clone git repository renders

git clone https://code.google.com/p/jspf/

Cloning into 'jspf'...

fatal: remote error: Repository not found

tried it in environments: linux command, windows command, eclipse

Hi,

I am wondering if there is any particular reason why the return object of 
PluginManager.addPluginsFrom is currently 'void'?
It would be useful if PluginManager.addPluginsFrom returns a Collection of 
added Plugins so the programmer can store them for later internal use, or use 
them immediately. 

I am aware of PluginMangerUtils.getPlugins but sometimes there would be too 
much hassle to filter out an specific plugin from that list, especially when 
there are multiple implementations of a plugin interface.

I believe that the suggested change in the API will be non intrusive, because 
no change would be necessary in any existing code which uses this method.

Kind regards,

What steps will reproduce the problem?
Try to add the same plugin directory more than once.

What is the expected output? What do you see instead?
No output to system out.
Use logging

What version of the product are you using? On what operating system?
0.9.0

Please provide any additional information below.

Hello there
I met some issues with InformationBroker:

1. I register listener in my plugin 
    @Init
    public void init() {
        InformationBrokerUtil ibu = new InformationBrokerUtil(broker);

        ibu.onValue(new ObjectID("action:startup"), new
ValueListener<Object>() {
            public void newValue(Object value) {...}
        });
    }

2. Then I load plugins in core application:
PluginManager pm = PluginManagerFactory.createPluginManager();
pm.addPluginsFrom(new File(cbadminProps.getPluginFolder()+"/").toURI());
InformationBroker broker = pm.getPlugin(InformationBroker.class);

        try {
            if (broker != null) {
                Thread.sleep(100);
                broker.publish(new ObjectItem("action:startup", ""));
                Thread.sleep(100);
            }
        } catch (InterruptedException interruptedException) {
        }

3. If I remove "Thread.sleep(100);" strings, then listener fired up several
(2 to 3) times upon one broker.publish() method.

I suppose such issue should not be solved by 'sleep' statements because
timing is very tender thing, especially on old machines. Anyway, end user
should not bother with threads in this case.

Using latest (0.8?) version of code.

Any ideas?
Thanks,
Maxim

After several hours of late-night fussing with JSPF to even run the simple 
example in the video, I have now learned that without the line..

pm.addPluginsFrom(new java.io.File("bin/").toURI());

.. my internal test plugin always returns null. Misleadingly thinking this line 
only loaded external jar files, I promptly commented it out. However now I 
realize it's loading .class plugins from the compiled bin folder 
post-execution. I assumed that JSPF could load internal plugins virtually with 
voodoo magic. The issue for me was a lack of obvious documentation about this-- 
loading internal plugins. I'm not sure if this is something that should be 
added to the homepage or the simple examples, or if the amount of people that 
actually follow directions is too high. Just posting.

Same issue as with #27, but now on Android. Android interface level 14, jspf 
1.0.2

Following the suggestion in the Wiki for Android, I do this (logging statements 
omitted):
   Action.getPluginManager().addPluginsFrom(new ClassURI(DownloadActionImplActionFactory.class).toURI());
   Action.getPluginManager().addPluginsFrom(new ClassURI(nl.wmc.fedNet.client.actions.ExecuteActionImpl.ActionFactory.class).toURI());

The first statement works fine. The second does not.

From the android log:

11-30 16:29:21.270: I/System.out(31508): 16:29:21.272 [main] INFO  
aa.bbb.ccc.GuiActivity - 
classpath://aa.bbb.ccc.client.actions.DownloadActionImplActionFactory

...the first one above worked fine...

11-30 16:29:23.029: I/System.out(31508): 16:29:23.033 [main] INFO  
aa.bbb.ccc.GuiActivity - 
classpath://aa.bbb.ccc.client.actions.ExecuteActionImpl.ActionFactory
11-30 16:29:23.039: D/dalvikvm(31508): GC_CONCURRENT freed 593K, 8% free 
10471K/11271K, paused 5ms+5ms
11-30 16:29:23.039: W/System.err(31508): java.lang.ClassNotFoundException: 
aa.bbb.ccc.client.actions.ExecuteActionImpl.ActionFactory
11-30 16:29:23.059: W/System.err(31508):    at 
dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:61)
11-30 16:29:23.059: W/System.err(31508):    at 
java.lang.ClassLoader.loadClass(ClassLoader.java:501)
11-30 16:29:23.059: W/System.err(31508):    at 
java.lang.ClassLoader.loadClass(ClassLoader.java:461)
11-30 16:29:23.059: W/System.err(31508):    at 
net.xeoh.plugins.base.impl.classpath.ClassPathManager.loadClass(ClassPathManager
.java:165)
11-30 16:29:23.059: W/System.err(31508):    at 
net.xeoh.plugins.base.impl.classpath.loader.AbstractLoader.tryToLoadClassAsPlugi
n(AbstractLoader.java:116)
11-30 16:29:23.059: W/System.err(31508):    at 
net.xeoh.plugins.base.impl.classpath.loader.InternalClasspathLoader.loadClassFro
mClasspathByName(InternalClasspathLoader.java:156)
11-30 16:29:23.059: W/System.err(31508):    at 
net.xeoh.plugins.base.impl.classpath.loader.InternalClasspathLoader.loadFrom(Int
ernalClasspathLoader.java:101)
11-30 16:29:23.059: W/System.err(31508):    at 
net.xeoh.plugins.base.impl.classpath.ClassPathManager.addFromLocation(ClassPathM
anager.java:140)
11-30 16:29:23.069: W/System.err(31508):    at 
net.xeoh.plugins.base.impl.PluginManagerImpl.addPluginsFrom(PluginManagerImpl.ja
va:127)
11-30 16:29:23.069: W/System.err(31508):    at 
aa.bbb.ccc.GuiActivity.onCreate(FednetGuiActivity.java:77)
....(snip)....
11-30 16:29:23.099: W/InternalClasspathLoader(31508): ClassNotFoundException. 
Unable to inspect class 
aa.bbb.ccc.client.actions.ExecuteActionImpl.ActionFactory although it appears 
to be one.


One additional question: do I have to register *all* plugins explicitly like 
this? Is there no way to include form starred classpath, or everything in the 
package I give a reference class from?

is it possible to add Maven support (insert the project to a central 
repository) ?

Thanks.

See this report from one of our users:


> I've found I can work around this with a much narrower search
> ("classpath://org.systemsbiology.[project name].plugins.*"), but I'm
> worried this isn't a stable solution (although there's no reason it
> shouldn't be). Actually, never mind, it's apparently failing to do a *
> match on classes at that point; I'll experimentally throw in the name
> of my actual plugin class and see if it's just not wildcarding, or if
> I simply screwed up the class search.


> What would I need to do to make a classpath://* search work- is there
> any strategy other than bumping up the PermGen space, and if not, what
> size should I set it to? Is there some plan to rework the loading
> algorithm to save memory by apparently wasting it, and- after a
> classloader contains too many classes- archive the names of found
> plugin classes, drop the classloader and all references to the plugin
> classes, and create a new one with a targeted search for just the
> found plugins, and then another new one to continue the search? This
> should allow the original classloader, and all the "oops, not a
> plugin" classes to get garbage-collected.

If a class is not a plugin (no @PluginImplementation), but implements a plugin 
interface and has a one-arg-constructor, @InjectPlugin should be able to 
construct and inject that instead. 

-

Hello

In its current state InformationBroker plugin is mostly for demo reasons,
but there's easy way to make it more real-life (and business) oriented.

I propose following changes:

- subscribe() method shouldn't call checkSubscriptions(), because
subscriber should receive notifications sent only _after_ moment it was
subscribed. Currently subscriber fires even if information was set/update
before subscription.

- checkSubscriptions() works incorrect with ALL_SET subscription mode
a) if nothing changed then no subscribers should ne notified.
b) subscriber should be notified only if item it subscribed for is changed.
Currently - after the moment all items match - subscriber notified every
time any item changes, even items not in subscription.

- sometimes items should be "consumed" (set to null) silently without
firing notification events. As you provided no method for this I propose
consume() method

I attach modified InformationBrokerImpl.java file. It's not optimized but
works.

Any ideas?
McSeemZ

A discovery call returns this exception:

java.util.concurrent.TimeoutException
    at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228)
    at java.util.concurrent.FutureTask.get(FutureTask.java:91)
    at net.xeoh.plugins.remotediscovery.impl.v2.RemoteDiscoveryImpl.getRemoteProxyToDiscoveryManager(RemoteDiscoveryImpl.java:367)
    at net.xeoh.plugins.remotediscovery.impl.v2.RemoteDiscoveryImpl.resolve(RemoteDiscoveryImpl.java:514)
    at net.xeoh.plugins.remotediscovery.impl.v2.RemoteDiscoveryImpl.discover(RemoteDiscoveryImpl.java:491)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at net.xeoh.plugins.base.impl.metahandling.PluginMetaHandler.invoke(PluginMetaHandler.java:82)
    at $Proxy18.discover(Unknown Source)
    at net.xeoh.plugins.remote.DiscoveryPluginTest3.testDiscovery(DiscoveryPluginTest3.java:99)

What steps will reproduce the problem?
1. Use JSPF in a GWT project

Please check the complete issue details on : 
http://stackoverflow.com/questions/6912504/ant-task-to-include-source-files-for-
gwt

Mail from one of our users:

I use plugins in a Web application. Each of my plugins has its own directory. I 
load my plugins individually by calling PluginManager#addPluginsFrom(URI). It 
works like a charm. Sometimes, my plugins require their own Jar files 
(dependencies) to work properly. I would like to have a "lib" subdirectory in a 
plugin's directory where I would put the said jars. At the moment, I have to 
put the dependencies in my default classpath, which is annoying. What do I need 
to do so that the plugin's ClassLoader recognizes its dependencies?

From Google Groups:



On 9 Aug., 11:40, Anastasios Bourazanis <[email protected]> wrote:
> You are right sorry, I have send you the wrong file.Im attaching a new
> one that as I see it has SpawnerTracer in.

Okay, the problem is that apparently Tomcat (or whoever is responsible for 
loading your class) loads JSPF from another classloader than it loads your 
application from. This means your application / class can see the CoolPlugin, 
but JSPF does not find it, as its location is "concealed" (rather: hidden in 
another class loader branch JSPF does not have access to). 

Two solutions: 

long term: JSPF needs to do more classloader juggling (e.g., walk back stack 
trace and get all classes and classloaders) and inspect their paths as well 
(will file an issue, but don't wait for it, I'm short on time atm) 

short term: put JSPF all your plugins into something that is loaded by the same 
classloader, i.e., either put your plugin as a JAR into your lib folder, or put 
JSPF "closer" to your application (no idea if Tomcat actually allows this)

Unfortunately class loading does not work if package of this class contains 
".class" (an example: 
com.domain.classification).

Appears not to work. Investigating ...

A few notes:

1. Should only be done when it is clear what should happen with Pluglets
2. We should convert at least ClasspathManager, Loader and Cache. 
3. In that process, see if we can reduce internal complexity. 
4. Dump Meta-Handling aka Supervision?

In order to improve the speed of the service discovery, the RemoteDiscovery 
should do lookups in 
parallel. In addition, one of the parallel branches  should use cached 
information of the last run in 
order to check if one of the old devices is still alive. In many of our 
situations, this could reduce the 
waiting times to a minimum. 

NullPointerException in:

 infos = this.jmdns.list(TYPE); 

-

Implement as classpath://* but filter for given name. 

I am trying to see if JSPF can be used with GWT. GWT needs sources for all 
modules and I could not get around this limitation yet.