Hi Henrique
I notice that in the app startup script WOFrameworksBaseURL is added
after command line arguments. For example,
eval exec ${JAVA_EXECUTABLE} ${JAVA_EXECUTABLE_ARGS} -classpath
WOBootstrap.jar com.webobjects._bootstrap.WOBootstrap $
{COMMAND_LINE_ARGS} -WOFrameworksBaseURL /WebObjects/
sf_advstand_200905011505.woa/Frameworks
That means it can't be overridden by JavaMonitor which I agree with
you is a problem. I just tested this to be sure and was unable to
override with JavaMonitor. I would be happy for -WOFrameworksBaseURL
to be moved in front of ${COMMAND_LINE_ARGS}. It would still override
Properties files. I am not sure how many people, apart from yourself,
set WOFrameworksBaseURL in a Properties file.
Regards
Tim
On 14/05/2009, at 2:39 AM, Henrique Prange wrote:
> Hi Chuck, Lachlan and Tim,
>
> 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. 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.
>
> This is very similar to our approach. The Maven build generates
> artifacts with the version attached to the name (i.e.
> MyApp-1.0.woa). We have different versions of the same application
> running in the same instance of JavaMonitor occasionally.
>
> In this circumstance, the generated URLs for web resources are
> inconsistent without a properly WOFrameworkBaseURL configuration. I
> solved the problem using Maven filters. I've added the following
> entry to the application's Properties file.
>
> WOFrameworkBaseURL = /WebObjects/${project.build.finalName}.woa/
> Contents/Frameworks
For WebServerResources,, the ant builds have moved Frameworks up a
folder so they are no longer in Contents.
>
>
> Maven replaces the ${project.build.finalName} variable for the
> correct name of the artifact during the build. It works, but I have
> to remember to add this information to every project (and every
> Maven user will). IMHO, the startup script generated by Maven builds
> should do that automatically. Otherwise it is producing an artifact
> that would probably be broken in deployment.
>
> On the other hand, it is a bad idea to add the launch argument if it
> drops the flexibility of configuration on JavaMonitor and Properties
> files for people that use different approach as Lachlan reported.
>
> So, the question remains: should this launch argument be added in
> the startup script of generated applications? I'm +1 for it if this
> change doesn't break everyone else's build.
>
> BTW, this modification also affects Ant builds. But I think it also
> make sense for Ant generated artifacts.
>
> Cheers,
>
> Henrique
This archive was generated by hypermail 2.0.0 : Wed May 13 2009 - 18:00:14 EDT