Discussion:
Weird case of "The requested application was not found on this server"
Ondřej Čada
2012-02-09 06:48:50 UTC
Permalink
Hello there,

looks like I've licked most of the Eclipse/WONDER/Groovy problems by now (but for WOGroovy, that one's still in queue), and I've bumped into one weird problem.

When I run my built application manually from Terminal, like "./Test.woa/Test -WOPort 56000", then the "http://localhost/cgi-bin/WebObjects/Test.woa/-56000" URL does not work -- consistently yields "The requested application was not found on this server".

Direct connect (http://localhost:56000) works all right (assumed I use -WODirectConnectEnabled of course).

If I set up the very same application in JavaMonitor and access through "http://localhost/cgi-bin/WebObjects/Test.woa", it _again_ works all right!

Finally, to make it couriouser and couriouser, when I run manually from the Terminal an _older_ application, a pre-5.4.3, Xcode-built one, the "...Another.woa/-56000" URL _does_ work all right :-O

So, the only case which does not work is a newly ant-built one manually run and accessed through ...woa/-port.

Since both direct connect and installed version work all right, it is not a pressing problem; nevertheless I wonder what might be the culprit and whether it might indicate some hidden problem which may later raise it ugly head to bit me in my tender parts?

Thanks for any insight,
---
Ondra Čada
OCSoftware: ***@ocs.cz http://www.ocs.cz
private ***@ocs.cz http://www.ocs.cz/oc
Chuck Hill
2012-02-09 18:30:34 UTC
Permalink
Post by Ondřej Čada
Hello there,
looks like I've licked most of the Eclipse/WONDER/Groovy problems by now (but for WOGroovy, that one's still in queue), and I've bumped into one weird problem.
When I run my built application manually from Terminal, like "./Test.woa/Test -WOPort 56000", then the "http://localhost/cgi-bin/WebObjects/Test.woa/-56000" URL does not work -- consistently yields "The requested application was not found on this server".
Direct connect (http://localhost:56000) works all right (assumed I use -WODirectConnectEnabled of course).
If I set up the very same application in JavaMonitor and access through "http://localhost/cgi-bin/WebObjects/Test.woa", it _again_ works all right!
Check and see what other parameters JavaMonitor is adding to the command line. Maybe a default was changed and needs to be set? Or the older application has something different in its Properties?


Chuck
Post by Ondřej Čada
Finally, to make it couriouser and couriouser, when I run manually from the Terminal an _older_ application, a pre-5.4.3, Xcode-built one, the "...Another.woa/-56000" URL _does_ work all right :-O
So, the only case which does not work is a newly ant-built one manually run and accessed through ...woa/-port.
Since both direct connect and installed version work all right, it is not a pressing problem; nevertheless I wonder what might be the culprit and whether it might indicate some hidden problem which may later raise it ugly head to bit me in my tender parts?
Thanks for any insight,
---
Ondra Čada
_______________________________________________
WebObjects-dev mailing list
http://www.omnigroup.com/mailman/listinfo/webobjects-dev
--
Chuck Hill Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/gvc/practical_webobjects
Ondřej Čada
2012-02-16 02:15:45 UTC
Permalink
Chuck,
Post by Chuck Hill
Post by Ondřej Čada
When I run my built application manually from Terminal, like "./Test.woa/Test -WOPort 56000", then the "http://localhost/cgi-bin/WebObjects/Test.woa/-56000" URL does not work -- consistently yields "The requested application was not found on this server".
Direct connect (http://localhost:56000) works all right (assumed I use -WODirectConnectEnabled of course).
If I set up the very same application in JavaMonitor and access through "http://localhost/cgi-bin/WebObjects/Test.woa", it _again_ works all right!
Check and see what other parameters JavaMonitor is adding to the command line. Maybe a default was changed and needs to be set? Or the older application has something different in its Properties?
Actually, I've found the culprit, but it does not elucidate the problem the slightest bit: when my app runs under JavaMonitor, anything like "http://localhost/cgi-bin/WebObjects/Foo.woa/-1" or "...Foo.woa/-123456789" or "...Foo.woa/-whattheheck" runs just as well, using in fact the JavaM-controlled instance.

In other words, it seems that the "http://localhost/cgi-bin/WebObjects/Foo.woa/-portnumber" URL completely ignores the -portnumber part and always works exactly as if it was not there. Did I perhaps miss anything and this kind of URL should not work?
Post by Chuck Hill
Post by Ondřej Čada
Finally, to make it couriouser and couriouser, when I run manually from the Terminal an _older_ application, a pre-5.4.3, Xcode-built one, the "...Another.woa/-56000" URL _does_ work all right :-O
Here I was mislead -- the old application I've tried _does_ run in JM, so I was using that instance.

And one quite unrelated question -- is there a way to get rid of the superfluous "Display groups are defined for component FOO.wo but class was not found" errors? They get reported for all my groovy components (and they are wrong, the classes are build all right and the app works with them without a glitch).

Thanks and all the best,
---
Ondra Čada
OCSoftware: ***@ocs.cz http://www.ocs.cz
private ***@ocs.cz http://www.ocs.cz/oc
Chuck Hill
2012-02-16 04:47:31 UTC
Permalink
Hi Ondřej,
Post by Ondřej Čada
Post by Chuck Hill
Post by Ondřej Čada
When I run my built application manually from Terminal, like "./Test.woa/Test -WOPort 56000", then the "http://localhost/cgi-bin/WebObjects/Test.woa/-56000" URL does not work -- consistently yields "The requested application was not found on this server".
Direct connect (http://localhost:56000) works all right (assumed I use -WODirectConnectEnabled of course).
If I set up the very same application in JavaMonitor and access through "http://localhost/cgi-bin/WebObjects/Test.woa", it _again_ works all right!
Check and see what other parameters JavaMonitor is adding to the command line. Maybe a default was changed and needs to be set? Or the older application has something different in its Properties?
Actually, I've found the culprit, but it does not elucidate the problem the slightest bit: when my app runs under JavaMonitor, anything like "http://localhost/cgi-bin/WebObjects/Foo.woa/-1" or "...Foo.woa/-123456789" or "...Foo.woa/-whattheheck" runs just as well, using in fact the JavaM-controlled instance.
Yes, that sounds correct. The /-whatever URLs are for development when you are only running a woadaptor and wotaskd but no JavaMonitor. They are most likely ignored or stripped out resulting in an effective URL of http://localhost/cgi-bin/WebObjects/Foo.woa. You can go to http://localhost:1085 to see what has been registered as available with wotaskd.
Post by Ondřej Čada
In other words, it seems that the "http://localhost/cgi-bin/WebObjects/Foo.woa/-portnumber" URL completely ignores the -portnumber part and always works exactly as if it was not there. Did I perhaps miss anything and this kind of URL should not work?
It should in development mode (e.g. when launched from Eclipse). I would expect it to not work in deployment. You need to use the instance number for that.
Post by Ondřej Čada
Post by Chuck Hill
Post by Ondřej Čada
Finally, to make it couriouser and couriouser, when I run manually from the Terminal an _older_ application, a pre-5.4.3, Xcode-built one, the "...Another.woa/-56000" URL _does_ work all right :-O
Here I was mislead -- the old application I've tried _does_ run in JM, so I was using that instance.
And one quite unrelated question -- is there a way to get rid of the superfluous "Display groups are defined for component FOO.wo but class was not found" errors? They get reported for all my groovy components (and they are wrong, the classes are build all right and the app works with them without a glitch).
Check the contents of the .woo file (it is text).


Chuck
--
Chuck Hill Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/gvc/practical_webobjects
Ondřej Čada
2012-02-16 05:40:29 UTC
Permalink
Chuck,

thanks a lot for quick answer!
Post by Chuck Hill
Yes, that sounds correct. The /-whatever URLs are for development when you are only running a woadaptor and wotaskd but no JavaMonitor. They are most likely ignored or stripped out resulting in an effective URL of http://localhost/cgi-bin/WebObjects/Foo.woa. You can go to http://localhost:1085 to see what has been registered as available with wotaskd.
Well I deploy and develop both on the same machine -- that is not allowed?

(Of course it would not do to deploy commercial apps there; what I deploy is just a few private WOapps which I use myself on my subnet for my own purposes. Guess I should select another machine in the subnet for this kind of deployment :))
Post by Chuck Hill
Post by Ondřej Čada
And one quite unrelated question -- is there a way to get rid of the superfluous "Display groups are defined for component FOO.wo but class was not found" errors? They get reported for all my groovy components (and they are wrong, the classes are build all right and the app works with them without a glitch).
Check the contents of the .woo file (it is text).
The woos are all right, the editor shows the proper settings and the application works exactly as it should. If I rename the groovy components to java, the errors disappear. Looks like the WOO compiler, instead of checking in the .class files whether the classes are available tries to parse .java or something like that.

Thanks a lot and all the best,
---
Ondra Čada
OCSoftware: ***@ocs.cz http://www.ocs.cz
private ***@ocs.cz http://www.ocs.cz/oc
Chuck Hill
2012-02-16 05:46:15 UTC
Permalink
Hi Ondřej,
Post by Ondřej Čada
Chuck,
thanks a lot for quick answer!
Post by Chuck Hill
Yes, that sounds correct. The /-whatever URLs are for development when you are only running a woadaptor and wotaskd but no JavaMonitor. They are most likely ignored or stripped out resulting in an effective URL of http://localhost/cgi-bin/WebObjects/Foo.woa. You can go to http://localhost:1085 to see what has been registered as available with wotaskd.
Well I deploy and develop both on the same machine -- that is not allowed?
Yes, it is allowed, but I fear things will get confused if you use the same app name for development and deployment on the same machine. You can make the app name not match the .woa name in the file system in JavaMonitor. That would probably work around this for you.
Post by Ondřej Čada
(Of course it would not do to deploy commercial apps there; what I deploy is just a few private WOapps which I use myself on my subnet for my own purposes. Guess I should select another machine in the subnet for this kind of deployment :))
I think it is just confusion over the app name in two kinds of deployments on the same host. I am getting confused just typing that. :-)
Post by Ondřej Čada
Post by Chuck Hill
Post by Ondřej Čada
And one quite unrelated question -- is there a way to get rid of the superfluous "Display groups are defined for component FOO.wo but class was not found" errors? They get reported for all my groovy components (and they are wrong, the classes are build all right and the app works with them without a glitch).
Check the contents of the .woo file (it is text).
The woos are all right, the editor shows the proper settings and the application works exactly as it should. If I rename the groovy components to java, the errors disappear. Looks like the WOO compiler, instead of checking in the .class files whether the classes are available tries to parse .java or something like that.
It may, I am not sure how it works.


Chuck
--
Chuck Hill Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/gvc/practical_webobjects
Ondřej Čada
2012-02-16 06:17:01 UTC
Permalink
Chuck,
Post by Chuck Hill
Post by Ondřej Čada
Post by Chuck Hill
Yes, that sounds correct. The /-whatever URLs are for development when you are only running a woadaptor and wotaskd but no JavaMonitor. They are most likely ignored or stripped out resulting in an effective URL of http://localhost/cgi-bin/WebObjects/Foo.woa. You can go to http://localhost:1085 to see what has been registered as available with wotaskd.
Well I deploy and develop both on the same machine -- that is not allowed?
Yes, it is allowed, but I fear things will get confused if you use the same app name for development and deployment on the same machine. You can make the app name not match the .woa name in the file system in JavaMonitor. That would probably work around this for you.
I see. Thanks a lot -- if I don't mess up the names (and if I make sure to use the -WOLifebeat* arguments when manually run applications, which I am afraid I've forgot the last time) it runs perfectly now.
Post by Chuck Hill
Post by Ondřej Čada
Post by Chuck Hill
Post by Ondřej Čada
And one quite unrelated question -- is there a way to get rid of the superfluous "Display groups are defined for component FOO.wo but class was not found" errors? They get reported for all my groovy components (and they are wrong, the classes are build all right and the app works with them without a glitch).
Check the contents of the .woo file (it is text).
The woos are all right, the editor shows the proper settings and the application works exactly as it should. If I rename the groovy components to java, the errors disappear. Looks like the WOO compiler, instead of checking in the .class files whether the classes are available tries to parse .java or something like that.
It may, I am not sure how it works.
Nor am I, which is why I'd like just to switch the error report off -- but can't find how to. Or is it not possible at all?

BTW I've just bumped into another completely weird behaviour of the IDE: if I change a (groovy) source, _sometimes_ I just select "Build Project" from the context menu and the source is compiled and changes are injected to the running app. Just about perfect.

Nevertheless the next time not only this does not work, but not even re-launching the app works, and the only way to make the changes to be reflected in the running application is to Project / Clean...! Far as I can say, no difference in the IDE or console: simply yesterday did work, today does not :(

Drives me completely mad. Any idea what the culprit might be, or at least, how to find it? Are the some detailed build logs somewhere, which may perhaps lead to pointing out the problem?

Thanks and all the best,
---
Ondra Čada
OCSoftware: ***@ocs.cz http://www.ocs.cz
private ***@ocs.cz http://www.ocs.cz/oc

Loading...