I was wondering if Spring has a properties files mechanism similar to Struts2 where it looks for a properties file first in the same package as the controller and then moves up the package structure until it finds the properties file or property.
I want to define a property file per controller, but I rather not have to wire them up together, if possible. Is there some convention that can be followed that would associate the properties file with the controller? The properties file resolution should also work correctly when resolving locales.
For example, if I define a property called "title" in several prop files, I want the correct one to resolve in the JSP based on which controller handled the request.
ControllerA RETURNS ViewA USES PropA.title
ControllerB RETURNS ViewB USES PropB.title
I was successful in auto wiring a Property file to a controller's Model attribute and display values in JSP. I was also able to specify a ResourceBundleMessageSource in the configuration and then display values from it in JSP.
Out of the box, not that I know of.... but you can easily write one, if that's what you really want!
Spring has things like BeanFactoryPostProcessor which lets you do things like this with your BeanFactory/ApplicationContext. I'm thinking BeanFactoryPostProcessor would fit the bill here - you could 'post process' a bean by looking for a properties file on the classpath, grabbing the properties, and applying them to the bean.
I'll say this though - Spring is usually meant to be fairly non-invasive. If you want something like this to become part of your design, you might want to think of a way to do this in pure Java, rather than using Spring. For example, create your own Factory and implement and unit test it separately. Require your app to use this Factory to get your business objects.
In other words, you can probably do it in Spring - but it isn't always the best approach. It does sound like it could be the most convenient, in your case, but I haven't see the details of what you're setting and where. Just food for thought..
Related
If I have a class such as ConfigReader which is able to store data from XML or Properties, usually with an initialize() method and getters for every field, where am I most likely supposed to implement it when using a classic MVC pattern?
In my opinion it would be a controller. However, when working with console applications, the configuration could be an essential part to display data in the console, therefore a view as well.
I am working on a struts2 project that has interdependent forms.
I found struts2-conversation, stepped through their simple-example
and understood the conversation mechanism this far (please correct me if I got something wrong):
The Controller is mapped in the struts.xml
It holds the serializable ConversationContext and the Storing-Service
The ConversationContext holds POJOs mapped on forms by naming convention
Now my question is where to put the validation?
In this structure the controller is only one extending ConversationSupport and thereby ActionSupport supplying the validate, prepare and addField- & ActionError methods.
But validating within the controller would mean to validate the whole context, which does not really serve the issue.
I tried validation through annotation within the POJOs, within the context as described above which gives me some NullPointerException as if the context wasn't flushed and I think the xml-validation approach of struts2 is just too stiff. (btw how to let the generated javascripts be minified before being served? And why is there so many options?)
Mark's conversation-interceptor approach had similar problems coming up which's workarounds I didn't really get. Maybe you can help me there.
If you would like to use annotations on your model classes, it works fine with the plugin (as do the other validation approaches).
To validate your model, add #VisitorFieldValidator to the getModel() method in your controller. In the example app, you would then also add #VisitorFieldValidator to the getContact() and getPreferences() methods. Then you can use the validation annotations on the fields you wish to validate.
The service in the example is just there as a simple example of using an injected service in a Struts2 controller and how that can integrate easily with the conversation framework, but it is not directly related or needed (and I would recommend using either Spring, Guice, or CDI for dependency injection in the real world).
The ConversationContext class is intended mostly for internal use by the framework. You should be able to avoid interacting with it by using the annotations and conventions. Unless you simply wish to be adventurous.
To use XML validation in the example app, you would have to change the package name to remove the "struts2" word in order for the Struts2 resource loading tool to load the XML.
I'm looking for a Bean to Bean Mapping Java Framework that their mapping rules could be defined outside/not in java code. The source and target beans has n subBeans so the mapping rules could be a little bit complex (not a simple one-to-one mapping).
A little overview about the process:
It's Simple ETL process but with a configurable mapping logic.
I use Spring Batch to load a multiline record (fixed lenght file) into a bean. Its just a representation of the record as an javabean to use it as base for the defined mapping rules. the result of this mapping is another javabean that is completly different build as the source one. And here I would like to use a generic mapping framework between this to java beans.
The Spring Batch part is completly clear and implemented.
Of course I could defined it hardcoded in java but for transparence reasons I have to export this mapping logic outside the java code.
Does anyone know a such framework? Does one exists? I found Dozer but I think I can't define some complex mapping rules in their XML.
Maybe. I would use the Java Scripting API for this. It allows you to load scripts (JavaScript, Beanshell, Groovy, whatever) and run them. You could put a line of input (or the whole model) in a variable and the script could then create the new object structure.
try to use JMapper Framework.
In XML you can write STATIC and DYNAMIC conversion using placeholders to use values and names of the fields, for example if you need to get and set values from a map the code is the follows:
<conversion name="fromMapToAll" from="map" type="DYNAMIC">
return (${destination.type}) ${source}.get("${destination.name}");
</conversion>
<conversion name="fromAllToMap" to="map" type="DYNAMIC">
${destination}.put("${source.name}",${source});
return ${destination};
</conversion>
see the wiki page for more info.
I am using Struts 2 and Spring autowiring. Right now, the default strategy is set to by-name, but usually we use the constructor and the fallback works to autowire in properties when only one implementing class is available.
There is one property however that I'd like to wire into an action class that has several implementing classes, so I made the Action a java bean, with the properties as fields that can be set. Unfortunately, the only ways that these will be used (apparently) is if they have a public getter/setter, which also exposes them to the type converter at request time. In other words, if a client adds their name to the request as form fields or parameters, Struts will attempt to write those values to them.
So my question is, is it actually possible to use by-name autowiring without exposing properties like that (which may or may not be a security hazard), or am I better off just using XML and defining the Action as an object with scope prototype?
I did eventually track down the documentation for the ParametersInterceptor which actually lists three ways you can limit what parameters are set by the interceptor.
Configuring excludeParams in the parameter configuration, which is a global regex which applies to all actions (not what I want, also possibly deprecated as it is no longer described in the most recent class docs).
Setting excludeMethods (does the same as the previous, the preferred method for global excludes)
Implementing ParameterNameAware, which is the closest to what I wanted. Here you can whitelist what parameters are used.
In the end, defining the action as a prototype object in the normal Spring configuration seemed to be the most prudent. Letting the action manage what parameters it has means another place where parameters need to be explicitly white listed every time a change is made.
I got pretty big webflow definition, which I do not want to copy/paste for reusing. There are references to action bean in XML, which is kind natural.
I want to use same flow definiton twice: second time with actions configured differently (inject different implementation of service to it).
Is there easy way to do this?
Problem is I want to use same flow with different beans at once, in the same app. Copy/Paste is bad, but I dont see other solution for now.
You could try creating a new flow that extends the "pretty big one" and adding flowExecutionListeners to it.
The interface "FlowExecutionListener"defines methods for the following events in flow execution:
requestSubmitted
requestProceessed
sessionCreating
sessionStarting
sessionStarted
eventSignaled
transitionExecuting
stateEntering
viewRendered
viewRendering
stateEntered
paused
resuming
sessionEnding
sessionEnded
exceptionThrown
You can write a handler that injects the required resources to your flow (and use different handles with different flows) by storing it in the RequestContext, where you can access it in your flow definition.
Note that in that case you would still have to modify the "pretty big flow" to use those resources instead of referencing the beans directly.
I'm in the same fix that you're in...i have different subclasses which have corresponding action beans, but a lot of the flow is the same. In the past we have just copied and pasted...not happy with that!
I have some ideas I am going to try out with using the expression language. First, I came up with an action bean factory that will return the right action bean to use for a given class, then i can call that factory to set a variable that i can use instead of the hard-coded bean name.
Here's part of the flow:
<action-state id="checkForParams">
<on-entry>
<set name="flowScope.clientKey" value="requestParameters.clientKey"/>
<set name="flowScope.viewReportBean"
value="reportActionFactory.getViewBean(reportUnit)"/>
</on-entry>
<evaluate expression="viewReportBean"/>
The evaluate in the last line would normally refer directly to a bean, but now it refers to the result of the "set" I just did.
Good news--the right bean gets called.
Bad news--anything in the flow scope needs to be Serializable, so I get a NotSerializableException--arggh!
I can try setting something on a very short-lived scope, in which case it will need to get called all the time...or I can figure out some kind of proxy which holds the real bean as a proxy declared "transient".
BTW, I am using Spring 2.5.6 and webflow 2.0.7. Later versions may have better ways of handling this; in particular, EL's have gotten some attention, it seems. I'm still stuck with OGNL, which is the Spring 1.x EL.
I'm sure some webflow guru knows other ways of doing things in a less clunky fashion...
I don't think you can use the same webflow definition with the actions configured in two different ways.
If you want to use different actions you'll either have to reconfigure your action beans then redeploy your app or create a separate webflow definition with the differently configured beans.
This is a great Spring WebFlow resource.
Try to refactor the common configurable part in a subflow, and call the subflow from the different main flows where you want to reuse it.
Pass parameters to the subflow to configure it in any way needed, using the spring expression language to pass different spring beans, etc.