Ruby applications deployed on context root fails to work with admin console

[glassfishrobot]

If a Ruby application is deployed at contextroot '/' and then admin consle is accessed then accessing the ruby application gives 404.

Here is what I did:

I deployed a Ruby application 'hello' on context root '/' and it works just fine.

Hitting http://locahost:8080/, I can access the application.

However, once the admin console is accessed at http://localhost:4848/ and after that accessing http://localhost:8080/ gives the classic glassfish index.html page. If I access some controller of the application such as http://localhost:8080/say/hello it gives 404.

This bug does not appear if admin console is started first and then I deploy the ruby app at root context '/'.

Environment

Operating System: All Platform: Macintosh

Affected Versions

[V3]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/10854
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @yaminikb
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented vivekp said: Created an attachment (id=3793) Ruby on Rails application

[glassfishrobot]

@glassfishrobot Commented vivekp said: This is how you can reproduce it:

wget [1] #this will get you jruby-all-1.5.4-1.3.1.zip

install jruby runtime

$ cd glassfishv3/glassfish $ unzip jruby-all-1.5.4-1.3.1.zip

unzip the sample rails app

$ cd ~ # or any place you want to keep this sample $ unzip hello.zip

asadmin start-domain

asadmin deploy --contextroot / hello/

Access the application at

http://locahost:8080/

and

http://locahost:8080/say/hello

Now start admin console and after it has loaded, access http://locahost:8080/say/hello you will get 404.

[1]http://download.java.net/maven/glassfish/org/glassfish/scripting/bundle/jr uby-all/1.5.4/jruby-all-1.5.4-1.3.1.zip

[glassfishrobot]

@glassfishrobot Commented oleksiys said: This happens in situation, when web container is not getting loaded on GF startup. So JRuby container gets registered on Mapper and works well. Once you access admin console UI, you start WebContainer, which overrides Mapper. It updates host (remove old one, add new one) etc. So finally WebContainer maps root element to itself [1]. So we have conflict between 2 containers with different root element settings. CCing more people )

Alexey.

[1] As I understand this happens org.apache.catalina.connector.Connector:1770 if (!"admin-listener".equals(getName()))

{ // See IT 8255 mapper.removeContext(defaultHost, ""); mapper.removeHost(defaultHost); }

[glassfishrobot]

@glassfishrobot Commented oleksiys said: hello Jan

[glassfishrobot]

@glassfishrobot Commented jfarcand said: Note that this is not a regression, and this is there since v3 works started

What is happening here when the WebContainer start's, it register the root '/' for itself, and override any values that were defined there. As an example, Grizzly StaticResourceAdapter gets overriden when a JRuby application is deployed at '/'. Then if a JRuby application was deployed at '/', the Grizzly's Mapper will override it with the WebContainer and it's virtual-server default-web-module value taken from domain.xml.

If we don't let the WebContainer override the '/', then it will means we ignore the default-web module value. It may also cause regression on how the WebContainer works as no WebApp will be defined as '/'. It also breaks the concept of default-web module defined in domain.xml.

[glassfishrobot]

@glassfishrobot Commented vivekp said: At v3 prelude time there was this bug where if jruby container occupies '/' then adminconsole won't comeup. Hong fixed it sometime back. Thats why I thought its a regression. Hong is added to the cc list here for further comments.

But the admin console (web-cotainer) in this case is registerd to a different port 4848. In any case http://localhost:8080/ and http://localhost:4848/ are two different thing and should work fine. Please note that if I start admin console first then deploing ruby app to '/' work fine. Its only other way when a ruby app is first deployed at '/' then admin console starts and then ruby app is no more accessible.

[glassfishrobot]

@glassfishrobot Commented jfarcand said: Admin Console or any applications, as soon as the WebContainer starts it will override the '/' on all ports. Try deploying a web app and you will see...I doubt it will works

[glassfishrobot]

@glassfishrobot Commented jfarcand said: We discussed the issue during the tech meeting and the proposal is we don't start the WebContainer's Connector if there is another GrizzlyAdapter other than the StaticResourceAdapter registered on that port. Investigating...

[glassfishrobot]

@glassfishrobot Commented jfarcand said: Fixed the WebContainer side

Sending web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java Transmitting file data . Committed revision 34031.

Re-assign to Vivek as he must do the same in JRuby to avoid overriding the WebContainer mapping, e.g if the WebContainer is started, JRuby app must fail to deploy on /

[glassfishrobot]

@glassfishrobot Commented vivekp said: the only way JRuby container interacts with deployment of applications is by calling during Deployer.load()

RequestDispatcher.registerEndpoint(contextRoot, adapter, appContainer, params.virtualservers);

It does not occupy and port or context directly.

So not sure what I can do inside my container. It should be deep inside RequestDispatcher.registerEndpoint() where it should fail deployment of a ruby application on contextroot '/' if there already some other application is deployed there.

I am assigning it to Hong for further evaluation.

BTW, I see now serious issues with Jeanfrancois fix. If I deploy a ruby app at context root '/', after that I can't deploy and servlet application on a different context.

1. asadmin deploy --contextroot '/' rubyapp/

Runs fine

2. asadmin deploy hello.war

deployment goes thru fine but accessing localhost:8080/hello hangs forever

3. asadmin undeploy hello

undeployment goes thru fine

4. asadmin undeploy rubyapp

Undeployment goes thru fine

4. asadmin deploy --contextroot '/' hello.war

deployment goes thru fine but application is unaccessible.

This is very confusing and why is that a container holds a port? Can we not deploy ruby as well as JavaEE applications on the same port, the only thing required is different context root for each application.

[glassfishrobot]

@glassfishrobot Commented jfarcand said: Vivek, this is exactly what we have discussed today at the meeting. The WebContainer has not started its WebConnector on port 8080 and 8181 because JRuby hold the port. SO this is not a serious issue like you stated since we have discussed this altogether today at the meeting and I explained exactly the current behavior.

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: As we had the java.net outage last night, Vivek and I were not able to enter the latest comments, we did email exchanges instead. I am entering those comments now:

Comments from Vivek:

Looks like I misunderstood. The thing is that with this behavior, if a ruby app is deployed at context root '/' and thats it, you can't deploy any servlet/ejb applications! This is rather serious limitation.

I can deploy a servlet and ruby application on the same port at different contextroot (non of them on '/') and all of them run fine. Why is '/' so special? Why are we tying '/' with an Adapter.

The expectation is that, deploy a ruby or java application at '/' and then deploy another application ruby or java application '/' and the deployer should throw an error as this context is occupied by another application. This same should happen for other contexts as well.

Comments from me (Hong):

Looking at the code (GrizzlyService), seems if we want to fail the RequestDispatcher.registerEndpoint() when the same context root is already used at that port, the best place for this logic is probably in the implementation of GrizzlyProxy.registerEndpoint() method.

The impl of this method currently calls ((ContainerMapper)grizzlyListener.getEmbeddedHttp().getAdapter()) .register(contextRoot, vsServers, endpointAdapter, container);

Jeanfrancois: I am not sure which class this getAdapter() returns, but in this class, do we have a table of the current used context roots, so we could check for conflict before registering?

Looking at the call again, I think the register method is on the ContainerMapper class, so I am assigning this issue to Jeanfrancois to see if we make the check there and fail the registering if the context root is in conflict.

[glassfishrobot]

@glassfishrobot Commented jfarcand said: I don't think the proposed solution is the proper one. The idea here is the Container that deploy on top of Grizzly should decide themself:

(1) If they want to start, event if the / (or any context-root) is already binded

(2) The call should happens inside the Container itself, not in any GrizzlyProxy/Services. The reason is to save and stop processing deployment event as soon as possible. Please take a look at the WebContainer implementation I did.

So in conclusion, I don't think the fix should go neither in deployment nor Grizzly-Kernel code, but inside the JRubySniffer.

Downgrading the bug to a p3 as for sure we will not change anything now for v3 FCS, and re-assign to Vivek so he can decide to postpone the issue or not. If you disagree, just re-assign to me but like I said a big -1 to implement mix and match of "/" context-root for FCS

[glassfishrobot]

@glassfishrobot Commented vivekp said: For 1), for a consistent behavior, container should not be allowed to override context root, this will result in to inconsistent behavior. A common/consistent behavior should be implemented somewhere in the deployment infrastructure/GrizzlyService that all container follow.

For 2), I disagree. There are other containers, Jython, Closure (coming up) and may be many others, copying the same code in all is a bad coding practice. The reason web container does this way is because this is how it did in v2 and not because its a technically better way to do it.

The right place to do is thru clean API, where a contextrot and the grizzly adapter is registered using

RequestDispatcher.registerEndpoint(contextRoot, adapter, appContainer, params.virtualservers);

Let it fail or pass indicating success or unsuccessful deployment.

[glassfishrobot]

@glassfishrobot Commented jfarcand said: Vivek, please take a look at the fix for the WbeContainer to understand what I means here. Your proposed solution won't work, and the WebContainer would have created way too many objects that will not get used at all if we are going with your solution. That's why it is the role of the Container to decide to bind or not, and act appropriately. Just write a class and share it among your containers for best practice

[glassfishrobot]

@glassfishrobot Commented vivekp said: Yes I have seen your code and I understand what its doing and I know how I can share this common patch. The disagreement is where this common code should live. I disagree that containers should decide what the behavior should be. Such behavior should be implemented for all containers deep down deployment infrastructure. Such patchwork code is always a bad idea. We will discuss more in the engg meeting then make a decision.

[glassfishrobot]

@glassfishrobot Commented vivekp said: As per discussion in engineering meeting and followed up with Jerome. Its too risky to fix this issue in the right way. So we are excluding this issue from fixing in this release.

[glassfishrobot]

@glassfishrobot Commented grisdal said: Added to v3 Release Notes.

[glassfishrobot]

@glassfishrobot Commented kumara said: GlassFish project is no longer enhancing scripting support and unfortunately these issues have to be closed.

[glassfishrobot]

@glassfishrobot Commented File: hello.zip Attached By: vivekp

[glassfishrobot]

@glassfishrobot Commented Was assigned to vivekp

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-10854

[glassfishrobot]

@glassfishrobot Commented Reported by vivekp

[glassfishrobot]

@glassfishrobot Commented Marked as won't fix on Thursday, March 3rd 2011, 10:11:45 am