Re: woproject-ant-tasks appstart script doubt

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Mon May 11 2009 - 01:03:32 EDT

  • Next message: Jonathan 'Wolf' Rentzsch (JIRA): "[OS-JIRA] Created: (WOL-1015) NPE in FrameworkSet"

    Hey there,

    On 09/05/2009, at 5:57 PM, D Tim Cummings wrote:

    > Hi Lachlan,
    >
    > I find it really useful to have the WOFrameworksBaseURL set in the
    > application start up file. I have modified the following two lines
    > in my build.xml so the app name contains a date and time stamp
    >
    > <property name="build.app.name" value="${project.name}${DSTAMP}$
    > {TSTAMP}" />
    > <property name="build.app.name.lowercase" value="$
    > {project.name.lowercase}${DSTAMP}${TSTAMP}" />
    >
    > Then when I deploy, I can install the new version of the app
    > alongside the old version.

    Sure.

    > In JavaMonitor I only have to change the "Path" to the new version
    > of the app and be confident that it will pick up the new
    > WebServerResources that were installed at the same time without
    > having to set the new WOFrameworksBaseURL in the "Additional
    > Arguments". Rolling back to a previous version of the app is
    > similarly easy.
    >
    > I was sure that JavaMonitor setting of WOFrameworksBaseURL would
    > override the application start up script if I had wanted to.
    > However, it is so long since I used to do it that way that I have
    > forgotten if I ever tried it.

    I'll have to test again to confirm but I remember having to implement
    a work around when this turned up (which works quite well for us now)
    - as we have our own scheme for versioned webserver resources and the
    WOFrameworksBaseURL wasn't honouring our setting. Perhaps, though,
    this was the WO5.4 bug that bit us. Can't remember.

    Doing the below always ensures that at runtime your frameworks baseURL
    is correct. No properties to update :-)
    i.e., it uses the app name on disk etc

    so in app.finishInitialization()
    {
            <...>
            // fix frameworks/app webserver resources url.
            if
    ( ERXProperties
    .booleanForKeyWithDefault
    ( "ISHFrameworksBaseURL.relativeToApplicationBaseURL", true ) )
            {
                    String realAppName = NSPathUtilities.lastPathComponent( path() );
                    NSArray< String > components = new NSArray< String >( new String[] {
                        realAppName, "Contents", "Frameworks"
                    } );
                    String newBaseURL = applicationBaseURL();
                    for ( Enumeration< String > en = components.objectEnumerator();
    en.hasMoreElements(); )
                    {
                            newBaseURL =
    NSPathUtilities.stringByAppendingPathComponent( newBaseURL,
    en.nextElement() );
                    }
                    ERXProperties.setStringForKey( newBaseURL, "WOFrameworksBaseURL" );
                    setFrameworksBaseURL( newBaseURL );
            }
            LOG.info( "WOFrameworksBaseURL:" + frameworksBaseURL() );
            <...>
    }

    > On 08/05/2009, at 11:08 AM, Lachlan Deck wrote:
    >
    >> On 08/05/2009, at 9:56 AM, Henrique Prange wrote:
    >>
    >>> I've found something that left me in doubt while investigating
    >>> some problems related with the WOFrameworksBaseURL property. The
    >>> woproject-ant-tasks module has two templates for the application
    >>> start-up file.
    >>>
    >>> src/resources/woapp/Contents/MacOS/appstart:
    >>>
    >>> [...]
    >>> echo ${JAVA_EXECUTABLE} ... ${COMMAND_LINE_ARGS}..
    >>> WOFrameworksBaseURL@
    >>> eval exec ${JAVA_EXECUTABLE} ... ${COMMAND_LINE_ARGS}..
    >>> WOFrameworksBaseURL@
    >>>
    >>> src/resources/woapp_52/Contents/MacOS/appstart:
    >>>
    >>> [...]
    >>> echo ${JAVA_EXECUTABLE} ... ${COMMAND_LINE_ARGS}
    >>> eval exec ${JAVA_EXECUTABLE} ... ${COMMAND_LINE_ARGS}
    >>>
    >>> The former has a "variable"..WOFrameworksBaseURL@ that is
    >>> replaced by the correct value in build time (if WO not 5.2 or
    >>> greater). The latter doesn't have this variable and the final
    >>> artifact generated doesn't have any reference to the
    >>> WOFrameworksBaseURL property.
    >>>
    >>> Is this a mistake or there is a reason to not add the
    >>> WOFrameworksBaseURL property in the application's launch script
    >>> for WO 5.2 or greater?
    >>
    >> It shouldn't be there and doesn't need to be there. It overrides
    >> anything defined in Java Monitor or the app properties.
    >>
    >> I've had to work around this (what I'd call a bug) by adjusting the
    >> baseurl during app launch to be what I wanted it to be...
    >>
    >> I'm not sure why it was added in. Perhaps there's a commit message
    >> that has an explanation. I'm willing to be convinced otherwise but
    >> I think it was a bad move. :-)

    with regards,

    --
    

    Lachlan Deck



    This archive was generated by hypermail 2.0.0 : Mon May 11 2009 - 01:04:58 EDT