search

tony1223 / run-jetty-run

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

Enable user to specify the jetty.xml to be used #9

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I think that the possibility to specify a jetty.xml is a must. It would 
help to do a lot of things, like running with SSL connector.

But I agree this can open a can of worms.
What would happen to the UI port specification?
And the context?

Original issue reported on code.google.com by danilo.t...@gmail.com on 26 Feb 2008 at 1:10

GoogleCodeExporter commented 9 years ago 
Attached is a patch to Bootstrap.java that allows you to set a VM property to 
specify
the jetty.xml config.  It's kind of a hack, since I didn't want to mess with 
the UI
code. but it works.

In the VM Arguments of your launch configuration set
-Drjrxml=./jetty.xml

If jetty.xml is in the root of your project it will be used (you can also use a 
fully
qualified path name). 

The UI port, context and WebApp dir are ignored, since you can define them in 
jetty.xml

Note: You still have to specify a valid "WebApp dir" because there are other 
checks
that the plugin performs.

Original comment by mshillin...@gmail.com on 26 Jun 2008 at 7:56

Attachments:

GoogleCodeExporter commented 9 years ago 
mshillinger, thanks for the patch.  Can you add the steps for build from 
sources the
plugin? (after I patched the code with unix-command "patch")

Original comment by hermetica@gmail.com on 29 Jun 2008 at 4:44

GoogleCodeExporter commented 9 years ago 
I have never built/packaged a plugin before, perhaps the project owner,
eelco.hillenius, can explain the correct way build and package the plugin.  
There
does not seem to be an automated way to do the packaging.

If you import the projects into eclipse, there is a build.xml file in the
"run-jetty-run-bootstrap" project. 

In Eclipse: File->Import->Existing projects into workspace.  

Select the top of the SVN tree and you should see 4 projects (run-jetty-run,
run-jetty-run-bootstrap, run-jetty-run-feature and run-jetty-run-updatesite)

Note: you will need a version of eclipse that supports PluginDevelopment.

Execute the <build> target to generate a new "run-jetty-run-bootstrap.jar".  
This
file lives in the "runjettyrun_1.0.1.jar" that ends up in ECLIPSE_HOME/plugins
directory.  

I never figured out how to generate runjettyrun_1.0.1.jar, so I unjared an 
existing
version and overwrote the existing "run-jetty-run-bootstrap.jar".  I then 
re-jared
the files and copied the new runjettyrun_1.0.1.jar to ECLIPSE_HOME/plugins.

It seems that the jar gets expanded under
ECLIPSE_HOME/configuration/org.eclipse.osgi/bundles, so you might have to start
eclipse with the "-clean" switch.  

I am sure this is NOT the correct way to do it, but I finally get it working.

Original comment by mshillin...@gmail.com on 7 Jul 2008 at 7:07

GoogleCodeExporter commented 9 years ago 
I already built the plugin and deploy in the update-site (runing locally).  
Then, i
can install it as another plugin using update remote.  Thanks! your patch works 
well! :)

Original comment by hermetica@gmail.com on 11 Jul 2008 at 1:46

GoogleCodeExporter commented 9 years ago 
+1 

Because of this issue I can't start Jetty from within Eclipse.

That's bad because debugging is much harder...

Plus, I've got 1.0.1 and still need to add servlet-api jar to my classpath :(

Just my two cents,

nachokb

Original comment by nachokb on 14 Aug 2008 at 5:13

GoogleCodeExporter commented 9 years ago 
Besides SSL support (addressed by version 1.1, just released), what else do you 
need 
to specify in jetty.xml?

Original comment by James.Sy...@gmail.com on 4 May 2009 at 12:29

GoogleCodeExporter commented 9 years ago

Original comment by James.Sy...@gmail.com on 4 May 2009 at 12:43

GoogleCodeExporter commented 9 years ago 
Updated the summary

Original comment by James.Sy...@gmail.com on 4 May 2009 at 12:51

GoogleCodeExporter commented 9 years ago 
I imagine that things like jndi resources can only be addressed by jetty.xml 
configuration.

Original comment by danilo.t...@gmail.com on 4 May 2009 at 12:33

GoogleCodeExporter commented 9 years ago 
I don't think JNDI resources will be usable without adding Jetty Plus (see 
Issue 11).

But I do think that being able to specify a jetty.xml file would be useful.  As 
it is
now you'll have to add a jetty-web.xml file to your WEB-INF folder which is not 
very
clean.  Being able to specify a jetty.xml in different run configurations would 
be
very useful.

Original comment by dree...@gmail.com on 6 Aug 2009 at 12:38

GoogleCodeExporter commented 9 years ago 
I used jetty.xml file with Jetty Launcher plugin to define multiple 
webapps/projects
so they could be started same time and under same jetty instance.

Original comment by rkopi...@gmail.com on 14 Aug 2009 at 11:30

GoogleCodeExporter commented 9 years ago 
Just wanted to let you guys know that I have forked this project and created a 
new
version on GitHub that supports supplying a VM Argument to specify a jetty.xml 
file.
 I have created a new update site and plan to maintain this project moving forward.
Any feedback would be appreciated, as well as whether it even works for anyone 
else.
I have also migrated this new version to use Maven which should allow anyone to 
build
the plugin out of the box.

http://github.com/alexwinston/RunJettyRun

Original comment by alex.win...@gmail.com on 14 May 2010 at 9:15

GoogleCodeExporter commented 9 years ago 
Accepted, i will make it as a milestone of 1.2.2 .

Original comment by tonylovejava on 20 Mar 2011 at 5:53

GoogleCodeExporter commented 9 years ago

Original comment by tonylovejava on 18 May 2011 at 6:06

GoogleCodeExporter commented 9 years ago

Original comment by tonylovejava on 21 Jul 2011 at 4:32

GoogleCodeExporter commented 9 years ago 
I've added a comment in issue#85, regarding being able to define jetty-xml 
overrides.

Original comment by en...@stolsvik.com on 29 Jul 2011 at 7:28

GoogleCodeExporter commented 9 years ago 
Regarding implementation: I don't have a very solid understanding here yet, but 
there should, AFAIU, be at least two ways to do this.

Both uses the logic that the starter 'jetty.jar' does - that it reads in 
jetty.xml files. There is one main jetty.xml, and then one can append configs 
(which are run after the main), but also prepend configs (which then are run 
before).

One still wants the basic functionality to work - that is, using no config 
files whatsoever, it shall be simple to make a run-configuration using RJR.

The basic need is to have the resulting jetty server have a specific context, 
specified in the run-configuration, and also stash the project classes onto the 
classpath where Jetty will read from. (Also possibly a specific port etc).

1) You make a dead-simple "template language", where the string $CONTEXT$, 
$CLASSPATH$, $PORT$ etc is magic. Upon start/debug, the run-configuration 
specified jetty.xml file is read (which has a default), the variables are 
exchanged with the run-configuration specified values, and save to a new 
location, and then the jetty-starter is pointed to the new resulting file, as 
well as any user-specified pre- and post- XML configs.

2) (I think this is the better, simpler, robuster one) - the jetty-starter 
first executes any run-configuration-specified XML pre-configs. RJR then 
/programmatically/ checks whether the pre-configs created a server instance, if 
not, then create it. RJR then programmatically checks if the 
run-configuration-specified context was created, if not, then create it. RJR 
then programmatically configures the server-instance with the 
run-configuration-specified port etc etc. RJR then executes any 
run-configuration-specified XML post-configs.

The point to remember, is that jetty's config files basically is a 
"java-in-XML" scripting language (One may argue that the jetty config is the 
very first Java IoC/DI system). Thus, whether one configures the server using 
java or jetty.xml doesn't really matter - and it should be possible to jump 
back and forth between the two.

Original comment by en...@stolsvik.com on 29 Jul 2011 at 7:45

GoogleCodeExporter commented 9 years ago 
I've added a comment on issue 85, with a use case for this configuration (it's 
in http://code.google.com/p/run-jetty-run/issues/detail?id=85#c24).

If I can help someway to get this done, please ping me!

Original comment by juan.t...@gmail.com on 23 Nov 2011 at 3:50

GoogleCodeExporter commented 9 years ago 
I think Issue 96 is good enough to handle those user's need.

If you only use jetty.xml , because we didn't know how many web context you 
define , what's the classpath for each web context.

So that means you have to maintain the classpath by yourself , 
that's not really a good things for most ppl.

Now you got chance to config a one more jetty.xml if you really need.

It's useful for settings handlers.

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

GoogleCodeExporter commented 9 years ago

Original comment by tonylovejava on 15 Dec 2011 at 12:57