Seam file component in javaee6 - java-ee-6

I'm trying to replicate the loading of a property file of seam in javaee6 but still don't know where to start.
In seam we can load a property file as a seam component by defining it in the components.xml:
<component name="propertyBean" class="PropertyBean" scope="application" auto-create="true" startup="true">
<property name="filename">myPropertyFile.properties</property>
<property name="reload">true</property>
</component>
And then we can access it in code:
PropertyBean.getInstance().getProperty("myProperty");
Is there a javaee6 feature that will replicate this functionality? Or in spring it's called PropertyPlaceholder.
In c#, we can do it by adding configuration property in appsettings.xml. And access via ConfigurationManager.
Thanks,
czetsuya

Unfortunately, there's nothing like a property component manager from seam into javaee6, but I was able to find something similar, a property loader.
It works by having a qualifier:
#Qualifier
#Retention(RUNTIME)
#Target({METHOD, FIELD, PARAMETER, TYPE})
public #interface ConfiguredBy {
#Nonbinding public String value();
}
With a parameter that serves as the name of the property file.
The whole approach is describe here:
http://john-ament.blogspot.com/2010/03/writing-property-loader-in-java-ee-6.html

Related

How to write custom XML tag parsers in STS?

I want to extend the STS to support my own custom XML tags by write a custom eclipse plugin.
For ex:
...
<bean id="demoBean" class="demo.JavaBean"/>
<myrpc:service interface="demo.MyService" ref="demoBean" />
...
myrpc:service means it will pulish the "demoBean" as a rpc service of interface "demo.MyService"
And now the SpringExplorer can list the "demoBean" as a node, but cannot recoginze the myrpc:service.
I want extend the STS to support these things.
Which extension point should be contributed?
How to do this?

GWT - internationalization, the default works but when I add locale to URL I still get the default values. Any idea?

I have now seriously started experimenting with GWT, and I am stuck of course. I am trying with a very simple internationalization and when I add locale to my URL as following it doesn't work and always default data is fetched.
http://127.0.0.1:8888/DoTime.html?gwt.codesvr=127.0.0.1:9997&locale=sv_SE
In the following picture you can see structure of the project. The name of the application is "DoTime".
In the file /client/properties/DoTimeConstants_sv_SE.properties I have
localeTest = Vi skriver något på svenska för att testa om vi kan få det på svenska med locale.
appTitle = DoTime på svenska
In the corresponding file /client/DoTimeConstants I have
package com.dotime.client;
import com.google.gwt.i18n.client.Constants;
public interface DoTimeConstants extends Constants {
#DefaultStringValue("haha we are writing something in default to test locale")
String localeTest();
#DefaultStringValue("DoTime default title")
String appTitle();
}
I the file /client/properties/DoTimeMessages_sv_SE.properties I have
#DefaultMessage("''{0}'' is not a valid symbol.")
String invalidSymbol(String symbol);
#DefaultMessage("Last update: {0,date,medium} {0,time,medium}")
String lastUpdate(Date timestamp);
In the corresponding file /client/DoTimeMessages I have
package com.dotime.client;
import com.google.gwt.i18n.client.Messages;
import java.util.Date;
public interface DoTimeMessages extends Messages {
#DefaultMessage("''{0}'' en symbol på svenska.")
String invalidSymbol(String symbol);
#DefaultMessage("Senaste uppdatering: {0,date,medium} {0,time,medium}")
String lastUpdate(Date timestamp);
}
In the file DoTime.gwt.xml I have add locale="sv_SE" and added inherit I18N:
<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 2.0//EN"
"http://google-web-toolkit.googlecode.com/svn/releases/2.0/distro-source/core/src/gwt-module.dtd">
<module rename-to="DoTime">
<!-- Inherit the core Web Toolkit stuff. -->
<inherits name='com.google.gwt.user.User'/>
<!-- Specify the app entry point class. -->
<entry-point class='com.dotime.client.DoTime'/>
<inherits name="com.google.gwt.i18n.I18N"/>
<extend-property name="locale" values="sv_SE"/>
<!-- Specify the app servlets. -->
<servlet path='/DoTimeService' class='com.dotime.server.DoTimeServiceImpl'/>
</module>
In my entry point method I fetch appTitle which returns the default value correctly
String appTitle = constants.appTitle();
but when I change my url by adding &locale=sv_SE nothing happens and I still have the default value.
I did try first by only having locale file extension locale=sv without any luck and later changed to sv_SE but it didn't work anyway. What is it I am missing? Do you have any idea? Many thanks for some clues.
Your properties files must be name the exact same as the Constants or Messages interfaces, except for the locale suffix and file extension. Specifically here, they must be in the same package; you cannot put them in some other package (the properties subpackage in this case) and expect GWT to find them.
Side notes:
I think the locale in the gwt.xml and in the URL has to be written in the Java notation, using a dash as separator rather than an underscore.
you shouldn't use the <servlet> tag in your gwt.xml; they're used by the GWTTestCase runtime, but then you'd rather make a test-specific module that <inherits> your app module, rather than put those declarations in your app module.

How to use org.jboss.varia.property.SystemPropertiesService and org.jboss.util.property.PropertyListener

All
I have seen the jboss-service.xml which use an extended SystemPropertiesService class to reference to custom property file. But I didn't totally understood this kind of usage yet.
Could someone please give me some help to understand how to use these two class? thanks.
The SystemPropertiesService is very useful to define properties that then can be accessed from your application, it's usually used to parametrize the application without having to change to code, or even the application package (provided you place the jboss-service.xml outside de war / ear / jar structure). For example, you can create a myapp-service.xml file with the following content:
<server>
<mbean code="org.jboss.varia.property.SystemPropertiesService" name="jboss:type=Service,name=MyAppProperties">
<!-- Define the properties directly in the service.xml file-->
<attribute name="Properties">
myapp.property1=property1Value
myapp.property2=property2Value
</attribute>
<!-- You can also specify a route to another file where you define properties-->
<attribute name="URLList">
/home/myuser/txtlist.properties
</attribute>
</mbean>
</server>
Then you can deploy this file directly in JBoss, the properties defined will be visible to all the applications deployed in the same JBoss and you'll be able to access them with the static method:
String System.getProperty(String propertyName)
So if you want to access to the value of myapp.property1 from your application you'd do:
String property = System.getProperty("myapp.property");
On the other hand the PropertyListener is really an interface that defines a listener that will be triggered when any event occurs with a property. The org.jboss.util.property.PropertyAdapter is an abstract implementation of this interface. To use it you've to implement its three methods (propertyAdded, propertyChanged, propertyRemoved), that will be called by the container when a property is added, changed or removed respectively. Those methods have a PropertyEvent object as parameter, which let you know the property affected.
This interface/class is useful when you want your application to do something every time a property changes (a bad implementation would be that you check every certain time for a property change), this way, when JBoss detects that a property has changed its value, it will call the respective method (that you should implement with the behaviour you want).
For example, if you want to print the new property value everytime it's changed you could implement the propertyChanged method this way:
void propertyChanged (PropertyEvent pe){
// check the property that has changed
if (pe.getPropertyName().equals("myapp.property1")){
System.out.println("The value of " + pe.getPropertyName() + " has changed to " + pe.getPropertyValue());
}
}
Look for more information in the API, and for PropertyAdapter and PropertyEvent.
In JBOSS 5.1 it only works when you put the properties or URL in properties-service.xml and this file should go under jboss.home/server/default/deploy directory.

GWT validation framework, how to specify location of internationalization bundle

This one is related to my previous post. Is it possible in GWT validation framework to specify location of ValidationMessages.properties files and their names? I already have messages translations in my application and I'd prefer them to be in one location.
You could create a custom UserValidationMessagesResolver:
public class CustomValidationMessagesResolver extends AbstractValidationMessageResolver implements UserValidationMessagesResolver {
protected CustomValidationMessagesResolver() {
super((ConstantsWithLookup) GWT.create(ValidationConstants.class));
}
}
In the above code, ValidationConstants is the class resulting from running I18NSync on my properties file.
Then in *.gwt.xml:
<replace-with class="yourpackage.client.validation.CustomValidationMessagesResolver">
<when-type-is class="com.google.gwt.validation.client.UserValidationMessagesResolver" />
</replace-with>
You can find a complete example here.

Using custom javax validation annotations in GWT

For the current project we're using JSR-303 annotations to validate our interface parameters.
I needed to create a custom annotation for dates, as the default #Past and #Before also take into account the time.
This is the definition of my annotation:
#Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
#Retention(RUNTIME)
#Documented
#Constraint(validatedBy = { NotInFutureValidator.class })
/**
* Annotated element must be a date before tomorrow, compared to the system's date
*/
public #interface NotInFuture {
String message() default "{be.credoc.contractRegistration.interface_v2.validation.pastignoretime}";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
The implementation of the validator is pretty straight forward.
Our webapplication is written in GWT and it makes use of gwt-validation. This allows us to validate our parameters on client side by means of the same annotations.
However, when I annotate my parameters with my custom annotation and I want to validate it by making use of the GwtValidatorFactory, it doesn't give me an error when the input date is in the future.
Does anyone have experiencing defining and using their own annotations in a GWT application and can see what I'm missing?
Thanks in advance
Instead of creating new annotations you might try to re-define the validators for the existing #Past and #Future annotations by providing an XML constraint mapping like this:
<?xml version="1.0" ?>
<constraint-mappings
xmlns="http://jboss.org/xml/ns/javax/validation/mapping"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd">
<constraint-definition annotation="javax.validation.constraints.Past">
<validated-by include-existing-validators="false">
<value>x.y.z.NotInFutureValidator</value>
</validated-by>
</constraint-definition>
</constraint-mappings>
This mapping must be registered in the configuration file META-INF/validation.xml like this:
<?xml version="1.0" encoding="UTF-8"?>
<validation-config
xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.0.xsd">
<constraint-mapping>META-INF/validation/custom-constraints.xml</constraint-mapping>
</validation-config>
You can learn more about custom validators for existing constraints in the Bean Validation specification and the Hibernate Validator reference guide.
Apparently we wrote our own JavaScript implementations for each custom annotation, so the solution in this case was to write such an implementation.