jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<bil...@jb...>]

"ad...@jb..." wrote : "bil...@jb..." wrote : I think you are going way overboard with dependency management here.  
  |   | 
  | 
  | I think this goes to heart of the disagreement.
  | 
  | My vote is for using picocontainer with limited ability to support hot-deployment 
  | or correctly startup a disparate group of loosy couple modules.
  | 
  | Leaving me to get on with doing something more useful than arguing about DI.
  | 

The "overboard" I'm talking about is publishing dependencies before the class is loaded so that class loading is aware of aspect dependencies as well.  

I think publishing aspect dependencies after the class is loaded and before class static initialization, will work just fine without to much disruption in so many codebases.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875697#3875697

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875697

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<bil...@jb...>]

anonymous wrote : 
  | The reason for knowing about the SecurityDomain is a fundamental difference
  | in the deployment strategies of AOP vs MC
  | 
  | In AOP if the advice is not deployed it is not included in the stack.
  | If a depdendency of the advice is not deployed you find out after requests are
  | being processed with a runtime exception.
  | 

I don't think you understand how I am doing this AOP/MC integration.

When the AOP deployer sees an Aspect declaration, it will create a GenericBeanFactory and install it into the Microconatiner.  It will also register AOP specific metadata about the Aspect into the AspectManager.

When a binding is defined, the AOP Deployer creates an InterceptorFactory and registers the metadata for binding the advice/aspect to the class.  This InterceptorFactory has a reference to the Kernel.  When a Class is statically initialized, it tries to create advice chains.  This is when the InterceptorFactory tries to lookup the GenericBeanFactory. 

anonymous wrote : 
  | In the MC if the advice and its dependencies are not installed the object is not created
  | and the user is told to deploy the missing dependency.
  | 

And this works, so what is the problem?  ClassAdapter.getDependencies() is currently called before class static initialization and the aspect dependencies propagated.  Did you see that I implemented and tested this?

The SecurityDomain example is a different example.  This is because knowledge of the dependency is hidden in the annotations.  So, I thought our agreement was that this annotation would have a @Dependency annotation on it:


  | @Dependency(attribute="value")
  | public @Interface SecurityDomain {
  |    String value();
  | }
  | 

Either the MC or AOP is gonna have to look at every single annotation attached to the class (and superclass) for this @Dependency annotation and add it to the BeanMetaData dependency list.  Correct?  I'm fine with adding this to the AspectAdapter.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875695#3875695

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875695

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

"ad...@jb..." wrote : "bil...@jb..." wrote : I think you are going way overboard with dependency management here.  
  |   | 
  | 
  | I think this goes to heart of the disagreement.
  | 
  | My vote is for using picocontainer with limited ability to support hot-deployment 
  | or correctly startup a disparate group of loosy couple modules.
  | 
  | Leaving me to get on with doing something more useful than arguing about DI.
  | 

A joke, but like most good jokes it is not far from the truth. :-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875692#3875692

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875692

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

"bil...@jb..." wrote : I think you are going way overboard with dependency management here.  
  | 

I think this goes to heart of the disagreement.

My vote is for using picocontainer with limited ability to support hot-deployment 
or correctly startup a disparate group of loosy couple modules.

Leaving me to get on with doing something more useful than arguing about DI.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875691#3875691

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875691

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

On the joinpoint model:

This is serving more than just a dialogue between the MC and AOP.
It is acting as a cache for the reflection style objects.

Resolving reflection objects is much more expensive than using them
which is why the current EJB/JMX containers preresolve these objects.

They are also used by the Bus/Detyped invocations:

  | public interface KernelBus extends KernelObject
  | {
  |    /**
  |     * Invoke an operation
  |     * 
  |     * @param name the name of the object
  |     * @param joinPoint the join point
  |     * @return the result
  |     * @throws Throwable for any error
  |     */
  |    Object invoke(Object name, TargettedJoinpoint joinPoint) throws Throwable;
  | }
  | 

This goes back to the "do we need to support a reflection implementation" question.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875689#3875689

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875689

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

It will take me a while to digest your proposal. 
I don't see the meat of it  (how it could possibly work) at the moment.

At first blush, this looks like my original proposal, which was that the MC would 
push all the metadata to the AspectManager, but we decided against that solution 
because 
1) it would require the MC understanding all the point cut expressions, etc.
i.e. understanding the cross cutting.
2) users can still deploy using jboss-aop.xml which the MC wouldn't know about.

Instead, we decided on the query approach where the MC asks the AOP
layer "what would it mean if I created an instance of this object" during the
describe stage.

Correct me if I have misunderstood.

anonymous wrote : 
  | This is going to require a bunch of refactoring to MC because currently the classadapter is hidden by BeanInfos.
  | 

I don't mind refactoring, especially if it simplifies the problem.

I don't see why the ClassAdapter inside the BeanInfo creates a problem.
The BeanInfo is just a description of the class after AOP has played with it
and it is per ClassAdapter (which could be instance level) not per Class.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875688#3875688

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875688

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<bil...@jb...>]

anonymous wrote : 
  | Ok, let's deal with a fundamental problem first.
  | 
  | The MC does not necessarily use a ConstructorJoinPoint.
  | It could use a factory to create the object. See the ConstructorMetaData.
  |  
  | 

The AOP container needs to intercept the allocation of the bean by the MC.  Whether this is done by a constructor or factory method, it doesn't matter. AOP needs to intercept allocation so that it can put a proxy in place or initialize the InstanceAdvisor (depending whether the class is aspectized or not).

What I think we should do is ditch the ClassAdapter stuff and just have an AspectAdapter.  An AspectAdapter should be created per bean.  This would require a rewrite of your MC because allocation information and the ClassAdapter stuff is embedded within the BeanInfo class which is cached on a per-class basis.

I think the AspectAdapter interface should be as follows in live within the kernel/ module:


  | public interface AspectAdapterFactory {
  |    AspectAdapter createAspectAdapter(Class clazz, BeanMetaData metadata);
  | }
  | 

Yes, AOP Requires the java.lang.Class.  Again, I refuse to use ClassInfos because it would require too much refactoring to JBoss AOP and creating ClassInfos with Javassist, is just way too slow.  I have no desire to refactor Javassist as well to make it faster.  I think you are going way overboard with dependency management here.  Requiring too much work for too little reward.

The AspectAdapter interface might look something like this:


  | public interface AspectAdapter {
  |    public List getDependencies();
  |    public ConstructorJoinpoint getConstructorJoinpoint(ConstructorInfo);
  |    public MethodJoinpoint getFactoryJoinpoint();
  |    public FieldGetJoinpoint getFieldGetJoinpoint(FieldInfo);
  |    public FieldSetJoinpoint getFieldSetJoinpoint(FieldInfo);
  |    public MethodJonipoint getMethodJoinpoint(MethodInfo);
  | }
  | 

For JBoss AOP at least, the getMethodJoinpoint would not be needed.  FieldGet/FieldSet are needed because JBoss AOP wraps field access in a static method call.  A separate getFactoryJoinpoint and getConstructorJoinpoint is needed, because again, JBoss AOP needs to be able to intercept allocation to create a proxy or to interact with the aspectized class's object instance's InstanceAdvisor.

This is going to require a bunch of refactoring to MC because currently the classadapter is hidden by BeanInfos.

Bill


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875686#3875686

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875686

[Jboss-dev-forums] [Design of JBossXB] - POJO Schema parsing

[<ad...@jb...>]

Let me know if you'd rather I raise JIRA tasks for these:

I've got some corrections to do to fix misconceptions and some "lost in translation"
usage of the metadata, but that is less important at the moment and my problem :-)

The main problems are:

1) If you don't specify a schema on the xml document you get lots of warnings
and a NULL object back. I would expect this to be a hard error if you pass in
an xml document that has no relevence to the schema binding.

2) Even though I've told it the schema with the schema binding (including the real local
location) this has no affect on the entity resolver:

  | 4625 WARN  [EntityResolver] Entity is not registered, publicId=null systemId=file:/home/ejort/jboss-head/workspace/kernel/src/resources/xml-test/org/jboss/test/kern
  | el/xml/test/pojo-deployer_1_0.xsd
  | 
It wants to load it from the system id (because there is no public id?) and it believes the
system id should be the same place as the xml file.

  | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  |    xsi:schemaLocation="urn:jboss:xml-deployer xml-deployer_1_0.xsd"
  |    xmlns="urn:jboss:xml-deployer">
  | 

3) Bill added the ability to use streams in the parsing, I think because he wants
to pass in fragments. There is no corresponding api for the schema binding.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875685#3875685

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875685

[Jboss-dev-forums] [Design of JBoss Build System] - Re: test target

[<ad...@jb...>]

To make this easy to parse you could add an "elements" attribute
identify what you want to replace.


  |          <source when="@{test}" elements="junit-elements">
  |             <mkdir dir="@{testDir}"/>
  |             <junit fork="true"
  |                    printSummary="true">
  |                <formatter type="plain"/>
  |                <classpath>
  |                   <pathElements/>
  |                </classpath>
  |                <batchtest todir="@{testDir}">
  |                   <fileset dir="@{sourceDir}" includes="@{test}"/>
  |                </batchtest>
  |                <junit-elements/> <!-- HERE source/junit-elements -->
  |             </junit>
  |          </source>
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875683#3875683

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875683

[Jboss-dev-forums] [Design of JBoss IIOP on JBoss] - Can we switch the default ORB to a foreign one without affec

[qdotlu <nu...@jb...>]

There is a situation that we would like to switch the JBoss default ORB to a 3rd party ORB implementation (the 3rd party ORB conforms to CORBA 2.3 specification also) by configuring the following 2 command line properties when starting up the JBoss AS:

org.omg.CORBA.ORBSingletonClass=
org.omg.CORBA.ORBClass=

We don't know whether the transaction context and security context will be propagated as it used to be if the default server ORB is used. Please see the following simple diagram:

                      RMI-IIOP (with foreign ORB)
EJB1 in JBoss1 -------------------------------> EJB2 in JBoss2
                     Transaction/Security Context??

Could somebody confirm whether this will work or not?

Thanks,
-Zhijiang

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875682#3875682

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875682

[Jboss-dev-forums] [Design of JBoss Build System] - Re: test target

[<ad...@jb...>]

Objections and ideals over.

To reproduce what already exists, like you suggested, 
you could add specialised parameters to the source definition that can affect the macro generating the junit task.

But this would require some coding. 

Probably the most general solution is to allow any element to  be added
to a macro by making each type implement DynamicElement not just DynamicAttribute?

  | <source id="tests" test="whatever">
  |     <junit-elements> <!-- This is just held inside the definition as a DynamicElement -->
  | ...
  |     </junit-elements>
  | </source>
  | 

Then insert the junit-elements directly into the junit task (which might be empty).


  |       <targetdef target="runtest">
  |          <component/>
  |          <source when="@{test}">
  |             <mkdir dir="@{testDir}"/>
  |             <junit fork="true"
  |                    printSummary="true">
  |                <formatter type="plain"/>
  |                <classpath>
  |                   <pathElements/>
  |                </classpath>
  |                <batchtest todir="@{testDir}">
  |                   <fileset dir="@{sourceDir}" includes="@{test}"/>
  |                </batchtest>
  |                <junit-elements/> <!-- HERE source/junit-elements -->
  |             </junit>
  |          </source>
  |       </targetdef>
  | 

The downside is the loss of validation if you mistype and sub-element, e.g.

  | <source id="tests">
  |    <incude id="main"/> // OOPS! this is now a DynamicElement when it should be a parser exception
  | </source>

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875681#3875681

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875681

[Jboss-dev-forums] [Design of JBoss Build System] - Re: test target

[<ad...@jb...>]

I've never liked the idea of passing arguments to tests this way.

For a start, it makes it difficult to run the those tests in IDEs. 

But more importantly, it also doesn't scale when more than one test 
in the same suite wants to do a similar but incompatible thing.

I prefer the mechanism where the test bootstraps its own environment, though
I've never found a good generic solution to this problem.
i.e. being able to run the tests as unit tests inside the home project, and also
bundling the tests for binary distribution into some larger testsuite or QA
environment.

I guess this is one for the custom TestRunner we want to write for other reasons
like being able to simulate a JBoss crash or reboot?

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875678#3875678

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875678

[Jboss-dev-forums] [Design of JBoss Build System] - Re: test target

[<rya...@jb...>]

anonymous wrote : 
  | I guess the jvmarg can be added to the runtest taskdef as well, but am not sure how to make it conditional depending of if there is a variable defined for it within the jbossbuild.xml.    
  | 

Usually,  you can add an attribute to an element like this, and then do conditional processing based on the presence of that attribute.  However, in this case we have an optional parameter (your jvm arguments), which the template processing can't handle.  I think we will need to extend the template language to allow you to do something like this:

   <source id="test" tests="*TestCase.java">
  |       <input id="main"/>
  |       <jvmarg value="-Dloader.path=${output.lib.dir}/jboss-remoting-loading-test.jar"/>
  |    </source>

and then in our tasks.xml where we make the JUnit call we could have:

   <junit ...
  |        <pathelements>
  |        <jvmargs/>
  |   </junit>

And the above would expand to include all the jmvarg elements you defined. This would be a generic mechanism for any kind of element.  

Adrian?  Do you see any problem with having dynamic elements like this?    I haven't investigated deeply, but ant's DynamicElement seems like it might fit the bill. 

We need to focus on getting the build complete, but I will add this as an enhancement in JIRA if Adrian agrees.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875675#3875675

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875675

[Jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re: Version compatibility tests

[<sco...@jb...>]

I would say all should be included. You can check with Thomas to see if some of these tests are excersizing features that really should not be considered as supportable across versions.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875674#3875674

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875674

[Jboss-dev-forums] [Design of JBoss Build System] - Re: test target

[<rya...@jb...>]

I'll start with the easiest questions first :-)

"tom...@jb..." wrote : I am still not totally clear on the source tags and what exactly they are defining (can these be any free form strings, or do they have to be 'main', 'test', etc.?).  
  | 

These are just the names of the directories under your src directory.  They have no special meaning to the build system.  So if you had a src/foo directory, you could generate compile targets for it like this:

<source id="foo"/>

which would result in a build.foo target.

"tom...@jb..." wrote : Am not sure how to specify a string expression for the files I want excluded.

Yes, that's certainly a limitation.  Is this an actual need at this point?  If so, we could change that attribute to be an Ant patternset refid instead of the actual pattern.

anonymous wrote : So now just need to be able to specify exactly the jars included on the classpath for the test run and how to pass the jvmarg parameter.  I see that runtest uses pathElements for the classpath, but don't know where the values come from.  
  | 

The pathElements tag is a special tag which resolves to the inputs of your source - and the jars in the Classpath of your inputs manfest.  So if you have:

<source id="tests">
  |    <input="jboss-common.jar"/>
  | </source>

The  will include jboss-common.jar in your test's classpath, as well as all of jboss-common.jar's dependencies.  You can see this working by using the special show target:

ant -f jbossbuild.xml show -Dshow=runtests.test

This will let you will see the target that is generated, and what the  actually resolves to.  Also, see the bottom of this page: 
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=58993&postdays=0&postorder=asc&start=10


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875671#3875671

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875671

[Jboss-dev-forums] [Design of Mail Services] - Re: M4 planning

[<aco...@jb...>]

Ohhh I thought it didn't use native code for the HTTP connector side which was about as fast as apache.  Now I kinda don't believe all the voodoo (keep alive with 1 second between is probably not the norm ;0)..  I like the idea of NIO but I'm not ready to leave JDK 1.4 behind.  The idea is to have a 1.0 release in the nearer term which means JDK 1.4 is still a factor (there are a lot of platforms with no JDK5 release yet).  After the 1.0 then we refactor to all NIO because by 2.0 we don't care about 1.4 anymore.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875670#3875670

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875670

[Jboss-dev-forums] [Design of JTA and JTS on JBoss] - Re: Where should UserTransaction live?

[<ad...@jb...>]

"reverbel" wrote : [
  | No, the transaction manager must be aware of remote access, as it must know a set of interfaces implemented by remote access providers. It must keep references to remote resources (which implement a Resource interface), a reference to a parent coordinator (which implement a Coordinator interface), etc. It must call methods on remote Resource and Coordinator objects at appropriate times. 
  | 

I'm saying these should be core the interfaces. Whether the implementations actually
do remote work or are optimized for local tx management is a deployment decision.

What I'm really after is the ability to plugin any TM and if it doesn't support certain
features like Tx propogation over Remoting or the JCA XATerminator then there is a
standard mechanism to integrate those features (or not if they are not required,
e.g. mocks for testing purposes).
This might be "pie in the sky" but it is an ideal we should aim for, even if it is not
entirely attainable.

That is how TransactionLocal works with a an implementation based on tx
synchronization if the transaction manager does not directly support it.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875662#3875662

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875662

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

"ad...@jb..." wrote : 
  | The idea of the ClassAdapter was that it would use this as a context for overrides
  | on the object being constructed.
  | 

Anticipating you saying this contradicts my description of the ClassAdapter as
just a bridge. 
Yes the ClassAdapter is a bridge, but that was why I had
ClassAdapter.getInstanceAdapter()
that created a context from which I retrieved joinpoints that knew about the context,
i.e. annotation overrides.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875660#3875660

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875660

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Development help

[<ad...@jb...>]

The original requirement docs is here:
http://www.jboss.org/wiki/Wiki.jsp?page=JBossKernel

There are also some skeleton docbooks in the kernel/docs folder, although
some of it is out-of-date due to refactoring of the xml and the container/aop integration.

The TRACE logging is quite extensive, so try running of the simpler tests and follow
where it goes the code to get an idea of how it works.

If I was anygood at computer art I would do a flow diagram. I did one on the board
at the dev conference and I believe Ovidiu took at photograph of it? :-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875657#3875657

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875657

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: status of AOP/MC integration

[<ad...@jb...>]

My prob lem is not so much that you have changed tack to provide
a more pragmatic implementation, nor that you are iterating a solution.

My problem is that you are creating interfaces that cannot survive all the requirements
we have down the road.

I would prefer a solution that looks like it will meet the requirements (even if it doesn't actually work - it can be fixed) to one where we are going to incompatibly break things
to do the more complicated stuff in future releases.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875655#3875655

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875655

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Development help

[<ste...@jb...>]

So where is the best point to jump in and start helping with development.  I have looked at the JIRA, but it is all greek (no offense Dimitris:) to me, because I don't have the context that has been building up for the last few months.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875653#3875653

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875653

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

"bil...@jb..." wrote : 
  | THis idea that everything has to work in all environments with the 1st iteration or even the first release of MC, MC+AOP is just stupid.  Iterate!
  | 
  | + others
  | 

At the time this was an important requirement because of the need for jmx/mc 
interopability/backwards compatibilty.
This is less important now that JBoss5 will not be release of this software.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875651#3875651

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875651

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

"ad...@jb..." wrote : I don't mind the MC using the AOP annotation metadata format. My only concern would be
  | the potential in future for an annotation to include data that also requires DI.

And that the AOP version has a notion of instance???
I only want the annotation to apply to that object not all future objects of the same class.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875648#3875648

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875648

[Jboss-dev-forums] [Design of JBoss Build System] - Re: component-info.xml vs release.xml artifacts

[<rya...@jb...>]

erm that should be:

ant synchronize
ant most

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875647#3875647

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875647

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

I don't mind the MC using the AOP annotation metadata format. My only concern would be
the potential in future for an annotation to include data that also requires DI.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875646#3875646

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875646