Enterprise Integration Zone is brought to you in partnership with:

Ales has posted 6 posts at DZone. View Full User Profile

A Look Inside JBoss Microcontainer, Part II – Advanced Dependency Injection and IoC

12.29.2008
| 34417 views |
  • submit to reddit

Today, Dependency injection (DI), or Inversion of Control (IoC), lies at the core of many frameworks that espouse the notion of a container or a component model. We discussed component models in my previous Microcontainer (MC) article. JBoss’ old JMX kernal provided lightweight DI/IoC support primarily due to the limitations of accessing mbeans through the mbean server; however with the new POJO-based component model, we have introduced several new and interesting features.

In this article, I will show how you can apply different DI concepts with the help of the JBoss Microcontainer. These concepts will be expressed via XML code (-beans.xml files), but you can also apply most of these features using annotations.

Since nothing speaks better than code when explaining DI/IoC, we'll go step by step over the code examples.

Read the other parts in DZone's exclusive JBoss Microcontainer Series:

 

Demo environment setup

To refresh the demo configuration from my previous article, let's quickly go over what we need to do to get this demo running in our IDE.

Before we begin, I'd like to first describe the various parts that constitute the demo. All the source code can be found at the following location in our Subversion repository:

    * http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/branches/DZone_1_0/

The project is fully mavenized, so it should be easy to adjust it to your IDE.

I will first go over the sub-projects within the demo and describe their usage. At the end of my article series, I will provide a more detailed look at what certain sub-projects do.

Below are the JBoss Microcontainer demos and sub-projects that are relevant for this article:

    * bootstrap (as the name suggests, it bootstraps the Microcontainer with demo code)
    * jmx (adds the JMX/AOP notion to demo's bootstrap)
    * ioc (source code of our ioc examples)

 
The demo has only one variable you need to set - demos home - but even this one can be optional if you checked-out your project into the \projects\demos directory. Otherwise, you need to set the system property demos.home (e.g. -Ddemos.home=<my demos home>). You should now be able to run JMXMain as a main class. In this case jmx classpath is enough, as ioc sub-project doesn't require any additional entry on classpath. Once the Microcontainer is booted it starts to scan the ${demos.home}/sandbox directory for any changes. Now all we need to do is provide a deployable unit and drop it in there.


Advanced IoC

We won't look into simple injection examples, as this should be obvious to most readers. Configuring attributes/setters with primitive or simple values or other beans is something we see all the time. I'll try to show you some of the stuff we feel is unique (OK, not all of it is unique, some features explained are just really cool :-).

I'll go over how some of the examples relate to one another, where applicable.  Most of the examples however, are independent of each other.
 

Value factory (value-factory-beans.xml)
 
Sometimes we want some bean just to act as a value factory - meaning we want to use one of its methods to generate some value for us.

<bean name="Binding" class="org.jboss.demos.ioc.vf.PortBindingManager">
<constructor>
<parameter>
<map keyClass="java.lang.String" valueClass="java.lang.Integer">
<entry>
<key>http</key>
<value>80</value>
</entry>
<entry>
<key>ssh</key>
<value>22</value>
</entry>
</map>
</parameter>
</constructor>
</bean>
<bean name="PortsConfig" class="org.jboss.demos.ioc.vf.PortsConfig">
<property name="http"><value-factory bean="Binding" method="getPort" parameter="http"/></property>
<property name="ssh"><value-factory bean="Binding" method="getPort" parameter="ssh"/></property>
<property name="ftp">
<value-factory bean="Binding" method="getPort">
<parameter>ftp</parameter>
<parameter>21</parameter>
</value-factory>
</property>
<property name="mail">
<value-factory bean="Binding" method="getPort">
<parameter>mail</parameter>
<parameter>25</parameter>
</value-factory>
</property>
</bean>

Here we can see how the PortsConfig bean is using Binding bean to get its values via getPort metod invocation.

public class PortBindingManager
{
private Map<String, Integer> bindings;
public PortBindingManager(Map<String, Integer> bindings)
{
this.bindings = bindings;
}
public Integer getPort(String key)
{
return getPort(key, null);
}
public Integer getPort(String key, Integer defaultValue)
{
if (bindings == null)
return defaultValue;
Integer value = bindings.get(key);
if (value != null)
return value;
if (defaultValue != null)
bindings.put(key, defaultValue);
return defaultValue;
}
}

Callbacks (callback-beans.xml)

A lot of times we want to 'collect' all beans of a certain type. We might even limit the number of matching beans that makes sense for our bean.
 
<bean name="checker" class="org.jboss.demos.ioc.callback.Checker">
<constructor>
<parameter>
<value-factory bean="parser" method="parse">
<parameter>
<array elementClass="java.lang.Object">
<value>http://www.jboss.org</value>
<value>SI</value>
<value>3.14</value>
<value>42</value>
</array>
</parameter>
</value-factory>
</parameter>
</constructor>
</bean>
<bean name="editorA" class="org.jboss.demos.ioc.callback.DoubleEditor"/>
<bean name="editorB" class="org.jboss.demos.ioc.callback.LocaleEditor"/>
<bean name="parser" class="org.jboss.demos.ioc.callback.Parser">
<incallback method="addEditor" cardinality="4..n"/>
<uncallback method="removeEditor"/>
</bean>
<bean name="editorC" class="org.jboss.demos.ioc.callback.LongEditor"/>
<bean name="editorD" class="org.jboss.demos.ioc.callback.URLEditor"/>

In this case we have a Parser that collects all Editors.  We see this from the method's signature:

public class Parser
{
private Set<Editor> editors = new HashSet<Editor>();
...
public void addEditor(Editor editor)
{
editors.add(editor);
}
public void removeEditor(Editor editor)
{
editors.remove(editor);
}
}

Note: see incallback and uncallback - they match via method name.

    <incallback method="addEditor" cardinality="4..n"/>
<uncallback method="removeEditor"/>

And we also put a bottom limit on how many editors actually make this bean progress from a Configured state. 
cardinality=4..n/>
Eventually, Checker gets created and checks the parser

   public void create() throws Throwable
{
Set<String> strings = new TreeSet<String>(String.CASE_INSENSITIVE_ORDER);
for (Object element : elements)
strings.add(element.toString());
if (expected.equals(strings) == false)
throw new IllegalArgumentException("Illegal expected set: " + expected + "!=" + strings);
}

Bean access mode (access-mode-beans.xml)

By default we don't inspect a bean's fields; however, if  you specify a different BeanAccessMode, the fields will be part of the bean's properties.

public enum BeanAccessMode
{
STANDARD(BeanInfoCreator.STANDARD), // Getters and Setters
FIELDS(BeanInfoCreator.FIELDS), // Getters/Setters and fields without getters and setters
ALL(BeanInfoCreator.ALL); // As above but with non public fields included

Here we set a String value to a private String field:
<bean name="FieldsBean" class="org.jboss.demos.ioc.access.FieldsBean" access-mode="ALL">
<property name="string">InternalString</property>
</bean>

public class FieldsBean
{
private String string;
public void start()
{
if (string == null)
throw new IllegalArgumentException("Strings should be set!");
}
}

Bean alias (aliases-beans.xml)

Each bean can have any number of aliases. Since we treat Microcontainer component names as Objects, we don't limit the alias type. By default we don't do a system property replacement - you need to set the replace flag explicitly.

  <bean name="SimpleName" class="java.lang.Object">
<alias>SimpleAlias</alias>
<alias replace="true">${some.system.property}</alias>
<alias class="java.lang.Integer">12345</alias>
<alias><javabean xmlns="urn:jboss:javabean:2.0" class="org.jboss.demos.bootstrap.Main"/></alias>
</bean>
 
XML (or MetaData) annotations support (annotations-beans.xml)


AOP support is a first class citizen in JBoss Microcontainer, hence we can mix and match AOP aspects and plain beans. In this example we'll try to intercept a method invocation based on an annotation. The cool part is that we don't care where this annotation comes from. It could be a true class annotation or an annotation added through the xml configuration.
 
<interceptor xmlns="urn:jboss:aop-beans:1.0" name="StopWatchInterceptor" class="org.jboss.demos.ioc.annotations.StopWatchInterceptor"/>

<bind xmlns="urn:jboss:aop-beans:1.0" pointcut="execution(* @org.jboss.demos.ioc.annotations.StopWatchLog->*(..)) OR execution(* *->@org.jboss.demos.ioc.annotations.StopWatchLog(..))">
<interceptor-ref name="StopWatchInterceptor"/>
</bind>
</interceptor>
 
public class StopWatchInterceptor implements Interceptor
{
...
public Object invoke(Invocation invocation) throws Throwable
{
Object target = invocation.getTargetObject();
long time = System.currentTimeMillis();
log.info("Invocation [" + target + "] start: " + time);
try
{
return invocation.invokeNext();
}
finally
{
log.info("Invocation [" + target + "] time: " + (System.currentTimeMillis() - time));
}
}
}

And true class annotated executor:

<bean name="AnnotatedExecutor" class="org.jboss.demos.ioc.annotations.AnnotatedExecutor">
 
public class AnnotatedExecutor implements Executor
{
...
@StopWatchLog // <-- Pointcut match!
public void execute() throws Exception
{
delegate.execute();
}
}

Simple executor with xml annotation:
  <bean name="SimpleExecutor" class="org.jboss.demos.ioc.annotations.SimpleExecutor">
<annotation>@org.jboss.demos.ioc.annotations.StopWatchLog</annotation> // <-- Pointcut match!
</bean>

public class SimpleExecutor implements Executor
{
private static Random random = new Random();
public void execute() throws Exception
{
Thread.sleep(Math.abs(random.nextLong() % 101));
}
}

We add some executor invoker bean, so that we see those executors in action during deployment:


JBoss-MC-Demo  INFO [15-12-2008 13:57:39] StopWatch - Invocation [org.jboss.demos.ioc.annotations.AnnotatedExecutor@4d28c7] start: 1229345859234
JBoss-MC-Demo  INFO [15-12-2008 13:57:39] StopWatch - Invocation [org.jboss.demos.ioc.annotations.AnnotatedExecutor@4d28c7] time: 31
JBoss-MC-Demo  INFO [15-12-2008 13:57:39] StopWatch - Invocation [org.jboss.demos.ioc.annotations.SimpleExecutor@1b044df] start: 1229345859265
JBoss-MC-Demo  INFO [15-12-2008 13:57:39] StopWatch - Invocation [org.jboss.demos.ioc.annotations.SimpleExecutor@1b044df] time: 47

 

Autowire (autowire-beans.xml)

Autowiring, or contextual injection, is a common feature with IoC frameworks.
The following shows you how to use or exclude beans with autowiring.

  <bean name="Square" class="org.jboss.demos.ioc.autowire.Square" autowire-candidate="false"/>
<bean name="Circle" class="org.jboss.demos.ioc.autowire.Circle"/>
<bean name="ShapeUser" class="org.jboss.demos.ioc.autowire.ShapeUser">
<constructor>
<parameter><inject/></parameter>
</constructor>
</bean>
<bean name="ShapeHolder" class="org.jboss.demos.ioc.autowire.ShapeHolder">
<incallback method="addShape"/>
<uncallback method="removeShape"/>
</bean>
<bean name="ShapeChecker" class="org.jboss.demos.ioc.autowire.ShapesChecker"/>

In both cases - ShapeUser and ShapeChecker - it should be only Circle that is used, as Square is excluded in the contextual binding.


Bean factory (bean-factory-beans.xml)

When we want more than one instance of some bean, we need to use the bean factory pattern. The job of the Microcontainer is to configure and install the bean factory as if it were a plain bean. Our job is then to invoke the bean factory's createBean method.

By default, the Microcontainer creates a GenericBeanFactory instance, but you can configure your own factory. The only limitation is that its signature / configuration hooks are similar to the one of AbstractBeanFactory.

  <bean name="Object" class="java.lang.Object"/>
<beanfactory name="DefaultPrototype" class="org.jboss.demos.ioc.factory.Prototype">
<property name="value"><inject bean="Object"/></property>
</beanfactory>
<beanfactory name="EnhancedPrototype" class="org.jboss.demos.ioc.factory.Prototype" factoryClass="org.jboss.demos.ioc.factory.EnhancedBeanFactory">
<property name="value"><inject bean="Object"/></property>
</beanfactory>
<beanfactory name="ProxiedPrototype" class="org.jboss.demos.ioc.factory.UnmodifiablePrototype" factoryClass="org.jboss.demos.ioc.factory.EnhancedBeanFactory">
<property name="value"><inject bean="Object"/></property>
</beanfactory>
<bean name="PrototypeCreator" class="org.jboss.demos.ioc.factory.PrototypeCreator">
<property name="default"><inject bean="DefaultPrototype"/></property>
<property name="enhanced"><inject bean="EnhancedPrototype"/></property>
<property name="proxied"><inject bean="ProxiedPrototype"/></property>
</bean>

Here you can see an example of such extended BeanFactory usage:

public class EnhancedBeanFactory extends GenericBeanFactory
{
public EnhancedBeanFactory(KernelConfigurator configurator)
{
super(configurator);
}
public Object createBean() throws Throwable
{
Object bean = super.createBean();
Class<?> clazz = bean.getClass();
if (clazz.isAnnotationPresent(SetterProxy.class))
{
Set<Class> interfaces = new HashSet<Class>();
addInterfaces(clazz, interfaces);
return Proxy.newProxyInstance(
clazz.getClassLoader(),
interfaces.toArray(new Class<?>[interfaces.size()]),
new SetterInterceptor(bean)
);
}
else
{
return bean;
}
}
protected static void addInterfaces(Class<?> clazz, Set<Class> interfaces)
{
if (clazz == null)
return;
interfaces.addAll(Arrays.asList(clazz.getInterfaces()));
addInterfaces(clazz.getSuperclass(), interfaces);
}
private class SetterInterceptor implements InvocationHandler
{
private Object target;
private SetterInterceptor(Object target)
{
this.target = target;
}
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable
{
String methodName = method.getName();
if (methodName.startsWith("set"))
throw new IllegalArgumentException("Cannot invoke setters.");
return method.invoke(target, args);
}
}
}

public class PrototypeCreator
{
...
public void create() throws Throwable
{
ValueInvoker vi1 = (ValueInvoker)bfDefault.createBean();
vi1.setValue("default");
ValueInvoker vi2 = (ValueInvoker)enhanced.createBean();
vi2.setValue("enhanced");
ValueInvoker vi3 = (ValueInvoker)proxied.createBean();
try
{
vi3.setValue("default");
throw new Error("Should not be here.");
}
catch (Exception ignored)
{
}
}

 
Bean Meta Data Builder (builder-util-beans.xml)

When using the Microcontainer in your code, we suggest using BeanMetaDataBuilder to configure/create your bean metadata.
 
<bean name="BuilderUtil" class="org.jboss.demos.ioc.builder.BuilderUtil"/>
<bean name="BuilderExampleHolder" class="org.jboss.demos.ioc.builder.BuilderExampleHolder">
<constructor>
<parameter><inject bean="BUExample"/></parameter>
</constructor>
</bean>

Using this concept you don't expose your code to any Microcontainer implementation details.

public class BuilderUtil
{
private KernelController controller;
@Constructor
public BuilderUtil(@Inject(bean = KernelConstants.KERNEL_CONTROLLER_NAME) KernelController controller)
{
this.controller = controller;
}
public void create() throws Throwable
{
BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder("BUExample", BuilderExample.class.getName());
builder.addStartParameter(Kernel.class.getName(), builder.createInject(KernelConstants.KERNEL_NAME));
controller.install(builder.getBeanMetaData());
}
public void destroy()
{
controller.uninstall("BUExample");
}
}


 
Custom ClassLoader (classloader-beans.xml)

In the Microcontainer you can even define a custom ClassLoader per bean.

When defining a classloader as per the whole deployment, make sure you don't create a cyclic dependency -- for instance, a newly defined classloader that depends on itself.

  <classloader><inject bean="custom-classloader:0.0.0"/></classloader>
<!-- this will be explained in future article -->
<classloader name="custom-classloader" xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY" import-all="true"/>
<bean name="CustomCL" class="org.jboss.demos.ioc.classloader.CustomClassLoader">
<constructor>
<parameter><inject bean="custom-classloader:0.0.0"/></parameter>
</constructor>
<property name="pattern">org\.jboss\.demos\.ioc\..+</property>
</bean>
<bean name="CB1" class="org.jboss.demos.ioc.classloader.CustomBean"/>
<bean name="CB2" class="org.jboss.demos.ioc.classloader.CustomBean">
<classloader><inject bean="CustomCL"/></classloader>
</bean>


Here you can see that CB2 bean uses a custom ClassLoader, which limits the loadable package scope:

public class CustomClassLoader extends ClassLoader
{
private Pattern pattern;
public CustomClassLoader(ClassLoader parent)
{
super(parent);
}
public Class<?> loadClass(String name) throws ClassNotFoundException
{
if (pattern == null || pattern.matcher(name).matches())
return super.loadClass(name);
else
throw new ClassNotFoundException("Name '" + name + "' doesn't match pattern: " + pattern);
}
public void setPattern(String regexp)
{
pattern = Pattern.compile(regexp);
}
}

 
Controller Mode (controller-mode-beans.xml)

By default the Microcontainer uses the AUTO controller mode - meaning it pushes beans as far as they go with respect to dependencies. But there are two other modes - MANUAL and ON_DEMAND which do exactly what their names suggest.

If the bean is marked as ON_DEMAND, it won't be used / installed until some other bean explicitly depends on it. In the Manual mode, it's up to the Microcontainer user to push the bean forward and backwards along the state ladder.

  <bean name="OptionalService" class="org.jboss.demos.ioc.mode.OptionalService" mode="On Demand"/>
<bean name="OptionalServiceUser" class="org.jboss.demos.ioc.mode.OptionalServiceUser"/>
<bean name="ManualService" class="org.jboss.demos.ioc.mode.ManualService" mode="Manual"/>
<bean name="ManualServiceUser" class="org.jboss.demos.ioc.mode.ManualServiceUser">
<start>
<parameter><inject bean="ManualService" fromContext="context" state="Not Installed"/></parameter>
</start>
</bean>

Note: see inject's fromContext attribute. Here, we can inject not only beans, but their unmodifiable Microcontainer component representation as well.

Check the code of OptionalServiceUser and ManualServiceUser on how to use the Microcontainer API for ON_DEMAND and MANUAL bean handling.

 
Cycle (cycle-beans.xml)

Sometimes beans depend on each other in a cycle. For instance A depends on B at construction, where B depends on A at setter. Due to the Microcontainer’s fine-grained state lifecycle separation, we can solve such problems fairly easily. 

  <bean name="cycleA" class="org.jboss.demos.ioc.cycle.CyclePojo">
<property name="dependency"><inject bean="cycleB"/></property>
</bean>
<bean name="cycleB" class="org.jboss.demos.ioc.cycle.CyclePojo">
<constructor><parameter><inject bean="cycleA" state="Instantiated"/></parameter></constructor>
</bean>
<bean name="cycleC" class="org.jboss.demos.ioc.cycle.CyclePojo">
<property name="dependency"><inject bean="cycleD"/></property>
</bean>
<bean name="cycleD" class="org.jboss.demos.ioc.cycle.CyclePojo">
<property name="dependency"><inject bean="cycleC" state="Instantiated"/></property>
</bean>
 

Demand / Supply (demand-supply-beans.xml)

Sometimes,  a dependency is not explicitly known, such as an injection; however, there may still be a dependency between two beans, such as static code usage. This should be expressed in a clear way:
  <bean name="TMDemand" class="org.jboss.demos.ioc.demandsupply.TMDemander">
<demand>TM</demand>
</bean>
<bean name="SimpleTMSupply" class="org.jboss.demos.ioc.demandsupply.SimpleTMSupplyer">
<supply>TM</supply>
</bean>

 
 Installs (install-beans.xml)

As our bean moves through states we might want to invoke some methods (actions) on other beans or the same bean.

Here we can see how Entry invokes RepositoryManager's add/removeEntry method to register/unregister itself.

  <bean name="RepositoryManager" class="org.jboss.demos.ioc.install.RepositoryManager">
<install method="addEntry">
<parameter><inject fromContext="name"/></parameter>
<parameter><this/></parameter>
</install>
<uninstall method="removeEntry">
<parameter><inject fromContext="name"/></parameter>
</uninstall>
</bean>
<bean name="Entry" class="org.jboss.demos.ioc.install.SimpleEntry">
<install bean="RepositoryManager" method="addEntry" state="Instantiated">
<parameter><inject fromContext="name"/></parameter>
<parameter><this/></parameter>
</install>
<uninstall bean="RepositoryManager" method="removeEntry" state="Configured">
<parameter><inject fromContext="name"/></parameter>
</uninstall>
</bean>


 
Lazy (lazy-beans.xml)

We might have a dependecy on a bean that is rarely used but it takes a long time to configure. We can use a lazy mock of the bean, so that the dependency gets resolved, but when we actually need the bean, we will invoke / use the target bean - hoping it has been installed by then.
  <bean name="lazyA" class="org.jboss.demos.ioc.lazy.LazyImpl">
<constructor>
<parameter>
<lazy bean="lazyB">
<interface>org.jboss.demos.ioc.lazy.ILazyPojo</interface>
</lazy>
</parameter>
</constructor>
</bean>
<bean name="lazyB" class="org.jboss.demos.ioc.lazy.LazyImpl">
<constructor>
<parameter>
<lazy bean="lazyA">
<interface>org.jboss.demos.ioc.lazy.ILazyPojo</interface>
</lazy>
</parameter>
</constructor>
</bean>
<lazy name="anotherLazy" bean="Pojo" exposeClass="true"/>
<bean name="Pojo" class="org.jboss.demos.ioc.lazy.Pojo"/>

Lifecycle (lifecycle-beans.xml)


By default the Microcontainer uses create/start/stop/destroy methods when it moves through the various states; however, we may not want the Microcontainer to invoke them. Hence we can set an ignore flag.

  <bean name="FullLifecycleBean-3" class="org.jboss.demos.ioc.lifecycle.FullLifecycleBean"/>
<bean name="FullLifecycleBean-2" class="org.jboss.demos.ioc.lifecycle.FullLifecycleBean">
<create ignored="true"/>
</bean>
<bean name="FullLifecycleBean-1" class="org.jboss.demos.ioc.lifecycle.FullLifecycleBean">
<start ignored="true"/>
</bean>


Summary

In this article, I showed you how to apply different DI concepts with the help of the JBoss Microcontainer. The Microcontainer provides a comprehensive range of DI/IoC capabilities.

Joining that with a modular design, a clean split into metadata driven deployment and an extensible state machine, you can nicely integrate any additional features you feel are missing. Nevertheless, the Microcontainer team still has some ideas on addition features it would like to add and is always open to your suggestions.

In my next article I'll present the Microcontainer’s Virtual File System (VFS) project. This will provide a nice prelude for subsequent articles on Microcontainer ClassLoading and the Deployment framework.

 

About the Author

Ales Justin was born in Ljubljana, Slovenia and graduated with a degree in mathematics from the University of Ljubljana. He fell in love with Java seven years ago and has spent most of his time developing information systems, ranging from customer service to energy management. He joined JBoss in 2006 to work full time on the Microcontainer project, currently serving as its lead. He also contributes to JBoss AS and is Seam and Spring integration specialist. He represent JBoss on 'JSR-291 Dynamic Component Support for Java SE' and 'OSGi' expert groups.

 

 

Published at DZone with permission of its author, Ales Justin.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Liam Knox replied on Mon, 2008/12/29 - 8:04pm

Why do people keep reinventing wheels and which genius actually pays for this work?

Andrew McVeigh replied on Mon, 2008/12/29 - 8:51pm

Why do people keep reinventing wheels

because they don't like the people who made the original wheels.

and which genius actually pays for this work?

redhat ;-)

 

Ales Justin replied on Tue, 2008/12/30 - 4:18am in response to: Liam Knox

[quote=knoxl]Why do people keep reinventing wheels?[/quote]

Why do you see this as reinventing the wheel?

You should at least bother to explain or else this is meaningless fud.

 

Did you bother to read the 1st article or even this one?

If things did what we wanted to do, I would be more than happy not to write another DI/IoC framework.

It's not like I have nothing else to do - see the whole scope of Microcontainer project. ;-)

[quote=knoxl]which genius actually pays for this work?[/quote]

The one with a vision?

Liam Knox replied on Tue, 2008/12/30 - 6:06am in response to: Ales Justin

Everheard of Spring?

I suppose I could write my own DI container, but why wouldnt I just pick up Spring which is by far the most evolved and well designed framework available.

What does this address that Spring does not? And if Spring doesnt, wouldnt you prefer them to incoporate this rather than end up with yet another mutated variant that is in no doubt lacking in a mirad of other fields?

I would also punt that if Spring doesnt support it, it is more likely to be a undesired practice than some amazing feature they have missed.

 

Liam Knox replied on Tue, 2008/12/30 - 6:12am in response to: Ales Justin

Just looked at the site and its changed my opinion. Yep looks like a really big wheel reinvent and a total waste of time. 

Why not do some application development rather rewriting frameworks?  It's probably alot more interesting, beneficial to man kind as a whole and pays a hell of a lot more.

Joshua Partogi replied on Tue, 2008/12/30 - 8:08am

Is there any reason why we should use JBoss MC instead of WebBeans ?

regards, 

Alex(JAlexoid) ... replied on Tue, 2008/12/30 - 9:51am in response to: Liam Knox

FYI: The key(part of a)word here is "micro-" and there is NOTHING micro about Spring these days.

Ales Justin replied on Tue, 2008/12/30 - 11:12am in response to: Liam Knox

[quote=knoxl]

Everheard of Spring?

I suppose I could write my own DI container, but why wouldnt I just pick up Spring which is by far the most evolved and well designed framework available.

What does this address that Spring does not? And if Spring doesnt, wouldnt you prefer them to incoporate this rather than end up with yet another mutated variant that is in no doubt lacking in a mirad of other fields?

I would also punt that if Spring doesnt support it, it is more likely to be a undesired practice than some amazing feature they have missed.

[/quote]

What are you trying to show here?

That your love for Spring is so big you would kiss RJ's ass right now,

as you do here: http://java.dzone.com/articles/the-cost-springsource-enterpri#comment-7032

 

C'mon, make argumented comments or stay away from exposing your ignorance.

 

Ales Justin replied on Tue, 2008/12/30 - 11:21am in response to: Liam Knox

[quote=knoxl]

Just looked at the site and its changed my opinion. Yep looks like a really big wheel reinvent and a total waste of time. 

[/quote]

Uh, oh, I guess you need to stay back with your 'original' Spring toys

as it seems you don't understand, bother to look-in-to and/or appreciate any other work.

 

[quote=knoxl]

Why not do some application development rather rewriting frameworks?  It's probably alot more interesting, beneficial to man kind as a whole and pays a hell of a lot more.

[/quote]

Last time I checked, we - JBoss - were middleware company, very successful at what we do.

But I guess you're right, I heard a lot about you and your profit making + saving the world apps,

so I'll probably change my profession after your another 'helpful' comment. ;-)

Ales Justin replied on Tue, 2008/12/30 - 11:40am in response to: Joshua Partogi

[quote=thejavafreak]

Is there any reason why we should use JBoss MC instead of WebBeans ?

[/quote]

MC and WB address different layers / levels of usage.

 - MC is hidden / transparent layer at a core app server level

 - WB is user layer, your app uses this extensively

 

You would use MC if you wrote some low level service for JBoss AS (or some other MC driven env),

and even then you should use as little as explicit dependecies on it.

Where you would use WB as Seam + Guice on steroids.

 

FYI: WebBeans RI Alpha 1.0 runs in JBoss5 with a help of MC's integration:

 - http://anonsvn.jboss.org/repos/jbossas/projects/webbeans-ri-int/trunk/

 

Eventually you could even favor MC over WB,

since they overlap at DI/IoC concepts,

but WB gives more user friendly access there - that's its purpose.

But as I was hopelessly trying to explain to knoxl,

MC is a lot more than DI/IoC, its real straingth is in the whole sub-project pieces,

which are at the same time tightly integrated as well as conceptually / architecturally differentiated.

Ales Justin replied on Tue, 2008/12/30 - 11:51am in response to: Alex(JAlexoid) Panzin

[quote=jalexoid]FYI: The key(part of a)word here is "micro-" and there is NOTHING micro about Spring these days.[/quote]

:-)

Although they do have a nice split between modules,

my only feeling is that that split doesn't make too much sense and it's too fine grained.

I guess it benefits the user (on which libs to depend - as you should aim at not depending at all),

but it doesn't benefit the developer that would like to override some aspect of it.

 

With MC, DI/IoC is just a few interfaces/classes.

If it wasn't for my Callback, we would still be at 5 interfaces. :-)

It's all metadata driven, so it's all trivial to change.

We're not even tied to states or corresponding actions.

Liam Knox replied on Tue, 2008/12/30 - 6:59pm in response to: Ales Justin

Obviously feel very passionate regarding your wheel reinvents, so much so as you have to regressed to foul language, without answering fundamentally what you are addressing in your work?

If you think the question of what are you benefit is ignorant, and answer as you do in this way you really dont have any reason to post anything.

Personally I was looking at this post and trying to see what the point is, I honestly cant.  I would also argue about other frameworks such as Guice, but atleast here there was originality in the annotaion approach which influenced Spring 2.5. 

Why not build on something that is fundamentally better than the old EJB debacle rather than reinventing it, wasting effort and providing a regression in technology as a whole.  Its slightly counter to Darwins theory of evolution atleast.  

Liam Knox replied on Tue, 2008/12/30 - 7:08pm in response to: Ales Justin

np, thank you for your recent posts, they are really a usefull demonstration in the inability to take criticism and to justify any of this work, even more so than the actual subject of the original post :-)

for anyone else interested in the afore mentioned 'toys' , heres a link

http://www.springsource.org/

I can gurantee you will see far more desire for this skillset on your CV, rather than the cheap immotations 

PS: Perhaps you can write us a paper on the greatness of cyclic object graphs also ?

 

Alex(JAlexoid) ... replied on Tue, 2008/12/30 - 7:48pm in response to: Liam Knox

Really, you don't seem to understand the reasons for having a specialized/custom solution then. And it's nothing to do with spring.

Oh, and BTW thank you for starting a flame war over nothing.

And for the skillset, I believe that there is more than enough demmand to have an engineer that actually worked on JBoss internals, where JBoss is installed. And JBoss Microkernel does not seem like a cheap immitation.

I myself have no Spring on my own CV and I don't have/forsee any issues with employment.

To the author, thank you for sharing the inner workings of one of the opensource JEE servers.

Good night, and good last year's day.

Ales Justin replied on Wed, 2008/12/31 - 6:26am in response to: Liam Knox

[quote=knoxl]

without answering fundamentally what you are addressing in your work?

[/quote] 

Fundamentally to what?

Since the title is not MC's DI/IoC vs. other DI/IoCs, I cannot go and compare features to whatever.

It's an introduction to our DI/IoC, touching the subjects we feel are missing or we do it differently.

 

[quote=knoxl]

I would also argue about other frameworks such as Guice, but atleast here there was originality in the annotaion approach which influenced Spring 2.5. 

[/quote] 

Aha, it this case it's an 'influence', not a re-invent.

Nice to see you have double standards. ;-)

 

[quote=knoxl]

Why not build on something that is fundamentally better than the old EJB debacle rather than reinventing it, wasting effort and providing a regression in technology as a whole.  Its slightly counter to Darwins theory of evolution atleast.  

[/quote]

Looks like you're still stuck in 2002:

 - http://exitcondition.alrubinger.com/2008/12/04/its-not-2002/

Ales Justin replied on Wed, 2008/12/31 - 6:40am in response to: Liam Knox

[quote=knoxl]

to take criticism and to justify any of this work

[/quote]

You call that criticism?

All I see is non-argumented fud and foul posting/commenting manners.

 

[quote=knoxl]

I can gurantee you will see far more desire for this skillset on your CV

[/quote] 

This is actually a skill?

I thought knowing JPA, JTA, WS, ... was a skill, not some simple wrappers.

But yeah, like I already said, you stick to it, 'original' wheels and your RJ doll. ;-)

 

[quote=knoxl]

PS: Perhaps you can write us a paper on the greatness of cyclic object graphs also ?

[/quote]

What's your point again?

Andrew Rubinger replied on Wed, 2008/12/31 - 5:59pm

Knoxl makes every argument I'd expect of a seasoned POJO services developer, and I say this in complimentary fashion.

In fact, I had similar reservations upon joining JBoss and starting work on the EJB3 Implementation for AS5.  MC/Spring/Guice is a Map<String,Object> which knows how to do contextual injection.  What's the big deal?

I can share an example.

Over the past year or so, we've taken steps to apply component-oriented development to EJB3 with relation to its inclusion in AS; this means that we must both decouple and reintegrate at the same time. MC has been the primary facilitator in this effort largely due to the Virtual Deployment Framework.

VDF hasn't yet been covered in this series of articles, but is a powerful agent that lets us incrementally build up the metadata necessary to describe an application component. Each deployer (ideally) focuses on just one concern, thus enabling us to aspectize the way we inspect, prepare, and process deployments.  In Unit Testing we may apply the same deployment chain to test our EJB Containers in-process.  

And because of MC's design, each deployer is itself a simple bean that's installed into some known context.

MC is built to be used not only as a model for business logic, but also a runtime.  It's the extensions and facades that expose these lower-level services as some other desireable view (JMX, WebBeans, EJB, OSGi, there's even Spring integration)

By choosing MC as your core, you get the tools necessary to do real component development, a concept I've been continually moving toward.  Small, testable, little bits of code.  Use MC as the glue, and then extend from there to get your user APIs.  Other vendors are using POJO development to wrap around existing APIs to bring them together, so that's another difference.

I encourage everyone to continue to bash Ales; it'll make him look like a martyred hero once MC gains more traction as a standalone product and we all see the type of development it encourages.

S,
ALR

Liam Knox replied on Wed, 2008/12/31 - 7:35pm

For all the response so far I have not really seen that answer to,... what IS this work addressing ?

Its amazing.

You see so many posts here. Some sharing good information. Some talking randon abstract rubbish. Some just trying to justify there own existence.

I did not start ANY flame war.  The question of 'wheel/reivent' my comment is infintely pertinent.

 One statement to me 'You suck Rod Johnsone' Ar$E'

This is massively ironic from someone who has just basically rewritten his work and added anything?

I suppose copying is the most purest way of flattery. Iterms of your statement I suggest looking in the mirror for the culprit before I.  If you did this in the art world you would probably be behind bars, but hey this it IT so you can flog your cheap ripoffs everywhere.

Again, ANYONE  can you tell me what this article, technology is fundamentallly addressing and what current solutions out there do not addres ?

 

 

 

 

Liam Knox replied on Wed, 2008/12/31 - 8:02pm in response to: Ales Justin

JPA - Peristence right, some persistent API that trys address the fundamental conflict of a Relational and OO system.  It has been around in a milllions variations over the years .  FACT , OO - Relational will never be simply rationalised via code, xml  JSRs. You are better investing you time, if you have some, in investigating a technology rationalisation of persistence relative to OO that performs, rather than rewriting Spring. Chuck out SQL see whats left... come on its more interesting no ?

 JTA - Transactions right, I thought Spring/Annotations do a great job in isollating you from the bolier plate. Fundamentally they guaratee perstince check points.  I can imagine some leaps in imagination here reducing the complexity given the now cheapness of ram and failover.

WS, remoting? Yeah that old chessnut. Has RMI, Web Services added much to Corba conceptially ? EJB actually digressed based on local and remote ideas which was an absolute abortion.  

So the afore mention skills covered, lets return to IoC. It is an Idea and IMHO a good one that addressing object depencies.  Certain people have tried to provide a leg up on this and I believe Spring has provided the most complete and well though through.  I still question the purest thought of the idea, for example no one seems to advocate injecting Loggers everywhere, but if you follow IoC to the core this would be mandate.

On your question of cyclic graphs, my question is why do you want to support this in your container?

 

Liam Knox replied on Wed, 2008/12/31 - 8:10pm in response to: Andrew Rubinger

I dont really see from what you are saying, why should I use JBoss rather than Spring?

How many man days of developement will it given me? Pros vs Cons etc ?

 

 

Liam Knox replied on Wed, 2008/12/31 - 8:19pm in response to: Ales Justin

Given your unrationtilised and offensively idiotic approach to discussion I can only retaught.  Once you current role is defunct ( probably soon ), dont call us we'll call you ;-)

Joshua Partogi replied on Wed, 2008/12/31 - 8:33pm in response to: Ales Justin

[quote=alesj][quote=thejavafreak]

Is there any reason why we should use JBoss MC instead of WebBeans ?

[/quote]

MC and WB address different layers / levels of usage.

 - MC is hidden / transparent layer at a core app server level

 - WB is user layer, your app uses this extensively

 

You would use MC if you wrote some low level service for JBoss AS (or some other MC driven env),

and even then you should use as little as explicit dependecies on it.

Where you would use WB as Seam + Guice on steroids.

[/quote]

Thanks Ales, I get the basic idea and the right usage right now about both MC and WB. Cheers 

Andrew Rubinger replied on Wed, 2008/12/31 - 8:58pm in response to: Liam Knox

[quote=knoxl]I dont really see from what you are saying, why should I use JBoss rather than Spring?[/quote]

I've already discussed one feature exclusive to MC.  In my opinion, MC is best used to build from the inside out (ie. low-level is MC, but these details are hidden from the users and exposed via some API), while Spring might be focusing its strengths outside-in (wiring many API implementations together to piece a complete solution).  My experience w/ MC has lead to a different, and I believe more beneficial, way of thinking about archiecture.  Provide an agnostic and extensible core, then adapt to whichever APIs you'd like.  And JBoss has proved this to work by making AS5 backwards-compat with the 3.x/4.x JMX views, WebBeans Alpha work, etc, all based on MC.

[quote=knoxl]How many man days of developement will it given me? Pros vs Cons etc ?[/quote]

Man-days is subjective to any number of other factors, you know that. ;)

I've given you some pros.  Go play with MC and find some cons, post your concerns on the User Forum.  If your path is anything like mine, you'll find helpful responses to get you on your way.  Or take a look at our EJB3 Unit Tests, and see how we leverage MC to run EJB3 with some minimal support out of the container.

S,
ALR

 

 

Liam Knox replied on Thu, 2009/01/01 - 12:40am in response to: Andrew Rubinger

I still find your posts rather abstract, for example 'Provide an agnostic and extensible core, then adapt to whichever APIs you'd like'. 

Can you given me some tangible examples?  Given most Java APIs are just a set of objects/interfaces I would of thought IoC covers this.

Agreed Man Days is rather abstarct ;-) .

On the general EJB3 front I still dont see anything more compelling in it when you have Spring/AOP and a whole miriad of good open source libraries.  That they actually stick with the premise of an architecture that is evolving ( version/name etc ) is very perverse given they have done a 360 degree turn in direction based on a better open source alternative designed to answer the problem it created. 

Still seems having a Sun label , J2EE, EJB etc, turns some people on for some reason.  If you look at the history of this you will find these are not the only failing in Sun API designs, look at Date, Properties, Formating, Exception etc, Josh Bloch himself is critical on these. 

My main question is still, if you have already the best IoC framework available why would you choose rewriting rather than building apon?  As I have pointed out ( but some moron failed to observe ) , some visions, Guice etc, have benefits, but IMHO this was influencing a direction rather than what is delivers stand alone. 

Perhaps something better will come along, but it certainly will not be from someone renaming id to name as an xml attribute and plugging many man years in duplication.

 

Ales Justin replied on Thu, 2009/01/01 - 3:17pm in response to: Liam Knox

[quote=knoxl]

I did not start ANY flame war.  The question of 'wheel/reivent' my comment is infintely pertinent.

[/quote]

You must be either a moron (tag, you're it ;-) or blind. But probably in your case - both.

How can you claim such innocence, when all your post didn't touch the subject, were insulting, you didn't bother to look any deeper and were posting Spring pr.

-  "which genius actually pays for this work"

- "Everheard of Spring?"

- "and a total waste of time"

- ...

 

[quote=knoxl]

One statement to me 'You suck Rod Johnsone' Ar$E'

[/quote]

Sorry, but your hilarious/pathetic posts

 - http://java.dzone.com/articles/the-cost-springsource-enterpri#comment-7032 ("I think it best they just give the new JSR to Rod Johson")

 -  http://java.dzone.com/news/your-architecture-starts-be-su#comment-8887 ("Sorry Rob and Jurgeun you clearly have no ideas")

perfectyl fit with this 'colorful' remark.

 

[quote=knoxl]

This is massively ironic from someone who has just basically rewritten his work and added anything?

[/quote]

Again, did you bother to read first article?

I very much doubt you get component models mixture out-of-the-box with Spring. ;-)

 

[quote=knoxl]

I suppose copying is the most purest way of flattery. Iterms of your statement I suggest looking in the mirror for the culprit before I.  If you did this in the art world you would probably be behind bars, but hey this it IT so you can flog your cheap ripoffs everywhere.

[/quote]

Like Guice's 'influence' on Spring?

 

[quote=knoxl]

Again, ANYONE  can you tell me what this article, technology is fundamentallly addressing and what current solutions out there do not addres ?

[/quote]

I don't know in general what DI/IoC solutions do, as there is just too many 'original' wheels out there,

but my general feeling was that they don't do all of what we do, and this of course goes vice versa.

As I already tried to explain you, this is an intro of what we do, not what others don't.

Perhaps you could, instead of your idiotic (2nd tag, you're it) rambling, enlighten me, and compare my list of features against Spring's list?

 And we can then finally discuss them in a decent manner, either here or our user fourm.

 

Ales Justin replied on Thu, 2009/01/01 - 9:58am in response to: Liam Knox

[quote=knoxl]

On your question of cyclic graphs, my question is why do you want to support this in your container?

 [/quote]

You mean my cycle example?

We had a couple of such usecases, and with the states notion it's trivial for us to support it.

Afaik others tackle this with proxies?

 

Liam Knox replied on Fri, 2009/01/02 - 7:22pm in response to: Ales Justin

1) Read the contents of this article

 http://java.dzone.com/news/your-architecture-starts-be-su#comment-8887

and tell me what is its of use?  This is an example of random abstract stuff people seem to post which has little to zero meaning.

 2) Given you are working on general developer tolls i.e. framework/containers, wouldnt it be first pertinent to know what the other containers support and how? This is FUNDAMENTAL in competition development.  I couldnt see Microsoft take on Google in the search space without trying to find out exactly what they are doing and how. 

You really should know what you competing containers do more than I.  From the above I dont really see what Spring doesnt do, BeanPostprocecissing,Aliasing, lazy instialization, static creational and factories, and also Spring does this is a consistent bean definition schema which is therefore more intutive. 

3) The post refering to giving Rod Johsons the JSR is tongue in cheek, but then some individuals have a very bland and non developed sense of humor :-(.  But I stand by the 360 degrees statment that EJB3 has basically become a fabrication on ideas from Rods orginal design.

4) I also stand by that I think this kind of work is fundamentally just rewriting the work of others, hence why I cant see a motivation in sponsoring it.  If I started posting API's that looked pretty much identical to java.util.Map, people would say WTF.   This work doesnt look that disimilar.  Again perhaps if you built apon rather than replication your ideas would add something.  I guess your employer (and J2EE) as a whole said, ah we need to remain competitive so we must get some IoC together ASAP.  Seems WebLogic tooks a much more pragramatic approach in leveraging rather than replicating.  

5) On Guice, Yes I really think this was worthwhile and unlike in your posts, Bob Lee, set out what the fundamental differences were in his idea compared to Spring in a very coherintant manner.  However I think the main lonterm benefit (both is volume of users usage, and time) will be on the adoption of annotation based IoC into Spring.

 

  

Andrew Rubinger replied on Fri, 2009/01/02 - 8:55pm in response to: Liam Knox

[quote=knoxl]3) The post refering to giving Rod Johsons the JSR is tongue in cheek, but then some individuals have a very bland and non developed sense of humor :-([/quote] 

Bad comedians blame the audience, good ones sign autographs after the show.

[quote=knoxl]But I stand by the 360 degrees statment that EJB3 has basically become a fabrication on ideas from Rods orginal design. [/quote]

You are wrong.

EJB continues to be a different animal from the ideas explored by Rod in "Expert One-on-One J2EE Design and Development", though the 3.0 revision of the specification heavily redefined how bean providers supply metadata.  What *looks* like a pure POJO becomes an EJB, with backing pool/cache, session context, and implicit support for all of the orthogonal services defined by the spec.  I wrote a little on this here.

So it's very cool that WebBeans (read: Contextual Injection and integration of known components) has set the stage for different models to play nicely.

S,
ALR

Andrew Rubinger replied on Fri, 2009/01/02 - 9:01pm in response to: Liam Knox

*Author removed double-post due to Network Hiccup.

Andrew Rubinger replied on Sat, 2009/01/03 - 2:33pm in response to: Liam Knox

[quote=knoxl]I still find your posts rather abstract, for example 'Provide an agnostic and extensible core, then adapt to whichever APIs you'd like'. 

Can you given me some tangible examples?[/quote]

Sure, that's fair. 

JBoss Application Server has to support a wide variety of component types because it's really an integration technology for all of the JEE technologies (and more).  That said, we needed a "core" which would not impose any restrictions upon the libraries to be integrated (like the old JMX implementation did, requiring MBean wrappers). As a concrete example, I'll walk us through a EJB3 deployment conceivably taking advantage of MC.

* JAR/EAR is deployed
* Deployer chain (MC's VDF) inspects and processes the new deployment
* Annotation scanning takes place *once*, is added to the MC Metadata Repository (other components may now gain access to this metadata via MDR, not by re-inspecting the deployment N times)
* AOP information (maybe additional annotations, etc) is added to the metadata.  Now also available.  This is provided by AOP Integration w/ MC.
* EJB3 Deployers pick up on that we've got a new candidate for EJB3 deployment, based upon the new metadata
* We construct an EJB3 container based upon configured smaller components (Pool and Cache Factories, Tx Manager, Aspect Manager, the deployed metadata, etc) to fulfill the EJB Spec contracts. 
* We trigger lifecycle start of the new EJB Container
* We now have built an EJB Component View from and using MC units.

Additionally, I could add another deployer to install the same EJB as a POJO, bound in JNDI.  Or installed into MC.  That's what I mean by a "core" with many component views.  (Sacha calls these "personalities", I'm not sure the approved marketing lingo now. ;))

This is a very good presentation, use as additional reference.

[quote=knoxl]Still seems having a Sun label , J2EE, EJB etc, turns some people on for some reason.  If you look at the history of this you will find these are not the only failing in Sun API designs, look at Date, Properties, Formating, Exception etc, Josh Bloch himself is critical on these. [/quote]

Don't confuse things here.  The label relates to portability, and the value-add here is to eliminate vendor lock-in and ensure that you can recruit a workforce familiar with open standards.  This doesn't mean the spec is perfect (I certainly would never infer that).  I was an application developer; when I consulted with an EJB shop I knew my way around immediately.

[quote=knoxl]My main question is still, if you have already the best IoC framework available why would you choose rewriting rather than building apon?[/quote]

I want to *build upon* my car to add the capability of flight.  When I'm done, how elegant do you think my solution will look?

S,
ALR

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.