Creating Spring Service that reads a file and serve queries based on its data - spring

In a Java Web Project with Spring and JSF, I want do this: I want to have a service that in the first run of the app, reads a file and puts its data to a variable. then other classes can read that variable.
In fact I want that file reads one time and after that I just query the data, even web pages changed via links and navigation system.
Is there a Spring annotation to turn class to a service like this? Should I have some XML config files to specify a class as a service? I don't know what I have to do. What I know is that it can be done via Spring and I can get its data from JSF components, but how?
I have to do this based on MVC.

You can have it lazy-loaded on first call of the service. Or you can add a ContextListener to initialize the service on startup of the web context, assuming you are deploying to a J2EE container. Or you can make that service a spring bean with an init-method that initializes the data. Or any one of a hundred different ways. You'll need to determine what works best for your application.
Here's a spring example:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
<bean id="myService"
class="org.your.Service"
init-method="initializeData"></bean>
</beans>
How you get hold of that service is up to you. You can either have the data stored statically on the class, or you can use the spring context to retrieve this single instance of the spring bean.
Spring documentation for lifecycle methods: http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-factory-lifecycle

Related

Insert data by mobile application and web application throws duplicated entry exception

I have an existing web application developed with JSF 2.0 for the view layer and Spring 3 for data access, service and security layers. Then I tried to create the mobile application so I used a Spring #controller class to listen on ws requests but the problem is that when I insert data by mobile application and web application a duplicated entry exception was thrown. It seems to me that Spring create two instances of my Dao in different application contexts one for my managed beans and other one for controller.
NB: I use criteria for data base querys
Can some one help me ?
Finally, i can use a spring controller with jsf web application. i created a applicationContext.xml file then i moved all my beans into it and i conserve my servlet.xml file but with no beans inside, that's will create one root webapp context, by consequence hibernate will create one session for the managed beans and the controller
Difference between applicationContext.xml and spring-servlet.xml in Spring

Spring MVC - code based servlet container initialization

I am a newbie and going through spring learning curve and i have a question to understand what cases i will be using code based servlet container initialization against xml initialization in web descriptor file.
The reason for my question is, at this time i wanted to spend time in learning what is used most of the time rather overloading many concepts which might be provided with the framework just for flexibility.
Any advice?
Thanks for reading
The main reason you'd want to use Java based container initialization is when you want to register Spring managed Servlet, Filter, and XxxListener objects.
For example, when you want to register a ServletContextListener, you specify
<listener>
com.your.listeners.MyListener
</listener>
in the deployment descriptor. The container takes that fully qualified class name and uses reflection to find the corresponding Class object which it instantiates to get an instance. In other words, the object is uniquely managed by the container. You can't have Spring inject fields easily.
On the other hand, with a ServletContainerInitializer, or the corresponding Spring class, you can specify Servlet, Filter, or Listener beans in your Spring context (either through XML or #Configuration classes) and register those Spring-managed instances directly through the ServletContext.
Note that there are still some configurations for which you need to use the deployment descriptor.

What is good practice to configure Spring MVC application with Spring security?

Assume I have Spring MVC powered application with Spring security. I have:
UserBean class which provides CRUD operations on table User
UserController : controller which expose operation on User to http clients
UserLogin: Authentication provider from Spring security, which authenticates users.
How should I configure my application if:
I want simple XML configuration, with auto-discovering beans by annotations (<context:component-scan base-package="org.example"/>)
UserLogin and UserController needs UserBean to work
UserLogin and UserController use transaction annotations and aspect annotations
I see the following oportunities:
Create one common Spring XML configuration file, used both by DispatcherServlet and ContextLoaderListener
Disadvantage: nobody shows that solution in tutorial. All beans are duplicated (one instance in ContextLoaderListener context, second in DispatcherServlet). Duplication may cause some hard to track bugs. Duplication is not elegant
Create two Spring XML configuration files, one for ContextLoaderListener (main) and one for DispatcherServlet (controllers). UserBean is declared in first config and visible in second one
Disadvantage: to avoid duplication I have to add complex component scanning rules to both files (context:component-scan). <tx:annotation-driven and <aop:aspectj-autoproxy/> must be defined in both files. I will have still doubts which config file is appropiate when declaring new stuff.
Create two Spring XML configuration files and include third for common settings like <tx:annotation-driven
Disadvantage: I wanted simple solution...
Summary: I'm looking for good practice to configure application with Spring MVC + Spring Security AND security part is highly connected with business part. I was searching for good example but I always find case when security code is isolated from business code. But I need example when security and business share the code
Similar question: ContextLoaderListener or not?
I have two xml files for my configuration, no particular reason, that's just how it worked out.
These sample spring security projects provide good examples of lots of different types of configurations maybe you can find something that works for you:
https://github.com/spring-projects/spring-security/tree/master/samples
Hidden message in my question was: having two contexts is stupid.
Did someone already notice that?
Is there a way to have single application configuration?
Answers:
Yes. https://jira.springsource.org/browse/SPR-6903
Yes. https://github.com/michaldo/spring-single-context-demo
The best practice which applies to my case is described here: https://stackoverflow.com/a/14032213/2365727

Spring approach for changing configuration source by environment

I'm new to Spring and trying to figure out the best way to handle the following scenario:
We have an application where for local development and testing, all configuration values are pulled from a Properties file. When the app is deployed on to the App Server (Websphere in this case), instead of properties file we use JNDI resource properties.
Is there an accepted way of handling this in Spring? For a non-Spring application I probably would have done something like this using a good ol' factory pattern to decide the config source. For Spring, I've seen examples that use different context XML files per environment (sounds messy), or make use of Spring "Profiles".
Is there a generally accepted practice for this scenario?
Spring profiles are rather new and they were added precisely to address your problems. Moreover they should deprecate all other workarounds like different context XML files you mention.
For the sake of completeness here is an example:
<beans profile="test">
<context:property-placeholder location="/foo/bar/buzz.properties" />
</beans>
<beans profile="prd">
<jee:jndi-lookup id="properties" jndi-name="foo/bar/name"/>
</beans>
Depending on which profile you choose during deployment/startup, only one of the beans above will be instantiated.
Another approach I've never tried but seems to fit your case is default-value attribute in jee namespace:
<jee:jndi-lookup id="properties" jndi-name="foo/bar/name" resource-ref="true"
default-value="classpath:foo.properties"/>
Not sure if this will help you though.
Assuming Spring 3.1, try using profiles like Tomasz suggested, but instead of setting individual JNDI values for production, use
<beans profile="prd">
<context:property-placeholder/>
</beans>
In Spring 3.1, ContextLoaderListener apparently pulls in JNDI props as a PropertySource by default, so with property-placeholder, when you need to access a value you can just use ${some/jndi/name} in applicationContext.xml or a #Value annotation.
To make sure the webapp gets the values from JNDI, add
<context-param>
<param-name>spring.profiles.default</param-name>
<param-value>prd</param-value>
</context-param>
to web.xml.
In your tests, set the system property 'spring.profiles.active' to 'test', and you'll get the values from the props file.
one way to go is you use jndi also for local dev and testing. You could define the same jndi name. I don't know what's your testing server, in practice we use jetty, and maven-jetty plugin to test. It is lightweight and can run from your ide.
another way is like what you said in your question. Making use of Spring profile. Then you could declare different transactionManager beans with same id/name. of course they should be in different profiles. At runtime you could decide which profile should be activated, that is, which bean should be used.

Dealing with two different values of a property (cloud and default) in cloudfoundry and the #Value annotation

I am in reference to Spring's #Value annotation as documented here: #Value and Spring profiles.
I need to be able to have different values for a given property such as:
websiteContext=http://localhost:8080/kadjoukor
...according to whether the app is running locally or on the cloud. I am not sure how to achieve that with the #Value("${websiteContext}") annotation...
What is the best practice for dealing with such an issue?
If you are using Spring 3.1 or later, you can take advantage of bean profiles and the CloudFoundry "cloud" profile to load a different properties file depending on the environment. That might look something like this in a Spring XML configuration file:
<beans profile="default">
<context:property-placeholder location="default.properties"/>
</beans>
<beans profile="cloud">
<context:property-placeholder location="cloud.properties"/>
</beans>
Here are a few good blog posts that explain how this works in more detail:
SPRING 3.1 M1: UNIFIED PROPERTY MANAGEMENT
USING CLOUD FOUNDRY SERVICES WITH SPRING: PART 4 – SPRING PROFILES

Resources