2019-08-28

No PersistenceProvider - Caused by: java.lang.IllegalArgumentException: No PersistenceProvider specified in EntityManagerFactory configuration, and chosen PersistenceUnitInfo does not specify a provider class name either











Change the emf bean configuration and add a new bean called jpaVendorAdapter:
<bean class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean" id="emf">
  <property name="packagesToScan" value="com.medsoft.stadto.entity" />
  <property name="dataSource" ref="dataSource" />
  <property name="jpaVendorAdapter" ref="jpaVendorAdapter"/>
  <property name="persistenceUnitName" value="stadto"/>
  <property name="jpaProperties">
    <props>
      <prop key="hibernate.show_sql">true</prop>
      <prop key="hibernate.hbm2ddl.auto">create</prop>
    </props>
  </property>
</bean>

<bean id="jpaVendorAdapter" class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
  <property name="showSql" value="true"/>
  <property name="generateDdl" value="true"/>
  <property name="databasePlatform" value="org.hibernate.dialect.PostgreSQLDialect"/>
</bean>
Also make sure you have a persistence.xml in the META-INF directory:
<?xml version="1.0"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence
  http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
  version="2.1">
  <persistence-unit name="stadto">
    //No need to specify the provider as we already have specified JPA vendor in applicationContext.xml
  </persistence-unit>
</persistence>






To remove persistence.xml, refer to: https://billson.blogspot.com/2019/08/caused-by-javalangillegalstateexception.html







Caused by: java.lang.IllegalStateException: No persistence units parsed from {classpath*:META-INF/persistence.xml}






Reference URL: https://www.baeldung.com/the-persistence-layer-with-spring-and-jpa


5. Going Full XML-less

Usually, JPA defines a persistence unit through the META-INF/persistence.xml file. Starting with Spring 3.1, the persistence.xml is no longer necessary. The LocalContainerEntityManagerFactoryBean now supports a packagesToScan' property where the packages to scan for @Entity classes can be specified.
This file was the last piece of XML we need to remove. We can now set up JPA fully with no XML.
We would usually specify JPA properties in the persistence.xml file. Alternatively, we can add the properties directly to the entity manager factory bean:
factoryBean.setJpaProperties(this.additionalProperties());
As a side-note, if Hibernate would be the persistence provider, then this would be the way to specify Hibernate specific properties.







add this into your servlet context.xml

<property name="packagesToScan" value="com.howtodoinjava.entity" />








Migrate Spring Security From 3 to 4, deprecated: org.springframework.security.core.authority.GrantedAuthorityImpl




Found URL: https://docs.spring.io/spring-security/site/migrate/current/3-to-4/html5/migrate-3-to-4-xml.html#m3to4-deprecations-core-gai


4.5.10. GrantedAuthorityImpl

GrantedAuthorityImpl was removed in favor of SimpleGrantedAuthority or implementing your own. For example:
new GrantedAuthorityImpl(role);
should be replaced with
new SimpleGrantedAuthority(role);






2019-08-27

maven deploy with eclipse



Add below to your settings.xml for global or user_settings.xml for personalized user id for access control.

<server>
<id>snapshots</id>
<username>user_one</username>
<password>password1</password>
</server>
<server>
<id>releases</id>
<username>user_two</username>
<password>password2</password>
</server>


Add below to your project/pom.xml


<distributionManagement>
<snapshotRepository>
<id>snapshots</id>
<name>Snapshots Repository</name>
<url>http://company-private-repo.com/apache-archiva-2.2.4/repository/snapshots</url>
</snapshotRepository>
<repository>
<id>releases</id>
<name>Releases Repository</name>
<url>http://company-private-repo.com/apache-archiva-2.2.4/repository/releases/</url>
</repository>
</distributionManagement>


Eclipse Run As: Maven build, goal as deploy.


Reference: 
https://maven.apache.org/repository-management.html







Alternative:






Info below from stackoverflow:

I want the jar to be in a 3rdparty lib in source control, and link to it by relative path from the pom.xml file.

If you really want this (understand, if you can't use a corporate repository), then my advice would be to use a "file repository" local to the project and to not use a system scoped dependency. The system scoped should be avoided, such dependencies don't work well in many situation (e.g. in assembly), they cause more troubles than benefits.

So, instead, declare a repository local to the project:

<repositories>
  <repository>
    <id>my-local-repo</id>
    <url>file://${project.basedir}/my-repo</url>
  </repository>
</repositories>

Install your third party lib in there using install:install-file with the localRepositoryPath parameter:




Update: It appears that install:install-file ignores the localRepositoryPath when using the version 2.2 of the plugin. However, it works with version 2.3 and later of the plugin. So use the fully qualified name of the plugin to specify the version:

mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file \
                         -Dfile=<path-to-file> -DgroupId=<myGroup> \ 
                         -DartifactId=<myArtifactId> -Dversion=<myVersion> \
                         -Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>

maven-install-plugin documentation

Finally, declare it like any other dependency (but without the system scope):

<dependency>
  <groupId>your.group.id</groupId>
  <artifactId>3rdparty</artifactId>
  <version>X.Y.Z</version>
</dependency>

This is IMHO a better solution than using a system scope as your dependency will be treated like a good citizen (e.g. it will be included in an assembly and so on).

Now, I have to mention that the "right way" to deal with this situation in a corporate environment (maybe not the case here) would be to use a corporate repository.