search

wjw465150 / run-jetty-run

Automatically exported from code.google.com/p/run-jetty-run
0 stars 0 forks source link

crossdomain.xml with multiple context issue #94

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 

Moved from other issue comment , still in discussing.

http://code.google.com/p/run-jetty-run/issues/detail?id=85#makechanges

Comment 24 by juan.tula, Today (4 hours ago)

Hi tony, thanks for this plugin.We have a use case for a jetty.xml file.
First, all our apps uses contexts different than root, but also uses flash to 
make xhr requests, and we need to have a /crossdomain.xml file, to solve this, 
we can use jetty.xml to define two contexts. The other possible sollution is to 
use a rewrite rule handler, to map a request to /crossdomain.xml to load a file 
from elsewhere. Have you any possible sollution to this without using a 
jetty.xml, or an Apache in front of Jetty? I think direct aliases may help, but 
there's no way to configure them now (also we use rewrite handler for some 
other important tasks, so it's needed too...)

Thanks!

Original issue reported on code.google.com by tonylovejava on 23 Nov 2011 at 8:39

GoogleCodeExporter commented 9 years ago

Original comment by tonylovejava on 23 Nov 2011 at 8:48

GoogleCodeExporter commented 9 years ago 
Are you talking about a RJR issue , or a Jetty issue ?

RJR assumed user only use one context , so that shouldn't not the case for RJR 
now.

As what I know , it's must have to use a jetty.xml , 
either you want to have a root context to serve the cross-domain.xml, 
or you want to use RewriteHandler to rewrite the path.

Original comment by tonylovejava on 23 Nov 2011 at 9:17

GoogleCodeExporter commented 9 years ago 
Yes, Jetty supports perfectly both features, the problem is I have no way to 
tell RJR to use them... The problem can be easily solved with jetty.xml 
support...

Other interesting feature wold be the possibility to add more jars to the jetty 
environment, to augment it's features (new filters, by example), without having 
to get them in project's classpath (that's because we use jetty only for 
development, don't want to have jetty jars in production).

Thanks a lot for your time!

Original comment by juan.t...@gmail.com on 24 Nov 2011 at 5:00

GoogleCodeExporter commented 9 years ago 

Ok , got your ideas.

For the jetty.xml support ,
we could have some configuration to handle this .

But I am wondering how will the classpath work for each context ?

Shall they use the same classpath as project classpath , 
or they need multiple classpath settings?

I don't think ppl who use RJR will want to config the project classpath by 
themself.

----------

If you are just looking for crossdomain.xml solution, 
will that help if I just provided a option for "crossdomain" field and let you 
fill the crossdomain file location ,
and setup a root context to provide this file as "/cross-domain.xml" ?

 (Sure,it won't work if you also setup the RJR project context as root context , 
  that's not the case.)

For the classpath issue , I am not sure you are talking about Jetty classpath 
or web context classpath , they are totally different classpath.

For Jetty classpath , you could config it in RunConfiguration , 
for web context classpath , currently you have to config the project classpath.

There's a discussion for web context classpath management, 
please reference to Issue 88 , I am still working on it.  :)

Original comment by tonylovejava on 25 Nov 2011 at 2:55

GoogleCodeExporter commented 9 years ago 
I think classpath configuration is for another topic, sorry to bring it here 
(btw, if you define two contexts in UI, then, each one should have it's own 
classpath)

The must is have a way to use rewrite rules, and the only current way to get 
that is specifying a full jetty.xml. Specifying a crossdomain.xml will solve 
only half of the problem, and I think the plugin will start to get filled with 
"special scenarios" options... :S

Original comment by juan.t...@gmail.com on 25 Nov 2011 at 2:26

GoogleCodeExporter commented 9 years ago 
I don't mind for special scenarios options , 
sometimes we have to build a plug-in for "it just work".

RJR is not considering to be a powerful tool , it's a simple development tool,
most ppl only use 4-5 basic options in most times.

If it's easy enough to solve the cross-domain issue , 
and if ppl really need this , I would like to add the option for it even it's 
just a special scenarios.

I am not sure ppl need cross-domain more or rewrite rules more.

If ppl don't want to use rewrite rules in most times , 
it's still a "special scenarios" options.

And if you want to fix the cross-domain issue in the rewrite rule case ,
you still have to write your own code.

For most of our users, it's not making things easier , that's my opinion.
---------

So far as what I know who used rewrite rule, the apache solution is good enough 
for them.

---------

For the url rewrite issue , I am thinking to add a option to let user set one 
more "jetty.xml" as a additional one , if you need to config those configs or 
to have more contexts , you could just set it in the jetty.xml.(Sure , you have 
to config the classpath for additional web contexts.)

We will run with original RJR settings and then apply all the settings in the 
additional jetty.xml .  
(that means a server with a specific web context we define in run 
configuration.)

Original comment by tonylovejava on 26 Nov 2011 at 12:25

GoogleCodeExporter commented 9 years ago 
For one more additional jetty.xml configuration issue , move to Issue 96 .

And left this one here,I am still thinking if there's a easier way for 
cross-domain issue.

Original comment by tonylovejava on 26 Nov 2011 at 12:34

GoogleCodeExporter commented 9 years ago 
What if you have two mutually excludent options to configure RJR?
One simpler, with the current UI, to most users, and another, where you provide 
the jetty.xml file? That is, a simple configuration option, and a really 
complex option, for everyone else?
In UI, you can have two tabs inside the first one, and you can use only one of 
them, classic or advanced...
That way, you don't complex amything tryint to apply two configuration sets, 
you use just one or another, and everyone is happy, you solve a lot of issues 
related to jetty.xml, and the other users does not get hit by additional 
complexity...

Original comment by juan.t...@gmail.com on 29 Nov 2011 at 4:22

GoogleCodeExporter commented 9 years ago 
We already have "advance options" in the UI. :P

Am just thinking what would really help for our user.

Yep , we will have a option for setting one more jetty.xml 
and I have already done the code.

I will release a new version after I finish Issue 88.

Original comment by tonylovejava on 29 Nov 2011 at 4:29