Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jetty8 with maven plugin takes to long to start #140

Closed
GoogleCodeExporter opened this issue Jul 7, 2015 · 13 comments
Closed

jetty8 with maven plugin takes to long to start #140

GoogleCodeExporter opened this issue Jul 7, 2015 · 13 comments

Comments

@GoogleCodeExporter
Copy link

When I run a project with jetty6 configuration everything is ok. But if I 
change to jetty8, the container takes too long to start. 
I have JNDI Support enabled, and my repository location is pointing to a 
network mapped location(like x:\maven\repo).

I moved my repo location to a localhost and disconnected from network an my 
jetty8 started with the same speed as jetty6. I tried to find some 
configuration that I could use to avoid this problem but I had no success.

Steps to reproduce the problem: 
1. LAN enabled
2. Change from jetty6 to Jetty8(with the proper changes to start correctly)
3. Maven repo pointing to a mapped shared folder in network(like x:\maven\repo)
4. Try to start jetty8 and wait 5minutes long

Eclipse version: Eclipse Indigo

Run-Jetty-Run version used: 1.3.3

Windows XP 32bits and Windows 7 32 bits tested.


Additional info.:

I have in my company LAN with proxy authentication via NTLM protocol.


Original issue reported on code.google.com by rafael.h...@gmail.com on 3 May 2012 at 2:00

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

How many jars you have in your maven dependency? 

The Jetty8 have to scan all the jar files to search those "Servlet3" features 
(web-fragment / annotations ... etc ) , 
and it might be a long time if your IO speed is not quick enough. 

Since you are talking the shared folder from your network , 
I think that's the root-cause and there's nothing to do.

Original comment by tonylovejava on 4 May 2012 at 2:53

@GoogleCodeExporter
Copy link
Author

I Agree. But in Jetty6 everything is pretty fast, no issues. I thought it
could be some validation that is delaying my app.

Original comment by rafael.h...@gmail.com on 4 May 2012 at 2:56

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

Jetty 6 didn't support Servlet3 features, so it need not to scan the content of 
all the jar files.That's the reason for why it's faster.

Jetty8 have to do a "content" scan for searching web-fragment.xml/annotations,
but Jetty6 not.

Original comment by tonylovejava on 4 May 2012 at 3:36

@GoogleCodeExporter
Copy link
Author

You can add metadata-complete="true" to your web.xml web-app definition to 
avoid scanning and initialize faster.
Here's my example:

<web-app id="apalabrados" version="2.4"
    xmlns="http://java.sun.com/xml/ns/j2ee" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
  http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd"
  metadata-complete="true">

Original comment by gonz...@gmail.com on 14 Jun 2012 at 2:51

@GoogleCodeExporter
Copy link
Author

Thank you. Adding metadata-complete=true makes my application run like hell.

Thank you again gonz...@gmail.com

Original comment by rafael.h...@gmail.com on 15 Jun 2012 at 11:26

@GoogleCodeExporter
Copy link
Author

That's a good suggestion , I will list it in the document.

Original comment by tonylovejava on 15 Jun 2012 at 4:05

@GoogleCodeExporter
Copy link
Author

adding metadata-complete sometimes doesn't help, there's a bug filed about it:

https://jira.codehaus.org/browse/JETTY-1503

the solution is to add

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" 
"http://www.eclipse.org/jetty/configure.dtd">

<Configure class="org.eclipse.jetty.webapp.WebAppContext">
<Call name="setAttribute">
<Arg>org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern</Arg>
<Arg>.*/.*jsp-api-[^/]\.jar$|./.*jsp-[^/]\.jar$|./.*taglibs[^/]*\.jar$</Arg>
</Call>
</Configure>

to jetty-context.xml. I'm not sure how to do that for run-jetty-run

Original comment by ja...@sindicetech.com on 11 Apr 2013 at 3:47

@GoogleCodeExporter
Copy link
Author

Here is a workaround for speeding up Jetty 8 with Servlet 3.x.

1. Create a file (jetty.xml)
2. Open a RJR configuration
3. Click on "Show advanced options"
4. Additional Jetty.xml: <location to the jetty.xml file>

The file (jetty.xml) must have these lines:

<Configure id="Server" class="org.eclipse.jetty.server.Server">
  <Get name="handler">
    <Call name="setAttribute">
      <Arg>org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern</Arg>
      <Arg>.*/mwa-web-.*\.jar$</Arg>
    </Call>
  </Get>
</Configure>

Here, I'm telling Jetty that any file starting with mwa-web-* should be scanned 
for Servlet 3.x.

As I said, this is a workaround. It will be nice if we can set the 
`webInfIncludeJarPattern` regex from RJR configuration dialog.

Thanks

edgar

Original comment by espina.e...@gmail.com on 27 Oct 2013 at 12:55

Attachments:

@GoogleCodeExporter
Copy link
Author

Whoa! I already use jetty.xml and this workaround will fit great in my
projects.
Thank you.

Yours faithfully,

Rafael Pereira

Systems Analyst Architect
Em 26/10/2013 22:56, <run-jetty-run@googlecode.com> escreveu:

Original comment by rafael.h...@gmail.com on 27 Oct 2013 at 1:10

@xzer
Copy link
Owner

xzer commented Feb 5, 2016

Close this issue since it is not the bug of rjr and there is a workaround.

@xzer xzer closed this as completed Feb 5, 2016
@cor3000
Copy link

cor3000 commented Jul 6, 2017

I just discovered this system property rjrDisableannotation which seems to speedup startup significantly:

-DrjrDisableannotation=true

not sure why this is not documented ... just thought I'd mention it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants