Re: [jetty-users] Jetty OSGI with JSP support - Missing Constraint
09301215 > 160ACTIVE org.eclipse.osgi.services_3.3.100.v20130513-1956 > 161ACTIVE org.eclipse.osgi.util_3.2.300.v20130513-1956 > 162ACTIVE org.eclipse.equinox.console_1.0.100.v20130429-0953 > 184ACTIVE com.neatherweb.automate.webtest_1.0.0.qualifier > 262ACTIVE javax.servlet.jsp-api_2.3.1 > 263ACTIVE org.eclipse.jetty.servlet_9.1.0.v20131115 > 264ACTIVE org.eclipse.jetty.webapp_9.1.0.v20131115 > 265ACTIVE javax.servlet-api_3.1.0 > 266ACTIVE > org.apache.taglibs.standard.glassfish_1.2.0.v201112081803 > 267ACTIVE org.eclipse.jetty.http_9.1.0.v20131115 > 268ACTIVE org.glassfish.web.javax.servlet.jsp_2.3.2 > 269ACTIVE > org.eclipse.jdt.core.compiler.batch_3.8.2.v20130121-145325 > 270ACTIVE org.eclipse.jetty.deploy_9.1.0.v20131115 > 272ACTIVE org.eclipse.jetty.io_9.1.0.v20131115 > 273ACTIVE org.eclipse.jetty.security_9.1.0.v20131115 > 274ACTIVE com.sun.el.javax.el_3.0.0 > 275ACTIVE org.eclipse.jetty.util_9.1.0.v20131115 > 276ACTIVE org.eclipse.jetty.xml_9.1.0.v20131115 > 278ACTIVE javax.servlet.jsp.jstl_1.2.0.v201105211821 > 279ACTIVE org.eclipse.jetty.server_9.1.0.v20131115 > 280ACTIVE javax.servlet_3.0.0.v201112011016 > 281ACTIVE javax.servlet.jsp_2.2.0.v201112011158 > 284ACTIVE org.eclipse.jetty.osgi.boot_9.1.0.v20131115 > Fragments=285 > 285RESOLVEDorg.eclipse.jetty.osgi.boot.jsp_9.1.0.v20131115 > Master=284 > osgi> > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] WAR overlays in Jetty 9.1?
Klaus, I've made some changes to jetty that should facilitate injection. If Weld apply those changes that were submitted to bring their code up to jetty-9 api, then the changes I've made should ensure listeners get injected too. If you have a local checkout of Weld, and you've applied the patch for the new jetty-9 Decorator class signature, then can you test with head of jetty-9 master??? cheers Jan On 7 December 2013 00:43, Klaus Brunner wrote: > 2013/12/6 Jan Bartel : >> Thanks for the test webapp. You'll need to declare your >> test.ContextListener in a web.xml to test. >> Even doing that, weld still need to apply this patch: >> https://github.com/weld/core/pull/431 to bring their impl up-to-date >> with the jetty-9.1 api. > > Sure, I did all that locally. Injection works, just not in the > ServletContextListener. > >> Its very late here, but I'll give some thought over the weekend to a >> better way that weld may be able to use to ensure that Listeners would >> be able to be injected when running in jetty. > > Thanks, sounds good! > > Klaus > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty OSGI with JSP support - Missing Constraint
ACTIVE com.neatherweb.automate.A4623.impl_1.0.0.qualifier > 34ACTIVE org.apache.felix.gogo.command_0.10.0.v201209301215 > 160ACTIVE org.eclipse.osgi.services_3.3.100.v20130513-1956 > 161ACTIVE org.eclipse.osgi.util_3.2.300.v20130513-1956 > 162ACTIVE org.eclipse.equinox.console_1.0.100.v20130429-0953 > 184ACTIVE com.neatherweb.automate.webtest_1.0.0.qualifier > 262ACTIVE javax.servlet.jsp-api_2.3.1 > 263ACTIVE org.eclipse.jetty.servlet_9.1.0.v20131115 > 264ACTIVE org.eclipse.jetty.webapp_9.1.0.v20131115 > 265ACTIVE javax.servlet-api_3.1.0 > 266ACTIVE > org.apache.taglibs.standard.glassfish_1.2.0.v201112081803 > 267ACTIVE org.eclipse.jetty.http_9.1.0.v20131115 > 268ACTIVE org.glassfish.web.javax.servlet.jsp_2.3.2 > 269ACTIVE > org.eclipse.jdt.core.compiler.batch_3.8.2.v20130121-145325 > 270ACTIVE org.eclipse.jetty.deploy_9.1.0.v20131115 > 272ACTIVE org.eclipse.jetty.io_9.1.0.v20131115 > 273ACTIVE org.eclipse.jetty.security_9.1.0.v20131115 > 274ACTIVE com.sun.el.javax.el_3.0.0 > 275ACTIVE org.eclipse.jetty.util_9.1.0.v20131115 > 276ACTIVE org.eclipse.jetty.xml_9.1.0.v20131115 > 278ACTIVE javax.servlet.jsp.jstl_1.2.0.v201105211821 > 279ACTIVE org.eclipse.jetty.server_9.1.0.v20131115 > 280ACTIVE javax.servlet_3.0.0.v201112011016 > 281ACTIVE javax.servlet.jsp_2.2.0.v201112011158 > 284ACTIVE org.eclipse.jetty.osgi.boot_9.1.0.v20131115 > Fragments=285 > 285RESOLVEDorg.eclipse.jetty.osgi.boot.jsp_9.1.0.v20131115 > Master=284 > osgi> > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > > -- > Jan Bartel > www.webtide.com > 'Expert Jetty/CometD developer,production,operations advice' > > ___ jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > ___ jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty OSGI with JSP support - Missing Constraint
And I see why you got an old version of the jetty-schemas.jar file - the
jetty-distribution build is still pointing at version 3.1.RC0 of that jar,
which doesn't contain the proper manifest added in 3.1.M0. As the
jetty-distro doesn't need the manifest in any way, that wasn't noticed.
I've corrected the build now to make sure its using 3.1.M0 of
jetty-schemas.jar
Jan
On 12 December 2013 15:44, Jan Bartel wrote:
> Hi Jason et al,
>
> Sorry, my bad again for not updating the jetty documentation.
>
> The jar you need is downloadable here:
> http://central.maven.org/maven2/org/eclipse/jetty/toolchain/jetty-jsp-fragment/2.3.3/
>
> This jar has all of the necessary glassfish jsp classes, including
> ResourceInjector and the JDTJavaCompiler class, along with an osgi manifest
> that attaches it as a fragment to the org.eclipse.jetty.osgi.boot bundle.
>
> So you should have these jsp-related bundles installed, in addition to the
> org.eclipse.jetty.osgi/jetty-osgi-boot/9.1.0.v2013111 bundle (and the jetty
> bundles listed under "General Setup" on
> http://www.eclipse.org/jetty/documentation/current/framework-jetty-osgi.html
> ):
>
> javax.servlet.jsp/javax.servlet.jsp-api/2.3.1
> org.eclipse.jetty.orbit/javax.servlet.jsp.jstl/1.2.0.v201105211821
>
>
> org.eclipse.jetty.orbit/org.apache.taglibs.standard.glassfish/1.2.0.v201112081803
> org.glassfish/javax.el/3.0.0
> org.eclipse.jetty.orbit/org.eclipse.jdt.core/3.8.2.v20130121
> org.eclipse.jetty.toolchain/jetty-jsp-fragment/2.3.3
> org.eclipse.jetty.osgi/jetty-osgi-boot-jsp/9.1.0.v2013111
>
> I'll update the documentation.
>
> Also, please double-check that you have version 3.1 of the servlet-api
> deployed NOT version 3.0, and the jetty-toolchain jetty-schemas 3.1.M0 jar.
> So should be:
>
> javax.servlet/javax.servlet-api/jar/3.1.0
> org.eclipse.jetty.toolchain/jetty-schemas/3.1.M0
>
> That version of the jetty-schemas jar has the correct export statements in
> its manifest.
>
> So, in short, I think I've wasted a bunch of your time by simply
> forgetting to update the jetty-osgi doco for jsp - sorry about that!
>
> Jan
>
>
>
> On 12 December 2013 03:31, Jason wrote:
>
>> Thanks Joakim, that set me on the right trail.
>>
>> I found that org.eclipse.jetty.osgi.boot.jsp fragment activator set
>> org.apache.jasper.compiler.disablejsr199=true
>>
>> //jsr199 compilation does not work in osgi
>> System.setProperty("org.apache.jasper.compiler.disablejsr199",
>> Boolean.TRUE.toString());
>>
>> So I followed through expecting it would need to find both,
>> org.eclipse.jdt.internal.compiler.Compiler and
>> org.apache.jasper.compiler.JDTJavaCompiler
>> I found that the .jasper.compiler.JDTJavaCompiler was not in the
>> org.glassfish.web.javax.servlet.jsp bundle, but in a separate JAR in Jetty
>> lib/jetty-jsp-jdt-2.3.3.jar
>> I also found that the jdt packages were not imported by
>> org.glassfish.web.javax.servlet.jsp
>> (they are exported by org.eclipse.jdt.core.compiler.batch).
>> Adding jetty-jsp-jdt-2.3.3.jar to OSGI, and fixing the jdt imports on
>> org.glassfish.web.javax.servlet.jsp
>> left me with another problem ...
>> I got a class not found for org.glassfish.jsp.api.ResourceInjector. To
>> fix this I added org.glassfish.jsp.api to the imports of
>> org.eclipse.jetty.webapp
>>
>>
>> Then success !!
>>
>> There was a fair bit of messing around so I'll check over the next few
>> days to see if I captured everything as a reference.
>>
>> Thanks all for the input
>> J
>>
>> --
>> Date: Tue, 10 Dec 2013 05:48:37 -0700
>> From: joa...@intalio.com
>>
>> To: jetty-users@eclipse.org
>> Subject: Re: [jetty-users] Jetty OSGI with JSP support - Missing
>> Constraint
>>
>> PWC63449: Cannot find a java compiler for compilation
>>
>> Here's the Jasper logic is to find a compiler it can use.
>>
>> If you do nothing, and rely on defaults, then
>> org.eclipse.jdt.internal.compiler.Compiler is used (if found)
>> But if you specify
>> System.setProperty("org.apache.jasper.compiler.disablejsr199","false"),
>> then the JDK built-in compiler is used (Jasper looks for "javax.tools.Tool"
>> class),
>> Next, if neither of those are found, the
>> "org.apache.tools.ant.taskdefs.Javac" is looked for.
>> Finally, if none are found, it throws that error.
>>
>> I don't use OSGi myself, so I don't know what you need to do, but maybe
>> this little i
Re: [jetty-users] Jetty OSGI with JSP support - Missing Constraint
Stuart,
Do you have any older jsp or servlet-api jars in the dependencies of
your webapp? Also double-check the version of the jetty-maven-plugin -
if its not correct, then maven falls back to some really old version.
BTW the non-osgi jsp impl jar will always use a full JDK and thus
expect to find a compiler in the jvm. It doesn't fall back to the jdt
compiler.
thanks
Jan
On 11 December 2013 04:56, Stuart Belden wrote:
> I have this same issue, but not in a OSGi container: I'm running via the
> maven jetty plugin.
>
> Only change was going from Jetty 9.0.6.v20130930 to 9.1.0.v2013111. I am
> definitely running on a JDK, Oracle 7u45. Adding
> -Dorg.apache.jasper.compiler.disablejsr199=false doesn't seem to work
> either. Anyone else seen this?
>
> (apologies for the wonky email thread, I just subscribed to this list).
>
> For context:
> ---
>
> PWC63449: Cannot find a java compiler for compilation
>
> Here's the Jasper logic is to find a compiler it can use.
>
> If you do nothing, and rely on defaults, then
> org.eclipse.jdt.internal.compiler.Compiler is used (if found)
> But if you specify
> System.setProperty("org.apache.jasper.compiler.disablejsr199","false"), then
> the JDK built-in compiler is used (Jasper looks for "javax.tools.Tool"
> class),
> Next, if neither of those are found, the
> "org.apache.tools.ant.taskdefs.Javac" is looked for.
> Finally, if none are found, it throws that error.
>
> I don't use OSGi myself, so I don't know what you need to do, but maybe this
> little insight into the process will help you address it directly.
>
>
> _______
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] WAR overlays in Jetty 9.1?
Klaus,
OK. So lets confirm that the normal jetty Decorators are being called
for your test.ContextListener. Please add the following code snippet
to it:
@PostConstruct
private void myPostConstructMethod ()
{
System.err.println("POST CONSTRUCT ON LISTENER CALLED");
}
The method annotated with @PostConstruct will be called back by the
org.eclipse.jetty.plus.webapp.PlusDecorator. If you see the output,
then jetty's Decorator mechanism is working fine for listeners. As I
understand it, Weld adds in another Decorator to do its magic, so this
test will at least confirm that Decorators are being called. If you
see the output, then there must be something else in Weld that is not
working for listeners.
thanks
Jan
On 12 December 2013 19:33, Klaus Brunner wrote:
> 2013/12/12 Jan Bartel :
>> If you have a local checkout of Weld, and you've applied the patch for
>> the new jetty-9 Decorator class signature, then can you test with head
>> of jetty-9 master???
>
> I just tried it, and I'm afraid nothing changed (injection works in
> servlets and filters, but not the ContextListener). I'll see if I can
> take a more detailed look at it today.
>
> FWIW, here's the output (the "ugh" line comes right out of my test app):
>
> klaus@klaus-nb:/opt/jetty-distribution-9.1.1-SNAPSHOT$ java -jar start.jar
> 2013-12-12 08:13:04.404:INFO:oejs.Server:main: jetty-9.1.1-SNAPSHOT
> 2013-12-12 08:13:04.426:INFO:oejdp.ScanningAppProvider:main:
> Deployment monitor
> [file:/opt/jetty-distribution-9.1.1-SNAPSHOT/webapps/] at interval 1
> Dec 12, 2013 8:13:04 AM org.jboss.weld.bootstrap.WeldStartup
> INFO: WELD-000900: 2.2.0 (2013-12-05 14:19)
> Dec 12, 2013 8:13:05 AM
> org.jboss.weld.environment.servlet.BeanManagerResourceBindingListener
> contextInitialized
> INFO: BeanManager reference bound to java:comp/env/BeanManager
> Dec 12, 2013 8:13:05 AM org.jboss.weld.bootstrap.WeldStartup startContainer
> INFO: WELD-000101: Transactional services not available. Injection of
> @Inject UserTransaction not available. Transactional observers will be
> invoked synchronously.
> Dec 12, 2013 8:13:05 AM
> org.jboss.weld.environment.jetty.JettyContainer initialize
> INFO: Jetty 7.2+ detected, CDI injection will be available in
> Listeners, Servlets and Filters.
> Dec 12, 2013 8:13:05 AM
> org.jboss.weld.interceptor.util.InterceptionTypeRegistry
> WARN: WELD-001700: Interceptor annotation class javax.ejb.PostActivate
> not found, interception based on it is not enabled
> Dec 12, 2013 8:13:05 AM
> org.jboss.weld.interceptor.util.InterceptionTypeRegistry
> WARN: WELD-001700: Interceptor annotation class javax.ejb.PrePassivate
> not found, interception based on it is not enabled
> ugh! injection into test.ContextListener failed!
> 2013-12-12 08:13:05.850:INFO:oejsh.ContextHandler:main: Started
> o.e.j.w.WebAppContext@17eba425{/cditest,file:/tmp/jetty-0.0.0.0-8080-cditest.war-_cditest-any-410754278095988835.dir/webapp/,AVAILABLE}{/cditest.war}
> 2013-12-12 08:13:05.874:INFO:oejs.ServerConnector:main: Started
> ServerConnector@a0e0ab9{HTTP/1.1}{0.0.0.0:8080}
>
>
> Thanks
>
> Klaus
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] WAR overlays in Jetty 9.1?
e call to contextInitialized(), and then goes on to >do some container-specific setup. That's too late to be able to inject >a listener, as the listeners are clearly already being called back >during their startup sequence! Jetty injects listeners just after >they are created. So, even though I've delayed the injection of listeners until just before they will be called back, the basic problem still stands: once the ServletContextListeners have started to be called back, it is way too late to try to execute code that should affect listeners (ie inject them). The approach that will work is to make the Weld/jetty integration a ServletContainerInitializer. They are guaranteed to be called back before any application code, and can thus do whatever setup is necessary. Even better, with Jetty we can guarantee the order that ServletContainerInitializers are called - which is not something the spec addresses - so we can ensure that the Weld SCI is the first to be called. I will look into the existing org.jboss.weld.environment.servlet.Listener and see if I can come up with some code as a SCI instead. So to sum up, can you do a fresh git pull on the jetty repo and full build to make sure you've got the latest code, and then put in those new Throwable().printStackTrace() calls where I suggested and report back your findings? Meanwhile, I'll investigate turning the Weld Listener in to a Weld ServletContainerInitializer. cheers Jan On 13 December 2013 00:59, Klaus Brunner wrote: > 2013/12/12 Jan Bartel : >> The method annotated with @PostConstruct will be called back by the >> org.eclipse.jetty.plus.webapp.PlusDecorator. If you see the output, >> then jetty's Decorator mechanism is working fine for listeners. As I >> understand it, Weld adds in another Decorator to do its magic, so this >> test will at least confirm that Decorators are being called. If you >> see the output, then there must be something else in Weld that is not >> working for listeners. > > The postConstruct is duly called, but that's before the whole > Jetty/Weld integration code is ever run (which is bootstrapped using > their own listeners): > > klaus@klaus-dellnb:/opt/jetty-distribution-9.1.1-SNAPSHOT$ java -jar start.jar > 2013-12-12 14:38:43.418:INFO:oejs.Server:main: jetty-9.1.1-SNAPSHOT > 2013-12-12 14:38:43.446:INFO:oejdp.ScanningAppProvider:main: > Deployment monitor > [file:/opt/jetty-distribution-9.1.1-SNAPSHOT/webapps/] at interval 1 > Dec 12, 2013 2:38:43 PM org.jboss.weld.bootstrap.WeldStartup > INFO: WELD-000900: 2.2.0 (2013-12-05 14:19) > POST CONSTRUCT ON LISTENER CALLED test.ContextListener@744f45c > Dec 12, 2013 2:38:44 PM > org.jboss.weld.environment.servlet.BeanManagerResourceBindingListener > contextInitialized > INFO: BeanManager reference bound to java:comp/env/BeanManager > Dec 12, 2013 2:38:44 PM org.jboss.weld.bootstrap.WeldStartup startContainer > INFO: WELD-000101: Transactional services not available. Injection of > @Inject UserTransaction not available. Transactional observers will be > invoked synchronously. > Dec 12, 2013 2:38:44 PM > org.jboss.weld.environment.jetty.JettyContainer initialize > INFO: Jetty 7.2+ detected, CDI injection will be available in > Listeners, Servlets and Filters. > Dec 12, 2013 2:38:45 PM > org.jboss.weld.interceptor.util.InterceptionTypeRegistry > WARN: WELD-001700: Interceptor annotation class javax.ejb.PostActivate > not found, interception based on it is not enabled > Dec 12, 2013 2:38:45 PM > org.jboss.weld.interceptor.util.InterceptionTypeRegistry > WARN: WELD-001700: Interceptor annotation class javax.ejb.PrePassivate > not found, interception based on it is not enabled > ugh! injection into test.ContextListener failed! > > My understanding is that the Weld bootstrapping code should be > executed before my own Listener is even instantiated (or at least > immediately after that) so that injection can take place, but I have > no idea how such ordering could be ensured in Jetty. > > BTW, I noticed that if I have my ContextListener both annotated as a > WebListener *and* referenced in the web.xml, postConstruct is called > several times (twice on the same instance apparently, and once on > another instance). This seems to be a bug, or at least it's not what > I'd expect: > > 2013-12-12 13:12:43.300:INFO:oejdp.ScanningAppProvider:main: > Deployment monitor > [file:/opt/jetty-distribution-9.1.1-SNAPSHOT/webapps/] at interval 1 > Dec 12, 2013 1:12:43 PM org.jboss.weld.bootstrap.WeldStartup > INFO: WELD-000900: 2.2.0 (2013-12-05 14:19) > POST CONSTRUCT ON LISTENER CALLED test.ContextListener@4bd38cb3 > POST CONSTRUCT ON LISTENER CALLED test.ContextListener@744f45c > POST CONSTRUCT ON LISTENER CALLED test.ContextListener@
Re: [jetty-users] WAR overlays in Jetty 9.1?
Hi Klaus,
I've made some more mods to Jetty - this time to make sure that
ServletContainerInitializers are definitely going to be called before
any injection happens on any listeners.
I've also implemented a ServletContainerInitializer that does the same
thing as the org.jboss.weld.environment.servlet.Listener to set up the
weld framework. Using it, I can definitely get your test context
listener injected just fine:
2013-12-13 16:07:03.785:INFO:oejs.Server:main: jetty-9.1.1-SNAPSHOT
Dec 13, 2013 4:07:03 PM org.jboss.weld.bootstrap.WeldStartup
INFO: WELD-000900: 2.2.0 (2013-12-13 12:20)
Dec 13, 2013 4:07:04 PM
org.jboss.weld.environment.servlet.WeldServletContainerInitializer
onStartup
INFO: WeldServletContainerInitializer onStartup called
Dec 13, 2013 4:07:04 PM org.jboss.weld.bootstrap.WeldStartup startContainer
INFO: WELD-000101: Transactional services not available. Injection of
@Inject UserTransaction not available. Transactional observers will be
invoked synchronously.
Dec 13, 2013 4:07:04 PM
org.jboss.weld.environment.jetty.JettyContainer initialize
INFO: Jetty 7.2+ detected, CDI injection will be available in
Listeners, Servlets and Filters.
Dec 13, 2013 4:07:04 PM
org.jboss.weld.interceptor.util.InterceptionTypeRegistry
WARN: WELD-001700: Interceptor annotation class javax.ejb.PostActivate
not found, interception based on it is not enabled
Dec 13, 2013 4:07:04 PM
org.jboss.weld.interceptor.util.InterceptionTypeRegistry
WARN: WELD-001700: Interceptor annotation class javax.ejb.PrePassivate
not found, interception based on it is not enabled
1st POST CONSTRUCT ON LISTENER CALLED test.ContextListener@6b66187b
Dec 13, 2013 4:07:05 PM
org.jboss.weld.environment.servlet.BeanManagerResourceBindingListener
contextInitialized
INFO: BeanManager reference bound to java:comp/env/BeanManager
2013-12-13 16:07:05.147:INFO:oejsh.ContextHandler:main: Started
o.e.j.m.p.JettyWebAppContext@63fd1f47{/,file:/home/janb/src/tmp/bug-423361/cditest/src/main/webapp/,AVAILABLE}{file:/home/janb/src/tmp/bug-423361/cditest/src/main/webapp/}
2013-12-13 16:07:05.148:WARN:oejsh.RequestLogHandler:main: !RequestLog
2013-12-13 16:07:05.168:INFO:oejs.ServerConnector:main: Started
ServerConnector@5eb7c06f{HTTP/1.1}{0.0.0.0:8080}
[INFO] Started Jetty Server
Here's the link to the repo I did the Weld changes in:
https://github.com/jetty-project/weld-core
I have opened a pull request on the Weld project for it:
https://github.com/weld/core/pull/435
If you want to test this, then clone my weld repo, build it. Then
update and build your jetty repo. In your cditest application, take
out the org.jboss.weld.environment.servlet.Listener from your web.xml,
as jetty will find the weld ServletContainerInitializer automatically.
cheers
Jan
On 13 December 2013 10:36, Jan Bartel wrote:
> Hi Klaus,
>
> There's something pretty funky going on in your environment ;) The
> @WebListener handler has code in there to check to see if the class
> that it is on has already been defined somewhere else (eg web.xml) and
> it does not create another instance if so (see
> https://github.com/eclipse/jetty.project/blob/master/jetty-annotations/src/main/java/org/eclipse/jetty/annotations/WebListenerAnnotation.java#L89).
> In my own testing by modifying your cditest webapp, I have kept the
> @WebListener annotation on test.ContextListener and also the
> definition in web.xml and I only see 1 output of the @PostConstruct (I
> added a debug line in the @WebListener handler that shows the check
> for the duplicate class name, which in this case is found in web.xml):
>
> janb@smidge:
> ~/src/jetty-eclipse/jetty-9/jetty-distribution/target/distribution/demo-base
> (master)
> [2139] java -jar ../start.jar
> 2013-12-13 09:24:26.203:WARN::main: demo test-realm is deployed. DO
> NOT USE IN PRODUCTION!
> 2013-12-13 09:24:26.207:INFO:oejs.Server:main: jetty-9.1.1-SNAPSHOT
> 2013-12-13 09:24:26.227:INFO:oejdp.ScanningAppProvider:main:
> Deployment monitor
> [file:/home/janb/src/jetty-eclipse/jetty-9/jetty-distribution/target/distribution/demo-base/webapps/]
> at interval 1
> Dec 13, 2013 9:24:26 AM org.jboss.weld.bootstrap.WeldStartup
> INFO: WELD-000900: 2.1.0 (Final)
> @WebListener checking for existing definition for test.ContextListener:WebXml
> POST CONSTRUCT ON LISTENER CALLED test.ContextListener@42538425
> Dec 13, 2013 9:24:27 AM
> org.jboss.weld.environment.servlet.BeanManagerResourceBindingListener
> contextInitialized
> INFO: BeanManager reference bound to java:comp/env/BeanManager
> Dec 13, 2013 9:24:27 AM org.jboss.weld.bootstrap.WeldStartup startContainer
> INFO: WELD-000101: Transactional services not available. Injection of
> @Inject UserTransaction not available. Transactional observers will be
> invoked synchronously.
> Dec 13, 2013 9:24:27 AM
> org.jboss.weld.environment.jetty.JettyContainer i
Re: [jetty-users] [Jetty 8] Deadlock in JDBCSessionManager
gt; org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:159) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) > at org.eclipse.jetty.server.Server.handle(Server.java:370) > at > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494) > at > org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982) > at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865) > at > org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) > at > org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) > at java.lang.Thread.run(Thread.java:744) > > "qtp235217511-128": > at > org.eclipse.jetty.server.session.JDBCSessionManager.invalidateSession(JDBCSessionManager.java:621) > - waiting to lock <0xc4f29a38> (a > no.posten.dpost.jetty.config.DpostJDBCSessionManager) > at > org.eclipse.jetty.server.session.JDBCSessionIdManager.invalidateAll(JDBCSessionIdManager.java:503) > - locked <0xc4e3aaa8> (a java.util.HashSet) > at > org.eclipse.jetty.server.session.JDBCSessionManager.removeSession(JDBCSessionManager.java:729) > at > org.eclipse.jetty.server.session.AbstractSession.invalidate(AbstractSession.java:335) > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Files in webapp temp dir (in /tmp) were deleted by tmpwatch
Hi,
You can configure the temp dir for your webapps using
wepappcontext.settempdir method (forgive poor camel case, I'm typing this
on my mobile).
Regards,
Jan
On 21/01/2014 4:50 PM, "Zen Zhong" wrote:
> Hi,
>
> On our staging environment (CentOS 6, jetty-9.1.0), I found this issue
> before and I set up auditd, and this time, I found the command deleted the
> important files, it's tmpwatch. I've added "-X '/tmp/jetty*'" in
> /etc/cron.daily/tmpwatch as a workaround for now.
>
> Maybe it's better to put webapp temp dir in ${jetty.home}.
>
> Thanks
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Embedded Jetty with Annotations and Jersey gets IncompatibleClassChangeError
Hi Jim,
Which version of jetty and which version of jersey are you using?
Jetty-9.1.1 certainly uses asm 4.1. If there are any other asm
versions on the classpath then that would be a problem - double check
that you have removed all other asm jars, and check that that the
remaining jars don't have asm classes inside them.
You may be able to upgrade the version of jersey to one that uses asm4?
Other things you could potentially try are messing around with the
system/server classpath settings on jetty :
http://www.eclipse.org/jetty/documentation/current/jetty-classloading.html
Jan
On 23 January 2014 09:10, Jim Garrison wrote:
> I tried to use the information at
> http://www.eclipse.org/jetty/documentation/current/using-annotations-embedded.html
> but on startup I get a bunch of exceptions during annotation processing.
>
>
>
> 2014-01-22 13:53:04.872:WARN:oejut.QueuedThreadPool:qtp1193472379-16:
>
> java.lang.IncompatibleClassChangeError: class
> org.eclipse.jetty.annotations.AnnotationParser$MyClassVisitor has interface
> org.objectweb.asm.ClassVisitor as super class
>
>at java.lang.ClassLoader.defineClass1(Native Method)
>
>at java.lang.ClassLoader.defineClass(ClassLoader.java:792)
>
>at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>
>at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>
>at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>
>at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>
>at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>
>at java.security.AccessController.doPrivileged(Native Method)
>
>at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>
>at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>
>at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>
>at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
>at
> org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:971)
>
>at
> org.eclipse.jetty.annotations.AnnotationParser.parseJarEntry(AnnotationParser.java:953)
>
>at
> org.eclipse.jetty.annotations.AnnotationParser.parseJar(AnnotationParser.java:906)
>
>at
> org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:828)
>
>at
> org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:111)
>
>at
> org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:472)
>
>at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607)
>
>at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536)
>
>at java.lang.Thread.run(Thread.java:724)
>
>
>
> Examining the transitive dependencies I found
>
>
>
>asm-all-repackaged-2.2.0-b21.jar
>
>asm-4.1.jar
>
>asm-commons-4.1.jar
>
>asm-tree-4.1.jar
>
>
>
> with asm-all-repackaged-2.2.0-b21 coming from
> jersey-container-jetty-servlet. Examining the sources I find that indeed,
> org.objectweb.asm.ClassVisitor changed from an interface in 2.2.0 to an
> abstract class in 4.1.
>
>
>
> However, I still get the error even after removing
> asm-all-repackaged-2.2.0-b21.jar from the jetty classpath.
>
>
>
> Here's the Java embedded launcher code:
>
>
>
> import org.eclipse.jetty.server.Server;
>
> import org.eclipse.jetty.webapp.Configuration.ClassList;
>
> import org.eclipse.jetty.webapp.WebAppContext;
>
>
>
> public class JettyLauncher
>
> {
>
> public static void main(String[] args) throws Exception
>
> {
>
> Server server = new Server(8080);
>
> ClassList classlist = ClassList.setServerDefault(server);
>
> classlist.addAfter("org.eclipse.jetty.webapp.FragmentConfiguration",
> "org.eclipse.jetty.plus.webapp.EnvConfiguration",
> "org.eclipse.jetty.plus.webapp.PlusConfiguration");
>
>
> classlist.addBefore("org.eclipse.jetty.webapp.JettyWebXmlConfiguration",
> "org.eclipse.jetty.annotations.AnnotationConfiguration");
>
>
>
> WebAppContext wac = new
> WebAppContext("target/server-0.1.0-SNAPSHOT","/test");
>
> server.setHandler(wac);
>
> server.start();
>
> server.join();
>
> }
>
> }
>
>
>
> Questions:
>
>
>
> 1) Why didn't removing asm-all-repackaged from the classpath make it work?
>
> 2) Is it possible to get Jetty and Jersey to play nice when using
> annotations?
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Upgrading to Jetty 9.1
Stefan, On 29 January 2014 19:19, Stefan Magnus Landrø wrote: > We're using the jdbc session id manager - it allows us to perform deploys > without downtime. The first/last parts identify a hashed version of the > hostname. Btw, performance-wise it sucks (there is lots of synchronization > code in the AbstractSession(Id)Manager) - that's why we're in the process of > writing our own Hazelcast-based session manager from scratch (without all > the synchro code). Using jdbc, we can't do more than 10-20 logins per second > per server, and that will give us problems down the road. Is this referring to jetty-8 or jetty-9? Recently in jetty-9 there was some unnecessary synchronization removed. However, I'm not sure that the synchronization is necessarily the limiting factor here database access tends to be the culprit speedwise, so it would be interesting to know about your environment and what you are observing. You may want to try the jetty mongodb session clustering solution? It would be great to have a Hazelcast-based session implementation - might be a good opportunity to collaborate between your company and Webtide? Jan -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Problem with Jetty >= 9.0.7 and static content
s.SocketChannel[connected > oshut local=/192.168.1.10:8085 remote=/5.5.8.36:52820] > java.lang.IllegalStateException: AsyncContext completed > at > org.eclipse.jetty.server.AsyncContextState.state(AsyncContextState.java:47) > at > org.eclipse.jetty.server.AsyncContextState.complete(AsyncContextState.java:92) > at > org.eclipse.jetty.server.handler.ResourceHandler$1.failed(ResourceHandler.java:527) > at > org.eclipse.jetty.util.IteratingNestedCallback.failed(IteratingNestedCallback.java:60) > at > org.eclipse.jetty.server.HttpOutput$ReadableByteChannelWritingCB.failed(HttpOutput.java:935) > at > org.eclipse.jetty.util.IteratingNestedCallback.failed(IteratingNestedCallback.java:60) > at > org.eclipse.jetty.io.WriteFlusher$PendingState.fail(WriteFlusher.java:259) > at > org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:427) > at > org.eclipse.jetty.io.SelectChannelEndPoint.onSelected(SelectChannelEndPoint.java:111) > at > org.eclipse.jetty.io.SelectorManager$ManagedSelector.processKey(SelectorManager.java:571) > at > org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:542) > at > org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:484) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536) > at java.lang.Thread.run(Thread.java:722) > > Any idea? > > THANKS!! > > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Executing code before and after each request
If you just want to execute code when the request enters the context and then leaves the context after exiting the last servlet/filter, you can use a javax.servlet.ServletRequestListener. If you want to know when the response IO is finished, that's a different matter - doyou leave it up to the container to flush the IO or do you do it in the servlet, or if you do Continuations then see Simone's response. cheers Jan On 11 February 2014 05:37, Simone Bordet wrote: > Hi, > > On Wed, Feb 5, 2014 at 6:32 PM, bubbleguuum wrote: >> Hi, >> >> using Jetty 7, I wonder what is the best way to have code executed for each >> request, >> when the request starts being processed and when processing is finished (the >> response body written fully, or aborted by the client, or any other error). >> >> To illustrate this, suppose that I want to log the start and the end of >> processing of each request. >> >> Initially I though that a Filter would be appropriate, but although I can >> get the start of the request, I cannot get the end as the processing is >> async. >> What would be the best way to do this ? >> >> Alternatively, is there any API that returns the current number of pending >> requests ? > > You said Jetty 7 and async processing. > What do you use for async processing ? > If you use Continuations, then you can implement > ContinuationListener.onComplete(...). > > If you are on Servlet 3 API, there is a similar AsyncListener class. > > -- > Simone Bordet > > http://cometd.org > http://webtide.com > http://intalio.com > Developer advice, training, services and support > from the Jetty & CometD experts. > Intalio, the modern way to build business applications. > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Compiling jsp
pedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:199) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:459) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:280) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:229) > at > org.eclipse.jetty.io.AbstractConnection$1.run(AbstractConnection.java:505) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536) > at java.lang.Thread.run(Thread.java:744) > Caused by: Unable to find a javac compiler; > com.sun.tools.javac.Main is not on the classpath. > Perhaps JAVA_HOME does not point to the JDK > at > org.apache.tools.ant.taskdefs.compilers.CompilerAdapterFactory.getCompiler(CompilerAdapterFactory.java:105) > at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:924) > at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757) > at > org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:382) > > > Googling I found other "solution" proposed, from explicit setting JAVA_HOME > to adding the directory which contains tools.jar to classpath, nothing > worked for me > > The only thing that worked was to copy the file tools.jar from > $JDK/lib/tools.jar to $JDK/jre/lib/ext/tools.jar > > I'm using > > java version "1.7.0_45" > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) > > and jetty 9.1.0 > > Any hint appreciated > > -- > Andrea Cappelli > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] What's wrong with this secureCookie configuration?
(true); >>>>>>> >>>>>>> Seems straight forward enough. >>>>>>> >>>>>>> So here's my new context configuration: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> true >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> But when I start jetty, the context dies with this error in the logs: >>>>>>> oejx.XmlConfiguration:Config error at true >>>>>>> java.lang.NoSuchMethodException: class >>>>>>> org.eclipse.jetty.server.session.AbstractSessionManager$2.setSecure(boolean) >>>>>>> >>>>>>> >>>>>>> Why is it trying to call setSecure on the sessionManager instead of >>>>>>> the sessionManager's sessionCookieConfig? >>>>>>> >>>>>>> Any thoughts? >>>>>>> >>>>>>> Thanks in advance! >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> P.S. this is an x-post of a stack overflow question, so if you want >>>>>>> some karma, you can answer over there: >>>>>>> http://stackoverflow.com/questions/21763824/setting-secure-cookies-on-jetty-6-8-upgrade >>>>>>> >>>>>>> ___ >>>>>>> jetty-users mailing list >>>>>>> jetty-users@eclipse.org >>>>>>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>>>>>> >>>>>> >>>>>> >>>>>> ___ >>>>>> jetty-users mailing list >>>>>> jetty-users@eclipse.org >>>>>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>>>>> >>>>> >>>>> >>>>> ___ >>>>> jetty-users mailing list >>>>> jetty-users@eclipse.org >>>>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>>>> >>>> >>> >>> >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>> >> > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] What's wrong with this secureCookie configuration?
Looks like a bug. It's an anonymous inner class, that is itself public. If I make it a regular inner class, then it works. I've raised: https://bugs.eclipse.org/bugs/show_bug.cgi?id=428157 Looking at it now. Jan On 14 February 2014 12:23, Joakim Erdfelt wrote: > That cannot be set that way. > > The method is found, but Java prevents its invocation. > > 2014-02-13 18:20:13.203:IGNORED:oejx.XmlConfiguration: > java.lang.IllegalAccessException: Class > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration can not access > a member of class org.eclipse.jetty.server.session.AbstractSessionManager$2 > with modifiers "public" > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:109) > at > java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:261) > at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:253) > at java.lang.reflect.Method.invoke(Method.java:599) > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.set(XmlConfiguration.java:574) > > I suspect its because the actual implementation of > javax.servlet.SessionCookieConfig is an internal class that itself isn't > public. > > > -- > Joakim Erdfelt > webtide.com - intalio.com/jetty > Expert advice, services and support from from the Jetty & CometD experts > eclipse.org/jetty - cometd.org > > > On Thu, Feb 13, 2014 at 5:47 PM, Tom Vaughan wrote: >> >> No dice (same error) >> >> Full file: >> >> > "http://www.eclipse.org/jetty/configure.dtd";> >> >> >> >> >> >> true >> >> >> >> >> >> >> >> >> >> /report >> /report/ >> /var/poseur/work_files/report_> name="jetty.port" /> >> >> >> >> >> false >> false >> >> >> >> true >> >> >> >> >> >> >> >> >> On Thu, Feb 13, 2014 at 7:40 PM, Jan Bartel wrote: >>> >>> Try this: >>> >>> >> "http://www.eclipse.org/jetty/configure.dtd";> >>> >>> Jan >>> >>> On 14 February 2014 11:07, Tom Vaughan wrote: >>> > I noticed the "mortbay" instead of "eclipse" reference in the DTD >>> > header, so >>> > I swapped that DTD line out for this: >>> > >>> > >> > "http://jetty.eclipse.org/configure.dtd";> >>> > >>> > And restarted jetty. Same error. >>> > >>> > >>> > >>> > On Thu, Feb 13, 2014 at 7:01 PM, Tom Vaughan >>> > wrote: >>> >> >>> >> This configuration is being done in a $jetty_home/contexts/myApp.xml >>> >> file >>> >> that corresponds to and controls the ../webapps/myApp >>> >> >>> >> Here's the full file >>> >> >>> >> >>> >> >> >> "http://jetty.mortbay.org/configure.dtd";> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> true >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> /report >>> >> /report/ >>> >> >> >> name="tempDirectory">/var/poseur/work_files/report_>> >> name="jetty.port" /> >>> >> >>> >> >>> >> >>> >> >>> >> false >>> >> false >>> >> >>> >> >>> >> >>> >> true >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> On Thu, Feb 13, 2014 at 6:55 PM, Joakim Erdfelt >>> >> wrote: >>> >>> >>> >>> Also, what is the DTD declaration of those XML files? (yes, its >>> >>> important) >>> >>> >>> >>> -- >>> >>> Joakim Erdfelt >>> >>> webtide.com - intalio.com/jetty >>> >>> Expert advice, services and support from from t
Re: [jetty-users] Compiling jsp
Just to confirm: with the standard jetty 9.1.2 distro, using
jre1.7.0_25 and setting
-Dorg.apache.jasper.compiler.disablejsr199=true in start.ini the jsps
compile on-the-fly just fine using the ecj-jdt compiler in lib/jsp.
The relevant code in the jsp implementation looks for the following,
so try printing these out in a servlet to verify their values:
System.getProperty("java.specification.version"));
System.getProperty("org.apache.jasper.compiler.disablejsr199")
//should be true
Class.forName("org.eclipse.jdt.internal.compiler.Compiler", false,
getClass().getClassLoader()); //should load
Class.forName("org.apache.jasper.compiler.JDTJavaCompiler", false,
getClass().getClassLoader()); //should load
Jan
On 15 February 2014 00:31, Andrea Cappelli wrote:
> Il 14/02/2014 14:12, Joakim Erdfelt ha scritto:
>
> Your upstart says ...
>
> JAVA="/usr/lib/jvm/java-1.7.0-oracle/bin/java"
>
> However, Jetty is actually running with ...
>
> java.home = /usr/lib/jvm/jdk1.7.0_45/jre
>
>
> Uhm, you are right, but the 2 installation are the same (there is a symlink)
>
> ls -la /usr/lib/jvm/
>
> lrwxrwxrwx 1 root root11 Nov 25 09:25 java-1.7.0-oracle -> jdk1.7.0_45
> drwxr-xr-x 8 root root 4096 Oct 8 15:03 jdk1.7.0_45
>
>
>
> Also, make sure your upstart configures JAVA_HOME and puts your selection of
> java first on the path (aka PATH=$JAVA_HOME/bin:$PATH)
>
>
> Ok, thank you
>
> --
> Andrea Cappelli
>
>
> ___________
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] An API incompatibility was encountered while executing org.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031
:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/javax.transaction/1.1.1.v201105210645/javax.transaction-1.1.1.v201105210645.jar > [ERROR] urls[21] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/jetty-jndi/8.1.14.v20131031/jetty-jndi-8.1.14.v20131031.jar > [ERROR] urls[22] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/jetty-server/8.1.14.v20131031/jetty-server-8.1.14.v20131031.jar > [ERROR] urls[23] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/javax.servlet/3.0.0.v201112011016/javax.servlet-3.0.0.v201112011016.jar > [ERROR] urls[24] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/jetty-continuation/8.1.14.v20131031/jetty-continuation-8.1.14.v20131031.jar > [ERROR] urls[25] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/javax.mail.glassfish/1.4.1.v201005082020/javax.mail.glassfish-1.4.1.v201005082020.jar > [ERROR] urls[26] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/javax.activation/1.1.0.v201105071233/javax.activation-1.1.0.v201105071233.jar > [ERROR] urls[27] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/jetty-jmx/8.1.14.v20131031/jetty-jmx-8.1.14.v20131031.jar > [ERROR] urls[28] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/jetty-annotations/8.1.14.v20131031/jetty-annotations-8.1.14.v20131031.jar > [ERROR] urls[29] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/javax.annotation/1.1.0.v20110806/javax.annotation-1.1.0.v20110806.jar > [ERROR] urls[30] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/org.objectweb.asm/3.1.0.v200803061910/org.objectweb.asm-3.1.0.v200803061910.jar > [ERROR] urls[31] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/jetty-websocket/8.1.14.v20131031/jetty-websocket-8.1.14.v20131031.jar > [ERROR] urls[32] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/jetty-io/8.1.14.v20131031/jetty-io-8.1.14.v20131031.jar > [ERROR] urls[33] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/jetty-http/8.1.14.v20131031/jetty-http-8.1.14.v20131031.jar > [ERROR] urls[34] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/jetty-jsp/8.1.14.v20131031/jetty-jsp-8.1.14.v20131031.jar > [ERROR] urls[35] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/javax.servlet.jsp/2.2.0.v201112011158/javax.servlet.jsp-2.2.0.v201112011158.jar > [ERROR] urls[36] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/org.apache.jasper.glassfish/2.2.2.v201112011158/org.apache.jasper.glassfish-2.2.2.v201112011158.jar > [ERROR] urls[37] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/javax.servlet.jsp.jstl/1.2.0.v201105211821/javax.servlet.jsp.jstl-1.2.0.v201105211821.jar > [ERROR] urls[38] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/org.apache.taglibs.standard.glassfish/1.2.0.v201112081803/org.apache.taglibs.standard.glassfish-1.2.0.v201112081803.jar > [ERROR] urls[39] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/javax.el/2.2.0.v20110806/javax.el-2.2.0.v20110806.jar > [ERROR] urls[40] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/com.sun.el/2.2.0.v20110806/com.sun.el-2.2.0.v20110806.jar > [ERROR] urls[41] = > file:/C:/Users/TEST/.m2/repository/org/eclipse/jetty/orbit/org.eclipse.jdt.core/3.7.1/org.eclipse.jdt.core-3.7.1.jar > [ERROR] Number of foreign imports: 1 > [ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: > null]] > [ERROR] > [ERROR] - > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException > > > Thanks & Regards, > Shri > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty-9.1.2 - websocket : OSGi packaging issue
=10.0.0))) > > at > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974) > > at org.apache.felix.framework.Felix.startBundle(Felix.java:2037) > > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291) > > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304) > > at java.lang.Thread.run(Thread.java:722) > > > > The list of deployed bundles is: > >ID|State |Level|Name > > 0|Active |0|System Bundle (4.2.1) > > 1|Active |1|Jetty :: Websocket :: javax.websocket :: Client > Implementation (9.1.2.v20140210) > > 2|Installed |1|Jetty :: Websocket :: javax.websocket.server :: > Server Implementation (9.1.2.v20140210) > > 3|Active |1|WebSocket server API (1.0.0) > > 4|Active |1|Jetty :: Asynchronous HTTP Client (9.1.2.v20140210) > > 5|Active |1|Jetty :: Continuation (9.1.2.v20140210) > > 6|Active |1|Jetty :: Deployers (9.1.2.v20140210) > > 7|Active |1|Jetty :: Http Utility (9.1.2.v20140210) > > 8|Active |1|Jetty :: IO Utility (9.1.2.v20140210) > > 9|Active |1|Jetty :: JMX Management (9.1.2.v20140210) > >10|Active |1|Jetty :: Proxy (9.1.2.v20140210) > >11|Active |1|Jetty :: Rewrite Handler (9.1.2.v20140210) > >12|Active |1|Jetty Servlet Schemas (3.1.0.M0) > >13|Active |1|Jetty :: Security (9.1.2.v20140210) > >14|Active |1|Jetty :: Server Core (9.1.2.v20140210) > >15|Active |1|Jetty :: Servlet Handling (9.1.2.v20140210) > >16|Active |1|Jetty :: Utility Servlets and Filters > (9.1.2.v20140210) > >17|Active |1|Jetty :: Utilities (9.1.2.v20140210) > >18|Active |1|Jetty :: Webapp Application Support > (9.1.2.v20140210) > >19|Active |1|Jetty :: XML utilities (9.1.2.v20140210) > >20|Active |1|Apache Felix Bundle Repository (1.6.6) > >21|Active |1|Apache Felix Gogo Command (0.12.0) > >22|Active |1|Apache Felix Gogo Runtime (0.10.0) > >23|Active |1|Apache Felix Gogo Shell (0.10.0) > >24|Active |1|Java Servlet API (3.1.0) > >25|Active |1|Jetty :: Websocket :: API (9.1.2.v20140210) > >26|Active |1|Jetty :: Websocket :: Client (9.1.2.v20140210) > >27|Active |1|Jetty :: Websocket :: Common (9.1.2.v20140210) > >28|Active |1|Jetty :: Websocket :: Server (9.1.2.v20140210) > >29|Active |1|Jetty :: Websocket :: Servlet Interface > (9.1.2.v20140210) > > > > Is there really a packaging issue or did I miss something? > > > > Thanks, > > Yves > > > > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 9.1.2 in OSGi
Mikhail, The jetty p2 bundles haven't ever (AFAIK) contained any of the dependency jars, just the jetty jars themselves. I think this was not a problem in the past because most of the dependency jars we needed were fetchable from orbit or already in the equinox plugins. With the latest versions of jetty, we are using versions of dependencies that are not in Orbit, such as: asm 4.1, and a servlet-3.1 jar. I would try downloading asm 4.1 from maven and installing it manually (see http://repo1.maven.org/maven2/org/ow2/asm/asm/) and also the servlet-3.1 jar ( see http://repo1.maven.org/maven2/javax/servlet/javax.servlet-api/3.1.0/). Then do the install of the latest jetty bundle. Unfortunately we don't have enough volunteers to take on the workload of constantly updating Orbit - any takers on the list Jan On 21 February 2014 15:31, Mikhail Mazursky wrote: > Hello, > > I'm trying to update my OSGi (Equinox-based) distribution from Jetty 9.0.7 > to 9.1.2. The distibution is assembled by maven tycho plugin. I get the > following output: > > Caused by: > org.eclipse.tycho.p2.target.facade.TargetDefinitionResolutionException: No > solution found because the problem is unsatisfiable.: [ > Unable to satisfy dependency from org.eclipse.jetty.annotations > 9.1.2.v20140210 to package org.objectweb.asm [4.1.0,5.0.0).; > Unable to satisfy dependency from org.eclipse.jetty.continuation > 9.1.2.v20140210 to package javax.servlet [3.1.0,4.0.0).; > Unable to satisfy dependency from org.eclipse.jetty.osgi.boot > 9.1.2.v20140210 to package javax.servlet [3.1.0,3.2.0).; > Unable to satisfy dependency from org.eclipse.jetty.osgi.boot > 9.1.2.v20140210 to package javax.servlet.http [3.1.0,3.2.0).; > Unable to satisfy dependency from org.eclipse.jetty.osgi.boot.jsp > 9.1.2.v20140210 to package javax.el [3.0.0,3.1.0).; > Unable to satisfy dependency from org.eclipse.jetty.osgi.boot.jsp > 9.1.2.v20140210 to package javax.servlet [3.1.0,3.2.0).; > Unable to satisfy dependency from org.eclipse.jetty.osgi.boot.jsp > 9.1.2.v20140210 to package javax.servlet.jsp [2.3.0,2.4.0).; > Unable to satisfy dependency from org.eclipse.jetty.osgi.boot.jsp > 9.1.2.v20140210 to package javax.servlet.jsp.el [2.3.0,2.4.0).; > Unable to satisfy dependency from org.eclipse.jetty.osgi.boot.jsp > 9.1.2.v20140210 to package javax.servlet.jsp.resources [3.1.0,3.2.0).; > Unable to satisfy dependency from org.eclipse.jetty.osgi.boot.jsp > 9.1.2.v20140210 to package javax.servlet.jsp.tagext [2.3.0,2.4.0).; > Unable to satisfy dependency from org.eclipse.jetty.osgi.boot.jsp > 9.1.2.v20140210 to package javax.servlet.resources [3.1.0,3.2.0).; > Unable to satisfy dependency from org.eclipse.jetty.osgi.httpservice > 9.1.2.v20140210 to package javax.servlet [3.1.0,4.0.0).; > Unable to satisfy dependency from org.eclipse.jetty.osgi.httpservice > 9.1.2.v20140210 to package javax.servlet.http [3.1.0,4.0.0).; > Unable to satisfy dependency from org.eclipse.jetty.spdy.http.server > 9.1.2.v20140210 to package org.eclipse.jetty.spdy.http [9.0.0,10.0.0).; > Unable to satisfy dependency from org.eclipse.jetty.websocket.server > 9.1.2.v20140210 to package javax.servlet [3.0.0,4.0.0).; > Unable to satisfy dependency from org.eclipse.jetty.websocket.server > 9.1.2.v20140210 to package javax.servlet.http [3.0.0,4.0.0).; > Unable to satisfy dependency from org.eclipse.jetty.websocket.servlet > 9.1.2.v20140210 to package javax.servlet [3.0.0,4.0.0).; > Unable to satisfy dependency from org.eclipse.jetty.websocket.servlet > 9.1.2.v20140210 to package javax.servlet.http [3.0.0,4.0.0).; > No solution found because the problem is unsatisfiable.] > > I'm using the following repositories: > http://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.1.2.v20140210/ > http://download.eclipse.org/releases/kepler/ > http://download.eclipse.org/tools/orbit/downloads/drops/S20140116105218/repository/ > (LATEST ORBIT) > > Looks like the bundles in Orbit repo are too old and cannot satisfy the > dependencies of 9.1.2. > > Maybe someone on the list can help me with this? > > Kind regards, > Mikhail. > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Using MovedContextHandler with the maven-jetty-plugin
Nick, Perhaps having a read of the doco as regards deploying other contexts alongside the webapp that is the subject of the jetty-maven-plugin will help. See http://www.eclipse.org/jetty/documentation/9.0.6.v20130930/jetty-maven-plugin.html, section "Running More than One Webapp". Jan On 25 February 2014 08:02, Nick Watts wrote: > Hello all, > > I want to setup a permanent HTTP redirect in the embedded Jetty server that > I'm using in my Maven build. I'm using Maven 3.0.4 and the > jetty-maven-plugin version 9.0.6.v20130930. The Jetty documentation clearly > demonstrates how to set this up in a non-embedded Jetty instance, but I > can't quite figure out how to to set it up when running inside of Maven. > > Here's the context XML file I'm using to do the redirect from > /permanently-moved-feeds to / > > > "http://www.eclipse.org/jetty/configure_9_0.dtd";> > > > /permanently-moved-feeds > / > true > false > false > > > Here is the relevant Maven pom.xml configuration: > > > org.eclipse.jetty > > jetty-maven-plugin > > > src/main/webapp,src/main/webapp/test-feeds,src/main/webapp/permanently-moved-feeds > > > > src/main/conf/jetty/jetty.xml,src/main/conf/jetty/contexts/PermanentlyMovedRSS.xml,src/main/conf/jetty/jetty-logging.xml > > > > > start-jetty > pre-integration-test > > > run > > > 10 > > true > > > > stop-jetty > > post-integration-test > > stop > > > > > > > So my specific question is how do I configure the jetty-maven-plugin so > that Jetty knows where to find the context XML file in the first XML > sample? When I run mvn jetty:run, I see that the config files I have > specified are loaded but when I do a GET > > for http://localhost:8080/permanently-moved-feeds, the response status code > is 200 instead of 301. Am I approaching this configuration in the right way? > > > > > -- > Nick Watts > blog: thewonggei.wordpress.com > twitter: @thewonggei > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] JDBCSessionManager dirty operations
Cemo,
This will need some refactoring of the implementation of the session
interface, but I'm not opposed to looking into it.
Can you open a bug for this please and assign to me?
thanks
Jan
On 27 February 2014 06:25, Cemo wrote:
> Hi,
>
> Current org.eclipse.jetty.server.session.JDBCSessionManager has
> removeAttribute as this:
>
> public void removeAttribute (String name)
>
> {
> super.removeAttribute(name);
>
>
>
> _dirty=true;
> }
>
>
> This has a side effect because of making dirty for every removing operation.
> This is causing a lot of trouble because each jstl set ( c:set ) call in JSP
> pages is also calling removeAttribute internally. What I am suggesting is
> that something like this:
>
>
>@Override
>public void removeAttribute(String name) {
>
>
>
> synchronized (this){
> Object attribute = getAttribute(name);
>
>
>
> if(attribute != null){
>
>
>
> super.removeAttribute(name);
>
>
>
> _dirty = true;
> }
> }
>}
>
> public
>
>
> https://gist.github.com/cemo/9236abe34d2b126242ad
>
> What do you think?
>
> _______
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] JDBCSessionManager dirty operations
Stefan, Cemo, David,
I agree that it would be a good idea to rewrite the session management
afresh. There's code in there that has been there since jetty-6, maybe
even longer! This isn't going to happen overnight - as with everything
to do with the servlet spec its a complex beastie that requires some
careful thought, and needs to take account of the many different
flavours of session management: persistent/non-persistent,
clustered/non-clustered, and the various technologies: jdbc, mongo etc
etc etc.
The session management code should mostly hold sync locks on a
specific session, rarely over the entire session manager (which will
affect all session ops for a context) or over the entire session id
manager (which can affect all session ops for a server). If you would
like to pinpoint areas where we can look at optimising the locking
strategy (patches are always nice! - see how to contribute here:
http://www.eclipse.org/jetty/documentation/current/advanced-contributing.html),
then that could probably be done fairly quickly.
regards
Jan
On 27 February 2014 21:50, Stefan Magnus Landrø wrote:
> Hi there,
>
> the problem here isn't really the synchronized block itself. The problem is
> that the different synchronization blocks cover lots of remote sql calls (@
> let's say 10ms each). Do the math - you'll notice how few session related
> operations you can do per second per jvm ...
> In my opinion, the jdbc-/(abstract-)session(id)manager code needs a complete
> rewrite.
>
> Stefan
>
>
> 2014-02-27 8:48 GMT+01:00 "" :
>
>> Indeed, tomcat uses a concurrent hash map and no explicit synchronisation
>> when accessing/updating session attributes.
>>
>> And in fact tomcat only uses synchronized in two places, when expiring the
>> session and when fire events to session listeners.
>>
>> Yeah, I hear that synchronisation "is not such an overhead", but then put
>> large load on big multi socket multicore box and watch it completely fail to
>> scale to the available hardware.
>>
>>
>> On 27 February 2014 20:35, "" wrote:
>>>
>>>
>>> Ouch. Just looked at the AbstractSessionManager... Such
>>> synchronisation is the tip of the iceberg.
>>>
>>> I wonder if there really needs to be this amount of synchronisation when
>>> the order of the requests coming in that might affect a session can be quote
>>> arbitrary in themselves. On AbstractSessionManager synchronisation
>>> protection on _attributes is perhaps overkill when a ConcurrentHashMap could
>>> be used instead.
>>>
>>>
>>>
>>>
>>>
>>> On 27 February 2014 20:02, "" wrote:
>>>>
>>>> I don't believe the synchronised block is useful here. Synchronised
>>>> should be used to stop things breaking, not to protect against something
>>>> that is occasionally inefficient.
>>>>
>>>> So this is sufficient and will avoid inconsistent synchronization
>>>> warnings...
>>>>
>>>>@Override
>>>>
>>>>
>>>>
>>>>public void removeAttribute(String name) {
>>>>
>>>>
>>>>
>>>>
>>>> if(getAttribute(name)){
>>>> super.removeAttribute(name);
>>>> _dirty = true;
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>}
>>>>
>>>>
>>>>
>>>>
>>>> On 27 February 2014 10:40, Jan Bartel wrote:
>>>>>
>>>>> Cemo,
>>>>>
>>>>> This will need some refactoring of the implementation of the session
>>>>> interface, but I'm not opposed to looking into it.
>>>>>
>>>>> Can you open a bug for this please and assign to me?
>>>>>
>>>>> thanks
>>>>> Jan
>>>>>
>>>>> On 27 February 2014 06:25, Cemo wrote:
>>>>> > Hi,
>>>>> >
>>>>> > Current org.eclipse.jetty.server.session.JDBCSessionManager has
>>>>> > removeAttribute as this:
>>>>> >
>>>>> > public void removeAttribute (String name)
>>>>> >
>>>>> > {
>>>>> > super.removeAttribute(name);
>>>>> >
>>>>> >
>>>>> >
>>>>> > _dirty=true;
>>>>> > }
>>>>> >
>>>>> >
>>&g
Re: [jetty-users] is hot re-deployment without errors possible?
Robert, Are you sure that the rsync has finished by the time you touch the xml file? Upgrading is generally a good idea :), but I can't think of anything specifically that would affect the hot redeployment (other than the war file not being fully copied). Might be able to comment more if you could post an example of the log messages. cheers Jan On 14 March 2014 02:33, Robert Nikander wrote: > Hi, > > (I posted on stackoverflow first [1] but no answers, so I'll try here.) > > I have the usual web app deployer as described in the docs [2] and defined in > etc/jetty-deploy.xml. I use an xml file to define my web app context, so when > I push new code to my production server, I upload a new myapp.war file using > `rsync` and then touch that myapp.xml file. This works pretty well, but there > are few seconds where the app throws a NullPointerException or other > weirdness, and some users appear to be getting corrupt statically served > files (.js files from the war), so that they have to flush their browser's > cache for the app to work again. > > Is this supposed to work perfectly, or do you expect a brief dead period like > this? Is there a recommended way to deploy new code without the 2-second > snafu? > > Jetty is behind nginx with simple proxy configuration, if that matters. I'm > running 9.0.5, but could upgrade. > > thanks, > Rob > > > [1] > http://stackoverflow.com/questions/22357690/can-jetty-hot-redeployment-work-without-service-interruption > [2] http://www.eclipse.org/jetty/documentation/current/hot-deployment.html > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] is hot re-deployment without errors possible?
Robert,
A 404 seems pretty reasonable. If the connectors are still running,
then the server is still accepting requests. Therefore there is a
small amount of time during which the webapp is stopped, and the
restart has not yet completed, and a request can arrive. During that
period, it is correct that there is no context matching the request.
If you want to avoid a 404 you could deploy a 2nd webapp at the same
context path. When the 1st webapp stops due to the hot update, the 2nd
webapp will answer the request. Normally this 2nd webapp would contain
a static page with a maintenance message, maybe doing an automatic
reload or directing the user to do the reload, and of course turning
off caching. After you've got the 1st webapp redeployed, you can use
jmx to turn off the 2nd webapp, so traffic will flow again to the 1st
webapp.
Jan
On 15 March 2014 00:56, Robert Nikander wrote:
> Upgrading to Jetty 9.1.3 fixed the NullPointerExceptions. But now, instead
> of the 500 error, I get a 404 not found error for a second while the app is
> redeploying. So, my question remains: is that normal, or is re-deployment
> supposed to work seamlessly?
>
> Rob
>
>
> On Mar 14, 2014, at 9:02 AM, Robert Nikander wrote:
>
>> Ah, this may be fixed in newer Jetty versions. I'll try upgrading.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=417475
>>
>> Rob
>>
>> On Mar 14, 2014, at 8:49 AM, Robert Nikander wrote:
>>
>>> Jan,
>>>
>>> I believe the rsync is finished. I use a shell script and and the two
>>> commands are sequential. Here is the script, and some log messages.
>>>
>>> #!/bin/bash
>>> rsync -v myapp.war myserver:/opt/webapps
>>> rsync -v deployment/myapp.xml myserver:/opt/jetty/webapps/
>>>
>>> If I run that, the logs show a stop and start.
>>>
>>> 2014-03-14 12:37:01.706:INFO:oejsh.ContextHandler:Scanner-0: Stopped
>>> o.e.j.w.WebAppContext@358ee631{/myapp,file:/tmp/jetty-0.0.0.0-8080-myapp.war-_myapp-any-/webapp/,UNAVAILABLE}{/myapp.war}
>>> 2014-03-14 12:37:03.644:INFO:oejsh.ContextHandler:Scanner-0: Started
>>> o.e.j.w.WebAppContext@760aa0cd{/myapp,file:/tmp/jetty-0.0.0.0-8080-myapp.war-_myapp-any-/webapp/,AVAILABLE}{/myapp.war}
>>>
>>> I ran the script again, but this time kept reloading a page in the browser,
>>> to trigger an error. Between the stop and the start messages, I see a
>>> bunch of errors like this:
>>>
>>> 2014-03-14 12:37:33.079:WARN:oejs.HttpChannel:qtp121295574-906:
>>> /myapp/static/common/angular/angular-sanitize.min.js
>>> java.lang.NullPointerException
>>> at
>>> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:192)
>>> at
>>> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
>>> at
>>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>>> at
>>> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:317)
>>> at
>>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>>> at org.eclipse.jetty.server.Server.handle(Server.java:445)
>>> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:268)
>>> at
>>> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:229)
>>> at
>>> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
>>> at
>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
>>> at
>>> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
>>> at java.lang.Thread.run(Thread.java:744)
>>>
>>> Rob
>>>
>>>
>>> On Mar 13, 2014, at 10:27 PM, Jan Bartel wrote:
>>>
>>>> Robert,
>>>>
>>>> Are you sure that the rsync has finished by the time you touch the xml
>>>> file?
>>>>
>>>> Upgrading is generally a good idea :), but I can't think of anything
>>>> specifically that would affect the hot redeployment (other than the
>>>> war file not being fully copied).
>>>>
>>>> Might be able to comment more if you could post an example of the log
>>>> messages.
>>>>
>>>> cheers
>>>> Jan
>>>>
>>>> On 14 March 2014 02:33, Robert Nikander wrote:
>>>>> Hi,
>>>>>
>>>
Re: [jetty-users] org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.runtime.ELContextImpl
David, Remove the jsp-related jars from your webapp - they are provided by the servlet container (in this case the jetty runner). regards Jan On 18 March 2014 10:35, David L Gangarapu wrote: > Joakim, > thank you for the reply...Here is the list of files in both war files: > jetty-server-9.1.0.v20131115.jar > jetty-util-9.1.0.v20131115.jar > javax.servlet.jsp-2.3.2.jar > jetty-jsp-jdt-2.3.3.jar > > Thank you. > > David > > > > On Monday, March 17, 2014 4:24 PM, Joakim Erdfelt > wrote: > That specific error usually points to two or more standard EL jars (at > different versions) present in your webapp. > What are your WEB-INF/lib/*.jar files? > > -- > Joakim Erdfelt > webtide.com - intalio.com/jetty > Expert advice, services and support from from the Jetty & CometD experts > eclipse.org/jetty - cometd.org > > > On Mon, Mar 17, 2014 at 4:21 PM, David L Gangarapu > wrote: > > Can someone please help me with the error ( see stack trace below ). > > I have two war files with different contexts and I am trying to run them > using jetty runner. > Each Individual war files get loaded and run well if I rum them > separately... > But when I combine them both, only one of them works and the 2nd context > gives me these errors... > > I have these jars included in the war file: > > > > > > I have this system property setting : > -Dorg.apache.jasper.compiler.disablejsr199=true > > > Thank you for your help. > > David > > > org.apache.jasper.JasperException: java.lang.ClassCastException: > org.apache.jasper.runtime.ELContextImpl cannot be cast to > org.apache.jasper.runtime.ELContextImpl > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:440) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:696) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:526) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:586) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1110) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:453) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1044) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:261) > at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:101) > > ... MORE > > Caused by: java.lang.ClassCastException: > org.apache.jasper.runtime.ELContextImpl cannot be cast to > org.apache.jasper.runtime.ELContextImpl > at > org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:1009) > at > org.apache.jsp.views.error_jsp._jspService(org.apache.jsp.views.error_jsp:52) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411) > ... 36 more > > > Caused by: > > java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl cannot > be cast to org.apache.jasper.runtime.ELContextImpl > at > org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:1009) > at > org.apache.jsp.views.error_jsp._jspService(org.apache.jsp.views.error_jsp:52) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377) > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > > >
Re: [jetty-users] org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.runtime.ELContextImpl
tHandler.doScope(ServletHandler.java:453) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1044) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:261) > at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:101) > > > Thank you. > > David > > > > > On Monday, March 17, 2014 5:43 PM, Jan Bartel wrote: > David, > > Remove the jsp-related jars from your webapp - they are provided by > the servlet container (in this case the jetty runner). > > regards > Jan > > On 18 March 2014 10:35, David L Gangarapu > wrote: >> Joakim, >> thank you for the reply...Here is the list of files in both war files: >> jetty-server-9.1.0.v20131115.jar >> jetty-util-9.1.0.v20131115.jar >> javax.servlet.jsp-2.3.2.jar >> jetty-jsp-jdt-2.3.3.jar >> >> Thank you. >> >> David >> >> >> >> On Monday, March 17, 2014 4:24 PM, Joakim Erdfelt >> wrote: >> That specific error usually points to two or more standard EL jars (at >> different versions) present in your webapp. >> What are your WEB-INF/lib/*.jar files? >> >> -- >> Joakim Erdfelt >> webtide.com - intalio.com/jetty >> Expert advice, services and support from from the Jetty & CometD experts >> eclipse.org/jetty - cometd.org >> >> >> On Mon, Mar 17, 2014 at 4:21 PM, David L Gangarapu >> wrote: >> >> Can someone please help me with the error ( see stack trace below ). >> >> I have two war files with different contexts and I am trying to run them >> using jetty runner. >> Each Individual war files get loaded and run well if I rum them >> separately... >> But when I combine them both, only one of them works and the 2nd context >> gives me these errors... >> >> I have these jars included in the war file: >> >> >> >> >> >> I have this system property setting : >> -Dorg.apache.jasper.compiler.disablejsr199=true >> >> >> Thank you for your help. >> >> David >> >> >> org.apache.jasper.JasperException: java.lang.ClassCastException: >> org.apache.jasper.runtime.ELContextImpl cannot be cast to >> org.apache.jasper.runtime.ELContextImpl >> at >> >> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:440) >> at >> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473) >> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> at >> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:696) >> at >> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:526) >> at >> >> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) >> at >> >> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:586) >> at >> >> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) >> at >> >> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1110) >> at >> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:453) >> at >> >> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) >> at >> >> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1044) >> at >> >> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) >> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:261) >> at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:101) >> >> ... MORE >> >> Caused by: java.lang.ClassCastException: >> org.apache.jasper.runtime.ELContextImpl cannot be cast to >> org.apache.jasper.runtime.ELContextImpl >> at >> >> org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:1009) >> at >> >> org.apache.jsp.views.error_jsp._jspService(org.apache.jsp.views.error_jsp:52) >> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> at >> >
Re: [jetty-users] org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.runtime.ELContextImpl
David, please remove the following: --jar ./lib/jsp/jetty-jsp-fragment-2.3.3.jar //this is only needed in osgi environments --jar .\lib\jetty-schemas-3.1.jar //this is already included inside the runner jar Please try again with those removed, and your environment variables set correctly as Joakim mentioned. Note that if indeed you have the %JAVA_HOME% and %PATH% set correctly, and you are using a full jdk (verify with "java -version"), you can use the in-jvm compiler, in which case you should also remove: --jar ./lib/jsp/jetty-jsp-jdt-2.3.3.jar -Dorg.apache.jasper.compiler.disablejsr199=true Jan On 19 March 2014 09:57, David L Gangarapu wrote: > Jan, > Thank you for the suggestion.. > Yes, I am running from JDK... I am getting that error even with that jar > file in the classpath to the container: > The error is: > PWC6349: Cannot find a java compiler for compilation. If running with JDK 5 > or before, Ant or JDT compiler can be used, if the corresponding jars and > bridge classes (org.apache.jasper.compiler.AntJavaCompiler or > org.apache.jasper.compiler.JDTJavaCompiler) are included > > > Here is the class path: > C:\Java\jdk-7u45\bin\java.exe > -Djava.library.path=C:\Java\jdk-7u45\bin > -Dorg.apache.jasper.compiler.disablejsr199=true > -Dlogs.dir=.\logs3\ > -Dfile.encoding=UTF-8 > -jar jetty-runner.jar > --jar ./lib/jsp/jetty-jsp-jdt-2.3.3.jar > --jar ./lib/jsp/jetty-jsp-fragment-2.3.3.jar > --jar .\lib\jetty-schemas-3.1.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-beans-4.0.0.RELEASE.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-context-4.0.0.RELEASE.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-context-support-4.0.0.RELEASE.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-core-4.0.0.RELEASE.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-expression-4.0.0.RELEASE.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-jdbc-4.0.0.RELEASE.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-jms-4.0.0.RELEASE.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-messaging-4.0.0.RELEASE.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-tx-4.0.0.RELEASE.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-web-4.0.0.RELEASE.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-webmvc-4.0.0.RELEASE.jar > --jar > C:/Java_Libs/spring-framework-4.0.0.RELEASE/libs/spring-webmvc-portlet-4.0.0.RELEASE.jar > --port 4003 infra7.xml home7.xml > > Thank you for your help. > > David > > > > On Monday, March 17, 2014 6:09 PM, Jan Bartel wrote: > David, > > Looks like you're running with a jre, not the jdk. In that case, > you'll need to put the jetty-jsp-jdt-2.3.3.jar onto the container's > classapath. You can do that using the --jar argument to the jetty > runner. Do java -jar runner.jar --help to see all the options. > > regards > Jan > > On 18 March 2014 11:55, David L Gangarapu > wrote: >> Jan, >> Thank you for the reply. >> I removed both the JSP related jar files from the web-inf\lib: >> javax.servlet.jsp-2.3.2.jar >> jetty-jsp-jdt-2.3.3.jar >> >> I get the following error when I run with >> -Dorg.apache.jasper.compiler.disablejsr199=true : >> >> org.apache.jasper.JasperException: PWC6349: Cannot find a java compiler >> for >> compilation. If running with JDK 5 or >> before, Ant or JDT compiler can be used, if the corresponding jars and >> bridge classes (org.apache.jasper.compiler.AntJavaCompiler or >> org.apache.jasper.compiler.JDTJavaCompiler) are included >> at >> >> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:92) >> at >> >> org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:378) >> at >> >> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:119) >> at >> org.apache.jasper.compiler.Compiler.initJavaCompiler(Compiler.java:773) >> at org.apache.jasper.compiler.Compiler.(Compiler.java:140) >> at >> >> org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:288) >> at >> >> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:622) >> at >> >> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375) >> at >> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473) >> at org.apache.jasper.servlet.JspServlet.service(Js
Re: [jetty-users] is hot re-deployment without errors possible?
Rob,
You could also look at customizing the
org.eclipse.jetty.server.handler.DefaultHandler, which is the last
handler in the HandlerCollection configured in jetty.xml. You could
make it do the error message, with an automatic retry redirect etc.
See
http://download.eclipse.org/jetty/stable-9/xref/org/eclipse/jetty/server/handler/DefaultHandler.html
regards
Jan
On 22 March 2014 01:29, Rob Nikander wrote:
> Thanks for the help, I'll explore both of these suggestions.
>
> Rob
>
>
> On Mon, Mar 17, 2014 at 3:09 PM, "" wrote:
>>
>> Another way to avoid this really is to run two instances of jetty,
>> production and production-standby. You deploy your new application version
>> to the standby then tell your load balancer to send all requests without an
>> already established session to the standby instance which effectively makes
>> the standby production and the old production into a standby, This should
>> be possible with nginx but certainly is using other reverse proxy
>> arrangements.
>>
>> An advantage for this is that if your production and production-standby
>> use two different installations of jetty, then it will be much easier to
>> perform upgrades / maintenance of jetty. It also allows you to test your
>> new application on production-standy before letting customers at it.
>>
>> Of course, this requires a bit more sysadmin type effort.
>>
>>
>> On 17 March 2014 12:14, Jan Bartel wrote:
>>>
>>> Robert,
>>>
>>> A 404 seems pretty reasonable. If the connectors are still running,
>>> then the server is still accepting requests. Therefore there is a
>>> small amount of time during which the webapp is stopped, and the
>>> restart has not yet completed, and a request can arrive. During that
>>> period, it is correct that there is no context matching the request.
>>>
>>> If you want to avoid a 404 you could deploy a 2nd webapp at the same
>>> context path. When the 1st webapp stops due to the hot update, the 2nd
>>> webapp will answer the request. Normally this 2nd webapp would contain
>>> a static page with a maintenance message, maybe doing an automatic
>>> reload or directing the user to do the reload, and of course turning
>>> off caching. After you've got the 1st webapp redeployed, you can use
>>> jmx to turn off the 2nd webapp, so traffic will flow again to the 1st
>>> webapp.
>>>
>>> Jan
>>>
>>> On 15 March 2014 00:56, Robert Nikander wrote:
>>> > Upgrading to Jetty 9.1.3 fixed the NullPointerExceptions. But now,
>>> > instead of the 500 error, I get a 404 not found error for a second while
>>> > the
>>> > app is redeploying. So, my question remains: is that normal, or is
>>> > re-deployment supposed to work seamlessly?
>>> >
>>> > Rob
>>> >
>>> >
>>> > On Mar 14, 2014, at 9:02 AM, Robert Nikander
>>> > wrote:
>>> >
>>> >> Ah, this may be fixed in newer Jetty versions. I'll try upgrading.
>>> >>
>>> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=417475
>>> >>
>>> >> Rob
>>> >>
>>> >> On Mar 14, 2014, at 8:49 AM, Robert Nikander
>>> >> wrote:
>>> >>
>>> >>> Jan,
>>> >>>
>>> >>> I believe the rsync is finished. I use a shell script and and the
>>> >>> two commands are sequential. Here is the script, and some log messages.
>>> >>>
>>> >>> #!/bin/bash
>>> >>> rsync -v myapp.war myserver:/opt/webapps
>>> >>> rsync -v deployment/myapp.xml myserver:/opt/jetty/webapps/
>>> >>>
>>> >>> If I run that, the logs show a stop and start.
>>> >>>
>>> >>> 2014-03-14 12:37:01.706:INFO:oejsh.ContextHandler:Scanner-0:
>>> >>> Stopped
>>> >>> o.e.j.w.WebAppContext@358ee631{/myapp,file:/tmp/jetty-0.0.0.0-8080-myapp.war-_myapp-any-/webapp/,UNAVAILABLE}{/myapp.war}
>>> >>> 2014-03-14 12:37:03.644:INFO:oejsh.ContextHandler:Scanner-0:
>>> >>> Started
>>> >>> o.e.j.w.WebAppContext@760aa0cd{/myapp,file:/tmp/jetty-0.0.0.0-8080-myapp.war-_myapp-any-/webapp/,AVAILABLE}{/myapp.war}
>>> >>>
>>> >>> I ran the script again, but this time kept reloading a page in the
>>> >>> browser, to trigger an error. Between the stop and
Re: [jetty-users] Jetty/SQL SERVER Connection Pool
Here's the link to the most recent Jetty doco: http://www.eclipse.org/jetty/documentation/current/jndi-datasource-examples.html It still references the JtdsDataSource because we haven't had anyone contribute any doc for newer classes. There's no requirement for you to use the JtdsDataSource - you can use whatever JDBC datasource MS recommends. But please do contribute your configuration example for it when you get it working. regards Jan On 25 March 2014 04:40, i haz the codez wrote: > Hi All > > I want configure data source connection pooling using the MS JDBC datasource > SQLServerConnectionPoolDataSource > > http://technet.microsoft.com/en-us/library/ms378484.aspx > > Looking at the documentation, and using Jetty 9.1.2, > https://wiki.eclipse.org/Jetty/Howto/Configure_JNDI_Datasource, should I be > using the net.sourceforge.jtds.jdbcx.JtdsDataSource as noted under SQL > SERVER 2000 - which is like super old - or what is the recommended practice > now? > > thanks > q > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] getContextPath returns null
Nils, Using the standard test.war and test.xml from the jetty distro, and setting the context path to be "/", I haven't been able to reproduce this with jetty-9.1.3, nor actually with jetty-9.1.0. Can you reliably reproduce with the test webapp? Jan On 5 April 2014 14:05, Nils Kilden-Pedersen wrote: > When running in the root context, request.getContextPath() returns null > rather than "" as expected. > > http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getContextPath() > > This is on 9.1.2. > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] getContextPath returns null
Hi Nils, Can you make a really simple test that reproduces? regards Jan On 6 April 2014 04:18, Nils Kilden-Pedersen wrote: > I suspect this is a race condition related to async. If the Request object > (or by extension HttpConnection), it looks like the context path (and other > mutable variables) are being set/reset to null, possibly before the async > context has completed. > > When I disabled async I could not reproduce this. > > On Sat, Apr 5, 2014 at 9:00 AM, Nils Kilden-Pedersen > wrote: >> >> Here are some characteristics of my app: >> >> Jetty 9.1.2 >> >> Windows 8.1, haven't yet tried on Linux (probably not relevant) >> >> App is a folder in webapps named ROOT >> There's no xml descriptor >> The servlet is configured using annotations >> The servlet is async >> >> So very basic setup, configuration wise. >> >> >> >> On Sat, Apr 5, 2014 at 3:27 AM, Jan Bartel wrote: >>> >>> Nils, >>> >>> Using the standard test.war and test.xml from the jetty distro, and >>> setting the context path to be "/", I haven't been able to reproduce >>> this with jetty-9.1.3, nor actually with jetty-9.1.0. Can you reliably >>> reproduce with the test webapp? >>> >>> Jan >>> >>> On 5 April 2014 14:05, Nils Kilden-Pedersen wrote: >>> > When running in the root context, request.getContextPath() returns null >>> > rather than "" as expected. >>> > >>> > >>> > http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getContextPath() >>> > >>> > This is on 9.1.2. >>> > >>> > >>> > ___ >>> > jetty-users mailing list >>> > jetty-users@eclipse.org >>> > https://dev.eclipse.org/mailman/listinfo/jetty-users >>> > >>> >>> >>> >>> -- >>> Jan Bartel >>> www.webtide.com >>> 'Expert Jetty/CometD developer,production,operations advice' >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] DoSFilter annotation not found.
Chetan,
How are you setting up the DosFilter in standalone mode - declared in
web.xml, or declared in a context xml file as a FilterHolder or some
other way in some other jetty xml file? Also check that you don't have
an older version of the DoSFilter inside your webapp.
Jan
On 6 April 2014 13:23, Singh, Chetan wrote:
> I am trying to set up a DoSFilter and configure it using JMX Mbean.
> Everything works fine when I try to do in Embedded jetty. However I want to
> do it in standalone mode but I get the following log messages
>
>
>
> 2014-04-05 20:18:32.834:DBUG:oejj.MBeanContainer:main: beanAdded
> o.e.j.w.WebAppContext@ace3c1b{/,file:/tmp/jetty-0.0.0.0-8080-ROOT.war-_-any-6506776307143437350.dir/webapp/,STARTING}{/ROOT.war}->org.eclipse.jetty.servlets.DoSFilter@6d4d63ba
>
> 2014-04-05 20:18:32.835:DBUG:oejj.ObjectMBean:main: ObjectMbean: mbeanFor
> org.eclipse.jetty.servlets.DoSFilter@6d4d63ba mClass=class
> org.eclipse.jetty.jmx.ObjectMBean
>
> 2014-04-05 20:18:32.835:DBUG:oejj.ObjectMBean:main: mbeanFor
> org.eclipse.jetty.servlets.DoSFilter@6d4d63ba is
> org.eclipse.jetty.jmx.ObjectMBean@34bb5def
>
> 2014-04-05 20:18:32.835:DBUG:oejj.ObjectMBean:main: No MBean Influence for
> DoSFilter
>
> 2014-04-05 20:18:32.835:DBUG:oejj.ObjectMBean:main: No MBean Influence for
> Object
>
> 2014-04-05 20:18:32.836:DBUG:oejj.ObjectMBean:main: No MBean Influence for
> Filter
>
> 2014-04-05 20:18:32.836:DBUG:oejj.ObjectMBean:main: Influence Count: 3
>
> 2014-04-05 20:18:32.836:DBUG:oejj.ObjectMBean:main: No @ManagedObject
> declared on class org.eclipse.jetty.servlets.DoSFilter
>
> 2014-04-05 20:18:32.836:DBUG:oejj.ObjectMBean:main: Influenced by:
> org.eclipse.jetty.servlets.DoSFilter
>
> 2014-04-05 20:18:32.836:DBUG:oejj.ObjectMBean:main: Annotations not found
> for: org.eclipse.jetty.servlets.DoSFilter
>
> 2014-04-05 20:18:32.836:DBUG:oejj.ObjectMBean:main: Influenced by:
> java.lang.Object
>
> 2014-04-05 20:18:32.836:DBUG:oejj.ObjectMBean:main: Annotations not found
> for: java.lang.Object
>
> 2014-04-05 20:18:32.836:DBUG:oejj.ObjectMBean:main: Influenced by:
> javax.servlet.Filter
>
> 2014-04-05 20:18:32.836:DBUG:oejj.ObjectMBean:main: Annotations not found
> for: javax.servlet.Filter
>
> 2014-04-05 20:18:32.836:DBUG:oejj.MBeanContainer:main: Registered
> org.eclipse.jetty.servlets:context=ROOT,type=dosfilter,id=0
>
>
>
> The @ManagedObject should be present and I am not sure why jetty can't
> detect it. Any help will be appreciated.
>
>
>
> Thanks
>
> Chetan
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Filter initialization order changed in 9.1.4?
Ryan, What was the previous version you're comparing it to? Jan On 9 April 2014 14:02, Ryan McKinley wrote: > It appears that the filter initialization order has changed in 9.1.4, is > this intentional? > > Previously the filters called 'init' in the order they are defined in > web.xml -- I *think* this has been true for a while (even if not part of > the spec) > http://jira.codehaus.org/browse/JETTY-72 > > > Digging a bit, i *think* it would be fixed using a LinkedHashMap in > StandardDescriptorProcessor.java: > > final Map _filterHolders = new HashMap<>(); > > > thanks > ryan > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Filter initialization order changed in 9.1.4?
Ryan, Nevermind, I found the problem and I've raised a bug for it here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=432473 Jan On 10 April 2014 07:12, Jan Bartel wrote: > Ryan, > > What was the previous version you're comparing it to? > > Jan > > On 9 April 2014 14:02, Ryan McKinley wrote: >> It appears that the filter initialization order has changed in 9.1.4, is >> this intentional? >> >> Previously the filters called 'init' in the order they are defined in >> web.xml -- I *think* this has been true for a while (even if not part of >> the spec) >> http://jira.codehaus.org/browse/JETTY-72 >> >> >> Digging a bit, i *think* it would be fixed using a LinkedHashMap in >> StandardDescriptorProcessor.java: >> >> final Map _filterHolders = new HashMap<>(); >> >> >> thanks >> ryan >> >> ___________ >> jetty-users mailing list >> jetty-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > > > > -- > Jan Bartel > www.webtide.com > 'Expert Jetty/CometD developer,production,operations advice' -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] jetty-rewrite.xml: RewriteRule clobbers requestURI
Jetty version? Jan On 11 April 2014 07:10, Michael Dykman wrote: > I am unsure if I am looking at a bug or an expected, if > under-documented feature: > > > A fragment of my jetty-rewrite.xml: > > > ... > false > false > requestedPath > ... > > > I have a number of rules in there, none of them particularly > complicated. Most of them are of type 'RewriteRegexRule' although > some of them have been nested into several 'VirtualHostRuleContainer' > objects. > > > I am testing the url > http://myhost:8080/v2/111/settings > > The matching rule in question is defined thus: > >^/v2/(.*) >/webdir/index.php >true > > > which does redirect my request to the requested script (I am am > running Quercus under Jetty) but the RequestUri and the PathInfo have > been clobbered. I was able to craft a shim to correct those values in > PHP (Quercus is a PHP-on-JVM engine), I am surprised that I had to. > -- > - michael dykman > - mdyk...@gmail.com > > May the Source be with you. > ___________ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Upgrading jetty-runner from version 7.6.15 to 9.1.4, exception from
Hi Mike, This is a bug we introduced with a change in 9.1.4 to preserve the order of declaration of servlets and filters. Someone else has raised a bug for it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=433365 I've committed a fix to head: https://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/commit/?id=e2ed934978b958d6fccb28a8a5d04768f7c0432d This fix will be backported to an upcoming 9.1.5 release. thanks, Jan On 22 April 2014 11:02, Mike McNally wrote: > I've been using jetty-runner for a long to to support development on web > applications. I've been setting up a new development machine, and I > downloaded the newest version of jetty-runner. When I try it with my .war > file, however, I get an exception: > > java.lang.IllegalStateException: No such servlet: > __org.eclipse.jetty.servlet.JspPropertyGroupServlet__ > > (I can of course provide the whole stack trace if that'd help.) I can run > the same .war file with 7.6.15 and it works fine. If I comment out the > thing, then it works with the newer version. > > Is there some other way to do what does? It's kind-of > important, as it's used to set a preamble to all the .jsp files in the > project. > > Thanks! I posted this on Stackoverflow too if you want some points :) > http://stackoverflow.com/questions/23206262/cannot-use-jsp-property-group-configuration-with-jetty-runner-9-1-4 > > > -- > Turtle, turtle, on the ground, > Pink and shiny, turn around. > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Configure STOP.PORT in jetty.xml
In jetty.xml you can do the equivalent in xml of the following calls to set it directly: ShutdownMonitor.getInstance().setPort(); Or you can use the element: http://www.eclipse.org/jetty/documentation/current/reference-section.html#jetty-xml-system-property Jan On 25 April 2014 19:50, Robert Šiška wrote: > Hello. > > I'm using Cargo plugin to deploy with Jetty and I can't seem to be able to > redefine > STOP.PORT system property. I can put it to cargo.jvmargs, but that's not very > nice because it > could collide with other containers. > > Is there a way to define STOP.PORT through jetty.xml? > > Thank you for any suggestion, > Robert > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] java.lang.OutOfMemoryError: PermGen space
Andrew, How are you running jetty? In a standalone distro, as the maven plugin, or via embedded code? I take it that the webapp is being unpacked to a tmp directory? It does sound as if the WebAppClassloader is being pinned. There should be a way with the heap dump tool to follow back to the objects that are keeping references to the WebAppClassLoaders, or follow the link from the doc page to the blog entry about classloader pinning, which describes how to use JVisualVM to hunt down the references. Jan On 1 May 2014 01:11, Andrew Eidsness wrote: > My jetty server (9.1.4.v20140401) eventually runs out of memory after I’ve > deployed the same war (during development) to the webapps folder. After > looking in the bugs database I think this might be happening because I’m > deploying jars inside the war’s lib folder. > > The reason I think this is that looking at the heap dump (in MAT) I can see > 8 copies of classes from those bundled jars. Each of the instances was > loaded by a different instance of > org.eclipse.jetty.webapp.WebAppClassLoader. > > My theory is that when the war is redeployed a new instance of > WebAppClassLoader is created which then loads the new jar files. > > I think I’m doing something wrong, but haven’t been able to figure out what. > I’m not sure how to get the old class loader’s to go away. > > I’ve tried using the leak preventer > (http://www.eclipse.org/jetty/documentation/current/preventing-memory-leaks.html) > by putting this into my jetty.xml file: > > > > class="org.eclipse.jetty.util.preventers.AppContextLeakPreventer"/> > > > > But it didn’t seem to make a difference. > > Any ideas or pointers to appropriate documentation? > > Thanks, > -Andrew > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] "Badly formatted multipart request"
Which version of jetty and can you post the capture of the whole request? Jan On 3 May 2014 16:16, Nils Kilden-Pedersen wrote: > Not sure if this is a Jetty problem or Chrome. > > I’m trying to upload data using the HTML5 FormData object. > > The content type when it reaches the server is > > multipart/form-data; boundary=WebKitFormBoundaryj2AVe6APfo5cJd0R > > which causes Jetty to first warn: > > WARN org.eclipse.jetty.util.MultiPartInputStreamParser - Badly formatted > multipart request > > and then throw this exception: > > java.io.IOException: Missing initial multi part boundary > at > org.eclipse.jetty.util.MultiPartInputStreamParser.parse(MultiPartInputStreamParser.java:515) > at > org.eclipse.jetty.util.MultiPartInputStreamParser.getParts(MultiPartInputStreamParser.java:408) > at org.eclipse.jetty.server.Request.getParts(Request.java:2121) > > Any idea? > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 9.1.5.v20140505 Released!
Ooops, fixed now. thanks Jan On 6 May 2014 17:37, Peter Ondruška wrote: > Sorry, I see it just few lines below. But wonder why is it not "Stable"? > > > On 6 May 2014 09:36, Peter Ondruška wrote: >> >> Dear Jesse, >> >> could you check the "Distribution Downloads", it still has 9.1.4, no >> 9.1.5. Thanks >> >> >> On 5 May 2014 23:30, Jesse McConnell wrote: >>> >>> We are pleased to announce the availability of Jetty 9.1.5! >>> >>> Close to 20 issues have been resolved in this release and we encourage >>> folks >>> to update soon. The issues resolved are listed below. >>> >>> Distribution Downloads: >>> >>> - http://download.eclipse.org/jetty/ >>> >>> The artifacts are also available in Maven Central. P2 repositories >>> are available as well (shortly). >>> >>> If you find an issue with this release you can open a bug through the >>> guided bugzilla page located here: >>> >>> - https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Jetty&format=guided >>> >>> A reminder that both dev and prod support are offered through Webtide >>> (www.webtide.com), feel free to contact us through that site or ping >>> me directly if you are interested in learning more. >>> >>> cheers, >>> jesse >>> >>> jetty-9.1.5.v20140505 - 05 May 2014 >>> + 431459 Jetty WebSocket compression extensions fails to handle big >>> messages >>>properly >>> + 431519 Fixed NetworkTrafficListener >>> + 432145 Pending request is not failed when HttpClient is stopped. >>> + 432270 Slow requests with response content delimited by EOF fail. >>> + 432473 web.xml declaration order of filters not preserved on calls to >>> init() >>> + 432483 make osgi.serviceloader support for >>>javax.servlet.ServletContainerInitializer optional (cherry picked from >>>commit 31043d25708edbea9ef31948093f4eaf2247919b) >>> + 432528 IllegalStateException when using DeferredContentProvider. >>> + 432777 Async Write Loses Data with HTTPS Server. >>> + 432901 ensure a single onError callback only in pending and unready >>> states >>> + 432993 Improve handling of ProxyTo and Prefix parameters in >>>ProxyServlet.Transparent. >>> + 433365 No such servlet: >>>__org.eclipse.jetty.servlet.JspPropertyGroupServlet__ (cherry picked >>> from >>>commit e2ed934978b958d6fccb28a8a5d04768f7c0432d) >>> + 433370 PATCH method does not work with ProxyServlet. >>> + 433483 sync log initialize >>> + 433692 improved buffer resizing >>> + 433916 HttpChannelOverHttp handles HTTP 1.0 connection reuse >>> incorrectly. >>> + 434027 ReadListener.onError() not invoked in case of read failures. >>> >>> >>> -- >>> jesse mcconnell >>> jesse.mcconn...@gmail.com >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] MIME types
Nils, Ah! The mime.properties file is in jetty-http.jar. I've fixed the comment in webdefault.xml. thanks Jan On 12 May 2014 06:22, Nils Kilden-Pedersen wrote: > I recently upgraded to 9.1.5 on my dev box and just noticed that all my .css > and .js files are being served as text/html. > > I then checked the webdefault.xml and could see that the usual MIME mappings > are moved to a mime.properties file, supposedly in the > org.eclipse.jetty.server.jar file, however I don't see it. > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Continuous stopping/starting of WebAppContext
Nils,
Try: http://www.eclipse.org/jetty/documentation/current/hot-deployment.html
Jan
On 11 May 2014 23:12, Nils Kilden-Pedersen wrote:
> I’ve noticed that, during development, whenever I save a file, e.g. a
> Javascript file, Jetty restarts the context. In the logs it looks like this:
>
> 302582 [Scanner-0] INFO org.eclipse.jetty.server.handler.ContextHandler -
> Stopped
> o.e.j.w.WebAppContext@7ee398b4{/,file:/C:/Users/Nils/jetty/webapps/ROOT/,UNAVAILABLE}{C:\Users\Nils\jetty\webapps\ROOT}
> 303041 [Scanner-0] INFO org.eclipse.jetty.server.handler.ContextHandler -
> Started
> o.e.j.w.WebAppContext@5807bb89{/,file:/C:/Users/Nils/jetty/webapps/ROOT/,AVAILABLE}{C:\Users\Nils\jetty\webapps\ROOT}
>
> Why is this happening and, more importantly, how do I make it stop?
>
> Thanks,
> Nils
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Contention in ServletHolder.handle()
Daniel, Not sure exactly the lines in ServletHolder you're referring to, but I assume its the synchronized block around line 652? If so, then this code guards the initial startup of a servlet - if it isn't load-on-startup, then any request coming in can initialize it. Therefore, if you have multiple concurrent requests, you need to protect the servlet startup so it happens only once. Jan On 8 May 2014 22:43, Daniel Feist wrote: > Hi, > > I've been doing some testing/benchmarking of Jetty 8 with Mule ESB and > seeming a decent amount of contention where it doesn't seem that > synchronization is required. > > My test scenario is just a simple echo, all i do is read the request > stream and then respond. The contention i'm seeing can be seen here: > > https://www.dropbox.com/s/bbkdsk7ndfpzoj9/Screen%20Shot%202014-05-08%20at%209.35.34%20PM.png > > Inspecting the code, I can't understand why this needs to even be > synchonrized. > > Any thoughts? Is there a config option I should be using that i'm not? > Is my test scenario unrealistic? > > thanks! > Dan > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Continuous stopping/starting of WebAppContext
Nils,
For development, many people choose to use maven. In which case, they
use the jetty-maven-plugin, which is specifically set up to do hot
replacement of files. Static files do not cause context restarts, only
changes to compiled files, or configuration files such as web.xml, the
pom.xml etc. Here's the doc link for it:
The jetty hot deployer does not distinguish between static and
compiled files - if any file in a monitored directory changed, then it
redeploys. Maybe open a bugzilla for an enhancement that could select
more files to ignore for redeployment (ie .html, .css, js etc etc) ...
Jan
On 11 May 2014 23:12, Nils Kilden-Pedersen wrote:
> I’ve noticed that, during development, whenever I save a file, e.g. a
> Javascript file, Jetty restarts the context. In the logs it looks like this:
>
> 302582 [Scanner-0] INFO org.eclipse.jetty.server.handler.ContextHandler -
> Stopped
> o.e.j.w.WebAppContext@7ee398b4{/,file:/C:/Users/Nils/jetty/webapps/ROOT/,UNAVAILABLE}{C:\Users\Nils\jetty\webapps\ROOT}
> 303041 [Scanner-0] INFO org.eclipse.jetty.server.handler.ContextHandler -
> Started
> o.e.j.w.WebAppContext@5807bb89{/,file:/C:/Users/Nils/jetty/webapps/ROOT/,AVAILABLE}{C:\Users\Nils\jetty\webapps\ROOT}
>
> Why is this happening and, more importantly, how do I make it stop?
>
> Thanks,
> Nils
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Continuous stopping/starting of WebAppContext
Nils,
If you're using the jetty-maven-plugin, you are NOT using the
jetty-deploy.xml file. You are running jetty directly on a webapp
project by typing "mvn jetty:run". If you do that, then ordinary
static file changes don't cause a redeploy, only changes to specific
files such as classes, web.xml etc.
If you're using the jetty distribution (starting with java -jar
start.jar) then the jetty-deploy.xml file is used and the
WebAppProvider monitors the webapps directory for changes in any
subdirs. It is not as choosy as the jetty-maven-plugin about which
files will trigger a redeployment - although it does ignore dot files
and cvs and svn dirs and a few others.
Jan
On 12/05/2014, Nils Kilden-Pedersen wrote:
> On Mon, May 12, 2014 at 9:06 AM, Jan Bartel wrote:
>
>> Nils,
>>
>> For development, many people choose to use maven. In which case, they
>> use the jetty-maven-plugin, which is specifically set up to do hot
>> replacement of files. Static files do not cause context restarts
>
>
> It most certainly does on 9.1.5, using the default jetty-deploy.xml.
>
>
>> , only
>> changes to compiled files
>
>
> And conversely it does not for changed class files.
>
>
>> , or configuration files such as web.xml, the
>> pom.xml etc. Here's the doc link for it:
>>
>> The jetty hot deployer does not distinguish between static and
>> compiled files - if any file in a monitored directory changed,
>
>
> Wait, what? Doesn't that contradict what you wrote above about static
> files?
>
>
> BTW, I'm developing on Windows, so maybe that could explain something?
>
>
>> then it
>> redeploys. Maybe open a bugzilla for an enhancement that could select
>> more files to ignore for redeployment (ie .html, .css, js etc etc) ...
>>
>> Jan
>>
>> On 11 May 2014 23:12, Nils Kilden-Pedersen wrote:
>> > I’ve noticed that, during development, whenever I save a file, e.g. a
>> > Javascript file, Jetty restarts the context. In the logs it looks like
>> this:
>> >
>> > 302582 [Scanner-0] INFO
>> > org.eclipse.jetty.server.handler.ContextHandler
>> -
>> > Stopped
>> > o.e.j.w.WebAppContext@7ee398b4
>> {/,file:/C:/Users/Nils/jetty/webapps/ROOT/,UNAVAILABLE}{C:\Users\Nils\jetty\webapps\ROOT}
>> > 303041 [Scanner-0] INFO
>> > org.eclipse.jetty.server.handler.ContextHandler
>> -
>> > Started
>> > o.e.j.w.WebAppContext@5807bb89
>> {/,file:/C:/Users/Nils/jetty/webapps/ROOT/,AVAILABLE}{C:\Users\Nils\jetty\webapps\ROOT}
>> >
>> > Why is this happening and, more importantly, how do I make it stop?
>> >
>> > Thanks,
>> > Nils
>> >
>> >
>> > _______
>> > jetty-users mailing list
>> > jetty-users@eclipse.org
>> > https://dev.eclipse.org/mailman/listinfo/jetty-users
>> >
>>
>>
>>
>> --
>> Jan Bartel
>> www.webtide.com
>> 'Expert Jetty/CometD developer,production,operations advice'
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Continuous stopping/starting of WebAppContext
Nils,
Hmm, I think the jetty hot deployer for the distro is possibly just
monitoring the webapps/ directory for changes, and not any subdirs. On
linux, I just unpacked the standard test.war into webapps/test and
touched a few static files and a few class files inside and it didn't
redeploy at all. However, as that webapp has a corresponding test.xml
context configuration file, if I touch that, it will certainly
redeploy the webapp.
So, looking at the configuration parameters for the hot deployer, as
recursion is turned off, I don't see how modifying any of the files
inside an unpacked war would cause a redeploy. Perhaps you should turn
on debugging and send a log trace?
Jan
On 12/05/2014, Nils Kilden-Pedersen wrote:
> On Mon, May 12, 2014 at 10:07 AM, Jan Bartel wrote:
>
>> Nils,
>>
>> If you're using the jetty-maven-plugin, you are NOT using the
>> jetty-deploy.xml file. You are running jetty directly on a webapp
>> project by typing "mvn jetty:run". If you do that, then ordinary
>> static file changes don't cause a redeploy, only changes to specific
>> files such as classes, web.xml etc.
>>
>
> Not using that.
>
>
>> If you're using the jetty distribution (starting with java -jar
>> start.jar) then the jetty-deploy.xml file is used and the
>> WebAppProvider monitors the webapps directory for changes in any
>> subdirs. It is not as choosy as the jetty-maven-plugin about which
>> files will trigger a redeployment - although it does ignore dot files
>> and cvs and svn dirs and a few others.
>>
>
> Ok, that clarifies things somewhat.
>
> Still not sure why class file changes are not detected though.
>
>
>>
>> Jan
>>
>> On 12/05/2014, Nils Kilden-Pedersen wrote:
>> > On Mon, May 12, 2014 at 9:06 AM, Jan Bartel wrote:
>> >
>> >> Nils,
>> >>
>> >> For development, many people choose to use maven. In which case, they
>> >> use the jetty-maven-plugin, which is specifically set up to do hot
>> >> replacement of files. Static files do not cause context restarts
>> >
>> >
>> > It most certainly does on 9.1.5, using the default jetty-deploy.xml.
>> >
>> >
>> >> , only
>> >> changes to compiled files
>> >
>> >
>> > And conversely it does not for changed class files.
>> >
>> >
>> >> , or configuration files such as web.xml, the
>> >> pom.xml etc. Here's the doc link for it:
>> >>
>> >> The jetty hot deployer does not distinguish between static and
>> >> compiled files - if any file in a monitored directory changed,
>> >
>> >
>> > Wait, what? Doesn't that contradict what you wrote above about static
>> > files?
>> >
>> >
>> > BTW, I'm developing on Windows, so maybe that could explain something?
>> >
>> >
>> >> then it
>> >> redeploys. Maybe open a bugzilla for an enhancement that could select
>> >> more files to ignore for redeployment (ie .html, .css, js etc etc) ...
>> >>
>> >> Jan
>> >>
>> >> On 11 May 2014 23:12, Nils Kilden-Pedersen wrote:
>> >> > I’ve noticed that, during development, whenever I save a file, e.g.
>> >> > a
>> >> > Javascript file, Jetty restarts the context. In the logs it looks
>> >> > like
>> >> this:
>> >> >
>> >> > 302582 [Scanner-0] INFO
>> >> > org.eclipse.jetty.server.handler.ContextHandler
>> >> -
>> >> > Stopped
>> >> > o.e.j.w.WebAppContext@7ee398b4
>> >>
>> {/,file:/C:/Users/Nils/jetty/webapps/ROOT/,UNAVAILABLE}{C:\Users\Nils\jetty\webapps\ROOT}
>> >> > 303041 [Scanner-0] INFO
>> >> > org.eclipse.jetty.server.handler.ContextHandler
>> >> -
>> >> > Started
>> >> > o.e.j.w.WebAppContext@5807bb89
>> >>
>> {/,file:/C:/Users/Nils/jetty/webapps/ROOT/,AVAILABLE}{C:\Users\Nils\jetty\webapps\ROOT}
>> >> >
>> >> > Why is this happening and, more importantly, how do I make it stop?
>> >> >
>> >> > Thanks,
>> >> > Nils
>> >> >
>> >> >
>> >> > ___
>> >> > jetty-users mailing list
>> >> > jetty-users@eclipse.org
>> >> > https://dev.eclipse.org/mailman/listinfo/jetty-users
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Jan Bartel
>> >> www.webtide.com
>> >> 'Expert Jetty/CometD developer,production,operations advice'
>> >> ___
>> >> jetty-users mailing list
>> >> jetty-users@eclipse.org
>> >> https://dev.eclipse.org/mailman/listinfo/jetty-users
>> >>
>> >
>>
>>
>> --
>> Jan Bartel
>> www.webtide.com
>> 'Expert Jetty/CometD developer,production,operations advice'
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Contention in ServletHolder.handle()
Daniel, let me see if I can prevent the call to getServlet() in the case where you provide a pre-constructed servlet. I'll do some testing and get back to you - I need to confirm that the handling of that would be ok for cases where the servlet may have been made unavailable etc etc as well. Jan On 12/05/2014, Daniel Feist wrote: > Hi, > > Yes. I agree this is needed is 'initOnStartup' is not configured, was > trying to work out why the synchonrized block was needed at all for > the 'initOnStartup' case though. > > That said, the reason reason I was seeing contention is probably > primarily due to org.eclipse.jetty.servlet.ServletHolder.getServlet() > because my servlet doesn't have 'initOnStartup' set. > > In my use case I embed jetty and provide Jetty with a > pre-instantiated/configured servlet instance wrapped in a > ServletHolder. I guess i need to set the somewhat unobvious initOrder > to non-0 to configure this and reduce the contention? > > thanks! > > > > On Mon, May 12, 2014 at 11:15 AM, Jan Bartel wrote: >> Daniel, >> >> Not sure exactly the lines in ServletHolder you're referring to, but I >> assume its the synchronized block around line 652? If so, then this >> code guards the initial startup of a servlet - if it isn't >> load-on-startup, then any request coming in can initialize it. >> Therefore, if you have multiple concurrent requests, you need to >> protect the servlet startup so it happens only once. >> >> Jan >> >> On 8 May 2014 22:43, Daniel Feist wrote: >>> Hi, >>> >>> I've been doing some testing/benchmarking of Jetty 8 with Mule ESB and >>> seeming a decent amount of contention where it doesn't seem that >>> synchronization is required. >>> >>> My test scenario is just a simple echo, all i do is read the request >>> stream and then respond. The contention i'm seeing can be seen here: >>> >>> https://www.dropbox.com/s/bbkdsk7ndfpzoj9/Screen%20Shot%202014-05-08%20at%209.35.34%20PM.png >>> >>> Inspecting the code, I can't understand why this needs to even be >>> synchonrized. >>> >>> Any thoughts? Is there a config option I should be using that i'm not? >>> Is my test scenario unrealistic? >>> >>> thanks! >>> Dan >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> >> >> -- >> Jan Bartel >> www.webtide.com >> 'Expert Jetty/CometD developer,production,operations advice' >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/jetty-users > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Contention in ServletHolder.handle()
Daniel, The only reason you would set the initOrder is to avoid the extra call to getServlet() in the handle() method. It won't make any difference to whether your servlet is properly initialized or not, as the code specifically handles an externally provided servlet instance on startup. Jan On 12/05/2014, Daniel Feist wrote: > After doing some performance testing, while contention shows in > profiler clearly the performance impact is not significant I don't > thnk, so this would just be minor cleanup/optimization. > > Was i right when i set I need to use "initOrder" to ensure it gets > initialized at startup? > > I should really just be implementing a handler, but current > implementation uses a servlet. > > thanks! > > On Mon, May 12, 2014 at 5:15 PM, Jan Bartel wrote: >> Daniel, >> >> let me see if I can prevent the call to getServlet() in the case where >> you provide a pre-constructed servlet. I'll do some testing and get >> back to you - I need to confirm that the handling of that would be ok >> for cases where the servlet may have been made unavailable etc etc as >> well. >> >> Jan >> >> On 12/05/2014, Daniel Feist wrote: >>> Hi, >>> >>> Yes. I agree this is needed is 'initOnStartup' is not configured, was >>> trying to work out why the synchonrized block was needed at all for >>> the 'initOnStartup' case though. >>> >>> That said, the reason reason I was seeing contention is probably >>> primarily due to org.eclipse.jetty.servlet.ServletHolder.getServlet() >>> because my servlet doesn't have 'initOnStartup' set. >>> >>> In my use case I embed jetty and provide Jetty with a >>> pre-instantiated/configured servlet instance wrapped in a >>> ServletHolder. I guess i need to set the somewhat unobvious initOrder >>> to non-0 to configure this and reduce the contention? >>> >>> thanks! >>> >>> >>> >>> On Mon, May 12, 2014 at 11:15 AM, Jan Bartel wrote: >>>> Daniel, >>>> >>>> Not sure exactly the lines in ServletHolder you're referring to, but I >>>> assume its the synchronized block around line 652? If so, then this >>>> code guards the initial startup of a servlet - if it isn't >>>> load-on-startup, then any request coming in can initialize it. >>>> Therefore, if you have multiple concurrent requests, you need to >>>> protect the servlet startup so it happens only once. >>>> >>>> Jan >>>> >>>> On 8 May 2014 22:43, Daniel Feist wrote: >>>>> Hi, >>>>> >>>>> I've been doing some testing/benchmarking of Jetty 8 with Mule ESB and >>>>> seeming a decent amount of contention where it doesn't seem that >>>>> synchronization is required. >>>>> >>>>> My test scenario is just a simple echo, all i do is read the request >>>>> stream and then respond. The contention i'm seeing can be seen here: >>>>> >>>>> https://www.dropbox.com/s/bbkdsk7ndfpzoj9/Screen%20Shot%202014-05-08%20at%209.35.34%20PM.png >>>>> >>>>> Inspecting the code, I can't understand why this needs to even be >>>>> synchonrized. >>>>> >>>>> Any thoughts? Is there a config option I should be using that i'm not? >>>>> Is my test scenario unrealistic? >>>>> >>>>> thanks! >>>>> Dan >>>>> ___ >>>>> jetty-users mailing list >>>>> jetty-users@eclipse.org >>>>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>>> >>>> >>>> >>>> -- >>>> Jan Bartel >>>> www.webtide.com >>>> 'Expert Jetty/CometD developer,production,operations advice' >>>> ___ >>>> jetty-users mailing list >>>> jetty-users@eclipse.org >>>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>> >> >> >> -- >> Jan Bartel >> www.webtide.com >> 'Expert Jetty/CometD developer,production,operations advice' >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/jetty-users > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Contention in ServletHolder.handle()
Daniel, I made a change to ServletHolder. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=434715 Jan On 12/05/2014, Jan Bartel wrote: > Daniel, > > The only reason you would set the initOrder is to avoid the extra call > to getServlet() in the handle() method. It won't make any difference > to whether your servlet is properly initialized or not, as the code > specifically handles an externally provided servlet instance on > startup. > > Jan > > On 12/05/2014, Daniel Feist wrote: >> After doing some performance testing, while contention shows in >> profiler clearly the performance impact is not significant I don't >> thnk, so this would just be minor cleanup/optimization. >> >> Was i right when i set I need to use "initOrder" to ensure it gets >> initialized at startup? >> >> I should really just be implementing a handler, but current >> implementation uses a servlet. >> >> thanks! >> >> On Mon, May 12, 2014 at 5:15 PM, Jan Bartel wrote: >>> Daniel, >>> >>> let me see if I can prevent the call to getServlet() in the case where >>> you provide a pre-constructed servlet. I'll do some testing and get >>> back to you - I need to confirm that the handling of that would be ok >>> for cases where the servlet may have been made unavailable etc etc as >>> well. >>> >>> Jan >>> >>> On 12/05/2014, Daniel Feist wrote: >>>> Hi, >>>> >>>> Yes. I agree this is needed is 'initOnStartup' is not configured, was >>>> trying to work out why the synchonrized block was needed at all for >>>> the 'initOnStartup' case though. >>>> >>>> That said, the reason reason I was seeing contention is probably >>>> primarily due to org.eclipse.jetty.servlet.ServletHolder.getServlet() >>>> because my servlet doesn't have 'initOnStartup' set. >>>> >>>> In my use case I embed jetty and provide Jetty with a >>>> pre-instantiated/configured servlet instance wrapped in a >>>> ServletHolder. I guess i need to set the somewhat unobvious initOrder >>>> to non-0 to configure this and reduce the contention? >>>> >>>> thanks! >>>> >>>> >>>> >>>> On Mon, May 12, 2014 at 11:15 AM, Jan Bartel wrote: >>>>> Daniel, >>>>> >>>>> Not sure exactly the lines in ServletHolder you're referring to, but I >>>>> assume its the synchronized block around line 652? If so, then this >>>>> code guards the initial startup of a servlet - if it isn't >>>>> load-on-startup, then any request coming in can initialize it. >>>>> Therefore, if you have multiple concurrent requests, you need to >>>>> protect the servlet startup so it happens only once. >>>>> >>>>> Jan >>>>> >>>>> On 8 May 2014 22:43, Daniel Feist wrote: >>>>>> Hi, >>>>>> >>>>>> I've been doing some testing/benchmarking of Jetty 8 with Mule ESB >>>>>> and >>>>>> seeming a decent amount of contention where it doesn't seem that >>>>>> synchronization is required. >>>>>> >>>>>> My test scenario is just a simple echo, all i do is read the request >>>>>> stream and then respond. The contention i'm seeing can be seen here: >>>>>> >>>>>> https://www.dropbox.com/s/bbkdsk7ndfpzoj9/Screen%20Shot%202014-05-08%20at%209.35.34%20PM.png >>>>>> >>>>>> Inspecting the code, I can't understand why this needs to even be >>>>>> synchonrized. >>>>>> >>>>>> Any thoughts? Is there a config option I should be using that i'm >>>>>> not? >>>>>> Is my test scenario unrealistic? >>>>>> >>>>>> thanks! >>>>>> Dan >>>>>> ___ >>>>>> jetty-users mailing list >>>>>> jetty-users@eclipse.org >>>>>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>>>> >>>>> >>>>> >>>>> -- >>>>> Jan Bartel >>>>> www.webtide.com >>>>> 'Expert Jetty/CometD developer,production,operations advice' >>>>> ___ >>>>> jetty-users mailing list >>>>> jetty-users@eclipse.org >>>>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>>> ___ >>>> jetty-users mailing list >>>> jetty-users@eclipse.org >>>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>>> >>> >>> >>> -- >>> Jan Bartel >>> www.webtide.com >>> 'Expert Jetty/CometD developer,production,operations advice' >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > > > -- > Jan Bartel > www.webtide.com > 'Expert Jetty/CometD developer,production,operations advice' > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Required file '${jetty.base}/etc/keystore' not downloaded warning
Jonathan,
That file is referred to in the ssl.mod file. I think its only for
demonstration purposes, so I think we need to break the ssl.mod file
into 2 pieces: an ssl-demo.mod file with the bits that are only for
demonstration purposes, and the ssl.mod file with what is essential.
Can you please raise a bug for that?
In your case, you could edit your ssl.mod file to remove the line, or
make an empty file.
Jan
On 14 May 2014 17:01, Jonathan Albrecht
wrote:
> I’m setting up jetty 9.1.4 with ssl and have moved the
> ${jetty.base}/etc/keystore to ${jetty.base}/../net/etc/keystore and it works
> but I’m getting a warning that ${jetty.base}/etc/keystore is a required
> file. Is there something I can configure to get rid of the warning? I’d
> prefer not to have to ship a ${jetty.base}/etc/keystore file.
>
>
>
> My config is below. I’ve set the location of the keystore with the
> jetty.keystore, jetty.truststore .ini vars.
>
>
>
> bash-4.1$ ../jre/bin/java -jar ../net/jetty/start.jar --list-config
>
>
>
> Java Environment:
>
> -
>
> java.home = /usr/local/uptime/jre
>
> java.vm.vendor = Oracle Corporation
>
> java.vm.version = 23.6-b04
>
> java.vm.name = Java HotSpot(TM) 64-Bit Server VM
>
> java.vm.info = mixed mode
>
> java.runtime.name = Java(TM) SE Runtime Environment
>
> java.runtime.version = 1.7.0_10-b18
>
> java.io.tmpdir = /tmp
>
> user.dir = /usr/local/uptime/eventstream
>
> user.language = en
>
> user.country = US
>
>
>
> Jetty Environment:
>
> -
>
> jetty.home = /usr/local/uptime/net/jetty
>
> jetty.base = /usr/local/uptime/eventstream
>
> jetty.version = 9.1.4.v20140401
>
>
>
> JVM Arguments:
>
> --
>
> (no jvm args specified)
>
>
>
> System Properties:
>
> --
>
> jetty.base = /usr/local/uptime/eventstream
>
> jetty.home = /usr/local/uptime/net/jetty
>
>
>
> Properties:
>
> ---
>
> https.port = 9993
>
> https.timeout = 3
>
> jetty.dump.start = false
>
> jetty.dump.stop = false
>
> jetty.keymanager.password = my_pass
>
> jetty.keystore = ../net/etc/keystore
>
> jetty.keystore.password = my_pass
>
> jetty.output.buffer.size = 32768
>
> jetty.request.header.size = 8192
>
> jetty.response.header.size = 8192
>
> jetty.secure.port = 9993
>
> jetty.send.date.header = false
>
> jetty.send.server.version = true
>
> jetty.truststore = ../net/etc/keystore
>
> jetty.truststore.password = my_pass
>
> threads.max = 200
>
> threads.min = 10
>
> threads.timeout = 6
>
>
>
> Jetty Server Classpath:
>
> ---
>
> Version Information on 12 entries in the classpath.
>
> Note: order presented here is how they would appear on the classpath.
>
> changes to the --module=name command line options will be reflected
> here.
>
> 0: 9.1.4.v20140401 |
> ${jetty.home}/lib/jetty-jmx-9.1.4.v20140401.jar
>
> 1:3.1.0 | ${jetty.home}/lib/servlet-api-3.1.jar
>
> 2: 3.1.0.M0 | ${jetty.home}/lib/jetty-schemas-3.1.jar
>
> 3: 9.1.4.v20140401 |
> ${jetty.home}/lib/jetty-http-9.1.4.v20140401.jar
>
> 4: 9.1.4.v20140401 |
> ${jetty.home}/lib/jetty-server-9.1.4.v20140401.jar
>
> 5: 9.1.4.v20140401 |
> ${jetty.home}/lib/jetty-xml-9.1.4.v20140401.jar
>
> 6: 9.1.4.v20140401 |
> ${jetty.home}/lib/jetty-util-9.1.4.v20140401.jar
>
> 7: 9.1.4.v20140401 | ${jetty.home}/lib/jetty-io-9.1.4.v20140401.jar
>
> 8: 9.1.4.v20140401 |
> ${jetty.home}/lib/jetty-security-9.1.4.v20140401.jar
>
> 9: 9.1.4.v20140401 |
> ${jetty.home}/lib/jetty-servlet-9.1.4.v20140401.jar
>
> 10: 9.1.4.v20140401 |
> ${jetty.home}/lib/jetty-webapp-9.1.4.v20140401.jar
>
> 11: 9.1.4.v20140401 |
> ${jetty.home}/lib/jetty-deploy-9.1.4.v20140401.jar
>
>
>
> Jetty Active XMLs:
>
> --
>
> ${jetty.home}/etc/jetty-jmx.xml
>
> ${jetty.home}/etc/jetty-logging.xml
>
> ${jetty.home}/etc/jetty.xml
>
> ${jetty.base}/etc/jetty-ssl.xml
>
> ${jetty.home}/etc/jetty-https.xml
>
> ${jetty.home}/etc/jetty-deploy.xml
>
> WARNING: Required file '${jetty.base}/etc/keystore' not downloaded from
> http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/plain/jetty-server/src/main/config/etc/keystore.
> Run with --create-files to download
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty startup directory
Kyle, In general, the jetty-maven-plugin is only designed to be used from a webapp module. Jan On 23 May 2014 20:42, Kyle Mera wrote: > Hello fellow Jetty users, > > I have a multi-module project that includes a war-project that runs a Jetty > server. > > Core > > api -> impl -> war > > When I run mvn jetty:run from the war module directory everything works as > expected. The database files are saved in war/target/database. > However, when I run any maven command from the core project, Jetty uses the > core directory to base the server. So the /target directory that is supposed > to be in the war project gets placed in the core directory. > Jetty starts from the war module so I'm not sure why it is using the core > directory as it's base. > > Are their any configurations I can use to enable Jetty to run from the war > directory instead of the core directory or is implemented by design? > > Thanks! > > -- > Kyle Mera - Software Engineer Intern > AgileSrc LLC > 3259 Progress Drive, Suite 159 > Orlando, FL 32826 > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty startup directory
Can you post the relevant snippets from your web module pom.xml? Jan On 24 May 2014 16:24, Kyle Mera wrote: > Jan, > > The Core project simply traverses the 3 sub-projects. So when I run mvn > clean install from the core project it runs tests on all 3 projects. When it > gets to the war project it starts up jetty just fine, the only issue is that > it references the core directory while running, which throws my tests out of > whack. > From my understanding, that is still running it from the webapp module since > the core traverses down to the war project. > > Kyle > > > On Sat, May 24, 2014 at 4:47 AM, Jan Bartel wrote: >> >> Kyle, >> >> In general, the jetty-maven-plugin is only designed to be used from a >> webapp module. >> >> Jan >> >> On 23 May 2014 20:42, Kyle Mera wrote: >> > Hello fellow Jetty users, >> > >> > I have a multi-module project that includes a war-project that runs a >> > Jetty >> > server. >> > >> > Core >> > >> > api -> impl -> war >> > >> > When I run mvn jetty:run from the war module directory everything works >> > as >> > expected. The database files are saved in war/target/database. >> > However, when I run any maven command from the core project, Jetty uses >> > the >> > core directory to base the server. So the /target directory that is >> > supposed >> > to be in the war project gets placed in the core directory. >> > Jetty starts from the war module so I'm not sure why it is using the >> > core >> > directory as it's base. >> > >> > Are their any configurations I can use to enable Jetty to run from the >> > war >> > directory instead of the core directory or is implemented by design? >> > >> > Thanks! >> > >> > -- >> > Kyle Mera - Software Engineer Intern >> > AgileSrc LLC >> > 3259 Progress Drive, Suite 159 >> > Orlando, FL 32826 >> > >> > ___ >> > jetty-users mailing list >> > jetty-users@eclipse.org >> > https://dev.eclipse.org/mailman/listinfo/jetty-users >> > >> >> >> >> -- >> Jan Bartel >> www.webtide.com >> 'Expert Jetty/CometD developer,production,operations advice' >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > > -- > Kyle Mera - Software Engineer Intern > AgileSrc LLC > 3259 Progress Drive, Suite 159 > Orlando, FL 32826 > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty startup directory
Kyle, Do you have your pom.xml configured for your unit tests according to the following doco: http://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html#jetty-start-goal ? Jan On 25 May 2014 19:19, Kyle Mera wrote: > War - Pom.xml > > > > org.mortbay.jetty > maven-jetty-plugin > 6.1.26 > > true > > > true > > > > 9898 > > > / > > > > > On Sun, May 25, 2014 at 9:15 AM, Jan Bartel wrote: >> >> Can you post the relevant snippets from your web module pom.xml? >> >> Jan >> >> On 24 May 2014 16:24, Kyle Mera wrote: >> > Jan, >> > >> > The Core project simply traverses the 3 sub-projects. So when I run mvn >> > clean install from the core project it runs tests on all 3 projects. >> > When it >> > gets to the war project it starts up jetty just fine, the only issue is >> > that >> > it references the core directory while running, which throws my tests >> > out of >> > whack. >> > From my understanding, that is still running it from the webapp module >> > since >> > the core traverses down to the war project. >> > >> > Kyle >> > >> > >> > On Sat, May 24, 2014 at 4:47 AM, Jan Bartel wrote: >> >> >> >> Kyle, >> >> >> >> In general, the jetty-maven-plugin is only designed to be used from a >> >> webapp module. >> >> >> >> Jan >> >> >> >> On 23 May 2014 20:42, Kyle Mera wrote: >> >> > Hello fellow Jetty users, >> >> > >> >> > I have a multi-module project that includes a war-project that runs a >> >> > Jetty >> >> > server. >> >> > >> >> > Core >> >> > >> >> > api -> impl -> war >> >> > >> >> > When I run mvn jetty:run from the war module directory everything >> >> > works >> >> > as >> >> > expected. The database files are saved in war/target/database. >> >> > However, when I run any maven command from the core project, Jetty >> >> > uses >> >> > the >> >> > core directory to base the server. So the /target directory that is >> >> > supposed >> >> > to be in the war project gets placed in the core directory. >> >> > Jetty starts from the war module so I'm not sure why it is using the >> >> > core >> >> > directory as it's base. >> >> > >> >> > Are their any configurations I can use to enable Jetty to run from >> >> > the >> >> > war >> >> > directory instead of the core directory or is implemented by design? >> >> > >> >> > Thanks! >> >> > >> >> > -- >> >> > Kyle Mera - Software Engineer Intern >> >> > AgileSrc LLC >> >> > 3259 Progress Drive, Suite 159 >> >> > Orlando, FL 32826 >> >> > >> >> > ___ >> >> > jetty-users mailing list >> >> > jetty-users@eclipse.org >> >> > https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> > >> >> >> >> >> >> >> >> -- >> >> Jan Bartel >> >> www.webtide.com >> >> 'Expert Jetty/CometD developer,production,operations advice' >> >> ___ >> >> jetty-users mailing list >> >> jetty-users@eclipse.org >> >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > >> > >> > >> > >> > -- >> > Kyle Mera - Software Engineer Intern >> > AgileSrc LLC >> > 3259 Progress Drive, Suite 159 >> > Orlando, FL 32826 >> > >> > ___ >> > jetty-users mailing list >> > jetty-users@eclipse.org >> > https://dev.eclipse.org/mailman/listinfo/jetty-users >> > >> >> >> >> -- >> Jan Bartel >> www.webtide.com >> 'Expert Jetty/CometD developer,production,operations advice' >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > > -- > Kyle Mera - Software Engineer Intern > AgileSrc LLC > 3259 Progress Drive, Suite 159 > Orlando, FL 32826 > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty startup directory
Geeze Kyle, jetty-6?! We're up to 9.2.0 :)
In all versions of the jetty maven plugin, we look to make the webapp
tmp dir in the maven project build directory, specified as:
${project.build.directory}
Jan
On 26 May 2014 21:53, Kyle Mera wrote:
> Jan,
>
> Here is the full plugin
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> 6.1.26
>
> true
>
>
> true
>
>
>
> 9898
>
>
> /
>
>
>
>
>
> start-jetty
> pre-integration-test
>
> run
>
>
> true
>
>
> 9898
>
>
>
>
>
> stop-jetty
> post-integration-test
>
>
>
>
>
> On Mon, May 26, 2014 at 6:57 AM, Jan Bartel wrote:
>>
>> Kyle,
>>
>> Do you have your pom.xml configured for your unit tests according to
>> the following doco:
>>
>> http://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html#jetty-start-goal
>>
>> ?
>>
>> Jan
>>
>> On 25 May 2014 19:19, Kyle Mera wrote:
>> > War - Pom.xml
>> >
>> >
>> >
>> > org.mortbay.jetty
>> > maven-jetty-plugin
>> > 6.1.26
>> >
>> > true
>> >
>> >
>> > true
>> >
>> >
>> > > > implementation="org.mortbay.jetty.nio.SelectChannelConnector">
>> > 9898
>> >
>> >
>> > /
>> >
>> >
>> >
>> >
>> > On Sun, May 25, 2014 at 9:15 AM, Jan Bartel wrote:
>> >>
>> >> Can you post the relevant snippets from your web module pom.xml?
>> >>
>> >> Jan
>> >>
>> >> On 24 May 2014 16:24, Kyle Mera wrote:
>> >> > Jan,
>> >> >
>> >> > The Core project simply traverses the 3 sub-projects. So when I run
>> >> > mvn
>> >> > clean install from the core project it runs tests on all 3 projects.
>> >> > When it
>> >> > gets to the war project it starts up jetty just fine, the only issue
>> >> > is
>> >> > that
>> >> > it references the core directory while running, which throws my tests
>> >> > out of
>> >> > whack.
>> >> > From my understanding, that is still running it from the webapp
>> >> > module
>> >> > since
>> >> > the core traverses down to the war project.
>> >> >
>> >> > Kyle
>> >> >
>> >> >
>> >> > On Sat, May 24, 2014 at 4:47 AM, Jan Bartel wrote:
>> >> >>
>> >> >> Kyle,
>> >> >>
>> >> >> In general, the jetty-maven-plugin is only designed to be used from
>> >> >> a
>> >> >> webapp module.
>> >> >>
>> >> >> Jan
>> >> >>
>> >> >> On 23 May 2014 20:42, Kyle Mera wrote:
>> >> >> > Hello fellow Jetty users,
>> >> >> >
>> >> >> > I have a multi-module project that includes a war-project that
>> >> >> > runs a
>> >> >> > Jetty
>> >> >> > server.
>> >> >> >
>> >> >> > Core
>> >> >> >
>> >> >> > api -> impl -> war
>> >> >> >
>> >> >> > When I run mvn jetty:run from the war module directory everything
>> >> >> > works
>> >> >> > as
>> >> >> > expected. The database files are saved in war/target/database.
>> >> >> > However, when I run any maven command from the core project, Jetty
>> >> >> > uses
>> >> >> > the
>> >> >> > core directory to base the server. So the /target directory that
>> >> >> > is
>> >> >> > supposed
>> >> >> > to be in the war project gets placed in the core directory.
>> >> >> > Jetty starts from the war module so I'm not sure why it is using
>> >> >> > the
>> >> >> > core
>> >> >> > directory as it's base.
>> >> >> >
>> >> >> > Are their any configurations I can use to enable Jetty to run from
>> >> >> > the
>> >> >> > war
>> >> >> > directory instead of the core directory or is impleme
Re: [jetty-users] Migrating to jetty 9
Shreshth, You've probably got conflicting versions of the java mail api jar on the classpath. Jan On 26 May 2014 11:40, shreshth wadhwa wrote: > Hi, > > We have a web application running on Jetty 8 with Comet 2.7. Now we upgraded > the Jetty to Jetty 9.0.7. We are facing an issue now that we are unable to > send emails through our application. > > > > If we move our application back to Jetty 8 the problem is solved. > > > > The JDK version we are using is jdk1.7.0_51 > > > > We are getting the following error in the logs. > > > > Caused by: java.lang.NoSuchMethodError: > javax.mail.Session.getInstance(Ljava/util/Properties;)Ljavax/mail/Session; > > at > org.springframework.mail.javamail.JavaMailSenderImpl.getSession(JavaMailSenderImpl.java:155) > > at > org.springframework.mail.javamail.JavaMailSenderImpl.createMimeMessage(JavaMailSenderImpl.java:325) > > > > > > Please help me in this regard. > > Thanks, > Shreshth > > > _______ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Railo Express (Jetty) File Upload Issue
Cory, Can you post your jetty config and web.xml setup? Jan On 19 June 2014 21:54, Cory Fail wrote: > I'm attempting to upload a 1 GB file with jetty. The code can be seen here: > > https://gist.github.com/CoryFail/26ce829f60198d8d951b > > It works perfectly on Tomcat but with Jetty the upload is uploading the file > partially multiple times and then times out. It looks like this: > > Folder 1 > Uploaded File (24MB) > Folder 2 > Uploaded File (2MB) > Folder 3 > Uploaded File (78MB) > > When it should just be: > > Folder 1 > Uploaded File (1GB) > > Any ideas what the issue is? > > Cory C. Fail > Software Engineer > coryfail.com / 912.257.0840 > "Don't give into wild currents." > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] jetty native memory leak
Dhiraj, That thread dump just shows an idle thread. In past versions of jetty, there were issues with jdk epoll bugs, but they manifested themselves as cpu spin. So if you're not seeing undue cpu activity then this is not a problem. Jan On 23 June 2014 14:57, dhiraj prajapati wrote: > I am using Jetty 9.1.2 in my application. The application uses huge native > memory space. In the thread dump, I see a lot of instances like: > > "qtp2042324703-524-selector-ServerConnectorManager@5c95306c/7" prio=10 > tid=0x7f4c1985a000 nid=0xb7bb runnable [0x7f4c0ef6e000] >java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) > - locked <0xbff941a8> (a sun.nio.ch.Util$2) > - locked <0xbff94198> (a > java.util.Collections$UnmodifiableSet) > - locked <0xbff941b8> (a sun.nio.ch.EPollSelectorImpl) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:102) > at > org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:531) > at > org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:484) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536) > at java.lang.Thread.run(Thread.java:744) > > I need some help to sort this out. Is this a known bug which is fixed in a > later release? > > Regards, > > Dhiraj > > > ___________ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] jetty native memory leak
Dhiraj, 500 threads in the pool lying idle is not necessarily a problem - you should check your connector configuration. Also do several thread dumps a minute or so apart to check on the thread activity. If there's no traffic or very little traffic, then your threads may all indeed mostly be idle, particularly if you had a traffic spike and jetty needed to spin up more threads (up to the max you have configured) to deal with it. In any case, have a read of our page on memory leak issues: http://www.eclipse.org/jetty/documentation/current/preventing-memory-leaks.html Jan On 24 June 2014 11:15, dhiraj prajapati wrote: > Thanks Thomas. > But It is the native memory that is being eaten up and not the heap memory. > So I don't think Memory Analyzer will be of any help here. I am just > concerned about the sheer number of RUNNABLE threads. It was more than 500. > Can we be sure that they are just lying idle, because the thread dump shows > them in RUNNABLE state? > > Regards, > Dhiraj > > > On Tue, Jun 24, 2014 at 2:38 PM, Thomas Becker > wrote: >> >> Hi Dhiraj, >> >> then use jmap to create a heap dump and browse that dump by using a tool >> like Eclipse Memory Analyzer, jhat or a Java Profiler that can read heap >> dumps. There you'll find what's occupying your memory. The idle thread you >> postet below is no harm as Jan already stated. >> >> Cheers, >> Thomas >> >> On 24/06/14 11:03, dhiraj prajapati wrote: >> >> Hi, >> But the application is using a lot of native memory and it ends up using a >> lot of swap space after which I am forced to restart the application. >> >> Regards, >> Dhiraj >> >> >> On Tue, Jun 24, 2014 at 1:20 PM, Jan Bartel wrote: >>> >>> Dhiraj, >>> >>> That thread dump just shows an idle thread. In past versions of jetty, >>> there were issues with jdk epoll bugs, but they manifested themselves >>> as cpu spin. So if you're not seeing undue cpu activity then this is >>> not a problem. >>> >>> Jan >>> >>> On 23 June 2014 14:57, dhiraj prajapati wrote: >>> > I am using Jetty 9.1.2 in my application. The application uses huge >>> > native >>> > memory space. In the thread dump, I see a lot of instances like: >>> > >>> > "qtp2042324703-524-selector-ServerConnectorManager@5c95306c/7" prio=10 >>> > tid=0x7f4c1985a000 nid=0xb7bb runnable [0x7f4c0ef6e000] >>> >java.lang.Thread.State: RUNNABLE >>> > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) >>> > at >>> > sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) >>> > at >>> > sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) >>> > at >>> > sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) >>> > - locked <0xbff941a8> (a sun.nio.ch.Util$2) >>> > - locked <0xbff94198> (a >>> > java.util.Collections$UnmodifiableSet) >>> > - locked <0xbff941b8> (a sun.nio.ch.EPollSelectorImpl) >>> > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) >>> > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:102) >>> > at >>> > >>> > org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:531) >>> > at >>> > >>> > org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:484) >>> > at >>> > >>> > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607) >>> > at >>> > >>> > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536) >>> > at java.lang.Thread.run(Thread.java:744) >>> > >>> > I need some help to sort this out. Is this a known bug which is fixed >>> > in a >>> > later release? >>> > >>> > Regards, >>> > >>> > Dhiraj >>> > >>> > >>> > ___ >>> > jetty-users mailing list >>> > jetty-users@eclipse.org >>> > https://dev.eclipse.org/mailman/listinfo/jetty-users >>> > >>> >>> >>> >>> -- >>> Jan Bartel >>> www.webtide.com >>> 'Expert Jetty/CometD developer,production,operations advice' >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> >> >> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> >> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 8.1.14 Regenerating JSPs after server restart
Andy, development=true should be enough. I suggest you turn on debugging (jasper uses java util logging, so enable logging at the finest level for org.apache.jasper) and see if that helps. The other thing to check is to make sure that the timestamps on the .jsp files are not being updated so they are indeed more recent than the .class files. In fact, make sure that the .class files aren't being deleted during the stop/start. cheers Jan On 24 June 2014 15:26, Andy Stoneberg wrote: > Greetings, > > I am noticing an issue where JSP pages are getting completely regenerated > following a server restart (I am using an Eclipse Plug-in Project - so its > an Equinox/OSGi application). > > I have found this page that lists various configuration properties: > https://wiki.eclipse.org/Jetty/Howto/Configure_JSP > > In debugging, I do see that we have development = 'true', but that should > only have it check for a 'possible' recompilation. I am seeing it always > recompiles. What are the criteria around whether or not to compile? Can > someone help me with what configuration parameters I should be using? > > Thanks! > > Andy > > p.s. I was trying to post this message via the forum, but kept getting a > mailer-daemon error saying I am not subscribed - even though I am...sorry > for the spam that may have caused... > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 8.1.14 Regenerating JSPs after server restart
Andy, Here's the jetty-8 doco on tmp directories (where the jsps are compiled): http://wiki.eclipse.org/Jetty/Reference/Temporary_Directories Jan On 24 June 2014 21:08, Andy Stoneberg wrote: > Is there any way to preserve the compiled files between restarts of the > server? > > > On Tue, Jun 24, 2014 at 12:07 PM, Michael Dykman wrote: >> >> You should expect JSPs to recompile after a restart as there is no >> permanent cache for the compiled class files. At runtime, they are >> compiled and deployed and when the server shuts down, the temporary >> space they have been compiled to vanishes. If your unmodified JSPs are >> recompiling between requests with a restart, then you might have a >> configuration or timestamp issue. >> >> On Tue, Jun 24, 2014 at 11:54 AM, Jan Bartel wrote: >> > Andy, >> > >> > development=true should be enough. I suggest you turn on debugging >> > (jasper uses java util logging, so enable logging at the finest level >> > for org.apache.jasper) and see if that helps. The other thing to check >> > is to make sure that the timestamps on the .jsp files are not being >> > updated so they are indeed more recent than the .class files. In fact, >> > make sure that the .class files aren't being deleted during the >> > stop/start. >> > >> > cheers >> > Jan >> > >> > On 24 June 2014 15:26, Andy Stoneberg wrote: >> >> Greetings, >> >> >> >> I am noticing an issue where JSP pages are getting completely >> >> regenerated >> >> following a server restart (I am using an Eclipse Plug-in Project - so >> >> its >> >> an Equinox/OSGi application). >> >> >> >> I have found this page that lists various configuration properties: >> >> https://wiki.eclipse.org/Jetty/Howto/Configure_JSP >> >> >> >> In debugging, I do see that we have development = 'true', but that >> >> should >> >> only have it check for a 'possible' recompilation. I am seeing it >> >> always >> >> recompiles. What are the criteria around whether or not to compile? >> >> Can >> >> someone help me with what configuration parameters I should be using? >> >> >> >> Thanks! >> >> >> >> Andy >> >> >> >> p.s. I was trying to post this message via the forum, but kept getting >> >> a >> >> mailer-daemon error saying I am not subscribed - even though I >> >> am...sorry >> >> for the spam that may have caused... >> >> >> >> ___ >> >> jetty-users mailing list >> >> jetty-users@eclipse.org >> >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> >> > >> > >> > >> > -- >> > Jan Bartel >> > www.webtide.com >> > 'Expert Jetty/CometD developer,production,operations advice' >> > ___ >> > jetty-users mailing list >> > jetty-users@eclipse.org >> > https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> >> >> -- >> - michael dykman >> - mdyk...@gmail.com >> >> May the Source be with you. >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Using override-web.xml
Eric, Can you post which version of jetty you are using, and also the relevant sections from your web.xml. Jan On 24 June 2014 22:29, Eric Rizzo wrote: > I’m trying to use the override-web.xml feature > (https://www.eclipse.org/jetty/documentation/current/override-web-xml.html) > to override some of the web.xml configuration in an app. There are two parts > of web.xml that I need to override, the and > . So my WebAppContext configuration includes this: > > > > override-web.xml > > > > And my override-web.xml look like this: > > > > > > http://www.w3.org/2001/XMLSchema-instance"; > xmlns="http://java.sun.com/xml/ns/javaee"; > xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"; > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"; id="WebApp_ID" > version="2.5"> > > > > > > > > Protected Area > > > > /* > > GET > > POST > > > > > > > > NONE > > > > > > > > > > FORM > > Health E Systems > > > > /login/login.html > > > /login/login_error.html > > > > > > > > > > > > It seems that the is working (when I run I am not > required to use https), but the login page doesn’t seem to be working. I am > not automatically redirected to that page as expected (it does work as > intended if I simply change the value directly in the > app’s web.xml). > > Am I doing something wrong? Is there a limit as to what can be overridden > with this capability? > > > > Thanks, > > Eric > > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Using override-web.xml
Eric,
Thanks for that. In general, elements in web.xml that can have
multiple occurences will have additive behaviour if also specified in
web-override.xml, and be replaced if they may have only 0 or 1
occurences in web.xml
Try calling server.setDumpAfterStart(true) (eg in jetty.xml via true) and posting what you get out.
I'm afraid I can't help you with the specifics of the Jetty Launcher
Plugin as I'm not familiar with it.
Jan
On 25 June 2014 16:04, Eric Rizzo wrote:
> Jetty 8.1.14
>
> Here's the as-is web.xml. Note that it's using variable substitution from
> maven properties for and , which is
> one reason I want to override it; I'm trying to launch the app in Jetty
> before/without the maven properties substitution.
>
>
> x
>
> Protected Area
>
> /*
> GET
> POST
>
>
> manager
> newprospect
> customer
> cadmin
>
>
>
>
> ${web.security.constraint}
>
>
>
>
> FORM
> Health E Systems
>
> /${login.form.page}
> /login/login_error.html
>
>
>
>
> I don't know if this info makes any difference but I'm using the Eclipse
> Jetty Launcher Plugin (http://eclipse-jetty.sourceforge.net/) to launch
> (since there doesn't appear to be a Jetty connector for WTP). I've modified
> that plugin to include in the app context configuration.
>
> Eric
>
>
>> -Original Message-
>> From: jetty-users-boun...@eclipse.org [mailto:jetty-users-
>> boun...@eclipse.org] On Behalf Of Jan Bartel
>> Sent: Wednesday, June 25, 2014 4:16 AM
>> To: JETTY user mailing list
>> Subject: Re: [jetty-users] Using override-web.xml
>>
>> Eric,
>>
>> Can you post which version of jetty you are using, and also the relevant
>> sections from your web.xml.
>>
>> Jan
>>
>> On 24 June 2014 22:29, Eric Rizzo wrote:
>> > I’m trying to use the override-web.xml feature
>> > (https://www.eclipse.org/jetty/documentation/current/override-web-
>> xml.
>> > html) to override some of the web.xml configuration in an app. There
>> > are two parts of web.xml that I need to override,
>> > the and . So my WebAppContext
>> > configuration includes this:
>> >
>> >
>> >
>> > override-web.xml
>> >
>> >
>> >
>> > And my override-web.xml look like this:
>> >
>> >
>> >
>> >
>> >
>> > http://www.w3.org/2001/XMLSchema-instance";
>> > xmlns="http://java.sun.com/xml/ns/javaee";
>> > xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd";
>> > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>> > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"; id="WebApp_ID"
>> > version="2.5">
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Protected
>> > Area
>> >
>> >
>> >
>> > /*
>> >
>> > GET
>> >
>> > POST
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > NONE
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > FORM
>> >
>> > Health E Systems
>> >
>> >
>> >
>> >
>> > /login/login.html
>> >
>> >
>> > /login/login_error.html
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > It seems that the is working (when I run I am
>> > not required to use https), but the login page doesn’t seem to be
>> > working. I am not automatically redirected to that page as expected
>> > (it does work as intended if I simply change the
>> > value directly in the app’s web.xml).
>> >
>> > Am I doing something wrong? Is there a limit as to what can be
>> > overridden with this capability?
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Eric
>> >
>> >
>> >
>> >
>> > ___
>> > jetty-users mailing list
>> > jetty-users@eclipse.org
>> > https://dev.eclipse.org/mailman/listinfo/jetty-users
>> >
>>
>>
>>
>> --
>> Jan Bartel
>> www.webtide.com
>> 'Expert Jetty/CometD developer,production,operations advice'
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Difficulty with jetty-maven-plugin and jmx
Jim,
Using the systemProperties configuration for the plugin means that
they cannot be set until the plugin runs - for some types of system
properties that's simply too late and they have to be set at the time
the jvm starts. Try using MAVEN_OPTS environment variable instead.
Jan
On 30 June 2014 19:58, Jim Garrison wrote:
> I'm trying to set system properties to enable JMX (the
> com.sun.management.jmxremote.* properties) but when I run
>
>mvn jetty:run
>
> JMX does not get enabled (nothing listening on port 1099). Here's my plugin
> configuration (${jetty.version} = 9.1.0.v20131115)
>
>
> org.eclipse.jetty
> jetty-maven-plugin
> ${jetty.version}
>
> 9967
> password
>
> /
>
>
>
> com.sun.management.jmxremote
>
> com.sun.management.jmxremote.sslfalse
>
> com.sun.management.jmxremote.authenticatefalse
>
> com.sun.management.jmxremote.port1099
>
>
>
>
> I ran Maven with the -X option and the debug log appears to show that the
> properties are being set correctly (see below). Obviously I'm missing
> something simple... any ideas?
>
> ...
>
> [DEBUG]
> ---
> [DEBUG] Goal:
> org.eclipse.jetty:jetty-maven-plugin:9.1.0.v20131115:run (default-cli)
> [DEBUG] Style: Regular
> [DEBUG] Configuration:
>
> ${project.build.outputDirectory}
> ${jetty.daemon}
> ${mojoExecution}
> ${plugin.artifacts}
> ${project}
> ${project.artifacts}
> ${jetty.reload}
>default-value="0">${jetty.scanIntervalSeconds}
> ${jetty.skip}
> password
> 9967
>
>
> com.sun.management.jmxremote
>
>
>
> com.sun.management.jmxremote.ssl
> false
>
>
> com.sun.management.jmxremote.authenticate
> false
>
>
> com.sun.management.jmxremote.port
> 1099
>
>
> ${jetty.systemPropertiesFile}
>
> ${project.build.testOutputDirectory}
>
>
>
> /
>
> ${maven.war.src}
> ${maven.war.webxml}
>
>
> ...
>
> [DEBUG] Configuring mojo
> org.eclipse.jetty:jetty-maven-plugin:9.1.0.v20131115:run from plugin realm
> ClassRealm[plugin>org.eclipse.jetty:jetty-maven-plugin:9.1.0.v20131115,
> parent: sun.misc.Launcher$AppClas
> sLoader@749cd006]
>
> ...
>
> [DEBUG] (s) name = com.sun.management.jmxremote
> [DEBUG] (s) systemProperty =
> org.eclipse.jetty.maven.plugin.SystemProperty@45fda6a8
> [DEBUG] (s) name = com.sun.management.jmxremote.ssl
> [DEBUG] (s) value = false
> [DEBUG] (s) systemProperty =
> org.eclipse.jetty.maven.plugin.SystemProperty@fc8837e
> [DEBUG] (s) name = com.sun.management.jmxremote.authenticate
> [DEBUG] (s) value = false
> [DEBUG] (s) systemProperty =
> org.eclipse.jetty.maven.plugin.SystemProperty@3530cd4a
> [DEBUG] (s) name = com.sun.management.jmxremote.port
> [DEBUG] (s) value = 1099
> [DEBUG] (s) systemProperty =
> org.eclipse.jetty.maven.plugin.SystemProperty@16f5d08e
> [DEBUG] (s) systemProperties =
> org.eclipse.jetty.maven.plugin.SystemProperties@644f2668
> [DEBUG] (f) testClassesDirectory =
> C:\dev\git\etl3\etl-server\target\test-classes
> [DEBUG] (f) useProvidedScope = false
> [DEBUG] (f) useTestScope = false
> [DEBUG] (s) contextPath = /
> [DEBUG] (f) webApp = o.e.j.m.p.JettyWebAppContext@7a8eb36a{/,null,null}
> [DEBUG] -- end configuration --
> [INFO] Configuring Jetty for project: etl-server
> [INFO] webAppSourceDirectory not set. Trying src\main\webapp
> [INFO] Reload Mechanic: automatic
> [INFO] Classes = C:\dev\git\etl3\etl-server\target\classes
> [DEBUG] Starting Jetty Server ...
> [DEBUG] Property com.sun.management.jmxremote.port=1099 was set
> [DEBUG] Property com.sun.management.jmxremote.ssl=false was set
> [DEBUG] Property com.sun.management.jmxremote=null was set
> [DEBUG] Property com.sun.management.jmxremote.authenticate=false was set
> [INFO] Context path = /
> [INFO] Tmp directory = C:\dev\git\etl3\etl-server\target\tmp
> [INFO] Web defaults = org/eclipse/jetty/webapp/webdefault.xml
> [INFO] Web overrides = none
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Migrating to jetty 9
copedHandler.handle(ScopedHandler.java:138) >> >> at >> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:564) >> >> at >> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:213) >> >> at >> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1097) >> >> at >> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:448) >> >> at >> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:175) >> >> at >> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1031) >> >> at >> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:136) >> >> at >> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:200) >> >> at >> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109) >> >> at >> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) >> >> at org.eclipse.jetty.server.Server.handle(Server.java:446) >> >> at >> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:271) >> >> at >> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:246) >> >> at >> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358) >> >> at >> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601) >> >> at >> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532) >> >> at java.lang.Thread.run(Thread.java:744) >> >> Thanks, >> Shreshth >> >> On 28 May 2014 15:14, "Jan Bartel" wrote: >>> >>> Shreshth, >>> >>> You've probably got conflicting versions of the java mail api jar on >>> the classpath. >>> >>> Jan >>> >>> On 26 May 2014 11:40, shreshth wadhwa wrote: >>> > Hi, >>> > >>> > We have a web application running on Jetty 8 with Comet 2.7. Now we >>> > upgraded >>> > the Jetty to Jetty 9.0.7. We are facing an issue now that we are unable >>> > to >>> > send emails through our application. >>> > >>> > >>> > >>> > If we move our application back to Jetty 8 the problem is solved. >>> > >>> > >>> > >>> > The JDK version we are using is jdk1.7.0_51 >>> > >>> > >>> > >>> > We are getting the following error in the logs. >>> > >>> > >>> > >>> > Caused by: java.lang.NoSuchMethodError: >>> > >>> > javax.mail.Session.getInstance(Ljava/util/Properties;)Ljavax/mail/Session; >>> > >>> > at >>> > >>> > org.springframework.mail.javamail.JavaMailSenderImpl.getSession(JavaMailSenderImpl.java:155) >>> > >>> > at >>> > >>> > org.springframework.mail.javamail.JavaMailSenderImpl.createMimeMessage(JavaMailSenderImpl.java:325) >>> > >>> > >>> > >>> > >>> > >>> > Please help me in this regard. >>> > >>> > Thanks, >>> > Shreshth >>> > >>> > >>> > ___ >>> > jetty-users mailing list >>> > jetty-users@eclipse.org >>> > https://dev.eclipse.org/mailman/listinfo/jetty-users >>> > >>> >>> >>> >>> -- >>> Jan Bartel >>> www.webtide.com >>> 'Expert Jetty/CometD developer,production,operations advice' >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Parsing of URL
Martin, /lgnrg is not the same as /lgnrg/whatever. If you have configured the servlet to match the url-pattern /lgnrg, only requests that exactly end in /lgnrg will match exactly (request params are ok like ?x=y as these don't form part of the matching algorithm). A trailing "/" announces another path segment. If you want to match /lgnrg/whatever (where 'whatever' can be empty or arbitrarily deep) then you need to use the url-pattern in the servlet declaration of /lgnrg/* You should see this if you do it at the command line with the 2 different urls you supplied in your email: https://apply.satac.edu.au/lgnrg/x?loginCycle=unis2014 and https://apply.satac.edu.au/lgnrg?loginCycle=unis2014 Jan On 2 July 2014 01:07, Martin Edge wrote: > The system is embedded and configured so that both URLs use the same servlet > via the one configuration (IE "/lgnrg" goes to > RegistrationLoginServlet.class). > > I would have assumed that this would be irrelevant and both URLs would be > the same, it is just a weird occurrence and after exhausting other avenues > of investigation I’d thought I’d ask other users who might have come across > this before. > > I am not surprised at all that it isn’t a jetty issue, but I am lost as to > why this would occur. As it occurs only under load it might simply be the > load testing itself. > > > > Anyway, thanks for the response, > > > > -medge > > > > > > > > From: jetty-users-boun...@eclipse.org > [mailto:jetty-users-boun...@eclipse.org] On Behalf Of Joakim Erdfelt > Sent: Wednesday, 2 July 2014 03:13 > To: JETTY user mailing list > Subject: Re: [jetty-users] Parsing of URL > > > > Not enough information to go on. > > Its highly unlikely to be a URL parsing issue. > > As your two examples are about as simple as URLs can get. > > You'll probably want to profile your two requests and see what is using all > of the resources/time, or what is waiting so long. > > > -- > > Joakim Erdfelt > > webtide.com - intalio.com/jetty > > Expert advice, services and support from from the Jetty & CometD experts > > eclipse.org/jetty - cometd.org > > > > On Mon, Jun 30, 2014 at 9:07 PM, Martin Edge > wrote: > > Currently have a Jetty 9.1.5 and have done a load test on the main server. > > > > It loaded one page (https://apply.satac.edu.au/lgnrg/x?loginCycle=unis2014) > quickly, but another which uses exactly the same code > (https://apply.satac.edu.au/lgnrg?loginCycle=unis2014) really slowly. > > The only thing I can think of is that there is a parsing issue. The work > around is obvious(use the /), but is there an issue inside Jetty that would > explain this or do I need to look further into it at my end? > > > > -medge > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Load-time weaving of servlets?
e that you are decorating the wrong location/classes for your > coverage. > > Try a server dump, it will show you what classes jetty is using. (it might > not be what you assume) > > To set this up with the jetty-maven-plugin > > Create a jetty-dump.xml (or whatever name you want) > > > "http://www.eclipse.org/jetty/configure_9_0.dtd";> > > true > > > Then configure the plugin to use it ... > > > org.eclipse.jetty > jetty-maven-plugin > > jetty-dump.xml > > > > The STDERR / STDOUT should have a lot of extra information in it now. > > -- > Joakim Erdfelt > webtide.com - intalio.com/jetty > Expert advice, services and support from from the Jetty & CometD experts > eclipse.org/jetty - cometd.org > > > > > _______ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] HTTP ERROR 500 - No org.apache.tomcat.InstanceManager
Joe, You'll have to provide some more information, such as which modules you have enabled, what your settings are. Use --list-config and --list-modules to check. That error usually occurs when the jsp engine is not properly initialized. Jan On 15 July 2014 01:52, Joe b wrote: > Attempting to access jsp page via browser after launching jetty from base > dir (not within home) results: > > > HTTP ERROR 500 > > Problem accessing /test/index.jsp. Reason: > > Server Error > > Caused by: > > org.apache.jasper.JasperException: java.lang.IllegalStateException: No > org.apache.tomcat.InstanceManager set in ServletContext > >at > org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:177) > > > > launch: > > > d:\jettybase>java -jar C:\jetty\jetty-distribution-9.2.1.v20140609\start.jar > > > browser: > > http://localhost:8080/test/index.jsp > > > Does not happen if launching jetty via mvn jetty:run > > > Any ideas? > > > Regards, > > > -J > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] GzipHandler doesn't work
Looks like there were a couple of bugs fixed recently, so should be in 9.2.2: https://bugs.eclipse.org/bugs/show_bug.cgi?id=439652 https://bugs.eclipse.org/bugs/show_bug.cgi?id=438366 Jan On 21 July 2014 15:36, fschmidt wrote: > I recently upgraded from Jetty 7 to Jetty 9. (I try to avoid upgrading any > software these days since software universally just seems to be getting > worse, but I needed some new features.) Upgrading broke GzipHandler which > used to work fine. If I wrap GzipHandler around HelloHandler, GzipHandler > does nothing. If I wrap GzipHandler around ResourceHandler, GzipHandler > breaks ResourceHandler completely. How exactly is GzipHandler supposed to > be used in Jetty 9? > > > > > -- > View this message in context: > http://jetty.4.x6.nabble.com/GzipHandler-doesn-t-work-tp4962804.html > Sent from the Jetty User mailing list archive at Nabble.com. > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Custom JAR visible to web applications
You don't say which version of jetty, nor the circumstances in which
the class should be found - is it a servlet/filter/listener or a pojo
or via an annotation or ...?
Have you put your jar in your ${jetty.base}/lib/ext or in the top
level ${jetty.home}/lib/ext? Did you enable the ext module in
${jetty.base} or in ${jetty.home}?
Jan
On 23 July 2014 00:03, Ney André de Mello Zunino wrote:
> Hello.
>
> I'm new to Jetty and I have a question regarding class paths. I wish to
> have a custom library (JAR) shared by multiple applications running in
> the container. I added the JAR file to '/lib/ext' and
> verified that it is actually being added to the CLASSPATH by running
> 'java -jar start.jar --list-classpath'. However, 'NoClassDefFound'
> errors occur when the web application is run.
>
> How can I make my custom JAR visible to the web application? Ideally, I
> wish I could do that without modifying the WAR deployment so that newly
> added applications would also have the custom JAR on their CLASSPATH
> without extra configuration.
>
> Thank you in advance and sorry if the question is too trivial. I admit I
> haven't been able to find a proper solution (given my requirements).
>
> --
> Zunino
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Custom JAR visible to web applications
Can you post the stacktrace? Do any of the classes in jar in lib/ext
depend on classes that are inside the webapp or one of its jars? Do
you have the jar in question in both lib/ext and inside the webapp as
well?
It would be worthwhile if you compare your webapp to the standard
test-spec.war that is part of the demo-base in the standard
distribution - it uses some jars inside demo-base/lib/ext.
Jan
On 23 July 2014 21:37, Ney André de Mello Zunino wrote:
> Hi and sorry for the missing details; here they are:
>
> I'm using Jetty 9.2.1 running on OpenJDK 7.
>
> My shared JAR has been placed in my '${jetty.home}/lib/ext' which,
> AFAIC, is the same as '${jetty.base}/lib/ext', since I'm not specifying
> a different base. Am I right? The classes in the shared JAR have nothing
> special about them. They don't use annotations.
>
> My webapp is a very simple Servlet 2.4 application. It contains a filter
> which indeed makes use of a couple of classes in the shared JAR. And
> here's where the 'NoClassDefFound' error occurs. The app's also got a
> Servlet which references classes in the shared JAR. And that's about it.
>
> As I said in my original message, the JAR is definitely being added to
> the classpath reported by 'java -jar start.jar --list-classpath'. I've
> read about the fact that web applications prioritize libraries and
> resources within their 'WEB-INF', but I expected the container's
> classpath to be visible as well. Surely, I must be missing something.
>
> Anything else I should add?
>
> Thank you!
>
> On 22-07-2014 20:00, Jan Bartel wrote:
>> You don't say which version of jetty, nor the circumstances in which
>> the class should be found - is it a servlet/filter/listener or a pojo
>> or via an annotation or ...?
>>
>> Have you put your jar in your ${jetty.base}/lib/ext or in the top
>> level ${jetty.home}/lib/ext? Did you enable the ext module in
>> ${jetty.base} or in ${jetty.home}?
>>
>> Jan
>>
>> On 23 July 2014 00:03, Ney André de Mello Zunino
>> wrote:
>>> Hello.
>>>
>>> I'm new to Jetty and I have a question regarding class paths. I wish to
>>> have a custom library (JAR) shared by multiple applications running in
>>> the container. I added the JAR file to '/lib/ext' and
>>> verified that it is actually being added to the CLASSPATH by running
>>> 'java -jar start.jar --list-classpath'. However, 'NoClassDefFound'
>>> errors occur when the web application is run.
>>>
>>> How can I make my custom JAR visible to the web application? Ideally, I
>>> wish I could do that without modifying the WAR deployment so that newly
>>> added applications would also have the custom JAR on their CLASSPATH
>>> without extra configuration.
>>>
>>> Thank you in advance and sorry if the question is too trivial. I admit I
>>> haven't been able to find a proper solution (given my requirements).
>>>
>>> --
>>> Zunino
>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>>
>>
>
> --
> Ney André de Mello Zunino
> Analista de Pesquisa e Desenvolvimento
> Softplan/Poligraph
> +55 48 3027-8000
> www.softplan.com.br
> twitter.com/softplanonline
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Missing initial multi part boundary
a:408) > at org.eclipse.jetty.server.Request.getParts(Request.java:2144) > at org.eclipse.jetty.server.Request.getParts(Request.java:2123) > at > Smeup.smeui.uimainmodule.internalappserver.servlet.UploadServlet.doPut(UploadServlet.java:49) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:751) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:566) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:498) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:98) > at org.eclipse.jetty.server.Server.handle(Server.java:461) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:284) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536) > at java.lang.Thread.run(Thread.java:745) > > > > > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
[jetty-users] JSTL and OSGi with jetty-9.x
Does anyone have an osgi environment where they are able to use jstl with their webapp deployed into osgi? If so, can you please post the details of your setup - osgi container name, version etc, how you have deployed your webapp, and how jstl is deployed (is it part of your webapp or separately deployed). I'm asking because it looks to me like jstl in osgi would be broken in jetty-9, so I'd like some user experience feedback to either confirm or discard my suspicions. thanks, Jan -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Embedded Jetty 9 + JSTL = The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
>
>
> org.eclipse.jetty,org.slf4j,ch.qos
>
> provided
> META-INF/*
>
>
> ${project.build.directory}/${project.build.finalName}
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-war-plugin
> 2.3
>
>
>
> Main
>
>
>
>
>
> default-war
> package
>
> war
>
>
>
>
>
>
>
>
> I also have:
>
>
> Jetty_9_Plugin
>
> 9.0.4.v20130625
>
>
>
> org.eclipse.jetty.orbit
> javax.servlet
> 3.0.0.v201112011016
> provided
>
>
>
>
>
> maven-compiler-plugin
> 2.3.2
>
>
> Main.java
>
> ${compileSource}
> ${compileSource}
>
>
>
> org.eclipse.jetty
> jetty-maven-plugin
> ${jetty9.version}
>
>
>
> ${basedir}/src/main/webapp/WEB-INF/web.xml
>
> ${server.environment.location}
>
>
>
> logback.configurationFile
>
> ${logback.configurationFile}
>
>
>
>
>
>
>
>
> which runs as expected with the mvn jetty:run command.
>
> Any suggestions would be greatly welcome.
>
> Cheers
>
> James
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Embedded Jetty 9 + JSTL = The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
> javax.mail
> mail
> 1.4.7
>
>
> org.apache.derby
> derby
> 10.10.2.0
>
>
> org.apache.commons
> commons-email
> 1.3.3
>
>
>
>
> org.eclipse.jetty
> jetty-webapp
> ${jetty.version}
>
>
> org.eclipse.jetty
> jetty-jsp
> ${jetty.version}
>
>
>
> Because of licensing of some included libraries, I need to provide all jars
> as they are. Meaning, I might not extract and include classes to my
> resulting jar. Thus, my maven assembly creates a following structure:
>
> *prefix*
> /bin
> myexecute.sh (calls java -jar ${prefix}/lib/java/main_app.jar)
> /lib/java
> *.jar (all the jar files)
>
>
> *prefix*/lib/java lists following libraries:
>
> ls
> activation-1.1.jar
> commons-email-1.3.3.jar
> derby-10.10.2.0.jar
> main_app.jar
> javax.el-3.0.0.jar
> javax.servlet-api-3.1.0.jar
> javax.servlet.jsp-2.3.2.jar
> javax.servlet.jsp-api-2.3.1.jar
> javax.servlet.jsp.jstl-1.2.0.v201105211821.jar
> javax.servlet.jsp.jstl-1.2.2.jar
> jetty-http-9.2.2.v20140723.jar
> jetty-io-9.2.2.v20140723.jar
> jetty-jsp-9.2.2.v20140723.jar
> jetty-schemas-3.1.M0.jar
> jetty-security-9.2.2.v20140723.jar
> jetty-server-9.2.2.v20140723.jar
> jetty-servlet-9.2.2.v20140723.jar
> jetty-util-9.2.2.v20140723.jar
> jetty-webapp-9.2.2.v20140723.jar
> jetty-xml-9.2.2.v20140723.jar
> log4j-1.2.17.jar
> mail-1.4.7.jar
> org.eclipse.jdt.core-3.8.2.v20130121.jar
>
> The classpath inside the main_app.jar looks just fine. All necessary java
> libraries are listed and the application works properly. However, I can't
> access the web-app, because of the PWC6188.
> Please notice, **There is no PWC6188-error, when running the application
> using eclipse or maven**. I set up the project using 'mvn eclipse:eclipse'
> btw.
> Following, regarding this thread
>
>> http://stackoverflow.com/questions/19448594/jetty-9-the-absolute-uri-http-java-sun-com-jsp-jstl-core-cannot-be-resolved
>
> just jetty-webapp and jetty-jsp artifacts are required, to set up Jetty
> containerserver with JSP, JSTL, Servlet etc. support.
>
>
> What else have I done? I read some useful info about Jetty class loading.
>> http://www.eclipse.org/jetty/documentation/current/jetty-classloading.html
> It states, that libraries defined in WEB-INF folder has a higher priority
> than libs from it's container server. However, even if I switch priority,
> I'm facing PWC6188. As mentioned here
>
>> http://stackoverflow.com/questions/2151075/cannot-load-jstl-taglib-within-embedded-jetty-server
>
> it might be a solution to set a classloader - I tried, without success.
>
> Because of the fact, that the webapp runs properly using eclipse IDE, I took
> a deeper look on what it actually does. I figured that:
> When I use eclipse to create a runnable jar ...
> 1) ... and choose to extract all dependencies in target jar (resulting to
> have just one jar), the webapp works well.
> --> However, this conflicts with some licenses of dependencies. I might not
> extract and include object-code in resulting jar.
> 2) ... and choose to place dependencies as jar next to my resulting jar
> (leaving all depedencies as they are), I'm facing PWC6188-Error.
>
>
>
> In conclusion, as you might notice, I tried a lot and got quite deep into
> all this JSTL lib. However, I can't manage to get rid of PWC6188 error. I
> bet it's something trivial, however, it might also be a major problem of
> Jetty 9.
> Thus, I like to say thanks for any help!
>
>
>
> --
> View this message in context:
> http://jetty.4.x6.nabble.com/jetty-users-Embedded-Jetty-9-JSTL-The-absolute-uri-http-java-sun-com-jsp-jstl-core-cannot-be-resolven-tp4961067p4962870.html
> Sent from the Jetty User mailing list archive at Nabble.com.
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] how to force/configure Jetty to increase the length of JSESSIONID
Ike, I think the way to do it would be to subclass one of the SessionIdManagers and override the newSessionId() method. cheers Jan On 22 August 2014 14:14, Ike Ikonne wrote: > Hi all, > > > I have an embedded jetty 7.0.1 in my application; I would like to know if > there is a way > to configure Jetty to increase the length of JESSIONID, I have a requirement > to have > the length of JESSIONID to be configurable. > > Thanks, > > Ike > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Loading resources from OSGi fragment bundle
Heng, Can you post the manifest of the fragment bundle? I would have thought that if the fragment exports the packages of the resources then it would be fine ... best if you post the manifest so we can see it for ourselves. thanks Jan On 9 September 2014 16:40, Heng Sin Low wrote: > Hi all, > > I've been evaluating the embedding of tomcat ( gemini web ) and jetty within > equinox. All have went well with Jetty 9.2.2 except one issue: our web > application have not been able to access resources (xml files, images, etc ) > contributed through OSGi fragment bundle where it have been tested working > with the tomcat setup. > > Is loading of resources from OSGi fragment bundle something not yet > supported by jetty osgi or is that a misconfiguration on my end ? > > Regards, > Low > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Loading resources from OSGi fragment bundle
I will make a note to update the jetty osgi doco to include these manifest headers. cheers Jan On 9 September 2014 21:57, Heng Sin Low wrote: > Found https://bugs.eclipse.org/bugs/show_bug.cgi?id=344067 and the 2 jetty > specific header that can cater to my need ( Jetty-WarFragmentFolderPath and > Jetty-WarPatchFragmentFolderPath ). > > All is good now :) > > On Tue, Sep 9, 2014 at 4:45 PM, Heng Sin Low wrote: >> >> Hi Jan, >> >> I'm not talking about loading of resources from classpath here but >> accessing static resources ( xml file, images etc ) that's contributed from >> fragment bundle. So there's really nothing interesting from the fragment >> manifest here. >> >> For e.g, the host bundle is deploy to the webapp context and the fragment >> bundle contains the resource images/help.png, >> http://localhost:8080/webapp/images/help.png give 404 on jetty but works >> when the same setup is deploy to gemini web ( tomcat osgi ). >> >> >> Regards, >> Low >> >> On Tue, Sep 9, 2014 at 3:33 PM, Jan Bartel wrote: >>> >>> Heng, >>> >>> Can you post the manifest of the fragment bundle? I would have thought >>> that if the fragment exports the packages of the resources then it >>> would be fine ... best if you post the manifest so we can see it for >>> ourselves. >>> >>> thanks >>> Jan >>> >>> On 9 September 2014 16:40, Heng Sin Low wrote: >>> > Hi all, >>> > >>> > I've been evaluating the embedding of tomcat ( gemini web ) and jetty >>> > within >>> > equinox. All have went well with Jetty 9.2.2 except one issue: our web >>> > application have not been able to access resources (xml files, images, >>> > etc ) >>> > contributed through OSGi fragment bundle where it have been tested >>> > working >>> > with the tomcat setup. >>> > >>> > Is loading of resources from OSGi fragment bundle something not yet >>> > supported by jetty osgi or is that a misconfiguration on my end ? >>> > >>> > Regards, >>> > Low >>> > >>> > ___ >>> > jetty-users mailing list >>> > jetty-users@eclipse.org >>> > To change your delivery options, retrieve your password, or unsubscribe >>> > from >>> > this list, visit >>> > https://dev.eclipse.org/mailman/listinfo/jetty-users >>> >>> >>> >>> -- >>> Jan Bartel >>> www.webtide.com >>> 'Expert Jetty/CometD developer,production,operations advice' >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] [jetty-dev] Jetty 9.2.3.v20140905 / 8.1.16.v20140903 / 7.6.16.v20140903 Released!
And for OSGi users out there, please note that with 9.2.3 we swapped over to using apache jsp (jasper 8.0.9), the same as we use for the distribution. cheers Jan On 10 September 2014 02:50, Jesse McConnell wrote: > We are pleased to announce the availability of Jetty 9.2.3, Jetty > 8.1.16 and Jetty 7.6.16! > > The Jetty 9 release is a standard point release with 25 total issues > resolved. The Jetty 7 and Jetty 8 releases continue to be released in > lockstep with 3 and 7 issues resolved respectively. > > We encourage everyone using Jetty 9.2.2 to update when they get the > chance. Additionally we encourage anyone using Jetty 7 and 8 to > update as well, ideally to Jetty 9. We have been clear for some time > now that public support for Jetty 7 and 8 will dry up on the mailing > lists over time and our current plans are to cease maintenance > releases for anything outside of a security vulnerability for Jetty 7 > and 8 entirely at years end. > > If you haven't already, now is the time to plan your migration to Jetty 9. > > The issues resolved are listed below. > > Distribution Downloads: > > - http://download.eclipse.org/jetty/ > > The artifacts are also available in the Global Central Repository. > > - http://central.maven.org/ > > Eclipse P2 repositories are available as well. > > If you find an issue with this release you can open a bug through the > guided bugzilla page located here: > > - https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Jetty&format=guided > > Documentation can be found at our documentation hub > > - https://www.eclipse.org/jetty/documentation/ > > Finally, a reminder that both dev and prod support are offered through Webtide > (www.webtide.com), feel free to contact us through that site or ping > me directly if you are interested in learning more. Documentation > PDF's are available for direct download on the webtide.com website as > well. > > cheers, > The Jetty Development Team > > > jetty-9.2.3.v20140905 - 05 September 2014 > + 347110 renamed class transformer methods > + 411163 Add embedded jetty code example with JSP enabled > + 435322 Added a idleTimeout to the SharedBlockerCallback > + 435533 Handle 0 sized async gzip > + 435988 ContainerLifeCycle: beans never stopped on remove > + 436862 Update jetty-osgi to asm-5 and spifly-1.0.1 > + 438500 Odd NoClassDef errors when shutting down the jetty-maven-plugin via >the stop goal > + 440255 ensure 500 is logged on thrown Errors > + 441073 isEarlyEOF on HttpInput > + 441475 org.eclipse.jetty.server.ResourceCache exceptions under high load > + 441479 Jetty hangs due to deadlocks in session manager > + 441649 Update to jsp and el Apache Jasper 8.0.9 > + 441756 Ssl Stackoverflow on renegotiate > + 441897 Fixed etag handling in gzipfilter > + 442048 fixed sendRedirect %2F encoding > + 442383 Improved insufficient threads message > + 442628 Update example xml file for second server instance to extract wars > + 442642 Quickstart generates valid XML > + 442759 Allow specific ServletContainerInitializers to be excluded > + 442950 Embedded Jetty client requests to localhost hangs with high cpu > usage >(NIO OP_CONNECT Solaris/Sparc). > + 443049 Improved HttpParser illegal character messages > + 443158 Fixed HttpOutput spin > + 443172 web-fragment.xml wrongly parsed for applications running in serlvet >2.4 mode > + 443231 java.lang.NullPointerException on scavenge scheduling when session > id >manager declared before shared scheduler > + 443262 Distinguish situation where jetty looks for tlds in META-INF but >finds none vs does not look > > > jetty-8.1.16.v20140903 - 03 September 2014 > + 409788 Large POST body causes java.lang.IllegalStateException: SENDING => >HEADERS. > + 433689 Evict idle HttpDestinations from client > + 433802 check EOF in send1xx > + 438996 Scavenger-Timer in HashSessionManager can die because of >IllegalStateException from getMaxInactiveInterval > + 442048 fixed sendRedirect %2F encoding > + 442839 highly fragmented websocket messages can result in corrupt binary >messages > > > jetty-7.6.16.v20140902 - 02 September 2014 > + 409788 Large POST body causes java.lang.IllegalStateException: SENDING => >HEADERS. > + 433802 check EOF in send1xx > + 442839 highly fragmented websocket messages can result in corrupt binary >messages > > > -- > jesse mcconnell > jesse.mcconn...@gmail.com > > - > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] [jetty-dev] Jetty 9.2.3.v20140905 / 8.1.16.v20140903 / 7.6.16.v20140903 Released!
Hi Low, Actually, I'm working on it as we speak. If you take a look in the jetty sources at the TestJettyOSGiBootWithAnnotations class (and also the superclass TestJettyOSGiBootCore), it will help get you started as to which jars you need to deploy. Here's a link to the src: https://github.com/eclipse/jetty.project/blob/master/jetty-osgi/test-jetty-osgi/src/test/java/org/eclipse/jetty/osgi/test/TestJettyOSGiBootWithAnnotations.java In addition to the standard jetty jars, for apache-jsp use: org.mortbay.jasper:apache-el:8.0.9.M3 org.mortbay.jasper:apache-jsp:8.0.9.M3 org.eclipse.jetty:apache-jsp:9.2.3 the usual jstl api jar the usual jstl impl jar the usual jdt jar you'll need all of the recommended jars for annotations as per the current documentation take out any jetty-schema jar you have and replace it with the org.eclipse.jetty.toolchain:jetty-osgi-servlet-api:3.1.M0 Hopefully this will point you in the right direction. I should have the doc updated shortly and pushed up to the documentation page. I'll let you know. Jan On 10 September 2014 17:12, Heng Sin Low wrote: > Hi Jan, > > I can only find the setup documentation ( > http://www.eclipse.org/jetty/documentation/current/framework-jetty-osgi.html > ) for the grassfish jsp engine. Where can I find the documentation for the > setup of the apache jsp engine for 9.2.3 ? The jetty-jsp-fragment is always > working for me but I couldn't get the apache jsp engine up and running and > without any documentation, it is always a struggle to know whether I've miss > anything. > > Regards, > Low > > On Wed, Sep 10, 2014 at 12:04 PM, Jan Bartel wrote: >> >> And for OSGi users out there, please note that with 9.2.3 we swapped >> over to using apache jsp (jasper 8.0.9), the same as we use for the >> distribution. >> >> cheers >> Jan >> >> On 10 September 2014 02:50, Jesse McConnell >> wrote: >> > We are pleased to announce the availability of Jetty 9.2.3, Jetty >> > 8.1.16 and Jetty 7.6.16! >> > >> > The Jetty 9 release is a standard point release with 25 total issues >> > resolved. The Jetty 7 and Jetty 8 releases continue to be released in >> > lockstep with 3 and 7 issues resolved respectively. >> > >> > We encourage everyone using Jetty 9.2.2 to update when they get the >> > chance. Additionally we encourage anyone using Jetty 7 and 8 to >> > update as well, ideally to Jetty 9. We have been clear for some time >> > now that public support for Jetty 7 and 8 will dry up on the mailing >> > lists over time and our current plans are to cease maintenance >> > releases for anything outside of a security vulnerability for Jetty 7 >> > and 8 entirely at years end. >> > >> > If you haven't already, now is the time to plan your migration to Jetty >> > 9. >> > >> > The issues resolved are listed below. >> > >> > Distribution Downloads: >> > >> > - http://download.eclipse.org/jetty/ >> > >> > The artifacts are also available in the Global Central Repository. >> > >> > - http://central.maven.org/ >> > >> > Eclipse P2 repositories are available as well. >> > >> > If you find an issue with this release you can open a bug through the >> > guided bugzilla page located here: >> > >> > - >> > https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Jetty&format=guided >> > >> > Documentation can be found at our documentation hub >> > >> > - https://www.eclipse.org/jetty/documentation/ >> > >> > Finally, a reminder that both dev and prod support are offered through >> > Webtide >> > (www.webtide.com), feel free to contact us through that site or ping >> > me directly if you are interested in learning more. Documentation >> > PDF's are available for direct download on the webtide.com website as >> > well. >> > >> > cheers, >> > The Jetty Development Team >> > >> > >> > jetty-9.2.3.v20140905 - 05 September 2014 >> > + 347110 renamed class transformer methods >> > + 411163 Add embedded jetty code example with JSP enabled >> > + 435322 Added a idleTimeout to the SharedBlockerCallback >> > + 435533 Handle 0 sized async gzip >> > + 435988 ContainerLifeCycle: beans never stopped on remove >> > + 436862 Update jetty-osgi to asm-5 and spifly-1.0.1 >> > + 438500 Odd NoClassDef errors when shutting down the >> > jetty-maven-plugin via >> >the stop goal >> > + 440255 ensure 500
Re: [jetty-users] ContextHandlerCollection as a child handler of ContextHandler
Neil,
I'm not really sure why you want to do that?
It is the ContextHandlerCollection that has the smarts to choose
amongst the best context paths that match the request. As the request
is eg /base/a/ then none of your PrintHandlers match that.
This will certainly work:
chc.setHandlers(new Handler[] {new PrintHandler("/base/a"), new
PrintHandler("/base/b"), new PrintHandler("/base/c")});
cheers
Jan
On 9 September 2014 21:46, Neil Williams wrote:
> Looking at having the following:
>
> public class ContextPlay {
> public static void main(String[] args) throws Exception {
> Server server = new Server(8000);
>
> ContextHandlerCollection chc = new ContextHandlerCollection();
> chc.setHandlers(new Handler[] {new PrintHandler("/a"), new
> PrintHandler("/b"), new PrintHandler("/c")});
>
> ContextHandler ch = new ContextHandler("/base")
> ch.setHandler(chc);
>
> server.setHandler(ch);
>
> server.start();
> server.join();
> }
>
> public static class PrintHandler extends ContextHandler {
> public PrintHandler(String context) {
> super(context);
> }
>
> @Override
> public void doHandle(String target, Request baseRequest,
> HttpServletRequest request,
> HttpServletResponse response) throws IOException, ServletException {
> response.getWriter().print(getContextPath());
> baseRequest.setHandled(true);
> }
> }
> }
>
> So a base ContextHandler with the ContextHandlerCollection as the
> ContextHandler's child handler.
>
> A request to http://localhost:8000/base/c will 404, a request to
> http://localhost:8000/base/a will succeed. Is this sort of chaining meant to
> be supported by Jetty? It would certainly be useful.
>
> Thanks, Neil
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] [jetty-dev] Jetty 9.2.3.v20140905 / 8.1.16.v20140903 / 7.6.16.v20140903 Released!
Hi Low, The doco is now updated and online: https://www.eclipse.org/jetty/documentation/9.2.3.v20140905/index.html cheers Jan On 10 September 2014 17:53, Jan Bartel wrote: > Hi Low, > > Actually, I'm working on it as we speak. > > If you take a look in the jetty sources at the > TestJettyOSGiBootWithAnnotations class (and also the superclass > TestJettyOSGiBootCore), it will help get you started as to which jars > you need to deploy. Here's a link to the src: > https://github.com/eclipse/jetty.project/blob/master/jetty-osgi/test-jetty-osgi/src/test/java/org/eclipse/jetty/osgi/test/TestJettyOSGiBootWithAnnotations.java > > In addition to the standard jetty jars, for apache-jsp use: > > org.mortbay.jasper:apache-el:8.0.9.M3 > org.mortbay.jasper:apache-jsp:8.0.9.M3 > org.eclipse.jetty:apache-jsp:9.2.3 > the usual jstl api jar > the usual jstl impl jar > the usual jdt jar > you'll need all of the recommended jars for annotations as per the > current documentation > take out any jetty-schema jar you have and replace it with the > org.eclipse.jetty.toolchain:jetty-osgi-servlet-api:3.1.M0 > > > Hopefully this will point you in the right direction. > > I should have the doc updated shortly and pushed up to the > documentation page. I'll let you know. > > Jan > > On 10 September 2014 17:12, Heng Sin Low wrote: >> Hi Jan, >> >> I can only find the setup documentation ( >> http://www.eclipse.org/jetty/documentation/current/framework-jetty-osgi.html >> ) for the grassfish jsp engine. Where can I find the documentation for the >> setup of the apache jsp engine for 9.2.3 ? The jetty-jsp-fragment is always >> working for me but I couldn't get the apache jsp engine up and running and >> without any documentation, it is always a struggle to know whether I've miss >> anything. >> >> Regards, >> Low >> >> On Wed, Sep 10, 2014 at 12:04 PM, Jan Bartel wrote: >>> >>> And for OSGi users out there, please note that with 9.2.3 we swapped >>> over to using apache jsp (jasper 8.0.9), the same as we use for the >>> distribution. >>> >>> cheers >>> Jan >>> >>> On 10 September 2014 02:50, Jesse McConnell >>> wrote: >>> > We are pleased to announce the availability of Jetty 9.2.3, Jetty >>> > 8.1.16 and Jetty 7.6.16! >>> > >>> > The Jetty 9 release is a standard point release with 25 total issues >>> > resolved. The Jetty 7 and Jetty 8 releases continue to be released in >>> > lockstep with 3 and 7 issues resolved respectively. >>> > >>> > We encourage everyone using Jetty 9.2.2 to update when they get the >>> > chance. Additionally we encourage anyone using Jetty 7 and 8 to >>> > update as well, ideally to Jetty 9. We have been clear for some time >>> > now that public support for Jetty 7 and 8 will dry up on the mailing >>> > lists over time and our current plans are to cease maintenance >>> > releases for anything outside of a security vulnerability for Jetty 7 >>> > and 8 entirely at years end. >>> > >>> > If you haven't already, now is the time to plan your migration to Jetty >>> > 9. >>> > >>> > The issues resolved are listed below. >>> > >>> > Distribution Downloads: >>> > >>> > - http://download.eclipse.org/jetty/ >>> > >>> > The artifacts are also available in the Global Central Repository. >>> > >>> > - http://central.maven.org/ >>> > >>> > Eclipse P2 repositories are available as well. >>> > >>> > If you find an issue with this release you can open a bug through the >>> > guided bugzilla page located here: >>> > >>> > - >>> > https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Jetty&format=guided >>> > >>> > Documentation can be found at our documentation hub >>> > >>> > - https://www.eclipse.org/jetty/documentation/ >>> > >>> > Finally, a reminder that both dev and prod support are offered through >>> > Webtide >>> > (www.webtide.com), feel free to contact us through that site or ping >>> > me directly if you are interested in learning more. Documentation >>> > PDF's are available for direct download on the webtide.com website as >>> > well. >>> > >>> > cheers, >>> > The Jetty Development Team >>> > &g
Re: [jetty-users] [jetty-dev] Jetty 9.2.3.v20140905 / 8.1.16.v20140903 / 7.6.16.v20140903 Released!
Hi Heng, How about you post the output of a console "status" command from eclipse so I can see which bundles you have deployed and their resolution status? On 11 September 2014 11:01, Heng Sin Low wrote: ... > 1. The jstl related jar listed in the osgi documentation is different from > what is being use in the 9.2.3 distribution. Is that because that's the only > combination that will work for the OSGi environment ? Ah. The names of the jstl jars look a bit mangled in the documentation. Darn. I'll have to fix that up. They should be: org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:1.2.0.v201105211821 org.glassfish.web:javax.servlet.jsp.jstl:1.2.2 Note that these are the glassfish jstl jars. I haven't tested against the apache jstl jars yet - I'll take a look at their manifests and see if they are compatible. > 2. I've been testing this against the equinox 3.10 ( eclipse luna ) > environment. Perhaps that's not a supported environment yet ? Its been tested on kepler and luna. > Regarding the updated doc, I think one missing piece of information is which > bundle needs to be set as auto start. I'm deploying this using the pax unit test environment for osgi and the default there seems to be to start all bundles that aren't fragments. Which bundle are you needing to set autostart on?? thanks Jan > > Thanks. > > Regards, > > Low > > > On Thu, Sep 11, 2014 at 6:08 AM, Jan Bartel wrote: >> >> Hi Low, >> >> The doco is now updated and online: >> https://www.eclipse.org/jetty/documentation/9.2.3.v20140905/index.html >> >> cheers >> Jan >> >> On 10 September 2014 17:53, Jan Bartel wrote: >> > Hi Low, >> > >> > Actually, I'm working on it as we speak. >> > >> > If you take a look in the jetty sources at the >> > TestJettyOSGiBootWithAnnotations class (and also the superclass >> > TestJettyOSGiBootCore), it will help get you started as to which jars >> > you need to deploy. Here's a link to the src: >> > >> > https://github.com/eclipse/jetty.project/blob/master/jetty-osgi/test-jetty-osgi/src/test/java/org/eclipse/jetty/osgi/test/TestJettyOSGiBootWithAnnotations.java >> > >> > In addition to the standard jetty jars, for apache-jsp use: >> > >> > org.mortbay.jasper:apache-el:8.0.9.M3 >> > org.mortbay.jasper:apache-jsp:8.0.9.M3 >> > org.eclipse.jetty:apache-jsp:9.2.3 >> > the usual jstl api jar >> > the usual jstl impl jar >> > the usual jdt jar >> > you'll need all of the recommended jars for annotations as per the >> > current documentation >> > take out any jetty-schema jar you have and replace it with the >> > org.eclipse.jetty.toolchain:jetty-osgi-servlet-api:3.1.M0 >> > >> > >> > Hopefully this will point you in the right direction. >> > >> > I should have the doc updated shortly and pushed up to the >> > documentation page. I'll let you know. >> > >> > Jan >> > >> > On 10 September 2014 17:12, Heng Sin Low wrote: >> >> Hi Jan, >> >> >> >> I can only find the setup documentation ( >> >> >> >> http://www.eclipse.org/jetty/documentation/current/framework-jetty-osgi.html >> >> ) for the grassfish jsp engine. Where can I find the documentation for >> >> the >> >> setup of the apache jsp engine for 9.2.3 ? The jetty-jsp-fragment is >> >> always >> >> working for me but I couldn't get the apache jsp engine up and running >> >> and >> >> without any documentation, it is always a struggle to know whether I've >> >> miss >> >> anything. >> >> >> >> Regards, >> >> Low >> >> >> >> On Wed, Sep 10, 2014 at 12:04 PM, Jan Bartel wrote: >> >>> >> >>> And for OSGi users out there, please note that with 9.2.3 we swapped >> >>> over to using apache jsp (jasper 8.0.9), the same as we use for the >> >>> distribution. >> >>> >> >>> cheers >> >>> Jan >> >>> >> >>> On 10 September 2014 02:50, Jesse McConnell >> >>> >> >>> wrote: >> >>> > We are pleased to announce the availability of Jetty 9.2.3, Jetty >> >>> > 8.1.16 and Jetty 7.6.16! >> >>> > >> >>> > The Jetty 9 release is a standard point release with 25 total issues >> >>> > resolved. The Jetty 7 and Jetty
Re: [jetty-users] [jetty-dev] Jetty 9.2.3.v20140905 / 8.1.16.v20140903 / 7.6.16.v20140903 Released!
Low, On 11 September 2014 12:22, Heng Sin Low wrote: > Hi Jan, > > Here it goes - http://pastebin.com/PMbP2z9n Thanks for that, looking at your deployed bundle list and will get back to you on that. > Also, since the jetty jsp fragment 2.3.3 is working fine for me, does I miss > anything if I stick with that instead ? You don't need it if you are using the apache jsp jars, and it may in fact be detrimental - its only there because some of the glassfish jars lack a correct manifest. > Just notice that there is setting of boot delegation and system packages in > the jetty osgi unit testing code ( wasn't mention in the osgi doc ) , is > that a must to get the whole thing working ? I don't think I added anything to the default delegation and system packages for apache jsp - whatever you had for glassfish jsp should be sufficient. However, if you're trying to use the apache jstl jars, they may require something extra, I won't know until I try to use them myself. Jan > > Regards, > Low > > On Thu, Sep 11, 2014 at 9:22 AM, Jan Bartel wrote: >> >> Hi Heng, >> >> How about you post the output of a console "status" command from >> eclipse so I can see which bundles you have deployed and their >> resolution status? >> >> >> >> On 11 September 2014 11:01, Heng Sin Low wrote: >> ... >> > 1. The jstl related jar listed in the osgi documentation is different >> > from >> > what is being use in the 9.2.3 distribution. Is that because that's the >> > only >> > combination that will work for the OSGi environment ? >> >> Ah. The names of the jstl jars look a bit mangled in the >> documentation. Darn. I'll have to fix that up. They should be: >> >> org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:1.2.0.v201105211821 >> org.glassfish.web:javax.servlet.jsp.jstl:1.2.2 >> >> Note that these are the glassfish jstl jars. I haven't tested against >> the apache jstl jars yet - I'll take a look at their manifests and see >> if they are compatible. >> >> > 2. I've been testing this against the equinox 3.10 ( eclipse luna ) >> > environment. Perhaps that's not a supported environment yet ? >> >> Its been tested on kepler and luna. >> >> >> > Regarding the updated doc, I think one missing piece of information is >> > which >> > bundle needs to be set as auto start. >> >> I'm deploying this using the pax unit test environment for osgi and >> the default there seems to be to start all bundles that aren't >> fragments. Which bundle are you needing to set autostart on?? >> >> thanks >> Jan >> >> > >> > Thanks. >> > >> > Regards, >> > >> > Low >> > >> > >> > On Thu, Sep 11, 2014 at 6:08 AM, Jan Bartel wrote: >> >> >> >> Hi Low, >> >> >> >> The doco is now updated and online: >> >> https://www.eclipse.org/jetty/documentation/9.2.3.v20140905/index.html >> >> >> >> cheers >> >> Jan >> >> >> >> On 10 September 2014 17:53, Jan Bartel wrote: >> >> > Hi Low, >> >> > >> >> > Actually, I'm working on it as we speak. >> >> > >> >> > If you take a look in the jetty sources at the >> >> > TestJettyOSGiBootWithAnnotations class (and also the superclass >> >> > TestJettyOSGiBootCore), it will help get you started as to which jars >> >> > you need to deploy. Here's a link to the src: >> >> > >> >> > >> >> > https://github.com/eclipse/jetty.project/blob/master/jetty-osgi/test-jetty-osgi/src/test/java/org/eclipse/jetty/osgi/test/TestJettyOSGiBootWithAnnotations.java >> >> > >> >> > In addition to the standard jetty jars, for apache-jsp use: >> >> > >> >> > org.mortbay.jasper:apache-el:8.0.9.M3 >> >> > org.mortbay.jasper:apache-jsp:8.0.9.M3 >> >> > org.eclipse.jetty:apache-jsp:9.2.3 >> >> > the usual jstl api jar >> >> > the usual jstl impl jar >> >> > the usual jdt jar >> >> > you'll need all of the recommended jars for annotations as per the >> >> > current documentation >> >> > take out any jetty-schema jar you have and replace it with the >> >> > org.eclipse.jetty.toolchain:jetty-osgi-servlet-api:3.1.M0 >> >> > >> >> > >> >> > Ho
Re: [jetty-users] [jetty-dev] Jetty 9.2.3.v20140905 / 8.1.16.v20140903 / 7.6.16.v20140903 Released!
Low, How did you get org.apache.taglibs.taglibs-standard-impl-1.2.1.jar to resolve? It does not resolve for me. Can you do a console "bundle" and "diag" commands on it for me to see how you're osgi container has resolved it? thanks Jan On 11 September 2014 13:17, Jan Bartel wrote: > Low, > > > On 11 September 2014 12:22, Heng Sin Low wrote: >> Hi Jan, >> >> Here it goes - http://pastebin.com/PMbP2z9n > > Thanks for that, looking at your deployed bundle list and will get > back to you on that. > > >> Also, since the jetty jsp fragment 2.3.3 is working fine for me, does I miss >> anything if I stick with that instead ? > > You don't need it if you are using the apache jsp jars, and it may in > fact be detrimental - its only there because some of the glassfish > jars lack a correct manifest. > >> Just notice that there is setting of boot delegation and system packages in >> the jetty osgi unit testing code ( wasn't mention in the osgi doc ) , is >> that a must to get the whole thing working ? > > I don't think I added anything to the default delegation and system > packages for apache jsp - whatever you had for glassfish jsp should be > sufficient. However, if you're trying to use the apache jstl jars, > they may require something extra, I won't know until I try to use them > myself. > > Jan > >> >> Regards, >> Low >> >> On Thu, Sep 11, 2014 at 9:22 AM, Jan Bartel wrote: >>> >>> Hi Heng, >>> >>> How about you post the output of a console "status" command from >>> eclipse so I can see which bundles you have deployed and their >>> resolution status? >>> >>> >>> >>> On 11 September 2014 11:01, Heng Sin Low wrote: >>> ... >>> > 1. The jstl related jar listed in the osgi documentation is different >>> > from >>> > what is being use in the 9.2.3 distribution. Is that because that's the >>> > only >>> > combination that will work for the OSGi environment ? >>> >>> Ah. The names of the jstl jars look a bit mangled in the >>> documentation. Darn. I'll have to fix that up. They should be: >>> >>> org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:1.2.0.v201105211821 >>> org.glassfish.web:javax.servlet.jsp.jstl:1.2.2 >>> >>> Note that these are the glassfish jstl jars. I haven't tested against >>> the apache jstl jars yet - I'll take a look at their manifests and see >>> if they are compatible. >>> >>> > 2. I've been testing this against the equinox 3.10 ( eclipse luna ) >>> > environment. Perhaps that's not a supported environment yet ? >>> >>> Its been tested on kepler and luna. >>> >>> >>> > Regarding the updated doc, I think one missing piece of information is >>> > which >>> > bundle needs to be set as auto start. >>> >>> I'm deploying this using the pax unit test environment for osgi and >>> the default there seems to be to start all bundles that aren't >>> fragments. Which bundle are you needing to set autostart on?? >>> >>> thanks >>> Jan >>> >>> > >>> > Thanks. >>> > >>> > Regards, >>> > >>> > Low >>> > >>> > >>> > On Thu, Sep 11, 2014 at 6:08 AM, Jan Bartel wrote: >>> >> >>> >> Hi Low, >>> >> >>> >> The doco is now updated and online: >>> >> https://www.eclipse.org/jetty/documentation/9.2.3.v20140905/index.html >>> >> >>> >> cheers >>> >> Jan >>> >> >>> >> On 10 September 2014 17:53, Jan Bartel wrote: >>> >> > Hi Low, >>> >> > >>> >> > Actually, I'm working on it as we speak. >>> >> > >>> >> > If you take a look in the jetty sources at the >>> >> > TestJettyOSGiBootWithAnnotations class (and also the superclass >>> >> > TestJettyOSGiBootCore), it will help get you started as to which jars >>> >> > you need to deploy. Here's a link to the src: >>> >> > >>> >> > >>> >> > https://github.com/eclipse/jetty.project/blob/master/jetty-osgi/test-jetty-osgi/src/test/java/org/eclipse/jetty/osgi/test/TestJettyOSGiBootWithAnnotations.java >>> >> > >>> >> > In
Re: [jetty-users] [jetty-dev] Jetty 9.2.3.v20140905 / 8.1.16.v20140903 / 7.6.16.v20140903 Released!
Low, Also worth noting that the el-api jar should in general not be deployed: this is true of both glassfish and apache. The reason is that the api unfortunately isn't a pure api of interfaces. The ExpressionFactory class does an spi-type finding of the ExpressionFactory implementation that simply won't work in osgi unless the el-api and implementation classes are in the same bundle. I suspect it is for this reason that the glassfish guys put the api inside their el impl jar. I've had to create a special bundle (the org.mortbay.jasper.apache-el jar) for this purpose as apache ships the api and impl in different jars. Jan On 11 September 2014 14:13, Heng Sin Low wrote: > Hi Jan, > > You are right, it doesn't resolve against the standard jetty and equinox > bundle list. Don't notice some of the import resolve against the export from > my application's bundle ( org.apache.xml.dtm, org.apache.xml.utils, > org.apache.xpath and org.apache.xpath.objects. the export comes from an > embedded xalan-2.7.1.jar ). Will test whether it will works better using the > grassfish jstl jar instead ( was trying to use what's recommended by the > 9.2.3 distribution ). > > Regards, > Low > > > On Thu, Sep 11, 2014 at 11:51 AM, Jan Bartel wrote: >> >> Low, >> >> How did you get org.apache.taglibs.taglibs-standard-impl-1.2.1.jar to >> resolve? It does not resolve for me. >> >> Can you do a console "bundle" and "diag" commands on it for me to see >> how you're osgi container has resolved it? >> >> thanks >> Jan >> >> On 11 September 2014 13:17, Jan Bartel wrote: >> > Low, >> > >> > >> > On 11 September 2014 12:22, Heng Sin Low wrote: >> >> Hi Jan, >> >> >> >> Here it goes - http://pastebin.com/PMbP2z9n >> > >> > Thanks for that, looking at your deployed bundle list and will get >> > back to you on that. >> > >> > >> >> Also, since the jetty jsp fragment 2.3.3 is working fine for me, does I >> >> miss >> >> anything if I stick with that instead ? >> > >> > You don't need it if you are using the apache jsp jars, and it may in >> > fact be detrimental - its only there because some of the glassfish >> > jars lack a correct manifest. >> > >> >> Just notice that there is setting of boot delegation and system >> >> packages in >> >> the jetty osgi unit testing code ( wasn't mention in the osgi doc ) , >> >> is >> >> that a must to get the whole thing working ? >> > >> > I don't think I added anything to the default delegation and system >> > packages for apache jsp - whatever you had for glassfish jsp should be >> > sufficient. However, if you're trying to use the apache jstl jars, >> > they may require something extra, I won't know until I try to use them >> > myself. >> > >> > Jan >> > >> >> >> >> Regards, >> >> Low >> >> >> >> On Thu, Sep 11, 2014 at 9:22 AM, Jan Bartel wrote: >> >>> >> >>> Hi Heng, >> >>> >> >>> How about you post the output of a console "status" command from >> >>> eclipse so I can see which bundles you have deployed and their >> >>> resolution status? >> >>> >> >>> >> >>> >> >>> On 11 September 2014 11:01, Heng Sin Low wrote: >> >>> ... >> >>> > 1. The jstl related jar listed in the osgi documentation is >> >>> > different >> >>> > from >> >>> > what is being use in the 9.2.3 distribution. Is that because that's >> >>> > the >> >>> > only >> >>> > combination that will work for the OSGi environment ? >> >>> >> >>> Ah. The names of the jstl jars look a bit mangled in the >> >>> documentation. Darn. I'll have to fix that up. They should be: >> >>> >> >>> org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:1.2.0.v201105211821 >> >>> org.glassfish.web:javax.servlet.jsp.jstl:1.2.2 >> >>> >> >>> Note that these are the glassfish jstl jars. I haven't tested against >> >>> the apache jstl jars yet - I'll take a look at their manifests and see >> >>> if they are compatible. >> >>> >> >>> > 2. I've been testing this a
Re: [jetty-users] [jetty-dev] Jetty 9.2.3.v20140905 / 8.1.16.v20140903 / 7.6.16.v20140903 Released!
Hi Low, You don't have the exact glassfish jstl jars deployed. From my earlier email to you, the ones you should use are: org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:1.2.0.v201105211821 org.glassfish.web:javax.servlet.jsp.jstl:1.2.2 Try using those - you wil find them in maven central. Jan On 11 September 2014 15:09, Heng Sin Low wrote: > Hi Jan, > > Same exception with the grassfish jstl bundle - http://pastebin.com/eaAZJ4RL > > Regards, > Low > > On Thu, Sep 11, 2014 at 12:13 PM, Heng Sin Low wrote: >> >> Hi Jan, >> >> You are right, it doesn't resolve against the standard jetty and equinox >> bundle list. Don't notice some of the import resolve against the export from >> my application's bundle ( org.apache.xml.dtm, org.apache.xml.utils, >> org.apache.xpath and org.apache.xpath.objects. the export comes from an >> embedded xalan-2.7.1.jar ). Will test whether it will works better using the >> grassfish jstl jar instead ( was trying to use what's recommended by the >> 9.2.3 distribution ). >> >> Regards, >> Low >> >> >> On Thu, Sep 11, 2014 at 11:51 AM, Jan Bartel wrote: >>> >>> Low, >>> >>> How did you get org.apache.taglibs.taglibs-standard-impl-1.2.1.jar to >>> resolve? It does not resolve for me. >>> >>> Can you do a console "bundle" and "diag" commands on it for me to see >>> how you're osgi container has resolved it? >>> >>> thanks >>> Jan >>> >>> On 11 September 2014 13:17, Jan Bartel wrote: >>> > Low, >>> > >>> > >>> > On 11 September 2014 12:22, Heng Sin Low wrote: >>> >> Hi Jan, >>> >> >>> >> Here it goes - http://pastebin.com/PMbP2z9n >>> > >>> > Thanks for that, looking at your deployed bundle list and will get >>> > back to you on that. >>> > >>> > >>> >> Also, since the jetty jsp fragment 2.3.3 is working fine for me, does >>> >> I miss >>> >> anything if I stick with that instead ? >>> > >>> > You don't need it if you are using the apache jsp jars, and it may in >>> > fact be detrimental - its only there because some of the glassfish >>> > jars lack a correct manifest. >>> > >>> >> Just notice that there is setting of boot delegation and system >>> >> packages in >>> >> the jetty osgi unit testing code ( wasn't mention in the osgi doc ) , >>> >> is >>> >> that a must to get the whole thing working ? >>> > >>> > I don't think I added anything to the default delegation and system >>> > packages for apache jsp - whatever you had for glassfish jsp should be >>> > sufficient. However, if you're trying to use the apache jstl jars, >>> > they may require something extra, I won't know until I try to use them >>> > myself. >>> > >>> > Jan >>> > >>> >> >>> >> Regards, >>> >> Low >>> >> >>> >> On Thu, Sep 11, 2014 at 9:22 AM, Jan Bartel wrote: >>> >>> >>> >>> Hi Heng, >>> >>> >>> >>> How about you post the output of a console "status" command from >>> >>> eclipse so I can see which bundles you have deployed and their >>> >>> resolution status? >>> >>> >>> >>> >>> >>> >>> >>> On 11 September 2014 11:01, Heng Sin Low wrote: >>> >>> ... >>> >>> > 1. The jstl related jar listed in the osgi documentation is >>> >>> > different >>> >>> > from >>> >>> > what is being use in the 9.2.3 distribution. Is that because that's >>> >>> > the >>> >>> > only >>> >>> > combination that will work for the OSGi environment ? >>> >>> >>> >>> Ah. The names of the jstl jars look a bit mangled in the >>> >>> documentation. Darn. I'll have to fix that up. They should be: >>> >>> >>> >>> org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:1.2.0.v201105211821 >>> >>> org.glassfish.web:javax.servlet.jsp.jstl:1.2.2 >>> >>> >>> >>> Note that these are the glassfish jstl jars. I haven&#
Re: [jetty-users] [jetty-dev] Jetty 9.2.3.v20140905 / 8.1.16.v20140903 / 7.6.16.v20140903 Released!
Hi Low, I'm getting kind of lost in what exactly you're doing and the environment you're running it in. Can I ask you to open a bug report for the problem you are seeing, and put in all the info on your jvm, platform, osgi container, how you're deploying your webapp, which bundles you have deployed and attaching any log output and output from console "status" command. https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Jetty thanks, Jan On 12 September 2014 02:27, Heng Sin Low wrote: > Hi Jan, > > Still can't solve the apache-jsp issue but I've found my problems with the > jetty-annotation module. > > Issues encounter with org.eclipse.jetty.osgi.annotations.AnnotationParser: > 1. At line 163, the output folder of project is hardcoded to either /bin or > /target/classes. Some of my eclipse project doesn't uses /bin as output > folder so I need to change that before jetty-annotation can work. It is easy > fix for me but I think that at least warrant an entry in the osgi > documentation page. > 2. At line 199, there isn't a check to ensure name is not null before the > transformation to shortName and invoke scanClass. Couple with the issue > above, it can leads to NullPointerException and stop the deployment of the > whole web bundle. > > Regards, > Low > > On Thu, Sep 11, 2014 at 2:10 PM, Heng Sin Low wrote: >> >> Hi Jan, >> >> For the setting of boot delegation and system packages, I'm referring to >> the configure method at >> http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-osgi/test-jetty-osgi/src/test/java/org/eclipse/jetty/osgi/test/TestJettyOSGiBootWithAnnotations.java. >> There's the CoreOptions.bootDelegationPackages and >> CoreOptions.systemPackages call in there. >> >> Regards, >> Low >> >> On Thu, Sep 11, 2014 at 11:17 AM, Jan Bartel wrote: >>> >>> Low, >>> >>> >>> On 11 September 2014 12:22, Heng Sin Low wrote: >>> > Hi Jan, >>> > >>> > Here it goes - http://pastebin.com/PMbP2z9n >>> >>> Thanks for that, looking at your deployed bundle list and will get >>> back to you on that. >>> >>> >>> > Also, since the jetty jsp fragment 2.3.3 is working fine for me, does I >>> > miss >>> > anything if I stick with that instead ? >>> >>> You don't need it if you are using the apache jsp jars, and it may in >>> fact be detrimental - its only there because some of the glassfish >>> jars lack a correct manifest. >>> >>> > Just notice that there is setting of boot delegation and system >>> > packages in >>> > the jetty osgi unit testing code ( wasn't mention in the osgi doc ) , >>> > is >>> > that a must to get the whole thing working ? >>> >>> I don't think I added anything to the default delegation and system >>> packages for apache jsp - whatever you had for glassfish jsp should be >>> sufficient. However, if you're trying to use the apache jstl jars, >>> they may require something extra, I won't know until I try to use them >>> myself. >>> >>> Jan >>> >>> > >>> > Regards, >>> > Low >>> > >>> > On Thu, Sep 11, 2014 at 9:22 AM, Jan Bartel wrote: >>> >> >>> >> Hi Heng, >>> >> >>> >> How about you post the output of a console "status" command from >>> >> eclipse so I can see which bundles you have deployed and their >>> >> resolution status? >>> >> >>> >> >>> >> >>> >> On 11 September 2014 11:01, Heng Sin Low wrote: >>> >> ... >>> >> > 1. The jstl related jar listed in the osgi documentation is >>> >> > different >>> >> > from >>> >> > what is being use in the 9.2.3 distribution. Is that because that's >>> >> > the >>> >> > only >>> >> > combination that will work for the OSGi environment ? >>> >> >>> >> Ah. The names of the jstl jars look a bit mangled in the >>> >> documentation. Darn. I'll have to fix that up. They should be: >>> >> >>> >> org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:1.2.0.v201105211821 >>> >> org.glassfish.web:javax.servlet.jsp.jstl:1.2.2 >>> >> >>> >> Note that these are the glassfish jstl jars. I haven'
Re: [jetty-users] java.io.FileNotFoundException: ServletContext resource [/WEB-INF/lib/] cannot be resolved to URL because it does not exist
:107) > > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60) > > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:154) > > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:125) > > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:107) > > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60) > > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:125) > > at org.eclipse.jetty.server.Server.start(Server.java:358) > > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:107) > > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60) > > at org.eclipse.jetty.server.Server.doStart(Server.java:325) > > at org.eclipse.jetty.maven.plugin.JettyServer.doStart(JettyServer.java:68) > > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > > at > org.eclipse.jetty.maven.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:564) > > at > org.eclipse.jetty.maven.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:360) > > at > org.eclipse.jetty.maven.plugin.JettyRunMojo.execute(JettyRunMojo.java:168) > > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) > > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) > > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:606) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > > Caused by: java.io.FileNotFoundException: ServletContext resource > [/WEB-INF/lib/] cannot be resolved to URL because it does not exist > > at > org.springframework.web.context.support.ServletContextResource.getURL(ServletContextResource.java:156) > > at > org.springframework.core.io.support.PathMatchingResourcePatternResolver.isJarResource(PathMatchingResourcePatternResolver.java:417) > > at > org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:346) > > at > org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:284) > > at > org.springframework.context.support.AbstractApplicationContext.getResources(AbstractApplicationContext.java:1170) > > at > org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:215) > > ... 59 more > > > > Thanks, > > Swapnil > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] [jetty-dev] Jetty 9.2.3.v20140905 / 8.1.16.v20140903 / 7.6.16.v20140903 Released!
Low, That's great. I'm updating the documentation. What was the final combination: are you using apache-jsp with glassfish jstl or apache-jsp with apache jstl, or some different combination? Jan On 12 September 2014 12:35, Heng Sin Low wrote: > Hi Jan, > > Finally got it working. Found that the start order of the bundle matter ( > org.apache.aries.spifly.dynamic.bundle -> org.eclipse.jetty.apache-jsp -> > org.eclipse.jetty.osgi.boot ). When it is not in that sequence of ordering, > the ServletContextInitializer service provided by > org.eclipse.jetty.apache-jsp is not discover by > org.eclipse.jetty.annotation. > > Regards, > Low > > On Fri, Sep 12, 2014 at 5:55 AM, Jan Bartel wrote: >> >> Hi Low, >> >> I'm getting kind of lost in what exactly you're doing and the >> environment you're running it in. Can I ask you to open a bug report >> for the problem you are seeing, and put in all the info on your jvm, >> platform, osgi container, how you're deploying your webapp, which >> bundles you have deployed and attaching any log output and output from >> console "status" command. >> https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Jetty >> >> thanks, >> Jan >> >> On 12 September 2014 02:27, Heng Sin Low wrote: >> > Hi Jan, >> > >> > Still can't solve the apache-jsp issue but I've found my problems with >> > the >> > jetty-annotation module. >> > >> > Issues encounter with >> > org.eclipse.jetty.osgi.annotations.AnnotationParser: >> > 1. At line 163, the output folder of project is hardcoded to either /bin >> > or >> > /target/classes. Some of my eclipse project doesn't uses /bin as output >> > folder so I need to change that before jetty-annotation can work. It is >> > easy >> > fix for me but I think that at least warrant an entry in the osgi >> > documentation page. >> > 2. At line 199, there isn't a check to ensure name is not null before >> > the >> > transformation to shortName and invoke scanClass. Couple with the issue >> > above, it can leads to NullPointerException and stop the deployment of >> > the >> > whole web bundle. >> > >> > Regards, >> > Low >> > >> > On Thu, Sep 11, 2014 at 2:10 PM, Heng Sin Low wrote: >> >> >> >> Hi Jan, >> >> >> >> For the setting of boot delegation and system packages, I'm referring >> >> to >> >> the configure method at >> >> >> >> http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-osgi/test-jetty-osgi/src/test/java/org/eclipse/jetty/osgi/test/TestJettyOSGiBootWithAnnotations.java. >> >> There's the CoreOptions.bootDelegationPackages and >> >> CoreOptions.systemPackages call in there. >> >> >> >> Regards, >> >> Low >> >> >> >> On Thu, Sep 11, 2014 at 11:17 AM, Jan Bartel wrote: >> >>> >> >>> Low, >> >>> >> >>> >> >>> On 11 September 2014 12:22, Heng Sin Low wrote: >> >>> > Hi Jan, >> >>> > >> >>> > Here it goes - http://pastebin.com/PMbP2z9n >> >>> >> >>> Thanks for that, looking at your deployed bundle list and will get >> >>> back to you on that. >> >>> >> >>> >> >>> > Also, since the jetty jsp fragment 2.3.3 is working fine for me, >> >>> > does I >> >>> > miss >> >>> > anything if I stick with that instead ? >> >>> >> >>> You don't need it if you are using the apache jsp jars, and it may in >> >>> fact be detrimental - its only there because some of the glassfish >> >>> jars lack a correct manifest. >> >>> >> >>> > Just notice that there is setting of boot delegation and system >> >>> > packages in >> >>> > the jetty osgi unit testing code ( wasn't mention in the osgi doc ) >> >>> > , >> >>> > is >> >>> > that a must to get the whole thing working ? >> >>> >> >>> I don't think I added anything to the default delegation and system >> >>> packages for apache jsp - whatever you had for glassfish jsp should be >> >>> sufficient. However, if you're trying to use the apache jstl jars, >> >>&
Re: [jetty-users] Jetty 9.2.1 and JSP
y-instances-enabled/jft/start.ini
>
> - Module: https
>Depend: ssl
> XML: etc/jetty-https.xml
> Enabled:
>
> - Module: ipaccess
>Depend: server
> XML: etc/jetty-ipaccess.xml
> Enabled:
>
> - Module: jaas
>Depend: server
> LIB: lib/jetty-jaas-${jetty.version}.jar
> XML: etc/jetty-jaas.xml
> Enabled:
>
> - Module: jaspi
>Depend: security
> LIB: lib/jetty-jaspi-${jetty.version}.jar
> LIB: lib/jaspi/*.jar
> Enabled:
>
> - Module: jmx
>Depend: server
> LIB: lib/jetty-jmx-${jetty.version}.jar
> XML: etc/jetty-jmx.xml
> Enabled:
>
> - Module: jmx-remote
>Depend: jmx
> XML: etc/jetty-jmx-remote.xml
> Enabled:
>
> - Module: jndi
>Depend: server
> LIB: lib/jetty-jndi-${jetty.version}.jar
> LIB: lib/jndi/*.jar
> Enabled:
>
> * Module: jsp
>Depend: jsp-impl
>Depend: servlet
> Enabled: /var/jolie/webreserv/jetty-instances-enabled/jft/start.ini
>
> + Module: jsp-impl
> Ref: jsp-impl/apache-jsp
> LIB: lib/apache-jsp/*.jar
> Enabled:
>
> - Module: jstl-impl
> Ref: jsp-impl/apache-jstl
> LIB: lib/apache-jstl/*.jar
> Enabled:
>
> - Module: jstl
>Depend: jsp
>Depend: jstl-impl
> Enabled:
>
> - Module: jvm
> Enabled:
>
> - Module: logging
> LIB: lib/logging/**.jar
> LIB: resources/
> XML: etc/jetty-logging.xml
> Enabled:
>
> - Module: lowresources
>Depend: server
> XML: etc/jetty-lowresources.xml
> Enabled:
>
> - Module: monitor
>Depend: client
>Depend: server
> LIB: lib/monitor/jetty-monitor-${jetty.version}.jar
> XML: etc/jetty-monitor.xml
> Enabled:
>
> - Module: plus
>Depend: webapp
>Depend: server
>Depend: security
>Depend: jndi
> LIB: lib/jetty-plus-${jetty.version}.jar
> XML: etc/jetty-plus.xml
> Enabled:
>
> - Module: protonego
>Depend: protonego-impl/${protonego}
> Enabled:
>
> - Module: proxy
>Depend: client
>Depend: servlet
> LIB: lib/jetty-proxy-${jetty.version}.jar
> XML: etc/jetty-proxy.xml
> Enabled:
>
> - Module: quickstart
>Depend: plus
>Depend: server
>Depend: annotations
> LIB: lib/jetty-quickstart-${jetty.version}.jar
> Enabled:
>
> - Module: requestlog
>Depend: server
> XML: etc/jetty-requestlog.xml
> Enabled:
>
> - Module: resources
> LIB: resources/
> Enabled:
>
> - Module: rewrite
>Depend: server
> LIB: lib/jetty-rewrite-${jetty.version}.jar
> XML: etc/jetty-rewrite.xml
> Enabled:
>
> + Module: security
>Depend: server
> LIB: lib/jetty-security-${jetty.version}.jar
> Enabled:
>
> * Module: server
> LIB: lib/servlet-api-3.1.jar
> LIB: lib/jetty-schemas-3.1.jar
> LIB: lib/jetty-http-${jetty.version}.jar
> LIB: lib/jetty-server-${jetty.version}.jar
> LIB: lib/jetty-xml-${jetty.version}.jar
> LIB: lib/jetty-util-${jetty.version}.jar
> LIB: lib/jetty-io-${jetty.version}.jar
> XML: etc/jetty.xml
> Enabled: /var/jolie/webreserv/jetty-instances-enabled/jft/start.ini
>
> + Module: servlet
>Depend: server
> LIB: lib/jetty-servlet-${jetty.version}.jar
> Enabled:
>
> - Module: servlets
>Depend: servlet
> LIB: lib/jetty-servlets-${jetty.version}.jar
> Enabled:
>
> - Module: setuid
>Depend: server
> LIB: lib/setuid/jetty-setuid-java-1.0.1.jar
> XML: etc/jetty-setuid.xml
> Enabled:
>
> - Module: spdy
>Depend: protonego
>Depend: ssl
> LIB: lib/spdy/*.jar
> XML: etc/jetty-ssl.xml
> XML: etc/jetty-spdy.xml
> Enabled:
>
> - Module: ssl
>Depend: server
> XML: etc/jetty-ssl.xml
> Enabled:
>
> - Module: stats
>Depend: server
> XML: etc/jetty-stats.xml
> Enabled:
>
> + Module: webapp
>Depend: security
>Depend: servlet
> LIB: lib/jetty-webapp-${jetty.version}.jar
> Enabled:
>
> - Module: websocket
>Depend: annotations
> LIB: lib/websocket/*.jar
> Enabled:
>
> - Module: xinetd
>Depend: server
> XML: etc/jetty-xinetd.xml
> Enabled:
>
> Jetty Active Module Tree:
> -
> + Module: jsp-impl [transitive]
> + Module: server [enabled]
>+ Module: http [enabled]
>+ Module: security [transitive]
>+ Module: servlet [transitive]
> + Module:
Re: [jetty-users] Jetty 9.2.1 and JSP
Andrea, You need to upgrade to jetty-9.2.3 if you want to use a jre but do runtime jsp compilation OR as a workaround, enable the jstl module. The reason is this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=443262 It seems that another side effect of the jasper engine not being initialized correctly when no tlds are found in any META-INF/ location is that the compiler is not initialized correctly either. cheers Jan On 16 September 2014 23:03, Joakim Erdfelt wrote: > You'll want to fix your environment (as in your OS environment) before you > attempt to start / run java. > > 1) get rid of the --lib and -Djava.home hacks, those are both improper. > 2) set the following in your environment. > > $ export JAVA_HOME=/var/jdk1.7.0_51 > $ export PATH=$JAVA_HOME/bin:$PATH > > 3) now start jetty normally. > >$ cd /var/jwww/myapp >$ java -jar /var/jetty_9.2.1/start.jar > > Note: the setting of your environment AND the execution of jetty should be > in the same process. > > You seem to be using a manually installed java, so you'll want to make sure > these steps all occur together for your upstart scenario. > Either that, or use the java packaged by ubuntu and update-alternatives to > set the java default that you want to use. > > > -- > Joakim Erdfelt > webtide.com - intalio.com/jetty > Expert advice, services and support from from the Jetty & CometD experts > eclipse.org/jetty - cometd.org > > On Tue, Sep 16, 2014 at 5:54 AM, Andrea Cappelli > wrote: >> >> >> >> 2014-09-16 14:16 GMT+02:00 Andrea Cappelli : >>> >>> >>> >>> 2014-09-16 12:19 GMT+02:00 Jan Bartel : >>>> >>>> Hi Andrea, >>>> >>>> I haven't seen that particular error before, however in order to >>>> really properly initialize the apache jsp engine, you need to enable >>>> the annotations module. Try doing that and see if it makes a >>>> difference. >>> >>> >>> Hi Jan, >>> thanks for your reply >> >> >> I made some other test and seems that adding >> >> --lib=/var//jdk1.7.0_51/lib/tools.jar to classpath solve the problem. >> >> Any idea? >> -- >> Andrea Cappelli >> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] org.eclipse.jetty.servlet.DefaultServlet: "d != java.lang.String" since 9.2.3
Yes, its a bug in ResourceCache.Content. In fact I thought I'd fixed
that recently, but must have accidentally backed it out as part of
removing some printlns.
Opened bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=444547
Jan
On 19 September 2014 00:41, Joakim Erdfelt wrote:
> Sounds like a bug.
> But in the meantime, disable the debug logging of DefaultServlet in your
> logging configuration.
> That will avoid that specific warning/error for you.
>
> --
> Joakim Erdfelt
> webtide.com - intalio.com/jetty
> Expert advice, services and support from from the Jetty & CometD experts
> eclipse.org/jetty - cometd.org
>
> On Thu, Sep 18, 2014 at 7:08 AM, Vullhorst, Wolfgang
> wrote:
>>
>> Hi all,
>>
>>
>>
>> I installed Jetty 9.2.3.v20140905 and deployed my servlets successfully.
>>
>>
>>
>> When requesting Javascript or binary data I receive the following message:
>>
>>
>>
>> 18.09 13:30:53.176 WARN (qtp15683161-17 -
>> /cetis-ssml/nextgendialog/dlgnextgen/CH/images/common/header.gif?sessionId=ky8pOZB)
>> [servlet.DefaultServlet] EXCEPTION
>>
>> java.util.IllegalFormatConversionException: d != java.lang.String
>>
>> ...
>>
>> at java.util.Formatter.format(Formatter.java:2520)
>>
>> at java.util.Formatter.format(Formatter.java:2455)
>>
>> at java.lang.String.format(String.java:2927)
>>
>> at
>> org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:497)
>>
>>
>>
>> The source code of DefaultServlet looks like this at lines 496,497:
>>
>>
>>
>> if (LOG.isDebugEnabled())
>>
>> LOG.debug(String.format("uri=%s, resource=%s,
>> content=%s",request.getRequestURI(),resource,content));
>>
>>
>>
>> When I change the Log level in my configuration to INFO, the problem
>> logically disappears.
>>
>>
>>
>> My question is:
>>
>> Is this a bug in the DefaultServlet implementation (the code was modified
>> at this point fom 9.2.2 to 9.2.3) or do I miss something in my deployment
>> (e.g. content types)?
>>
>>
>>
>> Freundliche Grüße / Kind regards
>> Wolfgang Vullhorst
>>
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] org.eclipse.jetty.servlet.DefaultServlet: "d != java.lang.String" since 9.2.3
Fixed bug in jetty-9.2.x branch and will merge it across to jetty-9.3.
Jan
On 19 September 2014 10:26, Jan Bartel wrote:
> Yes, its a bug in ResourceCache.Content. In fact I thought I'd fixed
> that recently, but must have accidentally backed it out as part of
> removing some printlns.
>
> Opened bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=444547
>
> Jan
>
> On 19 September 2014 00:41, Joakim Erdfelt wrote:
>> Sounds like a bug.
>> But in the meantime, disable the debug logging of DefaultServlet in your
>> logging configuration.
>> That will avoid that specific warning/error for you.
>>
>> --
>> Joakim Erdfelt
>> webtide.com - intalio.com/jetty
>> Expert advice, services and support from from the Jetty & CometD experts
>> eclipse.org/jetty - cometd.org
>>
>> On Thu, Sep 18, 2014 at 7:08 AM, Vullhorst, Wolfgang
>> wrote:
>>>
>>> Hi all,
>>>
>>>
>>>
>>> I installed Jetty 9.2.3.v20140905 and deployed my servlets successfully.
>>>
>>>
>>>
>>> When requesting Javascript or binary data I receive the following message:
>>>
>>>
>>>
>>> 18.09 13:30:53.176 WARN (qtp15683161-17 -
>>> /cetis-ssml/nextgendialog/dlgnextgen/CH/images/common/header.gif?sessionId=ky8pOZB)
>>> [servlet.DefaultServlet] EXCEPTION
>>>
>>> java.util.IllegalFormatConversionException: d != java.lang.String
>>>
>>> ...
>>>
>>> at java.util.Formatter.format(Formatter.java:2520)
>>>
>>> at java.util.Formatter.format(Formatter.java:2455)
>>>
>>> at java.lang.String.format(String.java:2927)
>>>
>>> at
>>> org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:497)
>>>
>>>
>>>
>>> The source code of DefaultServlet looks like this at lines 496,497:
>>>
>>>
>>>
>>> if (LOG.isDebugEnabled())
>>>
>>> LOG.debug(String.format("uri=%s, resource=%s,
>>> content=%s",request.getRequestURI(),resource,content));
>>>
>>>
>>>
>>> When I change the Log level in my configuration to INFO, the problem
>>> logically disappears.
>>>
>>>
>>>
>>> My question is:
>>>
>>> Is this a bug in the DefaultServlet implementation (the code was modified
>>> at this point fom 9.2.2 to 9.2.3) or do I miss something in my deployment
>>> (e.g. content types)?
>>>
>>>
>>>
>>> Freundliche Grüße / Kind regards
>>> Wolfgang Vullhorst
>>>
>>>
>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>>
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>
>
> --
> Jan Bartel
> www.webtide.com
> 'Expert Jetty/CometD developer,production,operations advice'
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] My redirects are looping.
Hi Andrew, Can you describe exactly what you're trying to achieve, ie what's the problem you're trying to solve? Getting that sorted will help determine which tools you use to do it. Jan On 24 September 2014 10:03, Andrew Penhorwood wrote: > I have this context > > > "http://www.eclipse.org/jetty/configure_9_0.dtd";> > > > / > /sites/wordmissions/www > > default="."/>/etc/webdefault.xml > > > > www.wordmissions.org > > > > > > I setup this MovedContextHandler but the *.wordmissions.org cause the > browser to go into a redirect loop and crash. > > > > "http://www.eclipse.org/jetty/configure_9_0.dtd";> > > > / > http://www.wordmissions.org > true > false > false > > > > wordmissions.org > wordmissions.com > *.wordmissions.org > *.wordmissions.com > > > > > > If I don't use the *.wordmissions.org then any sub domain like > bob.wordmissions.org does not redirect to the correct location. It goes to > the default context which seems to be the first one defined. > > > -- > Andrew Penhorwood > and...@coldbits.com > www.coldbits.com > > _______ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 9.2.x - Annotations
Krumpi, Are the @PostConstruct methods on a servlet/filter/listener declared either in web.xml, a web-fragment.xml or an annotation, or programatically registered? Might be worth comparing your webapp to the test-spec.war in the demo-base of the distro, as that has some @PostConstruct methods on it. Jan On 27 September 2014 21:38, krumpi wrote: > Hi, > > i've got an application running with many @PostConstruct-methods. > > The Application had been deployed on Jetty 9.1.5 without problems. > After upgrading to Jetty 9.2.2/9.2.3 the PostConstruct-methods aren't > executed any more (checked with debugger). > Although I've tried different installations, I couldn't get the > Application to work correctly. > > Details: > - jetty: jetty-distribution-9.2.3.v20140905 / > jetty-distribution-9.2.2.v20140723 > - JSF 2.2 with myfaces 2.2.1/2.2.5 > - web.xml: web-app set to 2.5/3.0/3.1 > - jetty-plus/jetty-annotations is activated (checked with --list-modules > and --list-config) > - metadata-complete: false / not set > - The annotation-methods are in a jar-file in the webapp-directory. > - faces-config in jar-file: without / jsf 2.2 compatible "empty" > faces-config. > > Hope somebody could give me a hint what to try next. > > > Thanks in advance. > --- > krumpi > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Jan Bartel www.webtide.com 'Expert Jetty/CometD developer,production,operations advice' ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] jetty-maven-plugin, war overlay and hot redeploy
Ivan,
To be clear about what you're reporting: you are saying that when you
change static resources or classes from inside a dependency war, then
re-make that war and install it to your maven repo, jetty
automatically restarts but you are seeing old static resources and
classes? Even after doing a full and proper refresh of your browser
page (ie eliminated browser caching?)
thanks
Jan
On 2 October 2014 10:06, Ivan Savchenko wrote:
> Hi Joakim,
>
> Thanks for your reply. I commented on your stackoverlow answer, but not sure
> if you saw my question, so I just duplicate it in e-mail:
>
> I've tried this configuration (removed recoureBases) and I found that reload
> doesn't work for both resources and classes. When I change resource (like
> html) or recompile class (changing just method body), embed jetty is getting
> restarted and after restart it uses old resources and classes, which are
> probably taken from artefact from maven local repository. Could it be a bug?
> I'll appreciate any tips to debug this issue
>
> On 2 October 2014 10:23, Joakim Erdfelt wrote:
>>
>> Answered at
>> http://stackoverflow.com/questions/26150681/how-to-hot-redeploy-non-active-maven-project-via-jetty-maven-plugin
>>
>> --
>> Joakim Erdfelt
>> webtide.com - intalio.com/jetty
>> Expert advice, services and support from from the Jetty & CometD experts
>> eclipse.org/jetty - cometd.org
>>
>> On Tue, Sep 30, 2014 at 10:36 PM, Ivan Savchenko
>> wrote:
>>>
>>> Hi guys,
>>>
>>> I'm trying to evaluate jetty for rapid development or project which is
>>> currently running on tomcat. My configuration looks like
>>>
>>>
>>> org.eclipse.jetty
>>> jetty-maven-plugin
>>> 9.2.3.v20140905
>>>
>>> 3
>>>
>>>
>>> ${project.build.directory}/${project.build.finalName}/WEB-INF/web.xml
>>>
>>>
>>> ${basedir}/src/main/webapp
>>>
>>> ${basedir}/../SharedWeb/src/main/webapp
>>>
>>>
>>> true
>>> /test
>>>
>>>
>>>
>>>
>>> I have main war depending on SharedWeb war via war overlay mechanism. I
>>> specify resourceBases for both maven projects so changes in resources are
>>> scanned automatically and reloaded on the fly and all working fine. Also
>>> when I compile classes in main war, jetty restarts automatically, reloading
>>> the latest changes. But when I try to change any class in SharedWeb project
>>> and compile it, the class is not reloaded. I'm just wondering if there is a
>>> way to make embed jetty to reload classes from SharedWeb automatically? I
>>> understand that jetty-maven-plugin uses SharedWeb war from local maven
>>> repository, so I need to install SharedWeb artifact before I can see any
>>> changes. So I don't have high expectations, but maybe I'm missing something.
>>>
>>> Thanks.
>>>
>>> --
>>> Kind regards,
>>> Ivan
>>>
>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>>
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>
>
>
> --
> Kind regards,
> Ivan
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] jetty-maven-plugin, war overlay and hot redeploy
Ivan,
Re my previous posting, I can confirm that what I described works in
jetty: if the dependency war changes in local maven repo jetty will
redeploy, re-unpack it and use the changed static resources, classes
etc.
Having re-re-read your stackoverflow post, I think I see the problem:
the plugin is using the classes and resources from your dependency
war, NOT from the that you have added. The
simply tells jetty to watch that location and redeploy if something in
it changes.
So you need to tell jetty to use the classes and resources from your
dependency war's project, NOT the war artifact.
So do something like:
org.eclipse.jetty
jetty-maven-plugin
9.2.3.v20140905
${basedir}/../SharedWeb/target/classes
${basedir}/src/main/webapp
${basedir}/../SharedWeb/src/main/webapp
3
${basedir}/../SharedWeb/target/classes/
Jan
On 2 October 2014 10:28, Jan Bartel wrote:
> Ivan,
>
> To be clear about what you're reporting: you are saying that when you
> change static resources or classes from inside a dependency war, then
> re-make that war and install it to your maven repo, jetty
> automatically restarts but you are seeing old static resources and
> classes? Even after doing a full and proper refresh of your browser
> page (ie eliminated browser caching?)
>
> thanks
> Jan
>
> On 2 October 2014 10:06, Ivan Savchenko wrote:
>> Hi Joakim,
>>
>> Thanks for your reply. I commented on your stackoverlow answer, but not sure
>> if you saw my question, so I just duplicate it in e-mail:
>>
>> I've tried this configuration (removed recoureBases) and I found that reload
>> doesn't work for both resources and classes. When I change resource (like
>> html) or recompile class (changing just method body), embed jetty is getting
>> restarted and after restart it uses old resources and classes, which are
>> probably taken from artefact from maven local repository. Could it be a bug?
>> I'll appreciate any tips to debug this issue
>>
>> On 2 October 2014 10:23, Joakim Erdfelt wrote:
>>>
>>> Answered at
>>> http://stackoverflow.com/questions/26150681/how-to-hot-redeploy-non-active-maven-project-via-jetty-maven-plugin
>>>
>>> --
>>> Joakim Erdfelt
>>> webtide.com - intalio.com/jetty
>>> Expert advice, services and support from from the Jetty & CometD experts
>>> eclipse.org/jetty - cometd.org
>>>
>>> On Tue, Sep 30, 2014 at 10:36 PM, Ivan Savchenko
>>> wrote:
>>>>
>>>> Hi guys,
>>>>
>>>> I'm trying to evaluate jetty for rapid development or project which is
>>>> currently running on tomcat. My configuration looks like
>>>>
>>>>
>>>> org.eclipse.jetty
>>>> jetty-maven-plugin
>>>> 9.2.3.v20140905
>>>>
>>>> 3
>>>>
>>>>
>>>> ${project.build.directory}/${project.build.finalName}/WEB-INF/web.xml
>>>>
>>>>
>>>> ${basedir}/src/main/webapp
>>>>
>>>> ${basedir}/../SharedWeb/src/main/webapp
>>>>
>>>>
>>>> true
>>>> /test
>>>>
>>>>
>>>>
>>>>
>>>> I have main war depending on SharedWeb war via war overlay mechanism. I
>>>> specify resourceBases for both maven projects so changes in resources are
>>>> scanned automatically and reloaded on the fly and all working fine. Also
>>>> when I compile classes in main war, jetty restarts automatically, reloading
>>>> the latest changes. But when I try to change any class in SharedWeb project
>>>> and compile it, the class is not reloaded. I'm just wondering if there is a
>>>> way to make embed jetty to reload classes from SharedWeb automatically? I
>>>> understand that jetty-maven-plugin uses SharedWeb war from local maven
>>>> repository, so I need to install SharedWeb artifact before I can see any
>>>> changes. So I don't have high expectations, but maybe I'm missing
>>>> something.
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> Kind regards,
>>>> Ivan
>>>>
>>>&g
Re: [jetty-users] jetty-maven-plugin, war overlay and hot redeploy
Ivan,
The that is configured is a subclass of the standard
o.e.j.w.WebAppContext, therefore you can call any of the
single-argument setters that exist on it, or indeed any of that
class's superclasses. See
http://download.eclipse.org/jetty/stable-9/apidocs/org/eclipse/jetty/webapp/WebAppContext.html
cheers
Jan
On 2 October 2014 11:43, Ivan Savchenko wrote:
> Jan,
>
> Thanks, but I don't see extraClassPath parameter in 9.2.3.v20140905 version
> of plugin. I checked documentation here
> http://www.eclipse.org/jetty/documentation/9.2.3.v20140905/jetty-maven-plugin.html
> Is this parameter have another name? Or is there another way to specify
> additional classpath? As I understand classesDirectory parameter is for
> dependent war, not the dependency one.
>
> Thanks,
> Ivan
>
> On 2 October 2014 14:02, Jan Bartel wrote:
>>
>> Ivan,
>>
>> Re my previous posting, I can confirm that what I described works in
>> jetty: if the dependency war changes in local maven repo jetty will
>> redeploy, re-unpack it and use the changed static resources, classes
>> etc.
>>
>> Having re-re-read your stackoverflow post, I think I see the problem:
>> the plugin is using the classes and resources from your dependency
>> war, NOT from the that you have added. The
>> simply tells jetty to watch that location and redeploy if something in
>> it changes.
>>
>> So you need to tell jetty to use the classes and resources from your
>> dependency war's project, NOT the war artifact.
>>
>> So do something like:
>>
>>
>> org.eclipse.jetty
>> jetty-maven-plugin
>> 9.2.3.v20140905
>>
>>
>>
>>
>> ${basedir}/../SharedWeb/target/classes
>>
>>
>>
>>${basedir}/src/main/webapp
>>
>> ${basedir}/../SharedWeb/src/main/webapp
>>
>>
>> 3
>>
>>
>>
>> ${basedir}/../SharedWeb/target/classes/
>>
>>
>>
>>
>>
>> Jan
>>
>> On 2 October 2014 10:28, Jan Bartel wrote:
>> > Ivan,
>> >
>> > To be clear about what you're reporting: you are saying that when you
>> > change static resources or classes from inside a dependency war, then
>> > re-make that war and install it to your maven repo, jetty
>> > automatically restarts but you are seeing old static resources and
>> > classes? Even after doing a full and proper refresh of your browser
>> > page (ie eliminated browser caching?)
>> >
>> > thanks
>> > Jan
>> >
>> > On 2 October 2014 10:06, Ivan Savchenko
>> > wrote:
>> >> Hi Joakim,
>> >>
>> >> Thanks for your reply. I commented on your stackoverlow answer, but not
>> >> sure
>> >> if you saw my question, so I just duplicate it in e-mail:
>> >>
>> >> I've tried this configuration (removed recoureBases) and I found that
>> >> reload
>> >> doesn't work for both resources and classes. When I change resource
>> >> (like
>> >> html) or recompile class (changing just method body), embed jetty is
>> >> getting
>> >> restarted and after restart it uses old resources and classes, which
>> >> are
>> >> probably taken from artefact from maven local repository. Could it be a
>> >> bug?
>> >> I'll appreciate any tips to debug this issue
>> >>
>> >> On 2 October 2014 10:23, Joakim Erdfelt wrote:
>> >>>
>> >>> Answered at
>> >>>
>> >>> http://stackoverflow.com/questions/26150681/how-to-hot-redeploy-non-active-maven-project-via-jetty-maven-plugin
>> >>>
>> >>> --
>> >>> Joakim Erdfelt
>> >>> webtide.com - intalio.com/jetty
>> >>> Expert advice, services and support from from the Jetty & CometD
>> >>> experts
>> >>> eclipse.org/jetty - cometd.org
>> >>>
>> >>> On Tue, Sep 30, 2014 at 10:36 PM, Ivan Savchenko
>> >>> wrote:
>> >>>>
>> >>>> Hi guys,
>> >>>>
>> >>>> I'm trying to evaluate jetty for rapid development or project which
>> >>>> is
>> >>>> currently running on tomcat. My configuration looks like
>> >>>>
>> >>>>
>> >>>>
