Distributing and registering to a custom location

Question

My VB application uses an axbridge bean dll and I want to register it on a client's machine.
(Call it MyBean.dll and its associated jar MyBean.jar)
As I understand it, it has to be registered this way...
1. create a directory called "axbridge" under the Java Runtime Environment installation directory (if not already)
2. copy MyBean.dll to there
3. run regsvr32 to register it (which puts MyBean.jar into the "lib" directory)
I understand it uses axbridge.dll which is in JRE\bin, so the total directory structure is this...
\JRE
    \axbridge
        \bin
            MyBean.dll
        \lib
            MyBean.jar
    \bin
        axbridge.dllMy question is this... does all of this need to be under the JRE directory?
Could I put the axbridge and bin directories somewhere else (the bin directory containing axbridge.dll) and register from there?
I ask this because when JRE installs it defaults to a directory named (eg.) JRE1.4.2_05 (or something like that). But what happens when the client uninstalls JRE1.4.2 and installs JRE1.5.0 (for example)? Do my dll/jar files remain and still work OK? And even if they do, it would be 'safer' if my files were under my application's installation directory, in case the client sees these files in the middle of nowhere (in a long-since-removed JRE location) and deletes them.
Lastly, if it does work in a custom location, am I allowed to do that? Specifically, am I allowed to distribute axbridge.dll myself, so my installation program knows where to find it?
Any comments would be great. Thanks.

Answer 1

You are in luck as I have been actively dissecting the ActiveX Bridge for a project I am working on.
I'll talk about this high-level to begin with. Using the packager tool to create the DLL, the answer is "Yes." The JavaBean ActiveX DLL has to be in the <jre>\axbridge\bin directory. The way the packager creates the DLL, it will only register itself if it resides in the <jre>\axbridge\bin directory. I guess you didn't try it, but moving the DLL somewhere else and running regsvr32 will fail with 0x80004005 Unspecified Error
To answer your other question if the client uninstalls one JRE and installs a new version, your ActiveX JavaBean will break. First because the uninstaller might remove the axbridge directory (not sure about this behavior). Secondly, because it will definitely remove the axbridge.dll in the <jre>\bin directory. The axbridge.dll is required for any ActiveX JavaBean.
Which brings me to the more detailed description of what is going on. The DLL created by the packager turns out only to hold only the TypeLib and the COM register / unregister methods (DllRegisterServer and DllUnregisterServer) that are invoked by regsvr32. When regsvr32 is ran it calls DllRegisterServer, which contains the code to actually register the object. This is implemented specifically for any given COM object usually by the COM object. If you take a look at these entries in the registry (or use oleview.exe) you will see that the actual COM InProcServer32 is axbridge.dll not the DLL created by the packager tool.
So to reiterate, the DLL created by packager is not the actual COM object used. It just contains the registration code used by regsvr32 and the type library.
Knowing how the system work one can attempt to change it. There are a few alternatives. One solution is to write your own DLL exporting DllRegisterServer and DllUnregisterServer and implement your own registration. You will have to look at what the DLL created by the packager does so you can include specific entries. This way you can control exactly where the DLL resides, where the axbridge.dll resides and a myriad of other COM related things.
Another solution would be to create and register the DLL created by the packager and follow up afterwards and change entries. Below are the most relevant entries. Your GUID will be something different of course. I specified {E9327EFF-770C-49A3-B38D-7E419A8EDFD1} when I ran packager.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{E9327EFF-770C-49A3-B38D-7E419A8EDFD1}\InprocServer32
@="C:\\PROGRA~1\\Java\\J2RE14~1.2_0\\bin\\axbridge.dll"
"ThreadingModel"="Apartment"As you can see the axbridge.dll is what is actually used for the COM server.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{E9327EFF-770C-49A3-B38D-7E419A8EDFD1}\JarFileName
@="C:\\PROGRA~1\\Java\\J2RE14~1.2_0\\axbridge\\lib\\AXBridgeBeanTest.jar"This entry tells the axbridge.dll where to find the jar file.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{E9327EFF-770C-49A3-B38D-7E419A8EDFD1}\JavaClass
@="com.advoxis.bean.AXBridgeBeanTest"This entry tells the axbridge.dll what the name of your bean is.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{E9327EFF-770C-49A3-B38D-7E419A8EDFD1}\TypeLib
@="{E9327F00-770C-49A3-B38D-7E419A8EDFD1}"All this is is the key for the typlib. Follow this to change where the DLL that the packager created resides
HKEY_CLASSES_ROOT\TypeLib\{E9327F00-770C-49A3-B38D-7E419A8EDFD1}\1.0\0\win32
@="C:\\PROGRA~1\\Java\\J2RE14~1.2_0\\axbridge\\bin\\AXBRID~1.DLL"This is the location of the DLL created by the packager that resides in the <jre>/axbridge/bin directory. Update this if the DLL needs to be in a different location.
Probably way more than you wanted to know but I wanted to put some documentation out there for the community. For some reason the ActiveX Bridge is poorly documented compared to other Java technologies. Most documents I found where ancient. I don't know why this technology is so neglected as it is actually quite cool once I figured out how it was really working and how I could exploit it.
NOTE TO SUN: I'm really disappointed the packager tool hides EVERYTHING about creating the supposed "ActiveX Control" for the bean. The packager creates an IDL file in the temp directory and deletes it. Why not keep that file around as a generated file that more advanced developers could modify and use? In fact, why not generate C++ code for the implemented DllRegisterServer and DllUnregisterServer? Still better yet, document how the axbridge.dll really works and all the specific registry settings (e.g. JarFileName, JavaClass)
/SOAPBOX
Anyhow, I hope this was useful to you gazzadev.
-Nick