ClassLoading in plugin architecture

I'm developing a Java Desktop Application with a plugin architecture. I'd like to know of any good resources for information on how to use ClassLoaders to implement different schemes of plugin isolation and sharing.
Examples:
Sharing Each plugin depends on the application's public API jar, and classes loaded from here must be shared between the application and all plugins.
Isolation Plugin A may be built using version 0.2.4.1 of a third-party Xxx.jar while plugin B is built using version 1.0.0.2 of Xxx.jar, which is incompatible with the earlier version. The two plugins must be isolated from each other, so that each loads the classes from its own version of Xxx.jar.
There are probably many other issues that my plugin mechanism needs to take care of. The application is not supposed to support hot-swapping of plugins.
Any help and/or references will be highly appreciated.
Edited by: nygaard on May 29, 2009 10:30 AM

nygaard wrote:
Here are two more things, I'd like to support:
Plugin/application isolation Plugin A uses third-party Xxx.jar which in turn depends on version 1.2.3.4 of log4j.jar. The application itself uses version 0.1.2.3 of log4j.jar which is incompatible with 1.2.3.4.this is a little more complicated, but doable. basically, you will have to have some bootstrapping startup code for you application which only includes a few jars in the main application classloader (not including anything you want to be isolated). basically, you initial classpath should only have a bootstrap jar and any common interfaces (presumably you will have some plugin API). your bootstraping code should then load your main application in a new classloader (we'll call it the app classloader to distinguish) which has the main classloader as its parent. your plugins should be loaded with the parent classloader being the main classloader, not the app classloader.
Plugin/plugin sharing Plugin A may depend on plugin B and should be allowed to use classes found there.this makes things a little stickier. does A just need to use classes from B, or does it need to interact with B (two different things)? the former is easy (just sharing jar files). the latter is much more difficult, and may require some custom classloading implementation. Also, you will need some sort of discovery mechanism (way for A to "lookup" B within the application).
Edited by: jtahlborn on May 29, 2009 11:41 AM

Similar Messages

ClassLoaders in a plugin architecture

Hello everybody,
I'm developing an application which is to be launched via webstart (running in all-permissions mode) and has to implement a plugin architecture.
The structure I've come up with so far is this:
- every plugin is packaged in a different jar, which can be loaded/unloaded at runtime (this is a spec), thus not appearing in the jnlp.
- The core classes of the application (the "launcher") are sealed into a jar which is listed in the jnlp, and gets the all-permissions privilege.
- Among the core classes there's a Plugin abstract class which all plugins must extend in order to be launched by the application
- each plugin can declare dependencies, meaning that it can use other plugins classes, which are loaded before the plugin itself
Plugins are written by different developers, hence the need to define a Plugin class..
My problem is with classloaders: right now I'm using a custom classloader which extends URLClassLoader and adds the URL pointing to every plugin jar when it is loaded using URLClassLoader's addURL() method.
Everything seemed to work fine, but recently I got a java.lang.NoSuchMethodException when a plugin B tried to access the constructor of a plugin A class. The pluginA class extends one of my Plugin abstract classes and the constructor requires an Object as argument.
To give you an idea of what causes the Exception:
Plugin A class
public class PluginAObject2 extends Plugin {
public PluginAObject2(Object data) {
    super(data); // this calls one of my abstract classes
Plugin B class
String foo = "foo";
PluginAObject1 object1 = new PluginAObject1(PluginAObject1.A_STATIC_FIELD, foo);
PluginAObject2 object2 = new PluginAObject2(object1); // this causes the NoSuchMethodException
[...]My questions are:
- is the NoSuchMethodException thrown because of the super() call in PluginA constructor? My abstract classes are loaded by JNLPClassLoader, is it possible that classB's object1 is not recognized as a subclass of Object because java.lang.Object in JNLPClassLoader is not the same as java.lang.Object in my custom classloader?
- if so how can I correct the error?
- if not, can you give me a hint on what's wrong with this?
Please don't tell me that I have to change the whole approach to the problem, unless it is really the only way to go through this issue...
Thanks,
mb

Thanks jschell,
still I have some things I don't quite understand..
jschell wrote:
You can't do that. You have the following situation.
Class A loaded via classloader X
Class B loaded via classloader Y.
I always use the same custom classloader, having a static reference to it in my "core" classes, calling its addURL(plugin_jar_directory) method every time a plugin must be loaded before it is actually loaded. Something like
class PluginLoader {
static CustomClassLoader loader;
private loadPlugin(JarFile jar, String pluginName) {
    loader.addURL(jar);
    loader.loadClass(jar, pluginName);
}I have only 2 classloaders: the JNLPClassLoader and one instance of, say, CustomClassLoader. Which is classloader X and classloader Y in this case?
jschell wrote:
One of the following would be needed.
Class B and A loaded via classloader Z.
Class A loaded via classloader Z1 and a child of that loads classloader Z2 which loads class B. (Thus Z1 is a parent of Z2.)
Before using my custom class loader I used to create a new URLClassLoader for every plugin chaining them in a parent-child fashion. The resulting classloader chain looked something like
+ com.sun.jnlp.JNLPClassLoader
+ java.net.URLClassLoader plugin A
    + java.net.URLClassLoader plugin B
      + java.net.URLClassLoader plugin C   and so on, but I had to face the same issue.
One last thing I don't get: if A and B cannot see each other, why is java.lang.NoSuchMethodError thrown instead of java.lang.ClassNotFoundException in the first line of the two of plugin B I posted before?
Since I have to extract the manifest of the jar files to know which dependencies they declare and some other things (version, main-class and so on.. we use a custom manifest) could it be that classes inside the jar are loaded by the JNLPClassLoader, which is the classloader of my core classes? I just extract the manifest and do nothing on the classes, so it would sound weird to me but... I'm a bit lost
Thanks in advance,
regards
mb

To More Specific Class & Plugin Architecture

Hello there,
I have a plugin architecture and I want to load a particular class on demand, when a user clicks a button etc.
I can do this using 'Get LV Class Default Value.vi' knowing the path of the .lvclass file, and I can then use the 'To More Specific Class' vi to cast it from type LV Object to the specific class I know it to be.
However if I have 30 different classes with this method I would have to have 30 different class constants in a case structure so I can cast to the right one. This works but it means all the classes are loaded into memory when the program is run, even though the user may never want to use most of them, which is a waste of time/memory.
Is there a better way of doing this please?
Thanks,
Martin

I wonder if minute 4:00 in Michael's video will help you. It avoids the constants, as long as all the classes are descendants of a common class:
http://vishots.com/005-visv-labview-class-factory-pattern/

LabVIEW 2015 - Fast File Format and PlugIn Architecture

In LabVIEW 2015 the new "fast file format" was introduced:
"Improving Load Time for LabVIEW-Built Applications and Shared Libraries.
You can build stand-alone applications (EXE) and DLLs that load faster by using the fast file format in LabVIEW. <...> When you enable the fast file format, LabVIEW does not use the Application Builder object cache"
The question about PlugIn architecture, when lot of SubVIs called dynamically (for example, from external LLBs) from relative small core application. What I observed is - the size of the executable with this option was significantly reduced (roughly twice) and the core application itself starts faster, but PlugIns load time is the same regardless from this option (I understand why - when application fully loaded then Dynamic calls just "normal" LabVIEW code and therefore this option takes no effect). Unfortunately in code distribution build spec (as well as in packed libraries) this option is not available.
Is it possible to get "fast" application also for PlugIn-based architecture and get LLBs or packed libraries in "fast file format"? Can someone explain, what means "LabVIEW does not use the Application Builder object cache" and how this "fast load" mechanism technically working?
Thank you in advance,
Andrey.

Andrey_Dmitriev wrote:
In LabVIEW 2015 the new "fast file format" was introduced:
Is it possible to get "fast" application also for PlugIn-based architecture and get LLBs or packed libraries in "fast file format"? Can someone explain, what means "LabVIEW does not use the Application Builder object cache" and how this "fast load" mechanism technically working?
Thank you in advance,
Andrey.
Hey Andrey! It's good to see that you guys have been getting some good mileage out of this project. I'll go through your questions in order ...
1) These optimization are actually always enabled by default for packed project libraries. In fact, the load time benefits for packed libraries should generally be better than what you observe for .EXEs and .DLLs!
2) The app builder cache is something that is enabled for EXEs and DLLs that works to cache the results of previous compiles when the source has not been updated. It is somewhat analogous to the .obj object files generated by a C++ compiler.
3) I won't get into too many nitty gritty details but the gist of it is... LabVIEWs various non optimized file formats are treated somewhat similarly to the way that we treat 'loose' VIs. In a DLL/EXE/LVLibp we know at build time what the contents and dependencies of a given built binary are going to be. With this knowledge we can go ahead and construct something that is more similar to a statically linked PE or ELF file (clearly we're not using either of those) while the analogy is not 100% perfect it's the best I can do without going into a couple pages worth of description In addition to these basic file format changes we did a large amount of work on implementing a new loader which is able to take advantage of the large amounts of precomputed file data that is now included in the format which enabled us to cut a lot of corners that were there previously.

Plugin Architecture / Modular Design

I'm trying to find some more information on creating a plugin capable program architecture. I would like to learn how to design a program so that it can later be extended/enhanced by plugins/modules. I would like for a compiled version of my program to be able to access these plugins.
Has anyone completed a similar task with Java? Can anyone point me in the right direction to start learning more?
Thank you for your help!
DesQuite

To be more explicit, the typical method of creating a "plugin architecture" is to use a combination of interfaces and reflection. For example, if I want to allow developers to create a forum plugin that displays a special footer, I might create an interface that looks like this:
* A plugin interface. Developers should implement
* this interface, and register their class.
public interface ForumFooterWriter {
* Writes the footer contents to the stream.
public void writeFooter( PrintStream stream );
Then you provide a means for the developers to 'register' their plugin. This can be as simple as them editing a properties/xml file and creating an entry with their class name. For example,
--- Begin plugin.properties
footerPlugin=com.foo.MyFooterPlugin
--- End plugin.properties
Then, you can read the file, and instantiate the plugins. For example,
/** Your code.
void writeFooter( PrintStream out ) {
Properties p = new Properties();
p.load( "plugin.properties" );
String footerPlugin = p.getProperty( "footerPlugin" );
Class footerPluginClass = Class.forName( "footerPlugin" );
ForumFooterWriter ffw = ( ForumFooterWriter ) footerPluginClass.newInstance();
ffw.writeFooter( out );
Note, that if you want people to be able to change which plugins are registered, or just be able to re-compile a plugin and have the effect take place without restarting your app, you'll have to add some more complexity to the above (for example, using your own custom class loader), but this ought to be enough to get you started.
God bless,
-Toby Reyelts

Plugin architecture

hi everybody
first of all, sorry if I posted this topic in the wrong forum, but I haven't found a better one for this!
down to business: I need a good/easy/robust/stable/everything-else-we-look-for-in-a-good-software plugin architecture to develop an application... right now a commercial one, and in the future a free one.
I've found Java Plugin Framework (JPF)... it seems a very good solution, despite its short lifetime.
anyway, I need more alternatives, to make a choice that best matches my needs, you know...
does anybody can point out some other alternatives? I'll be very grateful!
thanks for your attention!

What type of "plugging in" do you envision/desire?hum... reading all the messages so far, maybe some people misunderstood what I meant to say...
I'm looking for a plugin framework which I can include into my application, in order to allow it to be extended by third-party plugins using my application's API (I'll get flamed by posting such description :P )
it's just like Eclipse, jEdit, Netbeans or Winamp that allow plugins extensions. maybe someone thought that I wanted to make my application as a plugin...
looking for it, I have only found JPF - http://jpf.sourceforge.net/ -, which fits exactly in this funcion... but anyway I want to evaluate other alternatives...
I think this time is clear ;)

Plugin architecture as exe in 7.1.

I'm planning an application with a plugin architecture, that will look up a directory during runtime for available plugins. I know I could do it using .llb Top-Level VIs. But I would prefere to have the plugins 'compiled', so as exe or dll. Is that a straight foreward build of those plugins or do we need to take care of some things? And how about compatibility when we use plugins of a newer LabVIEW version?
Felix
www.aescusoft.de
My latest community nugget on producer/consumer design
My current blog: A journey through uml

Perhaps using the Dynamically Loading and Calling VIs concept is the best for your application. If I remember correct the "specify path on diagram" options for calling DLLs, is not available in Labview 7.1. Anyway then calling Labview built DLLs the correct runtime engine version has to be installed. Since a DLL is compiled I guess you may use a Labview 8.x compiled DLL in 7.1.
Tip. If you are using VIs as plugins you may password protect your code. You may also rename them to a dll extension. No one will bother to look deeper into to this.
Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
(Sorry no Labview "brag list" so far)

Teststand 2012 plugin architecture

Hi all,
Any tutorials on teststand 2012 plugin architecture. I searched on net but could find only few white papers and video tutorial which gives you an overview.
Thanks

You have three options:
A. Make your plug-in a result processor, even if it doesn't process results. This allows it to be inserted and configured in the Result Processing Dialog Box.
B. Make your plug-in an Addon. See http://zone.ni.com/reference/en-XX/help/370052K-01/tsfundamentals/infotopics/pmpconfiguring/, Model Plug-in Add-ons and Addons.cfg section.
C. Create your own configuration file:
For option (C), you can create additional model plug-in configuration files in the following ways:
1. Call the DisplayModelPluginDialogEx function from ModelSupport2.dll as defined in ResultProcessing.h to display a dialog that creates and edits a configuration file.
Note that this dialog will be programmatically customizable in a future version of TestStand. Also, the complete source code is already provided.
2. Copy an existing configuration file to a new file name. Open the new file in a text editor. Replace any occurrence of the previous file name with the new file name. Thus, you could use the Result Processing Dialog Box to create a ResultProcessing.cfg file with your plug-in in it and then copy the file before removing your plug-in from the dialog.
3. Create a configuration file programmatically using the TestStand API. You create a Model Plug-in configuration file with an instance of the PropertyObjectFile class with a file type of FileType_PropertyObjectFile. The PropertyObjectFile.Data property of the file must be of type NI_ModelPluginConfigurationSet. Currently there is no example of this, but the source code in ResultProcessing.c performs similar actions.

Enterprise Manager 11g Sybase Plugin architecture question

Hi,
have successfully installed and configured Grid 11g on RedHat Enterprise 5.5. Deployed and configured agents to solaris and linux environments..so far so good.
However, we're going to test the Sybase ASE plugin to monitor ASE with EM. My question is a simple one and I think I know the answer but I'd like to see what you guys think of this.
We'd like to go with a simple centralised agent rather than one agent/plugin per sybase machine, atleast for the tests. No doubt there may be pro's (first one clearly being one of a single point of failure - welll we can live with this for now) to this approach. My instinct is to install the oracle agent/plugin on a machine other than the grid machines itself, however the question arose - why not install the ASE plugin on the grid infrastructure machine agents themselves? Pros and cons?
The architecture we have currently : repository database configured to failover between 2 redhat boxes. 2 OMS running 1 on each of these boxes configured behind SLB using nfs based shared upload directory. One 'physical agent' running on each box. Simple for now. But I have the feeling , given that the Sybase servers will communicate or be interrogated via the sybase plugin directly to the grid infrastructure machines placing load etc on them , and in case of problems might interfere with the healthy running of the grid. Or am I being over cautious?
John
Edited by: user1746618 on 12-Jan-2011 09:01

well I have followed the common sense approach and avoided the potential problem by installing on a remote server and configuring the plugin on this.
Seems to be working fine and keeps the install base clean..

ClassLoader for plugins

Hi there,
I have an application where I would like to instantiate plugin classes. Now, for reasons that would be a bit too lengthy to explain right now I want each of these plugins to have their own classloader (i think, see the rest). Basically I want them not to share statics and I want to be able to see which classes are being loaded from within the plugins (so I can reject the instantiation of certain classes from within plugins, etc.).
I've tried extending URLClassLoader but even if I explicitly call a loadClass on my classloader any classes instantiated from within the class I created with my classloader use the original application class loader.
Can anyone point me in the direction? So the two features I need are :
- Each plugin needs it's own statics and such
- I need to reject instantiation of certain classes, but only if this is attempted from within plugin code
Is this possible? And if so, what's the most elegant way to accomplish it.
Any help would be much appreciated.

When you set up a URLClassloader the default behaviour is that it delegates class requests to the parent classloader (generally the system classloader) and only when the parent classloader returns "not found" does it attempt to load the class itself.
So your URLCLassLoader will not, itself, load any class which is present on the class path. You must place the plugin in a separate jar and ensure that no class with the same FQN exists on the class path. Further when a class accesses a class through a reference it asks the classloader which loaded it (not necessarily that from which it was requested) so if a class load is delegated then any referenced classes will be requested from the classloader it was delegated to.

Modular Design / Plugin Architecture for JSF 2

Are there some documents on web application modular design? I would like to design a base line JSF 2 web application and extended its features by adding plugins or modules (e.g. Blog, Forum). Can anyone give me some directions or references on how to do this with JSF 2? Is there an open source Java web application using such architecture?

You can find the entire JSF 2.0 specification here [JSR 314: JavaServer Faces 2.0|http://www.jcp.org/en/jsr/detail?id=314] . The reference open source implementation is [Mojarra 2|https://javaserverfaces.dev.java.net/] .
There is a good blog to start [Whats New in JSF 2?|http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/#navigation]
If you want to do some cool looking application then follow up the new [ICEfaces-2.0.0|http://wiki.icefaces.org/display/ICE/ICEfaces+2+Overview]
The rest is just best practice and experience what you need. I found many good blog on Internet.

Aperture 2.1 is out today, with new open plugin architecture

See press below. Sounds really great.
08:30 28Mar08 PRN-Apple Releases Aperture 2.1 with Powerful Image Editing Plug-In Architecture
CUPERTINO, Calif., March 28 /PRNewswire-FirstCall/ -- Apple(R) today
released Aperture(TM) 2.1, which introduces an open plug-in architecture that
makes it easy for photographers to use specialized third party imaging
software right from within Aperture. Available today as a free software
update, Aperture 2.1 includes the Apple-developed plug-in, Dodge & Burn, which
adds brush-based tools for dodge (lighten), burn (darken), contrast,
saturation, sharpen and blur. Over the coming months, third party software
developers will deliver image editing plug-ins for localized editing, filters
and effects, noise analysis and reduction, fisheye lens correction and more.
"The image quality in Aperture 2 has won over the most demanding
photographers," said Rob Schoeben, Apple's vice president of Applications
Product Marketing. "Now, thanks to our open plug-in architecture, users can
access an entire industry's worth of imaging expertise without ever leaving
Aperture."
"To date, maybe two percent of my photographs needed to be touched up
outside Aperture," said John Stanmeyer, founding member of the VII Photo
Agency and contributing photographer for Time and National Geographic
magazines. "Now that I can dodge and burn right within Aperture's new plug-in,
I can't imagine when I'll have to open any other application to tone my
images."
By clicking on one or more images within Aperture, users can choose from a
menu of installed plug-ins and apply specialized imaging operations to either
TIFF or RAW images. Apple is working closely with key developers to bring the
most requested plug-ins to Aperture such as:
-- Nik Software's Viveza plug-in, powered by U Point technology, which
provides a powerful, precise and easy way for photographers to
selectively control and adjust color and light in their digital images;
-- PictureCode's Noise Ninja plug-in that delivers advanced high ISO noise
analysis and reduction;
-- Digital Film Tools' Power Stroke plug-in that features a simple,
stroke-based interface to quickly mask and intuitively perform targeted
adjustments;
-- The Tiffen Company's Dfx plug-in that provides an expansive suite of
creative filters and effects;
-- dvGarage's dpMatte plug-in, which is a high performance chroma key tool
for creating seamless composites, and the HDRtoner plug-in that enables
the selection of multiple photos to create a single high dynamic range
(HDR) image; and
-- Image Trends' plug-ins that include Fisheye-Hemi to quickly and
effortlessly correct fisheye lens distortion, ShineOff which
automatically removes shine from faces and PearlyWhites that
automatically whitens and brightens teeth.
Pricing & Availability
Aperture 2.1 is available immediately as a free software update to current
Aperture 2.0 users. Full system requirements and more information on Aperture
can be found at http://www.apple.com/aperture. Information and availability
for third party imaging plug-ins can be found on
http://www.apple.com/aperture/resources, http://www.apple.com/downloads and at
the Aperture community site http://www.aperturepluggedin.com.

more info on 2.1
+Aperture 2.1 updates various features of the application and addresses issues related to performance and overall stability. The updates include the following:+
+Dodge & Burn Plug-in. A sample plug-in is pre-installed, taking advantage of the Edit API introduced in Aperture 2.0. The plug-in adds brush-based tools for Dodge (Lighten), Burn (Darken), Contrast, Saturation, Sharpen and Blur.+
+Customize Default Adjustment Set. You can now specify which adjustments appear by default in the Adjustments Inspector/HUD.+
+Updated Crop Tool. A simplified UI makes it easier to preserve an image's original aspect ratio, match the aspect ratio of your display, or use one of the standard preset aspect ratios.+
+Sorting in All Projects View. A contextual menu allows you to sort the All Projects view in ascending or descending date order.+
+Show on Map. A contextual menu allows you to choose the Show on Map by right-clicking (or Control-clicking) on an image that contains GPS data.+
+Access to Toolbar on Second Display. When using multiple displays in Full Screen mode, the Full Screen toolbar is now accessible on a second display.+
+"Snapshots" book theme. This additional theme includes new "photo border" frames in which to place images.+
+Flip Images. You can now flip images horizontally or vertically within Aperture.+
+Vignette. The range of gamma and exposure settings available has been expanded.+
+Save Books as JPEG or TIFF images. Automator actions have been added to Save as PDF pop-up menu in the Print Book window to automatically generate JPEG or TIFF images from book pages.+
+Update EXIF from Master. This command allows Aperture to reread EXIF from a master images after they have been imported.+
+Extended AppleScript support. The "Reveal" verb in the AppleScript dictionary has been extended to include containers such as projects and albums.+
+The update includes fixes that impact the a number of areas, including:+
+Image import+
+Image migration+
+Erasing memory cards after import+
+Quick Preview+
+Batch Change+
Auto-stacking
+All Projects view+
Tooltips
+Smart Albums+
Tethering
+Adjustments inspector+
Viewer
Loupe
+White Balance+
Definition
+Lift & Stamp+
+Handling of externally edited images+
+Reconnecting referenced files+
+Keyboard customization+
+Deleting images+
+Metadata presets+
+Book themes+
+Borderless printing+
+Web Page/Web Journal export+
+Exporting versions+
+Export Plug-in support+
+AppleScript support+
+For further information about this update, see Late-Breaking News About Aperture 2, available at http://manuals.info.apple.com/en/Aperture2.0_lbnz.pdf+
+The Aperture 2.1 Update is recommended for all Aperture 2 users.+
they really listened to the users on this ... many of the requested, and oft griped about, features are now included ... keep 'em coming ...

Plugin Classloader and Web Start

Our application JAR currently contains a Class-Path: entry pointing to another JAR that contains plugins. Now since the user shall be able to use other plugins than that one we provided, we need to remove the Class-Path: entry from the application JAR and instead provide a facility that names the JARs to scan for plugins. In fact, this should be as easy as providing a external properties file read by a Plugin Classloader.
Now the problem is that we like to deploy our application and the plugins using JNLP. So we think the planned solution is incompatible with JNLP due to two reasons: (a) It would require to access a properties file, (b) it would require that the JARs not beeing renamed (as Web Start does it).
So what can be a possible solution?
Are we the only ones that use plugin architectures together with JNLP?

You might want to take a look at the Java Plug-in Framework (http://jpf.sourceforge.net/).

VI name collision using plugin type architecture

I am using LabVIEW 8 and am building an application that will use a "plugin" architecture. There will be a main program built into an executable that calls sub vi's that are in llb's. Some vi's in the llb's will call DAQmx functions, others will do calculations, etc. Some math functions will be done in the main program too.
The problem I am trying to address is how to deal with vi.lib vi's that are used in the plugin llb vi's and the main program. For example, I use Mean.vi in one of the plugin vi's as well as in the main program. Where should Mean.vi be stored? A name collision occurs if it is in more than one location (i.e. in a plugin llb and the main program executable). This can get very complicated if many vi.lib vi's are used in the plugin llb's and the main program executable. How can I distribute vi.lib vi's that are required for my application to run? The application builder is fine for simple distributions but breaking up the application into several modules (llb's) that have functions (vi's) like a dll has some great advantages.
As side issue, does anyone know of a way to assign a version number of a llb file that is visible from its properties window in Windows?

TLE wrote:
I am using LabVIEW 8 and am building an application that will use a "plugin" architecture. There will be a main program built into an executable that calls sub vi's that are in llb's. Some vi's in the llb's will call DAQmx functions, others will do calculations, etc. Some math functions will be done in the main program too.
The problem I am trying to address is how to deal with vi.lib vi's that are used in the plugin llb vi's and the main program. For example, I use Mean.vi in one of the plugin vi's as well as in the main program. Where should Mean.vi be stored? A name collision occurs if it is in more than one location (i.e. in a plugin llb and the main program executable). This can get very complicated if many vi.lib vi's are used in the plugin llb's and the main program executable. How can I distribute vi.lib vi's that are required for my application to run? The application builder is fine for simple distributions but breaking up the application into several modules (llb's) that have functions (vi's) like a dll has some great advantages.
As side issue, does anyone know of a way to assign a version number of a llb file that is visible from its properties window in Windows?
I also use the plugin approach where a compiled .exe plugs in VIs which share vi.lib VIs with the main.exe. I did not yet use LV 8 for this, bit LV 7.0.
In principle there is no problem: the main.exe loads into memory first and with it the vi.lib VIs it contains (say e.g. mean.vi). When a plugin using mean.vi is loaded, it uses the instance of mean.vi which is in memory, i.e. the one which is stored in then main.exe (typically with its front panel and block diagram removed).
The problem starts when the plugin is closed, since the it asks if it should be saved to disk because the path to its subVI 'mean.vi' has changed. This is at least annoying. A workaround is to rename all VIs from vi.lib (and user.lib, instr.lib maybe) and save them to a different location before the .exe is built. That way all namespace collisions are avoided. I wrote a tool to do this renaming automatically. AFAIK there is a better (=more professional) tool for this purpose: the OpenG Builder, see at http://www.openg.org/index.php?option=com_content&task=category&sectionid=4&id=68&Itemid=47. I haven't used it, though.
OTH: My understanding was that all these namespace problems have been resolved with LV 8 since its new application builder supported such autoimatic renamings. From your post I understand the problem is still there in LV8!? So one more reason not to upgrade yet. Maybe others can confirm.

AIR Plug-In Architecture For HTML/AJAX Development?

Hi everyone,
Doing an AIR project. Mentor suggested to do app with plug-in capability, "Great idea! i'll get sraight on it!!" but now..... not so good :'(
I would have a pretty strong background in programming for a student and would hate to srink to the challange but I can't find any documentatin on building a plug-in architecture for AIR? I have developed many apps during my studies but never one with any sort of plugin architecture.
Without any more background into my problem my question is..... does anyone know of any good documentation for me to follow or that i could look through and would set me on the right track in order to create this? Or could you explain briefly how you would go about creating this type of application?
Thank you so much for any help that anyone can give to me in advance, hope you all having a good day,
IrishAIRMax

?

ClassLoading in plugin architecture

Similar Messages

Maybe you are looking for