On 14/05/2009, at 7:59 AM, D Tim Cummings wrote:
> 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.
Thanks for doing that - I've been a little swamped with some deadlines
so haven't read my mail for a few days.
> 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.
That sounds good.
> 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
>
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Fri May 15 2009 - 17:11:33 EDT