Recent changes to bugs

Multiple instantiation of WiredContainer

Matthias Bartels — Wed, 13 Aug 2008 09:57:23 -0000

the WiredContainer can be instantiated multiple times in a webservice environment with many parallel threads.
This is due to two code-blocks which are not synchronized.

1.) WSAdapter - this class holds a static member for a WiredClientContext. But the initialisation of this variable is not synchronized.

2.) WiredClientContext - this class holds a static member "defaultContainer", which is a WiredContainer. The creation of this WiredContainer is also not synchronized

If more than one Thread executes these code-blocks at a time, the WiredContainer can be created more than once.

This behaviour would be no problem if a thread used the same WiredContainer for the whole call chain, e.g. from entry into the WiredContainer till exit of the container. But due to currently unknown reasons the Thread switches its WiredContainer during the execution of the call chain. This causes some severe problems. The WiredContainer holds the AllocationManager (that means resource and transaction management) in a ThreadLocal. If a Thread switches its container the AllocationManager is not available for the Thread.

The consequence of this behaviour is that SQL-Statements can run outside of a transaction-scope although a TX-attribute is specified.

Missing implementation link no longer supported?

Anonymous — Wed, 09 Jul 2008 11:47:05 -0000

In older CUBA releases it was allowed to define components classes and component interfaces separately without an implementation reference between class and interface. Allthough it is not recommended at all, it is a kind of fea´ture which was adopted from EJB 2. With version 3 of CUBA it seems that this is not allowed any more. If I do so, I get a class cast exception at runtime.

Endless loop in garbage collection

Anonymous — Fri, 30 May 2008 12:33:59 -0000

Cyclic dependencies of components with predestroyer methods may case an endless loop during garbage collection. The problem ist that the predestroyer causes a complete initialization of the adapter which is of no use for a formerly unused adapter which is simply destroyed by its finalizer.

I'd suggest a bugfix like this. In AbstractComponentAdapter add the following function:

protected void invokeLifecycleWeak(Method coreMethod, AroundInvocation commonInterceptors) {
if (core != null)
invokeLifecycle(coreMethod, commonInterceptors);
}

In AbstractAdapterGenerator.generateLifecycleCall use this function for predestroy:

if (callType.equals(Interception.PRE_DESTROY))
adapter.print("invokeLifecycleWeak(");
else
adapter.print("invokeLifecycle(");

JPA always required

Anonymous — Wed, 07 May 2008 15:10:51 -0000

CUBA requires a JPA library even if JPA is not used in a project. It would be better if CUBA would contain the JPA interfaces itself just like the JTA interfaces which are also included.

Missinterpretation of * character in CMT

Anonymous — Sat, 05 Apr 2008 11:23:05 -0000

When associating CMT attributes to methods on a wildcard basis, the * character is supposed to represent 0 or more arbitrary characters. The embedded container interprets it as 1 or more characters. I.e. a specification like "create*" does not cover methods of name "create(...)".

AbstractEJBClientContext ignores exception messages

Anonymous — Mon, 24 Mar 2008 09:59:57 -0000

getJNDIContext() catches NamingExceptions and throws a new ReferenceException. The ReferenceException ignores the message of the NamingException, so bug finding will be more complicated.

Connect retry

Anonymous — Thu, 20 Mar 2008 17:08:52 -0000

When trying to fetch a connection from the connection pool of the embedded container, the appropriate allocation class immediately gives up if the pool is currently empty. It were better to retry it several times before giving up and report an exception.

Here is the modified code of class AllocatedResource which does retries 10 retries over a period of 1 second. Of course it would be nicer when these values could be configured per data source in wired-application.xml. But its a start :-)

class AllocatedResources {
public static final int NUM_RETRIES = 10;
public static final long RETRY_DELAY = 100L; //100ms

//... identical code removed
public WiredManagedConnection allocateResource(ResourceFactoryI factory)
throws SQLException {
assertFactoryType(factory);
WiredManagedConnection con = (WiredManagedConnection) resources.get(factory);
if (con == null) {
for (int retry = 0; true; retry++) {
try {
con = ((WiredDataSource) factory).nextConnection();
resources.put(factory, con);
break;
}
catch (SQLException sqlx) {
if (retry > NUM_RETRIES || !(factory instanceof WiredPooledDataSource)) {
throw sqlx;
}
}
try {
Thread.sleep(RETRY_DELAY);
} catch (InterruptedException e) { /* ignore */ }
}
}
return con;
}

//... identical code removed
}

same methods in internal and external interface

Anonymous — Tue, 18 Mar 2008 10:41:19 -0000

If an impl has both an external and an internal interface with the same methods, the adapter generator creates both methods on the generated file. This will lead to an compiler error.

Environment entries are not derived

Anonymous — Fri, 15 Feb 2008 16:36:15 -0000

Environment entries which are not bound to class members but just declared bei a @Resource or @Resources annotation at the class header are not inherited in derived component classes.

EJB3 adapter contains hard-coded stuff

Anonymous — Tue, 12 Feb 2008 22:23:14 -0000

The class EJB3AdapterGenerator produces hard-coded type case "(cubatest.CubaImpl)" for environment injection. This must be changed to the actual declaring class.