Add Resource Bundles Programmatically - jsf-2

I have a faces-config.xml file with some resource bundles declared, like this:
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">
<application>
<locale-config>
<default-locale>en</default-locale>
<supported-locale>de</supported-locale>
<supported-locale>es</supported-locale>
<supported-locale>pt</supported-locale>
<supported-locale>zh</supported-locale>
</locale-config>
<resource-bundle>
<base-name>messages.Messages</base-name>
<var>bundle</var>
</resource-bundle>
<resource-bundle>
<base-name>countries.Countries</base-name>
<var>countryBundle</var>
</resource-bundle>
</application>
</faces-config>
These resource bundles are registered and can be used in any .xhtml file, but is there any way to register these resource bundles programmatically? I mean by the use of dynamic code instead of a xml declaration.

Here's a simplified version of what I'm doing using CDI:
#ApplicationScoped
public class BundleProducer {
#Produce #RequestScoped #Named
public ResourceBundle getMsgBundle() {
Locale userLocale = Faces.getLocale();
return ResourceBundle.getBundle("messages", userLocale);
}
}
Note the use of omnifaces' getLocale() to avoid a ton of boilerplace code (for a less sane version, you can substitute FacesContext.getCurrentInstance().getViewRoot().getLocale() like in the tutorial you linked to).
This will cause the CDI framework to call getMsgBundle once each request if it needs to access to msgBundle thanks to the #Named annotation. In this simple case, I'm relying on the ResourceBundle internal caching and lookup mechanisms to produce my bundle efficiently. You can execute any logic you like here (eg, load stuff from the enclosing BundleProducer) as long as you return a ResourceBundle from the method (you're not allowed to return null).
Repeat as you like with more methods producing different bundles.
Not sure if I got what you were after, so just comment if you need more clarification.
For easier handling of FacesMessage stuff, I'd recommend having a look at omnifaces' Messages utility class. I use something like this to be able to optionally give bundle keys as message strings:
#Singleton
#Startup
public class MessageResolverInit {
#PostConstruct
public void initMessageResolver() {
Messages.setResolver(new Messages.Resolver() {
#Override
public String getMessage(String message, Object... params) {
Locale userLocale = Faces.getLocale();
ResourceBundle b = ResourceBundle.getBundle("msgs", userLocale);
if (b.containsKey(message)) {
return MessageFormat.format(b.getString(message), params);
}
return message;
}
});
}
Note that I use b as a variable name only for demo purposes. Usage goes like this:
Messages.addGlobalError("my_msg_key", param1);
Messages.addGlobalInfo("I'm a standalone message");

Here is the answer from Oracle documentation: Using FacesMessage to Create a Message

Related

How to internationalize a converter or renderer in Wicket?

I'm translating a web application and things are generally going smoothly with wicket:message and properties files. But Wicket always wants to have a component for looking up strings.
How can I translate converters and renderers (i.e. implementations of IConverter and IChoiceRenderer) which don't have access to any Wicket component in their methods?
So far I found one way - Application.get().getResourceSettings().getLocalizer().getString(key, null) - but I have to make the strings "global", i.e. associated with the application class. That's not nice for separation and reuse. How can I do it better?
I think you should invent you own way how to achieve this. Here in my current project we registered our own IStringResourceLoader like this:
IStringResourceLoader stringResourceLoader = new OurOwnResourceLoaderImpl();
Application.get().getResourceSettings().getStringResourceLoaders().add(stringResourceLoader);
Then for example in IChoiceRenderer we just call Application.get().getLocalizer().getString("key", null).
Inside our IStringResourceLoader we are looking for bundles (property files) with some string pattern according our own conventions.
Or you can just register localization bundle (ie. properties file) distributed inside your library's jar in Application#init through org.apache.wicket.resource.loader.BundleStringResourceLoader.
Afaik there is no standard way to do that so it's up to you what path you choose.
Updated:
I found another solution how your library/extension can register it's own localization by itself so you needn't to touch Application#init or create your own IStringResourceLoaders.
There is preregistered string resource loader org.apache.wicket.resource.loader.InitializerStringResourceLoader (see wickets default IResourceSetting implementation ie. ResourceSetting and it's constructor) which uses wicket's Initializer mechanism - see IInitializer javadoc - basically you add wicket.properties file in your jar class root (ie. it is in default/none package) and inside file there is:
initializer=i.am.robot.MyInitilizer
then i.am.robot.MyInitilizer:
public class MyInitializer implements IInitializer {
/**
* #param application
* The application loading the component
*/
void init(Application application) {
// do whatever want
}
/**
* #param application
* The application loading the component
*/
void destroy(Application application) {
}
}
and now you create your localization bundles in same package and same name as IInitializer implementation (in our example MyInitializer)
I think I found another way...
I noticed that IStringResourceLoader also has a method String loadStringResource(Class<?> clazz, String key, Locale locale, String style); (and one more parameter for variation in newer Wicket versions) which does not require a component. clazz is supposed to be a component class, but... it doesn't actually have to be :)
I was able to implement my own class MyLocalizer extends Localizer with a new method
getString(String key, Class<?> cl, IModel<?> model, Locale locale, String defaultValue)
which works in a similar way to
getString(String key, Component component, IModel<?> model, String defaultValue)
but uses the class directly instead of a component. It still uses the same properties cache and resource loaders.
Then I wrote an abstract class MyConverter implements IConverter which has a MyLocalizer getLocalizer() and a few getString methods like the Component class. Basically it does getLocalizer().getString(key, getClass(), model, locale, defaultValue), so the properties can now be attached to the converter class.
Seems to work :)
If I understand your question...
You can use package based properties that means if you put your keys/values into a property file 'package.properties' in a package. Each localized resource of any subpackage under that package returns the value associated to the requested key until you override it in another property file.
The file name is 'package.properties' in Wicket prior to 1.6.x and 'wicket-package.properties' in Wicket 1.6+
See
https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+6.0#MigrationtoWicket6.0-package.propertiesrenamedtowicket-package.properties
However it works just for componet, outside the componet (when component argument is null), it is possible to use:
WicketApplication.properties (the WebApplication class is WicketApplication.class, this property file is in the same package).
applicationGlobalProperty=My Global Localized Property
wicket-package.properties (package based, place it in the same package as the page)
localText=Localized text: A local component text based on wicket-package.properties
LocalizedPage.html (markup template)
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Localized Page</title>
</head>
<body xmlns:wicket="http://wicket.apache.org">
<div>
<div>
<h2>Texts</h2>
<div>
<wicket:message key="localText"/> <br/>
<span wicket:id="localizedLabel"></span>
</div>
</div>
</div>
</body>
</html>
LocalizePage.java (code)
public class LocalizedPage extends WebPage {
private static final long serialVersionUID = 1L;
public LocalizedPage() {
super();
}
#Override
protected void onInitialize() {
super.onInitialize();
add(new Label("localizedLabel", new AbstractReadOnlyModel<String>() {
private static final long serialVersionUID = 1L;
#Override
public String getObject() {
return WicketApplication.get().getResourceSettings().getLocalizer().getString("applicationGlobalProperty", null);
}
}));
}
}
See the full example on https://repo.twinstone.org/projects/WISTF/repos/wicket-examples-6.x/browse

CDI/WELD can a custom qualifier work in combination with the #Named annotation?

While having a custom qualifier for CDI support as followed:
#Qualifier
#Retention(RUNTIME)
#Target({METHOD, FIELD, PARAMETER, TYPE})
public #interface QualifiedFooBean {
}
#QualifiedFooBean
public class FooBean implements ImplFooBean {
}
public interface ImplFooBean {
}
I would like to bind FooBean #{fooBean} directly without requiring a wrapper or processor (seen from this example). The annotation "Named" (in class FooBean) seems not to work for my class layout.
My solution (without wrapper) which I'm wondering why it's not working and invoking: Target Unreachable, identifier 'fooBean' resolved to null
#Named
#QualifiedFooBean
public class FooBean implements ImplFooBean {
}
Has anyone any idea?
A wrapper is not needed. My solution is perfectly valid. It's also allowed to add Named in combination of a custom qualifier (in my case QualifiedFooBean). I had to just create an empty beans.xml file in WEB-INF folder in order to get CDI to work. Anyhow The question itself explains how custom qualifiers can work. You can also prefill beans.xml with following content:
<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
</beans>
It will serve as a skeleton for future use, if you need to configure more fancy stuff with CDI.
Adding #Named to your bean should work : it works for me.
In Fact #Named is a qualifier, when JSF resolve the Bean for displaying it does a lokup based on #Named qualifier. In CDI a bean is found if the lookup side (i.e. Injection point) ask for a subset of its Qualifier.
For instance a bean qualified like that :
#QualifiedFooBean
#SecondQualifier
public class FooBean {}
Will be found (if there is no ambiguous resolution) by
#Inject
#SecondQualifier
FooBean bean;
or even :
#Inject
FooBean bean;
But not by
#Inject
#SecondQualifier
#ThirdQualifier
FooBean bean;
So you can add the #Named qualifier and let CDI resolution engine do its job.

Calling Remote EJB3 in separate EAR file from JSF in another EAR file on WAS 8

I'm new to EJB3 and having trouble calling a remote ejb from my JSF managed bean when the two are in separate ear files on the same server (WAS 8). If they are in the same ear file then I have no problems. But I need the call to work across different applications on the same server.
During the EJB injection into the Managed Bean, I get the following exception:
Caused by: javax.ejb.EJBException: The EJB/BelgianBeerSessionBean EJB reference in the null component in the BeerStoreWebProject.war module of the BeerStoreWebEAR application could not be resolved; nested exception is: com.ibm.ejs.container.EJBNotFoundException: EJB with interface com.ejb.view.BelgianBeerSessionBeanRemote not present in application BeerStoreWebEAR
Caused by: com.ibm.ejs.container.EJBNotFoundException: EJB with interface com.ejb.view.BelgianBeerSessionBeanRemote not present in application BeerStoreWebEAR
at com.ibm.ejs.container.HomeOfHomes.getHomeByInterface(HomeOfHomes.java:928)
at com.ibm.ws.ejbcontainer.injection.factory.EJBLinkObjectFactory.getObjectInstance(EJBLinkObjectFactory.java:261)
at com.ibm.ws.ejbcontainer.injection.factory.EJBLinkObjectFactory.getObjectInstance(EJBLinkObjectFactory.java:167)
I'm hoping that someone could help me get to the bottom of this and explain how I should be injecting and looking up a remote EJB if it is in a separate EAR file.
Here is my setup:
Project Setup
1) BelgianBeersEJMProjectClient (an ejb client project that contains the interfaces)
package com.ejb.view;
public interface BelgianBeerSessionInterface {
List<Country> getAllCountries();
void saveCountries(List<Country> countries);
}
package com.ejb.view;
#Remote
public interface BelgianBeerSessionBeanRemote extends
BelgianBeerSessionInterface {
}
2) BelgianBeersEJBProject (containing the ejb implementation)
package com.ejb;
#Stateless
public class BelgianBeerSessionBean implements BelgianBeerSessionBeanRemote,
BelgianBeerSessionBeanLocal {
public BelgianBeerSessionBean() {
// TODO Auto-generated constructor stub
}
public List<Country> getAllCountries() {
//to be implemented
return null;
}
public void saveCountries(List<Country> countries) {
//to be implemented
}
}
Also in the META-INF there is an ejb-jar.xml:
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.1" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd">
<display-name>BelgianBeersEJBProject </display-name>
<ejb-client-jar>BelgianBeersEJBProjectClient.jar</ejb-client-jar>
</ejb-jar>
3) BelgianBeersWebProject - contains the jsf app
#ManagedBean
#ViewScoped
public class BeerStorePageBean {
#EJB(name="EJB/BelgianBeerSessionBean")
private BelgianBeerSessionBeanRemote store;
public BelgianBeerSessionBeanRemote getStore() {
return store;
}
public void setStore(BelgianBeerSessionBeanRemote store) {
this.store = store;
}
private List<Country> countries = null;
#PostConstruct
public void populateCountries(){
System.out.println("Store = " + store);
countries = store.getAllCountries();
}
public List<Country> getAllCountries() {
return countries;
}
}
and in the web.xml there is an ejb entry:
<ejb-ref>
<description />
<ejb-ref-name>EJB/BelgianBeerSessionBean</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home />
<remote>com.ejb.view.BelgianBeerSessionBeanRemote</remote>
</ejb-ref>
Deployment Units
EAR file 1 (BelgianBeersEARProject.ear) contains:
1) BelgianBeersEJBProject.jar
2) BelgianBeersEJBProjectClient.jar
EAR file 2 (BeerStoreWebEAR.ear) contains:
1. BeerStoreWebProject.war
2. BelginaBeersEJBProjectClient.jar
Please could somebody explain to me the correct way of calling a remote EJB which is in a separate EAR file. Please help! I'm tearing my hair out!
The #EJB annotation (and corresponding <ejb-ref> in XML) will only automatically link if the target EJB is in the same application. From the javadoc:
If no explicit linking information is provided and there is only one
session bean within the same application that exposes the matching
client view type, by default the EJB dependency resolves to that
session bean.
To link to an EJB in another application, you need to specify a binding. You can do this in several ways:
Specify <lookup-name>targetBindingName</lookup-name> in the <ejb-ref> in ejb-jar.xml.
Specify <ejb-ref name="EJB/BelgianBeerSessionBean" binding-name="targetBindingName"/> in the WEB-INF/ibm-web-bnd.xml file of the WAR module containing the ejb-ref. See the InfoCenter for more information on the format of the binding files.
Specify the target binding name during application deployment (that is, do not "use default bindings").
In any case, you're going to need the binding name of the target EJB. The InfoCenter link above describes both the "classic" WebSphere Application Server binding names and the Java EE 6 standard "java:global" names. The former can be configured in ibm-ejb-jar-bnd.xml and the latter cannot (aside from specifying alternate <application-name> or <module-name>), but it doesn't really matter which you use. To find which names are being used, it's easiest to start the EJB application and then look for the CNTR0167I messages that are printed by the EJB container when it starts (the first one is the "classic" binding):
[6/6/13 17:26:04:531 CDT] 00000049 WASNameSpaceB I CNTR0167I: The server is binding the javax.management.j2ee.ManagementHome interface of the Management enterprise bean in the mejb.jar module of the ManagementEJB application. The binding location is: ejb/mgmt/MEJB
[6/6/13 17:26:04:544 CDT] 00000049 AbstractEJBRu I CNTR0167I: The server is binding the javax.management.j2ee.ManagementHome interface of the Management enterprise bean in the mejb.jar module of the ManagementEJB application. The binding location is: java:global/ManagementEJB/mejb/Management!javax.management.j2ee.ManagementHome

Google Guice - How to pass a parameter to a third party library Factory class

I am attempting to migrate from Spring to Guice for dependency injection. Here is a sample snippet from a Spring xml config:
<bean id="connectionFactory" class="org.somethirdparty.MyConnectionFactory">
<property name="connectionUrl" value="${urls.connectionUrl}"/>
<property name="ackMode" value="unordered"/>
<property name="timeout" ref="timeoutBean"/>
</bean>
<bean id="timeoutBean" class="java.lang.Integer">
<constructor-arg value="10000"/>
</bean>
I am struggling with figuring out how to parameterize MyConnectionFactory with Google Guice. I cannot annotate the constructor or methods of 'MyConnectionFactory' as this is a class provided by a 3rd party library.
After reading the Guice FAQ it seems to me the only option is to make a Factory for the Factory? That seems silly to me!
You might need to make a Factory for the MyConnectionFactory, but only if you actually need to vary the parameters passed to MyConnectionFactory at runtime. Otherwise, you can get away with making a Provider—which is a Factory after all, I guess—or its slimmer cousin the #Provides Method. (I'm guessing the class in question takes unspecific or primitive arguments, or else a toConstructor binding is yet another possibility.)
The Factory would look like this:
public class MyConnectionFactoryFactory {
#Inject Provider<SomeDependency> someDependencyProvider;
public MyConnectionFactory create(String url) {
return new MyConnectionFactory(someDependencyProvider.get(), url, 10000);
}
}
The Provider would look identical, except it'd implement Provider<MyConnectionFactory> and create would instead be a zero-arg get(). You can bind that through bind(MyConnectionFactory.class).toProvider(MyConnectionFactoryProvider.class).
However, if you know all your constructor parameters at configuration time, you could equally create a #Provides method in your Module, which would look like this:
public class MyModule extends AbstractModule {
#Override public void configure() { /* your configuration here */ }
/* FYI: a #Provides method by any other name would return as sweet */
#Provides MyConnectionFactory getConnectionFactory(SomeDependency dependency) {
return new MyConnectionFactory(dependency, url, 10000);
}
}
...which takes your "wrapper code" boilerplate to three extra non-blank lines. Remember, Guice will automatically bind any combination of X, Provider<X>, or #Provides X to any injection of X or Provider<X> automatically for you, so feel free to bind it however is most convenient.

Identity Model Claims With XML Characters Within Them

I'd like to do something like
outputIdentity.Claims.Add(new Claim("Claim1", "<test>Hi</test>"))
However the security node within the response header itself shows it as
<Attribute Name="Claim1"><AttributeValue><test>Hi</test></AttributeValue></Attribute>
I know they are reserved XML characters getting translated but can't I specify that I want that node structure in my attribute?
NOTE: I've also tried wrapping it in CDATA however it serializes that tag too. When I replace the translated characters, it works.
Serialization of security tokens is done by the SecurityTokenHandler (in your case probably the Saml11SecurityTokenHandler).
If you want to customize serialization you have to overwrite the default behaviour by extending the Saml11SecurityTokenHandler class:
class CustomHandler : Saml11SecurityTokenHandler
{
public Saml11SecurityTokenHandler()
: base()
{
}
public Saml11SecurityTokenHandler(SamlSecurityTokenRequirement samlSecurityTokenRequirement)
: base(samlSecurityTokenRequirement)
{
}
public Saml11SecurityTokenHandler(XmlNodeList customConfigElements)
: base(customConfigElements)
{
}
protected override void WriteAttribute(XmlWriter writer, SamlAttribute attribute)
{
// your code here
}
}
You also have to add your custom security token handler in the web.config file:
<securityTokenHandlers>
<add type="Your.Namespace.CustomHandler, Your.Dll.Name, Version=1.0.0.0, Culture=neutral" />
</securityTokenHandlers>
EDIT: removed <clear />
Can you try wrapping the value in CDATA section? As:
<![CDATA[<test>Hi</test>]]> Not sure whether your SecurityTokenHandler class will handle that properly, but it's worth a try, and easier than introducing custom handlers.

Resources