Sean Keane

When I go to the publishers website, there is no 2017 revised version http://www.informit.com/authors/bio/e67c80b2-f367-438f-a4cb-dea867d0bec9 ?

Hi folks - I need to brush up on my concurrency knowledge. Is "Concurrency in Practice" still the go-to book?

When I go to www.amazon.co.uk I see two version of this book

https://www.amazon.co.uk/d/Books/Java-Concurrency-Practice-Brian-Goetz/0321349601
https://www.amazon.co.uk/dp/9332576521

The second version says it is published in 2017...but when I view inside the book it appears to be the same content as the 2015 version.

Is there a 2017 revised version, update with Java 8 information?

I agree it's good to have interfaces. From experience though, with significantly large applications it will not be a case that every class you want to unit test will have an interface.

Anyway. I think we are getting slightly off topic . So in summary, for this particular vulnerability, if we make the class final we are safe and if we still want to be able to mock the class for testing just ensure it has an interface to describe it's behaviour.

Technically nothing stopping me of course. Does every single class you want to unit test in applications you develop implement an interface?

I think from the feedback here and some more thinking that I don't need to worry about this security vulnerability in the context I am throwing exceptions in the constructor.

In some cases I have interfaces so the implementation can be final. But like most things in life it's a trade off; I can't have a proliferation of interfaces purely for sake of marking implementation final.

Dave Tolls wrote:All classes should be final (IMO) unless someone has to extend them..

Ideally yes, but then it makes unit testing more difficult. Requiring you to use something like Powermock to mock the final class - I'd rather not use this.

Good point. I can make some of my classes final. There's always the chance that another developer in future could remove final to subclass, unaware of why it was final. I guess I could document why it's final.

As to whether I actually need to worry about this vulnerability. Good question...

My code is running in a multithreaded environment.

Some of my classes would have direct access to the production database. So I guess these would be deemed vulnerable?

"please use exceptions to do parameter checking in your constructor." Using Objects.requireNonNull is using exceptions to do parameter checking?

When throwing an Exception from a constructor of a class in Java you are leaving yourself open to a security vulnerability.

See here https://www.securecoding.cert.org/confluence/display/java/OBJ11-J.+Be+wary+of+letting+constructors+throw+exceptions

Recently I have started to using https://docs.oracle.com/javase/7/docs/api/java/util/Objects.html#requireNonNull(T,%20java.lang.String) in methods and constructors to validate for null i.e.

class Foo {     private final Bar bar;     Foo(final Bar bar) {              this.bar = Objects.requireNonNull(bar);     } }

If the argument to the constructor is null then a NullPointerException is thrown from the constructor. So we have arrived in the situation where there is a known security vulnerability.

The article above mentions a strategy for getting around this security flaw (ensuring the Exception is thrown before the constructor of Object is finished executing).

To implement this strategy for every constructor where I want to use requireNonNull I think would be a serious overkill. So I’m wondering what I should do?

1. Don’t ever use requireNonNull to validate for non-null in the constructor
2. Use requireNonNull in the constructor in conjunction with the strategy to avoid the security vulnerability
3. Only use the strategy to avoid the security vulnerability in particular classes (not sure what the criteria would be to determine which classes), and for every other class simply use requireNonNull without this strategy

Any thoughts?

Yep, I intend moving to Tomcat 6 or 7 at a later stage. It's just that I'm working through a book at the moment which used Tomcat 5 - so I'm using it to ensure all the examples work smoothly.

I searched all the files in my Tomcat installation for references to "catalina.out". The only place I found a reference was in catalina.sh. There is no reference in catalina.bat.

Since I am running on a Windows machine and there is no reference to "catalina.out" in catalina.bat, I'm guessing that I should not expect to see the logs to ServletContext.log outputted to any file - they will only go to stdout. Does this sound correct?

Is there any way for me to configure Tomcat 5 so that it outputs the logs to ServletContext.log to a log file?

Ok, I see the logs getting output to stdout. But I don't understand what you mean by catalina.out file? Did you mean that Tomcat outputs ServletContext logs to a file called catalina.out? I searched my Tomcat installation for this file and it does not exist. I'm using Tomcat 5.5.

Where would I find official Tomcat documentation of how it handles ServletContext.log? I already search the documentation for Tomcat 5.5 and found no mention. (Just wondering how I would have figured out myself how Tomcat handles these logs).

Hi guys,

I have a simple filter that is outputing a message to a log file. I am following an example from a book. It said I should expect to see the log message in a log file. However I only see the message in the console for Tomcat, not the log file. Any ideas why?

I had a look at the documentation for Tomcat. The logging section http://tomcat.apache.org/tomcat-5.5-doc/logging.html doesn't mention anything about where the logs for ServletContext.log go? The JavaDoc for the Servlet API just says that the log method should output to a log file.

Any ideas?


Cheers,

Sean.



Here is my example:

public class LogFilter implements Filter { private FilterConfig config; private ServletContext context; private String filterName; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; this.context.log(req.getRemoteHost() + " tried to access " + req.getRequestURL() + " on " + new Date() + " (Reported by " + this.filterName + ")."); chain.doFilter(request, response); } public void init(FilterConfig fConfig) throws ServletException { this.config = fConfig; this.context = fConfig.getServletContext(); this.filterName = fConfig.getFilterName(); } public void destroy() { } }

Hi folks,

I was wondering if anyone has any information on why WebLogic does not use the distributable element in web.xml http://docs.oracle.com/cd/E14571_01/web.1111/e13712/web_xml.htm#i1044010 ?

As WebLogic does not use this element would that imply that the J2EE spec speficies that it is optional for vendors to support this element? How would I find this information out?

When you use the distributable element and run an App on a single Tomcat server (i.e. not in a cluster) it throws an exception if you attempt to add a non-serializable object to the session. So this is a good guard when developing an App on a single Tomcat server that will eventually be deployed to a cluster i.e. it will ensure that you aren't adding an non-serializable objects to the session.

I'm guessing that since WebLogic does not use this element, that adding it will not cause WebLogic to throw an execption if you add a non-serializable object to the session. Does WebLogic have some similiar way of marking the App as being suitable for running in a distributed environment, causing it throw an exception as per my example even when the App is running on a single WebLogic Server.


Cheers,

Sean

Thanks Ikpefua, confirms what I was thinking, I should ensure that my Servlet implementation is thread-safe.

Ah, I just found the answer to my question. Yes, my Servlet class definitely needs to be thread safe as multiple threads will be accessing it concurrently. Unless my Servlet implements the SingleThreadModel interface - in which case I am guaranteed that only one thread will be executing a method from my Servlet class at any particular moment in time. Sounds good?