If I'm using JavaBean Validation 1.0 (JSR 303), and I extract my validation messages into a property file how does Spring become aware of my property file? I know I need to declare a ResourceBundleMessageSource bean but I'm just not clear on how Spring/JavaBean validation becomes aware of this file?
That is main idea of "Framework". It makes lots of magic/setups behind of scenes, so you don't have to write thousands rows of boilerplate code for every project. You can follow with default path/settings (messages.properties) or switch to something else using Configuraton or application.properties file (which also can be changed). But for sure, you don't want to do that in most cases, but you can.
Related
#WebInitParam is an annotation that goes at class level.
It defines initialization parameters for the servlet.
I would like to know, what is the difference between doing this and using static variables, and why do it the #WebInitParam way rather than using statics?
What does defining k/v pairs as #WebInitParams allow you to do that you couldn't do if you declared static variables instead?
I have looked and all I can find is a million people saying how to define #WebInitParams. Well yes that's the easy bit. It's what I can do with that that is really what is of interest.
Thanks very much.
From a "raison d'etre" perspective, the annotation exists as a better design and architecture alternative to just peppering a class with static fields. #WebInitParam is a self-documenting approach to the initialization parameters a servlet or filter class needs, available via web.xml as well. It serves this purpose for the end developers as well as the JavaEE platform as a whole.
Think about it this way: in a vanilla project, you have the option of hardcoding a bunch of parameters in the class as static fields, or defining the same parameters in a property file. Which would you pick? Under what circumstances?
From a purely functional angle, apart from the function of using the annotation to override defaults set in web.xml, one other major reason is that you will sometimes need to get a hold of those initialization parameters from another component in your application. Using the annotation essentially increases the visibility of the parameter. In JSF for example, the API allows you to retrieve FacesServlet initialization parameters with:
//get all the parameters
FacesContext.getCurrentInstance().getExternalContext().getInitParameterMap()
//get a specific parameter
FacesContext.getCurrentInstance().getExternalContext().getInitParameter("aParameter");
In JSF-2.3 , it gets even more convenient with the following CDI-enabled injection:
#InitParameterMap Map<String,String> servletParameterMap;
Bear in mind that because it's CDI, it means this facility is available throughout the JavaEE platform, not just in web applications/JSF.
It's going to be a hassle to retrieve init parameters if the only mechanism available is a static field in the servlet class - you'll need to obtain an instance of the filter or servlet to get the static fields in it.
Separately, one could make the argument that maybe one should favour context-params over servlet-params because then, you get even more flexibility that isn't tied to any given servlet. That's a separate matter entirely :)
I'd like to configure bean validation (JEE6) constraints via a properties file or database.
So for instance the Max value below would get pulled from the properties file or database.
Is this possible in ?
#Max(value = 1)
private int elvis;
Any suggestions on a possible approach.
It is not possible via standard Bean Validation. The default as per specification are annotations or as alternative XML.
In theory, Hibernate Validator has the (internal) concept of a MetaDataProvider and one could think of plugging in a DbMetaDataProvider. However, that would be quite some work and I am not sure that it would be worth the effort.
What is you use case anyways? Why don't you use XML?
You can write your own constraint and validator for that. The constraint’s argument could be some identifier of the validation parameters stored in database and the validator could query database for these parameters to validate a value according to them.
Some hints:
See this validator for an idea how to reuse existing validators from your “über validator”.
See this question and this answer for a hint how to inject bean to a validator.
1) We are using OpenEJB (both embedded and standalone) with a few deployed EJBs. We would like to specify some simple static business rules and values (example: icon_size=200). Normally, we would put them in a regular properties file (example: rules.properties). Since we shouldn't access the file system directly while inside the application server, is is possible to place those key-value pairs somewhere inside the ejb-jar.xml?
2) If not, is there a standard mechanism to do this? What is it?
Thanks
Use env-entry. In XML:
<env-entry>
<env-entry-name>icon_size</env-entry-name>
<env-entry-type>java.lang.Integer</env-entry-type>
<env-entry-value>200</env-entry-value>
</env-entry>
In annotation:
#Resource(name="icon_size")
int icon_size;
I personally just use a .properties file; well a TernarySearchTree which reads in .properties and .XML files and allows quick retrieval. These files are available at application level. However you can in EJB 3 inject env-entry elements into your EJB. This link explains it in good detail Injection of env entry
There are some OpenEJB extensions here that might be useful.
env-entries.properties
Check out the Custom Injection example which is basically allows the <env-entry> to be specified as plain properties in a META-INF/env-entries.properties file. Nice for collapsing all those name & value pairs into a simple properties file. Internally, we just generate the xml for you using those properties. The default type is always java.lang.String, which is good for this next part.
java.beans.PropertyEditor support
Any <env-entry> which is of <env-entry-type> java.lang.String will automatically have its type converted using the VM java.beans.PropertyEditor for the target type. That's also how Spring does the converting. There are few built-in converters, such as #Resource java.util.Date myDate and #Resource java.io.File myFile
I'm trying to use Webservice component in my Flex 4 application.
I need to use this in Actioncript and not using MXML tags.
I'm able to invoke the WSDL operations successfully, but the resultFormat is Object by default.
How do I set it to e4x?
var lookupService:WebService = new WebService();
lookupService.wsdl =url;
lookupService.loadWSDL();
lookupService.doLookup.addEventListener(ResultEvent.RESULT, lookupResultHandler);
lookupService.doLookup.addEventListener(FaultEvent.FAULT, faultHandler);
lookupService.doLookup(lookupString);
I tried to set the format by
lookupService.resultFormat = "e4x";
But this is not working. The calls are not even going through when I do this.
Can you please provide your suggestions for implementing this using AS3?
If you take a look at the two web service classes, you'll realize that resultFormat is not a property on either of them. Resultset is a property on the operations array.
If that doesn't help, you'll have to quantify "not working." What isn't working? Are you getting compile errors? Are you getting runtime errors? IS the data not being returned? Is the data not be returned as XML?
You'll probably have to set this up in MXML and dissect the generated ActionScript to figure out the appropriate AS3 syntax.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/rpc/soap/WebService.html
I used dotfuscator to protect my source code and I disabled renaming(to keep public methods and class names correct) but I noticed when I used reflector to see the assemblies after encryption that they didn't changed a lot. I still can see the source code.
Any information?
You can specify finely what will be excluded from the renaming phase by using a Obfuscation attribute. For example on a property:
[Obfuscation(Feature = "renaming", Exclude = true)]
public int MyProperty
{
get { return this.prop; }
}
If you disable renaming that means that none of the symbols (methods, types, etc) in your assembly will be renamed, that mitigates much of the usefulness of obfuscation.
If you just want to preserve the names of your publicly accessible methods instead of disabling renaming turn on library mode for each of the assemblies whose public methods you want to exclude from renaming.
In addition, renaming on its own will not cause Reflector to not show decompiled source. In order to break the decompilation you need to be sure to have Control Flow obfuscation enabled as well.
dotfuscator only obfuscate your code, it doesn't hide it completely from prying eyes.
If you really want "hide" the method body from Reflector, I suggest you to use Clisecure. Clisecure can make the logic body disappear while maintaining all the method name.
Do you have an option to obfuscate the logic? You should use that; it will make your logic harder to understand.