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
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 would like to use shared resx file to specify all the translatable strings (both for translator convenience, and more importantly to avoid having dozens of separate resx files that clash with DRY principle). I got it working with IStringLocalizer for controllers and views, but I just can't figure out how to implement it for model's data annotations.
It works by using separate files like Models.AccountViewModels.LoginViewModel.en.resx, but how would I go and use shared resource file for data annotations instead of specific ones? Can anyone share example of implementation?
P.S. Environment is .NET Core 1.1 so both validation and display annotations should be in that version available for localization
Step 1: Create a simple class, named ValidationMessages.cs and leave it empty. I will assume that your class is located in /Validation folder.
Step 2: Modify provider for data annotations localizer in your Startup.cs file to be like this:
mvcBuilder.AddDataAnnotationsLocalization(options =>
{
options.DataAnnotationLocalizerProvider = (type, factory) =>
{
return factory.Create(typeof(ValidationMessages));
};
});
Step 3: Create folder /Validation in /Resources (I assume that you are keeping all resource files in that folder) and then add ValidationMessages.fr-FR.resx file there (for French culture i.e.).
Step 4: Add entries to the resource files with keys of your liking. I assume that you will have keys like RequiredError, MaxLengthError, etc.
Step 5: Decorate properties on your model class with [Required(ErrorMessage="RequiredError")].
Next time property validation fails, validation messages will be pulled from ValidationMessages.{culture}.resx files.
Keep in mind though, that not only validation messages will be searched there, but also property names if you use DisplayAttribute.
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.
I am using Unity2 with XML configuration. It has the neat feature to specify namespaces and assemblies in the XML config for which automatic type lookup is performed, so that you do not need to always specify full name or create an alias.
Is it possible to specify assemblies and namespaces for the automatic type lookup programatically, without them being explicitly listed in the XML configuration? My goal is to simplify the XML configuration for my application's administrators. Types from two or three namespaces will almost always be used in the container registrations, so I would like these namespaces to be included in the lookup automatically.
There's nothing built in explicitly to support this.
An option would require a few more steps in your code. instead of just calling container.LoadConfiguration(), you'd instead explicitly grab the configuration section:
var section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
Then, you'd go into the Namespaces or Assemblies properties on the section, and add new NamespaceElement or AssemblyElement objects pointing at the "standard" namespaces and assemblies. Then you apply the updated configuration section to the container. Something like this:
section.Namespaces.Add(new NamespaceElement() { Name = "my.standard.namespace" });
container.LoadConfiguration(section);
I haven't actually tried this, :-), but it should work.
I am new to the structure map but i want to use it in my asp.net site for dependency injection
can any one suggest me simple example to use structure map for the dependency injection
you will need to do something like this:-
StructureMapConfiguration
.ForRequestedType<IResourceA>()
.TheDefaultIsConcreteType<ResourceB>()
.CacheBy(InstanceScope.Singleton);
This tells StructureMap to inject ResourceB when there is a request for ResourceA.
Structure Map
You can configure programatically or via configuration file.
Programatical example (there are other ways):
StructureMap.StructureMapConfiguration.ForRequestedType<ISomething>().TheDefaultIsConcreteType<ConcreteSomething>();
then you can get an instance of the configured type using this sort of code:
//The concrete type will be ConcreteSomething
ISomething instance = ObjectFactory.GetInstance<ISomething>();
You can do it in a config file:
<StructureMap MementoStyle="Attribute">
<DefaultInstance PluginType="Blah.ISomething, Blah.SomethingDLL" PluggedType="Blah.Concrete.ConcreteSomething,Blah.ConcreteDLL"/>
</StructureMap>
and in the main method or Global.asax you can set this config by saying:
StructureMap.ObjectFactory.Initialize(x => { x.PullConfigurationFromAppConfig = true; });
and use it the same way as above:
ISomething instance = ObjectFactory.GetInstance<ISomething>();
If the concrete class has a constructor that needs instances injected in it, and you have those configured, the concrete types will get injected by the framework.
There are ways of passing parameters to constructors, dealing with Gereric types, creating named instances that are configured with specific constructor/property values. I use this framework and like it very much.