[Design of JBoss Portal] - Re: Initial UI Server Prototype Discussion
by sohil.shah＠jboss.com
The protocol needs to be modelled under the form of a hierarchy of serializable objects.
What do you think of a more flexible object model with a leaner hierarchy...
Something like this:
| public class UIRequest implements Serializable
| {
| private String requestType; //this signifies what type of function is asked for like
| getUIElement, processURL, moveWindow, removeWindow
|
| private Map attributes; //this contains the data needed for a particular function
| }
|
Something similar for UIResponse as well.
This way more functions can probably be integrated into the system pretty easily as well.
This would help to evolve the UIServer functionality over time while still keeping it lean and mean
btw- Now that we want to integrate at the second phase of the controller, a well thought out object model becomes very important
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061313#4061313
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061313
19 years
[Design the new POJO MicroContainer] - Re: Precedence
by adrian＠jboss.org
What is this? It is not a fix to change the test.
You're supposed to make the tests pass, not change them!
The orders in those tests were the correct ones.
There's NO POINT having regression tests if you modify the tests
because you introduced a regression. :-)
|
| > Modified: projects/microcontainer/trunk/deployers-impl/src/tests/org/jboss/test/deployers/deployer/test/DeployerFlowUnitTestCase.java
| > ===================================================================
| > --- projects/microcontainer/trunk/deployers-impl/src/tests/org/jboss/test/deployers/deployer/test/DeployerFlowUnitTestCase.java 2007-07-06 12:53:54 UTC (rev 63864)
| > +++ projects/microcontainer/trunk/deployers-impl/src/tests/org/jboss/test/deployers/deployer/test/DeployerFlowUnitTestCase.java 2007-07-06 13:05:54 UTC (rev 63865)
| > @@ -288,7 +288,7 @@
| > assertEquals(6, deployer3.getUndeployOrder());
| > assertEquals(5, deployer4.getUndeployOrder());
| > }
| > -
| > +
| > public void testMultipleOutput() throws Exception
| > {
| > DeployerClient main = createMainDeployer();
| > @@ -453,11 +453,11 @@
| > main.addDeployment(deployment);
| > main.process();
| >
| > - assertEquals(1, deployer1.getDeployOrder());
| > - assertEquals(2, deployer2.getDeployOrder());
| > - assertEquals(3, deployer3.getDeployOrder());
| > - assertEquals(4, deployer4.getDeployOrder());
| > - assertEquals(5, deployer5.getDeployOrder());
| > + assertEquals(5, deployer1.getDeployOrder());
| > + assertEquals(4, deployer2.getDeployOrder());
| > + assertEquals(1, deployer3.getDeployOrder());
| > + assertEquals(2, deployer4.getDeployOrder());
| > + assertEquals(3, deployer5.getDeployOrder());
| > assertEquals(6, deployer6.getDeployOrder());
| > assertEquals(-1, deployer1.getUndeployOrder());
| > assertEquals(-1, deployer2.getUndeployOrder());
| > @@ -469,33 +469,33 @@
| > main.removeDeployment(deployment);
| > main.process();
| >
| > - assertEquals(1, deployer1.getDeployOrder());
| > - assertEquals(2, deployer2.getDeployOrder());
| > - assertEquals(3, deployer3.getDeployOrder());
| > - assertEquals(4, deployer4.getDeployOrder());
| > - assertEquals(5, deployer5.getDeployOrder());
| > + assertEquals(5, deployer1.getDeployOrder());
| > + assertEquals(4, deployer2.getDeployOrder());
| > + assertEquals(1, deployer3.getDeployOrder());
| > + assertEquals(2, deployer4.getDeployOrder());
| > + assertEquals(3, deployer5.getDeployOrder());
| > assertEquals(6, deployer6.getDeployOrder());
| > - assertEquals(12, deployer1.getUndeployOrder());
| > - assertEquals(11, deployer2.getUndeployOrder());
| > - assertEquals(10, deployer3.getUndeployOrder());
| > - assertEquals(9, deployer4.getUndeployOrder());
| > - assertEquals(8, deployer5.getUndeployOrder());
| > + assertEquals(8, deployer1.getUndeployOrder());
| > + assertEquals(9, deployer2.getUndeployOrder());
| > + assertEquals(12, deployer3.getUndeployOrder());
| > + assertEquals(11, deployer4.getUndeployOrder());
| > + assertEquals(10, deployer5.getUndeployOrder());
| > assertEquals(7, deployer6.getUndeployOrder());
| >
| > main.addDeployment(deployment);
| > main.process();
| >
| > - assertEquals(13, deployer1.getDeployOrder());
| > - assertEquals(14, deployer2.getDeployOrder());
| > - assertEquals(15, deployer3.getDeployOrder());
| > - assertEquals(16, deployer4.getDeployOrder());
| > - assertEquals(17, deployer5.getDeployOrder());
| > + assertEquals(17, deployer1.getDeployOrder());
| > + assertEquals(16, deployer2.getDeployOrder());
| > + assertEquals(13, deployer3.getDeployOrder());
| > + assertEquals(14, deployer4.getDeployOrder());
| > + assertEquals(15, deployer5.getDeployOrder());
| > assertEquals(18, deployer6.getDeployOrder());
| > - assertEquals(12, deployer1.getUndeployOrder());
| > - assertEquals(11, deployer2.getUndeployOrder());
| > - assertEquals(10, deployer3.getUndeployOrder());
| > - assertEquals(9, deployer4.getUndeployOrder());
| > - assertEquals(8, deployer5.getUndeployOrder());
| > + assertEquals(8, deployer1.getUndeployOrder());
| > + assertEquals(9, deployer2.getUndeployOrder());
| > + assertEquals(12, deployer3.getUndeployOrder());
| > + assertEquals(11, deployer4.getUndeployOrder());
| > + assertEquals(10, deployer5.getUndeployOrder());
| > assertEquals(7, deployer6.getUndeployOrder());
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061289#4061289
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061289
19 years
[Design of JBossCache] - Re: JBossCache 2.1.0 - AOP framework
by adrian＠jboss.org
Of course you should use JBoss AOP. I can think of a number of reaons,
but probably the most compelling for you (and me but more importantly users :-) are:
1) If you have problems it is relatively trivial to get a fix/resolution in a "one stop shop"
at jboss.org
2) A user doesn't need to understand two sets of configuration to configure JBoss Cache
with other JBoss AOP usage in the same application (e.g. JBoss AS)
3) It's possible to use JBoss AOP without any "weaving" (either compile time
or load time) with the JBoss AOP proxy
e.g. the JCA prototype does exactly what you are doing (implement a project
using AOP for the design) but adds the AOP "on the fly" without any special help
from the classloading.
4) JBoss AOP works. Its unlikely that your own handwritten framework
has had the same amount of exposure to testing. It almost certainly contains more
bugs. :-)
5) Aspects written for other projects are usuable in your project (and vice versa)
6) There are some interesting features in the JBoss AOP/MC integration
that are not available anywhere else. One trivial example is the
"bind my object into JMX".
| @JMX
| public class CacheImpl {}
|
Whether it actually does bind it into JMX is dependent not upon you
writing code to do this, but adding the aspect to the aop config to say
what the annotation @JMX means.
No such aspect means there is no binding, and you can choose
what the implementation of the aspect is according the environment.
But there are other more interesting examples, such as proper
dependency management of aspects applied to a bean, e.g.
| @Tx(TxAttribute.REQUIRED)
| public class MyClass {}
|
But @Tx introduces the transaction demaraction aspect
which has a dependency on the transaction manager
| @Aspect
| public class TransactionDemarcation
| {
| @Inject
| public void setTransactionManager(TransactionManager tm) {}
|
| public Object invoke(Invocation) throws Throwable {}
| }
|
Only with JBoss AOP/MC does this transient dependency get recognised
and properly resolved, i.e. MyClass won't be installed until
TransactionDemarcation is installed which in turn requires the TransactionManager
installed.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061275#4061275
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061275
19 years