JBossDeveloper

 

"bill.burke@jboss.com" wrote:

I think I see what you mean. Thread scope would want to obtain metadata from both its transaction and conversation. Is that what you're talking about?

Yes it is similar to the AOP scoped metadata, but I rewrote it in the container
project to introduce type safety, annotation overrides, internal caching (if required)
and an abitrary scope concept.

 

"alesj" wrote:

<policy>
 <scope/>
 <annotations/>
 <bindings/>
</policy>

How is this integrated with current MC xml, I don't see it :-(?

Through the wildcard handling:

<policy xmlns="urn:jboss-policy:1.0"/>

The policy xml unmarshalling would create a BeanMetaDataFactory.

This is something we could defintely make it easier to do.
I'd like each project to define use case xml.

e.g. instead of

<bean name="MyQueue" class="SomeQueueClass">
 <ugly-irrelevant-implementation-detail-config-here/>

 <!-- Useful properties in ugly property config -->
 <property name="name">queue/MyQueue</property>
</bean>

The user would just write

<queue xmlns="urn:jboss-messaging:1.0"
 name="queue/MyQueue"/>

which produces the above BeanMetaData internally (probably using
your new builder :-).

You can forget about this and just use the bean xml equivalent in the initial work.

 

"adrian@jboss.org" wrote:

Yes it is similar to the AOP scoped metadata

It's also automatically available in AOP if you use the aop-mc-int version of MC
in the annotation retrieval and the new getMetaData() method of the Advisor.

i.e. You can get the metadata for the bean instance including annotations
overrides defined in the mc xml

This was the code that Carlo was having problems with missing
jboss-container.jar classes on the client.

 

"alesj" wrote:

"adrian@jboss.org" wrote:

Through the wildcard handling:

<policy xmlns="urn:jboss-policy:1.0"/>

Yes.
But what would be the content of policy?
Ok, scope element for sure.
Will it wrap deployment or just some wrapped beans?
Or is this the job of bindings?

It is a bean that contains a map of string->objects (the bindings).
The value side of the map could be anything the MC supports (except null :-)

In the use case xml, besides supporting the normal

<binding name="TheName"><!-- value --></binding>

You could also support simpler versions like

<binding><!-- value --></binding>

where the "name" comes value.getClass().getName();

I also wanted to support named policies so you can provide default policies:

<policy name="DefaultPolicy">
 <binding name="property">TheDefault</binding>
 <binding name="another">blah</binding>
</policy>

<policy name="RealPolicy" extends="DefaultPolicy">
 <binding name="property">Override</binding>
</policy>

The RealPolicy would then have:
property=Override
another=blah

But I think we decided that this might be difficult for the profile service/admin console to maintain or understand in the initial version.

I don't understand the question?

The policy xml should be unmarshalled to an object that implements
BeanMetaDataFactory. When the deployment invokes getBeans()
that object will create some BeanMetaData for a POJO
that knows how to install/uninstall data into the MetaData repository.

public class Policy implements BeanMetaDataFactory
{
 public void setScope(ScopeMetaData);

 public void setMappings(Map<String, ValueMetaData>)

 public List<BeanMetaData> getBeanMetaData()
 {
 // IMPORTANT the Mappings needs to be converted to a MapMetaData
 // such that the injections in ValueMetaData work correctly, i.e. dependencies
 return buildMetaDataRepositoryInstallerBeanMetaData();
 }
}

public class MetaDataRepositoryInstaller
{
 public void setScope(ScopeMetaData);

 @Inject // If we can assume there be will only one instance?
 public void setKernelMetaDataRepository(KernelMetaDataRepository)

 // The MC will resolve the ValueMetaData to objects!
 public void setMappings(Map<String, Object>)

 public void start()
 {
 // Install
 }

 public void stop()
 {
 // Uninstall
 }
}

NOTE: I'm not overly impressed by the name "Policy"
perhaps

<metadata>

would be a better name?

 

"alesj" wrote:

"adrian@jboss.org" wrote:

We discussed it a while ago (I think some of the major discussions were on
the jboss-dev mailing list). I called it "policy" configuration at that time.

How to find this? :-)

No idea. I had a quick search but I couldn't find anything (or more correctly
I found too much). The problem is that "policy" is a pretty common word. ;-)

Is this http://www.jboss.com/index.html?module=bb&op=viewtopic&t=85442&postdays=0&postorder=asc&start=0 it?

Yes, but you'll probably need to follow the links as well.

About this issue (Microcontainer and JBossXB) that I came up with:
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=95841

Snapshots are ok as long as tagged releases don't get tagged with
references to snapshots.

i.e. jboss-microcontainer-2.0.0-beta2 should not have any snapshots in the
build-thirdparty.xml when it is tagged for release!
If it contains snapshot references then the build will be unreproducable when
somebody changes the snapshot.

 

"alesj" wrote:

Currently I have a separate binding element, which takes any MC value. This should do it for the injection / dependency, right?

Ok, the binding metadata makes sense from what I said above
about keeping the xml simple, but you still need to create the BeanMetaData
for the installer pojo. You have to add a context to the MC that does this work
and resolves the ValueMetaData objects (e.g. injections).

I don't understand why you have visitor callbacks on the Binding/Policy/ScopeMetaData?
They are not a part of the BeanMetaData tree so they are never going to get
invoked.

An alternative to creating a MapMetaData would be to make BindingMetaData
extend ValueMetaData so you can set it directly as the value of the PropertyMetaData
of the installer pojo?

Or more accurately you would need a BindingsMetaData that specializes
AbstractSetMetaData to effectively a

Set<BindingMetaData>

The PolicyMetaData and the installer pojo could then take a BindingsMetaData.