On Thu, 2011-04-14 at 12:55 +0530, Jaikiran Pai wrote: > I was testing the lastest AS7 upstream and am noticing an issue with > web application context handling. Just start the server and access any > non-existent URL like http://localhost:8080/nonexistentapp. It just > renders a blank page. Shouldn't it show up a 404 error page like it > does in previous versions of JBoss AS? If there's nothing to map, you get a 404. Your browser then does not feel like it has to display the status code to you.

For whatever reason, just like it is a good idea to allow users to package whatever JAR they think is useful in their war, it is apparently needed to have hardcoded HTML generation with embedded images to present some hello page.

On Thu, 2011-04-14 at 12:55 +0530, Jaikiran Pai wrote: > I was testing the lastest AS7 upstream and am noticing an issue with > web application context handling. Just start the server and access any > non-existent URL like http://localhost:8080/nonexistentapp. It just > renders a blank page. Shouldn't it show up a 404 error page like it > does in previous versions of JBoss AS? If there's nothing to map, you get a 404. Your browser then does not feel like it has to display the status code to you. For whatever reason, just like it is a good idea to allow users to package whatever JAR they think is useful in their war, it is apparently needed to have hardcoded HTML generation with embedded images to present some hello page.

> > If there's nothing to map, you get a 404. Your browser then does not > feel like it has to display the status code to you. I saw the same thing, and I used Wireshark to see if a 404 was coming back from AS 7, and it always does. So, the blank page is caused by the browser.

Andy > > For whatever reason, just like it is a good idea to allow users to > package whatever JAR they think is useful in their war, it is > apparently > needed to have hardcoded HTML generation with embedded images to > present > some hello page. > > -- > Remy Maucherat <rmaucher(a)redhat.com&gt; > Red Hat Inc > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Am 15.04.2011 um 11:27 schrieb Max Rydahl Andersen: > But what is different about AS 7's errors and other 404's ? AS7 may only sent the http code 404 without any actual page content, while other sites also send a small http snippet that says "404".

On Fri, 2011-04-15 at 18:13 +0200, Max Rydahl Andersen wrote: >> Am 15.04.2011 um 11:27 schrieb Max Rydahl Andersen: >>> But what is different about AS 7's errors and other 404's ? >> >> AS7 may only sent the http code 404 without any actual page content, >> while other sites also send a small http snippet that says "404". > > ah got it - I guess this coincide with the "missing" ROOT.war which "missing status" also makes > it very hard for newbie users to know if they actually have a running AS since it just returns a blank boring page. > Yes, but we now have two HTTP ports. It may be better to place a welcome page on the management port (9990). This would also avoid the security problem that can be created by default deployments.

Although that only would work for standalone, in domain mode the management port is not running in the AS server process.

> On Fri, 2011-04-15 at 11:34 -0500, Jason T. Greene wrote: >> Although that only would work for standalone, in domain mode the >> management port is not running in the AS server process. > > I'm not sure it's a good idea to have a welcome page in that mode. > > Normally, all servers that I know of include a welcome of some sort, but > when they do it is usually a normal deployment. Couldn't we at least add a ROOT.war into deployments/ until you figure out how to have a fallback option ? :)

How about a more dynamic error page for the 404 error? "You have connected to JBoss AS but not deployed any web applications" Before the Root.war web app was added to the JBoss distributions in the past the number of people reporting JBoss did not work was quite high - what we don't know is how many actually gave up using it because they believed it was broken out of the box.

IMO, we really need a way to convey (on the browser) to the end user that something went wrong (not just 404, but for any other similar codes too). A blank page doesn't really help end users.

> Why on the web container port rather on > the management one ? I think we need it for both the ports not just web component.

On Mon, 2011-04-18 at 16:02 +0530, Jaikiran Pai wrote: > IMO, we really need a way to convey (on the browser) to the end user > that something went wrong (not just 404, but for any other similar codes > too). A blank page doesn't really help end users. Actually, it's the browser which does not "convey" to the end user that something went wrong. But I suppose it's easier to force me to add some hack ;)

>> Why on the web container port rather on >> the management one ? > I think we need it for both the ports not just web component. Ah, the "feel good it's working" factor it is, then. Don't you think people are going to whine if they read "404" (and nothing else) in their browser by that logic, rather than the usual fancy welcome page that does some handholding ?

> Couldn't we at least add a ROOT.war into deployments/ until you figure out > how to have a fallback option ? :) I don't think polluting the user deployments is good. Do you really need that, or is it simply a habit ?

Why on the web container port rather on the management one ?

On Mon, 2011-04-18 at 12:38 +0200, Max Rydahl Andersen wrote: > I personally don't care if the user deployments contain root.war or not - > what I do care is that users can very easily get started and verify they are on the right track. > > Getting a page verifying the server is working/running would be a great help here. > > Not only for usability/gettingstarted concerns but also to have some "identfiication"/branding of AS 7 so > you and everyone else know what they are seeing/using. > > btw. the error reporting/behavior is different when you visit the management, the web root or a deployed context - > would be nice to at least have them be somewhat consistent. So we need to add a welcome.war in deployments then (no need to name it ROOT.war IMO).

>> Why on the web container port rather on >> the management one ? > Because noone knows where the management one is at. > > First link on the default page should be the management - just like it was in previous versions (and no, that isn't just a habit, its what makes sense :) Port 8080 does not mean anything, it's just the Tomcat default.

I agree we do need some kind of welcome page. Assuming we cannot do it without a deployment though, I think it would be best to first solve https://issues.jboss.org/browse/JBAS-9020 so that we don't have to spend a great deal of time figuring out how to ship a deployment in our HD directory or in the content repository. This way it's just a file we put somewhere and reference from the configuration by default. In other words, much less work, and much easier for the savvy user to turn off when they want to provide their own root path WAR.

On 4/18/11 7:50 AM, David M. Lloyd wrote: > On 04/18/2011 06:38 AM, Carlo de Wolf wrote: >> On 04/18/2011 12:58 PM, Remy Maucherat wrote: >>> On Mon, 2011-04-18 at 12:38 +0200, Max Rydahl Andersen wrote: >>>> I personally don't care if the user deployments contain root.war or not - >>>> what I do care is that users can very easily get started and verify they are on the right track. >>>> >>>> Getting a page verifying the server is working/running would be a great help here. >>>> >>>> Not only for usability/gettingstarted concerns but also to have some "identfiication"/branding of AS 7 so >>>> you and everyone else know what they are seeing/using. >>>> >>>> btw. the error reporting/behavior is different when you visit the management, the web root or a deployed context - >>>> would be nice to at least have them be somewhat consistent. >>> So we need to add a welcome.war in deployments then (no need to name it >>> ROOT.war IMO). >> Yes. We have a good line between what is considered user space and AS >> space and this goes over it. >> I think a welcome.war should be considered a (complementary) user >> deployment. Maybe we should stuff it full of our profile pictures/mosaic >> ("Greetings from JBoss!"). :-) > > I agree we do need some kind of welcome page. Assuming we cannot do it > without a deployment though, I think it would be best to first solve > https://issues.jboss.org/browse/JBAS-9020 so that we don't have to spend > a great deal of time figuring out how to ship a deployment in our HD > directory or in the content repository. This way it's just a file we > put somewhere and reference from the configuration by default. > > In other words, much less work, and much easier for the savvy user to > turn off when they want to provide their own root path WAR. My biggest concern with doing this as a deployment is just a bunch of unnecessary processing just to display some static resources. However, if it can be shown that the cost of some kind of ROOT.war is very minimal, than I'd be ok with it.

On 04/18/2011 09:51 AM, Brian Stansberry wrote: > If we're going to do it as a true deployment (i.e. one that shows up in > the config file's<deployments> section and not a hack like we did in > Alpha1 for the jdbc rars) then we need to do JBAS-9020 and treat it as > "unmanaged" content > > <deployment name="ROOT.war" runtime-name="ROOT.war"> > <fs-archive path="ROOT.war" > relative-to="jboss.server.system.content.dir"/> > </deployment> > > Treating it as managed content ain't gonna fly. > > <!-- No way! > <deployment name="ROOT.war" runtime-name="ROOT.war"> > <content id="d37ede977b022a1456ec5e7a5eee07549cb1c414"/> > </deployment> > --> Yeah this is what I was getting at. To Remy's point though we will probably want a nice name like "jboss-welcome.war" or something.

On 4/18/11 9:56 AM, David M. Lloyd wrote: > On 04/18/2011 09:51 AM, Brian Stansberry wrote: >> If we're going to do it as a true deployment (i.e. one that shows up in >> the config file's<deployments> section and not a hack like we did in >> Alpha1 for the jdbc rars) then we need to do JBAS-9020 and treat it as >> "unmanaged" content >> >> <deployment name="ROOT.war" runtime-name="ROOT.war"> >> <fs-archive path="ROOT.war" >> relative-to="jboss.server.system.content.dir"/> >> </deployment> >> >> Treating it as managed content ain't gonna fly. >> >> <!-- No way! >> <deployment name="ROOT.war" runtime-name="ROOT.war"> >> <content id="d37ede977b022a1456ec5e7a5eee07549cb1c414"/> >> </deployment> >> --> > > Yeah this is what I was getting at. To Remy's point though we will > probably want a nice name like "jboss-welcome.war" or something. >

On 04/18/2011 11:57 AM, Brian Stansberry wrote: > On 4/18/11 9:59 AM, Jason T. Greene wrote: >> On 4/18/11 9:56 AM, David M. Lloyd wrote: >>> On 04/18/2011 09:51 AM, Brian Stansberry wrote: >>>> If we're going to do it as a true deployment (i.e. one that shows up in >>>> the config file's<deployments> section and not a hack like we did in >>>> Alpha1 for the jdbc rars) then we need to do JBAS-9020 and treat it as >>>> "unmanaged" content >>>> >>>> <deployment name="ROOT.war" runtime-name="ROOT.war"> >>>> <fs-archive path="ROOT.war" >>>> relative-to="jboss.server.system.content.dir"/> >>>> </deployment> >>>> >>>> Treating it as managed content ain't gonna fly. >>>> >>>> <!-- No way! >>>> <deployment name="ROOT.war" runtime-name="ROOT.war"> >>>> <content id="d37ede977b022a1456ec5e7a5eee07549cb1c414"/> >>>> </deployment> >>>> --> >>> >>> Yeah this is what I was getting at. To Remy's point though we will >>> probably want a nice name like "jboss-welcome.war" or something. >>> > > Sounds good. BTW, to help clarify, that > "jboss.server.system.content.dir" above is a system path that points to > a special location in the dist for this kind of thing, probably a peer > to "standalone/configuration", "standalone/data", "standalone/log", > "standalone/deployments". For domain mode an analogue would be under > "domain". > > We had such a location in Alpha1. See strikeout-text discussion of it in > http://community.jboss.org/wiki/JBossAS7UserGuide TBH in this particular case, it could most likely exist outside of "standalone" or "domain" in some other location. After all if we ship this file, we can reference it by file name even in domain mode.

>>> In other words, much less work, and much easier for the savvy user to >>> turn off when they want to provide their own root path WAR. If I understand that issue then I would be able to do cp mywelcome.war standalone/deployments/welcome.war and it will "override" the defaults provided in the default setup ? Sounds good :)

On 04/18/2011 10:31 AM, Max Rydahl Andersen wrote: > >>>> In other words, much less work, and much easier for the savvy user to >>>> turn off when they want to provide their own root path WAR. > > > If I understand that issue then I would be able to do cp mywelcome.war standalone/deployments/welcome.war > and it will "override" the defaults provided in the default setup ? > > Sounds good :) No, if we distribute the welcome JAR as a deployment they will have to remove it before they can install their own root context.  However, it is pretty easy to do - we could even put instructions for how to do it on the landing page. Hell we could even put a *button* to do it on the landing page.

On 04/18/2011 07:03 PM, denstar wrote:

> And getting rid of it would be as easy as deleting the jar before > deploying? No, it would be a configuration change - just deleting the file would not really do anything except cause a deployment error.  But then everything is a configuration change.  Basically when you pack up and ship your server environment, if you're using the standalone model (AS <=6 style) you'll probably have your final standalone.xml file anyway which could just exclude that.  If you're using the domain model then you'd be building up your production config in a completely different way anyway.

>> Couldn't we at least add a ROOT.war into deployments/ until you figure out >> how to have a fallback option ? :) > > I don't think polluting the user deployments is good. Do you really need > that, or is it simply a habit ? I personally don't care if the user deployments contain root.war or not - what I do care is that users can very easily get started and verify they are on the right track. Getting a page verifying the server is working/running would be a great help here. Not only for usability/gettingstarted concerns but also to have some "identfiication"/branding of AS 7 so you and everyone else know what they are seeing/using. btw. the error reporting/behavior is different when you visit the management, the web root or a deployed context - would be nice to at least have them be somewhat consistent. > Why on the web container port rather on > the management one ? Because noone knows where the management one is at. First link on the default page should be the management - just like it was in previous versions (and no, that isn't just a habit, its what makes sense :) /max _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

At least put a http accessible welcome page *somewhere* and consider this a request to make the error codes/handling consistent on both management, empty root and within a deployed context if at all possible.