Bear Bibeault wrote:A 3rd edition is being planned, but there's no announced availability date.
Everything in the 2nd edition is still very relevant for today's JS.
Tim Moores wrote:For additional ideas you could also study the source code of a mature Java blog platform such as http://pebble.sourceforge.net/. It supports multiple blogs as well as multiple contributors per blog.
Stephan van Hulst wrote:I believe Wildfly just uses the standard Java EE security mechanisms. You can read more about those here: https://docs.oracle.com/javaee/7/tutorial/partsecurity.htm
I believe chapter 47 will explain how to add users, groups and roles to your application, and chapter 49 will explain how to authorize certain users, groups or roles to access methods in your application.
Stephan van Hulst wrote:Typically this is done by middleware in the request processing pipeline of your web application framework. Most web application frameworks have already implemented this middleware. For instance, Spring has the Spring Security project which includes in-memory authentication.
What framework are you using to develop your web application?
Rob Spoor wrote:Ignore any JBoss/WildFly specific configuration. You're trying to run a unit test, and that has (more or less) the same rules as a standalone JSE application.
Last time I had to unit test my database code, I simply used a second persistence.xml (in src/test/resources/META-INF) with its own persistence unit name, and used that. This one was mostly identical, except:
1) the transaction-type was RESOURCE_LOCAL instead of JTA.
2) there was no data source, but properties for connecting instead (you already have those).
3) classes were included instead of relying on automatic discovery.
Campbell Ritchie wrote:By no means an easy subject. I know that foo(int...) and foo(int[]) are regarded as equivalent to each other, so they are not permissible together. That sounds like a mistake in the Java™ Tutorials, so I shall send you to the Java® Language Specification (=JLS) here. Beware: The JLS is often difficult to read.
The Java programming language supports overloading methods, and Java can distinguish between methods with different method signatures. This means that methods within a class can have the same name if they have different parameter lists (there are some qualifications to this that will be discussed in the lesson titled "Interfaces and Inheritance").
Campbell Ritchie wrote:
Remove the top three lines, which only appear to be duplicates of lines 4‑6.
Campbell Ritchie wrote:
I think you should restore the PATH in /etc/environment.
Campbell Ritchie wrote:
How did you install Java®?
Campbell Ritchie wrote:
In a fit of desperation I shall suggest a couple of things, but we really are scraping the bottom of the barrel here:-1: cd / then sudo grep -R "CLASSPATH=" * which should find any files where you have set a CLASSPATH and forgotten. 2: export CLASSPATH=~/Documents:$CLASSPATH:~/Documents then echo $CLASSPATH
That will really mess up your CLASSPATH, but if you set it at the terminal, it won't affect other terminals. See whether you have somehow got the CLASSPATH set to whitespace only.