The problem is that we have a need to deploy the same application in 2
different ways (resulting in the need for a runtime value set in
WOFrameworksBaseURL. I was hoping to do it with a property or a arg in
monitor. If the ant task just swapped the position of it's args and
${COMMAND_LINE_ARGS} it would all work (in theory). :)
-Lon
On Wed, Aug 7, 2013 at 1:17 PM, Hugi Thordarson <[email protected]> wrote:
> You can fix this by changing the frameworksBaseURL attribute in your
> build.xml. It's been wrong for quite a while.
>
> - hugi
>
>
> On 7.8.2013, at 20:04, Lon Varscsak <[email protected]> wrote:
>
> > Okay, I've figured out the source of my problem…and, after looking at
> many lines of decompiled code…I realized it's not a bug in code. :P
> >
> > It seems (and I don't know if this is unique to our setup) that when the
> application is packaged the script that it generates uses the command line
> args (which get passed in from Monitor) and THEN adds it's own version of
> -WOFrameworksBaseURL, which ends up negating the one I've been trying to
> force in.
> >
> > I'm not sure where to look on how to overcome this.
> >
> > -Lon
> >
> >
> > On Wed, Aug 7, 2013 at 11:06 AM, Lon Varscsak <[email protected]>
> wrote:
> > I have some code similar to this (actually so does ERXApplication's
> constructor), but even after trying your code...for resources in frameworks
> it still ignores this value. I may be missing something.
> >
> > -Lon
> >
> >
> > On Tue, Aug 6, 2013 at 6:53 PM, Aaron Rosenzweig <[email protected]>
> wrote:
> > Hi Lon,
> >
> > It's a bug in WO 5.4.3 that was not there in WO 5.3.3 but there are ways
> to deal with it.
> >
> > In your Application.java try adding these lines:
> >
> > @Override
> > public void setFrameworksBaseURL(String string) {
> > // To workaround a WO 5.4 bug we need to take over and
> forcibly set the frameworks base URL
> > String defaultURL =
> "/WebObjects/yourAppName.woa/Contents/Frameworks";
> > String sysPropsURL =
> NSProperties.getProperty("WOFrameworksBaseURL");
> > String finalURL = defaultURL;
> > if (StringUtils.isNotBlank(sysPropsURL)) {
> > finalURL = sysPropsURL;
> > }
> >
> > super.setFrameworksBaseURL(finalURL);
> > }
> >
> > @Override
> > public void setApplicationBaseURL(String aString) {
> > // To workaround a WO 5.4 bug we need to take over and
> forcibly set the application base URL
> > String defaultURL = "/WebObjects";
> > String sysPropsURL =
> NSProperties.getProperty("WOApplicationBaseURL");
> > String finalURL = defaultURL;
> > if (StringUtils.isNotBlank(sysPropsURL)) {
> > finalURL = sysPropsURL;
> > }
> >
> > super.setApplicationBaseURL(finalURL);
> > }
> >
> > Cheers,
> > -- Aaron
> >
> >
> > On Tue, Aug 6, 2013 at 9:15 PM, Lon Varscsak <[email protected]>
> wrote:
> > I'm not sure where to turn here, but it appears there's a bug with the
> way WOnder/WO (which one, I'm not sure…probably WO) handles
> WOFrameworksBaseURL.
> >
> > It appears that the resource manager is never returning the right (based
> on WOFrameworksBaseURL) url for resources located inside of frameworks. It
> only generates urls that look like /WebObjects/<app directory
> name>/Frameworks. It's not even using the app's name (which in my case is
> different than the app's directory name)..
> >
> > Has anyone ever encountered this? Any ways around it?
> >
> > -Lon
> >
> > _______________________________________________
> > Do not post admin requests to the list. They will be ignored.
> > Webobjects-dev mailing list ([email protected])
> > Help/Unsubscribe/Update your Subscription:
> >
> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com
> >
> > This email sent to [email protected]
> >
> >
> >
> > _______________________________________________
> > Do not post admin requests to the list. They will be ignored.
> > Webobjects-dev mailing list ([email protected])
> > Help/Unsubscribe/Update your Subscription:
> >
> https://lists.apple.com/mailman/options/webobjects-dev/hugi%40karlmenn.is
> >
> > This email sent to [email protected]
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
