Jump to content
Excelsior Forums
tanelorn

Plug-in compilation

Recommended Posts

Hi,

Our application uses a plug-in mechanism implemented in the following way:

  • Each plug-in is a standalone jar, which must be in the [tt]CLASSPATH[/tt].
  • They all contain a descriptor, at a given, fixed path (let's say [tt]/resources/descriptor.xml[/tt]).
  • Each descriptor stores the name of the "main" class of the plug-in.
  • at start-up, descriptors are discovered using:

Thread.currentThread().getContextClassLoader().getResources("/resources/descriptor.xml")

  • We finally iterate on the descriptors collection to load each plug-in "main class".

For now, this has worked finely with JET by compiling all plug-in jars with the application jar, in a monolithic way.

But I would now like to make this more modular by compiling each plug-in jar in its own DLL. Will the JET runtime then be able to "discover" all of our plug-ins using the previous algorithm?

I suppose this part of the doc is appropriate:

"You need to tell the JET runtime in which DLL to look for each class or package. You may do that by adding the following options to the JETVMPROP equation or the JETVMPROP environment variable:

-dll:class-name:dll-name or

-dll:class-prefix*:dll-name"

But will this work in our case (multiple [tt]/resources/descriptor.xml[/tt] files, each one in a plug-in)?

Regards,

Olivier Parisy.

Share this post


Link to post
Share on other sites

First, you have to check if the following pre-conditions are met for your plug-in jars:

1) Any jar may not belong to more than one EXE or DLL

2) Cyclic import between compilation sets is not allowed. For example, if A.jar uses B.jar and, at the same time, B.jar uses A.jar, they should be put into the same EXE or DLL.

So be ready that the model "one jar - one DLL" cannot be used if the jars have cyclic interdependencies.

So my questions are:

I. Are you sure that the plug-in jars meet the requirements? In particular, they should not have cyclic interdependencies with each other, and with the jars you place into EXE.

II. Is it really necessary to compile the plug-ins into DLLs? They could be handled by the JIT compiler that comes with the JET Runtime so that you compile into exe only the main jars.

Share this post


Link to post
Share on other sites

First, you have to check if the following pre-conditions are met for your plug-in jars:

1) Any jar may not belong to more than one EXE or DLL

2) Cyclic import between compilation sets is not allowed. For example, if A.jar uses B.jar and, at the same time, B.jar uses A.jar, they should be put into the same EXE or DLL.

So be ready that the model "one jar - one DLL" cannot be used if the jars have cyclic interdependencies.

OK, I understand those are the standard checks to be performed when using the JET compiler on multi-components applications.

So my questions are:

I. Are you sure that the plug-in jars meet the requirements? In particular, they should not have cyclic interdependencies with each other, and with the jars you place into EXE.

Our plug-ins are independant of each other, so cyclic dependencies are not to be expected. They may be dependant on some "core" classes compiled in the main EXE, though. Would that be the case, I suppose I could compile those "core" classes in a "core.dll" compilation set, on which my plug-ins and main EXE would be dependant, isn't it? Anyway, I understand this constrain and I am ready to track dependencies as needed to define my compilation sets properly.

II. Is it really necessary to compile the plug-ins into DLLs? They could be handled by the JIT compiler that comes with the JET Runtime so that you compile into exe only the main jars.

I am asked to provide intellectual property protection to our app; Excelior JET was explicitely chosen to enable such a native compilation of our "business" classes (I am very interested by your "stay tuned" post regarding JSR 277, btw  ;)). Monolithic compilation of our code in an EXE nicely fulfills this purpose, but limits extensibility, hence my question.

Regards,

Olivier Parisy.

Share this post


Link to post
Share on other sites
I am asked to provide intellectual property protection to our app

Ok I see, no words about JIT anymore.  B)

Anyway, I understand this constrain and I am ready to track dependencies as needed to define my compilation sets properly.

You may use the JET Control Panel to perform this check.

For details, see JET User's Guide, Chapter "Dynamic linking", section Multi-component applications \ Building multi-component applications ("STEP 1. Consistency check")

What's the version of Excelsior JET you are using now?

I am very interested by your "stay tuned" post regarding JSR 277

Do you need to protect an Eclipse RCP application?

Share this post


Link to post
Share on other sites

Ok I see, no words about JIT anymore.  B)

Thanks for your understanding  ;)

You may use the JET Control Panel to perform this check.

For details, see JET User's Guide, Chapter "Dynamic linking", section Multi-component applications \ Building multi-component applications ("STEP 1. Consistency check")

Great, thanks for the hint!

What's the version of Excelsior JET you are using now?

A JET 6.0 pro version.

Do you need to protect an Eclipse RCP application?

No, not for now. But knowing it can/will be done opens possibilities.

Regarding my initial query: you remembered me of the checks required to compile an application in multiple components. But would the getResources("/resources/descriptor.xml") mechanism I described work if each of my plug-in is compiled as a DLL (as I understand it, I suppose it would)?

On a more general note: could it be used as a "real" plug-in system, ie, offer extensibility "on-site" by just dropping new DLLs in an existing installation? What would then be the steps required so that the existing application could "see" the new plug-ins? Referencing the new DLLs in the CLASSPATH? Or some trick with JETVMPROP and the -dll option, perhaps?

Regards,

Olivier Parisy.

Share this post


Link to post
Share on other sites
But would the getResources("/resources/descriptor.xml") mechanism I described work if each of my plug-in is compiled as a DLL (as I understand it, I suppose it would)?

I remember that you asked it. ;)

As a registered customer of Excelsior JET 6.0, please contact Excelsior Support (java @ excelsior-usa.com) and our engineers will recommend you how to better organize such a plug-in system.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×