Pluggable Modules

[Bent C Dalager]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I wanted to build an application that had pluggable modules, how
would I go about doing this?
I've thought a bit about it and the idea that comes to me is:
1. Have a jar file for each module.
2. When the application starts, check for the possible jar files - these
must be known prior to deployment of course.
3. If the modules exist, build menu's based on what exists.


Is this logical, or is there a standard way to handle this type of problem?

Typically, you have a config file somewhere that lists all the modules
you should be looking for. It tends to do this by listing the name of
an entry point into each module, e.g., its main factory class.

So I could have a myapp.properties file that says:
com.company.app.modules=com.company.app.module1.FooFactory,com.company.app.module2.BarFactory

The question then becomes: where do you put this config file and how,
if at all, do you give the user access to it for editing?

If you intend for the user to modify the list, you might want to have
only a default list in the config file and access the user's own
preferences about the matter through the preferences API. You'd then
just put the defaults config file into your app's JAR and have that
happen as part of your regular build job.

Cheers
Bent D

 

[VisionSet]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I wanted to build an application that had pluggable modules, how
would I go about doing this?
I've thought a bit about it and the idea that comes to me is:
1. Have a jar file for each module.
2. When the application starts, check for the possible jar files

- these must be known prior to deployment of course.

Not sure that is true.
So long as you can access any classes proffered and load them dynamically,
and those classes were written to be 'aware' of the application. Then they
can register themselves with your application.
Or have I misunderstood?

 

[Andrew]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I wanted to build an application that had pluggable modules, how
would I go about doing this?
I've thought a bit about it and the idea that comes to me is:
1. Have a jar file for each module.
2. When the application starts, check for the possible jar files - these
must be known prior to deployment of course.
3. If the modules exist, build menu's based on what exists.


Is this logical, or is there a standard way to handle this type of problem?

Thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fsbxx4nopx2ZsVURAsjTAJ9VExAexyDSBQMnBAZDsqfg3O4VngCcDRkJ
farGgb2+DqU0SBV+VngFQx4=
=p1p0
-----END PGP SIGNATURE-----

 

[VisionSet]

I understand what you are saying here, and thanks for your comment. I'd
like it if you could clarify what you mean by making the classes 'aware'
of the application. I understand the concept, but how would such a thing
actually be implemented? I can see how the application would be aware of
~ classes and register the classes for use, but not the other way around,
which is how I read your reply. Perhaps I am confused!

A common interface that all plugables implement, then the application just
deals with objects of type ThatInterface. Perhaps if the pluggable is more
complex and constitutes several classes then access could be through a
facade that implements that interface.
Then the classes can be dynamically loaded on demand, as you are aware. Each
class could have a static block which registers itself with a central
repository as it is loaded.

class PlugableA implements Plugable {
static {Application.addPlugable(PlugableA.class);}
}

I'm not up on plugins, so not sure how they generally operate, perhaps you
need fine control over instantiation of objects of a Plugable, in which case
you can either do Class.newInstance(); or perhaps have an inner class
factory.

You'll have to forgive me re the patterns, I've been learning some. Don't
use them unless you have to.

 

[Andrew]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

VisionSet wrote:
| |
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>If I wanted to build an application that had pluggable modules, how
|>would I go about doing this?
|>I've thought a bit about it and the idea that comes to me is:
|>1. Have a jar file for each module.
|>2. When the application starts, check for the possible jar files
|
|
|>- these must be known prior to deployment of course.
|
|
| Not sure that is true.
| So long as you can access any classes proffered and load them dynamically,
| and those classes were written to be 'aware' of the application. Then
they
| can register themselves with your application.
| Or have I misunderstood?
|
| --
| Mike W
|
|

I understand what you are saying here, and thanks for your comment. I'd
like it if you could clarify what you mean by making the classes 'aware'
of the application. I understand the concept, but how would such a thing
actually be implemented? I can see how the application would be aware of
~ classes and register the classes for use, but not the other way around,
which is how I read your reply. Perhaps I am confused!

- --
Andrew.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fvy6x4nopx2ZsVURArQmAJ0evDgJU7xiKPiv9/lkPE0InmDTgwCguWO1
L62xAoU7DKThBxBHOWge25k=
=3MHU
-----END PGP SIGNATURE-----

 

[Andrew]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bent C Dalager wrote:
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>If I wanted to build an application that had pluggable modules, how
|>would I go about doing this?
|>I've thought a bit about it and the idea that comes to me is:
|>1. Have a jar file for each module.
|>2. When the application starts, check for the possible jar files - these
|>must be known prior to deployment of course.
|>3. If the modules exist, build menu's based on what exists.
|>
|>
|>Is this logical, or is there a standard way to handle this type of
problem?
|
|
| Typically, you have a config file somewhere that lists all the modules
| you should be looking for. It tends to do this by listing the name of
| an entry point into each module, e.g., its main factory class.
|
| So I could have a myapp.properties file that says:
|
com.company.app.modules=com.company.app.module1.FooFactory,com.company.app.module2.BarFactory
|
| The question then becomes: where do you put this config file and how,
| if at all, do you give the user access to it for editing?
|
| If you intend for the user to modify the list, you might want to have
| only a default list in the config file and access the user's own
| preferences about the matter through the preferences API. You'd then
| just put the defaults config file into your app's JAR and have that
| happen as part of your regular build job.
|
| Cheers
| Bent D

Thanks,
I see how you are approaching it which is similar to how I pictured it.

- --
Andrew.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fvz4x4nopx2ZsVURApvFAKDW2gnMoDEJ5XWRZfR7i0mdO5VqIgCg0Fao
Ew0d/YnGqvpFjZokzEBJnLQ=
=3hz7
-----END PGP SIGNATURE-----

 

[Andrew]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew wrote:
| If I wanted to build an application that had pluggable modules, how
| would I go about doing this?
| I've thought a bit about it and the idea that comes to me is:
| 1. Have a jar file for each module.
| 2. When the application starts, check for the possible jar files - these
| must be known prior to deployment of course.
| 3. If the modules exist, build menu's based on what exists.
|
|
| Is this logical, or is there a standard way to handle this type of
problem?
|
| Thanks.

I've been thinking a bit more about this, and I have another question.
If you were to package a module up in a jar file, would this mean you
slice your packages up based on business functionality, or do you slice
it up based on technical functionality (such as data access, client,
controllers, messaging)?
I've always created package structure based on technical functions, but
doing it this way would mean it's quite hard to get a jar file packaged up?

- --
Andrew.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/fw2ix4nopx2ZsVURAlRoAJwN8gK1nz0Xn1uoS29Jru3FEsKEVgCcCnPo
q+h7DpmtPGV5wsaanmNfJSE=
=lXgG
-----END PGP SIGNATURE-----

 

[Bent C Dalager]

Then the classes can be dynamically loaded on demand, as you are aware. Each
class could have a static block which registers itself with a central
repository as it is loaded.

But how do you make sure the classes get loaded?

Cheers
Bent D

 

[VisionSet]

But how do you make sure the classes get loaded?

I'm not sure what you're getting at, what's wrong with:
put them on the classpath
Class.forName("myPackage.myClass");

 

[Bent C Dalager]

I'm not sure what you're getting at, what's wrong with:
put them on the classpath
Class.forName("myPackage.myClass");

You'll typically have a number of these classes. You write one
Class.forName() call for each?

Cheers
Bent D

 

[VisionSet]

You'll typically have a number of these classes. You write one
Class.forName() call for each?

Like I said I'm not up on plugins
so, what usualy happens? user specifies plugin ?
directory search of available classes under com.me.plugins.* ?
properties file with plugins specified ?
loop through them with class.forName()
or load on demand from these details stored in collection ?

I'm no expert!

 

[Roedy Green]

You'll typically have a number of these classes. You write one
Class.forName() call for each?

Let us say your dynamically loaded classes all implement the HolInfo
interface:

then you write something like this:


HolIng holiday delegate = (HolIng)
(Class.forName(
"com.mindprod.holidays." + inteRnationAlisaTion
).new instance());

see http://mindprod.com/jgloss/classforname.html

 

[Bent C Dalager]

Like I said I'm not up on plugins
so, what usualy happens? user specifies plugin ?
directory search of available classes under com.me.plugins.* ?
properties file with plugins specified ?
loop through them with class.forName()
or load on demand from these details stored in collection ?

It all really depends on how close you want the user to be to the
configuration. If he is meant to edit it at all, it could just be an
obscure file somewhere he has to load into a text editor to edit
manually, or your app could provide him with a way to edit it in a
user friendly manner. Or the modules might automatically install
themselves and update the config file.

There isn't really a decent way of searching for classes from within
Java, though, so I believe the common solution is to have a list of
classes to load in a config file.

I'd imagine something like this (exception handling omitted):

String[] classesToLoad = myConfig.getPluginModuleClassNames();
for (int i = 0; i < classesToLoad.length; ++i)
{
Module m = (Module) Class.forName(classesToLoad).newInstance();
m.startModule();
}

where myConfig.getPluginModuleClassNames() loads a list of class names
from the config file, and "Module" is the interface that all my
plugins must implement.

Cheers
Bent D

 

[Lee Fesperman]

Let us say your dynamically loaded classes all implement the HolInfo
interface:

then you write something like this:

HolIng holiday delegate = (HolIng)
(Class.forName(
"com.mindprod.holidays." + inteRnationAlisaTion
).new instance());

see http://mindprod.com/jgloss/classforname.html

Yes, but you don't need the extra set of parentheses. Also, your code should use HolInfo
instead HolIng ... documentation error ;^)

 

[Roedy Green]

HolIng holiday delegate = (HolIng)
(Class.forName(
"com.mindprod.holidays." + inteRnationAlisaTion
).new instance());

That is the weirdest ruddy thing. That is not at all what I wrote,
however it is what is in my outbox. Perhaps the spell checker went
nuts on it without me paying attention.

See http://mindprod.com/jgloss/classforname.html