Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 364925

Summary: Deploy to Web Server / File System
Product: z_Archived Reporter: Tony Chen <chenzhh>
Component: EDTAssignee: Project Inbox <edt.deployment-inbox>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3 CC: dan.darnell, hjiyong, jvincens, mayunf, smythew, svihovec, tww
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Tony Chen CLA 2011-11-28 00:24:37 EST
Because the changes in Rich UI deployment. Deploying to a Web Server (not Application Server) is not as easy as in RBD. See forum post 
  http://www.eclipse.org/forums/index.php/t/262775/

We need to make deployment to Web Server as easy as to Application Server.
Comment 1 Huang Ji Yong CLA 2012-01-09 09:59:33 EST
Hi Guys,
Part of this problem related to the includeFile. I have made a document in bug 363959 to discuss it.
The problem is that load local file by ajax does not work in chrome except we add a parameter when starting chrome --allow-file-access-from-files.
I think the solution makes sense because only developers would likely to encounter this defect, and they are able to add the param if they want to debug in chrome.
Any comments is appreciated.
Comment 2 Brian Svihovec CLA 2012-01-10 11:39:29 EST
In RBD, a Rich UI application works on an HTTP server (assuming there are no Service invocations) due to the fact that all of the include files are added to the HTML file during deployment, meaning that no proxy requests are required. 

In EDT, all of the required .js files are loaded using proxy requests, so it is no longer possible to run a Rich UI application on an HTTP server.

Can you provide more details on the 'load local file' feature, and how it related to this conversation?  If a file is 'local', where is it located?  The design document states that IE and Chrome don't support loading local files using Ajax.  If FF supports this feature, how does this work when there is no proxy on the server?

I was under the impression that the solution to this problem would be to replace our proxy requests for loading required .js files with standard <script> tags, which is something that Will mentioned in a different defect (I don't have the # off hand).  I realize that we would still need to make things 'synchronous' in some way, but using standard script tags would make an application work on an HTTP server where no proxy could be used.
Comment 3 Will Smythe CLA 2012-01-10 11:45:11 EST
Is there some reason we have to load .js files via our proxy? Since the files are located on the same web server as the HTML file, why can't standard Ajax be used to retrieve the files? This comment is somewhat related to my comment #1 in Bug 368168.

Also, should we consider using Jetty to serve up pages/resources during development instead of whatever approach we are using today?
Comment 4 Dan Darnell CLA 2012-01-10 13:05:11 EST
(In reply to comment #3)
> In EDT, all of the required .js files are loaded using proxy requests, so it is
> no longer possible to run a Rich UI application on an HTTP server.

This doesn't ring true to me. I am successfully serving up several EDT-developed apps on nothing but an HTTP server.

Am I not understanding some nuance of your statement? I'm not using any "includeFile" references and I'm not using Dojo. But for regular Rich UI applications (developed in EDT) that don't make service calls I can (manually) deploy to an HTTP server.

--Dan
Comment 5 Tony Chen CLA 2012-01-10 22:07:30 EST
Looks like there are some confusion for both the requirement and how the bootstrap is done in EDT. 

For the requirement, it says deploy to Web Server. However, in the offline discussion, I also mentioned to Jiyong that be able to open a RUI app from local file system and run it is also important for development and demo purpose. This was OK in RBD, and I like it to be in EDT as well. Part of Jiyong's the design is for this purpose. I just updated the subject of the bug to reflect this requirement. Sorry that I did not make it clear. 

For how EDT bootstrap load code. It is not using proxy in any way. The bootstrap will do the following in sequence

1. use AJAX (xmlhttp) to load all include files, using document.write() to append the include files to the current dom

2. load dependent js file (runtime, widgets, etc) by creating a <script> tag for each and inserting the <script> tag into the document head. There's also callback methods to ensure the js are loaded one by one in sequence.

Problem mentioned in comment 1 bug relates to step 1, where in Chrome, loading a resource from **local file system** using AJAX is not allowed. 




(In reply to comment #1)
> Hi Guys,
> Part of this problem related to the includeFile. I have made a document in bug
> 363959 to discuss it.
> The problem is that load local file by ajax does not work in chrome except we
> add a parameter when starting chrome --allow-file-access-from-files.
> I think the solution makes sense because only developers would likely to
> encounter this defect, and they are able to add the param if they want to debug
> in chrome.
> Any comments is appreciated.
Comment 6 Huang Ji Yong CLA 2012-01-11 01:11:07 EST
Thanks Tony for clarifying.
In RBD, the deploy html file without services can be run without deploying to servers like Tomcat. It can run by "file://.." in the browser.
EDT cannot do this because of 2 issues:
1. EDT will load the dependent js file in runtime. The file path is set by
script.src = "/" + egl__contextRoot + "/" + url;
This path works when deploying but not for local file system.
This problem does not happen in RBD because all the js file content are included in html file, no need to load in runtime.
2. When there is includeFile, EDT load it by ajax. Ajax load for local file system does not work in chrome and IE.

In the design document, I'm discussing issue #2 because it relates to the other bug in the document.
Comment 7 Brian Svihovec CLA 2012-04-17 15:38:33 EDT
This type of line item should also be considered when defining extension points for deployment.  I am not going to assign this to the .8.1 release at this time, since it is not a specific type of deployment we want to implement right now, but providing the ability to add this in the future through extension points should be considered.