JettyLauncher class loader

[Manuel Carrasco Moñino]

Following the discussion here: https://gwt-review.googlesource.com/#/c/8150/2

What do you guys think about changing the way of how embedded jetty class loader works?

Options:

- leave it as current: a bunch of hacks to load certain classes at first

- modify it to use the standard way: first WEB-INF/lib  then classpath

- a mix of both, so as the default is #2 but we maintain a flag for using #1

- more... ? 

[Brandon Donnelson]

I like your change. I think having this allows for easier transition to a more favorable facet pattern down the road. 

[Brian Slesinsky]

I don't understand the details enough to make an informed recommendation, but I think introducing a new entry point is a good time to transition to the standard way (assuming it is standard).

We could add the backward-compatibility flag if needed after some testing to see what the breakage would be.

- Brian

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAtaxEabPDFt-2CEFR154GOHcBYMj47BQOVXHUfqvbyGBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Brandon Donnelson]

After looking at it a bit more, I think it would be nice to add in a -server argument like DevMode has to the change, but that looks like it also needs a couple other args like -war. Having the -server arg would allow for another server type to launch other than the embedded jetty, and maybe its a matter of providing a separate jetty launcher like appengines so none of the jetty code is in the main type class that provides the GWT logic. This way it extracts the responsibility and decouples jetty as a dependency b/c folks use tomcat, jboss, vaadin, or other backend platform. Thoughts?

On Tuesday, July 1, 2014 12:19:03 PM UTC-7, Brian Slesinsky wrote:

I don't understand the details enough to make an informed recommendation, but I think introducing a new entry point is a good time to transition to the standard way (assuming it is standard).

We could add the backward-compatibility flag if needed after some testing to see what the breakage would be.

- Brian

On Tue, Jul 1, 2014 at 6:36 AM, Manuel Carrasco Moñino <man...@apache.org> wrote:

Following the discussion here: https://gwt-review.googlesource.com/#/c/8150/2

What do you guys think about changing the way of how embedded jetty class loader works?

Options:

- leave it as current: a bunch of hacks to load certain classes at first

- modify it to use the standard way: first WEB-INF/lib  then classpath

- a mix of both, so as the default is #2 but we maintain a flag for using #1

- more... ? 

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Brandon Donnelson]

After looking at the GPE bootstrapping for DevMode, I think I found a good way to start the CodeServer, which means two launch configs go when dev mode is started. Then I could sync up the launch configs in case more than one, or persist one and not the other. At anyrate there are some options with out having to worry about accidentally stopping one and not the other. My demo used CodeServer as the main type although it creates more waves in changes, and I suspect I could change the main types around, DevMode being main and this would cause less changes. I think I could have this worked up in a couple of half days and get back with a demo, screencast for thoughts. This would mean I could have all the steps wrapped up shortly and it would work seamlessly for a 2.5.1+.

Eclipse Goals

1. no precompile flag on
2. create a no cache file, with just dev mode, that code server initializes
3. start the code server, which starts the servlet container, dev mode, -server flag
4. remove code server flag

• clean compile - generates clean no cache with sum logic
• start sdm
• start servlet container
• start browser
• dev mode on

[Manuel Carrasco Moñino]

Brandon, I think you are mixing subjects in this thread.

You have introduced another discussion related with how to run superdevmode from eclipse, so lets move that discussion to a different channel. 

What we wanted to discuss here (Thomas suggestion) is how to improve or get rid of current class loader hacks in the JettyLauncher.

This has been cause of problems and it does not follow a standard way.

I agree with Thomas and Brian to make a transition to the standard way with a flag to enable the current way.

But first we have to decide how long are we going to support jetty launcher, because maybe we can consider remove it in 3.0.

- Manolo

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ae294613-6514-4f1a-a202-cc001dd32425%40googlegroups.com.

[Brandon Donnelson]

Sorry about that I thought the GPE(IDE) context may be relevant to the process because clients use these processes and are designed around them to boot the processes. Good point I'll move my comments. 

I vote for keeping a default jetty launcher into 3, upgrade jetty and and use to continue to use the -server flag to pipe in other servers. The reason I mention this is if you remove jetty it will cause issues downstream in the IDEs, well that is if they had a good way of setting up a servlet container in the launch config that would be optimal. There are some challenges with moving to a decoupled structure, at least with GPE. In eclipse this can be done well with facets, but this is new territory, so the experience and changes are more drastic. Keeping it in once process on GWT side, allows for easy decouple of the sdk in the IDE which allows to call the main. And some folks are still using 2.5.1+ for debugging, sad, but I get them which means that multiple versions in the IDE which I think are primary end users of the launchers/main types. 

Maybe removing the Jetty would be ideal, but it looks like it may shake the boat a bit yet. I could be looking at it wrong, maybe I should be asking how would the process be replaced in a seamless un-painful way for users to use? 

Brandon

[Stephen Haberman]

I've not looked at the code, but I'll chime in my support for Manuel's
approach--I think the JettyLauncher/SuperDevMode class would be the
easiest transition path for us.

(Not all of our devs use GPE, so while the facets sound spiffy/etc.,
hopefully they would be an alternative and not a replacement.)

Goktug's idea of shipping servlets is pretty intriguing, in terms of
getting Jetty out of GWT core all together; I think the only complexity
would be conditionally mangling the web.xml for dev vs. prod mode (e.g.
I assume we wouldn't want the proposed GWT SuperDevMode servlet in the
web.xml that is deployed to production).

- Stephen