Re: java 10 with jpa eclipselink and tomcat 9

2018-04-10 Thread Riccardo Cohen
For your information, the problem with java 10 have been solved with 
org.eclipse.persistence:org.eclipse.persistence.jpa:2.7.2-SNAPSHOT


I can now run my server application with Java 10
Thanks

On 02/04/2018 16:02, Riccardo Cohen wrote:

Hello
Is there anybody that tried to use Java 9 or 10 ?
Thanks

On 29/03/2018 11:42, Riccardo Cohen wrote:

Hello
I'm using Tomcat 9.0.6 with java 1.8 and EclipseLink 
org.eclipse.persistence:org.eclipse.persistence.jpa:2.7.1


This works fine !

I try to migrate to java 10:
JAVA_VERSION="10"
JAVA_VERSION_DATE="2018-03-20"
downloaded into my mac today from 
https://download.java.net/java/GA/jdk10/10/binaries/openjdk-10_osx-x64_bin.tar.gz


I had to add 2 libraries :
    javax.activation:activation:1.1.1
    javax.xml.bind:jaxb-api:2.3.0

The server succeded to launch. But at launch time I have the info :

/[EL Warning]: metamodel: 2018-03-28 13:55:44.159--The collection of 
metamodel types is empty. Model classes may not have been found during 
entity search for Java SE and some Java EE container managed 
persistence units.  Please verify that your entity classes are 
referenced in persistence.xml using either  elements or a 
global false element/


With java 10, the persistence.xml seems to be ignored. This is the 
content of the file :


http://java.sun.com/xml/ns/persistence;
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence 
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd;

    version="2.0">
    
org.eclipse.persistence.jpa.PersistenceProvider
        Data.E5User
        Data.E5Witem
        
            value="java:comp/env/jdbc/wfdb"/>


Re: Virtual directories, PostResources, and DefaultServlet

2018-04-10 Thread tomcat

Hi.

On 10.04.2018 15:53, Christopher Schultz wrote:

All,

I've been asked to take some static files we already have on our
(reverse-proxied) web servers and require authentication before allowing
the resources to be fetched by a client.

One way to do that would be to physically (electronically?) move the
files from the web servers to the application servers, either as a part
of the web application itself (tricky due to licensing issues of these
documents) or as a separate set of files in an arbitrary place on the
disk e.g. using .

Before I do that, I was thinking that maybe I could point
 at a (private) URL that points back to the location
where these files were already available. I was kind of hoping that
simply doing http://static/files/here/;
webAppMount="/static" /> or something like that.

It looks like the existing WebResourceSet implementations are all
disk-based resource providers.

It also seems like writing a simple, read-only, "non-listable"
implementation of an HTTPResourceSet might work for me.

So I'm looking for opinions on what I should do, here. I might be able
to hack-together an HttpResourceSet, but it probably won't benefit from
e.g. range-requests (the files I am serving are PDFs, which often
benefit from being able to perform range-requests) and might be fragile.

I could move the files to the application servers, but then I need to
make that a part of my app-server build process and I'd like that to
remain as simple as possible.

Finally, the files cannot go into revision-control due to licensing
restrictions, so we basically have to keep them ... "safe" until they
are deployed.

Any ideas or suggestions?



I know that when you have a hammer, everything looks like a nail but why not set up a 
separate Apache httpd webserver for these things, and have your reverse-proxies direct the 
calls there for them ?

Or, use URLRewriteFilter to redirect these calls to wherever you want.
I'm saying that because it doesn't really sound like you want to mix this up too much with 
your Java apps..




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Virtual directories, PostResources, and DefaultServlet

2018-04-10 Thread Woonsan Ko
On Tue, Apr 10, 2018 at 9:53 AM, Christopher Schultz
 wrote:
> All,
>
> I've been asked to take some static files we already have on our
> (reverse-proxied) web servers and require authentication before allowing
> the resources to be fetched by a client.
>
> One way to do that would be to physically (electronically?) move the
> files from the web servers to the application servers, either as a part
> of the web application itself (tricky due to licensing issues of these
> documents) or as a separate set of files in an arbitrary place on the
> disk e.g. using .
>
> Before I do that, I was thinking that maybe I could point
>  at a (private) URL that points back to the location
> where these files were already available. I was kind of hoping that
> simply doing http://static/files/here/;
> webAppMount="/static" /> or something like that.
>
> It looks like the existing WebResourceSet implementations are all
> disk-based resource providers.
>
> It also seems like writing a simple, read-only, "non-listable"
> implementation of an HTTPResourceSet might work for me.
>
> So I'm looking for opinions on what I should do, here. I might be able
> to hack-together an HttpResourceSet, but it probably won't benefit from
> e.g. range-requests (the files I am serving are PDFs, which often
> benefit from being able to perform range-requests) and might be fragile.
>
> I could move the files to the application servers, but then I need to
> make that a part of my app-server build process and I'd like that to
> remain as simple as possible.
>
> Finally, the files cannot go into revision-control due to licensing
> restrictions, so we basically have to keep them ... "safe" until they
> are deployed.
>
> Any ideas or suggestions?

How about Reverse Proxy Servlet Filter?
- http://portals.apache.org/applications/webcontent2/reverse-proxy-module.html

Regards,

Woonsan

>
> Thanks,
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Virtual directories, PostResources, and DefaultServlet

2018-04-10 Thread Christopher Schultz
All,

I've been asked to take some static files we already have on our
(reverse-proxied) web servers and require authentication before allowing
the resources to be fetched by a client.

One way to do that would be to physically (electronically?) move the
files from the web servers to the application servers, either as a part
of the web application itself (tricky due to licensing issues of these
documents) or as a separate set of files in an arbitrary place on the
disk e.g. using .

Before I do that, I was thinking that maybe I could point
 at a (private) URL that points back to the location
where these files were already available. I was kind of hoping that
simply doing http://static/files/here/;
webAppMount="/static" /> or something like that.

It looks like the existing WebResourceSet implementations are all
disk-based resource providers.

It also seems like writing a simple, read-only, "non-listable"
implementation of an HTTPResourceSet might work for me.

So I'm looking for opinions on what I should do, here. I might be able
to hack-together an HttpResourceSet, but it probably won't benefit from
e.g. range-requests (the files I am serving are PDFs, which often
benefit from being able to perform range-requests) and might be fragile.

I could move the files to the application servers, but then I need to
make that a part of my app-server build process and I'd like that to
remain as simple as possible.

Finally, the files cannot go into revision-control due to licensing
restrictions, so we basically have to keep them ... "safe" until they
are deployed.

Any ideas or suggestions?

Thanks,
-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [EXTERNAL] Using CLIENT-CERT

2018-04-10 Thread Mark Thomas
On 9 April 2018 23:29:43 BST, Amit Pande  wrote:
>Some more debugging here and I got some stuff working here.
>
>Only one question:
>
>It is not really clear from the documentation of "clientAuth"
>
>"Set to true if you want the SSL stack to require a valid certificate
>chain from the client before accepting a connection. Set to want if you
>want the SSL stack to request a client Certificate, but not fail if one
>isn't presented. A false value (which is the default) will not require
>a certificate chain unless the client requests a resource protected by
>a security constraint that uses CLIENT-CERT authentication. See the SSL
>HowTo for an example. That SSL HowTo also contains tips on using
>per-user or per-session certificate-based clientAuth."
>
>So, if I am using a clientAuth="false" and relying on "CLIENT-CERT"
>configuration, does that mean browsers won't prompt users to supply the
>certificate when a protected resource is accessed?

In that scenario the browser will prompt the user for a certificate if 
everything is correctly configured.

However, it is possible that the browser will determine that it has no matching 
certificates and therefore decide not to display the certificate prompt.

Mark

>
>Is it because in case of "CLIENT-CERT", the client is always expected
>to supply a certificate?  If yes, is there any recommended practice to
>configure browser for this? Or application needs to take care of
>supplying one when accessing such a protected resource?
>
>Appreciate your inputs.
>
>
>
>On 4/8/18, 6:44 PM, "Amit Pande"  wrote:
>
>I am trying to setup Tomcat (8.5.28) and the web-app correctly in order
>to get the mutual authentication (using client certificates) done but
>only for some recourses and not all.
>
>For instance, I have a “authenticate” API for which I want to enable
>the client certificate authentication.  So, I want only a
>“/authenticate” URL to ask for a client certificate from the browser.
>
>I want to first validate if this client certificate is issued by a
>trusted CA. If yes, accept the request and invoke the “/authenticate”
>business logic which further validates the certificate/user against our
>own user database.
>
>Looking at Tomcat documentation “clientAuth=want” in server.xml seemed
>a potential option but the issue with that is when this results in
>asking for user certificate for all the URLs being invoked from the
>Browser (unless we tell Browser to remember the decision). Also, this
>approach results in renegotiation for every request.
>
>This is when I came across, “CLIENT-CERT” alternate, which can be
>configured only for certain URL (e.g. “/authenticate” in my case).
>However, I am not able to get it configured as expected. I issued a
>client certificate and imported in browser but still unable to get the
>browser pop-up which asks for the certificate to be sent. Debugging SSL
>level did not yield much.
>
>https://stackoverflow.com/questions/41438536/protecting-webresource-in-tomcat-8-5-with-client-cert
>
>This is the link that closely matches the requirement and I saw Chris’
>input there. However,
>
>
>“Realm className="org.apache.catalina.realm.UserDatabaseRealm"
>allRolesMode="authOnly"
>resourceName="UserDatabase" />
>“
>In server.xml
>
>And
>
>
>
>
>  
>
>My Secure Area
>
>/authenticate
>
>  
>
>  
>
>CONFIDENTIAL
>
>  
>
>  
>
>  *
>
>  
>
>
>
>In my web app’s web.xml.
>
>When I access the URL from browser, I expected to see a dialog asking
>for client-certificate and then a successful invocation of the
>“/authenticate”. However, from browser, I don’t get a pop-up and I get
>a HTTP 401 with below message.
>
>
>Message Cannot authenticate with the provided credentials
>
>Description The request has not been applied because it lacks valid
>authentication credentials for the target resource.
>
>
>Appreciate your help on this.
>
>Thanks,
>Amit
>
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>>


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org