Re: [jetty-users] shibboleth idp webapp under jetty 12.0.7

[Jan Bartel via jetty-users]

Sorry, I have a fix already, so I raised the relevant issue to get the
issue tracking number: https://github.com/jetty/jetty.project/issues/11574

cheers
Jan

On Tue, 26 Mar 2024 at 09:19, Greg Wilkins via jetty-users <
jetty-users@eclipse.org> wrote:

> Paul,
>
> Jetty will extract from to a temp web-inf directory to avoid the jar
> inside war class loading issues when a war file is not unpacked.   It
> should not be doing this if the webapp is unpacked.  It should definitely
> not put both on the classpath.
>
> I think we may have a bug here.  We will investigate.  To better track
> this, can you open an issue
> <https://github.com/jetty/jetty.project/issues> and paste your message in
> as the description.
>
> regards
>
>
>
> On Tue, 26 Mar 2024 at 04:54, Paul B. Henson via jetty-users <
> jetty-users@eclipse.org> wrote:
>
>> I'm currently running the shibboleth idp webapp 4 under jetty 9, and
>> trying to migrate to idp 5 using jetty 12. I've run into an odd problem,
>> I get the following error:
>>
>> Caused by: org.springframework.beans.factory.BeanCreationException: Error
>> creating bean with name 'flowRegistry' defined in class path resource
>> [net/shibboleth/idp/conf/webflow-config.xml]: Illegal attempt to register
>> pre-existing flow ID 'authn/DuoOIDC'via resource: URL
>> [jar:file:/var/lib/jetty/tmp/jetty-127_0_0_1-80-idp_war-_idp-any-10824638488520165161/webapp/WEB-INF/lib/idp-plugin-duo-impl-2.0.0.jar!/META-INF/net/shibboleth/idp/flows/authn/DuoOIDC/duo-oidc-authn-flow.xml]
>>
>> This generally occurs if there are multiple copies of the jar on the
>> classpath, such as if the war accidentally included more than one (which
>> isn't the case here).
>>
>> The deployment descriptor for the idp app is:
>>
>> 
>> /opt/shibboleth-idp/war/idp.war
>> /idp
>> false
>> false
>> true
>> 
>>
>> which is the recommended config per the idp documentation. With this
>> config, I see two separate copies of the jar in the jetty tmp directory,
>> one in webapp and one in webinf:
>>
>> # find | grep duo
>>
>> ./webapp/WEB-INF/lib/idp-plugin-duo-nimbus-client-impl-2.0.0.jar
>>
>> ./webapp/WEB-INF/lib/idp-plugin-duo-impl-2.0.0.jar
>>
>> ./webapp/WEB-INF/lib/idp-plugin-duo-api-2.0.0.jar
>>
>> ./webinf/WEB-INF/lib/idp-plugin-duo-nimbus-client-impl-2.0.0.jar
>>
>> ./webinf/WEB-INF/lib/idp-plugin-duo-impl-2.0.0.jar
>>
>> ./webinf/WEB-INF/lib/idp-plugin-duo-api-2.0.0.jar
>>
>>
>> If I update the config and set copyWebInf=false, there's only one copy
>> of the jar in the tmp directory (in webapp) and everything works fine.
>>
>> Looking at my existing jetty 9 deployment, there's only the webinf
>> directory in the tmp dir, not the webapp one. If I update my jetty 9
>> config and set extractWAR=true, then I get the same multiple copies (one
>> in webapp, one in webinf) as I do with extractWAR=false in jetty 12,
>> although this doesn't cause an error under jetty 9. If I set
>> extractWAR=true under jetty 12, I see no change in the content of the
>> tmp directory as compared to extractWAR=false.
>>
>> So I'm confused. Why is jetty 12 apparently extracting the war when
>> extractWAR=false? And when it does, how come the same jar file seems to
>> get processed twice, when that doesn't occur under jetty 9 with
>> extractWAR=true?
>>
>> I'm not sure if I'm hitting a bug or have something misconfigured. It
>> seems to be working now with copyWebInf=false, but that also seems more
>> of a workaround than a resolution. This feels buggy, that jetty is
>> extracting the war when it shouldn't be, and also loading the same jars
>> from two different places when the war is extracted *and* copyWebInf=true.
>> But I'm far from a jetty expert :).
>>
>> Thanks for any hints...
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
>
>
> --
> Greg Wilkins  CTO http://webtide.com
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] ClassLoader issues with custom LoginModule

[Jan Bartel via jetty-users]

xample I have found is doing it for Jetty 8 and this has changed
> in Jetty 11. So, have not figured that out yet. Although I would rather
> figure out why the module is using the webapp classloader so I do not need
> to set up customer, more permissive class loader configuration.
>
> The really funny thing is I have been using the static
> method Credential.MD5.*digest*(password) in my actual web application for
> a long time in the logic allowing users to change their password. Not sure
> how or why this ever worked, but I know it did in Jetty 8. I will admit, I
> just tested tonight and this no longer works. Must have gotten broken when
> I upgraded to Jetty 11 and I never realized.
>
> Is there any way to get my module to utilize the startJarLoader instead
> of the one in the webapp? I would really like to get this figured out. I
> may need to reimplement the whole Credential logic anyway since I can't use
> the method to digest passwords anymore. That would be a shame, but I do
> need the symmetric digest/validate logic available.
>
> I really appreciate any insight anyone has on why the module is using the
> webapp class loader.  Would really like to understand this.  Also, if
> anyone has any suggestions on how to solve this problem besides
> re-implementing/duplicating the credential logic I'd appreciate it.
>
> Scott
>
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Question about ALPN when embedding Jetty inside an OSGi bundle

[Jan Bartel via jetty-users]

Silvio,

Can you show us how your osgi manifest looks for the embedded jetty jars?

Jan

On Fri, 12 Jan 2024 at 04:52, Silvio Bierman via jetty-users <
jetty-users@eclipse.org> wrote:

> Thank you Joakim,
>
> I looked into SpiFly and it seems quite complex. It sounds to me like it
> is targeted at crossing bundle boundaries through ServiceLoaders while all
> I want is for Jetty (which is an internal implementation detail of my
> bundle) to use its own ALPN implemenation. Nothing ServiceLoader, ALPN or
> even Jetty/Servlet should be visible outside the bundle. I am not doing
> HTTP whiteboard at the OSGI level and do not want to deploy Jetty as OSGI
> bundle(s). If I could hardwire my embedded Jetty to its ALPNProvider and
> forsake ServiceLoader altogether that would be my prefered solution. Is
> that in any way possible?
>
> Cheers, Silvio
>
>
> On 30-12-2023 01:59, Joakim Erdfelt wrote:
>
> For OSGi you must (as in not optional) include a java ServiceLoader
> provider for your OSGi environment.
>
> The most common is Apache SpiFly.
>
> This is the most common reason for various things in Jetty not working in
> OSGi. (typically it's one of the following the ALPNProcessors, WebSocket,
> Precomputed Headers Impls, WebApp Configurations)
>
> Joakim Erdfelt / joa...@webtide.com
>
>
> On Fri, Dec 29, 2023 at 11:46 AM Silvio Bierman via jetty-users <
> jetty-users@eclipse.org> wrote:
>
>> I have Jetty 12.0.5 embedded inside an OSGi bundle with all dependencies
>> embedded. Jetty starts normally and I can get it working with a HTTP
>> listener. But when I add the code to add HTTPS support I get an error at
>> startup:
>>
>> java.lang.IllegalStateException: No Server ALPNProcessors!
>>
>> The jetty-alpn-server and jetty-alpn-java-server artifacts are included
>> in the bundle JAR as embedded dependency but the ALPN processor still
>> can not be found, probably because the OSGi class loader is incompatible
>> with how the search for ALPN processors works.
>>
>> Does anyone know how I can resolve this?
>>
>> Cheers,
>>
>> Silvio
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Run multiple instances of the same WAR servlet and pass it a config value

[Jan Bartel via jetty-users]

You could call the method setInitParameter(String,String) via the context
xml that defines the webapp, then you can retrieve it in the init() of your
servlet via the ServletConfig.getInitParameter(String).

Jan

On Thu, 5 Oct 2023 at 06:42, Alexander Farber via jetty-users <
jetty-users@eclipse.org> wrote:

> Apologies, the getServletConfig().getContextPath() in the init() of my
> servlet works well, that probably had been a problem in my VS Code.
>
> Still I wonder, if I would set a "property" with a "name" and "value" as
> described in the "Jetty XML Syntax" section
> https://eclipse.dev/jetty/documentation/jetty-10/operations-guide/index.html#og-xml
> - how could I retrieve the value in the servlet?
>
> Best regards
> Alex
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Exception in Jetty 12.0.1

[Jan Bartel via jetty-users]

Silvio,


This looks like a url with the sessionid encoded in the url, but it is
incomplete. It looks like the url just contains JSESSIONID, whereas it
should be JSESSIONID=.

I don't think we changed the way we parse the sessionid from the url since
at least jetty 10, but I could be wrong, I don't have my computer in front
of me.

Will look into it.


Jan

On Mon, 4 Sept 2023, 22:10 Silvio Bierman via jetty-users, <
jetty-users@eclipse.org> wrote:

> I do not know exactly which request causes the issue since I have not yet
> debugged that. There may be a UUID in the parameter list but these have
> length 36. The issue only occurs in 12.0.1 so I doubt the URL-paramaters
> are encoded incorrectly. We never use application character data in URL
> parameters so it is unlikely that any special characters are in there.
>
>
> On 04-09-2023 13:58, Bill Ross via jetty-users wrote:
>
> I wonder if this could be a string encoding issue? Can you think of any
> strings/params that are this long?
>
> 1234567890123456789012345678901234
>
>
> 2023-09-04 13:39:27.421:WARN :oejs.Response:qtp105374791-42: writeError:
> status=500, message=java.lang.StringIndexOutOfBoundsException: Index 34 out
> of bounds for length 34,
> response=org.eclipse.jetty.ee10.servlet.ServletContextResponse@77c7bf1
> java.lang.StringIndexOutOfBoundsException: Index 34 out of bounds for
> length 34
> at
> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55)
> at
> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52)
> at
> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213)
> at
> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210)
> at
> java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98)
> at
> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
> at
> java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
> at java.base/java.lang.String.checkIndex(String.java:4575)
> at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:46)
> at java.base/java.lang.String.charAt(String.java:1535)
>
>
> ---
> --
>
> Phobrain.com
>
>
> On 2023-09-04 04:45, Silvio Bierman via jetty-users wrote:
>
> I get a runtime exception when using Jetty 12.0.1 in embedded mode
> (http/2). I have to add that i call SessionIdManager.setWorkerName(null) to
> get rid of the node id in the session ID (which has always worked for
> previous versions).
>
> 2023-09-04 13:39:27.421:WARN :oejs.Response:qtp105374791-42: writeError:
> status=500, message=java.lang.StringIndexOutOfBoundsException: Index 34 out
> of bounds for length 34,
> response=org.eclipse.jetty.ee10.servlet.ServletContextResponse@77c7bf1
> java.lang.StringIndexOutOfBoundsException: Index 34 out of bounds for
> length 34
> at
> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55)
> at
> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52)
> at
> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213)
> at
> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210)
> at
> java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98)
> at
> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
> at
> java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
> at java.base/java.lang.String.checkIndex(String.java:4575)
> at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:46)
> at java.base/java.lang.String.charAt(String.java:1535)
> at
> org.eclipse.jetty.session.AbstractSessionManager.resolveRequestedSessionId(AbstractSessionManager.java:1261)
> at
> org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:652)
> at
> org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:811)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:177)
> at org.eclipse.jetty.server.Handler$Wrapper.handle(Handler.java:712)
> at org.eclipse.jetty.server.Server.handle(Server.java:176)
> at
> org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:648)
> at
> org.eclipse.jetty.util.thread.Invocable$ReadyTask.run(Invocable.java:105)
> at
> org.eclipse.jetty.http2.server.internal.HttpStreamOverHTTP2$1.run(HttpStreamOverHTTP2.java:129)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293)
> at
> 

Re: [jetty-users] Session ID oddity

[Jan Bartel]

The ".nodeX" suffix on the the session id can be used by load balancers to
direct traffic to particular nodes in the cluster, ie ensure session
stickiness.

If a session lands on a different node other than the one it originated on
(eg that node failed, or the load balancer is non sticky) then the suffix
will change but the rest of the session id is invariant.

The session id, minus the suffix, is unique across all nodes in the cluster.

Jan

On Sat, 18 Feb 2023, 06:21 John English,  wrote:

> Looking at my session ID in my browser's Network tools, I see that
> JSESSION=node01.node0
>
> When I do session.getid() inside the running code, I see node01
> (without the trailing ".node0").
>
> It's a minor triviality, but can anyone explain why they are different?
>
> Thanks,
> --
> John English
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] File session store: Unwriteable session

[Jan Bartel]

Hi Mark,

The jetty doco shows you how to correctly set up a DefaultSessionIdManager
in code:
https://www.eclipse.org/jetty/documentation/jetty-10/programming-guide/index.html#pg-server-session-architecture

I think what is happening is that your code is creating the
DefaultSessionIdManager, but not adding it to the Server with the
setSessionIdManager call, and thus it is not being started - it is in
startup that it works out what it's unique nodeid is, which is null in your
stacktrace.

If you don't want to do any explicit setup of the DefaultSessionIdManager,
you don't even have to create one yourself: the SessionHandler will create
one on startup (if it can't find one via the Server instance).

I might add a log warning or exception if a non-initialized
DefaultSessionIdManager is used, to make the problem more obvious.

cheers
Jan


On Sun, 14 Aug 2022 at 20:49, Mark Raynsford via jetty-users <
jetty-users@eclipse.org> wrote:

> Hello!
>
> I'm running into what I think is an easily reproducible bug:
>
> https://github.com/io7m/jetty-bug-20220814
>
> Can anyone else confirm this happens to them? This effectively makes
> the FileSessionStore unusable here, because it fails to do the one
> thing it's intended to do (allow sessions to survive server restarts).
>
> To reproduce, just run:
>
>
> https://github.com/io7m/jetty-bug-20220814/blob/master/src/main/java/com/io7m/jettybug/Main.java
>
> ... and try the sequence given in the `README.md` images.
>
> --
> Mark Raynsford | https://www.io7m.com
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] How Jetty Loads On-disk Session Files into Memory

[Jan Bartel]

I don't see why you would have so many sessions? Doesn't the poll have it's
own session? Or are you polling using all known existing session IDs?

The sessions will be read in from disk as needed, but will then stay in the
cache until they expire. As you are polling at a higher rate than the
session expiry time they will never expire and stay in the cache.

You could try adjusting some of the cache settings to do with eviction so
the session won't take up memory, but will remain on disk.

Jetty will periodically check for expired sessions on disk, and also at
start up. However,  as you have set a long expiry and are actively keeping
these sessions fresh by polling, it's unlikely many of the sessions will be
removed.

Jan

On Fri, 29 Apr 2022, 02:46 Wang Yicheng,  wrote:

> Hi team,
>
> We're using the session-store-file module to persist all sessions on disk.
> Recently we added a polling service to issue a request every second to the
> server. Since we deliberately set a very long time-out, it now leaves tons
> of session files and never gets purged. We were thinking of limiting the
> total number of sessions under the same user. Thus we created a  session ID> map to track that. However, this would not work throughout the
> server restart.
>
> Thus, I'm wondering if you could help with the following questions.
> 1. Will Jetty load all persisted sessions into memory during start-up, or
> is it a on-demand fashion?
> 2. If the answer to Q1 is "yes", is there a function that we can
> piggy-back into?
> 3. If the answer to Q1 is "no", is there a way to forcibly load in all
> persisted sessions?
>
> Btw, we're still on the Jetty 9 branch. We're aware of the upcoming EOL
> and have planned an upgrade :)
>
> Many thanks in advance!
>
> Best,
> Yicheng
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] 9.4: can I get rid of LoginService if no login?

[Jan Bartel]

You only need to configure a realm and loginservice if you're doing any
kind of authentication/authorization in your webapp.

You have some kind of configuration mismatch, as the the
ConstraintSecurityHandler has had a BasicAuthenticator set up on it -
either via jetty xml config or an entry in web.xml - but yet neither the
server or the context has had a LoginService set up on it. Your xml snippet
shows a FormAuthenticator, yet at runtime it's a BasicAuthencator, so
there's something wrong with your config.

If you don't want to do any authentication, take the  element
out of your web.xml (or however you've set up the BasicAuthenticator).
Otherwise, you need to provide some type of LoginService, usually set as a
bean on the Server instance, but can also be set on the WebAppContext
instance in the context xml file (I think you're calling it app.xml?).  You
haven't provided many details of your setup, but if you have another
webapp/context in the mix and it also requires authentication it will also
need access to a LoginService: generally, but not necessarily, all webapps
share the same LoginService, set as a bean on the Server. If you've only
configured a LoginService for one context, the other could be the one
producing the stacktrace.

regards
Jan

On Wed, 27 Apr 2022 at 09:51, Bill Ross via jetty-users <
jetty-users@eclipse.org> wrote:

> I'm trying to simplify before open-sourcing. I used to have a HashLogin,
> and it seems I can't get rid of the requirement. E.g. it wants the
> securityHandler, and an empty jetty-base/etc/realm.properties is needed
> at least.
>
> 9.4
>
> Thanks,
>
> Bill
>
>
> I seem to need this in jetty-base/webapps/app.xml:
>
>
>  
>  
>
>...
>
>  
>  
> class="org.eclipse.jetty.security.authentication.FormAuthenticator">
>  true
>
>  
>  true
>
>
> java.lang.IllegalStateException: No LoginService for
> org.eclipse.jetty.security.authentication.BasicAuthenticator@77825085 in
> ConstraintSecurityHandler@3568f9d2{STARTING}
>  at
>
> org.eclipse.jetty.security.authentication.LoginAuthenticator.setConfiguration(LoginAuthenticator.java:92)
>  at
>
> org.eclipse.jetty.security.SecurityHandler.doStart(SecurityHandler.java:410)
>  at
>
> org.eclipse.jetty.security.ConstraintSecurityHandler.doStart(ConstraintSecurityHandler.java:417)
>
> --
> Phobrain.com
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Duplicate valid session cookies?

[Jan Bartel]

Well, a proper client shouldn't be sending more than one cookie of the same
name for the same path and domain. If jetty receives multiple session
cookies, we look through them all (because we've had previous reports of
badly configured clients and apps) to find the one that is valid. If we
find more than one valid cookie, we don't know which one to use, so we log
it as an error.

On Tue, 5 Apr 2022 at 11:16, John English  wrote:

> On 05/04/2022 01:08, Jan Bartel wrote:
> > Somehow your client is sending 2 session cookies. Maybe you have have a
> > couple of different overlapping cookie paths configured on the server?
>
> No, it just looks like someone has been playing with openssl or the
> like. There are a series of HEAD and OPTIONS commands from a (known,
> internal) IP address. There was no login attempt, so perhaps whoever did
> it is trying a replay attack using session cookies from an earlier
> session. The only annoyance is it shows up as an unhandled exception, so
> I get emailed automatically.
>
> --
> John English
>
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Duplicate valid session cookies?

[Jan Bartel]

Somehow your client is sending 2 session cookies. Maybe you have have a
couple of different overlapping cookie paths configured on the server?

On Mon, 4 Apr 2022, 22:18 John English,  wrote:

> Just found this in today;s logfile:
>
> org.eclipse.jetty.http.BadMessageException: 400: Duplicate valid session
> cookies:
>   node01i4jd7v7oyycb11ehdwk49qdb6337.node0,
> node01vpsmo7e7yapu1ajschdxrfhk8336.node0
> at
>
> org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(SessionHandler.java:1712)
>
> Can someone explain what might have happened here?
>
> Thanks,
> --
> John English
>
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Migration help to Jersey 3 / Jetty 11

[Jan Bartel]

It would be useful if you could provide either a pointer to your project or
a minimum reproducible example. The exact stacktrace you get would also be
useful.

Jan

On Tue, 8 Feb 2022 at 09:29,  wrote:

> Hi,
>
> I'm having trouble migrating a Jersey/Jetty project (2.25) to Jersey 3 /
> Jetty 11.
>
> The Jersey part is working fine and I can serve requests using
> jersey-container-simple-http with a ResourceConfig to specify the
> service and filter classes.
>
> When I try to use a Jetty 11 jersey-container-jetty-http container to
> add static resources and HttpServletRequest session handling I'm unable
> to work out the correct steps to convert the code below to use the
> latest APIs.
>
> The HttpServletRequest injected by @Context is always null and I think
> I'm hitting the same problem as this post:
>
> https://stackoverflow.com/questions/68623182/cant-inject-httpservletrequest-into-containerrequestfilter-with-javal-11-jetty
>
> My pom dependencies are:
>
> 3.0.3
>
>  
>  
>  
>  org.glassfish.jersey
>  jersey-bom
>  ${jersey.version}
>  pom
>  import
>  
>  
>  
>
>   
>  org.glassfish.jersey.containers
>  jersey-container-jetty-http
>  
>
>  
>  org.glassfish.jersey.inject
>  jersey-hk2
>  
>
>  
>  jakarta.servlet
>  jakarta.servlet-api
>  5.0.0
>  
>
>  
>  org.glassfish.jersey.media
>  jersey-media-json-jackson
>  
>
>
> And advice would be greatly appreciated please.
>
> Many thanks,
>
> Chris
>
>
>
> ResourceConfig config = new ResourceConfig();
>
> config.packages(stuff);
>
> Server server = new Server(new InetSocketAddress("0.0.0.0", port));
>
> ServletContextHandler context = new ServletContextHandler(server, "/",
> ServletContextHandler.SESSIONS);
>
> SessionHandler sessions = context.getSessionHandler();
>
> SessionCache cache = new DefaultSessionCache(sessions);
>
> cache.setSessionDataStore(new NullSessionDataStore());
>
> sessions.setSessionCache(cache);
>
> Path staticResourcePath = resourcesPath.resolve("static");
>
> ServletHolder holderHome = new ServletHolder("static-home",
> DefaultServlet.class);
>
> holderHome.setInitParameter("resourceBase",
> staticResourcePath.toString());
> holderHome.setInitParameter("dirAllowed", "true");
> holderHome.setInitParameter("pathInfoOnly", "true");
>
> context.addServlet(holderHome, "/static/*");
>
> ServletHolder holderDefault = new ServletHolder("default",
> DefaultServlet.class);
> context.addServlet(holderDefault, "/");
>
> ServletHolder servletHolder = new ServletHolder(new
> ServletContainer(config));
>
> context.addServlet(servletHolder, "/*");
>
> try
> {
> server.start();
> server.join();
> }
> catch (Throwable t)
> {
> t.printStackTrace();
> }
> finally
> {
> server.destroy();
> }
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Need Help Configuring A Security Handler for Embedded Jetty

[Jan Bartel]

Hi,

You could subclass JettyWebXmlConfiguration, and point it to a different
jetty-web.xml, outside of your webapp that sets up only what you need.

Or you could create your own Configuration class, make sure it comes
_after_ JettyWebXmlConfiguration, and re-set up the SecurityHandler the way
you want it.

Or you could pre-extract the war, and copy over a different jetty-web.xml
file that doesn't do the security handler setup.

Jan

On Tue, 14 Dec 2021 at 04:10, Patrick Buchheit  wrote:

> Here is what the setup method for my tests looks like:
>
> *private* *static* HashLoginService *loginService*;
>
> *private* *final* *static* *int* *port* = 8089;
>
> @BeforeClass
>
> *public* *static* *void* setUpBeforeClass() *throws* Exception {
>
> *server* = *new* Server(*port*);
>
> ClassList classList = ClassList.*setServerDefault*(*server*);
>
> // uncommenting this line will avoid the error but require us to specify
> all the configuration from jetty-web.xml by hand.
>
> // boolean removed =
> classList.remove("org.eclipse.jetty.webapp.JettyWebXmlConfiguration");
>
> classList.addAfter("org.eclipse.jetty.webapp.FragmentConfiguration",
> "org.eclipse.jetty.plus.webapp.EnvConfiguration",
> "org.eclipse.jetty.plus.webapp.PlusConfiguration");
>
> WebAppContext context = *new* WebAppContext("eyerep-data", "/eyerep-data"
> );
>
> context.setDescriptor("src/main/webapp/WEB-INF/web.xml");
>
> context.setResourceBase("src/main/webapp");
>
> //we want a custom configuration for the tests so we need to supply an
> override descriptor
>
> context.setOverrideDescriptors(Arrays.*asList*(
> "src/test/resources/override-web.xml"));
>
> // Creating the LoginService for the realm
>
> *loginService* = *new* HashLoginService("EyeRep");
>
> // Setting the realm configuration there the users, passwords and roles
> reside
>
> *loginService*.setConfig("src/test/resources/realm.properties");
>
> context.getSecurityHandler().setLoginService(*loginService*);
>
> context.getSecurityHandler().setAuthenticator(*new* BasicAuthenticator());
>
> BasicDataSource ds = *null*;
>
> ds = *new* BasicDataSource();
>
> ds.setUrl(
> "jdbc:h2:mem:myDB;create=true;MODE=MSSQLServer;DATABASE_TO_UPPER=FALSE;");
>
> org.eclipse.jetty.plus.jndi.Resource mydatasource = *new*
> org.eclipse.jetty.plus.jndi.Resource(*null*, "jdbc/NavDS",ds);
>
>
> *server*.setHandler(context);
>
> *server*.start();
>
>
> }
>
>
>
> If I run the test with that code, it will end up overriding my custom
> security handler with the values from jetty-web.xml when server.start() is
> called. I can work around it by removing 
> org.eclipse.jetty.webapp.JettyWebXmlConfiguration
> from the class list, but then I have to specify everything that would
> normally be handled by jetty-web.xml by hand. I'm trying to keep my test
> configuration as close to the production config as possible and only
> override the things that need to be different for the test environment.
>
>
>
> On Fri, Dec 10, 2021 at 7:02 PM Jan Bartel  wrote:
>
>> Patrick,
>>
>> You'd need to provide the non-working code. In the absence of that, I've
>> whipped up a working example that might help you:
>>
>>
>> public class OneWebApp
>> {
>> public static Server createServer(int port) throws IOException
>> {
>> // Create a basic jetty server object that will listen on port
>> 8080.
>> // Note that if you set this to port 0 then a randomly available
>> port
>> // will be assigned that you can either look in the logs for the
>> port,
>> // or programmatically obtain it for use in test cases.
>> Server server = new Server(port);
>>
>> // The WebAppContext is the entity that controls the environment
>> in
>> // which a web application lives and breathes. In this example the
>> // context path is being set to "/" so it is suitable for serving
>> root
>> // context requests and then we see it setting the location of
>> the war.
>> // A whole host of other configurations are available, ranging
>> from
>> // configuring to support annotation scanning in the webapp
>> (through
>> // PlusConfiguration) to choosing where the webapp will unpack
>> itself.
>> WebAppContext webapp = new WebAppContext();
>> webapp.setContextPath("/");
>> Path warFile =
>> JettyDemos.find("demo-async-

Re: [jetty-users] Need Help Configuring A Security Handler for Embedded Jetty

[Jan Bartel]

Patrick,

You'd need to provide the non-working code. In the absence of that, I've
whipped up a working example that might help you:


public class OneWebApp
{
public static Server createServer(int port) throws IOException
{
// Create a basic jetty server object that will listen on port 8080.
// Note that if you set this to port 0 then a randomly available
port
// will be assigned that you can either look in the logs for the
port,
// or programmatically obtain it for use in test cases.
Server server = new Server(port);

// The WebAppContext is the entity that controls the environment in
// which a web application lives and breathes. In this example the
// context path is being set to "/" so it is suitable for serving
root
// context requests and then we see it setting the location of the
war.
// A whole host of other configurations are available, ranging from
// configuring to support annotation scanning in the webapp (through
// PlusConfiguration) to choosing where the webapp will unpack
itself.
WebAppContext webapp = new WebAppContext();
webapp.setContextPath("/");
Path warFile =
JettyDemos.find("demo-async-rest/demo-async-rest-webapp/target/demo-async-rest-webapp-@VER
@.war");
webapp.setWar(warFile.toString());

String realmResourceName = "etc/realm.properties";
ClassLoader classLoader =
SecuredHelloHandler.class.getClassLoader();
URL realmProps = classLoader.getResource(realmResourceName);
if (realmProps == null)
throw new FileNotFoundException("Unable to find " +
realmResourceName);

LoginService loginService = new HashLoginService("XX",
realmProps.toExternalForm());

webapp.getSecurityHandler().setLoginService(loginService);

// A WebAppContext is a ContextHandler as well so it needs to be
set to
// the server so it is aware of where to send the appropriate
requests.
server.setHandler(webapp);
return server;
}

public static void main(String[] args) throws Exception
{
int port = ExampleUtil.getPort(args, "jetty.http.port", 8080);
Server server = createServer(port);

Configurations.setServerDefault(server);

// Start things up!
server.start();

server.dumpStdErr();

// The use of server.join() the will make the current thread join
and
// wait until the server is done executing.
server.join();
}


On Sat, 11 Dec 2021 at 04:34, Patrick Buchheit  wrote:

> I posted this question on StackOverflow (
> https://stackoverflow.com/questions/70278074/override-login-service-for-embedded-jetty
> ) but I'm hoping someone here can help as well. I'm trying to do some
> integration testing on a jetty application with basic authentication. I'm
> using a jetty-web.xml file to configure the security handler like this:
>
>  *"org.eclipse.jetty.webapp.WebAppContext"*>
>
> /eyerep-data
>
>  *"./webapps"* />/eyerep-data/eyerep-data.war
>
> 
>
> 
>
>   
>
> EyeRep
>
>  default=*"."*/>/etc/realm.properties
>
>   
>
> 
>
>   
>
> 
>
>
>
> That works for production, but for testing, I'm using an embedded jetty
> server so I need to use a different config path for the login service.
>
>
> The problem I'm running into is that there doesn't seem to be any way to
> override just the config path. if I try to do something like:
>
>
> WebAppContext context = *new* WebAppContext();
>
> *loginService* = ((HashLoginService)context
> .getSecurityHandler().getLoginService());
>
> *loginService*.setConfig("src/test/resources/realm.properties");
>
>
> I found that there is no point where that code can succeed. If I run it
> before calling 'server.start()' the login service has not been initialized
> yet and I get an NPE. If I run it after the call to 'server.start()', it is
> too late. The server will already have tried and failed to setup the user
> store using the invalid config path.
>
>
> I'm at a bit of a loss here. I don't see anything equivalent to 
> context.setOverrideDescriptors()
> for jetty-web.xml. Is there any way to do this without completely replacing
> the work done by jetty-web.xml with manual code?
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Regrading R4_19_maintenance branch

[Jan Bartel]

Your logging looks a little messed up - ManagedServiceFactory Update Queue
is something from your application. Not sure what value it is adding
appearing in the logging like like.

> 2021-11-25 17:36:16.698:WARN:oejsh.ContextHandler:ManagedServiceFactory
Update Queue: Empty contextPath
This message is from ContextHandler.setContextPath method - it has been
called with the empty string ""

> 2021-11-25 17:36:16.709:INFO:oejs.session:ManagedServiceFactory Update
Queue: DefaultSessionIdManager workerName=node0
> 2021-11-25 17:36:16.709:INFO:oejs.session:ManagedServiceFactory Update
Queue: No SessionScavenger set, using defaults
These  lines come from the DefaultSessionIdManager start up.

> 2021-11-25 17:36:16.710:INFO:oejs.session:ManagedServiceFactory Update
Queue: node0 Scavenging every 60ms
This line most probably comes from the HouseKeeper startup, it is using the
default value for scavenging frequency

> 2021-11-25 17:36:16.735:INFO:oejs.session:ManagedServiceFactory Update
Queue: node0 Scavenging every 60ms
This line occurs whenever the HouseKeeper scavenging frequency is changed.

> 2021-11-25 17:36:16.752:INFO:oejs.session:ManagedServiceFactory Update
Queue: node0 Scavenging every 726000ms
This means the HouseKeeper scavenging frequency has been changed.

>From your logs it is impossible to tell if these are all different
concurrent instances of the ContextHandler, DefaultSessionIdManager and
HouseKeeper that have been started or
whether it's just one instance restarting.

Use the Server.setDumpAfterStart(true) option to log the exact
configuration of your jetty server after it starts. Try increasing the
detail of the logging to DEBUG until you can understand what is going on
-you should also check your osgi container as to which bundles have been
started/restarted/resolved etc

Jan
On Mon, 29 Nov 2021 at 23:23, Kuldeep Singh Budania <
kuldeep.sing...@gmail.com> wrote:

> Hi All,
>
> Can someone update on this as we are stuck at this point and application
> is not coming up because of this issue?
>
> Thanks,
> -
> Kuldeep Singh Budania
>
>
>
> On Mon, Nov 29, 2021 at 10:09 AM Kuldeep Singh Budania <
> kuldeep.sing...@gmail.com> wrote:
>
>> Hi All,
>>
>> I am upgrading jetty and OSGI versions from R-4.9 to R4_19_maintenance.
>> The Jetty version is getting upgraded from 9.4.11 to 9.4.44 and bundles
>> seem to be satisfied using 'Validate Bundles'.
>>
>> When I am trying to boot my system with newly mentioned artifacts, after
>> booting initially for 4-5 minutes, it suddenly stops processing further
>> with below message in the console:
>>
>> 2021-11-25 17:36:16.698:WARN:oejsh.ContextHandler:ManagedServiceFactory
>> Update Queue: Empty contextPath
>>
>> 2021-11-25 17:36:16.709:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: DefaultSessionIdManager workerName=node0
>>
>> 2021-11-25 17:36:16.709:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: No SessionScavenger set, using defaults
>>
>> 2021-11-25 17:36:16.710:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: node0 Scavenging every 60ms
>>
>> 2021-11-25 17:36:16.735:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: node0 Scavenging every 60ms
>>
>> 2021-11-25 17:36:16.736:WARN:oejsh.ContextHandler:ManagedServiceFactory
>> Update Queue: Empty contextPath
>>
>> 2021-11-25 17:36:16.739:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: DefaultSessionIdManager workerName=node0
>>
>> 2021-11-25 17:36:16.739:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: No SessionScavenger set, using defaults
>>
>> 2021-11-25 17:36:16.740:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: node0 Scavenging every 66ms
>>
>> 2021-11-25 17:36:16.752:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: node0 Scavenging every 726000ms
>>
>> 2021-11-25 17:36:16.761:WARN:oejsh.ContextHandler:ManagedServiceFactory
>> Update Queue: Empty contextPath
>>
>> 2021-11-25 17:36:16.776:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: DefaultSessionIdManager workerName=node0
>>
>> 2021-11-25 17:36:16.776:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: No SessionScavenger set, using defaults
>>
>> 2021-11-25 17:36:16.776:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: node0 Scavenging every 66ms
>>
>> 2021-11-25 17:36:16.792:INFO:oejs.session:ManagedServiceFactory Update
>> Queue: node0 Scavenging every 726000ms
>>
>>
>> Thanks in advance for the quick response
>>
>>
>> Thanks,
>> -
>> Kuldeep Si

Re: [jetty-users] Regrading R4_19_maintenance branch

[Jan Bartel]

Hi,

That branch isn't a branch in the jetty project, so the question might be
better addressed to the eclipse equinox group.

However, I can tell you that the current release of jetty-9.4 is at version
9.4.44. This is the list of changes from 9.4.43:

jetty-9.4.44.v20210927 - 27 September 2021
 + 3514 Use interpolation of versions from pom in mod files
 + 6369 Increment default jetty.http2.rateControl.maxEventsPerSecond
 + 6372 Review socket options configuration
 + 6487 Expose ServletHolder getter in ServletHandler$ChainEnd for auditing
   libraries to use
 + 6491 onDataAvailable() not called when HttpParser is closed prematurely
 + 6520 Error page has HTML error when writePoweredBy is enabled.
 + 6545 image/webp MIME type support
 + 6553 Review usage of Authentication.UNAUTHENTICATED in SecurityHandler
 + 6554 Allow creation of DefaultIdentityService without realmName.
 + 6558 Allow to configure return type in JSON array parsing
 + 6562 HttpOutput.write(ByteBuffer buffer)
 + 6603 HTTP/2 max local stream count exceeded
 + 6617 Add basic auth support for OpenId token endpoint
(client_secret_basic)
 + 6618 ID token `azp` claim should not be required if `aud` is single value
   array
 + 6652 Improve ReservedThreadExecutor dump
 + 6671 Update to apache jsp 8.5.70
 + 6772 Update to asm 9.2
 + 6853 Remove pack200 plugins
 + 6860 Correct IPv6 format
 + 6869 Correct Content-Type within HTML error pages
 + 6870 Encode control characters in URIUtil.encodePath
 + 6883 Welcome file redirects do not honor the relativeRedirectAllowed
option

regards
Jan

On Fri, 12 Nov 2021 at 15:11, Kuldeep Singh Budania <
kuldeep.sing...@gmail.com> wrote:

>   Hi,
>
> I am looking for jetty version 9.4.43 in eclipse equinox release and
> planning to move to the "*R4_19_maintenance branch*" ,
> I Just wanted to know if there are any open issues on this branch.
>
> Thanks in advance for quick response.
>
> Thanks,
> -
> Kuldeep Singh Budania
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] IllegalStateException: !UserIdentity with custom login service and NullSessionCache

[Jan Bartel]

erIdentity
>
> URI:/
> STATUS:500
> MESSAGE:java.lang.IllegalStateException: !UserIdentity
> SERVLET:org.eclipse.jetty.servlet.ServletHandler$Default404Servlet-5d7f1e59
> CAUSED BY:java.lang.IllegalStateException: !UserIdentity
>
> Caused by:
>
> java.lang.IllegalStateException: !UserIdentity
> at
> org.eclipse.jetty.security.authentication.SessionAuthentication.getUserIdentity(SessionAuthentication.java:68)
> at
> org.eclipse.jetty.security.authentication.FormAuthenticator.validateRequest(FormAuthenticator.java:331)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:537)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> com.paywholesail.components.server.metrics.OTInstrumentedHandler.handle(OTInstrumentedHandler.java:278)
> at
> org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:179)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:516)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
> at org.eclipse.jetty.io
> .AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
> at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:386)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
> at java.base/java.lang.Thread.run(Thread.java:831)
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Using WebAppContext at contextPath / but also serving images, sounds folders

[Jan Bartel]

Just change the context path in the context XML files for your webapp from
'/ws' to '/'.



On Tue, 10 Aug 2021, 23:02 Alexander Farber, 
wrote:

> The answer at Stackoverflow by Joakim is as always very informative, thank
> you for pointing to it.
>
> I just have one open question left: if I would like to serve 3 different
> things by Jetty - the 2 static subfolders (/images and /sounds) and one
> servlet (at /, serving Websockets, GET, POST) - then should I put them all
> in one XML config files (and what it the name, is it
> org.eclipse.jetty.server.handler.ContextHandler ?) or should I use 3
> different XML files?
>
> Best regards
> Alex
>
>
> On Tue, Aug 10, 2021 at 2:50 PM Alexander Farber <
> alexander.far...@gmail.com> wrote:
>
>>
>> On Tue, Aug 10, 2021 at 12:42 PM  wrote:
>>
>>> https://stackoverflow.com/a/68682598/458157
>>>
>> Ah the longest match is used? I was assuming the folder order in the
>> config files and maybe thus I was having problems
>>
>> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Using WebAppContext at contextPath / but also serving images, sounds folders

[Jan Bartel]

I'm not sure what you are wanting to do?  Do you want to keep your 2 static
content ContextHandlers (at context paths "/images" and "/sounds") and your
var/www/myservlet-3.0.war but move it to context path "/"?  Or are you
asking can you combine all 3 into a single webapp?

Jan

On Mon, 9 Aug 2021 at 21:21, Alexander Farber 
wrote:

> Hello dear Jetty users and developers,
>
> I am using 9.4.43.v20210629 for two things:
>
> 1) serve Websockets and GET, POST requests
> 2) serve files located in "images" and "sounds" folders
>
> My config for 1 is currently using contextPath "/ws":
>
> 
>  "http://www.eclipse.org/jetty/configure_9_0.dtd;>
> 
>
> /ws
> /var/www/myservlet-3.0.war
>
> 
>
>
> And the two configs for 2 are (only the "resourceBase" differs):
>
> 
>  "http://www.eclipse.org/jetty/configure_9_0.dtd;>
> 
> /images
> 
> 
>  /var/www/html/mydomain.com/images
> 
> true
> 
> 
> 
>
>
> It works well for several years already (and behind HAProxy 1.8.27), but I
> am not happy with having  contextPath "/ws" as a prefix to my servlet.
>
> I would like to change it to "/" aka root, but wonder how to keep
> "/images" and "/sounds" also servable by Jetty.
>
> Would org.eclipse.jetty.fcgi.server.proxy.TryFilesFilter help me in this
> situation?
>
> If a file (a sound or image file) is found, it should be served. Otherwise
> the Websockets, GET or POST request should be forwarded to my servlet.
>
> In the Jetty doc for FastCGI there is an example:
>
> 
> org.eclipse.jetty.fcgi.server.proxy.TryFilesFilter
> /*
> 
> 
>  class="javax.servlet.DispatcherType" />
> 
> 
> 
> files
> $path /index.php?p=$path
> 
> 
>
> but I am not sure how to apply it to my situation, how to replace the
> "index.php" by my servlet there?
>
> Best regards
> Alex
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] SameSite to STRICT

[Jan Bartel]

By the way, there is something wrong with the response headers you posted:
there are two Set-Cookie headers for different paths, and the one for root
has an empty session id - you must have some code that is explicitly
setting this.

Jan

On Thu, 15 Jul 2021 at 11:50, Jan Bartel  wrote:

> I can't reproduce this using the standard jetty distro and the standard
> test webapp that just creates a session via
> HttpServletRequest.getSession(true),  and the web.xml snippet you provided.
> I tried both 9.4.38 and the latest release and both result in a response
> with the correct Set-Cookie:
>
> Content-Length: 0
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> Location:
> http://localhost:8080/test/session/;jsessionid=node01ggldqpcbwnmpvb21biv2gceb0.node0?R=0
> Server: Jetty(9.4.38.v20210224)
> Set-Cookie: visited=yes
> Set-Cookie: JSESSIONID=node01ggldqpcbwnmpvb21biv2gceb0.node0; Path=/test;
> Secure; HttpOnly; SameSite=Strict
>
> Some questions for you:
>
> Are you sure you don't have any code that would interfere with the
> setCookie?
> Are you setting this web snippet in a web.xml, or a web-fragment.xml or a
> web-override.xml?
> Is this response being generated directly from jetty or is this via some
> other middleware that fonts it (apache, haproxy etc etc?)?
> When is this session created? Is it created by your code, or is it created
> by jetty implicitly via a form login?
> Did a session already exist when the form login occurred?
>
> Jan
>
> On Thu, 15 Jul 2021 at 04:02, Sai Sankar Challa via jetty-users <
> jetty-users@eclipse.org> wrote:
>
>> Sorry for snipped images.
>>
>>
>>
>> *Here is the configuration added in web.xml*
>>
>>
>>
>> 
>>
>> 
>>
>>  true
>>
>>  true
>>
>>  __SAME_SITE_STRICT__*
>>
>> 
>>
>>   
>>
>>
>>
>>
>>
>> *Response Headers*
>>
>> HTTP/1.1 200 OK
>>
>> Content-Type: text/html;charset=utf-8
>>
>> Set-Cookie: JSESSIONID=node0u99zpkbrxegr59fnxzac8m217.node0;
>> Path=/dashboard; Secure; HttpOnly
>>
>> Expires: Thu, 01 Jan 1970 00:00:00 GMT *//Here expecting SameSite to be
>> returned*
>>
>> Set-Cookie: JSESSIONID=; Path=/; Expires=Thu, 01-Jan-1970 00:00:00 GMT;
>> Max-Age=0
>>
>> X-Frame-Options: DENY
>>
>> Referrer-Policy: same-origin
>>
>> X-Content-Type-Options: nosniff
>>
>> X-XSS-Protection: 1; mode=block
>>
>> Content-Security-Policy: default-src 'self' https:; script-src 'self'
>> 'sha256-jLiclQuK1N1QZInVr4VJp6uKckK7+/GGsba4nme+PRA='
>> 'sha256-WcSfBbTthoIIuIdlLvU5spxO2l32y5Nw3Oh4jk4VnBY='; object-src 'self';
>> style-src 'self' 'unsafe-inline'; img-src 'self' data:; media-src 'self';
>> frame-src 'self'; font-src 'self'; connect-src 'self'
>>
>> Strict-Transport-Security: max-age=31536000; includeSubDomains
>>
>> Content-Length: 3737
>>
>>
>>
>> Thanks
>>
>> Sai
>>
>>
>>
>> *From:* Joakim Erdfelt 
>> *Sent:* Wednesday, July 14, 2021 10:46 PM
>> *To:* Sai Sankar Challa 
>> *Cc:* JETTY user mailing list 
>> *Subject:* Re: [jetty-users] SameSite to STRICT
>>
>>
>>
>> You are using browser developer tooling.
>>
>>
>>
>> What does the raw HTTP Response (that sets the JSESSIONID) look like?
>>
>> As in, can you copy/paste the response, in raw form (not in a table, not
>> post-parsed, not as an image) to this mailing list?
>>
>>
>> Joakim Erdfelt / joa...@webtide.com
>>
>>
>>
>>
>>
>> On Wed, Jul 14, 2021 at 11:34 AM Sai Sankar Challa <
>> saisanka...@motivitylabs.com> wrote:
>>
>> Thanks for the response.
>>
>>
>>
>> I am assuming this done by Jetty Server.
>>
>>
>>
>> The URL we are trying is the very first URL i.e., login page, post login
>> we do have filter classes where we are doing some modifications.
>>
>>
>>
>> Thanks
>>
>> Sai
>>
>>
>>
>>
>>
>> *From:* Joakim Erdfelt 
>> *Sent:* Wednesday, July 14, 2021 9:49 PM
>> *To:* JETTY user mailing list 
>> *Cc:* Sai Sankar Challa 
>> *Subject:* Re: [jetty-users] SameSite to STRICT
>>
>>
>>
>> What does the actual HTTP Response that created that JSESSIONID look like?
>>
>>
>> Joakim Erdfelt / joa...@webtide.com
>>
>>
>>
>>
>>
>> On Wed, Jul 14, 2021 at 11:07 AM Sai Sankar Challa via jetty-users <
>> jetty-

Re: [jetty-users] SameSite to STRICT

[Jan Bartel]

I can't reproduce this using the standard jetty distro and the standard
test webapp that just creates a session via
HttpServletRequest.getSession(true),  and the web.xml snippet you provided.
I tried both 9.4.38 and the latest release and both result in a response
with the correct Set-Cookie:

Content-Length: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location:
http://localhost:8080/test/session/;jsessionid=node01ggldqpcbwnmpvb21biv2gceb0.node0?R=0
Server: Jetty(9.4.38.v20210224)
Set-Cookie: visited=yes
Set-Cookie: JSESSIONID=node01ggldqpcbwnmpvb21biv2gceb0.node0; Path=/test;
Secure; HttpOnly; SameSite=Strict

Some questions for you:

Are you sure you don't have any code that would interfere with the
setCookie?
Are you setting this web snippet in a web.xml, or a web-fragment.xml or a
web-override.xml?
Is this response being generated directly from jetty or is this via some
other middleware that fonts it (apache, haproxy etc etc?)?
When is this session created? Is it created by your code, or is it created
by jetty implicitly via a form login?
Did a session already exist when the form login occurred?

Jan

On Thu, 15 Jul 2021 at 04:02, Sai Sankar Challa via jetty-users <
jetty-users@eclipse.org> wrote:

> Sorry for snipped images.
>
>
>
> *Here is the configuration added in web.xml*
>
>
>
> 
>
> 
>
>  true
>
>  true
>
>  __SAME_SITE_STRICT__*
>
> 
>
>   
>
>
>
>
>
> *Response Headers*
>
> HTTP/1.1 200 OK
>
> Content-Type: text/html;charset=utf-8
>
> Set-Cookie: JSESSIONID=node0u99zpkbrxegr59fnxzac8m217.node0;
> Path=/dashboard; Secure; HttpOnly
>
> Expires: Thu, 01 Jan 1970 00:00:00 GMT *//Here expecting SameSite to be
> returned*
>
> Set-Cookie: JSESSIONID=; Path=/; Expires=Thu, 01-Jan-1970 00:00:00 GMT;
> Max-Age=0
>
> X-Frame-Options: DENY
>
> Referrer-Policy: same-origin
>
> X-Content-Type-Options: nosniff
>
> X-XSS-Protection: 1; mode=block
>
> Content-Security-Policy: default-src 'self' https:; script-src 'self'
> 'sha256-jLiclQuK1N1QZInVr4VJp6uKckK7+/GGsba4nme+PRA='
> 'sha256-WcSfBbTthoIIuIdlLvU5spxO2l32y5Nw3Oh4jk4VnBY='; object-src 'self';
> style-src 'self' 'unsafe-inline'; img-src 'self' data:; media-src 'self';
> frame-src 'self'; font-src 'self'; connect-src 'self'
>
> Strict-Transport-Security: max-age=31536000; includeSubDomains
>
> Content-Length: 3737
>
>
>
> Thanks
>
> Sai
>
>
>
> *From:* Joakim Erdfelt 
> *Sent:* Wednesday, July 14, 2021 10:46 PM
> *To:* Sai Sankar Challa 
> *Cc:* JETTY user mailing list 
> *Subject:* Re: [jetty-users] SameSite to STRICT
>
>
>
> You are using browser developer tooling.
>
>
>
> What does the raw HTTP Response (that sets the JSESSIONID) look like?
>
> As in, can you copy/paste the response, in raw form (not in a table, not
> post-parsed, not as an image) to this mailing list?
>
>
> Joakim Erdfelt / joa...@webtide.com
>
>
>
>
>
> On Wed, Jul 14, 2021 at 11:34 AM Sai Sankar Challa <
> saisanka...@motivitylabs.com> wrote:
>
> Thanks for the response.
>
>
>
> I am assuming this done by Jetty Server.
>
>
>
> The URL we are trying is the very first URL i.e., login page, post login
> we do have filter classes where we are doing some modifications.
>
>
>
> Thanks
>
> Sai
>
>
>
>
>
> *From:* Joakim Erdfelt 
> *Sent:* Wednesday, July 14, 2021 9:49 PM
> *To:* JETTY user mailing list 
> *Cc:* Sai Sankar Challa 
> *Subject:* Re: [jetty-users] SameSite to STRICT
>
>
>
> What does the actual HTTP Response that created that JSESSIONID look like?
>
>
> Joakim Erdfelt / joa...@webtide.com
>
>
>
>
>
> On Wed, Jul 14, 2021 at 11:07 AM Sai Sankar Challa via jetty-users <
> jetty-users@eclipse.org> wrote:
>
> Hi Team
>
>
>
> We upgraded our Jetty version to 9.4.38.v20210224 and we want to Set
> 'SameSite' attribute to 'Strict'  in JSESSIONID for our portal security .
>
>
>
> We made the code changes as per below in our web.xml and still not seeing
> any difference.
>
>
>
>   
>
> 
>
>  false
>
>  false
>
>  __SAME_SITE_STRICT__
>
> 
>
>   
>
>
>
> Browser Cookie
>
>
>
>
>
> Can you please through some idea to get this done .
>
>
>
> Thanks
>
> Sai
>
>
>
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] HttpSession object lifetime

[Jan Bartel]

Hi Gordon,

You really shouldn't be holding references to the HttpSession in between
requests - there's no guarantee that when an app calls getSession() on each
new request that you will get back the same session object. I haven't
checked but I'm not even sure that if you call get Session() twice for the
same request that there's any guarantee that you'd get the same object.
Certainly if you've configured the NullSessionCache the object is not
shared at all. If you're using the DefaultSessionCache you've got a good
chance that you'll get back the same object, but not guaranteed because the
session many have been passivated out eg if you're using idle eviction.

Managing the lifecycle of the HttpSession is a tricky business and jetty is
working hard behind the scenes to maintain consistency and integrity -
hanging on to object references either won't work as you expect or won't
work at all.

Cheers
Jan



On Sun, 2 May 2021, 09:21 Gordon Jahn,  wrote:

> Hi folks,
>
> Is it not safe to store references to the session as long as you remove
> your references (if you still have one) when sessionDestroyed in
> HttpSessionListener is called?
>
> For this, I’d keep a Map of user -> session and when a new user logs in,
> I’d put the new session to the map and if map put call returns a session,
> invalidate it.
>
> Just make sure you when you remove the user/session from your user/session
> map in sessionDestroyed you use:
>
> default boolean remove(Object 
> <https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html> key,
>Object 
> <https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html> value)
>
> ... to make sure that the user is only removed if that session hasn’t been
> overwritten.
>
> I think this is safe as this way the session reference is only kept whilst
> the user is logged in and the server hasn’t killed the session but
> maybe I’ve misunderstood...? Or maybe I’ve just described Jan’s final
> approach?
>
> I ask because I do hold session references to be iterated over
> periodically for a session timeout that excludes some requests from
> resetting the timeout and perhaps I shouldn’t!?
>
> Gordon
>
> On Fri, 30 Apr 2021 at 01:04, Jan Bartel  wrote:
>
>> Hi Silvio,
>>
>> The HttpSession is a server object and thus its lifecycle is managed by
>> the server. Applications should not try and hold references to these
>> objects, as you've discovered ;)
>>
>> There isn't an api provided by the spec that would allow you to randomly
>> access any session by its id. I wouldn't encourage you to try and use any
>> jetty-specific apis to do that either, as once again you could wind up in a
>> mess trying to manage session lifecycles that are designed to be managed by
>> the container. So I don't see any easy way of proactively invalidating and
>> removing a session that is not part of the current request.
>>
>> Instead, you could investigate an approach like:
>>
>> + set a reasonably short timeout on sessions (tuned to your app's usage):
>> if the user logs in again somewhere else and never refers to that session
>> again, it will timeout
>> + keep a map of user -> sessionid that is the currently "valid" one, and
>> use a filter in your app to check if the user,sessionid tuple of the
>> current request is in that map; if not, invalidate the session or just
>> reject the request and let the session timeout
>>
>> An alternative approach would be to do a custom LoginService or jaas
>> LoginModule that prevented a subsequent login if the user is already logged
>> in. You would still need to manage and consult your own map of logged-in
>> users.
>>
>> cheers
>> Jan
>>
>> On Thu, 29 Apr 2021 at 23:32, Silvio Bierman 
>> wrote:
>>
>>> Hello all,
>>>
>>> This might be a generic servlet question but since Jetty (10.0.2,
>>> embedded mode) implements otherwise unspecified behavior I would like to
>>> ask this here anyway.
>>>
>>> I am trying to setup a scheme where user can be limited to no more than
>>> one logged in session at the same time. Any existing session for a
>>> particular user that logs in should be invalidated making the last
>>> session the only valid one. Somehow I need to manage a mapping from user
>>> name to some session referencing information that represents currently
>>> active sessions and allows me to invalidate a session. I did a
>>> quick-and-naive implementation using a WeakValueMap that maps the user
>>> name to a weak reference to a HttpSession object. Unfortunately, that
>>> showed

Re: [jetty-users] HttpSession object lifetime

[Jan Bartel]

Hi Silvio,

The HttpSession is a server object and thus its lifecycle is managed by the
server. Applications should not try and hold references to these objects,
as you've discovered ;)

There isn't an api provided by the spec that would allow you to randomly
access any session by its id. I wouldn't encourage you to try and use any
jetty-specific apis to do that either, as once again you could wind up in a
mess trying to manage session lifecycles that are designed to be managed by
the container. So I don't see any easy way of proactively invalidating and
removing a session that is not part of the current request.

Instead, you could investigate an approach like:

+ set a reasonably short timeout on sessions (tuned to your app's usage):
if the user logs in again somewhere else and never refers to that session
again, it will timeout
+ keep a map of user -> sessionid that is the currently "valid" one, and
use a filter in your app to check if the user,sessionid tuple of the
current request is in that map; if not, invalidate the session or just
reject the request and let the session timeout

An alternative approach would be to do a custom LoginService or jaas
LoginModule that prevented a subsequent login if the user is already logged
in. You would still need to manage and consult your own map of logged-in
users.

cheers
Jan

On Thu, 29 Apr 2021 at 23:32, Silvio Bierman 
wrote:

> Hello all,
>
> This might be a generic servlet question but since Jetty (10.0.2,
> embedded mode) implements otherwise unspecified behavior I would like to
> ask this here anyway.
>
> I am trying to setup a scheme where user can be limited to no more than
> one logged in session at the same time. Any existing session for a
> particular user that logs in should be invalidated making the last
> session the only valid one. Somehow I need to manage a mapping from user
> name to some session referencing information that represents currently
> active sessions and allows me to invalidate a session. I did a
> quick-and-naive implementation using a WeakValueMap that maps the user
> name to a weak reference to a HttpSession object. Unfortunately, that
> showed very erratic behavior (existing session where not in the map)
> that I at first could not explain. I decided to try what happened when I
> use the HttpSession objects themselves as mapped values. That worked. I
> suspect that the HttpSession objects could be more temporary than I
> thought that validity of a HttpSession object is only guaranteed during
> the lifetime of the HttpServletRequest object that it was obtained from.
> That makes perfect sense and explains what I observed.
>
> But now my question is: how can I achieve my goal? I can map user names
> to session IDs but have no way of accessing the related sessions, other
> than using the ID to make up some request that is handled by
> invalidating the then accessible session. This seems rather clumsy and I
> am hoping there is a better way to do this.
>
> Any suggestions would be welcome.
>
> Thanks,
>
> Silvio
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Heroku archetype web.xml still broken

[Jan Bartel]

Hi,

I think you should post this to the jersey community so they can update
their example.

Regards
Jan

On Fri, 26 Mar 2021, 14:13 Som Lima,  wrote:

> Thanks for trying to fix the heroku  archetype  web.xml .
>
> https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest3x/user-guide.html#new-webapp
> I really appreciate  you listening  but it is wrong.
>
> This is WRONG
> https://jakarta.ee/xml/ns/jakartaee; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
> http://java.sun.com/xml/ns/javaee/web-app_5_0.xsd;
> version="5.0">
>
> This is RIGHT
> https://jakarta.ee/xml/ns/jakartaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
> https://jakarta.ee/xml/ns/jakartaee
> https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;>
>
> I copied and pasted from
> jersey/examples/bookstore-webapp/src/main/webapp/WEB-INF/web.xml
>
> I know it is wrong because if you upload the created project into eclipse
> it lights up in red  with the message
>
> Multiple annotations found at this line:
> - There are '5' errors in 'web-app_5_0.xsd'.
> - schema_reference.4: Failed to read schema document '
> http://java.sun.com/xml/ns/javaee/
> web-app_5_0.xsd', because 1) could not find the document; 2) the document
> could not be read;
> 3) the root element of the document is not .
>
>
> I know it is 5 errors but lists only 3) . Could be 4. It is what it is.
>
> Regards
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] jersey to jsp different welcome file served on different platform

[Jan Bartel]

The other thing to consider, if your annotated servlet isn't serving your
page was expected when running with jetty configured by your main class, is
that you don't have annotation support turned on at all. Have a read of the
section of the documentation about annotations.


Jan

On Fri, 26 Mar 2021, 08:47 Som Lima,  wrote:

> Thank you I will check the documentation.
>
> In the meantime I have found that on the heroku website,
> following the git commands in the documentation for uploading,
> https://lit-savannah-55019.herokuapp.com/
> The contents of the index.html file  is served.
>
> meanwhile
> mvn jetty:run
> localhost:8080
> the contents of the servlet are served.
> That is very strange !
>
> Previously on the heroku website when I served index.jsp
> there was an error message saying JSP is not configured.
> Could this behaviour be an indication that somehow  two different versions
> of jetty are running on different platforms.
>
>
> 
> 
> Jersey RESTful Web Application!
> Jersey resource
> Visit http://jersey.java.net> Project Jersey website more
> information on Jersey! 
> contents of index.html 
> 
>
>
> @WebServlet(name="indexServlet", urlPatterns={"index.html"})
> public class IndexServlet extends HttpServlet {
>
> private static final long serialVersionUID = 1L;
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response)
> throws ServletException, IOException {
>
> response.setContentType("text/html");
> PrintWriter out=response.getWriter();
> out.print("");
> out.print("Jersey RESTful Web Application!");
> out.print("Jersey resource");
> out.print("Visit http://jersey.java.net> Project
> Jersey website ");
> out.print("more information on Jersey!");
> out.print(" contents of servlet Indexservlet ");
> out.print("");
> }
> }
>
>
> On Thu, 25 Mar 2021, 21:28 Jan Bartel,  wrote:
>
>>
>> You're using a servlet to serve a welcome file instead of serving a
>> static file. There is some ambiguity in the servlet spec around serving of
>> welcome files, and jetty's default mode looks for a static resource. There
>> are other configuration modes that will let you serve from the servlet
>> without any associated static resource  - I think it's "exact" mode on the
>> DefaultServlet, but check the jetty doco for the correct setting:
>>
>>
>> https://www.eclipse.org/jetty/documentation/jetty-9/index.html#default-servlet
>>
>> On Fri, 26 Mar 2021, 06:37 Som Lima,  wrote:
>>
>>> Something rather strange and unexpected just happened.
>>>
>>> I put back the index.html file and now the contents of the java servlet
>>> class is being published to the browser.
>>>
>>> The contents of index.html file is being overridden
>>>
>>> Even a completely empty files called index.html does the trick.
>>>
>>>
>>>
>>> On Thu, 25 Mar 2021, 17:15 Simone Bordet,  wrote:
>>>
>>>> Hi,
>>>>
>>>> On Thu, Mar 25, 2021 at 4:04 PM Som Lima 
>>>> wrote:
>>>> >
>>>> >
>>>> > If I do not have web.xml in the aforementioned project
>>>> > and I have a  java class annotated with @WebServlet and also
>>>> decorated with urlPattern={"/index.html"}
>>>> > I am getting a 500 Errors with localhost:8080/
>>>> >
>>>> > The java class as servlet  is published in browser with the url
>>>> localhost:8080/index.html
>>>> >
>>>> > Is there anyway to get this java class as servlet to be picked up
>>>> > because I feel the servlet  should be registered with the servlet
>>>> container and should return
>>>> > on localhost:8080/  same as  src/mainwebapp/index.html
>>>> src/mainwebapp/index.jsp files.
>>>> >
>>>> > @WebServlet(name="indexServlet", urlPatterns={"/index.html"})
>>>> > public class IndexServlet extends HttpServlet {
>>>> >
>>>> > private static final long serialVersionUID = 1L;
>>>> >
>>>> > protected void doGet(HttpServletRequest request,
>>>> HttpServletResponse response)
>>>> > throws ServletException, IOException {
>>>> >
>>>> > response.setContentType("te

Re: [jetty-users] jersey to jsp: error 500 on index

[Jan Bartel]

You're using a servlet to serve a welcome file instead of serving a static
file. There is some ambiguity in the servlet spec around serving of welcome
files, and jetty's default mode looks for a static resource. There are
other configuration modes that will let you serve from the servlet without
any associated static resource  - I think it's "exact" mode on the
DefaultServlet, but check the jetty doco for the correct setting:

https://www.eclipse.org/jetty/documentation/jetty-9/index.html#default-servlet

On Fri, 26 Mar 2021, 06:37 Som Lima,  wrote:

> Something rather strange and unexpected just happened.
>
> I put back the index.html file and now the contents of the java servlet
> class is being published to the browser.
>
> The contents of index.html file is being overridden
>
> Even a completely empty files called index.html does the trick.
>
>
>
> On Thu, 25 Mar 2021, 17:15 Simone Bordet,  wrote:
>
>> Hi,
>>
>> On Thu, Mar 25, 2021 at 4:04 PM Som Lima  wrote:
>> >
>> >
>> > If I do not have web.xml in the aforementioned project
>> > and I have a  java class annotated with @WebServlet and also decorated
>> with urlPattern={"/index.html"}
>> > I am getting a 500 Errors with localhost:8080/
>> >
>> > The java class as servlet  is published in browser with the url
>> localhost:8080/index.html
>> >
>> > Is there anyway to get this java class as servlet to be picked up
>> > because I feel the servlet  should be registered with the servlet
>> container and should return
>> > on localhost:8080/  same as  src/mainwebapp/index.html
>> src/mainwebapp/index.jsp files.
>> >
>> > @WebServlet(name="indexServlet", urlPatterns={"/index.html"})
>> > public class IndexServlet extends HttpServlet {
>> >
>> > private static final long serialVersionUID = 1L;
>> >
>> > protected void doGet(HttpServletRequest request,
>> HttpServletResponse response)
>> > throws ServletException, IOException {
>> >
>> > response.setContentType("text/html");
>> > PrintWriter out=response.getWriter();
>> >
>> > out.print("");
>> > out.print("Hello Index Servlet");
>> > out.print("");
>> > }
>> > }
>> >
>> >
>> > HTTP ERROR 500 java.lang.ClassCastException: class [Ljava.lang.Object;
>> cannot be cast to class [Ljava.lang.String; ([Ljava.lang.Object; and
>> [Ljava.lang.String; are in module java.base of loader 'bootstrap')
>> >
>> > URI:/
>> > STATUS:500
>> > MESSAGE:java.lang.ClassCastException: class [Ljava.lang.Object; cannot
>> be cast to class [Ljava.lang.String; ([Ljava.lang.Object; and
>> [Ljava.lang.String; are in module java.base of loader 'bootstrap')
>> > SERVLET:default
>> > CAUSED BY:java.lang.ClassCastException: class [Ljava.lang.Object;
>> cannot be cast to class [Ljava.lang.String; ([Ljava.lang.Object; and
>> [Ljava.lang.String; are in module java.base of loader 'bootstrap')
>> >
>> > Caused by:
>> >
>> > java.lang.ClassCastException: class [Ljava.lang.Object; cannot be cast
>> to class [Ljava.lang.String; ([Ljava.lang.Object; and [Ljava.lang.String;
>> are in module java.base of loader 'bootstrap')
>> > at
>> org.eclipse.jetty.util.resource.ResourceCollection.list(ResourceCollection.java:426)
>> > at
>> org.eclipse.jetty.util.resource.Resource.getListHTML(Resource.java:479)
>> > at
>> >
>> >
>>
>> Please open an issue with as much information as possible at
>> https://github.com/eclipse/jetty.project/issues.
>>
>> Thanks!
>>
>> --
>> Simone Bordet
>> 
>> http://cometd.org
>> http://webtide.com
>> Developer advice, training, services and support
>> from the Jetty & CometD experts.
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] jersey to jsp

[Jan Bartel]

You do not need to add the welcome files clause to your web.xml. Jetty has
a default web.xml file that sets up jsp for you.

I think the issue is that your web.xml file is not targetted at jetty-11,
which uses the jakarta.* namespace as Olivier pointed out in a previous
post.

Jan

On Thu, 25 Mar 2021 at 11:57, Som Lima  wrote:

> Sorry you are right. I got confused.
> There is a main  class which  came with the archetype. That works when I
> ran as java application in eclipse IDE with my hack. I think the main class
> is
> invoked for unit tests.
>
> So I just ran mvn exec:java I got an error because I don't have a main
> class declared in the pom.xml. I have no issue with the error.
>
> I am running the archetype as
> mvn jetty:run
>
> I tried adding welcome-file tags  ( see below) in the existing archetype
> 's web.xml for index.html to be picked up but I am getting a 404.
>
> 
> http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>  http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> 
> Jersey Web Application
> org.glassfish.jersey.servlet.ServletContainer class>
> 
> jersey.config.server.provider.packages
> com.example
> 
> 1
> 
> 
> Jersey Web Application
> /*
> 
>
> 
> index.html
> 
> 
>
> On Thu, 25 Mar 2021, 00:15 Jan Bartel,  wrote:
>
>> Now I'm confused. You say you're using mvn jetty:run BUT you have posted
>> a java main class where you are configuring and running jetty in embedded
>> mode. Which is it?
>>
>> Using mvn jetty:run will run jetty inside maven, and deploy the webapp
>> that is your maven project.  It does not run your main class.
>>
>> Alternatively, you can write a main class to startup up jetty and deploy
>> your webapp. You then need to ensure that all of the required jetty jars
>> and other dependencies are on the execution classpath. You'd need to use
>> something like the maven exec plugin to run it, or run it manually at the
>> command line in the usual java fashion.
>>
>> On Thu, 25 Mar 2021 at 10:46, Som Lima  wrote:
>>
>>> I used this archetype.
>>>
>>> mvn archetype:generate -DarchetypeArtifactId=jersey-heroku-webapp \
>>> -DarchetypeGroupId=org.glassfish.jersey.archetypes
>>> -DinteractiveMode=false \
>>> -DgroupId=com.example -DartifactId=simple-heroku-webapp
>>> -Dpackage=com.example \
>>> -DarchetypeVersion=3.0.1
>>>
>>>
>>>
>>> running   as  mvn jetty:run
>>>
>>>
>>> I made this hack by adding a new class
>>> HelloHandler and commenting out the  line server.setHandler(root)
>>>  , which has worked so far but it is just a hack in the existing Main
>>> class. I was hoping I can just an index.html but seems to be too good to be
>>> true.  I guess I will have to rework the existing Main class.
>>>
>>> //server.setHandler(root);
>>>   server.setHandler(new HelloHandler());
>>>
>>> public class HelloHandler extends AbstractHandler
>>> {
>>> public void handle(String target,Request
>>> baseRequest,HttpServletRequest request,HttpServletResponse response)
>>> throws IOException, ServletException
>>> {
>>> response.setContentType("text/html;charset=utf-8");
>>> response.setStatus(HttpServletResponse.SC_OK);
>>> baseRequest.setHandled(true);
>>> response.getWriter().println("Hello World");
>>> }
>>> }
>>>
>>>
>>> public class Main {
>>>
>>> public static void main(String[] args) throws Exception{
>>> // The port that we should run on can be set into an environment
>>> variable
>>> // Look for that variable and default to 8080 if it isn't there.
>>> String webPort = System.getenv("PORT");
>>> if (webPort == null || webPort.isEmpty()) {
>>> webPort = "8080";
>>> }
>>>
>>> final Server server = new Server(Integer.valueOf(webPort));
>>>
>>> final WebAppContext root = new WebAppContext();
>>>
>>> root.setContextPath("/");
>>> // Parent loader priority is a class loader setting that Jetty
>>> accepts.
>>> // By default Jetty will behave like most web containers in that
>>> it will
>>>

Re: [jetty-users] jersey to jsp

[Jan Bartel]

Now I'm confused. You say you're using mvn jetty:run BUT you have posted a
java main class where you are configuring and running jetty in embedded
mode. Which is it?

Using mvn jetty:run will run jetty inside maven, and deploy the webapp that
is your maven project.  It does not run your main class.

Alternatively, you can write a main class to startup up jetty and deploy
your webapp. You then need to ensure that all of the required jetty jars
and other dependencies are on the execution classpath. You'd need to use
something like the maven exec plugin to run it, or run it manually at the
command line in the usual java fashion.

On Thu, 25 Mar 2021 at 10:46, Som Lima  wrote:

> I used this archetype.
>
> mvn archetype:generate -DarchetypeArtifactId=jersey-heroku-webapp \
> -DarchetypeGroupId=org.glassfish.jersey.archetypes
> -DinteractiveMode=false \
> -DgroupId=com.example -DartifactId=simple-heroku-webapp
> -Dpackage=com.example \
> -DarchetypeVersion=3.0.1
>
>
>
> running   as  mvn jetty:run
>
>
> I made this hack by adding a new class
> HelloHandler and commenting out the  line server.setHandler(root)
>  , which has worked so far but it is just a hack in the existing Main
> class. I was hoping I can just an index.html but seems to be too good to be
> true.  I guess I will have to rework the existing Main class.
>
> //server.setHandler(root);
>   server.setHandler(new HelloHandler());
>
> public class HelloHandler extends AbstractHandler
> {
> public void handle(String target,Request
> baseRequest,HttpServletRequest request,HttpServletResponse response)
> throws IOException, ServletException
> {
> response.setContentType("text/html;charset=utf-8");
> response.setStatus(HttpServletResponse.SC_OK);
> baseRequest.setHandled(true);
> response.getWriter().println("Hello World");
> }
> }
>
>
> public class Main {
>
> public static void main(String[] args) throws Exception{
> // The port that we should run on can be set into an environment
> variable
> // Look for that variable and default to 8080 if it isn't there.
> String webPort = System.getenv("PORT");
> if (webPort == null || webPort.isEmpty()) {
> webPort = "8080";
> }
>
> final Server server = new Server(Integer.valueOf(webPort));
>
> final WebAppContext root = new WebAppContext();
>
> root.setContextPath("/");
> // Parent loader priority is a class loader setting that Jetty
> accepts.
> // By default Jetty will behave like most web containers in that
> it will
> // allow your application to replace non-server libraries that are
> part of the
> // container. Setting parent loader priority to true changes this
> behaviour.
> // Read more here:
> http://wiki.eclipse.org/Jetty/Reference/Jetty_Classloading
> root.setParentLoaderPriority(true);
>
> final String webappDirLocation = "src/main/webapp/";
> root.setDescriptor(webappDirLocation + "/WEB-INF/web.xml");
> root.setResourceBase(webappDirLocation);
>
> //server.setHandler(root);
>   server.setHandler(new HelloHandler());
> server.start();
> server.join();
> }
> }
>
>
>
>
>
>
>
> On Wed, 24 Mar 2021, 23:13 Jan Bartel,  wrote:
>
>> Hi,
>>
>> How are you running jetty? Are you running in the
>> distribution/embedded/maven plugin? Do you have jsp and it's dependencies
>> enabled?
>>
>> Making a very simple webapp that is a directory that looks like:
>>
>> /test
>>   index.jsp
>>
>> deploys and runs just fine on the jetty-11 distro, so there must be
>> something else going on with your setup.
>>
>> Firstly, I would make sure you're using the latest full release version
>> of jetty-11, which is 11.0.1. Then build up from a simple webapp like the
>> one above gradually adding more of your app in until you can see where the
>> problem lies.
>>
>> regards
>> Jan
>>
>> On Thu, 25 Mar 2021 at 09:19, Som Lima  wrote:
>>
>>> Hi,
>>>
>>> I am using  working on the heroku  archetype   webapp  for  jersey jax-rs
>>>  section 5.1
>>>
>>>
>>> https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest3x/getting-started.html#deploy-it-on-heroku
>>>
>>> It is publishing   jax-rs resources.
>>>
>>> https://lit-savannah-55019.herokuapp.com/myresource
>&

Re: [jetty-users] jersey to jsp

[Jan Bartel]

Hi,

How are you running jetty? Are you running in the
distribution/embedded/maven plugin? Do you have jsp and it's dependencies
enabled?

Making a very simple webapp that is a directory that looks like:

/test
  index.jsp

deploys and runs just fine on the jetty-11 distro, so there must be
something else going on with your setup.

Firstly, I would make sure you're using the latest full release version of
jetty-11, which is 11.0.1. Then build up from a simple webapp like the one
above gradually adding more of your app in until you can see where the
problem lies.

regards
Jan

On Thu, 25 Mar 2021 at 09:19, Som Lima  wrote:

> Hi,
>
> I am using  working on the heroku  archetype   webapp  for  jersey jax-rs
>  section 5.1
>
>
> https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest3x/getting-started.html#deploy-it-on-heroku
>
> It is publishing   jax-rs resources.
>
> https://lit-savannah-55019.herokuapp.com/myresource
>
> The archetype seem to have everything
> to be a webapp also , so I thought I just need to drop jsp in the
> src/main/webapp/index.jsp
>
> Adding welcome-file-list tag and
> welcome-file  tag with index.jsp.
> in the web.xml file.
>
> That didn't do the trick.
>
> I got a 404.
> running jetty  11.0.0.beta3.
>
> Can you please tell me what  more is needed for the index.jsp to be
> published
> .
>
> Regards
>
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Session invalidation

[Jan Bartel]

Difficult to tell you what is happening with so little information ;)  What
version of jetty? What configuration of the session management:
SessionCache, SessionStore, SessionIdManager?

Does your webapp involve forwarding between contexts? Does your webapp have
any filters or 3rd party libraries that might create a session?

Have you used a tool like Chrome's developer panel that shows you the http
dialog going on between the tabs and the server? Or tcpdump/wireshark etc
etc?

Have you turned on DEBUG level logging for org.eclipse.jetty.server.session?

How does SessionState get set onto the Session? Is it via a
HttpSessionListener? If so, Request.getSession() will create a new Session
if one does not exist, and the listener could set the SessionState on it.

Jan



On Fri, 26 Feb 2021 at 13:14, John English  wrote:

> I have a webapp requiring a user to log in before doing anything else.
> State information is stored in an object in a session attribute called
> "state". When I log out I do the following:
>
>  HttpSession session = request.getSession();
>  if (session != null) {
>session.removeAttribute("state");
>try {
>  session.invalidate();
>}
>catch (IllegalStateException e) { }
>  }
>
> I go to the webapp and log in, then open another tab for the same webapp
> and log out, executing the code above. I then go back to the first tab
> and click a button which sends a POST request to a servlet that starts
> off like this:
>
>  HttpSession session = request.getSession();
>  SessionState state = (session != null ?
> (SessionState)session.getAttribute("state") : null);
>
> The session and the state are both valid objects after these two lines.
>
> Can anyone tell me what might be happening here?
>
> --
> John English
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] File upload failing with InterruptedException in Jetty serer

[Jan Bartel]

va.lang.Object.wait(Native Method)
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput - at
>> java.lang.Object.wait(Object.java:502)
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput - at
>> org.eclipse.jetty.server.HttpInput.blockForContent(HttpInput.java:580)
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput - at
>> org.eclipse.jetty.server.HttpInput$1.blockForContent(HttpInput.java:1139)
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput - at
>> org.eclipse.jetty.server.HttpInput.read(HttpInput.java:330)
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput - ...
>> 97 more
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput -
>> Suppressed: java.lang.Throwable: HttpInput failure
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput - at
>> org.eclipse.jetty.server.HttpInput.failed(HttpInput.java:871)
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput - at
>> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback.failed(HttpConnection.java:638)
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput - at
>> org.eclipse.jetty.server.HttpConnection.blockingReadFailure(HttpConnection.java:579)
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput - at
>> org.eclipse.jetty.server.HttpChannelOverHttp.onBlockWaitForContentFailure(HttpChannelOverHttp.java:265)
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput - at
>> org.eclipse.jetty.server.HttpInput.blockForContent(HttpInput.java:587)
>> 2021-01-27/15:09:58.871/UTC [qtp1253396693-94] ERROR consoleOutput - ...
>> 99 more
>>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Having issues with session instantiation from cookie by Jetty-9.4.34

[Jan Bartel]

Eze,

OK, I will close the issue I opened.

Other answers inline below.

regards
Jan


On Wed, 6 Jan 2021 at 02:58, Eze Ikonne  wrote:

> Hi Jan,
>
>
>
> Thanks for the prompt response, I believe that the reason why the session
> issue was happening was because of a logic in our Servlet
>
> filter that was invoking “addCookie” on HttpServletResponse object, it was
> causing duplicate copies of same cookie to appear in the response to
>
> the browser, hence the confusion when Jetty tries to instantiate the
> Session.
>
>
>
> We fixed that issue now, but we are now stuck on trying to set  
> “org.eclipse.jetty.servlet.SessionDomain”;
> how do we let Jetty know what value that
>
> it needs to set for “SessionDomain” within the Servlet context?
>

If you want to explicitly set the domain on the session cookies, you either
set the servlet context init param
"org.eclipse.jetty.servlet.SessionDomain" or you call
SessionHandler.getSessionCookieConfig().setDomain(String).


>
> Also, how do we let Jetty know to set  “Secure; HttpOnly” on Cookies for
> all responses back to the browser, right now when we set the following
> attributes in our embedded Jetty
>
>
>
> SessionHandler sh = wc.getSessionHandler();
>
> sh.getSessionCookieConfig().setHttpOnly(true);
>
> sh.getSessionCookieConfig().setSecure(true);
>
> sh.getSessionCookieConfig().setPath(null);
>

You don't have to call setPath(null), it is null by default. Your code
above ensures that "Secure; HttpOnly" will be set on all session cookies
generated by that context. If you want those set on all cookies that your
app creates, then you have to ensure that you set them in the cookie that
you pass into the HttpServletResponse.addCookie(Cookie) call.


> These attributes are only present in only a certain set of responses to
> the browser, this is what we were trying to
>
> achieve when we invoked the “addCookie” on the HttpServletResponse in our
> filter. Any hint will be appreciated.
>
>
>
> Thanks,
>
>
>
> Ike
>
>
>
>
>
> *From:* jetty-users-boun...@eclipse.org  *On
> Behalf Of *Jan Bartel
> *Sent:* Tuesday, January 5, 2021 4:02 AM
> *To:* JETTY user mailing list 
> *Subject:* Re: [jetty-users] Having issues with session instantiation
> from cookie by Jetty-9.4.34
>
>
>
> ** This mail has been sent from an external source **
>
>
>
> Hi Eze,
>
>
>
> I've opened an issue to track this while I investigate:
> https://github.com/eclipse/jetty.project/issues/5853
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_jetty.project_issues_5853=DwMFaQ=cxWN2QSDopt5SklNfbjIjg=9EhYabrbBNvJhLb9eW1k973v8ouhMLndFRJB8Bp9aFE=0O-4Jf47DcPg8f7IcJ5o7VcQr2FkxHwhoq94BHCV2e0=q1FxjB8S437dQVR6KDB2DT-Xk419sv-VM8o9J517s0w=>
>
>
>
> Can you reply to the issue and provide the info I've asked for?
>
>
>
> thanks
>
> Jan
>
>
>
> On Tue, 5 Jan 2021 at 04:28, Eze Ikonne  wrote:
>
> Hi all,
>
>
>
> I have the following sequence of request/response between my browser and
> embedded Jetty-9.4.34. I am not sure why
>
> this happening, but I hope that someone might give me an Insight as to
> what is happening here. Please see the Jetty Debug
>
> below.  Jetty is not able to instantiate the session from the cookie Any
> insight will be highly appreciated.
>
>
>
> Request from Browser to Jetty
>
>
>
> GET // xxx.xxx.xxx.xxx:18443/SSPDashboard/keepalive HTTP/1.1
>
> Host: xxx.xxx.xxx.xxx:18443
>
> Connection: keep-alive
>
> Upgrade-Insecure-Requests: 1
>
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
> (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36
>
> Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
>
> Sec-Fetch-Site: same-origin
>
> Sec-Fetch-Mode: navigate
>
> Sec-Fetch-Dest: iframe
>
> Referer: https://xxx.xxx.xxx.xxx:18443/SspJsf/faces/dispatcher.jsp
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__xxx.xxx.xxx.xxx-3A18443_SspJsf_faces_dispatcher.jsp=DwMFaQ=cxWN2QSDopt5SklNfbjIjg=9EhYabrbBNvJhLb9eW1k973v8ouhMLndFRJB8Bp9aFE=0O-4Jf47DcPg8f7IcJ5o7VcQr2FkxHwhoq94BHCV2e0=S7k9g5fsH7DVu1WsQVwpPDuPdw1ruawFR10mMOA0bG4=>
>
> Accept-Encoding: gzip, deflate, br
>
> Accept-Language: en-US,en;q=0.9
>
> Cookie:
> JSESSIONID=1jk28dc2s7prt9zqg0yrb2faq1kmn881t05szq1c46w93gr38nq.node0;
> JSESSIONID=10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4.node0
>
>
>
> Session Established from Cookie
> (1jk28dc2s7prt9zqg0yrb2faq1kmn881t05szq1c46w93gr38nq ) by Jetty
>
>
>
> 2020-12-23 17:46:31,

Re: [jetty-users] Having issues with session instantiation from cookie by Jetty-9.4.34

[Jan Bartel]

; Sec-Fetch-Mode: no-cors
>
> Sec-Fetch-Dest: style
>
> Referer: https:// xxx.xxx.xxx.xxx:18443/SSPDashboard/keepalive
>
> Accept-Encoding: gzip, deflate, br
>
> Accept-Language: en-US,en;q=0.9
>
> Cookie:
> JSESSIONID=10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4.node0;
> JSESSIONID=10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4.node0;
> JSESSIONID=10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4.node0
>
>
>
> Session could not be established by Jetty (Why?)
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Got Session ID
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4.node0 from cookie
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Session
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4 not found locally,
> attempting to load
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Got Session ID
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4.node0 from cookie
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Session
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4 not found locally,
> attempting to load
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Got Session ID
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4.node0 from cookie
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Session
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4 not found locally,
> attempting to load
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session -
> sessionHandler=org.eclipse.jetty.server.session.SessionHandler-1125304579==dftMaxIdleSec=1800
> session=null
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Got Session ID
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4.node0 from cookie
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Session
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4 not found locally,
> attempting to load
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Got Session ID
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4.node0 from cookie
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Session
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4 not found locally,
> attempting to load
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Got Session ID
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4.node0 from cookie
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session - Session
> 10lfyaco45qk1o5epecgjp53110asgk10ichef1gu1ozdqlaqd4 not found locally,
> attempting to load
>
> 2020-12-23 17:46:31,185 [qtp-272100020-19] DEBUG session -
> sessionHandler=org.eclipse.jetty.server.session.SessionHandler-1125304579==dftMaxIdleSec=1800
> session=null
>
>
> =
> Please refer to https://northamerica.altran.com/email-disclaimer
> for important disclosures regarding this electronic communication.
> =
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] HttpSession NULL issue with Browsers (Jetty-9.4.34)

[Jan Bartel]

If they're using Chrome or Mozilla you can guide them through using the
developer tools to look at the cookies cached, and even look at the http
request and response so they can see whether or not the cookie was sent.
Probably other browsers have some similar facility.

On the server side, you could try using Wireshark, but that might be a lot
of traffic.  Or you could use the CustomRequestLog to log the cookies that
you receive so you can see which clients aren't sending them when they
should.

Regards
Jan

On Thu, 24 Dec 2020, 23:02 Eze Ikonne,  wrote:

> Hi all,
>
> I have a scenario where, when our webapp is accessed by certain browsers,
> the session is null even though it has been initialized prior to been
> accessed as below
>
> HttpServletRequest request = (HttpServletRequest)req;
> HttpSession session = request.getSession(false);
>
> We are running embedded Jetty-9.4.34
>
> Is there a mechanism that I could instigate to determine that the browser
> is not sending back cookies hence this erratic behavior? I have not
> experienced this in
> our environment, but one customer is running into this issue. When the
> customer uses the Microsoft Edge browser, they are successful. Is there
> anything that I could
> use to determine why the other browsers are running into this issue? Any
> hints and suggestions would be appreciated.
>
> Thanks,
>
> Ike
>
> =
> Please refer to https://northamerica.altran.com/email-disclaimer
> for important disclosures regarding this electronic communication.
> =
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] java.lang.NoSuchFieldException: serverClasspathPattern

[Jan Bartel]

Hi David,

Have you tried using the static methods on WebAppContext:
addSystemClasses(Server server, String... patterns) and
addServerClasses(Server server, String... patterns)? I believe the method
signature is the same for jetty-9 and jetty-10/11.

cheers
Jan

On Tue, 8 Dec 2020 at 17:33, David Karlsen  wrote:

> I have this descriptor:
>
> 
>"-//Mort Bay Consulting//DTD Configure//EN"
>   "http://www.eclipse.org/jetty/configure.dtd;>
> 
>  /finods
>  true
>  
>   
>-org.eclipse.jetty.server.
>   
>   
>-org.eclipse.jetty.util.thread.
>   
>  
> 
>
> which works on 9.x, but on 10 I get:
>
> .e.j.w.WebAppContext@1d470d0
> {ccm-finodsping-dist-5.0.4-SNAPSHOT,/finods,file:///eos/d1/amw-virus-scan-ws/i1/tmp/jetty-0_0_0_0-20261-ccm-finodsping-dist-5_0_4-SNAPSHOT_war-_ccm-finodsping-dist-5_0_4-SNAPSHOT-any-2186630068394942064/webapp/,UNAVAILABLE}{/eos/d1/amw-virus-scan-ws/i1/releases/1.0.15-TEST/webapps/ccm-finodsping-dist-5.0.4-SNAPSHOT.war}
> java.lang.NoSuchFieldException: serverClasspathPattern
> at java.base/java.lang.Class.getField(Class.java:1999)
> at
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.get(XmlConfiguration.java:856)
> at
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:456)
> at
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:369)
> at
> org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:308)
> at
> org.eclipse.jetty.webapp.JettyWebXmlConfiguration.lambda$configure$0(JettyWebXmlConfiguration.java:86)
> at org.eclipse.jetty.webapp.WebAppClassLoader.runWithServerClassAcc
>
> It seems in 10.x this is replaced with a serverClassMatcher which is a
> ClassMatcher.
>
> Is there any way to write a descriptor so that it's compatible with jetty9
> and 10 at the same time?
> --
> --
> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] jetty-maven-plugin: minimal HTTPS example?

[Jan Bartel]

Jeroen,

Any improvements to the doco are always welcome :)  Please be aware that
the jetty-maven-plugin doco has been rewritten for jetty-10, so please
checkout the jetty-10.0.x branch and build that too and take a look at it -
any changes you make to the jetty-9 doco will need to be re-worked for
jetty-10.

cheers
Jan

On Mon, 24 Aug 2020 at 09:27, Jeroen Hoek  wrote:

> Hello Lachlan,
>
> Thank you very much! Your example gave me just the help I needed to find
> the problem in my code.
>
> The diff that makes my example work:
>
>
> https://github.com/LableOrg/jetty-maven-ssl/commit/d21f7e6b4cceac471db564a22e6c80b333265b4a
>
> I think what got me stuck was that the part about the sslContextFactory
> is missing from this page:
>
> https://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html
>
> Would a PR adding a bit about jetty-ssl-context.xml to the 'Configuring
> a Https Connector' heading be welcome?
>
> Kind regards,
>
> Jeroen
>
> On 21-08-2020 06:19, Lachlan Roberts wrote:
> > HI Jeroen,
> >
> > I have set up a basic project which works with HTTPS and with your
> > keystore. You can look at this to get some idea why yours isn't working.
> > https://github.com/lachlan-roberts/jetty-maven-plugin-https-example
> >
> > Cheers,
> > Lachlan
> >
> > On Thu, Aug 20, 2020 at 10:43 PM Jeroen Hoek  > <mailto:jeroen.h...@lable.nl>> wrote:
> >
> > Hello,
> >
> > I am trying to get the jetty-maven-plugin working with HTTPS, but am
> > running into an issue with the certificate not working.
> >
> > I've found a Maven archetype that sets up a minimal Maven project
> with
> > the plugin without HTTPS (this works), and have tried to switch from
> > HTTP to HTTPS by following the Jetty documentation. I'm not sure if
> I've
> > done everything right though.
> >
> > When I run `mvn jetty:run` the server starts on port 8443, but
> attempts
> > to connect fail:
> >
> > * In Firefox, I get:
> > Error code: SSL_ERROR_RX_RECORD_TOO_LONG
> > * With curl, I get:
> > error:1408F10B:SSL routines:ssl3_get_record:wrong version number
> >
> > Here is my minimal example:
> >
> > https://github.com/LableOrg/jetty-maven-ssl
> >
> > I used keytool (JDK 11) to generate this specific certificate, but
> have
> > tried to use an existing certificate that works with
> > tomcat7-maven-plugin as well. Both give the same errors.
> >
> > Could someone point me in the right direction? Or is there a minimal
> > Maven project example with working HTTPS I can examine?
> >
> > Kind regards,
> >
> > Jeroen Hoek
> > ___
> > jetty-users mailing list
> > jetty-users@eclipse.org <mailto:jetty-users@eclipse.org>
> > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/jetty-users
> >
> >
> > ___
> > jetty-users mailing list
> > jetty-users@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
> >
>
> --
> Vriendelijke groeten,
>
> Jeroen Hoek
>
> Lable
> ✉ jeroen.h...@lable.nl
> ℡ 088 44 20 202
> GPG-sleutel: 44D4 1D39 535A 1F9A 9509  92C5 A7A8 B913 D40D D022
>
> https://lable.nl — KvK № 55984037 — BTW № NL8519.32.411.B.01
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] (no subject)

[Jan Bartel]

="9.4.30",
>  org.eclipse.jetty.apache-jsp;bundle-version="9.4.30"
>
> ...and only the WAB bundle is set to auto-start.
>
> For completeness, the VM arguments to configure plugins are:
>
> -Djetty.home.bundle=jetty-config-bundle
> -Djava.naming.factory.url.pkgs=org.eclipse.jetty.jndi
> -Djava.naming.factory.initial=org.eclipse.jetty.jndi.InitialContextFactory
>
> And jetty-config-bundle does contain the jetty.xml, etc. files and they
> are being processed.
>
> Can anyone tell me if they've got this working, and how? Is it
> configurable to just work without needing a jetty-web.xml in each WAB, or
> am I missing a dependency bundle on my plugin?
>
> Thanks in advance,
>
> Gordon Jahn
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] WAR reloading leaves stale file descriptors (file system quota not working as expected)

[Jan Bartel]

mp/jetty-0_0_0_0-8443-root_war-_-any-1577458225866104653.dir/webapp/WEB-INF/lib/stats_collector_2.13-0.1.0-SNAPSHOT.jar
>> (deleted)
>> java  39467 sclient   76r  REG8,1
>>187761  101365270
>> /home/client/tmp/jetty-0_0_0_0-8443-root_war-_-any-1577458225866104653.dir/webapp/WEB-INF/lib/ujson_2.13-1.1.0.jar
>> (deleted)
>> java  39467 sclient   77r  REG8,1
>>114284  101365269
>> /home/client/tmp/jetty-0_0_0_0-8443-root_war-_-any-1577458225866104653.dir/webapp/WEB-INF/lib/upickle-core_2.13-1.1.0.jar
>> (deleted)
>> java  39467 sclient   94r  REG8,1
>> 694091220495
>> /home/client/tmp/jetty-0_0_0_0-8443-root_war-_-any-17785782056536538882.dir/webapp/WEB-INF/lib/activation-1.1.1.jar
>> (deleted)
>> java  39467 sclient   95r  REG8,1
>>2678271352165
>> /home/client/tmp/jetty-0_0_0_0-8443-root_war-_-any-17785782056536538882.dir/webapp/WEB-INF/lib/admin_2.13.jar
>> (deleted)
>> java  39467 sclient   96r  REG8,1
>>4998441352184
>> /home/client/tmp/jetty-0_0_0_0-8443-root_war-_-any-17785782056536538882.dir/webapp/WEB-INF/lib/c3p0-0.9.5.4.jar
>> (deleted)
>> java  39467 sclient   97r  REG8,1
>>2469181352170
>> /home/client/tmp/jetty-0_0_0_0-8443-root_war-_-any-17785782056536538882.dir/webapp/WEB-INF/lib/commons-beanutils-1.9.4.jar
>> (deleted)
>> java  39467 sclient   98r  REG8,1
>>3476691352166
>> /home/client/tmp/jetty-0_0_0_0-8443-root_war-_-any-17785782056536538882.dir/webapp/WEB-INF/lib/commons-codec-1.14.jar
>> (deleted)
>> java  39467 sclient   99r  REG8,1
>>5883371352180
>> /home/client/tmp/jetty-0_0_0_0-8443-root_war-_-any-17785782056536538882.dir/webapp/WEB-INF/lib/commons-collections-3.2.2.jar
>> (deleted)
>> java  39467 sclient  100r  REG8,1
>>208475 957623
>> /home/client/tmp/jetty-0_0_0_0-8443-root_war-_-any-17785782056536538882.dir/webapp/WEB-INF/lib/commons-dbcp2-2.7.0.jar
>> (deleted)
>> java  39467 sclient  101r  REG8,1
>>1461081352186
>> /home/client/tmp/jetty-0_0_0_0-8443-root_war-_-any-17785782056536538882.dir/webapp/WEB-INF/lib/commons-digester-1.8.1.jar
>> (deleted)
>> java  39467 sclient  102r  REG8,1
>>2147881212954
>> /home/client/tmp/jetty-0_0_0_0-8443-root_war-_-any-17785782056536538882.dir/webapp/WEB-INF/lib/commons-io-2.6.jar
>> (deleted)
>> ...
>>
>> The file system tools(du) correctly report used disk space but file
>> system quota is not seeing space being released after each update of
>> deployed WAR file (used space grows). After I restart jetty file system
>> quota is updated correctly. It's only JAR files from what I can tell so
>> could it be related to the class loader in some way?
>>
>> FS is xfs on centos8 with pquota (project quota)
>>
>> I am using latest release 9.4.30.v20200611
>>
>> Regards
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Sessions are not invalidated at shutdown any longer

[Jan Bartel]

Dirk,

I think you're spot on here: I do remember changing my mind about whether a
session data store could be null or not. I've raised an issue for that:
https://github.com/eclipse/jetty.project/issues/4920

Cheers
Jan

On Thu, 28 May 2020, 12:36 Dirk Olmes,  wrote:

> On 5/28/20 11:08 AM, Jan Bartel wrote:
> > Sounds like you need the NullSessionDataStore:
> >
> https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/java/org/eclipse/jetty/server/session/NullSessionDataStore.java
>
> ... whis is active by default, yes.
>
> But then in DefaultSessionCache's shutdown method the _sessionDataStore
> is not null and the else branch will not be executed, i.e. the sessions
> will not be invalidated as they are "stored" by the NullSessionDataStore.
>
> IMHO the code is inconsistent here: some parts of AbstractSessionCache
> assume that there is a _sessionDataStore (e.g. doStop(), commit(Session)
> etc.) and some parts are safely guarded with null checks.
> DefaultSessionCache suggests that it's OK to have no _sessionDataStore ...
>
> I imagine I could hack together a subclass of DefaultSessionCache, grab
> the sessions and invalidate them manually but I think a proper fix in
> the Jetty codebase would be better.
>
> -dirk
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Sessions are not invalidated at shutdown any longer

[Jan Bartel]

Sounds like you need the NullSessionDataStore:
https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/java/org/eclipse/jetty/server/session/NullSessionDataStore.java

Jan

On Thu, 28 May 2020 at 08:17, Dirk Olmes  wrote:

> Hi,
>
> I'm using an embedded Jetty for our web application. A long time ago we
> have tied our usage checks to http sessions. This makes use of the fact
> that all sessions are properly invalidated when the server shuts down.
>
> I have revisited this topic again now and I'm seeing that the http
> sessions are no longer invalidated when the server shuts down. Digging
> into DefaultSessionCache's shutdown method I see that to get proper
> session invalidation I should not use a SessionDataStore
> (
> https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/java/org/eclipse/jetty/server/session/DefaultSessionCache.java#L143
> ).
>
> At the same time it seems I cannot go without a SessionDataStore as
> AbstractSessionCache's doStart method insists on using one
> (
> https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/java/org/eclipse/jetty/server/session/AbstractSessionCache.java#L203
> ).
>
> Is this inconsistency expected? How would I code my way around it?
>
> -dirk
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Setting Content-Type: text/html; charset=utf-8 for all html files

[Jan Bartel]

Alexander,

Jetty's default mime.properties file does not have a charset specified for
text/html.

You can add one in your slova.de.xml file by doing the equivalent of the
following in xml:

getMimeTypes().addMimeMapping("html", "utf-8")

The getMimeTypes() is a method inherited by the ServletContextHandler.

regards
Jan

On Sat, 11 Apr 2020 at 17:58, Alexander Farber 
wrote:

> Good evening,
>
> on my CentOS 7 server I run Jetty by:
>
> # /usr/bin/java -Djdbc.drivers=org.postgresql.Driver -jar
> /usr/share/java/jetty-distribution-9.4.27.v20200227/start.jar
> jetty.home=/usr/share/java/jetty-distribution-9.4.27.v20200227
> jetty.base=/var/www/jetty-base-ru jetty.http.host=127.0.0.1
> jetty.http.port=8080
>
> Also I serve PHP files through FastCGI as suggested at
> https://www.eclipse.org/jetty/documentation/9.4.28.v20200408/configuring-fastcgi.html
>
> My XML config file is listed at the very bottom of this mail.
>
> However I have a problem: when I create a static HTML file in UTF-8
> encoding, with no BOM, Russian language - it is misinterpreted by browsers
> and they do not display Russian letters. When I rename the file. from .html
> to .php then it works - because the following HTTP header is suddenly added:
>
> Content-Type: text/html;charset=utf-8
>
> Is there please a way to configure Jetty through the XML file below to
> send the header for all HTML files?
>
> I have searched Stackoverflow and the question seems to be complicated
> because of the servlet spec.
>
> I would prefer finding an XML option, because it would suit my deployment
> and Jetty-upgrades procedure best (i.e. no editing the files distributed
> with new Jetty versions, but better just configuring it once in
> $JETTY_BASE/webapps)
>
> Thank you and happy Easter :-)
> Alex
>
> PS: below is my  /var/www/jetty-base-ru/webapps/slova.de.xml, how to add
> the header there?
>
> ?xml version="1.0" encoding="UTF-8"?>
>  "http://www.eclipse.org/jetty/configure_9_3.dtd;>
> 
>
> 
> /var/www/html/slova.de
> 
>
> /
> 
>
> 
> 
> slova.de
> www.slova.de
> 
> 
>
> 
> 
> index.php
> index.html
> 
> 
>
> 
> org.eclipse.jetty.fcgi.server.proxy.TryFilesFilter
> /*
> 
> 
>  class="javax.servlet.DispatcherType" />
> 
> 
> 
> files
> $path /index.php?p=$path
> 
> 
>
> 
> 
> 
> default
> 
> 
> org.eclipse.jetty.servlet.DefaultServlet
> 
> 
> 
> dirAllowed
> false
> 
> 
> gzip
> true
> 
> 
> 
> /
> 
>
> 
> org.eclipse.jetty.fcgi.server.proxy.FastCGIProxyServlet
> *.php
> 
> proxyTo
> http://localhost:9000
> 
> 
> prefix
> /
> 
> 
> scriptRoot
> 
> 
> 
> scriptPattern
> (.+?\\.php)
> 
> 
>
> 
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Cross Context communication between WebApps without HTTP overhead

[Jan Bartel]

Have a look at the ServletContext.getContext and
ServletContext.getRequestDispatcher methods and read up in the spec on
request forwarding and including which happens only on the server side.

Jan

On Fri, 6 Mar 2020 at 07:33, Manpreet Singh  wrote:

> Hi,
>
>
>
> What would be the best way in Jetty to have 2 web applications communicate
> with each other without using HTTP calls?
>
>
>
> Thanks,
>
> Manpreet
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Does Jetty Uses Session to Set the Principal in HTTP Request

[Jan Bartel]

If you use BASIC authentication, every single request must contain the
realm, username and password and is authenticated on reception - there is
no concept of a session maintaining state.

The form login page can be generated by a servlet, it doesn't have to be a
static html resource.

Jan

On Tue, 18 Feb 2020 at 20:34, Wang Yicheng 
wrote:

> Thanks Jan! The thing is, my project actually doesn't have any pages. So,
> is it possible to have FORM authentication without login pages? Or does it
> mean I should go with BASIC while create sessions myself?
>
> On Mon, Feb 17, 2020 at 2:16 AM Jan Bartel  wrote:
>
>> You need to set up what the authentication method is, ie the equivalent
>> of the  in web.xml. The default
>> is basic authentication. If you want to use sessions to maintain the
>> authentication state, then configure FORM authentication, either in web.xml
>> or by setting an instance of
>> https://www.eclipse.org/jetty/javadoc/9.4.26.v20200117/org/eclipse/jetty/security/authentication/FormAuthenticator.html
>> on the SecurityHandler.
>>
>> Jan
>>
>> On Mon, 10 Feb 2020 at 23:12, Wang Yicheng 
>> wrote:
>>
>>> Thanks Joakim!
>>>
>>> Yes I do have a customized login module following JAAS spec. So it seems
>>> the missing session is causing the problem. Then my question is: With
>>> default configuration, does Jetty generate session automatically for
>>> authenticated user? Or is my code responsible for doing that?
>>>
>>> I actually published another question here
>>> <http://jetty.4.x6.nabble.com/HttpServletRequest-Returns-NULL-Principal-After-Logging-In-td4968503.html>
>>> which contains more details about my issue. Any help is highly appreciated!
>>>
>>> Best
>>>
>>> On Mon, Feb 10, 2020 at 1:11 PM Joakim Erdfelt 
>>> wrote:
>>>
>>>> If using Servlet authentication (or JAAS) the principal would be set.
>>>>
>>>> If you are using a 3rd party web library (like spring) then odds are
>>>> you are not integrating with Servlet security.
>>>>
>>>> Joakim Erdfelt / joa...@webtide.com
>>>>
>>>>
>>>> On Mon, Feb 10, 2020 at 2:05 PM Yicheng Wang 
>>>> wrote:
>>>>
>>>>> Hi team,
>>>>>
>>>>> My question is as the subject state. My issue is the login request
>>>>> does have
>>>>> the principal by calling getUserPrincipal. But after logging in, the
>>>>> second
>>>>> request has a null principal. Besides, neither of the requests have
>>>>> sessions. So I'm wondering if Jetty uses session information to set the
>>>>> principal in HTTP request. Do appreciate your help!
>>>>>
>>>>> Best
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sent from: http://jetty.4.x6.nabble.com/Jetty-User-f3247280.html
>>>>> ___
>>>>> jetty-users mailing list
>>>>> jetty-users@eclipse.org
>>>>> To change your delivery options, retrieve your password, or
>>>>> unsubscribe from this list, visit
>>>>> https://www.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://www.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://www.eclipse.org/mailman/listinfo/jetty-users
>>
>>
>>
>> --
>> Jan Bartel 
>> www.webtide.com
>> *Expert assistance from the creators of Jetty and CometD*
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.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://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Does Jetty Uses Session to Set the Principal in HTTP Request

[Jan Bartel]

You need to set up what the authentication method is, ie the equivalent of
the  in web.xml. The default is
basic authentication. If you want to use sessions to maintain the
authentication state, then configure FORM authentication, either in web.xml
or by setting an instance of
https://www.eclipse.org/jetty/javadoc/9.4.26.v20200117/org/eclipse/jetty/security/authentication/FormAuthenticator.html
on the SecurityHandler.

Jan

On Mon, 10 Feb 2020 at 23:12, Wang Yicheng 
wrote:

> Thanks Joakim!
>
> Yes I do have a customized login module following JAAS spec. So it seems
> the missing session is causing the problem. Then my question is: With
> default configuration, does Jetty generate session automatically for
> authenticated user? Or is my code responsible for doing that?
>
> I actually published another question here
> <http://jetty.4.x6.nabble.com/HttpServletRequest-Returns-NULL-Principal-After-Logging-In-td4968503.html>
> which contains more details about my issue. Any help is highly appreciated!
>
> Best
>
> On Mon, Feb 10, 2020 at 1:11 PM Joakim Erdfelt  wrote:
>
>> If using Servlet authentication (or JAAS) the principal would be set.
>>
>> If you are using a 3rd party web library (like spring) then odds are you
>> are not integrating with Servlet security.
>>
>> Joakim Erdfelt / joa...@webtide.com
>>
>>
>> On Mon, Feb 10, 2020 at 2:05 PM Yicheng Wang 
>> wrote:
>>
>>> Hi team,
>>>
>>> My question is as the subject state. My issue is the login request does
>>> have
>>> the principal by calling getUserPrincipal. But after logging in, the
>>> second
>>> request has a null principal. Besides, neither of the requests have
>>> sessions. So I'm wondering if Jetty uses session information to set the
>>> principal in HTTP request. Do appreciate your help!
>>>
>>> Best
>>>
>>>
>>>
>>> --
>>> Sent from: http://jetty.4.x6.nabble.com/Jetty-User-f3247280.html
>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://www.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://www.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://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] HttpServletRequest Returns NULL Principal After Logging In

[Jan Bartel]

Have a read of the doc on the JAAS module in jetty here:
https://www.eclipse.org/jetty/documentation/9.4.26.v20200117/jaas-support.html#_writing_your_own_loginmodule

Javadoc is here:
https://www.eclipse.org/jetty/javadoc/9.4.26.v20200117/org/eclipse/jetty/jaas/spi/package-summary.html

Jan

On Thu, 6 Feb 2020 at 06:18, Yicheng Wang  wrote:

> I’m sorry I didn’t find a detailed documentation of getUserInfo function
> and thus I’m not quite familiar with it. So given the username, getUserInfo
> should return the password wrapped in UserInfo class. And then login
> function would use that information to compare with the input password,
> which has already been handled with the current code. Am I getting it right?
>
>
> On Feb 5, 2020, at 20:29, Olivier Lamy  wrote:
>
> Hi
> You do not need to override login. The class has been designed to only
> need overwrite getUserInfo.
> if getUserInfo returns null it means you cannot login with this username.
> Otherwise you need to look at how login method is implemented in
> AbstractLoginModule and this can change in the future.
>
> On Thu, Feb 6, 2020 at 1:43 PM Yicheng Wang 
> wrote:
>
>> Hi Olivier,
>>
>> Thanks for your timely reply. Just to confirm, are you suggesting to have
>> the login module extend AbstractLoginModule and override getUserInfo only?
>> In my case, the login module relies on another class to do the
>> authentication, so I have to override login as well. If in this case, shall
>> I maintain other fields of AbstractLoginModule (like currentUser)
>> manually in login function?
>>
>> Best,
>> Yicheng
>>
>> On Feb 5, 2020, at 19:26, Olivier Lamy  wrote:
>>
>> Hi
>> Can you try with a simple subclass of AbstractLoginModule?
>> This should work.
>>
>>
>> On Thu, Feb 6, 2020 at 11:51 AM Yicheng Wang 
>> wrote:
>>
>>> Hi Team,
>>>
>>> First of all, thank you for developing Jetty. I'm working on a project to
>>> replace WebLogic with Jetty, and I've been stuck with authentication for
>>> quite a while.
>>>
>>> The previous project implements the JAAS interface and stores all user
>>> information with self-maintained files, instead of using realm. I tried
>>> to
>>> implement the login module with the same code. And I followed the
>>> official
>>> document to set the configuration, but without realm. The login part
>>> works
>>> fine. But after logging in, no matter what request I send to Jetty,
>>> principal is always null and thus the user is deemed as unauthenticated
>>> and
>>> is logged out. While for the login request, I do get the principal from
>>> the
>>> request.
>>>
>>> I have no idea about the root cause. Some of my guesses are as below.
>>> 1. I read the source code of AbstractLoginModule class, and there're a
>>> bunch
>>> of fields like currentUser etc. I guess I shouldn't implement LoginModule
>>> directly, as this breaks the inner mechanism of how Jetty integrates
>>> customized login module.
>>> 2. I'm missing some critical configurations of HTTP requests.
>>> 3. I also notice session is not working properly at this point. Does
>>> session
>>> have anything to do with null principal in the request?
>>>
>>> Do appreciate your kind help!
>>>
>>> Yicheng
>>>
>>>
>>>
>>> --
>>> Sent from: http://jetty.4.x6.nabble.com/Jetty-User-f3247280.html
>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>
>>
>>
>> --
>> Olivier
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.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://www.eclipse.org/mailman/listinfo/jetty-users
>
>
>
> --
> Olivier
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Communication between a Servlet and a custom protocol

[Jan Bartel]

Josh,

In your etc/test.xml file, set the shared resource as an attribute on the
Server:


myserverfoo
HELLO



In your webapps/servlet.xml, you can refer to the Server instance and
retrieve the attribute, and set it as a context attribute instead:

  
  myserverfoo
  

  
   mycontextfoo
   
  


regards
Jan

On Mon, 27 Jan 2020 at 22:40, Josh Spiegel  wrote:

> Simone,
>
> Thanks again.  Bug it seems the webapp configuration can't reference ids
> set by the server module.  Am I missing something?  Here is what I tried:
>
> *./webapps/servlet.xml*
>
>
> 
>
>
>   /ServletExample
>
>
>   /Users//ServletExample.war
>
>
>   
>
>
>
> # SERVLET ##
>
>
>
>   
>
>
>   
>
>
>
> 
>
>
>
>   
>
>
> 
>
> *./modules/test.mod*
>
> [xml]
>
> etc/test.xml
>
> *./etc/test.xml*
>
>
> 
>
>
>   
>
> 
>
>   test
>
>   foo
>
> 
>
>   
>
>
>   
>
>
>
> # test.xml ##
>
>
>
>   
>
>
>   
>
>
>
> 
>
>
>
>   
>
>
> 
>
>
> > java -jar start.jar --add-module=test
>
> 2020-01-27 13:38:20.070:INFO::main: Logging initialized @467ms to
> org.eclipse.jetty.util.log.StdErrLog
>
> # test.xml ##
>
> {test=foo}
>
> 2020-01-27 13:38:20.286:INFO:oejs.Server:main: jetty-9.4.26.v20200117;
> built: 2020-01-17T12:35:33.676Z; git:
> 7b38981d25d14afb4a12ff1f2596756144edf695; jvm 1.8.0_201-b09
>
> 2020-01-27 13:38:20.301:INFO:oejdp.ScanningAppProvider:main: Deployment
> monitor [file:///Users//jetty-distribution-9.4.26.v20200117/webapps/]
> at interval 1
>
> # SERVLET ##
>
> null
>
> Notice the servlet.xml reference to "myContext" prints null.
>
> Thanks,
> Josh
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jan 27, 2020 at 7:24 AM Simone Bordet  wrote:
>
>> Hi,
>>
>> On Mon, Jan 27, 2020 at 3:58 PM Josh Spiegel 
>> wrote:
>> >
>> > Thanks.  I can definitely break things up and use a module.  However,
>> using webapps and configuring WebAppContext via mywar.xml doesn't seem to
>> work since the call to webAppContext.getServer() returns null at the time
>> the WebAppContext is configured.
>>
>>  will allow you to obtain the map by using > refid="myContext"/> so you don't need the Server anymore.
>>
>> --
>> Simone Bordet
>> 
>> http://cometd.org
>> http://webtide.com
>> Developer advice, training, services and support
>> from the Jetty & CometD experts.
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.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://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Access to HttpRequest in Custom Login Module (JAAS)

[Jan Bartel]

One of the 2 custom callbacks provided by jetty will do the trick.
Documentation is here:
https://www.eclipse.org/jetty/documentation/9.4.26.v20200117/jaas-support.html#_other_goodies

Jan

On Thu, 30 Jan 2020 at 05:57, Mohan Kishore  wrote:

> Hi,
>
> For my web application using  Jetty 9.4.x. We have a JAAS Custom
> LoginModule which extended by using AbstractLoginModule. I would like to
> use HttpRequest object inside my custom LoginModule. Could you please let
> me know how to get HttpRequest in my custom LoginModule in Jetty 9.4? Can
> we add additional HttpRequest parameters?
>
> Thank you for your support.
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Redis session management cause jetty-runner to fail on startup

[Jan Bartel]

e.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:100)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:407)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:100)
> at org.eclipse.jetty.server.Server.doStart(Server.java:371)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at org.eclipse.jetty.runner.Runner.run(Runner.java:520)
> at org.eclipse.jetty.runner.Runner.main(Runner.java:565)
> 2020-01-03 16:27:56.656:INFO:oejs.RequestLogWriter:main: Opened
> /Users/johnruggentaler/logs/2020_01_03-requests.log
> 2020-01-03 16:27:56.671:INFO:oejs.AbstractConnector:main: Started
> ServerConnector@6fdb1f78{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
> 2020-01-03 16:27:56.672:INFO:oejs.Server:main: Started @20115ms
> 2020-01-03 16:38:56.532:DBUG:oejs.session:Session-HouseKeeper-4135c3b-1:
> node0 scavenging sessions
>
> OS version: Mac OS Catalina 10.15.2
> jetty-runner version: 9.4.25.v20191220
> Java version: 1.8.0_232
>
> Here is my context.xml
> 
>  http://www.eclipse.org/jetty/configure.dtd;>
>
> 
>
>   /
>   current.war
>
>   
> 
>   false
> 
>   
>
>   
> 
>   
> 
> 
> class="org.eclipse.jetty.redis.session.RedisSessionDataMap">
> localhost
> 6379
> 0
> 0
> session:
>
> 
>   
> 
>   
>
> 
>
> I downloaded jetty-redis-sessions and modified RedisSessionDataMap see
> attachment. I built the jetty-redis-sessions jar and included it in my lib
> directory. In the constructor I logged the Host and port to verify the
> constructor is called,...
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] jrxml loaing issue from classpath.

[Jan Bartel]

In that case, you should use:

InputStream is =
request.getServletContext().getResourceAsStream("/jrxml/ABC.jrxml");

Works portably on all servlet containers.

Jan

On Tue, 10 Dec 2019 at 17:13, kapil gupta  wrote:

> Jan,
>
> Thanks for the reply.
> The ClassLoader.getResource() works fine when the resources are within
> src/main/resources package. But my jrxml is in parallel to WEB-INF package.
> So it works fine with below structure:
>
>- WEB-INF
>   - classes
>  - jrxml
> - ABC.jrxml
>
>
> But my hierarchy is different, it is in parallel to WEB-INF like below:
>
>- WEB-INF
>   - classes
>- jrxml
>   - ABC.jrxml
>
>
> On Tue, Dec 10, 2019 at 11:32 AM Jan Bartel  wrote:
>
>> Kapil,
>>
>> That's not a very portable way of finding the resource.
>>
>> I have no idea what the classloader for tomcat is, but the URLClassLoader
>> (a subclass of which is the classloader for the webapp in jetty)  will load
>> the path of the resource sought by adding it to its urls in turn.
>> For example:
>> If I have:
>>  /home/janb/tmp/xxx
>>   /jrx
>> foo.blah
>> and
>>
>> URLClassLoader l = new URLClassLoader(new URL[]{new
>> URL("file:///home/janb/tmp/xxx/")},Thread.currentThread().getContextClassLoader());
>> URL u = l.getResource("../../jrx/foo.blah");
>>
>> The URLClassLoader concatenates to result in
>> "file:/home/janb/tmp/xxx/../../jrx/foo.blah", and this file does not exist.
>>
>> If you use instead ClassLoader.getResource("jrx/foo.blah") the
>> URLClassLoader can find it. The java bootloader can find it too, if you run
>> the above lines at the command line, and I would assume that tomcat's
>> loader would find it as well.
>>
>> Jan
>>
>>
>>
>> On Tue, 10 Dec 2019 at 16:26, kapil gupta  wrote:
>>
>>> Depicting the structure in better way:
>>>
>>>- WEB-INF
>>>   - classes
>>>- jrxml
>>>   - ABC.jrxml
>>>
>>> So WEB-INF and jrxml packages are at same level.
>>>
>>> On Tue, Dec 10, 2019 at 9:57 AM kapil gupta 
>>> wrote:
>>>
>>>> Hi,
>>>> I am facing issue where I am trying to load jrxml files from classpath,
>>>> it is working fine in Tomcat server but same code not working on jetty.
>>>>
>>>> War structure
>>>>   - WEB-INF
>>>> - classes
>>>>   - jrxml
>>>> - ABC.jrxml
>>>>
>>>>
>>>> I am trying to load file via below code:
>>>>
>>>> Thread.currentThread().getContextClassLoader().getResourceAsStream("../../jrxml/ABC.jrxml);
>>>>
>>>> Please let me know how can I solve this problem.
>>>>
>>>> Thanks & Regards
>>>> Kapil
>>>>
>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
>>
>>
>> --
>> Jan Bartel 
>> www.webtide.com
>> *Expert assistance from the creators of Jetty and CometD*
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.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://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] jrxml loaing issue from classpath.

[Jan Bartel]

Kapil,

That's not a very portable way of finding the resource.

I have no idea what the classloader for tomcat is, but the URLClassLoader
(a subclass of which is the classloader for the webapp in jetty)  will load
the path of the resource sought by adding it to its urls in turn.
For example:
If I have:
 /home/janb/tmp/xxx
  /jrx
foo.blah
and

URLClassLoader l = new URLClassLoader(new URL[]{new
URL("file:///home/janb/tmp/xxx/")},Thread.currentThread().getContextClassLoader());
URL u = l.getResource("../../jrx/foo.blah");

The URLClassLoader concatenates to result in
"file:/home/janb/tmp/xxx/../../jrx/foo.blah", and this file does not exist.

If you use instead ClassLoader.getResource("jrx/foo.blah") the
URLClassLoader can find it. The java bootloader can find it too, if you run
the above lines at the command line, and I would assume that tomcat's
loader would find it as well.

Jan



On Tue, 10 Dec 2019 at 16:26, kapil gupta  wrote:

> Depicting the structure in better way:
>
>- WEB-INF
>   - classes
>- jrxml
>   - ABC.jrxml
>
> So WEB-INF and jrxml packages are at same level.
>
> On Tue, Dec 10, 2019 at 9:57 AM kapil gupta 
> wrote:
>
>> Hi,
>> I am facing issue where I am trying to load jrxml files from classpath,
>> it is working fine in Tomcat server but same code not working on jetty.
>>
>> War structure
>>   - WEB-INF
>> - classes
>>   - jrxml
>> - ABC.jrxml
>>
>>
>> I am trying to load file via below code:
>>
>> Thread.currentThread().getContextClassLoader().getResourceAsStream("../../jrxml/ABC.jrxml);
>>
>> Please let me know how can I solve this problem.
>>
>> Thanks & Regards
>> Kapil
>>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Necessity of workerName as part of DefaultSessionIdManager

[Jan Bartel]

Reilly,

The workername should uniquely identify a server instance.  This is used a)
to prepend to session id to ensure uniqueness  and b) by some of the
SessionDataStore flavours to reason about which node was last managing a
session when considering whether a session should be regarded as expired or
not.  For an example of the latter case, see the
InfinispanSessionDataStore. I thought the JDBCSessionDataStore did as well,
but can't remember the details now.

regards
Jan

On Thu, 29 Aug 2019 at 10:23, Reilly Brogan  wrote:

> We're working on switching our application from external Tomcat to
> embedded Jetty and one of the things that we've noticed is different is
> that the SessionId worker name is prepended to all session IDs (we do have
> multiple application servers accessing the sessions and the docs said we
> needed to set the workerName).
>
> We'd prefer to avoid this if possible as we log the session ID to several
> database tables that currently have a length limit that would need to be
> extended for the new format. Looking at the code it looks like the purpose
> of this is to try to ensure that there are no ID collisions if there are
> multiple application servers, but assuming you are using SecureRandom on
> hosts with sufficient hardware-provided entropy is that really a real risk?
>
> Are there any other reasons that workerName would need to be globally
> unique that I'm not seeing?
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Reference environment variables in jetty descriptors?

[Jan Bartel]

Looks like an omission in our documentation on the reference guide to our
xml syntax. I raised https://github.com/eclipse/jetty.project/issues/3914.

thanks
Jan

On Tue, 30 Jul 2019 at 14:31, Olivier Lamy  wrote:

> Hi
> have you tried something such .?
>
>
> On Tue, Jul 30, 2019 at 9:15 AM David Karlsen 
> wrote:
>
>> Is it possible to refer environment variables in jetty descriptors?
>> I am trying to avoid hardcoding proxy values in
>> jetty-websocket-httpclient.xml:
>>
>> 
>> > "http://www.eclipse.org/jetty/configure.dtd;>
>>
>> 
>>   
>> 
>>   
>>   
>> 
>>   
>> 
>>   
>> HERE
>> HERE
>>   
>> 
>>   
>> 
>>   
>> 
>>
>>
>> --
>> --
>> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>
>
>
> --
> Olivier
> _______
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] web app specific port in single jetty instance

[Jan Bartel]

Have you seen the documentation on this at
https://www.eclipse.org/jetty/documentation/9.4.19.v20190610/serving-webapp-from-particular-port.html
 ?

Jan

On Mon, 29 Jul 2019 at 18:14, deepak dhandapani 
wrote:

> Jetty version i'm running is jetty-distribution-9.4.9.v20180320
>
> On Mon, Jul 29, 2019 at 1:42 PM deepak dhandapani 
> wrote:
>
>> Hi There,
>>
>> I'm looking to configure unique port for each web application i'm running
>> in a single jetty server instance.
>>
>> For example, I have two webapps A and B, I want to make the webapp A
>> should listen to port  only and webapp B should listen to port 
>> only.
>>
>> Could someone guide me how to do this?
>>
>> Thanks in advance!
>>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] javax.mail in webapp

[Jan Bartel]

Assuming you are using jetty via the distribution, the better thing to do
is to make your own module that uses the javax.mail of your choice. Take a
look at this issue: https://github.com/eclipse/jetty.project/issues/2960,
particularly links to other issues where I describe how to make and use
your own module.

You are correct that the change you have made, as it was in the webapps
context xml file will not affect other applications.

Jan

On Mon, 29 Jul 2019 at 14:20, kapil gupta  wrote:

> Hi,
>
> We are using jetty-9.4.14 which internally
> use javax.mail.glassfish-1.4.1.v201005082020. Now we are using updated
> version of javax.mail in our application and which was not being picked up.
> So we made changes in application's context.xml as below:
>
> 
> -javax.mail.
> 
> 
> javax.mail.
> 
>
> This works fine, but I have one question. We have around 10 applications
> and made this change only for one application, so this should not have an
> impact on other applications? Is this the correct approach to the problem?
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] File locking when Jetty service is up(Need to lock the Web ARchieve preventing the file from tampering when the Jetty service is up and running)

[Jan Bartel]

You haven't provided a recognisable jetty version, can you double check
what you're using?

You don't have to use the webapp deployer to deploy your webapp if you
don't want to. The one we provide will periodically scan for changed files,
however you could write your own that just deploys once. Take a look in the
jetty-deploy maven src module, should be pretty easy.

You might be able to fudge it by setting the scanInterval to 0 on the
current deployer in the ini file or in the jetty-deploy.xml file, but I've
never tried that so can't guarantee it works.

Other option is you can just write a small xml file that directly deploys
your webapp.

You should also be using operating system privileges to protect who can
interact with the jetty instance, do things like copying or modifying
files, starting or stopping jetty.



On Tue., 16 Jul. 2019, 07:44 deepak dhandapani, 
wrote:

> Hi There,
>
> I'm currently working with the Gradle project which is used to design an
> web services to deploy in the Jetty web server in the location "*C:\Program
> Files\jetty\mt-base\webapps*" as .WAR file. When I run the Jetty
> services, my services working fine as expected but what worrying me is,
> Jetty allowing the WAR file for modification even when Jetty is running and
> thus reloading the services to have effect on the server response for the
> client request.
>
> This allows for malicious tampering of the WAR file and we are looking to
> protect this from happening.
>
> My question is, *Is there any Jetty configuration to lock the web
> application file while the service is up and running (I.E., lock all files
> inside "C:\Program Files\jetty\mt-base\webapps" folder)? If Yes, could you
> let me know how to setup the configurations for me, please?*
>
> However, I do see a facility *'useFileMappedBuffer'* property in the link
> https://wiki.eclipse.org/Jetty/Reference/webdefault.xml for
> memory-mapping of files for the Jetty services. I'm currently trying this
> to see if I can achieve my need. Could you elaborate the statement "*Jetty
> buffers static content for webapps such as HTML files, CSS files, images,
> etc. If you are using NIO connectors, Jetty uses memory-mapped files to do
> this.*" in the link
> https://wiki.eclipse.org/Jetty/Reference/webdefault.xml? What does NIO
> connectors mean? How to implement in my Jetty?
>
> Current Jetty I'm using is *Jetty (x64) 1.4.0.56668 *
> OS - Windows 10 Enterprise
>
> Thanks in advance!
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Jetty 9.4.15 and JSP issue

[Jan Bartel]

;org.eclipse.jdt.", // hide jdt used by jetty
"org.eclipse.jetty."// hide other jetty classes

There is also something else wrong with the setup for your contexts, as you
can see by the logs that for the contexts /service and /, that jetty tries
to load the JettyJspServlet, fails and replaces it with the NoJspServlet:

NO JSP Support for /service, did not find
org.eclipse.jetty.jsp.JettyJspServlet
NO JSP Support for /, did not find org.eclipse.jetty.jsp.JettyJspServlet

However, for the /zAdmin context, we don't see the failure to load the
JettyJspServlet early in deployment, it only fails to load it when the
ServletHandler is being started.  I assume this failure is due to your
incorrect system and server classes setup, however this should also fail
for the / and /service contexts. The fact that it doesn't means there is
something else wrong with your setup.

As for the /zimlet context, this appears to be differently deployed than
the rest - I see it is an auto-managed bean of the
ContextHandlerCollection, whereas the rest of the contexts are added as
managed beans of the ContextHandlerCollection. Please provide more details
on how you are deploying the /zimlet context.

Jan

On Wed, 24 Apr 2019 at 11:11, Jan Bartel  wrote:

> Number 12) apache-jsp should say "transitive provider of apache-jsp for
> jsp", so there is something wrong with the way the apache-jsp module is
> being initialized.
>
> There is also a further problem, in that your log output from the dump
> command throws a NullPointerException - not sure why that is happening or
> if it is related, but it certainly prevents the dump from showing us your
> system classpath. Will look into the NPE further.
>
> Meanwhile, I suggest you do a "java -jar ../start.jar --dry-run" and that
> output should show us the jars that are on jetty's container classpath. But
> first, do please check how you have enbled the apache-jsp module - you
> shouldn't specify it anywyhere, jetty should do it for you if you just
> enable the jsp module.
>
> Jan
>
> On Tue, 23 Apr 2019 at 12:54, Rupali Desai  wrote:
>
>> Hello,
>> I am upgrading the jetty in my web application from 9.3 to 9.4.15. I have
>> added support for JSP in the app web.xml and the"jsp" module is included in
>> startup option using "--module=jsp...". Iam using open JDK 11.02. However
>> when I start the application I get
>> "java.lang.ClassNotFoundException: org.eclipse.jetty.jsp.JettyJspServlet"
>>
>> I can see the Apache JSP jars on the container classpath. However I still
>> get the above error.
>> Any suggestions on how to fix it.
>>
>> Jetty Server Classpath:
>> ---
>> 19:  7.0 |
>> ${jetty.home}/lib/annotations/asm-tree-7.0.jar
>> 20:  1.3 |
>> ${jetty.home}/lib/annotations/javax.annotation-api-1.3.jar
>> 21:3.14.0.v20180528-0519 |
>> ${jetty.home}/lib/apache-jsp/org.eclipse.jdt.ecj-3.14.0.jar
>> 22: 9.4.15.v20190215 |
>> ${jetty.home}/lib/apache-jsp/org.eclipse.jetty.apache-jsp-9.4.15.v20190215.jar
>> 23:   8.5.24 |
>> ${jetty.home}/lib/apache-jsp/org.mortbay.jasper.apache-el-8.5.35.1.jar
>> 24:  2.3 |
>> ${jetty.home}/lib/apache-jsp/org.mortbay.jasper.apache-jsp-8.5.35.1.jar
>> 25:1.2.5 |
>> ${jetty.home}/lib/apache-jstl/org.apache.taglibs.taglibs-standard-impl-1.2.5.jar
>> 26:1.2.5 |
>> ${jetty.home}/lib/apache-jstl/org.apache.taglibs.taglibs-standard-spec-1.2.5.jar
>>
>> Enabled Modules:
>> 
>> 0) mailtransitive provider of mail for jndi
>> 1) ext 
>> 2) resources   
>> 3) threadpool  transitive provider of threadpool for server
>>init template available with
>> --add-to-start=threadpool
>> 4) server  
>> 5) jnditransitive provider of jndi for plus
>> 6) securitytransitive provider of security for webapp
>>transitive provider of security for plus
>> 7) transactionstransitive provider of transactions for plus
>> 8) servlet 
>> 9) webapp  
>>10) plus
>>11) annotations     transitive provider of annotations for websocket
>>transitive provider of annotations for jsp
>>12) apache-jsp  
>>13) apache-jstl transitive provider of apache-jstl for jstl
>>14) client  transitive provider of client for websocket
>>15) continuation
>>16) jmx 

Re: [jetty-users] Jetty 9.4.15 and JSP issue

[Jan Bartel]

Number 12) apache-jsp should say "transitive provider of apache-jsp for
jsp", so there is something wrong with the way the apache-jsp module is
being initialized.

There is also a further problem, in that your log output from the dump
command throws a NullPointerException - not sure why that is happening or
if it is related, but it certainly prevents the dump from showing us your
system classpath. Will look into the NPE further.

Meanwhile, I suggest you do a "java -jar ../start.jar --dry-run" and that
output should show us the jars that are on jetty's container classpath. But
first, do please check how you have enbled the apache-jsp module - you
shouldn't specify it anywyhere, jetty should do it for you if you just
enable the jsp module.

Jan

On Tue, 23 Apr 2019 at 12:54, Rupali Desai  wrote:

> Hello,
> I am upgrading the jetty in my web application from 9.3 to 9.4.15. I have
> added support for JSP in the app web.xml and the"jsp" module is included in
> startup option using "--module=jsp...". Iam using open JDK 11.02. However
> when I start the application I get
> "java.lang.ClassNotFoundException: org.eclipse.jetty.jsp.JettyJspServlet"
>
> I can see the Apache JSP jars on the container classpath. However I still
> get the above error.
> Any suggestions on how to fix it.
>
> Jetty Server Classpath:
> ---
> 19:  7.0 |
> ${jetty.home}/lib/annotations/asm-tree-7.0.jar
> 20:  1.3 |
> ${jetty.home}/lib/annotations/javax.annotation-api-1.3.jar
> 21:3.14.0.v20180528-0519 |
> ${jetty.home}/lib/apache-jsp/org.eclipse.jdt.ecj-3.14.0.jar
> 22: 9.4.15.v20190215 |
> ${jetty.home}/lib/apache-jsp/org.eclipse.jetty.apache-jsp-9.4.15.v20190215.jar
> 23:   8.5.24 |
> ${jetty.home}/lib/apache-jsp/org.mortbay.jasper.apache-el-8.5.35.1.jar
> 24:  2.3 |
> ${jetty.home}/lib/apache-jsp/org.mortbay.jasper.apache-jsp-8.5.35.1.jar
> 25:1.2.5 |
> ${jetty.home}/lib/apache-jstl/org.apache.taglibs.taglibs-standard-impl-1.2.5.jar
> 26:1.2.5 |
> ${jetty.home}/lib/apache-jstl/org.apache.taglibs.taglibs-standard-spec-1.2.5.jar
>
> Enabled Modules:
> 
> 0) mailtransitive provider of mail for jndi
> 1) ext 
> 2) resources   
> 3) threadpool  transitive provider of threadpool for server
>init template available with
> --add-to-start=threadpool
> 4) server  
> 5) jnditransitive provider of jndi for plus
> 6) securitytransitive provider of security for webapp
>transitive provider of security for plus
> 7) transactionstransitive provider of transactions for plus
> 8) servlet 
> 9) webapp  
>10) plus
>11) annotations transitive provider of annotations for websocket
>transitive provider of annotations for jsp
>12) apache-jsp  
>13) apache-jstl transitive provider of apache-jstl for jstl
>14) client  transitive provider of client for websocket
>15) continuation
>16) jmx 
>17) jsp 
>18) jstl
>19) servlets
>20) websocket   
>21) rewrite 
>22) setuid  
>
> Thanks
> Rupali
> ___________
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] security-constraint for implicit welcome-file

[Jan Bartel]

Ilya,

A correction to my previous post. It is probable that Glassfish/Tomcat is
using a container-specific mechanism to handle the welcome-file. As per the
spec, Section 10.10:

"The container may send the request to the welcome resource with a forward,
a redirect, or a container specific mechanism that is indistinguishable
from a direct request."

In the case of a container-specific mechanism that is indistinguishable
from a direct request, this implies that the security constraints would be
re-evaluated.

Jetty does not have a container-specific mechanism and uses only the
servlet specification mechanisms of forward or redirect.

Jan

On Tue, 19 Mar 2019 at 10:48, Jan Bartel  wrote:

> Ilya,
>
> The differences you are seeing with the handling of a security constraint
> for the url-pattern "/index.jsp" is most probably due to the different way
> Glassfish/Tomcat handles welcome files as compared to Jetty.  When Jetty
> receives a request for "/context-root/" and we look to see if there is a
> security constraint that exactly matches as per the specification Section
> 13.8.3 (using the algorithm specified in 12.1). Because your constraint is
> /index.jsp, this does not match. Jetty then dispatches the request to the
> welcome file mechanism via a forward - as this is a dispatch, the security
> constraints cannot be re-evaluated.  Most probably Glassfish/Tomcat are
> using a redirect instead of a forward, which will cause a 2nd request that
> will be evaluated against the security constraints.  If you wish, you can
> configure Jetty to do this too:  set the init-param "redirectWelcome" to
> "true" for the DefaultServlet.
>
> As for the empty string, this is mandated by the Servlet Specification
> section 12.2:
>   "The empty string ("") is a special URL pattern that exactly maps to the
> application's context root, i.e., requests of the form http://host:port
> //.
> In this case the path info is ’ / ’ and the servlet path and context
> path is empty string (““)."
>
> regards,
> Jan
>
>
>
> On Fri, 15 Mar 2019 at 00:37, Basin Ilya  wrote:
>
>> In Glassfish and Tomcat the following constraint protects access for both
>> "/index.jsp" and "/" URIs, but in Jetty the latter is unprotected:
>>
>> 
>> Restricted
>> 
>> index
>> 
>> /index.jsp
>> 
>> 
>> remembermeclient
>> 
>> 
>>
>> On the other hand, Jetty seems to support the empty string url-pattern
>> inside security-constraint, but Tomcat and Glassfish don't.
>>
>> Who's right?
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>
>
>
> --
> Jan Bartel 
> www.webtide.com
> *Expert assistance from the creators of Jetty and CometD*
>
>

-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] security-constraint for implicit welcome-file

[Jan Bartel]

Ilya,

The differences you are seeing with the handling of a security constraint
for the url-pattern "/index.jsp" is most probably due to the different way
Glassfish/Tomcat handles welcome files as compared to Jetty.  When Jetty
receives a request for "/context-root/" and we look to see if there is a
security constraint that exactly matches as per the specification Section
13.8.3 (using the algorithm specified in 12.1). Because your constraint is
/index.jsp, this does not match. Jetty then dispatches the request to the
welcome file mechanism via a forward - as this is a dispatch, the security
constraints cannot be re-evaluated.  Most probably Glassfish/Tomcat are
using a redirect instead of a forward, which will cause a 2nd request that
will be evaluated against the security constraints.  If you wish, you can
configure Jetty to do this too:  set the init-param "redirectWelcome" to
"true" for the DefaultServlet.

As for the empty string, this is mandated by the Servlet Specification
section 12.2:
  "The empty string ("") is a special URL pattern that exactly maps to the
application's context root, i.e., requests of the form http://host:port
//.
In this case the path info is ’ / ’ and the servlet path and context
path is empty string (““)."

regards,
Jan



On Fri, 15 Mar 2019 at 00:37, Basin Ilya  wrote:

> In Glassfish and Tomcat the following constraint protects access for both
> "/index.jsp" and "/" URIs, but in Jetty the latter is unprotected:
>
> 
> Restricted
> 
> index
> 
> /index.jsp
> 
> 
> remembermeclient
> 
> 
>
> On the other hand, Jetty seems to support the empty string url-pattern
> inside security-constraint, but Tomcat and Glassfish don't.
>
> Who's right?
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Concurreny problem in Session Management

[Jan Bartel]

Reinhold,

I've opened bug https://github.com/eclipse/jetty.project/issues/3284 to
record this.

I've had a look at your jetty-base, and nothing seems amiss.  I have more
questions for you,  are you able to respond on that issue please?

thanks
Jan


On Tue, 22 Jan 2019 at 23:48, Gruber Reinhold  wrote:

> Hi,
>
>
>
> upgrading to latest version 9.4.14 did not resolve the problem.
>
>
>
> Best regards
>
> Reinhold
>
>
>
> *From:* jetty-users-boun...@eclipse.org  *On
> Behalf Of *Jan Bartel
> *Sent:* Montag, 21. Januar 2019 22:48
> *To:* JETTY user mailing list 
> *Subject:* Re: [jetty-users] Concurreny problem in Session Management
>
>
>
> Hi,
>
>
>
>
>
> Thanks for the log output. Firstly,  could you try upgrading to the latest
> jetty 9.4 version 9.4.14.  Secondly, can you provide a simple reproduction
> webapp?
>
>
>
> Thanks
>
> Jan
>
>
>
> On Tue., 22 Jan. 2019, 04:18 Gruber Reinhold 
> Good day,
>
>
>
> we are using jetty-9.4.11.v20180605 and are experiencing problems with the
> standard session config  DefaultSessionCache + NullSessionStore.
>
> Some Sessions never gets destroyed. From the logs it seems that sometimes
> the sessiontimer expires a few milliseconds too soon.
>
> The session is still valid (comparing creationTime and currentTime I
> guess??) and after that the session never gets checked again and stays in
> the cache forever.
>
>
>
> Here the logs of such a session
>
>
>
> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Timer
> expired for session node07vies8r8ln8t155xl877f7899221
>
> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Inspecting
> session node07vies8r8ln8t155xl877f7899221, valid=true
>
> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Testing
> expiry on session node07vies8r8ln8t155xl877f7899221: expires at
> 1548084744136 now 1548084744135 maxIdle 180
>
> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Checking
> for idle node07vies8r8ln8t155xl877f7899221
>
> *** No more Logs for this session id
>
>
>
>
>
> Compared to the logs for a proper scavenged Session
>
>
>
> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Timer
> expired for session node01hentjzld5u6vz39lbnt2loaj150
>
> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Inspecting
> session node01hentjzld5u6vz39lbnt2loaj150, valid=true
>
> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Testing
> expiry on session node01hentjzld5u6vz39lbnt2loaj150: expires at
> 1548084308706 now 1548084308848 maxIdle 180
>
> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Session
> node01hentjzld5u6vz39lbnt2loaj150 is candidate for expiry
>
> 2019-01-21 16:26:42.963:DBUG:oejs.session:Scheduler-627185331:
> org.eclipse.jetty.server.session.SessionHandler1824115191==dftMaxIdleSec=1800
> scavenging session ids [node01hentjzld5u6vz39lbnt2loaj150,
> node01m0c0ptdefjzq6p1jcjmss49b91, node015m99znyw1u0u1eocjxuy6g4be76,
> node0128njutc20q9bg076cosq2u7v45, node01bxvp6fa4zdr71hzl49zazino264,
> node0w94ozpsbfhrf5hti1fcf0w95111, node01tnlhsfxfi2gp1kn99g5lsiuw138,
> node01esletkbhaj9g1o4cshwgurugm65, node011vmoxjy7an21bnpty5qzlkop126,
> node0x3cvb3an5g84kqq0f0q1crmx62, node0gew7z9vb030u10txee3kqgwms112,
> node01cp1wc584wvnlo52d61x6my4l96, node01x75o4937d8i61secnbltektro85,
> node01kshabnwf9h8fx3551ypmlfg136, node04l2993xxgx4kb45za59xno5b139,
> node0rxinxivxibule9ko7roh8qvo63, node0ljny6qwerth81l33o7fsz2wpw34,
> node0cnffoiinzf4y12k3taa1uk48s105, node01sy6nl8jpg6pptmb46ujfdrp914,
> node03vqeu3xu5f7w19fgsmpnd48ag103, node0yowe2bz2urnmm458d6unosmo82,
> node028cjkes81yfq323kfi99br1n125, node0cb4bpd4ik8pvmenisfk9khew110,
> node0igg96ivibij7dfz9v88k3y0u15, node0e1i3so4hhbc06pvi5v7ksha4140,
> node07y8eh82s8n261b8i5sw0kykau69, node0174qm2kcvrh931ok48ry0kti13129,
> node08z8p9rg4vpubxlw252dphpbd51, node0dpg67j74597tyykho51vu4k546,
> node01xdkyljsv4h5a1m2g2icuvsk9z164, node09i93e46nqe21d8frip28cx3j133,
> node01fy0gre1jni4yz7czmlbqi77b136, node0d7oyaaf9sfj233wh24o0grdq19,
> node01gq4d3c0j1w591qd7u86djhltq10, node01tfdg3qy5j8ax1jy49dx1n015f28,
> node0onnitlzog1nl1b02kfgvxkldq149, node0136onv2pe35vxzzcuw851krnb77,
> node01afdq1vs3ce0xnscabdh1oxtm17, node01qrlkyyk19tr4r2a21wvohcsr66,
> node019x8ur8rjhwisg61rl5qvfaut107, node0piv2sh1nxa501ukmnb876wtr143,
> node0j4955urdevwvf4hoshnuo8e2120, node011hwuf7lfptpywdz8pcvjient57,
> node0xo7wjnaddojxtl2gy3fa06hi83, node01imacjy3lp1wr1fkmxsrfujap993,
> node07y1imt3u0whc1ld1exl93x9ou127, node012v6yctpwcx4i117z79bgid8lk114,
> node01clflynk302nt1qyy7kk9q0ox442, node0t02eftrahavscusevowxa9ng73,
> node01hkogy

Re: [jetty-users] Concurreny problem in Session Management

[Jan Bartel]

Please also report your DefaultSessionCache settings, and settings for the
DefaultSessionIdManager/HouseKeeper.

thanks
Jan

On Tue, 22 Jan 2019 at 09:41, Jan Bartel  wrote:

> Also, could this bug (since fixed), but related:
> https://github.com/eclipse/jetty.project/issues/3203 ???
>
> Jan
>
> On Tue, 22 Jan 2019 at 08:48, Jan Bartel  wrote:
>
>> Hi,
>>
>>
>> Thanks for the log output. Firstly,  could you try upgrading to the
>> latest jetty 9.4 version 9.4.14.  Secondly, can you provide a simple
>> reproduction webapp?
>>
>> Thanks
>> Jan
>>
>> On Tue., 22 Jan. 2019, 04:18 Gruber Reinhold >
>>> Good day,
>>>
>>>
>>>
>>> we are using jetty-9.4.11.v20180605 and are experiencing problems with
>>> the standard session config  DefaultSessionCache + NullSessionStore.
>>>
>>> Some Sessions never gets destroyed. From the logs it seems that
>>> sometimes the sessiontimer expires a few milliseconds too soon.
>>>
>>> The session is still valid (comparing creationTime and currentTime I
>>> guess??) and after that the session never gets checked again and stays in
>>> the cache forever.
>>>
>>>
>>>
>>> Here the logs of such a session
>>>
>>>
>>>
>>> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Timer
>>> expired for session node07vies8r8ln8t155xl877f7899221
>>>
>>> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331:
>>> Inspecting session node07vies8r8ln8t155xl877f7899221, valid=true
>>>
>>> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Testing
>>> expiry on session node07vies8r8ln8t155xl877f7899221: expires at
>>> 1548084744136 now 1548084744135 maxIdle 180
>>>
>>> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Checking
>>> for idle node07vies8r8ln8t155xl877f7899221
>>>
>>> *** No more Logs for this session id
>>>
>>>
>>>
>>>
>>>
>>> Compared to the logs for a proper scavenged Session
>>>
>>>
>>>
>>> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Timer
>>> expired for session node01hentjzld5u6vz39lbnt2loaj150
>>>
>>> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331:
>>> Inspecting session node01hentjzld5u6vz39lbnt2loaj150, valid=true
>>>
>>> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Testing
>>> expiry on session node01hentjzld5u6vz39lbnt2loaj150: expires at
>>> 1548084308706 now 1548084308848 maxIdle 180
>>>
>>> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Session
>>> node01hentjzld5u6vz39lbnt2loaj150 is candidate for expiry
>>>
>>> 2019-01-21 16:26:42.963:DBUG:oejs.session:Scheduler-627185331:
>>> org.eclipse.jetty.server.session.SessionHandler1824115191==dftMaxIdleSec=1800
>>> scavenging session ids [node01hentjzld5u6vz39lbnt2loaj150,
>>> node01m0c0ptdefjzq6p1jcjmss49b91, node015m99znyw1u0u1eocjxuy6g4be76,
>>> node0128njutc20q9bg076cosq2u7v45, node01bxvp6fa4zdr71hzl49zazino264,
>>> node0w94ozpsbfhrf5hti1fcf0w95111, node01tnlhsfxfi2gp1kn99g5lsiuw138,
>>> node01esletkbhaj9g1o4cshwgurugm65, node011vmoxjy7an21bnpty5qzlkop126,
>>> node0x3cvb3an5g84kqq0f0q1crmx62, node0gew7z9vb030u10txee3kqgwms112,
>>> node01cp1wc584wvnlo52d61x6my4l96, node01x75o4937d8i61secnbltektro85,
>>> node01kshabnwf9h8fx3551ypmlfg136, node04l2993xxgx4kb45za59xno5b139,
>>> node0rxinxivxibule9ko7roh8qvo63, node0ljny6qwerth81l33o7fsz2wpw34,
>>> node0cnffoiinzf4y12k3taa1uk48s105, node01sy6nl8jpg6pptmb46ujfdrp914,
>>> node03vqeu3xu5f7w19fgsmpnd48ag103, node0yowe2bz2urnmm458d6unosmo82,
>>> node028cjkes81yfq323kfi99br1n125, node0cb4bpd4ik8pvmenisfk9khew110,
>>> node0igg96ivibij7dfz9v88k3y0u15, node0e1i3so4hhbc06pvi5v7ksha4140,
>>> node07y8eh82s8n261b8i5sw0kykau69, node0174qm2kcvrh931ok48ry0kti13129,
>>> node08z8p9rg4vpubxlw252dphpbd51, node0dpg67j74597tyykho51vu4k546,
>>> node01xdkyljsv4h5a1m2g2icuvsk9z164, node09i93e46nqe21d8frip28cx3j133,
>>> node01fy0gre1jni4yz7czmlbqi77b136, node0d7oyaaf9sfj233wh24o0grdq19,
>>> node01gq4d3c0j1w591qd7u86djhltq10, node01tfdg3qy5j8ax1jy49dx1n015f28,
>>> node0onnitlzog1nl1b02kfgvxkldq149, node0136onv2pe35vxzzcuw851krnb77,
>>> node01afdq1vs3ce0xnscabdh1oxtm17, node01qrlkyyk19tr4r2a21wvohcsr66,
>>> node019x8ur8rjhwisg61rl5qvfaut107, node0piv2sh1nxa501ukmnb876wtr143,
&

Re: [jetty-users] Concurreny problem in Session Management

[Jan Bartel]

Also, could this bug (since fixed), but related:
https://github.com/eclipse/jetty.project/issues/3203 ???

Jan

On Tue, 22 Jan 2019 at 08:48, Jan Bartel  wrote:

> Hi,
>
>
> Thanks for the log output. Firstly,  could you try upgrading to the latest
> jetty 9.4 version 9.4.14.  Secondly, can you provide a simple reproduction
> webapp?
>
> Thanks
> Jan
>
> On Tue., 22 Jan. 2019, 04:18 Gruber Reinhold 
>> Good day,
>>
>>
>>
>> we are using jetty-9.4.11.v20180605 and are experiencing problems with
>> the standard session config  DefaultSessionCache + NullSessionStore.
>>
>> Some Sessions never gets destroyed. From the logs it seems that sometimes
>> the sessiontimer expires a few milliseconds too soon.
>>
>> The session is still valid (comparing creationTime and currentTime I
>> guess??) and after that the session never gets checked again and stays in
>> the cache forever.
>>
>>
>>
>> Here the logs of such a session
>>
>>
>>
>> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Timer
>> expired for session node07vies8r8ln8t155xl877f7899221
>>
>> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Inspecting
>> session node07vies8r8ln8t155xl877f7899221, valid=true
>>
>> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Testing
>> expiry on session node07vies8r8ln8t155xl877f7899221: expires at
>> 1548084744136 now 1548084744135 maxIdle 180
>>
>> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Checking
>> for idle node07vies8r8ln8t155xl877f7899221
>>
>> *** No more Logs for this session id
>>
>>
>>
>>
>>
>> Compared to the logs for a proper scavenged Session
>>
>>
>>
>> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Timer
>> expired for session node01hentjzld5u6vz39lbnt2loaj150
>>
>> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Inspecting
>> session node01hentjzld5u6vz39lbnt2loaj150, valid=true
>>
>> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Testing
>> expiry on session node01hentjzld5u6vz39lbnt2loaj150: expires at
>> 1548084308706 now 1548084308848 maxIdle 180
>>
>> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Session
>> node01hentjzld5u6vz39lbnt2loaj150 is candidate for expiry
>>
>> 2019-01-21 16:26:42.963:DBUG:oejs.session:Scheduler-627185331:
>> org.eclipse.jetty.server.session.SessionHandler1824115191==dftMaxIdleSec=1800
>> scavenging session ids [node01hentjzld5u6vz39lbnt2loaj150,
>> node01m0c0ptdefjzq6p1jcjmss49b91, node015m99znyw1u0u1eocjxuy6g4be76,
>> node0128njutc20q9bg076cosq2u7v45, node01bxvp6fa4zdr71hzl49zazino264,
>> node0w94ozpsbfhrf5hti1fcf0w95111, node01tnlhsfxfi2gp1kn99g5lsiuw138,
>> node01esletkbhaj9g1o4cshwgurugm65, node011vmoxjy7an21bnpty5qzlkop126,
>> node0x3cvb3an5g84kqq0f0q1crmx62, node0gew7z9vb030u10txee3kqgwms112,
>> node01cp1wc584wvnlo52d61x6my4l96, node01x75o4937d8i61secnbltektro85,
>> node01kshabnwf9h8fx3551ypmlfg136, node04l2993xxgx4kb45za59xno5b139,
>> node0rxinxivxibule9ko7roh8qvo63, node0ljny6qwerth81l33o7fsz2wpw34,
>> node0cnffoiinzf4y12k3taa1uk48s105, node01sy6nl8jpg6pptmb46ujfdrp914,
>> node03vqeu3xu5f7w19fgsmpnd48ag103, node0yowe2bz2urnmm458d6unosmo82,
>> node028cjkes81yfq323kfi99br1n125, node0cb4bpd4ik8pvmenisfk9khew110,
>> node0igg96ivibij7dfz9v88k3y0u15, node0e1i3so4hhbc06pvi5v7ksha4140,
>> node07y8eh82s8n261b8i5sw0kykau69, node0174qm2kcvrh931ok48ry0kti13129,
>> node08z8p9rg4vpubxlw252dphpbd51, node0dpg67j74597tyykho51vu4k546,
>> node01xdkyljsv4h5a1m2g2icuvsk9z164, node09i93e46nqe21d8frip28cx3j133,
>> node01fy0gre1jni4yz7czmlbqi77b136, node0d7oyaaf9sfj233wh24o0grdq19,
>> node01gq4d3c0j1w591qd7u86djhltq10, node01tfdg3qy5j8ax1jy49dx1n015f28,
>> node0onnitlzog1nl1b02kfgvxkldq149, node0136onv2pe35vxzzcuw851krnb77,
>> node01afdq1vs3ce0xnscabdh1oxtm17, node01qrlkyyk19tr4r2a21wvohcsr66,
>> node019x8ur8rjhwisg61rl5qvfaut107, node0piv2sh1nxa501ukmnb876wtr143,
>> node0j4955urdevwvf4hoshnuo8e2120, node011hwuf7lfptpywdz8pcvjient57,
>> node0xo7wjnaddojxtl2gy3fa06hi83, node01imacjy3lp1wr1fkmxsrfujap993,
>> node07y1imt3u0whc1ld1exl93x9ou127, node012v6yctpwcx4i117z79bgid8lk114,
>> node01clflynk302nt1qyy7kk9q0ox442, node0t02eftrahavscusevowxa9ng73,
>> node01hkogytp7gw2hy38v8732yr21, node014jexudy7y7l61mey7wlt0cct287,
>> node01jcmajrzk4aim1iym78zilbrvd80, node0tlc3h1ifv71b1cr8bnbttio3w88,
>> node010h5pb66srlg516kktw3qoyrcw2, node01m8db9brlt838coucn5kdyd5v74,
>> node01n4u2ir2jzsjfin8nnqcog1je152, node01jjc7jhs3x10f1w6

Re: [jetty-users] Concurreny problem in Session Management

[Jan Bartel]

Hi,


Thanks for the log output. Firstly,  could you try upgrading to the latest
jetty 9.4 version 9.4.14.  Secondly, can you provide a simple reproduction
webapp?

Thanks
Jan

On Tue., 22 Jan. 2019, 04:18 Gruber Reinhold  Good day,
>
>
>
> we are using jetty-9.4.11.v20180605 and are experiencing problems with the
> standard session config  DefaultSessionCache + NullSessionStore.
>
> Some Sessions never gets destroyed. From the logs it seems that sometimes
> the sessiontimer expires a few milliseconds too soon.
>
> The session is still valid (comparing creationTime and currentTime I
> guess??) and after that the session never gets checked again and stays in
> the cache forever.
>
>
>
> Here the logs of such a session
>
>
>
> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Timer
> expired for session node07vies8r8ln8t155xl877f7899221
>
> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Inspecting
> session node07vies8r8ln8t155xl877f7899221, valid=true
>
> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Testing
> expiry on session node07vies8r8ln8t155xl877f7899221: expires at
> 1548084744136 now 1548084744135 maxIdle 180
>
> 2019-01-21 16:32:24.135:DBUG:oejs.session:Scheduler-627185331: Checking
> for idle node07vies8r8ln8t155xl877f7899221
>
> *** No more Logs for this session id
>
>
>
>
>
> Compared to the logs for a proper scavenged Session
>
>
>
> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Timer
> expired for session node01hentjzld5u6vz39lbnt2loaj150
>
> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Inspecting
> session node01hentjzld5u6vz39lbnt2loaj150, valid=true
>
> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Testing
> expiry on session node01hentjzld5u6vz39lbnt2loaj150: expires at
> 1548084308706 now 1548084308848 maxIdle 180
>
> 2019-01-21 16:25:08.848:DBUG:oejs.session:Scheduler-627185331: Session
> node01hentjzld5u6vz39lbnt2loaj150 is candidate for expiry
>
> 2019-01-21 16:26:42.963:DBUG:oejs.session:Scheduler-627185331:
> org.eclipse.jetty.server.session.SessionHandler1824115191==dftMaxIdleSec=1800
> scavenging session ids [node01hentjzld5u6vz39lbnt2loaj150,
> node01m0c0ptdefjzq6p1jcjmss49b91, node015m99znyw1u0u1eocjxuy6g4be76,
> node0128njutc20q9bg076cosq2u7v45, node01bxvp6fa4zdr71hzl49zazino264,
> node0w94ozpsbfhrf5hti1fcf0w95111, node01tnlhsfxfi2gp1kn99g5lsiuw138,
> node01esletkbhaj9g1o4cshwgurugm65, node011vmoxjy7an21bnpty5qzlkop126,
> node0x3cvb3an5g84kqq0f0q1crmx62, node0gew7z9vb030u10txee3kqgwms112,
> node01cp1wc584wvnlo52d61x6my4l96, node01x75o4937d8i61secnbltektro85,
> node01kshabnwf9h8fx3551ypmlfg136, node04l2993xxgx4kb45za59xno5b139,
> node0rxinxivxibule9ko7roh8qvo63, node0ljny6qwerth81l33o7fsz2wpw34,
> node0cnffoiinzf4y12k3taa1uk48s105, node01sy6nl8jpg6pptmb46ujfdrp914,
> node03vqeu3xu5f7w19fgsmpnd48ag103, node0yowe2bz2urnmm458d6unosmo82,
> node028cjkes81yfq323kfi99br1n125, node0cb4bpd4ik8pvmenisfk9khew110,
> node0igg96ivibij7dfz9v88k3y0u15, node0e1i3so4hhbc06pvi5v7ksha4140,
> node07y8eh82s8n261b8i5sw0kykau69, node0174qm2kcvrh931ok48ry0kti13129,
> node08z8p9rg4vpubxlw252dphpbd51, node0dpg67j74597tyykho51vu4k546,
> node01xdkyljsv4h5a1m2g2icuvsk9z164, node09i93e46nqe21d8frip28cx3j133,
> node01fy0gre1jni4yz7czmlbqi77b136, node0d7oyaaf9sfj233wh24o0grdq19,
> node01gq4d3c0j1w591qd7u86djhltq10, node01tfdg3qy5j8ax1jy49dx1n015f28,
> node0onnitlzog1nl1b02kfgvxkldq149, node0136onv2pe35vxzzcuw851krnb77,
> node01afdq1vs3ce0xnscabdh1oxtm17, node01qrlkyyk19tr4r2a21wvohcsr66,
> node019x8ur8rjhwisg61rl5qvfaut107, node0piv2sh1nxa501ukmnb876wtr143,
> node0j4955urdevwvf4hoshnuo8e2120, node011hwuf7lfptpywdz8pcvjient57,
> node0xo7wjnaddojxtl2gy3fa06hi83, node01imacjy3lp1wr1fkmxsrfujap993,
> node07y1imt3u0whc1ld1exl93x9ou127, node012v6yctpwcx4i117z79bgid8lk114,
> node01clflynk302nt1qyy7kk9q0ox442, node0t02eftrahavscusevowxa9ng73,
> node01hkogytp7gw2hy38v8732yr21, node014jexudy7y7l61mey7wlt0cct287,
> node01jcmajrzk4aim1iym78zilbrvd80, node0tlc3h1ifv71b1cr8bnbttio3w88,
> node010h5pb66srlg516kktw3qoyrcw2, node01m8db9brlt838coucn5kdyd5v74,
> node01n4u2ir2jzsjfin8nnqcog1je152, node01jjc7jhs3x10f1w6m4hv4h7xug0,
> node01tthlplz6momg1hmzpx8z242y9156, node01k2aefpam0q223jum1o1pb57s37,
> node01fkzj2zgycdg218n0p8oy978q129, node01bdr1dytm31at18v89aai6nvxf104,
> node01hk4jj9s4agbb1nii1n4pkxklt108, node01ve8wp1dyqnkumfxckxbqgktd170,
> node0kxf9va52juhsgf2nnw38u99u23, node01fp5596z3mqw81636r81ke1cuw50,
> node0u6vajhgrnp8z6vewb9w3gz9l123, node018ovezppho2y1le7x0jmybj2x84,
> node04b8wqt5encht1oac1yxagcbet147, node01ajur79hkcl0qwvw6cw2a8tbz113,
> node01lpep6w3e6m4chy9yb3xv984b81, node0eprqkz4b12o9828oq9jl7ajp44,
> node010az9536agwy78x90x7omdbs7122, node0zujdmlzece221uoky5ul5w3s26,
> node014ii42e5ftupr110cql6b5bfqj109, node0gm5wcugzy0rx19min4c58btq8124,
> node0yuv51y8q0dncm73rigjsbfn101, node0v986jwfu06yb1gzje9xz39xj8157,
> node07hn6i53faqs95eum3xywhp7756, node0r138ssgcbkpzyf7miiqp6fzi162,
> 

Re: [jetty-users] Problem with JSTL and Jetty running under OSGI

[Jan Bartel]

And do have a read of the 9.3 doco for jetty in osgi here:
https://www.eclipse.org/jetty/documentation/9.3.25.v20180904/framework-jetty-osgi.html

Jan

On Thu, 17 Jan 2019 at 04:46, Tom Hoffman  wrote:

> Thank you! I'll check into that as well!
>
> Tom
> *~~~*
> *Tom Hoffman*
>
>
>
> On Wed, Jan 16, 2019 at 11:38 AM Joakim Erdfelt 
> wrote:
>
>> When it comes to JSP and JSTL on OSGi, you might want to look at the
>> jetty-osgi-boot-jsp artifact and it's hacks to OSGi to allow JSTL to
>> function.
>>
>>
>> https://github.com/eclipse/jetty.project/tree/jetty-9.4.14.v20181114/jetty-osgi/jetty-osgi-boot-jsp
>>
>> Joakim Erdfelt / joa...@webtide.com
>>
>>
>> On Wed, Jan 16, 2019 at 11:35 AM Joakim Erdfelt 
>> wrote:
>>
>>> 9.3.0 is very old now. (the entire 9.3.x series is on security
>>> maintenance atm and isn't being updated anymore)
>>>
>>> There are a number of quirks throughout the 9.3.0 series related to JSTL
>>> and the need (or not) for the WEB-INF/lib/ to contain the appropriate jstl
>>> jar files (or not).
>>> The 9.4.x series on the other hand is much cleaner in this regard.  Have
>>> you tried a more recent / stable version of Jetty?
>>>
>>> Joakim Erdfelt / joa...@webtide.com
>>>
>>>
>>> On Wed, Jan 16, 2019 at 11:00 AM Tom Hoffman 
>>> wrote:
>>>
>>>> I'm using version jetty-9.3.0.v20150612 in an OSGI environment, with
>>>> v2.5 of the Servlet specification. I've inherited a mass/mess of old Java
>>>> Servlet code that works, that is replete with security issues. I'm trying
>>>> to address some of the XSS issues by using JSTL. I've added the required
>>>> JSTL directive at the top of the JSP files:
>>>>
>>>>  <%@ taglib uri="http://java.sun.com/jsp/jstl/core; prefix="c" %>
>>>>
>>>>
>>>> But when I first access this jsp page, it fails and I see the following
>>>> in the error log:
>>>>
>>>> 2019-01-08 20:44:44,606 qtp1697835528-134 WARN
>>>>> org.eclipse.jetty.servlet.ServletHandler -   
>>>>> org.apache.jasper.JasperException:
>>>>> /jsp/applicationsChoice.jsp(1,63) PWC6188: 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
>>>>> at
>>>>> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:92)
>>>>
>>>>
>>>> I've seen many old references that suggest there was at one point in
>>>> time issues with JSTL and the Jetty 9.x release. Is this old information?
>>>> Can someone supply a pointer or two?
>>>>
>>>> *~~~*
>>>> *Tom Hoffman*
>>>>
>>>> ___
>>>> jetty-users mailing list
>>>> jetty-users@eclipse.org
>>>> To change your delivery options, retrieve your password, or unsubscribe
>>>> from this list, visit
>>>> https://www.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://www.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://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Jetty sessions leaking

[Jan Bartel]

Carey,

if you open the issue, I've got a fix ready to go.

Jan

On Sat, 15 Dec 2018 at 09:22, Jan Bartel  wrote:

> By all means raise it as an issue. And thank you for the repro test case,
> I'm on it.
>
> Jan
>
> On Sat, 15 Dec 2018 at 08:51, Carey Evans  wrote:
>
>>
>> On Thu, 13 Dec 2018 at 20:31, Carey Evans  wrote:
>>
>>> An update: I added
>>>
>>> <%@ page language="java" contentType="text/html; charset=UTF-8" 
>>> pageEncoding="UTF-8" session="false" isErrorPage="true" %>
>>>
>>> to the top of 503.jsp, and I no longer see the issue using this code.
>>>
>>
>> I've simplified the code at https://github.com/carey/jetty-sessions-bug.
>> Now all that's needed to create sessions that never expire is an error
>> handling servlet that starts a new session from an async dispatch.
>>
>> Should I raise this at https://github.com/eclipse/jetty.project/issues?
>>
>> --
>> Laissez lire, et laissez danser; ces deux amusements ne feront jamais de
>> mal au monde.
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>
>
>
> --
> Jan Bartel 
> www.webtide.com
> *Expert assistance from the creators of Jetty and CometD*
>
>

-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Jetty sessions leaking

[Jan Bartel]

By all means raise it as an issue. And thank you for the repro test case,
I'm on it.

Jan

On Sat, 15 Dec 2018 at 08:51, Carey Evans  wrote:

>
> On Thu, 13 Dec 2018 at 20:31, Carey Evans  wrote:
>
>> An update: I added
>>
>> <%@ page language="java" contentType="text/html; charset=UTF-8" 
>> pageEncoding="UTF-8" session="false" isErrorPage="true" %>
>>
>> to the top of 503.jsp, and I no longer see the issue using this code.
>>
>
> I've simplified the code at https://github.com/carey/jetty-sessions-bug.
> Now all that's needed to create sessions that never expire is an error
> handling servlet that starts a new session from an async dispatch.
>
> Should I raise this at https://github.com/eclipse/jetty.project/issues?
>
> --
> Laissez lire, et laissez danser; ces deux amusements ne feront jamais de
> mal au monde.
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users



-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Jetty sessions leaking

[Jan Bartel]

Carey,

Some follow up on this.

I wrote a test with async servlet handling accessing sessions, and it
passes:  the request count is as it should be.

I need more details from you:
+ do you wrap your requests
+ do you have multiple simultaneous requests accessing the same session
+ what SessionCache implementation do you use, and what configuration do
you have on it
+ what is the max inactive interval on your sessions
+ how does your async handling terminate, is it with dispatch() or
complete()
+ do you do any forwarding between contexts
+ does your application call Request.changeSessionId()
+ does your application use form authentication

Jan

On Thu, 13 Dec 2018 at 13:38, Jan Bartel  wrote:

> Hi Carey,
>
> So sessions will only be written to the store (jdbc) when the request
> count drops to zero. If the count remains above 0, then that is why they
> are not written nor expired.
>
> I will take a particularly close look at the Async handling myself, but if
> you came up with a repro test case that does some simple async handling
> that would be great .
>
> Jan
>
> On Thu., 13 Dec. 2018, 13:24 Carey Evans 
>> Hi.
>>
>> We're trying to use Jetty 9.4.14 with an application that uses a lot of
>> sessions, and we're having trouble with the DefaultSessionCache not
>> deleting some old sessions, until we ended up with 6.7 GB consumed by
>> 393216 Session objects in the heap after our load test. Looking at the
>> sessions that hadn't expired after a few hours, I see that each of them has
>> _requests set to 1, when it looks like they should all be 0.
>>
>> We're using a JDBC session store, and a lot of sessions didn't seem to
>> make it to the database table, although the ones that did were expired and
>> removed as expected.
>>
>> This is a fairly large application with a lot of proprietary code, so
>> unfortunately I don't have a way to reproduce this that I can share at the
>> moment. We do a fair bit of asynchronous servlet processing, though, which
>> makes me suspicious. Where can I start to look for a solution to this?
>>
>>
>>
>> --
>> Laissez lire, et laissez danser; ces deux amusements ne feront jamais de
>> mal au monde.
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>
>

-- 
Jan Bartel 
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Jetty sessions leaking

[Jan Bartel]

Hi Carey,

So sessions will only be written to the store (jdbc) when the request count
drops to zero. If the count remains above 0, then that is why they are not
written nor expired.

I will take a particularly close look at the Async handling myself, but if
you came up with a repro test case that does some simple async handling
that would be great .

Jan

On Thu., 13 Dec. 2018, 13:24 Carey Evans  Hi.
>
> We're trying to use Jetty 9.4.14 with an application that uses a lot of
> sessions, and we're having trouble with the DefaultSessionCache not
> deleting some old sessions, until we ended up with 6.7 GB consumed by
> 393216 Session objects in the heap after our load test. Looking at the
> sessions that hadn't expired after a few hours, I see that each of them has
> _requests set to 1, when it looks like they should all be 0.
>
> We're using a JDBC session store, and a lot of sessions didn't seem to
> make it to the database table, although the ones that did were expired and
> removed as expected.
>
> This is a fairly large application with a lot of proprietary code, so
> unfortunately I don't have a way to reproduce this that I can share at the
> moment. We do a fair bit of asynchronous servlet processing, though, which
> makes me suspicious. Where can I start to look for a solution to this?
>
>
>
> --
> Laissez lire, et laissez danser; ces deux amusements ne feront jamais de
> mal au monde.
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Completely different behaviour when using maven jetty plugin with and without debug flag

[Jan Bartel]

Hi,

You didn't mention the version of jetty, the version of java, the version
of maven, nor the os you're running on, so that makes it more difficult to
help you.

To help pinpoint the problem, you could edit the
$MAVEN_HOME/conf/logging/simplelogger.properties file, and turn on all
jetty debug logging by adding a line like:
org.slf4j.simpleLogger.log.org.eclipse.jetty=DEBUG

Compare the output you get with/without the -X option.

Jan

On Wed, 17 Oct 2018 at 15:21, Saad Mazahir  wrote:

> Hi all,
>
> I have a jetty server which runs fine normally.  When I try to add a new
> POM dependency, the war file fails to get assembled.  When I run the plugin
> but with the debug switch enabled, the war file get's assembled and run's
> fine.
> That is:
>
> Bad:
>
> mvn clean install jetty:run
>
> mvn clean install jetty:run -Dorg.eclipse.jetty.annotations.maxWait=420
>
> *webAppSourceDirectory/Users/smazahir/Workspace/zodiac/touchless_maven_fix/simpleServer/jaxrs/target/swagger-jaxrs-server-1.0.0
> does not exist.*
>
> Good:
>
> mvn clean install jetty:run -Dorg.eclipse.jetty.annotations.maxWait=420 -X
>
>
>
> What could cause this discrepancy?  How can I debug whether adding a new
> pom dependency actually causes my project to fail?
>
> Thanks.
>
> ___
> 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 assistance from the creators of Jetty and CometD*
___
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] Webapp started twice??

[Jan Bartel]

When you copied the webapp to 'myapp.old' jetty will deploy that new
directory. So you would have had 2 identical webapps deployed.

The better way to do it would be to copy the new webapp into the existing
'myapp' directory and then touch myapp.xml to cause it to be redeployed.

I haven't seen the exception you report before. We there any more relevant
lines in the log?


Jan

On Sat., 6 Oct. 2018, 22:06 John English,  wrote:

> I just updated a webapp, and something peculiar happened, and I'm
> wondering if it's normal behaviour. I'm using jetty-9.4.6.v20170531.
>
> In my webapps directory, I have a directory "myapp" and a corresponding
> "myapp.xml". Since this was a major update, I copied "myapp" to
> "myapp.old" and then updated the contents of "myapp". When I tried to
> stop the webapp with"java -jar start.jar --stop", I got this:
>
> java.lang.NullPointerException
> at org.eclipse.jetty.start.Main.stop(Main.java:620)
> at org.eclipse.jetty.start.Main.stop(Main.java:560)
> at org.eclipse.jetty.start.Main.doStop(Main.java:548)
> at org.eclipse.jetty.start.Main.start(Main.java:424)
>
> I killed the webapp by hand and then tried to restart it, but both
> "myapp" and "myapp.old" started. As soon as I moved "myapp.old"
> elsewhere, everything went back to normal: I can now stop it using
> "--stop", and it restarts correctly.
>
> Is it really the expected behaviour?
>
> Thanks,
> --
> John English
>
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.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
>
___
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] Issues with jetty-9.4.11 running JSTL.jar

[Jan Bartel]

,eio=-1/-1,di=-1}=>HttpConnection@cdb548d2[p=HttpParser{s=END,0
> of -1},g=HttpGenerator@7e29bce8{s=START}]=>HttpChannelOverHttp@97013d33{
> r=1,c=false,a=IDLE,uri=//localhost:/SSPDashboard,age=3} parsed true
> HttpParser{s=END,0 of -1}
> 2018-09-13 14:24:21,797 [qtp-35913463-24] DEBUG HttpConnection -
> releaseRequestBuffer HttpConnection@cdb548d2[p=HttpParser{s=END,0 of
> -1},g=HttpGenerator@7e29bce8{s=START}]=>HttpChannelOverHttp@97013d33{
> r=1,c=false,a=IDLE,uri=//localhost:/SSPDashboard,
> age=3}<-DecryptedEndPoint@1693a94f{/127.0.0.1:49886<->/127.0.0.1:
> ,OPEN,fill=-,flush=-,to=158/3}->HttpConnection@cdb548d2[p=HttpParser{s=END,0
> of -1},g=HttpGenerator@7e29bce8{s=START}]=>HttpChannelOverHttp@97013d33{
> r=1,c=false,a=IDLE,uri=//localhost:/SSPDashboard,
> age=3}->SocketChannelEndPoint@432790d4{/127.0.0.1:49886<->/127.0.0.1:
> ,OPEN,fill=-,flush=-,to=16/3}{io=0/0,kio=0,kro=1}->SslConnection@
> 26197137{NOT_HANDSHAKING,eio=-1/-1,di=-1}=>HttpConnection@cdb548d2[p=HttpParser{s=END,0
> of -1},g=HttpGenerator@7e29bce8{s=START}]=>HttpChannelOverHttp@97013d33{
> r=1,c=false,a=IDLE,uri=//localhost:/SSPDashboard,age=3}
> 2018-09-13 14:24:21,797 [qtp-35913463-24] DEBUG HttpChannel -
> HttpChannelOverHttp@97013d33{r=1,c=false,a=IDLE,uri=//
> localhost:/SSPDashboard,age=3} handle //localhost:/SSPDashboard
> 2018-09-13 14:24:21,797 [qtp-35913463-24] DEBUG HttpChannelState -
> handling HttpChannelState@9c865bec{s=IDLE a=NOT_ASYNC i=true r=IDLE
> w=false}
> 2018-09-13 14:24:21,798 [qtp-35913463-24] DEBUG HttpChannel -
> HttpChannelOverHttp@97013d33{r=1,c=false,a=DISPATCHED,uri=/
> /localhost:/SSPDashboard,age=4} action DISPATCH
> 2018-09-13 14:24:21,799 [qtp-35913463-24] DEBUG Server - REQUEST GET
> /SSPDashboard on HttpChannelOverHttp@97013d33{
> r=1,c=false,a=DISPATCHED,uri=//localhost:/SSPDashboard,age=5}
> 2018-09-13 14:24:21,799 [qtp-35913463-24] DEBUG ContextHandler - scope
> null||/SSPDashboard @ o.e.j.w.WebAppContext@-536f2062{SSPDashboard,/
> SSPDashboard,file:///C:/Users/ari51787/sandbox/SSPConfig3432-20180529-NEW-
> HEAD-BUILD400/apps/jetty/webservices/webapps/
> SSPDashboard/,UNAVAILABLE}{C:\Users\ari51787\sandbox\
> SSPConfig3432-20180529-NEW-HEAD-BUILD400\apps\jetty\webservices\webapps\
> SSPDashboard}
> 2018-09-13 14:24:21,801 [qtp-35913463-24] DEBUG HttpChannel - sendResponse
> info=null content=HeapByteBuffer@790b7f36[p=0,l=0,c=0,r=0]={<<<>>>}
> complete=true committing=true callback=Blocker@d9468f8{null}
> 2018-09-13 14:24:21,801 [qtp-35913463-24] DEBUG HttpChannel - COMMIT for
> /SSPDashboard on HttpChannelOverHttp@97013d33{
> r=1,c=true,a=DISPATCHED,uri=//localhost:/SSPDashboard,age=7}
>
>
> ___
> 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 assistance from the creators of Jetty and CometD*
___
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.4.7 to 9.4.11

[Jan Bartel]

How are you deploying your apps, with the distro or embedded?  Can you
please enable server.dumpAfterStart=true (in server.ini), and report the
output?

thanks
Jan

On 12 June 2018 at 13:16, Lord Buddha  wrote:

> Ah, the WstxInputFactory is because of some system properties we were
> crudely using.
>
> -Djavax.xml.stream.XMLEventFactory=com.ctc.wstx.stax.WstxEventFactory
> -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory
> -Djavax.xml.stream.XMLOutputFactory=com.ctc.wstx.stax.WstxOutputFactory
>
> I guess jetty now using javax.xml.stream and so was broken by that.
>
> Don't think that is why JSP compilation is not working.
>
> On 12 June 2018 at 23:03, Lord Buddha  wrote:
>
>> Have just attempted to do this upgrade.
>>
>> Apps all deploy, but am getting the following so no JSP's compile.
>>
>> INFO   | jvm 1| 2018/06/12 17:20:11 | [qtp687479235-48] WARN
>> org.eclipse.jetty.server.handler.ErrorHandler - EXCEPTION
>> INFO   | jvm 1| 2018/06/12 17:20:11 | javax.servlet.ServletException:
>> java.lang.NoClassDefFoundError: Could not initialize class
>> org.apache.jasper.compiler.EncodingDetector
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.jsp.JettyJspServlet.service(JettyJspServlet.java:112)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:857)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHan
>> dler.java:535)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.server.handler.ScopedHandler.handle(Scoped
>> Handler.java:146)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHa
>> ndler.java:566)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(Handl
>> erWrapper.java:132)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(
>> ScopedHandler.java:257)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.server.session.SessionHandler.doHandle(
>> SessionHandler.java:1595)
>>
>>
>> Am also getting (before the above error, but they don't look related).
>>
>> INFO   | jvm 1| 2018/06/12 17:20:11 | javax.servlet.ServletException:
>> javax.servlet.ServletException: javax.xml.stream.FactoryConfigurationError:
>> Provider com.ctc.wstx.stax.WstxInputFactory not found
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.server.handler.HandlerCollection.handle(
>> HandlerCollection.java:146)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.server.handler.StatisticsHandler.handle(
>> StatisticsHandler.java:169)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(Handl
>> erWrapper.java:132)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.server.Server.handle(Server.java:531)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConne
>> ction.java:260)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at org.eclipse.jetty.io
>> .AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at org.eclipse.jetty.io
>> .FillInterest.fillable(FillInterest.java:102)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at org.eclipse.jetty.io
>> .ChannelEndPoint$2.run(ChannelEndPoint.java:118)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(Queued
>> ThreadPool.java:762)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedT
>> hreadPool.java:680)
>> INFO   | jvm 1| 2018/06/12 17:20:11 |   at
>> java.lang.Thread.run(Thread.java:748)
>>
>> We deploy on a JRE  Always have.   Currently on 1.8.0_172.
>>
>> Anybody any ideas on this limited info ?
>>
>>
>>

Re: [jetty-users] Getting error compiling JSP via embeded Jetty 9.4.9

[Jan Bartel]

Ike,


This is not the cause of your problem but you have wy too many session
managers on your classpath. Just pick one.

Other than that, check to make sure that none of the jars on your classpath
contain duplicate jsp engine classes. Also make sure that you have
configured the correct pattern configured for jars that contain taglines
you want parsed. By default the pattern matches the names of the jars we
use in the distro, if you have differently named jars you'll need to adjust
the pattern accordingly. Check this page for the name of the attribute for
the pattern:
http://www.eclipse.org/jetty/documentation/current/configuring-jsp.html

Jan

On 4 Jun. 2018 07:04, "Ike Ikonne"  wrote:

Hi all,

I am getting a JSP compilation error in Jetty-9.4.9. Please see the
attached stacktrace and the java classloader output. Any insight
will be appreciated.

at java.lang.Thread.run(Thread.java:811) [?:2.9 (02-08-2018)]
Caused by: java.lang.NullPointerException
at
org.apache.jasper.compiler.Validator$ValidateVisitor.(Validator.java:516)
~[org.mortbay.jasper.apache-jsp-8.5.24.2.jar:2.3]
at
org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1854)
~[org.mortbay.jasper.apache-jsp-8.5.24.2.jar:2.3]
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:221)
~[org.mortbay.jasper.apache-jsp-8.5.24.2.jar:2.3]
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:374)
~[org.mortbay.jasper.apache-jsp-8.5.24.2.jar:2.3]
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:351)
~[org.mortbay.jasper.apache-jsp-8.5.24.2.jar:2.3]
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:335)
~[org.mortbay.jasper.apache-jsp-8.5.24.2.jar:2.3]
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:595)
~[org.mortbay.jasper.apache-jsp-8.5.24.2.jar:2.3]
... 45 more


+> sun.misc.Launcher$AppClassLoader@aba3166f
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/sterling/sspconfig.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/sterling/accepter.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/sterling/authentication.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/sterling/componentCommon.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/sterling/configurator.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/sterling/haas.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/sterling/hadrian-client.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/sterling/hadrian-common.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/sterling/hadrian-gui.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/sterling/persistence.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/sterling/sspconfig.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/thirdparty/activemq-client-5.11.1.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/thirdparty/alloy.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/thirdparty/alpn-api-1.1.3.v20160715.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/thirdparty/asm-3.1.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/thirdparty/castor-1.3.3-anttasks.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/thirdparty/castor-1.3.3-codegen.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/thirdparty/castor-1.3.3-core.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/thirdparty/castor-1.3.3-ddlgen.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-
file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/lib/thirdparty/castor-1.3.3-jdo.jar
 +- file:/C:/SSPConfig3432-20180529-NEW-HEAD-BUILD400/bin/
 +-

Re: [jetty-users] Getting HTTP 403 instead of logon page

[Jan Bartel]

t;HttpChannelOverHttp@858adad3{
> r=2,c=false,a=IDLE,uri=null,age=0} filled 0 
> HeapByteBuffer@dd4bae89[p=0,l=0,c=8192,r=0]={<<<>>>HTTP/1.1
> 403 !Sec...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00}
> 2018-05-30 09:57:46,904 [qtp1305791298-29] DEBUG HttpConnection -
> HttpConnection@21f56b77[p=HttpParser{s=START,0 of
> -1},g=HttpGenerator@aac2a5be{s=START}]=>HttpChannelOverHttp@858adad3{
> r=2,c=false,a=IDLE,uri=null,age=0}<-SocketChannelEndPoint@b3d57a7a{/
> 127.0.0.1:58357<->/127.0.0.1:,OPEN,fill=-,flush=-,to=0/3}{io=0/0,
> kio=0,kro=1}->HttpConnection@21f56b77[p=HttpParser{s=START,0 of
> -1},g=HttpGenerator@aac2a5be{s=START}]=>HttpChannelOverHttp@858adad3{
> r=2,c=false,a=IDLE,uri=null,age=0} parse 
> HeapByteBuffer@dd4bae89[p=0,l=0,c=8192,r=0]={<<<>>>HTTP/1.1
> 403 !Sec...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00}
> {}
> 2018-05-30 09:57:46,904 [qtp1305791298-29] DEBUG HttpParser - parseNext
> s=START HeapByteBuffer@dd4bae89[p=0,l=0,c=8192,r=0]={<<<>>>HTTP/1.1 403
> !Sec...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00}
> 2018-05-30 09:57:46,920 [qtp1305791298-29] DEBUG HttpConnection -
> HttpConnection@21f56b77[p=HttpParser{s=START,0 of
> -1},g=HttpGenerator@aac2a5be{s=START}]=>HttpChannelOverHttp@858adad3{
> r=2,c=false,a=IDLE,uri=null,age=0}<-SocketChannelEndPoint@b3d57a7a{/
> 127.0.0.1:58357<->/127.0.0.1:,OPEN,fill=-,flush=-,to=16/3}{io=0/0,
> kio=0,kro=1}->HttpConnection@21f56b77[p=HttpParser{s=START,0 of
> -1},g=HttpGenerator@aac2a5be{s=START}]=>HttpChannelOverHttp@858adad3{
> r=2,c=false,a=IDLE,uri=null,age=0} parsed false HttpParser{s=START,0 of
> -1}
>
>
> ___
> 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 assistance from the creators of Jetty and CometD*
___
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] Issue during embedded Jetty startup

[Jan Bartel]

> jar:9.4.9.v20180320]
> at org.eclipse.jetty.util.component.ContainerLifeCycle.
> start(ContainerLifeCycle.java:138) [jetty-util-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.util.component.ContainerLifeCycle.
> doStart(ContainerLifeCycle.java:108) [jetty-util-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.server.handler.AbstractHandler.
> doStart(AbstractHandler.java:113) [jetty-server-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:123)
> [jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
> at org.eclipse.jetty.server.handler.ContextHandler.
> startContext(ContextHandler.java:844) [jetty-server-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.servlet.ServletContextHandler.startContext(
> ServletContextHandler.java:370) [jetty-servlet-9.4.9.
> v20180320.jar:9.4.9.v20180320]
> at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497)
> [jetty-webapp-9.4.9.v20180320.jar:9.4.9.v20180320]
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459)
> [jetty-webapp-9.4.9.v20180320.jar:9.4.9.v20180320]
> at org.eclipse.jetty.server.handler.ContextHandler.
> doStart(ContextHandler.java:785) [jetty-server-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.servlet.ServletContextHandler.doStart(
> ServletContextHandler.java:287) [jetty-servlet-9.4.9.
> v20180320.jar:9.4.9.v20180320]
> at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545)
> [jetty-webapp-9.4.9.v20180320.jar:9.4.9.v20180320]
> at org.eclipse.jetty.util.component.AbstractLifeCycle.
> start(AbstractLifeCycle.java:68) [jetty-util-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.util.component.ContainerLifeCycle.
> start(ContainerLifeCycle.java:138) [jetty-util-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.util.component.ContainerLifeCycle.
> doStart(ContainerLifeCycle.java:117) [jetty-util-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.server.handler.AbstractHandler.
> doStart(AbstractHandler.java:113) [jetty-server-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(
> ContextHandlerCollection.java:167) [jetty-server-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.util.component.AbstractLifeCycle.
> start(AbstractLifeCycle.java:68) [jetty-util-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.util.component.ContainerLifeCycle.
> start(ContainerLifeCycle.java:138) [jetty-util-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.util.component.ContainerLifeCycle.
> doStart(ContainerLifeCycle.java:117) [jetty-util-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.server.handler.AbstractHandler.
> doStart(AbstractHandler.java:113) [jetty-server-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.util.component.AbstractLifeCycle.
> start(AbstractLifeCycle.java:68) [jetty-util-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.util.component.ContainerLifeCycle.
> start(ContainerLifeCycle.java:138) [jetty-util-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.server.Server.start(Server.java:419)
> [jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
> at org.eclipse.jetty.util.component.ContainerLifeCycle.
> doStart(ContainerLifeCycle.java:108) [jetty-util-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.server.handler.AbstractHandler.
> doStart(AbstractHandler.java:113) [jetty-server-9.4.9.v20180320.
> jar:9.4.9.v20180320]
> at org.eclipse.jetty.server.Server.doStart(Server.java:386)
> [jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
>
>
>
> Ike Ikonne
>
> Aricent Engineering
>
>
> ___
> 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*
> <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
>
>
>
> ___
> 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 assistance from the creators of Jetty and CometD*
___
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] Can Jetty user bind JNDI by themselves?

[Jan Bartel]

Make the subcontext first and then bind the object into it.

Jan

On Tue., 10 Apr. 2018, 13:55 Lin Ren,  wrote:

> Hi,
>
>
>
> Thanks a lot for your reply!
>
>
>
> Then how can I bind a resource to a tree like name, such as “a/b/c”,
> please? We’re trying merge from Weblogic to Jetty, and seems something
> different between Weblogic and Jetty on the JNDI name binding…
>
>
>
> Thanks!
>
>
>
> Lin
>
>
>
> *From:* Joakim Erdfelt [mailto:joa...@webtide.com]
> *Sent:* 2018年4月9日 20:23
> *To:* JETTY user mailing list
> *Subject:* Re: [jetty-users] Can Jetty user bind JNDI by themselves?
>
>
>
> That error tells you that "/event_channel" doesn't exist.
>
>
>
> You are trying to bind "/event_channel/${serverName}" before the parent
> even exists.
>
>
>
>
> Joakim Erdfelt / joa...@webtide.com
>
>
>
> On Sat, Apr 7, 2018 at 9:41 PM, Lin Ren  wrote:
>
> Hi,
>
>
>
> I’m currently trying to bind a JNDI by myself in the Bean code (not in the
> application), code is like below:
>
>
>
>*try* {
>
>   // Bind receiver under server name
>
>   jndiName = WlngContext.*getInstance*().getServerName();
>
> *final* String *JNDI_PREFIX* = "event_channel/";
>
>   fullJndiName = *JNDI_PREFIX* + jndiName;
>
>   namingContext = *new* InitialContext();
>
>   localReceiver = *new* EventReceiverImpl(*this*);
>
>   *namingContext.bind(fullJndiName, localReceiver);*
>
>   eventContext = (EventContext) namingContext.createSubcontext(
> *JNDI_PREFIX*);
>
>   namingListener = *new* EventReceiversListener(*this*);
>
>   eventContext.addNamingListener("", EventContext.*ONELEVEL_SCOPE*,
> namingListener);
>
>   refreshCachedEventReceivers();
>
> } *catch* (Exception e) {
>
>   // Cleanup what we've done before throwing exception
>
>   System.*out*.println("" + e
> .getMessage());
>
>   e.printStackTrace();
>
>   deactivate();
>
>   *throw* e;
>
> }
>
>
>
> And I got an exception said that:
>
>
>
> *javax.naming.NameNotFoundException: event_channel is not bound*
>
>  at
> org.eclipse.jetty.jndi.local.localContextRoot.bind(localContextRoot.java:608)
>
>  at
> org.eclipse.jetty.jndi.local.localContextRoot.bind(localContextRoot.java:547)
>
>  at javax.naming.InitialContext.bind(InitialContext.java:425)
>
>  at
> com.bea.wlcp.wlng.event_channel.rmi.EventBroadcasterRmi.activate(EventBroadcasterRmi.java:54)
>
>
>
> My question here is, can we bind JNDI by ourselves? If yes, how can we do
> for that?
>
>
>
> Thanks!
>
>
>
> Lin
>
>
>
>
> ___
> 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
___
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 7's Servlet Annotations bundle requires javax.naming 0.0.0 package?

[Jan Bartel]

Yes, jetty-annotations in jetty-7 and beyond requires javax.naming to be
available. Usually this is available from the jvm and exposed by osgi
container. Check the doco for your osgi container version, and look at the
boot delegation packages or system packages. If its a really old container
then maybe you'll need to find and deploy a javax.naming bundle.

Jan

On 30 March 2018 at 10:02, Alexei Trebounskikh <
alexei.trebounsk...@tasktop.com> wrote:

> Hi all,
>
>
>
> I am trying to replace Jetty 6 bundle with Jetty 7 in a legacy Eclipse RCP
> project , but get this error:
>
> Missing requirement: Jetty :: Servlet Annotations requires package
> ‘javax.naming 0.0.0’ but it could not be found.
>
>
>
> Does it require a plugin that exports javax.naming? The project uses Java
> 8.
>
>
>
> Thanks!
>
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] Binding a WebAppContext to a specific connector?

[Jan Bartel]

Steve,

Jetty version? What other configuration? What urls did you try? What output
did you get? Did you turn on debug?

I cut and pasted your code and tested against jetty-9.4.8, and it is
working fine. I actually used 2 http ports instead of one https port, but I
suspect that wouldn't make any difference.
I used port numbers 8080 (associated with the second context) and 9090
(associated with the first context), with these urls:

http://localhost:8080/   -> served only context two
http://localhost:9090/   -> served only context one

Jan

On 24 March 2018 at 02:07, Steve Sobol - Lobos Studios <
st...@lobosstudios.com> wrote:

> It didn’t seem to work when I only used the connector names, either.
>
>
>
>
> On Fri, Mar 23, 2018 at 7:38 AM -0700, "Steve Sobol - Lobos Studios" <
> st...@lobosstudios.com> wrote:
>
> So if I want a WebAppContext to serve my app only for certain hostnames
>> and only on one connector, that isn’t possible?
>>
>>
>>
>>
>> On Fri, Mar 23, 2018 at 2:59 AM -0700, "Joakim Erdfelt" <
>> joa...@webtide.com> wrote:
>>
>> virtualHosts are not AND logic, they are OR logic.
>>>
>>> Said another way, if you have a context.virtualHosts, then the incoming
>>> request MUST match ONE of the virtualHosts entries.
>>>
>>> - Joakim
>>>
>>> Joakim Erdfelt / joa...@webtide.com
>>>
>>> On Thu, Mar 22, 2018 at 11:06 PM, Steve Sobol - Lobos Studios <
>>> st...@lobosstudios.com> wrote:
>>>
>>>> Hello :)
>>>>
>>>> https://stackoverflow.com/questions/26148418/jetty-9-setting
>>>> -up-handlers-and-connectors talks about setting up a handler that is
>>>> only used to respond to requests on a specific connector:
>>>>
>>>>
>>>>
>>>> ServerConnector httpConnector = new ServerConnector(server);
>>>>
>>>> httpConnector.setName("unsecured"); // named connector
>>>>
>>>> httpConnector.setPort(80);
>>>>
>>>>
>>>>
>>>> ContextHandler helloHandler = new ContextHandler();
>>>>
>>>> helloHandler.setContextPath("/hello");
>>>>
>>>> helloHandler.setHandler(new HelloHandler("Hello World"));
>>>>
>>>> helloHandler.setVirtualHosts(new String[]{"@unsecured"});
>>>>
>>>>
>>>>
>>>> Does this work out of the box for web app contexts? Part of my code
>>>> follows:
>>>>
>>>>
>>>>
>>>> ServerConnector sslConnector = *new *ServerConnector(s,
>>>>   *new *SslConnectionFactory(sslContextFactory, 
>>>> HttpVersion.*HTTP_1_1*.asString()),
>>>>   *new *HttpConnectionFactory(sslHttpConfig));
>>>> sslConnector.setName(*"https"*);
>>>>
>>>> sslConnector.setHost(*"0.0.0.0"*);
>>>> sslConnector.setPort(443);
>>>>
>>>>
>>>>
>>>> ServerConnector nonSslConnector = *new *ServerConnector(s,
>>>>   *new *HttpConnectionFactory(),
>>>>   *new *HttpConnectionFactory(nonSslHttpConfig));
>>>> nonSslConnector.setName(*"http"*);
>>>> nonSslConnector.setHost(*"0.0.0.0"*);
>>>> nonSslConnector.setPort(80);
>>>>
>>>>
>>>>
>>>> WebAppContext t1 = *new *WebAppContext();
>>>> t1.setContextPath(*"/"*);
>>>> t1.setDisplayName(*"abc"*);
>>>> t1.setWar(*"c:/TempWebapp-1.0.war"*);
>>>> t1.setVirtualHosts(*new *String[] {*"@https"*,*"admin.bamidbarconnect.com 
>>>> <http://admin.bamidbarconnect.com>"*,*"test2.local"*});
>>>> WebAppContext t2 = *new *WebAppContext();
>>>> t2.setContextPath(*"/"*);
>>>> t2.setResourceBase(*"c:/TempWebapp2/"*);
>>>> t2.setParentLoaderPriority(*true*);
>>>> t2.setVirtualHosts(*new *String[] {*"@http"*,*"test1.local"*});
>>>>
>>>> s.setConnectors(*new *Connector[]{nonSslConnector, sslConnector});
>>>>
>>>> HandlerList list = *new *HandlerList();
>>>> list.addHandler(t1);
>>>> list.addHandler(t2);
>>>>
>>>> s.setHandler(list);
>>>>
>>>>
>>>>
>>>> If it’s supposed to work, it doesn’t seem to be working for me. T1

Re: [jetty-users] Question for JDBC JNDI look up issue

[Jan Bartel]

Make your class an AbstractLifeCycle, and add it to the Server with
addBean(). Do it in jetty.xml before the call to setHandler, but after
you've defined your datasource.  In your class, you can look up your
datasource with context.lookup("jdbc/DSTest").

Jan

On 23 March 2018 at 00:25, Lin Ren <lin@oracle.com> wrote:

> Hi Team,
>
>
>
> I’m not sure if I’m mailing the correct alias but I’ve a question about
> Jetty usage.
>
>
>
> I’m currently trying to build up applications based on standalone Jetty
> and have a requirement that, some of the server services need be started
> before the war applications are deployed and started to provide general
> services for the deployed applications.
>
>
>
> I tried to create a class which inherits 
> “org.eclipse.jetty.util.component.AbstractLifeCycle”
> with annotation “@ManagedObject”, and also, it is injected by adding
> definitions into jetty.xml like below:
>
>
>
> 
>
>   
>
> 
>
>   
>
> 
>
>
>
> And, within the class, I need get access to the JDBC connection data
> source. I checked the document and found that, for applications, it is
> required to add the jdbc resource reference into the web.xml. While for my
> case, I don’t know how to get the data source. I tried to lookup JNDI in
> the MyAbstractLifeCycle class I created, but it failed.
>
>
>
> Below is my JDBC connection pool definition in the jetty.xml:
>
>
>
> 
>
>  
>
>  jdbc/DSTest
>
>  
>
> 
>
>jdbc:mysql://10.182.12.146:3306/linren
>
>ocsgtest
>
>123456
>
> 
>
>  
>
> 
>
>
>
> Can anyone tell me how to get the JDBC connection from the inherited class
> MyAbstractLifeCycle?
>
>
>
> Thanks!
>
>
>
> Lin
>
>
>
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] Help trying to investigate a file descriptor leak

[Jan Bartel]

We haven't had any reports of file descriptor leaks that I'm aware of.

How are you serving static content with Jetty - are you using a
ResourceHandler, or are you using the DefaultServlet, or something else?

If you are using the DefaultServlet, check how it is configured - do you
have caching enabled? Look for the settings of these init-params:

- resourceCache
- maxCacheSize
- maxCachedFileSize
- maxCachedFiles
- useFileMappedBuffer

You can turn debug on to see more info on the handling of static files -
add -Dorg.eclipse.jetty.servlet.DefaultServlet.LEVEL=DEBUG  and
-Dorg.eclipse.jetty.server.ResourceService.LEVEL=DEBUG to the command line
if you're using jetty's default logging, or otherwise configure whatever
logging system you're using to output highest level for those classes.

You can also specify jetty.dump.start=true at the very end of the jetty
command line. That will spit out most of the configuration of your jetty
server to the log just after it starts - might reveal something useful.

regards
Jan




On 14 February 2018 at 22:17, <m...@ow2.org> wrote:

> Hello everybody.
>
> I need a guess if the issue below could come from Jetty.
> We run a webapp (XWiki) at https://www.ow2.org
>
> The application is reached through Apache as a reverse proxy.
> Jetty is 9.4.6.v20170531 running on Debian (9.3)
> JVM is 8u151-b12-1~deb9u1
>
> The issue I observe from the xwiki perspective is detailed at:
>
> https://jira.xwiki.org/browse/XWIKI-15009
>
> As far as I understand, the specific content of the webapp at
> https://www.ow2.org/resources/ is statically served by Jetty and opened
> by XWiki through it. (I don't know how).
>
> The issue we observe is as time goes on, many files - not all of them -
> in the folder 'resources' above like
> https://www.ow2.org/resources/js/xwiki/meta.js are opened more than 2
> times by the java process and that number keeps increasing. We observe
> that by running:
>
> lsof -p 21948 | egrep '(REG|DIR)' | awk '{print $9'} | sort | uniq -c
> |sort -n
>
> XWiki support team says they haven't got any report of such a behavior
> recently.
>
> By the way we're also using http://www.tuckey.org/urlrewrite/ which is
> installed as a JAR in the webapp and called via web.xml. The
> configuration of the rewrite filter is as stated in
> http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/ShortURLs/#
> HUrlRewriteFilter
>
> Unfortunately I can't disable the rewrite filter for testing purpose
> right now as it would break URL schemes compatibility with URLs already
> spread over the internet.
>
> NB : The leak concerns *only* files in '/resources' which are expected
> to be server statically (by Jetty in the current case).
>
> Regards,
>
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] 'Could not instantiate listener' error on Android Studio

[Jan Bartel]

ptorProcessor.process(IterativeDescriptorProcessor.java:72)
>>>> W/System.err: at org.eclipse.jetty.webapp.MetaD
>>>> ata.resolve(MetaData.java:366)
>>>> W/System.err: at org.eclipse.jetty.webapp.WebAp
>>>> pContext.startContext(WebAppContext.java:1240)
>>>> W/System.err: at org.eclipse.jetty.server.handl
>>>> er.ContextHandler.doStart(ContextHandler.java:717)
>>>> W/System.err: at org.eclipse.jetty.webapp.WebAp
>>>> pContext.doStart(WebAppContext.java:494)
>>>> W/System.err: at org.eclipse.jetty.util.compone
>>>> nt.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>>>> W/System.err: at org.eclipse.jetty.server.handl
>>>> er.HandlerWrapper.doStart(HandlerWrapper.java:95)
>>>> W/System.err: at org.eclipse.jetty.server.Serve
>>>> r.doStart(Server.java:282)
>>>> W/System.err: at org.eclipse.jetty.util.compone
>>>> nt.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
>>>>
>>>> The library is added as a dependency. Is there any other setup that
>>>> needs to be done?
>>>>
>>>> Thank you
>>>>
>>>>
>>>> ___
>>>> 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
>>>
>>
>>
>
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] problem install jetty

[Jan Bartel]

Oops, pressed send before link to the bug, which is here:
https://github.com/eclipse/jetty.project/issues/2138

On 18 January 2018 at 11:07, Jan Bartel <j...@webtide.com> wrote:

> Ah, that's interesting.  We recently deleted the master branch, which you
> can see the URL is trying to fetch.  I don't think we should be trying to
> fetch from master for a particular release in any case.
>
> I've opened this bug:
>
> On 18 January 2018 at 10:28, Petr Vanicek <vanic...@utia.cas.cz> wrote:
>
>>
>> when installing a jetty I get the following result, do not you know where
>> the error is?
>>
>>
>> java -jar /opt/jetty-distribution-9.3.22.v20171030//start.jar
>> --add-to-startd=http,https,logging,deploy,jsp,jstl,plus,serv
>> lets,annotations,ext,resources,logging,requestlog
>> INFO: ext initialised in ${jetty.base}/start.d/ext.ini
>> INFO: logging initialised in ${jetty.base}/start.d/logging.ini
>> INFO: resources   initialised in ${jetty.base}/start.d/resources.ini
>> INFO: server  initialised (transitively) in
>> ${jetty.base}/start.d/server.ini
>> INFO: httpinitialised in ${jetty.base}/start.d/http.ini
>> INFO: requestlog  initialised in ${jetty.base}/start.d/requestlog.ini
>> INFO: ssl initialised (transitively) in
>> ${jetty.base}/start.d/ssl.ini
>> INFO: https   initialised in ${jetty.base}/start.d/https.ini
>> INFO: servletsinitialised in ${jetty.base}/start.d/servlets.ini
>> INFO: deploy  initialised in ${jetty.base}/start.d/deploy.ini
>> INFO: plusinitialised in ${jetty.base}/start.d/plus.ini
>> INFO: annotations initialised in ${jetty.base}/start.d/annotati
>> ons.ini
>> INFO: jsp initialised in ${jetty.base}/start.d/jsp.ini
>> INFO: jstlinitialised in ${jetty.base}/start.d/jstl.ini
>> MKDIR: ${jetty.base}/lib
>> MKDIR: ${jetty.base}/lib/ext
>> MKDIR: ${jetty.base}/logs
>> MKDIR: ${jetty.base}/resources
>> DOWNLOAD: https://raw.githubusercontent.com/eclipse/jetty.project/mast
>> er/jetty-server/src/test/config/etc/keystore?id=master to
>> ${jetty.base}/etc/keystore
>> java.io.IOException: URL GET Failure [404/Not Found] on
>> https://raw.githubusercontent.com/eclipse/jetty.project/mast
>> er/jetty-server/src/test/config/etc/keystore?id=master
>> at org.eclipse.jetty.start.fileinits.UriFileInitializer.downloa
>> d(UriFileInitializer.java:79)
>> at org.eclipse.jetty.start.fileinits.UriFileInitializer.init(Ur
>> iFileInitializer.java:60)
>> at org.eclipse.jetty.start.BaseBuilder.processFileResource(Base
>> Builder.java:283)
>> at org.eclipse.jetty.start.BaseBuilder.processFileResources(Bas
>> eBuilder.java:375)
>> at org.eclipse.jetty.start.BaseBuilder.build(BaseBuilder.java:2
>> 39)
>> at org.eclipse.jetty.start.Main.start(Main.java:408)
>> at org.eclipse.jetty.start.Main.main(Main.java:76)
>> MKDIR: ${jetty.base}/webapps
>> WARNING: Failed to process all file resources.
>>  - [IOException] URL GET Failure [404/Not Found] on
>> https://raw.githubusercontent.com/eclipse/jetty.project/mast
>> er/jetty-server/src/test/config/etc/keystore?id=master -
>> /opt/jetty/etc/keystore
>> java.lang.RuntimeException: Failed to process all file resources.
>>  - [IOException] URL GET Failure [404/Not Found] on
>> https://raw.githubusercontent.com/eclipse/jetty.project/mast
>> er/jetty-server/src/test/config/etc/keystore?id=master -
>> /opt/jetty/etc/keystore
>> at org.eclipse.jetty.start.BaseBuilder.processFileResources(Bas
>> eBuilder.java:394)
>> at org.eclipse.jetty.start.BaseBuilder.build(BaseBuilder.java:2
>> 39)
>> at org.eclipse.jetty.start.Main.start(Main.java:408)
>> at org.eclipse.jetty.start.Main.main(Main.java:76)
>>
>> Usage: java -jar start.jar [options] [properties] [configs]
>>java -jar start.jar --help  # for more information
>>
>> --
>>
>>   Ing. Petr Vaníček
>>
>>  _
>> |ÚTIA AV ČR v.v.i.|
>> |tel.:  26605 2233   Pod Vodárenskou věží 4   |
>> |   26605 2364   182 08 Praha 8   |
>> |fax.:  2868 90 299           |
>> | |
>> |Email: vanic...@utia.cas.cz  |
>> |

Re: [jetty-users] problem install jetty

[Jan Bartel]

Ah, that's interesting.  We recently deleted the master branch, which you
can see the URL is trying to fetch.  I don't think we should be trying to
fetch from master for a particular release in any case.

I've opened this bug:

On 18 January 2018 at 10:28, Petr Vanicek <vanic...@utia.cas.cz> wrote:

>
> when installing a jetty I get the following result, do not you know where
> the error is?
>
>
> java -jar /opt/jetty-distribution-9.3.22.v20171030//start.jar
> --add-to-startd=http,https,logging,deploy,jsp,jstl,plus,serv
> lets,annotations,ext,resources,logging,requestlog
> INFO: ext initialised in ${jetty.base}/start.d/ext.ini
> INFO: logging initialised in ${jetty.base}/start.d/logging.ini
> INFO: resources   initialised in ${jetty.base}/start.d/resources.ini
> INFO: server  initialised (transitively) in
> ${jetty.base}/start.d/server.ini
> INFO: httpinitialised in ${jetty.base}/start.d/http.ini
> INFO: requestlog  initialised in ${jetty.base}/start.d/requestlog.ini
> INFO: ssl initialised (transitively) in
> ${jetty.base}/start.d/ssl.ini
> INFO: https   initialised in ${jetty.base}/start.d/https.ini
> INFO: servletsinitialised in ${jetty.base}/start.d/servlets.ini
> INFO: deploy  initialised in ${jetty.base}/start.d/deploy.ini
> INFO: plusinitialised in ${jetty.base}/start.d/plus.ini
> INFO: annotations initialised in ${jetty.base}/start.d/annotations.ini
> INFO: jsp initialised in ${jetty.base}/start.d/jsp.ini
> INFO: jstlinitialised in ${jetty.base}/start.d/jstl.ini
> MKDIR: ${jetty.base}/lib
> MKDIR: ${jetty.base}/lib/ext
> MKDIR: ${jetty.base}/logs
> MKDIR: ${jetty.base}/resources
> DOWNLOAD: https://raw.githubusercontent.com/eclipse/jetty.project/mast
> er/jetty-server/src/test/config/etc/keystore?id=master to
> ${jetty.base}/etc/keystore
> java.io.IOException: URL GET Failure [404/Not Found] on
> https://raw.githubusercontent.com/eclipse/jetty.project/mast
> er/jetty-server/src/test/config/etc/keystore?id=master
> at org.eclipse.jetty.start.fileinits.UriFileInitializer.downloa
> d(UriFileInitializer.java:79)
> at org.eclipse.jetty.start.fileinits.UriFileInitializer.init(
> UriFileInitializer.java:60)
> at org.eclipse.jetty.start.BaseBuilder.processFileResource(Base
> Builder.java:283)
> at org.eclipse.jetty.start.BaseBuilder.processFileResources(Bas
> eBuilder.java:375)
> at org.eclipse.jetty.start.BaseBuilder.build(BaseBuilder.java:239)
> at org.eclipse.jetty.start.Main.start(Main.java:408)
> at org.eclipse.jetty.start.Main.main(Main.java:76)
> MKDIR: ${jetty.base}/webapps
> WARNING: Failed to process all file resources.
>  - [IOException] URL GET Failure [404/Not Found] on
> https://raw.githubusercontent.com/eclipse/jetty.project/mast
> er/jetty-server/src/test/config/etc/keystore?id=master -
> /opt/jetty/etc/keystore
> java.lang.RuntimeException: Failed to process all file resources.
>  - [IOException] URL GET Failure [404/Not Found] on
> https://raw.githubusercontent.com/eclipse/jetty.project/mast
> er/jetty-server/src/test/config/etc/keystore?id=master -
> /opt/jetty/etc/keystore
> at org.eclipse.jetty.start.BaseBuilder.processFileResources(Bas
> eBuilder.java:394)
> at org.eclipse.jetty.start.BaseBuilder.build(BaseBuilder.java:239)
> at org.eclipse.jetty.start.Main.start(Main.java:408)
> at org.eclipse.jetty.start.Main.main(Main.java:76)
>
> Usage: java -jar start.jar [options] [properties] [configs]
>java -jar start.jar --help  # for more information
>
> --
>
>   Ing. Petr Vaníček
>
>  _
> |ÚTIA AV ČR v.v.i.|
> |tel.:  26605 2233   Pod Vodárenskou věží 4   |
> |   26605 2364   182 08 Praha 8   |
> |fax.:  2868 90 299   |
> | |
> |Email: vanic...@utia.cas.cz  |
> |_|
> ___________
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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 Custom LoginService

[Jan Bartel]

Hi Gil,

Glad to hear you've had success.

1. Yes, it makes a lot of sense:  the authentication in the application
container/servlet container world has always been a container
responsibility. The touch point with the application is the nomination of
the realm name in web.xml and any role mappings, or equivalent in
annotations.  Section 13 Security of the Servlet Specification makes it
clear that security is a container responsibility. Not even the
programmatic interfaces allow the webapp to perform its own security - the
best the app can do is to call back into the container to ask for
authentication/authorization.  This must be the case because as @gregw
pointed out in a conversation, once a user is authenticated by a webapp
that user is then trusted by other webapps during a cross context dispatch
call.

2. I think we do explain that in the documentation, but perhaps that is
only obliquely, and maybe I'm thinking of all the times its come up in
emails on the list :)  I've added an issue for us to make sure this is
stated unambiguously in the doco:
https://github.com/eclipse/jetty.project/issues/2124

cheers
Jan

On 16 January 2018 at 00:44, Gil Baruch <gilbaruch.m...@gmail.com> wrote:

> Hi Jan,
>
> I wanted to deeply thank you for the explanation along with the example
> which clarified everything.
>
> So, thanks to you I was able to customize my login service. However, I was
> left with a few questions about this thing...
>
> 1. Does it make sense that one needs to play around that heavily with
> Jetty in order to simply have a custom login service?
> 2. Where does it ever say that jetty-web.xml loads classes by the webapp
> class loader while the context conf file loads classes by the server class
> loader
>
>
> thanks a lot,
> GBa.
>
> On Tue, Jan 9, 2018 at 1:22 PM, Jan Bartel <j...@webtide.com> wrote:
>
>> Gil,
>>
>> I'm attaching a small project to show what I mean. Look at the setup in
>> the webapp subproject and run it with mvn jetty:run.
>>
>> cheers
>> Jan
>>
>> On 8 January 2018 at 21:27, Gil Baruch <gilbaruch.m...@gmail.com> wrote:
>>
>>> Hi Jan,
>>>
>>> thank you for the detailed answer. However, I'm having some trouble
>>> figuring out your proposed solution.
>>>
>>> Let's say that we have the following:
>>>
>>>
>>>1. CustomLoginService - placed in {jetty.base}/lib/etc
>>>2. WebappLoginService - Interface with few methods, placed also in
>>>{jetty.base}/lib/etc
>>>3. WebappLoginServiceImpl - implementation of the interface, placed
>>>in {jetty.base}/webapps/MyWebApp/WEB-INF/lib
>>>
>>> if I follow you correctly, I should be adding WebappLoginServiceImpl FQN
>>> to the server classes by using the API (or system property). However, the
>>> definition of server class is:
>>> *Setting Server Classes*
>>>
>>> *You can call the
>>> methods org.eclipse.jetty.webapp.WebAppContext.setServerClasses(String
>>> Array)
>>> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#setServerClasses%28java.lang.String%5B%5D%29>
>>>  ororg.eclipse.jetty.webapp.WebAppContext.addServerClass(String)
>>> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#addServerClass(java.lang.String)>
>>>  to
>>> allow fine control over which classes are considered Server classes.*
>>>
>>>- *A web application cannot see a Server class.*
>>>- *A WEB-INF class can replace a Server class.*
>>>
>>>
>>> So, I'm assuming that you meant System class which is defined as:
>>> *Setting System Classes*
>>>
>>> *You can call the
>>> methods org.eclipse.jetty.webapp.WebAppContext.setSystemClasses(String
>>> Array)
>>> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#setSystemClasses%28java.lang.String%5B%5D%29>
>>>  or org.eclipse.jetty.webapp.WebAppContext.addSystemClass(String)
>>> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#addSystemClass(java.lang.String)>
>>>  to
>>> allow fine control over which classes are considered System classes.*
>>>
>>>- *A web application can see a System class.*
>>>- *A WEB-INF class cannot replace a System class.*
>>>
>>> However, even with system class, I'm failing to understand how it would
>>> become accessible from the server classloader... AFAIU, setting a class as
>>> syst

Re: [jetty-users] Using Jetty to launch a Spring Boot application

[Jan Bartel]

Robert,

You don't say what version of jetty you are porting from?

If you're using spring web libraries, then you will need to ensure that you
have annotation processing turned on. See this chapter of the jetty docs:
https://www.eclipse.org/jetty/documentation/9.4.8.v20171121/annotations.html

Jan

On 9 January 2018 at 15:23, Robert Stroud <r...@adelard.com> wrote:

> Hello,
>
> I have inherited a legacy web application that we distribute as a WAR file
> with a separate launcher application that uses Jetty to launch the
> application. The web application is built using Grails, which uses the
> Spring framework.
>
> The latest version of Grails uses Spring Boot to build the war file - my
> understanding is that Spring Boot depends on version 3.0 of the Servlet
> specification and uses a WebApplicationInitializer to bootstrap the
> configuration. In particular, there is no web.xml configuration in the war
> file.
>
> I have updated our launcher application to use Jetty 9.4.8, which I
> believe supports Servlet 3.x, but when I launch the web application, I see
> what is effectively a directory listing of the war file that looks like
> this:
> Directory: /
> META-INF/  <http://localhost:61508/META-INF/> 102 bytes  Jan 9, 2018
> 1:35:44 PM
> WEB-INF/  <http://localhost:61508/WEB-INF/> 136 bytes  Jan 9, 2018
> 1:35:42 PM
> assets/  <http://localhost:61508/assets/> 8024 bytes  Jan 9, 2018 1:35:44
> PM
>
> How do I configure Jetty to recognise the WebApplicationInitializer and
> load the Spring Boot application correctly? The current version of the
> launch code creates a WebAppContext in the usual way, but I assume I need
> to do something different.
>
> WebAppContext context = new WebAppContext();
> context.setWar(APPLICATION_WAR);
> context.setContextPath("/");
>
> server.setHandler(context);
> server.addLifeCycleListener(this);
>
> try {
>server.start();
> } catch (Exception e) {
>serverError(e.getMessage());
> }
>
> Thank you
>
> Robert
>
>
>
>
>
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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 Custom LoginService

[Jan Bartel]

Gil,

You can very probably use an implementation of jetty's LoginService class
that references classes from inside your webapp. To do that, you'd need to
put your LoginService impl onto the server's classpath, and make it
delegate to another class that is inside your webapp; define an interface
for the delegate that you implement inside your webapp.  It won't work of
course if you want to  reference your webapp's classes inside the
constructor of your LoginService, but if you can confine references to
webapp classes to the authentication method calls you should be ok.  You
will also need to punch some holes in the serverClasses settings that are
used to shield the webapp from access to jetty impl classes (see
WebAppContext.prependServerClass() method).

You could also go the JAAS route, as I think (but haven't checked
thoroughly) that the LoginContext will lazily delegate the loading of the
LoginModule to the thread context classloader.  Of course, if you want to
use any of the jetty impl classes to help with your implementation, you're
back to punching holes in the serverClasses settings again.

The login/auth services have traditionally been services that are offered
by the container to the webapp, with the webapp simply using the
javax.servlet api in conjunction with the declarative security statements
in web.xml to ensure portability across containers. The login/auth info
generally exists in the container's environment, with appropriate role
mappings to the webapp's environment to support portability.

cheers,
Jan

On 6 January 2018 at 17:46, Gil Baruch <gilbaruch.m...@gmail.com> wrote:

> Hi,
>
> I'm probably missing something otherwise this makes no sense...
>
> I've been trying to use a custom login service for my webapp for a while
> already without success...
>
> After lots of tries/readings I figured out the following:
>
> 1. Custom Login Service can be registered from either context deployer xml
> (preferred) or jetty-web.xml. I understood that the deployer is preferred
> because it is read first rather than the jetty-web which is read last...
> (though I don't understand the real impact in this context)
>
> 2. The custom Login Service class *must* be deployed as part of the
> server's classpath i.e. {jetty.base}/lib/etc. If deployed at
> {webapp}/WEB-INF/lib or {extra.classpath} (when extra.classpath is
> configured in the context deployer xml), it will not work and a
> ClassDefNotFound exception will be thrown.
>
> 3. It turns out that Jetty loads the class by using a server classloader
> rather than a webappcontext classloader of the webapp where it was
> configured. This means that the customLoginService has no access to the
> custom logic of the specific webapp which IMHO kind of kills the entire
> purpose of having a custom login service.
>
> Lastly, I'm not willing to turn parentPriority setting to true mainly
> because that is the opposite of the standard and thus, I want to keep my
> project as close to the standard as possible.
>
> What I'm currently thinking of is moving from the proprietary solution in
> Jetty to the standard JAAS based solution which I believe will let me have
> my custom logic in the authentication phase. However, it is more cumbersome
> IMO than the proposed LoginService alternative...
>
> Your feedback is welcome.
>
> thanks,
> GBa.
>
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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.3.3 zip file closed problem

[Jan Bartel]

edThreadPool.java:572)
>
> at java.lang.Thread.run(Thread.java:745)
>
> 2017-11-17 14:29:11.630:DBUG:oejs.HttpOutput:qtp660743486-93:
>
> java.lang.IllegalStateException: zip file closed
>
> at java.util.zip.ZipFile.ensureOpen(ZipFile.java:670)
>
> at java.util.zip.ZipFile.getInputStream(ZipFile.java:352)
>
> at java.util.jar.JarFile.getInputStream(JarFile.java:447)
>
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(
> JarURLConnection.java:162)
>
> at org.eclipse.jetty.util.resource.URLResource.
> getInputStream(URLResource.java:241)
>
> at org.eclipse.jetty.util.resource.JarResource.
> getInputStream(JarResource.java:121)
>
> at org.eclipse.jetty.util.BufferUtil.toBuffer(BufferUtil.java:924)
>
> at org.eclipse.jetty.server.ResourceCache.getDirectBuffer(
> ResourceCache.java:308)
>
> at org.eclipse.jetty.server.ResourceCache$CachedHttpContent.
> getDirectBuffer(ResourceCache.java:514)
>
> at org.eclipse.jetty.server.HttpOutput.sendContent(
> HttpOutput.java:769)
>
> at org.eclipse.jetty.server.HttpOutput.sendContent(
> HttpOutput.java:654)
>
> at org.eclipse.jetty.servlet.DefaultServlet.sendData(
> DefaultServlet.java:985)
>
> at org.eclipse.jetty.servlet.DefaultServlet.doGet(
> DefaultServlet.java:533)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>
> at org.eclipse.jetty.servlet.ServletHolder.handle(
> ServletHolder.java:816)
>
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> doFilter(ServletHandler.java:1686)
>
> at a***.servlet.SiteminderServletFilter.doFilter(
> SiteminderServletFilter.java:226)
>
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> doFilter(ServletHandler.java:1669)
>
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(
> ServletHandler.java:581)
>
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(
> ScopedHandler.java:143)
>
> at org.eclipse.jetty.security.SecurityHandler.handle(
> SecurityHandler.java:548)
>
> at org.eclipse.jetty.server.session.SessionHandler.
> doHandle(SessionHandler.java:226)
>
> at org.eclipse.jetty.server.handler.ContextHandler.
> doHandle(ContextHandler.java:1156)
>
> at org.eclipse.jetty.servlet.ServletHandler.doScope(
> ServletHandler.java:511)
>
> at org.eclipse.jetty.server.session.SessionHandler.
> doScope(SessionHandler.java:185)
>
> at org.eclipse.jetty.server.handler.ContextHandler.
> doScope(ContextHandler.java:1088)
>
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(
> ScopedHandler.java:141)
>
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
> HandlerWrapper.java:119)
>
> at org.eclipse.jetty.server.Server.handle(Server.java:517)
>
> at org.eclipse.jetty.server.HttpChannel.handle(
> HttpChannel.java:306)
>
> at org.eclipse.jetty.server.HttpConnection.onFillable(
> HttpConnection.java:242)
>
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(
> AbstractConnection.java:245)
>
> at org.eclipse.jetty.io.FillInterest.fillable(
> FillInterest.java:95)
>
> at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(
> SelectChannelEndPoint.java:75)
>
> at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.
> produceAndRun(ExecuteProduceConsume.java:213)
>
> at org.eclipse.jetty.util.thread.strategy.
> ExecuteProduceConsume.run(ExecuteProduceConsume.java:147)
>
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
> QueuedThreadPool.java:654)
>
> at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(
> QueuedThreadPool.java:572)
>
> at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
> Thanks,
>
> Jacques
>
>
>
>
> --
>
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the
> opinions or views contained herein are not intended to be, and do not
> constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall
> Street Reform and Consumer Protection Act. If you have received this
> communication in error, please destroy all electronic and paper copies and
> notify the sender immediately. Mistransmission is not intended to waive
> confidentiality or privilege. Morgan Stanley reserves the right, to the
> extent required and/or permitted under applicable law, to monitor
> electronic communications, including telephone calls with Morgan Stanl

Re: [jetty-users] Displaying progress of startup in a web browser

[Jan Bartel]

Hi Matt,

When you say embedded jetty instance, you mean your application is invoking
jetty and setting up the jetty structure? If so, you could insert a Handler
in the HandlerList before the ContextHandlerCollection. That Handler would
check some static value set by your application, and then either serve a
reply or let the request flow on to the ContextHandlerCollection to be
handled by your app.  Of course you'd have to arrange visibility of some of
your apps classes in the Handler to make that work.

Jan

On 13 November 2017 at 01:37, Matthew Sheppard <mshepp...@funnelback.com>
wrote:

> Hi all,
>
> I recently ran across an article about using Tomcat’s Valve mechanism to
> serve information about the progress of starting up the underlying web apps
> - http://www.nurkiewicz.com/2015/09/displaying-progress-of-spring.html
>
> Can anyone point me in a possible direction for doing the same kinda of
> thing with an embedded Jetty instance? Or even better, are there examples
> of people already doing this with Jetty I could take a look at?
>
> Cheers,
> Matt
>
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] Running a standalone server

[Jan Bartel]

Keith,

Here's a bunch of examples of how to configure jetty to do various things
in an embedded scenario:
https://github.com/eclipse/jetty.project/tree/jetty-9.4.x/examples/embedded/src/main/java/org/eclipse/jetty/embedded

Jan

On 26 October 2017 at 13:53, Keith Brown <keith6...@gmail.com> wrote:

> Currently, I am running a stanalone server by doing this:
> java -Dorg.eclipse.jetty.util.log.DEBUG=true -cp
> .:../jetty-all-9.4.7.v20170914-uber.jar HelloWorld
>
> by following https://wiki.eclipse.org/Jetty/Tutorial/Jetty_HelloWorld
>
> Is there a way I can simulate a start.ini with this setup? and
> jetty.xml and webapp? How can I also setup request logs
> (https://www.eclipse.org/jetty/documentation/9.4.x/
> configuring-jetty-request-logs.html)
> with this setup?
>
> I want something small and functionocal while not trying to fight
> layers of directories and files.
>
> Any thoughts would be much appreciated.
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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 compile JSPs via Maven, but without failing on errors?

[Jan Bartel]

Or you could use the includes/excludes patterns to avoid trying to compile
the jsps you know don't compile.

https://www.eclipse.org/jetty/documentation/9.4.7.v20170914/jetty-jspc-maven-plugin.html

Jan

On 21 October 2017 at 06:15, Keith Cassell <kcass...@tapestrysolutions.com>
wrote:

> I've just started working on a large project that has many JSPs, many of
> which were created long ago, and some of which were generated. I would like
> to use the jetty-jspc-maven-plugin from org.eclipse.jetty to compile our
> JSPs for use in Tomcat 8.5. Unfortunately, some of the JSPs do not compile
> cleanly, and when there is a compilation problem, the maven build fails and
> stops.
>
>
>
> The JspcMojo class does most of the work. It has an embedded class,
> JspcMojo.JettyJspC that extends org.apache.jasper.JspC and has a
> failOnError property. The documentation for JettyJspC says, "JettyJspC Add
> some extra setters to standard JspC class to help configure it for running
> in maven." So, it seems like I ought to be able to set the failOnError
> property to false and be done. I have tried all of the following, without
> success. How can I pass the failOnError property from maven to the JSP
> compiler?
>
>
>
> false
>
> false jasper.compiler.failOnError>
>
> false jasper.JspC.failOnError>
>
> false
>
> false
>
> false
>
> false eclipse.jetty.jspc.plugin.JspcMojo.JettyJspC.failOnError>
>
>
>
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] Way to start Jetty without requiring internet connection

[Jan Bartel]

John,

That error is not a jetty xml parsing error.  Are you running in osgi?
Please enable debug logging as appropriate for your environment so you can
see where this error is emanating from.

Jan

On 13 October 2017 at 08:12, John Carrieri <jcarri...@greennet.com> wrote:

> Hi I was wondering if anyone had any more ideas for me in regards to
> getting jetty to start if there is no internet connection?
>
> I did try some of the other suggestions.
>
> 1.  Adding hostname in hosts file did not get around the issue.
> 2.  I added eclipse.org  and www.eclipse.org ip in hosts file.  (Not
> ideal by any means, but wanted to rule out if it was merely from dns
> resolution.
> 3.  Without an internet connection, but with eclipse.org ip defined, I’ll
> still get a
>  java.net.NoRouteToHostException: No route to host
>
> 4.  I did try / correct the public doctype notation as per Joakim’s
> suggestion but that did not resolve the issue, although I think the
> suggestion was just to have the correct one.
>  http://www.eclipse.org/jetty/configure_9_3.dtd;>
>
> I believe I still need to have the correct notation to load
> configure_9_3.dtd locally.
>
> -John
>
>
> 10/01/2017 14:38:56.983   15 0  ERROR BUNDLE error reading XML
> configuration /usr/share/terascript/server/webconfig/contexts/localhost.
> xml:
> java.net.UnknownHostException: www.eclipse.org
>
>
> 10/01/2017 14:46:33.393   15 0  ERROR BUNDLE error reading XML
> configuration /usr/share/terascript/server/webconfig/contexts/localhost.
> xml:
> java.net.SocketException: Network is unreachable
>
>
>
>
>
>
> On Aug 20, 2017, at 3:27 AM, Travis Spencer <travislspen...@gmail.com>
> wrote:
>
> This kind of behavior would happen to me on Mac OS X El Capitan using
> Jetty 9.3.15.v20161220. It was easy to reproduce:
>
> 1. Make my cell phone a WIFI hotspot
> 2. Disable cellular data, thus making the hotspot a deadend
> 3. Connect my Mac to the hotspot
> 4. Start embedded Jetty
>
> It would hang when log4j was being initialized and actually had nothing to
> do with Jetty. It would hang here:
>
> InetAddress addr = InetAddress.getLocalHost() in NetUtils.
>
> I fixed it by adding my laptop's hostname and localhost to /etc/hosts as
> 127.0.0.1 and ::1. See [1]
>
> I know that it is somewhat different situation, but I'm wondering if the
> root cause is the same -- slow DNS resolution in Java's InetAddress.
>
> HTH!
>
> [1] https://stackoverflow.com/questions/33289695/
> inetaddress-getlocalhost-slow-to-run-30-seconds
>
> On Sun, Aug 20, 2017 at 11:27 AM John Carrieri <jcarri...@greennet.com>
> wrote:
>
>> Jetty 9.4.6
>> Java build 1.8.0_65-b17
>> Debian:  Jessie
>> It’s being started by our Application server Terascript
>>
>> Configuration file is named localhost.xml and the previous mentioned line
>> Is where the errors come from if there is no Internet connection:
>>
>> >>> http://www.eclipse.org/jetty/configure_9_3.dtd”>
>>>>
>>>
>> Thanks
>> John
>>
>>
>>
>> On Aug 19, 2017, at 7:52 PM, Jan Bartel <j...@webtide.com> wrote:
>>
>> What version of jetty? How are you starting it - embedded, distro, maven
>> ... ? What jdk? What os?
>>
>> Jetty does not need an internet connection to resolve the dtd and schemas
>> - that has always been taken care of by code in the jetty-xml jar. I just
>> tested jetty-9.4.7.RC0 and reconfirmed this, so you'll need to provide more
>> details on your setup.
>>
>> Jan
>>
>> On 20 August 2017 at 14:40, Thomas Maslen <thomas.mpp.mas...@gmail.com>
>> wrote:
>>
>>> With the caveat that this isn't a complete answer, just the first little
>>> piece of one...
>>>
>>> XML Catalog(ue) files exist to solve this sort of thing.  They let you
>>> express "when you encounter a reference to this XML-related object, satisfy
>>> it by using the local copy stored here".  For a DTD (the case you're
>>> dealing with here), the XML catalog lets you identify "this XML-related
>>> object" either by the PUBLIC id or by the System ID (that
>>> www.eclipse.org URL) or both.
>>>
>>> The other 90% of the answer would be:  how do you configure the right
>>> parts of Jetty to use an XML Catalogue?  That part I don't know, but my
>>> guess is your chances of getting an answer from folks who do know may
>>> improve if you state the version of Jetty you're using.
>>>
>>> (Perhaps it may also be possible to hack a solution by editing that line
>>> and replaci

Re: [jetty-users] GWT+Jersey+Embedded Jetty+war files query

[Jan Bartel]

*.JSPX,
> *.XSP]=>jsp
>  |   |   |   |   += Jetty_WebSocketUpgradeFilter - STARTED
>  |   |   |   |   |   +- contextAttributeKey=org.eclips
> e.jetty.websocket.server.WebSocketUpgradeFilter
>  |   |   |   |   |   +- configuration=org.eclipse.jett
> y.websocket.server.NativeWebSocketConfiguration@14658f7
>  |   |   |   |   +- [/*]/[]==1=>Jetty_WebSocketUpgradeFilter
>  |   |   |   |   += org.eclipse.jetty.servlet.ListenerHolder@8eee0f -
> STARTED
>  |   |   |   |   += com.armida.jersey.jersey_getti
> ng_started.MyResourceConfig@647d15ac==org.glassfish.
> jersey.servlet.ServletContainer,jsp=null,order=1,inst=true - STARTED
>  |   |   |   |   +- [/webapi/*]=>com.armida.jersey
> .jersey_getting_started.MyResourceConfig
>  ^
>   OK
>
>
> Plain GWT Interface no RMI/RPC calls, backend Jersey server only
> Embedded: This FAILS:
> =
> When starting: "src/webapps/gwt_jersey_test.war");
> This is some printout:
>  |   |   |   += org.eclipse.jetty.servlet.ServletHandler@15c6049 - STARTED
>  
>  |   |   |   |   +- [/]=>default
>  |   |   |   |   +- [*.jsp, *.jspf, *.jspx, *.xsp, *.JSP, *.JSPF, *.JSPX,
> *.XSP]=>jsp
>  |   |   |   |   += Jetty_WebSocketUpgradeFilter - STARTED
>  |   |   |   |   |   +- contextAttributeKey=org.eclips
> e.jetty.websocket.server.WebSocketUpgradeFilter
>  |   |   |   |   |   +- configuration=org.eclipse.jett
> y.websocket.server.NativeWebSocketConfiguration@3118b0
>  |   |   |   |   +- [/*]/[]==1=>Jetty_WebSocketUpgradeFilter
>  |   |   |   |   += org.eclipse.jetty.servlet.ListenerHolder@5d7657 -
> STARTED
>   ? FAIL
>
>
>
>
> in reply to:
> 
>
>
> Quoting Joakim Erdfelt <joa...@webtide.com>:
>
> Did you configure your embedded-jetty to use the appropriate webapp
>> configurations?
>> Of particular interest is the AnnotationConfiguration (which scans
>> bytecode
>> and looks for annotated classes).
>>
>> Joakim Erdfelt / joa...@webtide.com
>>
>> On Mon, Sep 18, 2017 at 7:08 AM, <goffr...@twibble.org> wrote:
>>
>> Hi,
>>>
>>> Hoping someone can help with a problem I have not been able to solve.
>>> I have a simple GWT application, with a simple Jersey REST server. I am
>>> able to compile and succesfully run it on Eclipse IDE using SuperDev
>>> Mode.
>>> I am able to created a .war file from my project, and drop this .war file
>>> into an unmodified stand-alone Jetty (9.4.6) webapps folder, and again it
>>> runs as expected. The .war File Size is 95981747 bytes containing the
>>> appropriate GWT and Jersey jars (if that is relevant).
>>>
>>> But when I try to load the .war file into an Embedded Jetty (9.4.2), the
>>> server-side programs will not work at all, as if the server side programs
>>> did not exist. The welcome page is however available, just that it
>>> appears
>>> there is no backend. (I am able as well to write and run simple Jersey
>>> REST
>>> applications with no dependency on GWT; also able to run simple GWT apps
>>> in
>>> embedded mode.) GWT's JettyLauncher.java (which starts embedded Jetty in
>>> Dev Mode) provides no clue. From my reading of the documentation a .war
>>> file should just work with embedded Jetty. I can't understand why one
>>> .war
>>> file works in embedded Jetty and another fails, or why a .war file works
>>> in
>>> Jetty stand-alone mode, but seriously fails in Jetty embedded mode. Maybe
>>> it's a configuration problem? If so is there a document that shows how to
>>> configure embedded Jetty to work like the stand-alone Jetty?
>>>
>>> Regards
>>> Goffredo
>>>
>>>
>>> ___
>>> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] GWT+Jersey+Embedded Jetty+war files query

[Jan Bartel]

You might find it helpful to look at the embedded jetty code examples here:
https://github.com/eclipse/jetty.project/tree/jetty-9.4.x/examples/embedded/src/main/java/org/eclipse/jetty/embedded

Jan

On 19 September 2017 at 00:08, <goffr...@twibble.org> wrote:

> Hi,
>
> Hoping someone can help with a problem I have not been able to solve.
> I have a simple GWT application, with a simple Jersey REST server. I am
> able to compile and succesfully run it on Eclipse IDE using SuperDev Mode.
> I am able to created a .war file from my project, and drop this .war file
> into an unmodified stand-alone Jetty (9.4.6) webapps folder, and again it
> runs as expected. The .war File Size is 95981747 bytes containing the
> appropriate GWT and Jersey jars (if that is relevant).
>
> But when I try to load the .war file into an Embedded Jetty (9.4.2), the
> server-side programs will not work at all, as if the server side programs
> did not exist. The welcome page is however available, just that it appears
> there is no backend. (I am able as well to write and run simple Jersey REST
> applications with no dependency on GWT; also able to run simple GWT apps in
> embedded mode.) GWT's JettyLauncher.java (which starts embedded Jetty in
> Dev Mode) provides no clue. From my reading of the documentation a .war
> file should just work with embedded Jetty. I can't understand why one .war
> file works in embedded Jetty and another fails, or why a .war file works in
> Jetty stand-alone mode, but seriously fails in Jetty embedded mode. Maybe
> it's a configuration problem? If so is there a document that shows how to
> configure embedded Jetty to work like the stand-alone Jetty?
>
> Regards
> Goffredo
>
>
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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.4.6 - getting null servletcontext in servlets

[Jan Bartel]

Aravind,

There's not enough info in your post to pinpoint the problem. I've whipped
up a small example based on your code, and it runs with no problems:

Server server = new Server(8080);
HandlerCollection handlers_ = new HandlerCollection(true);
ContextHandlerCollection chc_ = new ContextHandlerCollection();
String path = "/blah";

WebAppContext context =
new WebAppContext(chc_,
"/path/to/distro/demo-base/webapps/test.war", path);

//needed for the test webapp
HashLoginService loginService = new HashLoginService();
loginService.setName( "Test Realm" );
loginService.setConfig(
"/path/to/distro/demo-base/etc/realm.properties" );
server.addBean( loginService );
chc_.addHandler(context);
context.setContextPath(path);


String servletPath = "/blah/*";
Servlet servlet = new HelloServlet("blah-hello");
ServletHolder servletHolder = new ServletHolder(servlet);
context.addServlet(servletHolder, servletPath);

handlers_.setHandlers(new Handler[] { chc_, new DefaultHandler()});
server.setHandler(handlers_);
server.start();
server.join();


Perhaps you have old jetty-9.3 jars on the classpath?

In the absence of more info, I can only suggest that you turn on full debug
to give a clue. Maybe also try a  server.setDumpAfterStart(true) as well to
see more.

Jan

On 8 September 2017 at 13:05, Raghavan, Aravind <aravind.ragha...@fenics.com
> wrote:

> Hi All,
>
>
>
> I recently upgraded from jetty 9.3.11 to 9.4.6 .  And after upgrade  none
> of my servlets are able to get servlet context.  getServletContext() always
> returns null.  Can you please help me figure out what I am doing wrong?
>
>
>
> Relevant section of code:
>
>
>
> handlers_ = *new* HandlerCollection(*true*);
>
> chc_ = *new* ContextHandlerCollection();
>
> *for*(WebAppConfig wap: webAppConfigs)   //webappconfig a POJO from where
> I am getting webapp configs
>
> {
>
>   String path = wap.getPath();
>
>   String warFile = wap.getWarFile();
>
>   WebAppContext context =
>
> *new* WebAppContext(chc_, warFile, path);
>
>   chc_.addHandler(context);
>
>   context.setContextPath(path);
>
>   *for* (ServletConfig servletConfig: wap.getServletConfigs())
> //ServletConfig is another POJO to get servlet configs
>
>   {
>
> String servletName = servletConfig.getName();
>
> String servletPath = servletConfig.getPath();
>
> Servlet servlet = servletConfig.getServlet();
>
> ServletHolder servletHolder = *new* ServletHolder(servlet);
>
> context.addServlet(servletHolder, servletPath);
>
>   }
>
> }
>
> handlers_.setHandlers(*new* Handler[] { chc_, *new* DefaultHandler()});
>
> server_.setHandler(handlers_);
>
>
>
>
>
> Note the same code worked fined with 9.3.11.  Getting null context only
> after upgrading to 9.4.6.  I am not sure what has changed in 9.4.x to cause
> this issue.  I can’t find any changes (other than Session Management) in
> documentation.
>
>
>
>
>
> *Thanks,*
>
> *Aravind.*
>
>
>
>
>
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] Session timeout

[Jan Bartel]

John,

Ah hah! As I posted before, it seems you are not using the most recent
jetty-9.4, because you are seeing this issue, which has since been fixed:
https://github.com/eclipse/jetty.project/issues/1224

And no, old versions of jetty did not invalidate the session as soon as
they expired: we have always had a scavenger thread which periodically
invalidated sessions that were found to be expired. Note that having
changed the implementation in jetty-9.4, it is possible to do immediate
invalidation, but it is not implemented because it is highly inefficient:
consider a server that is using jdbc to store its sessions, individual
expiry invalidation would incur a network roundtrip for every session.

As regards your session expiry observed timing, as I've said, you need to
use a shorter scavenge interval than your session timeout.

And you need to update your version of jetty ;)

Jan

On 6 September 2017 at 16:36, John English <john.fore...@gmail.com> wrote:

> On 06/09/2017 03:55, Jan Bartel wrote:
>
>> John,
>>
>> As you can see on your log trace, each session contains a timer that
>> expires when the session maxInactiveInterval is reached. When the timer
>> expires, that session is queued for attention by the scavenger.
>>
>
> Why not call sessionDestroyed() at this point? I presume that this is what
> older versions of Jetty used to do, since sessionDestroyed() always used to
> be called at precisely the correct time and the session object was still
> accessible inside it. This would accord with the servlet spec where it says
> that sessiondestroyed() is called when "a session is *about to be*
> invalidated", not "some time after the session has been invalidated".
>
> By default the scavenger thread only runs once every 10mins, so it is
>> timing dependent exactly when the session will be scavenged wrt when the
>> session expires.
>>
>
> And yet:
>
> On 6 September 2017 at 01:26, John English <john.fore...@gmail.com
>> <mailto:john.fore...@gmail.com>> wrote:
>> Correction: with a 5 minute timeout and no DEBUG flag,
>> sessionDestroyed() gets called automatically after TWENTY minutes!
>>
>
> This is 15 minutes after the session expires, which is well outside the
> 10-minute period. So, hmm, I'm still baffled.
>
> --
> John English
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] Session timeout

[Jan Bartel]

I should also have added that you should upgrade to the latest jetty-9.4,
which is jetty-9.4.6.  From the look of some of those debug statements
you're on a slightly older version.

Jan

On 6 September 2017 at 10:55, Jan Bartel <j...@webtide.com> wrote:

> John,
>
> As you can see on your log trace, each session contains a timer that
> expires when the session maxInactiveInterval is reached. When the timer
> expires, that session is queued for attention by the scavenger.  By default
> the scavenger thread only runs once every 10mins, so it is timing dependent
> exactly when the session will be scavenged wrt when the session expires.
> Note that an expired session that has not yet been scavenged is not able to
> be used, as you have discovered.  The servlet spec does not stipulate any
> relationship between when a session expires and when the sessionDestroyed
> listeners will be called, only that an expired session cannot be used, and
> that the listener must be called when the session is actually invalidated
> (expiry and invalidation being 2 different things).
>
> If you want to more aggressively get rid of sessions, you can either
> invalidate them yourself in code, or you can configure a smaller scavenge
> interval.  To do that, enable the "sessions" module (java -jar
> $jetty.home/start.jar --add-to-start=sessions) and configure the jetty.
> sessionScavengeInterval.seconds property. I don't think we've documented
> that adequately, so I've opened an issue to improve the doco on this
> aspect: https://github.com/eclipse/jetty.project/issues/1793
>
> cheers
> Jan
>
> On 6 September 2017 at 01:26, John English <john.fore...@gmail.com> wrote:
>
>> On 05/09/2017 18:18, John English wrote:
>>
>>> Later tests showed that a second request made between 5 and 10 minutes
>>> later also triggers sessionDestroyed(), and that a request is needed to
>>> trigger the call to sessionDestroyed() if the DEBUG flag is not turned
>>> on; with no DEBUG parameter and no subsequent request,
>>> sessionDestroyed() is never called.
>>>
>>
>> Correction: with a 5 minute timeout and no DEBUG flag, sessionDestroyed()
>> gets called automatically after TWENTY minutes!
>>
>> --
>> John English
>> ___
>> 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 <j...@webtide.com>
> www.webtide.com
> *Expert assistance from the creators of Jetty and CometD*
>
>


-- 
Jan Bartel <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] Session timeout

[Jan Bartel]

John,

As you can see on your log trace, each session contains a timer that
expires when the session maxInactiveInterval is reached. When the timer
expires, that session is queued for attention by the scavenger.  By default
the scavenger thread only runs once every 10mins, so it is timing dependent
exactly when the session will be scavenged wrt when the session expires.
Note that an expired session that has not yet been scavenged is not able to
be used, as you have discovered.  The servlet spec does not stipulate any
relationship between when a session expires and when the sessionDestroyed
listeners will be called, only that an expired session cannot be used, and
that the listener must be called when the session is actually invalidated
(expiry and invalidation being 2 different things).

If you want to more aggressively get rid of sessions, you can either
invalidate them yourself in code, or you can configure a smaller scavenge
interval.  To do that, enable the "sessions" module (java -jar
$jetty.home/start.jar --add-to-start=sessions) and configure
the jetty.sessionScavengeInterval.seconds property. I don't think we've
documented that adequately, so I've opened an issue to improve the doco on
this aspect: https://github.com/eclipse/jetty.project/issues/1793

cheers
Jan

On 6 September 2017 at 01:26, John English <john.fore...@gmail.com> wrote:

> On 05/09/2017 18:18, John English wrote:
>
>> Later tests showed that a second request made between 5 and 10 minutes
>> later also triggers sessionDestroyed(), and that a request is needed to
>> trigger the call to sessionDestroyed() if the DEBUG flag is not turned
>> on; with no DEBUG parameter and no subsequent request,
>> sessionDestroyed() is never called.
>>
>
> Correction: with a 5 minute timeout and no DEBUG flag, sessionDestroyed()
> gets called automatically after TWENTY minutes!
>
> --
> John English
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] Stream closed warning for JSP files, only when accessing from IE

[Jan Bartel]

gt; at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:317)
> at org.eclipse.jetty.server.HttpConnection.onFillable(
> HttpConnection.java:251)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(
> AbstractConnection.java:279)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(
> ChannelEndPoint.java:124)
> at org.eclipse.jetty.util.thread.Invocable.invokePreferred(
> Invocable.java:128)
> at org.eclipse.jetty.util.thread.Invocable$InvocableExecutor.
> invoke(Invocable.java:222)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.
> doProduce(EatWhatYouKill.java:294)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(
> EatWhatYouKill.java:199)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
> QueuedThreadPool.java:673)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(
> QueuedThreadPool.java:591)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> org.eclipse.jetty.io.EofException: Stream closed
> at org.eclipse.jetty.server.ResponseWriter.isOpen(
> ResponseWriter.java:136)
> at org.eclipse.jetty.server.ResponseWriter.write(
> ResponseWriter.java:202)
> at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(
> JspWriterImpl.java:112)
> at org.apache.jasper.runtime.JspWriterImpl.write(
> JspWriterImpl.java:329)
> at java.io.Writer.write(Writer.java:157)
> at org.apache.jsp.emap_jsp._jspService(emap_jsp.java:625)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(
> JspServletWrapper.java:443)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(
> JspServlet.java:385)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)
> at org.eclipse.jetty.jsp.JettyJspServlet.service(
> JettyJspServlet.java:112)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.eclipse.jetty.servlet.ServletHolder.handle(
> ServletHolder.java:833)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(
> ServletHandler.java:535)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(
> ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(
> SecurityHandler.java:548)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
> HandlerWrapper.java:132)
> at org.eclipse.jetty.server.handler.ScopedHandler.
> nextHandle(ScopedHandler.java:190)
> at org.eclipse.jetty.server.session.SessionHandler.
> doHandle(SessionHandler.java:1595)
> at org.eclipse.jetty.server.handler.ScopedHandler.
> nextHandle(ScopedHandler.java:188)
> at org.eclipse.jetty.server.handler.ContextHandler.
> doHandle(ContextHandler.java:1253)
> at org.eclipse.jetty.server.handler.ScopedHandler.
> nextScope(ScopedHandler.java:168)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(
> ServletHandler.java:473)
> at org.eclipse.jetty.server.session.SessionHandler.
> doScope(SessionHandler.java:1564)
> at org.eclipse.jetty.server.handler.ScopedHandler.
> nextScope(ScopedHandler.java:166)
> at org.eclipse.jetty.server.handler.ContextHandler.
> doScope(ContextHandler.java:1155)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(
> ScopedHandler.java:141)
> at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(
> ContextHandlerCollection.java:219)
> at org.eclipse.jetty.server.handler.HandlerCollection.
> handle(HandlerCollection.java:126)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
> HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:564)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:317)
> at org.eclipse.jetty.server.HttpConnection.onFillable(
> HttpConnection.java:251)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(
> AbstractConnection.java:279)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(
> ChannelEndPoint.java:124)
> at org.eclipse.jetty.util.thread.Invocable.invokePreferred(
> Invocable.java:128)
> at org.eclipse.jetty.util.thread.Invocable$InvocableExecutor.
> invoke(Invocable.java:222)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.
> doProduce(EatWhatYouKill.java:294)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(
> EatWhatYouKill.java:199)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
> QueuedThreadPool.java:673)
> at org.ecli

Re: [jetty-users] Stream closed warning for JSP files, only when accessing from IE

[Jan Bartel]

Pankaj,

Do you have the full stack trace? Also, have you tried using those versions
of IE directly locally, not from within browserstack?

thanks
Jan

On 3 September 2017 at 07:45, Pankaj K Garg <g...@zeemaps.com> wrote:

> Hi,
>
> We are trying to migrate a web app from Jetty 9.2 to 9.4.
>
>  Everything seems to be working okay, except for some requests from IE 11,
> 14, 15 we get a "Stream Closed" warning in the log for JSP files.
>
>  Here's a top level snippet of the warning:
>
>  2017-09-02 20:22:50.458:WARN:oejs.HttpChannel:qtp1076835071-12: /map
> javax.servlet.ServletException: org.apache.jasper.JasperException:
> org.eclipse.jetty.io.RuntimeIOException: org.eclipse.jetty.io.EofException:
> Stream closedn.handle(HandlerCollection.java:146)
>
>  The page loads fine and the warning doesn't seem to impact the delivery
> of the web page.
>
>  We tried out in several browsers in browserstack, and only IE seems to be
> causing this.
>
>  Even more strange, browserstack running within Safari doesn't cause the
> warning, while running within Firefox it does.
>
>  Stumped. Would appreciate any pointers.
>
>  Thanks,
>
> Pankaj
>
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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] Session timeout

[Jan Bartel]

John,

Can you provide the rest of your jetty configuration as regards sessions.
Also, please run your app with debug turned on for sessions
(-Dorg.eclipse.jetty.server.session.LEVEL=DEBUG) and post that. You should
see some debug info about the maximum idle time and expiry of the session
when you create one. Here's some examples for a run with the standard jetty
test webapp, with session-timeout=60 in web.xml:

2017-09-05 12:05:05.819:DBUG:oejs.session:qtp184966243-20: setIdleTimeout
called: old=0 new=360
2017-09-05 12:05:05.830:DBUG:oejs.session:qtp184966243-15: Testing expiry
on session node06t4scaybs5j7qagd30qd1eu20: expires at 1504580705830 now
1504577105830 maxIdle 360

Is it possible that there is a filter or other application code that is
calling session.setMaxInactiveInterval() before your println?

Jan

On 5 September 2017 at 00:22, John English <john.fore...@gmail.com> wrote:

> A while ago I upgraded from Jetty 8 to Jetty 9.4. It supports a web
> application which includes a session timeout of 60 minutes in the web.xml
> (which used to work fine):
>
>   
> 60
>   
>
> However, the sessions no longer seem to be timing out at all since the
> upgrade. To investigate this, I printed out a debug message at the point
> where the session is obtained:
>
> HttpSession session = request.getSession();
> System.err.println("Session timeout: " +
>session.getMaxInactiveInterval());
>
> The result is the message "Session timeout: 1800", i.e 30 minutes.
>
> I'm completely confused as to (a) why the 60-minute timeout is not
> happening, and (b) why the timeout interval is showing up as 30 minutes
> when web.xml sets it to 60. Can anyone please help me understand this?
> --
> John English
> ___
> 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 <j...@webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*
___
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