Develop Reference

Clustered Singleton using Wildfly?

I'm trying to create a simple clustered Singleton on Wildfly 8.2. I've configured 2 Wildfly instances, running in a standalone clustered configuration. My app is deployed to both, and I'm able to access it with no problem.
My clustered EJB looks like this:
#Named
#Clustered
#Singleton
public class PeekPokeEJB implements PeekPoke {
/**
* Logger for this class
*/
private static final Logger logger = Logger
.getLogger(PeekPokeEJB.class);
private static final long serialVersionUID = 2332663907180293111L;
private int value = -1;
#Override
public void poke() {
if (logger.isDebugEnabled()) {
logger.debug("poke() - start"); //$NON-NLS-1$
}
Random rand = new SecureRandom();
int newValue = rand.nextInt();
if (logger.isDebugEnabled()) {
logger.debug("poke() - int newValue=" + newValue); //$NON-NLS-1$
}
this.value = newValue;
if (logger.isDebugEnabled()) {
logger.debug("poke() - end"); //$NON-NLS-1$
}
}
#Override
public void peek() {
if (logger.isDebugEnabled()) {
logger.debug("peek() - start"); //$NON-NLS-1$
}
if (logger.isDebugEnabled()) {
logger.debug("peek() - value=" + value); //$NON-NLS-1$
}
if (logger.isDebugEnabled()) {
logger.debug("peek() - end"); //$NON-NLS-1$
}
}
}
...and I've written a very simple RESTful service to let me call these methods through the browser...
#Path("/test")
#Named
public class TestRS extends AbstractRestService {
/**
* Logger for this class
*/
private static final Logger logger = Logger.getLogger(TestRS.class);
#Inject
private PeekPoke ejb = null;
#GET
#Path("/poke")
public void poke() {
if (logger.isDebugEnabled()) {
logger.debug("poke() - start"); //$NON-NLS-1$
}
this.ejb.poke();
if (logger.isDebugEnabled()) {
logger.debug("poke() - end"); //$NON-NLS-1$
}
}
#GET
#Path("/peek")
public void peek() {
if (logger.isDebugEnabled()) {
logger.debug("peek() - start"); //$NON-NLS-1$
}
this.ejb.peek();
if (logger.isDebugEnabled()) {
logger.debug("peek() - end"); //$NON-NLS-1$
}
}
}
I'm able to call both the peek and poke methods from a single Wildfly instance and get the expected value. However, if I attempt to call poke from one instance, and peek from another I see that the values are not being replicated across the EJBs.
I was under the impression that a clustered singleton would replicate the value of 'value' across both application servers, providing the same value regardless of which host I made the peek call from. Is this not correct? Is there something I'm missing that still needs to be added to this code?
I'd appreciate any help you can give me! Thanks!

Singleton session beans provide a formal programming construct that guarantees a session bean will be instantiated once per application in a particular Java Virtual Machine (JVM).
The JSR 318: Enterprise JavaBeans TM ,Version 3.1 says:
A Singleton session bean is a session bean component that is
instantiated once per application. In cases where the container is
distributed over many virtual machines, each application will have one
bean instance of the Singleton for each JVM
Hence, in a clustered application, each cluster member will have its own instance of singleton session beans and data is not shared across JVM instances (in Wildfly implementation).
In Wildfly if you need only one instance of singleton in a cluster scope you can use the SingletonService implementation. Using a SingletonService, the target service is installed on every node in the cluster but is only started on one node at any given time.
See:
Implement an HA Singleton
cluster-ha-singleton: A SingletonService deployed in a JAR started
by SingletonStartup and accessed by an EJB
UPDATE:
WildFly 10 adds the ability to deploy a given application as a
"singleton deployment". This is a new implementation of a feature that
existed in AS 6.0 and earlier. When deployed to a group of clustered
servers, a singleton deployment will only deploy on a single node at
any given time. If the node on which the deployment is active stops or
fails, the deployment will automatically start on another node.
See: WildFly 10 Final is now available!

WebApplicationContext not being shut down on Servlet Context reload

When I shut down Tomcat, I observe a correct shutdown and cleanup of the Spring WebApplicationContext. However, when I redeploy my Spring-based WAR (by copying the new WAR to webapps), normal shutdown does not occur. This is a problem for me due to all the ensuing resource leaks:
org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [] appears to have started a thread named [hz.hazelcast-swipe-instance.scheduled] but has failed to stop it. This is very likely to create a memory leak.
org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [] appears to have started a thread named [hz.hazelcast-swipe-instance.operation.thread-0] but has failed to stop it. This is very likely to create a memory leak.
... and many more. I am using XML-less configuration, this is my WebApplicationInitializer:
public class WebApplicationInitializer extends AbstractAnnotationConfigDispatcherServletInitializer
{
#Override protected Class<?>[] getRootConfigClasses() {
return new Class[] { WebSecurityConfig.class, WebMvcConfig.class };
}
#Override protected Class<?>[] getServletConfigClasses() { return null; }
#Override protected String[] getServletMappings() { return new String[] { "/" }; }
#Override public void onStartup(ServletContext ctx) throws ServletException {
ctx.setInitParameter("spring.profiles.active", "production");
super.onStartup(ctx);
}
}
There is no configuration specific to controlling the behavior upon servlet context reload, and I assume this should have worked out of the box.
Is there a way to make the WebApplicationContext close properly before continuing the servlet context reloading procedure?
I am on Spring 4.0.5, Tomcat 7.0.54, Hazelcast 3.2.1, Hibernate 4.3.4.Final.
Update
I have added a Spring application listener for the ContextClosedEvent and printed the stack trace of its invocation:
at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:333) [spring-context-4.0.6.RELEASE.jar:4.0.6.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:335) [spring-context-4.0.6.RELEASE.jar:4.0.6.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:880) [spring-context-4.0.6.RELEASE.jar:4.0.6.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:841) [spring-context-4.0.6.RELEASE.jar:4.0.6.RELEASE]
at org.springframework.web.servlet.FrameworkServlet.destroy(FrameworkServlet.java:819) [spring-webmvc-4.0.6.RELEASE.jar:4.0.6.RELEASE]
at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1486) [catalina.jar:7.0.54]
at org.apache.catalina.core.StandardWrapper.stopInternal(StandardWrapper.java:1847) [catalina.jar:7.0.54]
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232) [catalina.jar:7.0.54]
at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5647) [catalina.jar:7.0.54]
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232) [catalina.jar:7.0.54]
at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1575) [catalina.jar:7.0.54]
at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1564) [catalina.jar:7.0.54]
This indicates that the Spring shutdown occurs in its Servlet#destroy method. This is the relevant snippet from AbstractApplicationContext#close():
if (logger.isInfoEnabled()) {
logger.info("Closing " + this);
}
LiveBeansView.unregisterApplicationContext(this);
try {
// Publish shutdown event.
publishEvent(new ContextClosedEvent(this));
}
catch (Throwable ex) {
logger.warn("Exception thrown from ApplicationListener handling ContextClosedEvent", ex);
}
// Stop all Lifecycle beans, to avoid delays during individual destruction.
try {
getLifecycleProcessor().onClose();
}
catch (Throwable ex) {
logger.warn("Exception thrown from LifecycleProcessor on context close", ex);
}
// Destroy all cached singletons in the context's BeanFactory.
destroyBeans();
// Close the state of this context itself.
closeBeanFactory();
// Let subclasses do some final clean-up if they wish...
onClose();
synchronized (this.activeMonitor) {
this.active = false;
}
I see the log entry from the start of this snippet, and I get my ContextClosedEvent. I also see an entry DefaultLifecycleProcessor - Stopping beans in phase 2147483647, which probably comes from the getLifecycleProcessor.onClose() line. It seems that some error occurs downstream from that. Some exception may be swallowed.
Update 2
As requested, this is how I configure Hazelcast:
#Bean(destroyMethod="shutdown") public HazelcastInstance hazelcast() {
final Config c = hzConfig();
final JoinConfig join = c.getNetworkConfig().getJoin();
join.getMulticastConfig().setEnabled(false);
join.getTcpIpConfig().setEnabled(true);
return getOrCreateHazelcastInstance(c);
}
hzConfig() is a method where instance name, group name and password, map names, and map indices are configured, so I don't think it is of interest here.
And this is my Hibernate SessionFactory config:
#Bean
public LocalSessionFactoryBean sessionFactory() {
final LocalSessionFactoryBean b = new LocalSessionFactoryBean();
b.setDataSource(dataSource);
b.setHibernateProperties(props(
"hibernate.connection.release_mode", "on_close",
"hibernate.id.new_generator_mappings", "true",
"hibernate.hbm2ddl.auto", "update",
"hibernate.order_inserts", "true",
"hibernate.order_updates", "true",
"hibernate.max_fetch_depth", "0",
"hibernate.jdbc.fetch_size", "200",
"hibernate.jdbc.batch_size", "50",
"hibernate.jdbc.batch_versioned_data", "true",
"hibernate.jdbc.use_streams_for_binary", "true",
"hibernate.use_sql_comments", "true"
));
return b;
}

At some point, you mentioned that there was a NoClassDefFoundError for Logback. You got this fixed by removing this dependency, but then the problem moved to a another class - one of Spring's own classes.
This can mean that either one of the libraries you have does something buggy with class loaders or maybe Tomcat needs instructions not to keep locks on some resources. See here more about Tomcat resources being locked and the <Context> setting to try: in your Tomcat's conf/context.xml place a antiResourceLocking="true" to the element.

Have you tried upping unloadDelay (defaults to 2000ms) for Tomcat contexts? See http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
UPDATE: I see that you are having issues with logback as well, it might be worth the shot to try and register this listener as well:
class LogbackShutdownListener implements ServletContextListener {
#Override
public void contextDestroyed(ServletContextEvent event) {
LoggerContext loggerContext = (LoggerContext)LoggerFactory.getILoggerFactory();
System.out.println("Shutting down Logback context '" + loggerContext.getName() + "' for " + contextRootFor(event));
loggerContext.stop();
}
#Override
public void contextInitialized(ServletContextEvent event) {
System.out.println("Logback context shutdown listener registered for " + contextRootFor(event));
}
private String contextRootFor(ServletContextEvent event) {
return event.getServletContext().getContextPath();
}
}
Be sure to declare this listener before the spring context loader listener so that it is invoked after the context listener upon shutdown.
UPDATE 2: Also it might be worth the try to register another bean to handle closing of the Hazelcast stuff manually (be sure to also remove destroyMethod from the hazelcast bean):
#Component
class HazelcastDestructor {
#Autowired
private HazelcastInstance instance;
#PreDestroy
public void shutdown() {
try {
instance.shutdown();
} catch (Exception e) {
System.out.println("Hazelcast failed to shutdown(): " + e);
throw e;
}
}
}
UPDATE 3: Just out of curiosity, have you tried parallel deployment: http://www.javacodegeeks.com/2011/06/zero-downtime-deployment-and-rollback.html. It might behave differently than reloading the very same context. At the very least you should be able to undeploy the old version lazily and see if that makes a difference.

There is a similar issue on the dangling threads while container restarting here.
Of all the answers, one particular answer of interest was by Howard - which shows the way these threads are cleared.
There is some good discussion and reasoning as to how this can terminate the threads here.
Now implement ServletContextListener and take care of these threads in the contextDestroyed() method as:
public class YourListener implements ServletContextListener{
....
#Override
public void contextDestroyed(ServletContextEvent event) {
//Call the immolate method here
}
}
Register this listener in WebApplicationInitilizer as:
ctx.addListener(new YourListener());
So when server is restarted - contextDestroyed method is called and this takes care of all these threads.

From Web App development point of view, ServletContainer can only notify the before started and before end process of app.
It is using ServletContextListener.
Config ServletContextListener in web.xml
<listener>
<listener-class>com.var.YourListener</listener-class>
</listener>
YourListener.java
public class YourListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
//initialization process
}
public void contextDestroyed(ServletContextEvent sce) {
//destory process
}
}
Update -XML Less
Programmatically
#Override
public void onStartup(ServletContext ctx) throws ServletException {
ctx.addListener(new YourContextListener());
ctx.setInitParameter("spring.profiles.active", "production");
super.onStartup(ctx);
}
Annotation
#WebListener / #WebServletContextListener
public class YourContextListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent servletContextEvent) {
}
public void contextDestroyed(ServletContextEvent servletContextEvent) {
}
}
Update- ShoutDown Hook In Spring
I never use it before my app development, we can register shoutdownhook event into AbstractApplicationContext of Spring.
I am not sure it will be ok or not for you.
AbstractApplicationContext context = ...
context.registerShutdownHook();
Reference 1 Reference 2

How to load Class in an OSGI E4 Environment while using Shiro?

I'm trying to build a Desktop Application using E4 with his OSGi(Equinox) Environment. For my User Security im using Shiro. But i can load class from my OSGi but shiro cant!
In my Bundle i try this :
InitActivator.java :
public class InitActivator implements BundleActivator {
private static BundleContext context;
static BundleContext getContext() {
return context;
}
#Override
public void start(BundleContext context) throws Exception {
//1. OSGi loadClass function
System.err.println(context.getBundle().loadClass("com.firm.demo.MyCustomClass")
.getName());
//2. Using Apache Shiro ClassUtils
System.err.println("Shiro : " + ClassUtils.forName("com.firm.demo.MyCustomClass"));
}
}
The 1. system.err return the right class with his qualified name.
The 2. system.err return a org.apache.shiro.util.UnknownClassException: Unable to load class named
How can i use Shiro into OSGi to find Class with Name?

If you look at the source of ClassUtils, you will see how it tries to load the classes: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.shiro/shiro-core/1.0.0-incubating/org/apache/shiro/util/ClassUtils.java#ClassUtils.forName%28java.lang.String%29
The first thing it tries is to load the class with the help of the ClassLoader attached to the thread. If it fails, it tries to load with the ClassLoader that loaded ClassUtils. If it fails, it tries to load the class with the system ClassLoader.
You can trick the first one, the thread context classloader. I must mention that this is only a workaround, not a solution that is nice in the OSGi world:
BundleWiring bundleWiring = context.getBundle().adapt(BundleWiring.class);
ClassLoader bundleClassLoader = bundleWiring.getClassLoader();
Thread currentThread = Thread.currentThread();
ClassLoader originalCl = currentThread.getContextClassLoader()
currentThread.setContectClassLoader(bundleClassLoader);
try {
System.err.println("Shiro : " + ClassUtils.forName("com.firm.demo.MyCustomClass"));
} finally {
currentThread.setContextClassLoader(originalCl);
}

java.lang.Exception: ServletConfig has not been initialized

i have a problem is:
java.lang.Exception: ServletConfig has not been initialized
I searched for it nearly 2 days but i did not have a solution for me. Every one had said that
super.init(config) must be used. I have tried this, but there is nothing change for me.
My init method;
#Override
public void init(ServletConfig config) throws ServletException {
super.init(config);
AppServiceServlet service = new AppServiceServlet();
try {
service.getir();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
AutoCheckStatus.autoCheckStatus(600000);
}
and my AppServiceServlet;
public List<SswAppServiceDto> getir() throws Exception {
try {
final WebApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(this
.getServletContext());
setiAppServiceBusinessManager((IAppServiceBusinessManager) context.getBean(BEAN_ADI));
List<SswAppService> result = getiAppServiceBusinessManager().getir();
List<SswAppServiceDto> list = DtoConverter.convertSswAppServiceDto(result);
for (int i = 0; i < result.size(); i++) {
AppService appService = new AppService();
appService.setServiceName(result.get(i).getName());
appService.setUid(result.get(i).getServiceUid());
appService.setHost(result.get(i).getHost());
appService.setPort((int) result.get(i).getPort());
SystemConfiguration.appServiceList.put(appService.getUid(), appService);
}
return list;
} catch (RuntimeException e) {
throw new Exception(e.getMessage(), e.getCause());
}
}
The exception is thrown in this line;
final WebApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(this.getServletContext());
in AppServiceServlet and says:
java.lang.Exception: ServletConfig has not been initialized.
Pls help.

This call:
AppServiceServlet service = new AppServiceServlet();
Instantiates a servlet instance via new, which circumvents the normal, container managed creation of a servlet. As such, critical class variables (for example, the servlet config) don't get properly initialized.
Later on, you are making a call to getServletContext, which simply redirects to getServletConfig().getServletContext(), but because the servlet configuration was never completed you get an exception.
Infact, calling new on a servlet the way you are is non-compliant with the specification - servlets are supposed to be maintained by the web app container. The proper way to launch a startup servlet is either via configuration in your web.xml file, or via annotation.

How to keep properties values in session scope?

I am using spring. i have an externalized properties file. i am loading it as below.
<context:property-placeholder location="file:///C:/some.properties"/>
Now how can i keep properties in session as key-value pair ?
i tried writing a listener which extends ServletContextListener.
public class Sample implements ServletContextListener {
#Override
public void contextInitialized(ServletContextEvent event) {
//here i tried to get the values of properties file as below.
InputStream stream = event.getServletContext().getResourceAsStream("C:\\some.properties");
//But here stream is coming as null
}
}
Am i missing anything here?
Thanks!

SetvletContext's contextInitlalized() is called when the servlet context is initialized when the application loads successfully,
If you want to store it properties file in application context you can put it in
event.getServletContext().setAttribute("global_properties", propertiesInstance);
If you want it on per session, then you need to hook it into HttpSessionListener's sessionCreated() method
So put the data that is frequently used and that is shared across the application in applicationscope and the data that is limited to a session but frequently used put it in session

I would suggest use PropertyPlaceHolderConfigurer which communicates with a ServletContextListner. This class PropertyPlaceHolderConfigurer has one method call processProperties in which you could get the map of all the properties.
#Override
protected void processProperties(ConfigurableListableBeanFactory beanFactoryToProcess,
Properties props) throws BeansException {
super.processProperties(beanFactoryToProcess, props);
resolvedProps = new HashMap<String, String>();
for (Object key : props.keySet()) {
String keyStr = key.toString();
resolvedProps.put(keyStr, parseStringValue(props.getProperty(keyStr), props,
new HashSet()));
}
}
And in the listner contextInitialized() you could do like:
ServletContext servletContext = sce.getServletContext();
WebApplicationContext context = WebApplicationContextUtils
.getRequiredWebApplicationContext(servletContext);
ExposablePropertyPlaceHolder configurer =(ExposablePropertyPlaceHolder)context.getBean(propertiesBeanName);
sce.getServletContext().setAttribute(contextProperty, configurer.getResolvedProps());
where ExposablePropertyPlaceHolder is the class which extends PropertyPlaceHolderConfigurer.