Develop Reference

Property in IntelliJ: driver-class-name or driverClassName?

I use IntelliJ IDEA, the IntelliSense suggests the usage of assigning jdbc driver in application.properties file as
spring.datasource.driver-class-name=com.microsoft.jdbc.sqlserver.SQLServerDriver
See the image when I typing
But by the answer, that is wrong. It should be
spring.datasource.driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
However a web site related to JetBrains seems indicate that using driver-class-name might be correct.
https://youtrack.jetbrains.com/issue/IDEA-202820?_ga=2.207495315.1822682194.1613252382-718343134.1609267918
So I am confused. Which one is right? Is it a bug of IntelliJ IDEA?

Spring Boot supports both formats for properties, and they can be used interchangeably for properties defined by property binding (#ConfigurationProperties beans).
See also Relaxed Binding in the Spring Boot Features documentation:
Spring Boot uses some relaxed rules for binding Environment
properties to #ConfigurationProperties beans, so there does not need
to be an exact match between the Environment property name and the
bean property name. Common examples where this is useful include
dash-separated environment properties (for example, context-path
binds to contextPath), and capitalized environment properties (for
example, PORT binds to port).
In other words, given spring.datasource.driverClassName is defined through a #ConfigurationProperties bean, you can use both spring.datasource.driver-class-name and spring.datasource.driverClassName. The kebab-case form is the recommended form. The relaxed binding was - AFAIK - introduced in Spring Boot 2, so maybe the question you referenced was still at Spring Boot 1.x.
In any case, IntelliJ's autocomplete cannot be wrong in this case, because it uses information contained in the Spring Boot JAR files, generated by Spring Boot tools, specifically for spring.datasource.driver-class-name, this property name is obtained from META-INF/additional-spring-configuration-metadata.json in the spring-boot-autoconfigure JAR file. It is also the property listed in Common Application properties.
The Youtrack issue you listed seems to be an unrelated problem.

how to change datasource connection url dynamically in Jboss 6

I am using Jboss AS6 with container manager tracsaction.
Normally I am using a single MYSQL data source defined in mysql-ds.xml.
Now I have an user requirement that multiple users can have different database contents.So I am planning to create a new database for each user.In the future I can change my database design. But now for a quick solution, I need to find a way to crossover between different databases.
this is my default configuration. I need to change dbname
<local-tx-datasource>
<jndi-name>DefaultDS</jndi-name>
<connection-url>jdbc:mysql://144.0.0.1:3306/**dbname**</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
<user-name>root</user-name>
<password>password</password>
<max-pool-size>100</max-pool-size>
<min-pool-size>0</min-pool-size>
<connection-property name="readOnly">false</connection-property>
<autoReconnect>true</autoReconnect>
<failOverReadOnly>false</failOverReadOnly>
<maxReconnects>0</maxReconnects>
<initialTimeout>15</initialTimeout>
<idle-timeout-minutes>0</idle-timeout-minutes>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
<!-- should only be used on drivers after 3.22.1 with "ping" support
<valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker</valid-connection-checker-class-name>
-->
<!-- sql to call when connection is created
<new-connection-sql>some arbitrary sql</new-connection-sql>
-->
<!-- sql to call on an existing pooled connection when it is obtained from pool - MySQLValidConnectionChecker is preferred for newer drivers
<check-valid-connection-sql>some arbitrary sql</check-valid-connection-sql>
-->
</local-tx-datasource>
I am using Container manager transcaction.I need to find a way to change connection-url of my data source configuration.Then clear entity manager to connect new database.Is this possible

For your task you actually can just hold multiple (5 in your case) persistence contexts. Then you link to appropriate context by choosing it according to the user name for example. This is the simpliest solution. It would work but all 5 contexts would be open and hold connection. Maybe it's what you need: from one hand this context are always ready for use and don't need to be warmed.
Another option is to construct persistence conext manually like in Java SE envirionment. This can be helpful if you are not able to hold many resources and switching is not so regular (once a day. for example).
You can find a lot of articles describing how to use JPA in Java SE environment. You are able to use them nearly in the same manner (so you will not use container injection mechanism, but find Persistnece Context through raw JNDI)
https://dzone.com/articles/jpa-tutorial-setting-jpa-java
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/SettingUpJPA/SettingUpJPA.htm

I think you could use something like:
<connection-url>${connectionURL:jdbc:mysql://144.0.0.1:3306/xyz}</connection-url>
and then pas the -DconnectionURL=jdbc:mysql://144.0.0.1:3306/abc to the standalone.sh/bat

Spring Security - documentation for SPRING_SECURITY_LAST_EXCEPTION

I am working on an application using Spring Security 3.1.0. A piece of functionality that I need to modify is being driven by SPRING_SECURITY_LAST_EXCEPTION being set as an certain type of attribute. I do not see any code from my organization that is setting an attribute by this name, so I have guessed that this is being set by Spring Security.
My suspicion that it was not a name we made up was confirmed when I found many forum messages and 'how-to' blog posts referencing SPRING_SECURITY_LAST_EXCEPTION that don't address my actual issue.
I still can't say what kind of attribute it is, because I have not found any documentation of how this attribute gets set and what is properties are.
Please show me where I have failed to look in order to find the documentation explaining how this property gets set and what its attributes are.

The class WebAttributes contains a constant named AUTHENTICATION_EXCEPTION. This is used to set a request attribute or session attribute (depending if forwarding or redirecting is used) with the name of SPRING_SECURITY_LAST_EXCEPTION and value of the last AuthenticationException in SimpleUrlAuthenticationFailureHandler.
NOTES
It is generally not a good idea to use SPRING_SECURITY_LAST_EXCEPTION for error messages since it displays information an attacker can use.
I would recommend updating to Spring Security 3.2.7.RELEASE. This should be passive and will fix any vulnerabilities that are present in older versions. Eventually you should spend the time to update to Spring Security 4, but this is a little more involved since it includes some non passive changes.

Are there JNDI namespace conventions?

I have downloaded JBoss EAP 6.1 and I am going to add a new data source. I must bind the data source to a JNDI name. By reading the JNDI name of the sample data source which is:
java:jboss/datasources/ExampleDS
I see that they have used datasources after java:jboss. Is this just a naming convention - that I am not able to find anywhere - or would it be fine using java:jboss/bananaboat/MyDS?`
Is it correct that the first part that is listed below - such as java:comp is the scope and the rest is just normal hierarchy organization?
java:comp/ - The namespace is scoped to the current component (i.e. EJB)
java:module/ - Scoped to the current module
java:app/ - Scoped to the current application
java:global/ - Scoped to the application server
https://docs.jboss.org/author/display/AS71/JNDI+Reference

I had to answer the same question to myself and pulled these links together.
In short, JNDI Naming Policies can be any but JEE defines its own:
JNDI is defined independent of any specific naming and
directory service implementation.
However, one important platform that does define a limited set of
naming policies for using the JNDI is ... JEE.
This would be the most conventional name for the datasource:
The enterprise namespace is rooted in a URL context for the java URL scheme.
For example, a JDBC Salary database might have the name "java:comp/env/jdbc/Salary".
... comp is bound to a subtree reserved for component-related bindings.
... env is bound to a subtree that is reserved for the component's environment-related bindings, as defined by its deployment descriptor.
Resource factory references are placed in subtrees differentiated by their resource manager type.
...jdbc for JDBC DataSource references.
JEE 7 Tutorial also details naming policies to reference EJBs in 32.4.1.1 Portable JNDI Syntax.
Note that #Resource annotation to inject DataSource often specifies JNDI name relative to java:comp/env - see this answer or this answer for portable and deployable solutions.
As mentioned in your updated link, java:jboss namespace is a custom extension provided by WildFly/JBoss only.
To answer the question, the sub-trees under standard namespaces are just normal hierarchy. Obviously, it only makes sense if these sub-trees are (widely) recognized by application server, documentation, processes, etc. Otherwise, I guess nearly flat key-value or random bananaboat/MyDS is fine but still has to be "mounted" under supported namespace like java:jboss.

This is all from memory (I was told by another team member a while ago):
The java: prefix is a JBoss/EE standard. It should be prefixed for all non serializable resources which means they are local to the jvm. After that you can name whatever you like to form the "directory" like structure. e.g. if you use JNDI to get binding "java:jboss/datasources", you will get back a subtree of all resources listed under that name. It will contain ExampleDS and possibly other DataSources as well.
To answer your question: you don't have to name it datasources after java:jboss. But it make sense to name it something meaningful.

Understanding Persistence.xml in JPA

I am trying to understand the following things:
When I make an EJB project and deploys it to Glassfish do I set up JDBC resources/connection pools at the administrator center of Glassfish or do I add all the different properites for username, password etc in the persistence.xml? I don't understand one bit of that.
I do not understand why we have both JDBC resource and JDBC Connection pool either. What is it and what is the difference between them? Could somebody explain me these things or/and provide some good link about the persistence.xml file and the part around it?

It's better to define a JDBC resource rather than putting the information in the persistence.xml. In this way you are going to take advantage of connection pooling. You are going to define the JNDI name you provided for the JDBC resource in the persistence.xml.
What is it and what is the difference between them
Below I pasted some parts of the Glassfish 3.x help. Check it out. It's really helpful
JDBC connection pool
A JDBC connection pool contains a group of JDBC connections that are created when the connection pool is registered
JDBC resource
A Java DataBase Connectivity (JDBC) resource (data source) provides applications with the means of connecting to a database. Typically, the administrator creates a JDBC resource for each database accessed by the applications deployed in a domain; however, more than one JDBC resource can be created for a database.
Applications get a database connection from a connection pool by looking up a data source on the Java Naming and Directory Interface (JNDI) API tree and then requesting a connection. The connection pool associated with the data source provides the connection to the application.
Think of the data source(JDBC) resource as a factory for a facade of some type of data service(Connection Pool). In this case it implicitly gets a connection from the pool and provides it to your application.
An example persistence.xml:
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="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">
<persistence-unit name="WebApplication2PU" transaction-type="JTA">
<jta-data-source>jdbc/sample</jta-data-source>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties/>
</persistence-unit>
</persistence>
This line is the JNDI name I gave to my JDBC resourse:
<jta-data-source>jdbc/sample</jta-data-source>
You dont need to define anything related to the database connection in your persistence.xml this way...just the JNDI name of the resource

When you configure a data source in your application server, all you need to set in persistence.xml is the JNDI name of that data source.

I found this in the book that I read to learn Spring and Hibernate. The book name is Professional Java for Web Applications written by Nicholas S. Williams. I think this will be helpful for many people.
Creating the Persistence Configuration:
To use the entities you create, you must define a persistence unit. Doing so is simple. Create a
persistence.xml file not dissimilar from a deployment descriptor, but with far fewer options
to worry about. The root element of a persistence configuration file is <persistence>. This
element may contain one or more <persistence-unit> elements. No other elements are
within <persistence>. <persistence-unit> has two attributes: name specifies the name of
the persistence unit and transaction-type indicates whether this persistence unit uses Java
Transaction API (JTA) transactions or standard local transactions.
You must specify a name, which is how you locate the persistence unit in code. If not specified,
transaction-type defaults to JTA in a Java EE application server and RESOURCE_LOCAL in a Java
SE environment or simple Servlet container. However, to prevent unexpected behavior it’s best to
always set this value explicitly instead of relying on a default value.
<persistence-unit> contains the following inner elements. None of them are required (so
<persistence-unit> may be empty); however, you must specify whichever elements you use in the
following order:
<description> contains a useful description for this persistence unit. Although it makes
reading the persistence file easier, it has no semantic value.
<provider> specifies the fully qualified class name of the javax.persistence.spi
.PersistenceProvider implementation used for this persistence unit. By default, when you
look up the persistence unit, the API will use the first JPA provider on the classpath. You
can include this element to mandate a specific JPA provider.
You can use either <jta-data-source> or <non-jta-data-source> (but not both) to
use a JNDI DataSource resource. You may use <jta-data-source> only if
transaction-type is JTA; likewise you may use <non-jta-data-source> only
if transaction-type is RESOURCE_LOCAL. Specifying a DataSource causes the persistence
unit to use that DataSource for all entity operations.
<mapping-file> specifies the classpath-relative path to an XML mapping file. If you don’t
specify any <mapping-file>, the provider looks for orm.xml. You may specify multiple
<mapping-file> elements to use multiple mapping files.
You can use one or more <jar-file> elements to specify a JAR file or JAR files that the
JPA provider should scan for mapping-annotated entities. Any #Entity, #Embeddable,
#javax.persistence.MappedSuperclass, or #javax.persistence.Converter classes
found are added to the persistence unit.
You can use one or more <class> elements to indicate specific #Entity, #Embeddable,
#MappedSuperclass, or #Converter classes that should be added to the persistence unit.
You must annotate the class or classes with JPA annotations.
Using <exclude-unlisted-classes /> or <exclude-unlisted-classes>true</exclude-unlisted-classes> indicates that the provider should ignore classes not
specified with <jar-file> or <class>. Omitting <exclude-unlisted-classes> or using
<exclude-unlisted-classes>false</exclude-unlisted-classes> causes the JPA
provider to scan the classpath location of the persistence file for JPA-annotated classes. If
persistence.xml is located in a JAR file, that JAR file (and only that JAR file) is scanned
for classes. If persistence.xml is located in a directory-based classpath location (such as /
WEB-INF/classes), that directory (and only that directory) is scanned for classes. Prior to
Hibernate 4.3.0 and Spring Framework 3.2.5, specifying this element with the value false
was incorrectly interpreted as true.
<shared-cache-mode> indicates how entities are cached in the persistence unit (if the JPA
provider supports caching, which is optional). NONE disables caching, whereas ALL enables
caching for all entities. ENABLE_SELECTIVE means that only entities annotated #javax
.persistence.Cacheable or #Cacheable(true) (or marked as cacheable in orm.xml)
are cached. DISABLE_SELECTIVE results in caching of all entities except those annotated
#Cacheable(false) (or marked as non-cacheable in orm.xml). The default value,
UNSPECIFIED, means that the JPA provider decides what the effective default is. Hibernate
ORM defaults to ENABLE_SELECTIVE, but relying on this is not portable.
<validation-mode> indicates if and how Bean Validation should be applied to entities.
NONE means that Bean Validation is not enabled, whereas CALLBACK makes the provider
validate all entities on insert, update, and delete. AUTO has an effective value of CALLBACK
if a Bean Validation provider exists on the classpath and an effective value of NONE if no
Bean Validation provider exists on the classpath. If you enable validation, the JPA provider
configures a new Validator to validate your entities. If you have configured a special
Spring Framework Validator with your custom localized error codes, the JPA provider
ignores it. As such, it’s best to set the validation mode to NONE and use Bean Validation
before your persistence layer is invoked.
<properties> provides a way to specify other JPA properties, including standard JPA
properties (such as JDBC connection string, username, and password, or schema generation
settings) as well as provider-specific properties (such as Hibernate settings). You specify
one or more properties using nested elements, each with a name and value
attribute.
Nicholas S. Williams, Professional Java for Web Applications, (Indianapolis, Indiana: John Wiley & Sons, Inc., 2014), pg 584-585