Skip to main content
P
pzorrilla1-Visitor
1-Visitor
September 19, 2013
Question

About the JVM and how to modify it (Arbortext Editor)

  • September 19, 2013
  • 15 replies
  • 3586 views

Hello experts!

Ok, so I've been playing with the jvm and I would like to know the
flexibility provided by Arbortext in order to modify or not use the
jvm.dll provided by default in the installation folder. Until now I have
the idea that by first instance Arbortext Editor will always use the one
provided by default, is that correct? Do you know how many ways do I
have in order to personalize my jdk version according to my Arbortext
Editor? Is that possible? and also I would like to know, is that
recommended? In my case I have the Arbortext 6.0 32-bit and in my
computer I just installed the 32-bit Java7.

Thank you soo much for your time and suggestions/responses. Have a
wonderful day! 🙂



P.D. (I would like to know also if it's possible to know if my Arbortext Editor is using a 32-bit or a 64 version. Do you know any command to get this information using ACL?)

Paulette Zorrilla

    15 replies

    C
    ClayHelberg18-Opal
    18-Opal
    September 19, 2013
    Hi Paulette--

    Probably the easiest way to select an alternate Java VM is to use the set JAVAVMPATH option in your init.acl file. You can read the details in the Arbortext Help Center, just search for "set javavmpath" and you'll find the info.

    Note that they give a generic warning about not supporting other versions apart from the one that ships with Arbortext. So, theoretically you could run into problems. However, if you are going to a later Java version, I wouldn't expect too much trouble. You are more likely to have problems if you are trying to stick with an older version than Arbortext wants, or to switch vendors (say to use Microsoft's JVM instead of Oracle's)

    --Clay
    B
    berard1-Visitor
    1-Visitor
    September 20, 2013
    We currently are stuck using java1.5 with Arbortext 6 due to some
    third-party integrations that still use the old httpconnection methods.
    That said, JAVAVMPATH has worked fine for us, without ever giving a warning.

    Now, the issue we started to run into was when we began to upgrade users
    from 32-bit to 64-bit machines. This caused our default JVM path to be in
    either "Program Files" or "Program Files (x86)". Until now, I've been
    dealing with it on a per-machine basis, in the hopes that we'd be able to
    get away from our 3rd party dependencies. As that is looking like a
    long-shot, my plan was to set our custom deployment to look at a common
    path (eg: c:\jvm\jvm.dll), with a separate, one-time installer.

    My question is do you know if there's a way to include the desired JVM.dll
    in our deployment package (custom.zip), but also have the JAVAVMPATH know
    where to look for it? Custom gets installed in
    C:\Users\<username>\AppData\Local\PTC\Arbortext\Editor\.aptcache\zc\1 or
    2... so it's been a tricky one for us to reference.

    No biggie if we can't, pretty easy to put that default dir c:\jvm or
    whatever, but figured it didn't hurt to ask.

    Keith Berard, MCG


    C
    ClayHelberg18-Opal
    18-Opal
    September 20, 2013
    Hi Keith--

    You might be able to do this with something along these lines:


    1) Put your Java VM files in a subdirectory of $CUSTOM/lib

    2) In your init.acl file, include something like this:

    $vmpath = get_custom_dir() . "\\lib\\jvm\\jvm.dll"
    set javavmpath=$vmpath

    The get_custom_dir() function knows all about zipped customizations, so it will point to the copy in {user appdata}.../aptcache/zc/... if that's what you're using.

    --Clay
    B
    berard1-Visitor
    1-Visitor
    September 20, 2013
    Awesome, I'll give that a shot.

    I try to stay away from acl wherever possible these days, so I'm not
    exactly up on the available functions.

    I'll let you know how it goes.

    - keith


    J
    JeffStevenson1-Visitor
    1-Visitor
    September 21, 2013

    Just a note that Arbortext 6.1 supports Java 7.


    Regarding testing whether the version is 64-bit, there isn't an environment variable that explicitly denotes this. However, if you've installed Arbortext into the default location (Program Files vs. Program Files (x86)), you could extrapolate the version based on the installation directory. The variable to try would be$aptpath (or $aptbinarypath to get the full path to the exe).


    -Jeff

    B
    berard1-Visitor
    1-Visitor
    September 23, 2013
    Finally getting around to trying this...

    get_custom_dir() is not returning the correct path it seems, but I know
    it's loading the right file, since the error message states:

    [A18115] Error in initializationfile:
    c:\Users\BerarK\AppData\Local\PTC\Arbortext\Editor\.aptcache\zc\1\custom\init\astinit.acl,
    [A11683] Cannot access the Java Virtual Machine library "C:\Program Files
    (x86)\PTC\Arbortext Editor\custom\lib\jvm.dll".

    Any thoughts?
    - keith


    E
    ebenton1-Visitor
    1-Visitor
    September 23, 2013
    Could it be something as simple as the spaces in "Program Files (x86)"?
    B
    berard1-Visitor
    1-Visitor
    September 23, 2013
    It's actually getting the correct directory I'm talking about.

    We deploy patches using a custom.zip file on startup, so I'm looking to
    find the current custom dir, not the custom dir that's part of the program
    files path, since that really doesn't help with me being able to deploy the
    jvm.dll as part of the patch.

    eg: c:\Users\BerarK\AppData\Local\PTC\Arbortext\Editor\.
    aptcache\zc\1\custom


    C
    ClayHelberg18-Opal
    18-Opal
    September 23, 2013
    Keith--

    If you fire up Arbortext and type the command below in the command window, what do you get back?

    eval get_custom_dir() output=>*

    If you have your customizations configured as an application (with an application.xml file), they you might need to specify the application name as a parameter to get_custom_dir(). For example, in the stock Arbortext application, get_custom_dir() with no parameter returns my regular $APTCUSTOM location. But if I ask for get_custom_dir('com.arbortext.dita') I get the location of the DITA application in the install directory.

    --Clay
    B
    berard1-Visitor
    1-Visitor
    September 24, 2013
    Yeah, it's weird. When I run that from the cmd line, I still get:

    C:\Program Files (x86)\PTC\Arbortext Editor\custom

    The way I'm running the custom is to use the create_installer.exe to make a
    custom installer that points to a custom location on a web server. Then,
    at startup, Arbortext automatically looks at the siteprefs.xml on the
    server, and downloads the newest patch (custom.zip) if available.

    Ultimately, this installer sets the custom.zip URL location in: c:\Program
    Files (x86)\PTC\Arbortext Editor\lib\deploy.xml, and looks like this:
    <deploy resource="&lt;a" style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="http://servername.domain.com/deploylocation"></deploy>">http://servername.domain.com/deploylocation"></deploy>

    Now, per my previous email, I know it's looking in the right place, since
    the acl fails first by showing me the location in
    c:\users\<username>\appdata\local\ptc\arbortext\editor\.aptcache\zc\1.
    Maybe instead of get_custom_dir(), is there an acl method to get the
    current dir? That is, the dir that the acl file is in? That way, since
    it's in the correct custom\init, I could look for current_dir() + "\..\lib"
    or whatever?

    I still think you have a good idea simply setting this in the instance.acl,
    but I'm going to look more into the deploy_guide.pdf as well, since I now
    notice there's a <libraryfiles> tag that may be of some use.

    - keith



    Show more replies
    Terms & ConditionsAccessibility statement