[JBossCache] - A single point of failure in ChainingCacheLoader
by shimi
In the user documentation of the cache it is written:
anonymous wrote : To alleviate single point of failure, we could combine this with a ChainingCacheLoader, where the first CacheLoader is a ClusteredCacheLoader, the second a TcpDelegatingCacheLoader, and the last a JDBCacheLoader, effectively defining our cost of access to a cache in increasing order of cost.
This sounds like a good thing to have but this is not true. Since all the delegate methods at ChainingCacheLoader throws Exceptions.
Lets take a look at the example above. When ChainingCacheLoader execute
public void put(Fqn name, Map attributes) throws Exception
| {
| Iterator i = writeCacheLoaders.iterator();
| while (i.hasNext())
| {
| CacheLoader l = (CacheLoader) i.next();
| l.put(name, attributes);
| }
| } and there is an Exception in the first CacheLoader which is ClusteredCacheLoader, the second CacheLoader TcpDelegatingCacheLoader and the next one after will never be called
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965258#3965258
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965258
19 years, 10 months
[JBoss Eclipse IDE (users)] - Re: Fibo-tutorial -- I cannot run it???
by ashishjain
The structure of FiboApp.ear is :
It contains one META-INF folder and 2 files: FiboEJB.jar and FiboWeb.jar
Further META-INF contains application.xml.
Since I am using JBOSS IDE 1.5 and JBOSS Server 4.0 and it was written in the article,
I didnt build FiboEJB-client.jar and since I didn't build FiboEJB-cliet.jar I didn't include it in FiboWeb.jar
So, application.xml is there under META-INF inside FiboApp.ear
Also,
Under Descriptors, I choose "EAR 1.3 Deployment Descriptor" but I am using J2EE 1.4. Is this thing fine.
While XDoclet Configuration I choose EJB specification as 2.0 and servlet specification as 2.3
For jobswebxml subtask (while configuring XDoclet), I change specification to 4.0 from 3.0 as written in the article since I am using JBOSS server 4.0.
Please clarify the problem.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965255#3965255
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965255
19 years, 10 months
[JBoss jBPM] - Re: taken end and task instance end
by cpob
"yxyang" wrote : (1)what do you mean "task end"? I went through the source code and find out that the hibernate queries for findTaskInstance....() related methods only retrieve the "open" tasks.
This is in the user guide. Task end... means the task is ended.
"yxyang" wrote : (2)What is the purpose of this "open" flag in jbpm design?
I think that flag indicates if it is active/open or ended/closed. Experiment a bit and see what it does
"yxyang" wrote : (3)Under what situation, will the completion of a task instances trigger a signal on the token? In other words, who will response for the triggering of the token when a task instance is completed?
Like I said before, if there is a single task instance on a task node, and you end that task, it will signal the token. (using default jPDL attributes - if you don't know what these are, you're using the defaults) If you have multiple tasks on a task node, the LAST completed task will signal the token.
"yxyang" wrote : (4)I know token.signal() move the token to next node. But what is the function of "token.end()"? If a token and all of its children are ended, what does it mean?
I take it as killing the token. It's done, no more, no more signalling, etc. My suggestion is just to experiment and see what happens. Write up a simple test case which ends tasks and tokens and etc and see what happens. Look at the database.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965253#3965253
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965253
19 years, 10 months
[JBoss Seam] - Eliminating code redundancy + suggestion for DataModel and D
by gcomnz
Preface: I'm quite certain that my usage patterns in Seam are not advanced yet, so I might be looking at the problem of code redundancy in Seam components completely wrong, so comments highly welcome.
I'm trying to work through strategies to eliminate repetitive code in a large project, and common features such as entity search pages and components are an example of an easy win since the combination of Hibernate + Seam makes much of the code generic. It looks to me that even with a modest project its easy to eliminate 10k lines of code just for that one feature alone on all the entities that need searchability.
My approach at this point is to create an abstract class that holds most of the standard functionality and use Generics to handle typing provided by the subclasses. It's not fully tested yet, but so far appears good.
For instance, the signature of the (untested) abstract superclass is:
| public abstract class StatelessSearchBean<T> implements Search <T> {
|
| ...
|
| }
|
The code currently has some less than safe typecasts, due to erasure, but I'm not so worried about that at this point.
A subclass looks like this:
| @Name("someEntityFinder")
| @Stateful
| @Scope(ScopeType.SESSION)
| @Interceptors(SeamInterceptor.class)
| public class SomeEntitySearchBean extends StatelessSearchBean<SomeEntity> {
|
| private static final long serialVersionUID = 1L;
|
| @DataModel
| private List<SomeEntity> someEntityList;
|
| @DataModelSelection
| private SomeEntity selectedSomeEntity;
|
| public SomeEntitySearchBean() throws IllegalAccessException,
| InstantiationException {
| }
|
| public SomeEntity getSelected() {
| return this.selectedSomeEntity;
| }
|
| public void setList(List<SomeEntity> list) {
| this.someEntityList = list;
| }
|
| public List<SomeEntity> getList() {
| return this.someEntityList;
| }
|
| }
|
The constructor is currently resolving Generics instantiation issues as well, but it's just a placeholder for better handling that I will add later.
The @DataModel and @DataModelSelection are both set here instead of the superclass, since the default "value" parameter in the superclass would name-clash with other components. For instance, it wouldn't work to have multiple lists on a page named "list". But since it's annotations that set the DataModel* naming, I can't use non-constant values, such as getName() results to fix the problem. (The accessors and mutators are also there to allow access internally in the abstract superclass.)
1. It appears that with a minor modification to @DataModel and @DataModelSelection default value settings in Seam code, it would be possible to turn the above into:
| @Name("someEntityFinder")
| @Stateful
| @Scope(ScopeType.SESSION)
| @Interceptors(SeamInterceptor.class)
| public class SomeEntitySearchBean extends StatelessSearchBean<SomeEntity> {
|
| private static final long serialVersionUID = 1L;
|
| }
|
I suggest that perhaps an optional setting @DataModel and @DataModelSelection, to change the naming strategy in the "value" parameter, would fix the issue of all that repetitive code. For instance, a parameter like "qualifyDefaultValue" could prefix the class name so that a default of "list" becomes "someEntityList" in the above example.
Of course, it's been a long night, and I might just be missing other obvious ways to refactor this. In which case... >> cringe << while i wait for a flaming ;-)
2. What am I missing here? What are other people experiencing? Just like most of Java, it looks like there's a lot of repetitive code laying around (no fault of Seam's), so I'm just trying to cut down several 10's of thousands of lines of code from my project and I want to work out the best strategies for doing so. This is just one example of a common use case that I'm trying to genericize.
I'd really rather not opt for a code generator, instead preferring to eliminate redundancy (plus, the Hibernate Utils Seam template code is rather attrocious anyway ;-D, so I'd have to resort to homegrown tools).
Thanks!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965252#3965252
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965252
19 years, 10 months