Spring Boot JNDI not found - can't compile WAR with Maven - java

i can't mvn clean install my project.
I need to use a remote JNDI in WAR(not jar), but having the name in application.properties throws error during mvn clean install(due to "datasource jndi name not found")
if I have to use jndi name from a remote server, that I have no control over, how do i compile my package in WAR without lookup fail, but let it look up during the deployment/installation of the app on the server? any hint, or direction is very much appreicated...
in app prop, i have
spring.datasource.jndi-name=jdbc/ff-app
I have tried: Spring boot JNDI datasource lookup failure - Name comp/env/jdbc not found in context "java:"
tried, http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#boot-features-connecting-to-a-jndi-datasource
and pretty much every questions asked in stackoverflow about a remote jndi..
Some of the errors:
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [javax.sql.DataSource]: Factory method 'dataSource' threw exception; nested exception is org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Failed to look up JNDI DataSource with name 'jdbc/ff-app'; nested exception is javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:189) ~[spring-beans-4.3.6.RELEASE.jar:4.3.6.RELEASE]
at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:588) ~[spring-beans-4.3.6.RELEASE.jar:4.3.6.RELEASE]
... 69 common frames omitted
Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Failed to look up JNDI DataSource with name 'jdbc/ff-app'; nested exception is javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
at org.springframework.jdbc.datasource.lookup.JndiDataSourceLookup.getDataSource(JndiDataSourceLookup.java:48) ~[spring-jdbc-4.3.6.RELEASE.jar:4.3.6.RELEASE]
at org.springframework.boot.autoconfigure.jdbc.JndiDataSourceAutoConfiguration.dataSource(JndiDataSourceAutoConfiguration.java:62) ~[spring-boot-autoconfigure-1.5.1.RELEASE.jar:1.5.1.RELEASE]
at org.springframework.boot.autoconfigure.jdbc.JndiDataSourceAutoConfiguration$$EnhancerBySpringCGLIB$$9509801a.CGLIB$dataSource$0() ~ ........
My POM.xml
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.5.1.RELEASE</version>
<relativePath /> <!-- lookup parent from repository -->
</parent>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<java.version>1.8</java.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
</dependency>
</dependencies>

The point is that when you try to compile by using maven, maven tries to execute also Junit tests; in your case you have in src/resources/java some unit tests and so maven tries to execute them. Since you are using a JNDI datasource, it means that also the servlet container must be active for executing tests otherwise you can't get connection.
In this case when maven tries to execute tests maybe no servlet container (and, so, no JNDI datasource) is active and your test throws error.
To solve this (and to compile the maven artifact) you must:
or exclude tests execution: this is done by adding <maven.test.skip>true</maven.test.skip> in pom.xml. No test will be executed
or ignore tests error this is done by adding <maven.test.failure.ignore>true</maven.test.failure.ignore> in pom.xml. In this case tests will be executed but any test error will not stop maven compilation
The configuration I gave not only tells maven to not execute tests but it tells maven to not stop on any test error
I hope i have been clearer... my english is not the best

Related

Spring core/beans 5.3.18 upgraded project won't start - Autowired and Bean annotations crashing

here's the error:
SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class [com.mycompany.chassis.engine.core.web.listener.ChassisContextLoaderListener]
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'chassisApiSpringConfig': Unsatisfied dependency expressed through field 'sdpLoggingOn'; nested exception is org.springframework.beans.TypeMismatchException: Failed to convert value of type 'java.lang.String' to required type 'boolean'; nested exception is java.lang.IllegalArgumentException: Invalid boolean value [false,false]
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:659)
so I upgraded to spring-beans 5.3.18, got the above error, thought I was slick and upgraded spring-core to match the version of spring-beans and I still get this error.
I have like 4 separate pom files, please direct me to how I can give you the best info to help me through this. Would upgrading spring-web to the same version help or is it something else entirely? It feels like Spring Beans doesn't recognize #Value anymore? Here's the line it's complaining about.
#Value("${sdp.logging.on:false}")
private boolean sdpLoggingOn;
Here's the imports I currently have:
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
Maybe Autowired and Value aren't in the factory anymore now with the upgrade?
Add the spring framework bom to your dependencyManagement section to keep all the spring framework jars at the same version.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>${spring.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
With multiple pom files, in my experience, it works best to have them share a common parent pom which manages the dependencies.

Method org/hibernate/cache/ehcache/EhCacheRegionFactory.start(Lorg/hibernate/boot/spi/SessionFactoryOptions;Ljava/util/Map;)V is abstract

I am trying to configure hibernate without using the hibernate.cfg.xml file and using annotations instead. It works fine until I activate the second level cache to access statistics like hit, fetch and miss count.
When I set the option use_second_level_cache to true I get the following error:
Caused by: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'getSessionFactory' defined in class
path resource
[myPath/hibernate/config/HibernateConfiguration.class]:
Invocation of init method failed; nested exception is
java.lang.AbstractMethodError: Method
org/hibernate/cache/ehcache/EhCacheRegionFactory.start(Lorg/hibernate/boot/spi/SessionFactoryOptions;Ljava/util/Map;)V
is abstract
Here's the relevant configurations lines:
properties.put(USE_SECOND_LEVEL_CACHE, true);
properties.put(CACHE_REGION_FACTORY, "org.hibernate.cache.ehcache.EhCacheRegionFactory");
and (part of) my pom:
<hibernate.version>5.2.10.Final</hibernate.version>
...
<!-- Hibernate Core -->
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>${hibernate.version}</version>
</dependency>
<!-- Hibernate Ehcache -->
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>${hibernate.version}</version>
</dependency>
I initially thought of a version issue or conflicting jars, but can't seem to spot the issue. Any help would be appreciated.
Changing the project made the issue vanish.

Parameter 0 of constructor in ..RoleService required a bean named 'entityManagerFactory' that could not be found

I'm trying to create a basic spring boot application and when I try to implement a repository i keep getting this error:
Description:
Parameter 0 of constructor in com.frana.taskme.services.RoleService required a bean named 'entityManagerFactory' that could not be found.
Action:
Consider defining a bean named 'entityManagerFactory' in your configuration.
I've used all kind of Annotations in the Application.java and all kind of properties and nothing changes.
This is my repository where you can find the app: https://github.com/franagibo/test
Is there some problem with the dependencies of the pom?
Update your pom.xml jpa dependency from:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
</dependency>
to
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
Remove from application.propertiesspring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
Dont forget to update the dependencies, you might need to clean m2/repository.
you are excluding the autoconfiguration on your application.properties
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
which means you have to manually define your DataSource, SessionFactory, EntityManager ...

Why dependency order in POM impacts to bean visibility

I'm trying to wire up one component to existing system. To do that I included dependency to my component (DataFilter) into main project POM file.
Order 1)
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>DataFilter</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>CommandHandler</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
Such order (only dependencies in POM file; no import calls) cause that system during start pre-instantiate following beans:
from main app (blueprint.xml)
[activemq,parser,rawStorage,commandDAO,CommandService,payloadStorage,payloadRetrieval,rawReply,rawRetrieval,template,consumerTemplate,app-context:beanPostProcessor,app-context];
from component DataFilter
[filters,hdop_filter_pass_less_than_4,vdop_filter_pass_less_than_4,speed_filter_pass_less_than_high_speed,event_and_gps_time_diff_less_than_exp_time,fix_type_recomended_to_3dfix,always_pass_when_motion_or_stationary]
and don't see the bean iCommandService what cause that rawReply in main app can not be created
Exception encountered during context initialization - cancelling refresh attempt
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'rawReply' defined in class path resource [OSGI-INF/blueprint/packaging-jar-camel-context-xml.txt]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.company.product.CommandHandler.InitialClass]: Constructor threw exception; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'iCommandService' is defined
When I switch the dependencies to order 2) (CommandHandler first)
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>CommandHandler</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>DataFilter</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
Following behaviour appear:
main app still pre-instantiate beans as above
[activemq,parser,rawStorage,commandDAO,CommandService,payloadStorage,payloadRetrieval,rawReply,rawRetrieval,template,consumerTemplate,app-context:beanPostProcessor,app-context]
component command handler (which beans wasn't visible in order 1)) pre-instantiate its beans
[iCommandService,commandDAO]
component data filter is not even mentioned during setting up the camel context; no pre-instantiating of data filter beans, no errors about missing beans.
camel context starts and built routes properly
Additionally
Command Handler and Data Filter keep its contexts in Beans.xml
Main app in blueprint.xml (or packaging-jar-camel-context-xml.txt when build as jar, not bundle)
Data Filer is compilable as OSGi bundle
No autowire is used
The questions are:
why the dependecies order influance on visibility or not creating beans
how to set it properly to achive the moment when all beans for all three components are created properly?

weblogic 12c deployment failure

I'm migrating from Weblogic 11g to 12c, during the deployment process it fails and shows the following error:
Caused by: weblogic.application.naming.ReferenceResolutionException: [J2EE:160199]Error resolving ejb-ref "ejb/BizRuleFacade" from module "BizAgi-ejb.jar" of application "BizAgi-ear-Weblogic". The ejb-ref does not have an ejb-link and the JNDI name of the target bean has not been specified. Attempts to automatically link the ejb-ref to its target bean failed because multiple EJBs in the application were found to implement the "BizAgi.bpm.rules.entities.BizRuleFacade" interface, including BizAgi-war.war/BizRuleFacadeBean, BizAgi-ejb.jar/BizRuleFacadeBean. Specify a qualified ejb-link for this ejb-ref to indicate which EJB is the target of this ejb-ref.
My web.xml file looks like this:
<ejb-local-ref>
<ejb-ref-name>ejb/BAScopeLogFacade</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local>BizAgi.PAL.historylog.entities.BAScopeLogFacade</local>
<ejb-link>BizAgi-ejb.jar#BAScopeLogFacadeBean</ejb-link>
</ejb-local-ref>
The BizAgi-ejb.jar is a module inside the ear (BizAgi-ear-Weblogic.ear).
How can i properly deploy my application?
Thank you so much everybody, I've finally found the solution, it is to simply delete/remove the META-INF/MANIFEST.MF file from the .war file. That way the EJBs aren't double referenced.
1.Add below dependency in Ear Pom.xml
<dependency>
<groupId>com.example</groupId>
<artifactId>ejbModel</artifactId>
<version>1.0-SNAPSHOT</version>
<type>ejb</type>
</dependency>
2.In Ear pom.xml in modules add ejb module
<modules>
<ejbModule>
<groupId>com.example</groupId>
<artifactId>ejbModel</artifactId>
<bundleFileName>ejbModel-1.0-SNAPSHOT.jar</bundleFileName>
</ejbModule>
.......
</modules>
3.Change scope of ejbmodel dependency to provided in application pom.xml
<dependency>
<groupId>com.example</groupId>
<artifactId>ejbModel</artifactId>
<version>1.0-SNAPSHOT</version>
<type>jar</type>
<scope>provided</scope>
</dependency>
4.add persistence.xml of ejbmodel application to resource folder
Make sure that the same EJBs are not loaded multiple times in your deployment. You can check this by using the weblogic console (AdminServer) and checking the EJBs of the deployment (by clicking the little "+" sign next to the deployment that is failing int the deployments overview).
In my case I had to fix the maven dependencies (by setting one dependency of one project to "provided") so that it did not load the same EJB twice.
ERROR:
weblogic.management.DeploymentException: weblogic.application.naming.ReferenceResolutionException: [J2EE:160199]Error resolving ejb-ref "com.xxx.xxx.xxx.xxx.xxx.xxx.XXXX/xxxRemote" from module
"XXX-X.X.X.war" of application "XXX-X.X.X". The ejb-ref does not have an ejb-link and the JNDI name of the target Bean has not been specified.
SOLUTION:
1 SOLUTION: pom.xml (Web Project)
<dependencies>
<dependency>
<groupId>co.xx.cxxxx</groupId>
<artifactId>xxxxx-ejb</artifactId>
<version>1.0</version>
<type>ejb</type>
<scope>provided</scope>
</dependency>
<dependencies>
2 SOLUTION: Delete xxxxx-ejb.jar
xxxx.ear > xxxx.war > WEB-INF > lib > xxx-ejb.jar [remove]
3 Conclusion:
This is because there is a double reference to the ejb.jar, therefore the best way to control this is by saying in pom (web) that the is of type EJB, in order to take the (ejb.jar ) from the parent (EAR, where the ejb module is added).
I hope to be of help

Categories

Resources