-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 9 posts ] 
Author Message
 Post subject: Serialization exception with hashCode() and eager-eager
PostPosted: Fri Jun 02, 2006 9:36 am 
Newbie

Joined: Fri Jun 02, 2006 9:20 am
Posts: 3
Hi all,
I have a problem with some weird stuff going on when I implement the equals()/hashCode() methods in my entites. The short version is that I get a NullPointerException on deserialization on the client side after a remote server request when I am using eager fetching in both Team and Player. If I set the player-> team to lazy it works.

Please advise.

Thanks,

Stefan Norberg

Sun Jdk 1.5.0_07
Hibernate version: Running JBoss 4.0.4.GA-patch1 with ejb3

Client that calls a slsb on the Jboss server:
Code:
public class TestHashCodeClient extends TestCase {

   Facade facade = null; 
   public TestHashCodeClient(String name) {
      super(name);
      
   }
   
   @Override
   protected void setUp() throws Exception {
      super.setUp();
      Properties properties = new Properties();
      properties.put("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");
      properties.put("java.naming.factory.url.pkgs","=org.jboss.naming:org.jnp.interfaces");
      properties.put("java.naming.provider.url","localhost:1099");
      InitialContext ctx = new InitialContext(properties);
      facade   =  (Facade) ctx.lookup( Facade.class.getSimpleName()+ "Bean/remote");
   }
   
   public void testUpdatePlayer() {
      Set<Player> players = new HashSet<Player>();
      players.add(new Player("Player1"));
      players.add(new Player("Player2"));
      players.add(new Player("Player3"));
      Team t1 = new Team("Team1");
      for (Player p : players) {
         p.setTeam(t1);
      }
      t1.setPlayers(players);
      facade.updateTeam(t1);
   }
   
   public void testGetPlayer() throws Exception {
      for (Player p : facade.getPlayers()) {
         System.out.println(p.getFullName());
      }
   }


The stateless session bean:
Code:
public @Stateless class FacadeBean implements Facade {
   
   @PersistenceContext
   EntityManager em;

   public List<Player> getPlayers() {
      Query q = em.createQuery("select p from Player p");
      return q.getResultList();
   }

   public void updateTeam(Team  t) {
      em.merge(t);
   }
}


Two entity classes: Team and Player:

Code:
@Entity
public class Team implements Serializable {
   private static final long serialVersionUID = 1L;

   private Long id;

   @Id
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   public Long getId() {
      return id;
   }

   public void setId(Long id) {
      this.id = id;
   }

   /** Optimistic locking */
   private Integer version;

   @Version
   public Integer getVersion() {
      return version;
   }

   public void setVersion(Integer version) {
      this.version = version;
   }

   public Team() {

   }

   public Team(String name) {
      setName(name);
   }

   private String name;

   @Basic
   public String getName() {
      return name;
   }

   public void setName(String name) {
      this.name = name;
   }

   private Set<Player> players = new HashSet<Player>();

   @OneToMany(fetch = FetchType.EAGER, mappedBy = "team")
   @Cascade( { org.hibernate.annotations.CascadeType.ALL,
         org.hibernate.annotations.CascadeType.DELETE_ORPHAN })
   public Set<Player> getPlayers() {
      return players;
   }

   public void setPlayers(Set<Player> players) {
      this.players = players;
   }

   public String toString() {
      return name;
   }

   public boolean equals(Object obj) {
      if (obj instanceof Team) {
         Team other = (Team) obj;
         return other.getName().equals(this.getName());
      }
      return false;
   }

   public int hashCode() {
      return name.hashCode();
   }
}

@Entity
public class Player implements Serializable {
   private static final long serialVersionUID = 1L;

   private Long id;

   @Id
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   public Long getId() {
      return id;
   }

   public void setId(Long id) {
      this.id = id;
   }

   /** Optimistic locking */
   private Integer version;

   @Version
   public Integer getVersion() {
      return version;
   }

   public void setVersion(Integer version) {
      this.version = version;
   }

   public Player() {

   }

   public Player(String name) {
      setFullName(name);
   }

   private String fullName;

   public String getFullName() {
      return fullName;
   }

   public void setFullName(String name) {
      this.fullName = name;
   }

   private Team team;

   @ManyToOne(fetch = FetchType.EAGER)
   public Team getTeam() {
      return team;
   }

   public void setTeam(Team team) {
      this.team = team;
   }

   public String toString() {
      return fullName;
   }

   public boolean equals(Object obj) {
      if (obj instanceof Player) {
         Player other = (Player) obj;
         return other.getFullName().equals(this.getFullName());
      }
      return false;
   }

   public int hashCode() {
      return fullName.hashCode();
   }
}

Full stack trace of any exception that occurs:
Code:
javax.ejb.EJBException: java.lang.NullPointerException
   at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69)
   at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
   at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:225)
   at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
   at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
   at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
   at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
   at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
   at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412)
   at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
Caused by: java.lang.NullPointerException
   at com.weirdstuff.Player.hashCode(Player.java:83)
   at java.util.HashMap.hash(HashMap.java:264)
   at java.util.HashMap.put(HashMap.java:382)
   at java.util.HashSet.add(HashSet.java:194)
   at java.util.AbstractCollection.addAll(AbstractCollection.java:318)
   at org.hibernate.collection.PersistentSet.endRead(PersistentSet.java:273)
   at org.hibernate.engine.CollectionLoadContext.endLoadingCollection(CollectionLoadContext.java:183)
   at org.hibernate.engine.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:268)
   at org.hibernate.engine.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:249)
   at org.hibernate.loader.Loader.endCollectionLoad(Loader.java:866)
   at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:853)
   at org.hibernate.loader.Loader.doQuery(Loader.java:717)
   at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
   at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
   at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
   at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
   at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2821)
   at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:370)
   at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:351)
   at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:122)
   at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:178)
   at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:86)
   at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
   at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:839)
   at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266)
   at org.hibernate.type.EntityType.resolve(EntityType.java:303)
   at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:116)
   at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842)
   at org.hibernate.loader.Loader.doQuery(Loader.java:717)
   at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
   at org.hibernate.loader.Loader.doList(Loader.java:2145)
   at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
   at org.hibernate.loader.Loader.list(Loader.java:2024)
   at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:392)
   at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:333)
   at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
   at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1114)
   at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
   at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:53)
   at com.weirdstuff.FacadeBean.getPlayers(FacadeBean.java:17)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
   at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
   at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
   at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:225)
   at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
   at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
   at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
   at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
   at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
   at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412)
   at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
   at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:190)
   at org.jboss.remoting.Client.invoke(Client.java:525)
   at org.jboss.remoting.Client.invoke(Client.java:488)
   at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
   at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
   at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
   at $Proxy0.getPlayers(Unknown Source)
   at com.weirdstuff.TestHashCodeClient.testGetPlayer(TestHashCodeClient.java:51)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at junit.framework.TestCase.runTest(TestCase.java:154)
   at junit.framework.TestCase.runBare(TestCase.java:127)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:118)
   at junit.framework.TestSuite.runTest(TestSuite.java:208)
   at junit.framework.TestSuite.run(TestSuite.java:203)
   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
   at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)



Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 03, 2006 11:05 am 
Newbie

Joined: Fri Jun 02, 2006 9:20 am
Posts: 3
Oh btw this workaround works fine, but something seems terribly broken in either Hibernate or Jboss.

public boolean equals(Object obj) {
if (name == null) return super.equals(obj);
if (obj instanceof Team) {
Team other = (Team) obj;
return other.getName().equals(this.getName());
}
return false;
}

public int hashCode() {
if (name == null) return super.hashCode(obj);
return name.hashCode();
}

All the fields in the entity are null when the the object hits the deserialization code and hence the exception... But the name is of course initialized when shown in my app later. What gives?

Jira?


Top
 Profile  
 
 Post subject: Java HashMap/HashSet deserialization may be problem
PostPosted: Tue Jun 13, 2006 9:34 pm 
Newbie

Joined: Tue Jun 13, 2006 8:58 pm
Posts: 6
There are a few bugs on the Sun Developer Network at http://bugs.sun.com related to HashMap deserialization. They have relatively few votes, and have not been resolved. As you noted, the deserialization mechanism is calling hashCode before having valid values. That's not good.

As an experiment, try eliminating any trace of Hibernate or JBoss code/libraries for your example code. Do straight up instances serializing and deserializing to a file -- using exactly the Player and Team instances you have now. I'd bet you'll still get the NullPointerException.

I strongly encourage you not to use the conditional calls to super.hashCode(), as you will lose the Set semantics. Once deserialization is done, your instances will almost certainly hash to a different value because they will have their name field value set later in the deserialization.

I have myself encountered a problem similar to yours and have implemented patched the platform classes HashMap/HashSet. I forwarded toy bug examples and an working patch to Sun on April 21, 2006, but they haven't responded yet.

The basis for the patch is an extension of one of the ideas posted for one of the HashSet/HashMap NullPointerException bugs posted at Sun. The variation I pursued ensures that serialization works with both overridden and non-overridden hashCodes, not just classes with hashCode() overridden.

In summary, the method is to hack the HashSet and HashMap platform classes to suspend the hashing, but collect the set instance in a list and call registerObject() for each. Then the validateObject() methods are called subsequent to the ordinary deserialization. HashMap thus implements ObjectInputValidation. If you roll your own patches along these lines, don't forget you'll need to use a switch such as -Xbootclasspathp: to override the default platform classes -- just putting patched classes in the regular CLASSPATH won't do it.

Ideally, Sun would have implemented serialization so that circular references work out of the box... but maybe they will revisit the problem. The failure to manage this case cleanly has probably caused a lot of mischief to those who believed "it should just work."

I am frankly surprised more Hibernaters haven't encountered this problem. Moving detached partial object graphs around is a wonderful Hibernate trick, but if one has only POJOs, it depends on serialization. Maybe this "use case" isn't common, perhaps individuals aren't creating many circular references on objects that have hashCode overridden... or maybe when people bonk, they abandon the approach, or work around it by trial and error.

If you'd like to see the care package I sent to Sun, which includes a source patch to work around the messy deserialization wrinkle, send me a note. The patch was designed to be just good enough to work until Sun resolved it, but that may be awhile... ;)

Ahem, something seems terribly broken in Java!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 14, 2006 1:57 pm 
Newbie

Joined: Fri Jun 02, 2006 9:20 am
Posts: 3
Thanks for the answer Mike,
Any idea why this only occurs when I'm having the eager-eager?
When I set one side to lazy it works like a charm (this is true for all my entities). Eager eager doesn't work for detaching as far as I can tell.

Stefan


Top
 Profile  
 
 Post subject: Why NullPointerException only on eager/eager?
PostPosted: Wed Jun 14, 2006 8:11 pm 
Newbie

Joined: Tue Jun 13, 2006 8:58 pm
Posts: 6
My guess is that with only one side being fetched eagerly, you have a proxy on the other side of the association, rather than an object "pointing" back. If Team is fully loaded, but the Players are proxied (or vice-versa), then there is no circularity in graph of objects being deserialized. This circularity seems to be a common factor in the various HashSet/HashMap serialization bugs.


Top
 Profile  
 
 Post subject: Re: Serialization exception with hashCode() and eager-eager
PostPosted: Wed Aug 16, 2006 9:44 pm 
Newbie

Joined: Tue Sep 21, 2004 12:39 pm
Posts: 18
I have the exact same problem, my objects also have a circular reference as well. Did you find any other solution?

_________________
David Launen


Top
 Profile  
 
 Post subject: Still patching platform classes
PostPosted: Thu Aug 17, 2006 11:39 pm 
Newbie

Joined: Tue Jun 13, 2006 8:58 pm
Posts: 6
I'm still waiting for a response from Sun. I haven't gone back and looked up the related bug reports on their site recently. In the meantime, we'll use our patches to the platform classes. Sun has made these platform classes nearly sacrosanct -- which would be fine if they were bulletproff and/or had responded to the associated bug reports.

I don't believe my bug has received an official ID, two related bugs to vote for on the sun developer network (http://bugs.sun.com) are:

6208166
4957674

At this point, I'll just keep trying to round up cohorts to get this addressed. Serialization of this sort is possible, but the platform implementation appears to fall short.

If someone finds this patched in a version, please poke a message onto this thread please.

- Mike


Top
 Profile  
 
 Post subject: TreeSets pass serialization tests that HashSets fail
PostPosted: Sat Jan 20, 2007 1:09 am 
Newbie

Joined: Tue Jun 13, 2006 8:58 pm
Posts: 6
TreeSets do not fail with circular references in the places a series of "Set regression" tests fail. That lends itself to approaching this HashSet bug from another angle.

I haven't tried a variant of TreeSet with Hibernate as a substitute for HashSet. Can this be done or will another set be substituted during persistence?

This would be a less intrusive work-around than patching HashSet. Performance might suffer depending on the app, but at least platform patching would be avoided. In many cases the change in performance shoulud be minor (relatively small sets).

Have to try this, not sure if underlying persistable implementation will guarantee use of TreeSet (without requiring ordering.)
[/img][/b]


Top
 Profile  
 
 Post subject: TreeSets pass serialization tests that HashSets fail
PostPosted: Sat Jan 20, 2007 1:18 am 
Newbie

Joined: Tue Jun 13, 2006 8:58 pm
Posts: 6
TreeSets do not fail when containing circular references in any of the places a series of "Set serialization regression" tests I created fail. That finding suggests a different approach to this HashSet bug... not using HashSet! This means compromising on TreeSet as an alternative base set class.

I haven't tried to configure classes and mappings to use a variant of TreeSet with an unmodified Hibernate as a substitute for HashSet. Can this be done or will another set be substituted under the covers during persistence? A quick look at the ref manual hints that only sorted sets would result in a TreeSet-like implementation. [PersistentHashSets are substituted IIRC, is there a PersistentTreeSet?]

Using TreeSet as a substitute for HashSet would be a far less intrusive work-around than patching HashSet. Performance might suffer depending on the app, but at least troublesome need for platform patching would be avoided (which could be impossible for distantly deployed apps). In many (typical?) cases the change in performance should be minor (relatively small sets).

Eventually I'll give a whack at this -- but if anyone already has this dialed in (with mapping example), I'd appreciate any suggestions.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 9 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.