February 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: In/Un callbacks should be happening at Install

by alesj

When the installs fail, should we just unwind from the current index? The thing is that uninstalls are different instances, and user can order them differently than the matching installs, or install perhaps even doesn't need to have matching uninstall. But normally they do. :-) So, the only question is, what to do by default - execute all uninstalls or just from the failed install's index? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130485#4130485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130485

18 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: jndi lookup during restart

by jcreynol

Forgot to mention that there is an ongoing thread regarding the Socket issue: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=125962&start=10 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130464#4130464 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130464

18 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: jndi lookup during restart

by jcreynol

>> Basically, any RMI-based transport is vulnerable to the problem of a >> client holding onto an RMI stub that no longer matches the server. >> Do you need to use an RMI connector? The short answer to this is no -- in fact, in production, per the suggestions of a JBoss consultant that we'd see better performance with Socket transport, we are using Socket transport. The reason we're investigating a switch to RMI is that the RMI transport "properly" handles aborted transactions, in that it immediately throws an exception back to the client that the transaction was rolled back. Socket Transport will not catch that the transaction is rolled back, so the client doesn't get notified -- until the thread completes... assuming it does... and even then, the client only receives a notice that the long running thread's transaction is dead so, even though we made you wait for the long running thread to complete, we're only going to give you an InvalidStateException because the wrapping transaction has timed out. That said, Socket Transport handles a server bounce quite elegantly. :) So long answer is that we're trying to find a transport that meets all our needs -- which are pretty simple -- notify client immediately when Transaction times out (some type of Exception is fine TransactionRolledBack or whatever) AND handle a server restart. Any advice on what the best approach is to get one of these transports fixed to meet our needs is very much appreciated. Thanks, much! John View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130463#4130463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130463

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: In/Un callbacks should be happening at Install

by alesj

"adrian(a)jboss.org" wrote : For (install/) the use of (this/) should validate that there is actually something to inject? | Since we allow install execution on any InvokeDispatchContext, it boils down to the target context to inform you if it cannot invoke the method. But I think we have pretty good info in those cases. e.g. MBeanServer is gonna complain that the mbean is not yet registered, ReflectionUtils that the target object was null, ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130449#4130449 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130449

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: In/Un callbacks should be happening at Install

by adrian＠jboss.org

I guess using whenRequired makes sense. The install and incallback won't work before instantiated unless you explicitly pass the target on the controller context when installed into the MC. i.e. you are installing a pre-instantiated object. For the use of should validate that there is actually something to inject? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130434#4130434 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130434

18 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: wrong sql-file for creating database - Data too long for

by inxaoc

This solved this problem and database works correctly now! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130433#4130433 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130433

18 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - wrong sql-file for creating database - Data too long for col

by inxaoc

Hello! The following exception was thrown when I've tried to use Mysql DB. Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'ISTERMINATIONIMPLICIT_' at row 1. I've used the special file for creating mysql database. The sql-file provided by developers (in starter kit) is wrong, and I've token correct file from other source (jbpm wiki article). But this file was no good fully. It contains error. Ypu should replacde all inclusion like this - "ISTERMINATIONIMPLICIT_ bit" (bit is wrong type for mysql it is the same as UNKNOWN, but this should be boolean!) with for example such "ISTERMINATIONIMPLICIT_ tinyint(1)" View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130432#4130432 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130432

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: In/Un callbacks should be happening at Install

by alesj

We already have 'state' attribute, which marks the dependent state of the target bean (if there is one configured for install/uninstall). | if (install.getBean() != null) | target = controller.getContext(install.getBean(), install.getDependentState()); | What sohuld we call the new state attribute, whenRequired to make it consistent? Should we allow this just for certain states? I would again leave it to the user, since we don't enforce this anywhere else. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130421#4130421 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130421

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Another startup time regression

by kabir.khan＠jboss.com

The legacy ant one, i.e. just update build/build-thirdparty.xml to use: | <componentref name="jboss/aop" version="snapshot"/> | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130381#4130381 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130381

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Wrong dependency info after module uninstall

by adrian＠jboss.org

Ok, now I've seen the commit, I understand what you are talking about. You changed the api in an incompatible way and didn't update the class hierarchy. There is a similar issue with the demand dependency which is the original version of depending on an abstract concept and what I copied to create the RequirementDependencyItem.. I've added @Override to the methods to ensure they are actually overridding things, but more importantly, I've changed the AbstractDependencyItem to do what you should have done in the first place: Compatible change: | // Old method possibly overridden by subclasses | public void unresolved() | { | if (resolved) | { | resolved = false; | flushJBossObjectCache(); | log.trace("Forced unresolved " + this); | } | } | | // New method just calls the old method | public boolean unresolved(Controller controller) | { | unresolved(); | return true; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130371#4130371 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130371

18 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2008