[Design of POJO Server] - ManagedObjects of ManagedObjects, etc.
by adrian＠jboss.org
Apologies in advance if this is a bit of a brain dump since I don't have
this clear in my head yet.
If you look at the OpenMBean api there is an OpenType, SimpleType.OBJECT_NAME
which is used to link MBeans together, i..e. to implement references.
Currently in the MetaType api I haven't added this.
The main use case for this is for ManagedObjects of ManagedObjects,
e.g. a ServiceDeployment has a LoaderRepositoryConfig and a List
which need to be ManagedObjects in their own write.
This part is fairly trivial to implement.
What is not so trivial is when you get to more complicated deployments.
e.g. an ejb deployment can have multiple attachments (ejb-jar.xml, jboss.xml,
jbosscmp-jdbc.xml)
Additionally, the ejb deployment is made of multiple ejbs, each has the
same split, i.e. multiple attachments but they see the "sub managed objects"
of the main managed objects.
These are obviously references like the SimpleType.OBJECT_NAME.
There are also two views:
1) The merged view, i.e. I am managing this ejb
2) The split view, i.e. give me the updated attachments (plural) for this ejb
deployment
Finally, the keys to these references can be used elsewhere,
e.g. the ejb's assembly descriptor
What is not clear to me yet, is how we implement this such that:
* It is easy for the deployer to describe how these references work
(this element of jboss.xml is related to another element in ejb-jar.xml)
* It is easy for the profile service/admin console to understand/use these references
(e.g. providing a drop down list of available ejb-names when editiing the
assembly descriptor)
I think only going through the more complicated uses cases will reveal
all the issues, unless somebody has a clearer view than me on them?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995589#3995589
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995589
18 years
[Design of POJO Server] - Re: Moving forward with the profile service mgmt api
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote :
| The piece that is missing is how does the profile service take a ManagedObject populated with a set of changes, and then merge that into the base DeploymentContext metadata attachments to create the predetermined attachments that override the raw deployment values.
|
The initial construction of DeploymentContexts from the profile
is a problem for the profile service (with or without predetermined attachments).
Of course the managed object will provide a method to
turn a managed object into its wrapped attachment (metadata object)
for serialization by the profile service.
The piece that is missing outside the profile service
will be an extension to the deployers api where there will be two links:
1) You are a "parsing deployer", tell me what your managed object looks like.
i.e. construct a managed object for this attachment you created.
2) You want to support runtime updates (not just redeployment),
then the server side support of the managed object needs a link to the
"real deployer' for the attachment.
anonymous wrote :
| The missing mapping is the attachment name, and the corresponding metdata object property(s). In general a ManagedObject properties are going to map to several different metadata objects/properties.
|
Correct, in fact I'll talk about this in a seperate thread, because this is
my major stumbing block. Most of the other stuff I know how to do
and it is just a case of doing it, but this requires some extra thought.
anonymous wrote :
| The ManagementView also needs to be updated to support applying a ManagedObject change. I don't see that the ManagedObject returned from the ManagementView is hooked up to the attachments it overrides, therefore, this needs to be a write step.
|
To repeat what I said above (in pseudo code):
| ManagedObject mo = parsingDeployer.getManagedObject(Attachment);
|
Only each deployer/subsystem really knows how it wants to be managed.
With the usual caveats of providing implements/helpers for the deployer to choose
from and allowing overrides to fix up what the programmer of the deployer did (or did not) do. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995584#3995584
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995584
18 years
[Design the new POJO MicroContainer] - Re: JBMICROCONT-132 todo?
by alesj
As I can see
| public static Object convertValue(Class<? extends Object> clazz, Object value) throws Throwable
| {
| if (clazz == null)
| throw new IllegalArgumentException("Null class");
| if (value == null)
| return null;
|
| Class<? extends Object> valueClass = value.getClass();
| if (clazz.isAssignableFrom(valueClass))
| return value;
|
| // First see if this is an Enum
| if (clazz.isEnum())
| {
| Class<? extends Enum> eclazz = clazz.asSubclass(Enum.class);
| return Enum.valueOf(eclazz, value.toString());
| }
|
| // Next look for a property editor
| if (valueClass == String.class)
| {
| PropertyEditor editor = PropertyEditorManager.findEditor(clazz);
| if (editor != null)
| {
| editor.setAsText((String) value);
| return editor.getValue();
| }
| }
|
| Object result = null;
| // Try a static clazz.valueOf(value)
| try
| {
| Method method = clazz.getMethod("valueOf", valueClass);
| int modifiers = method.getModifiers();
| if (Modifier.isPublic(modifiers) && Modifier.isStatic(modifiers)
| && clazz.isAssignableFrom(method.getReturnType()))
| result = ReflectionUtils.invoke(null, method, new Object[]{value});
| }
| catch (Exception ignored)
| {
| }
| if (result == null)
| {
| // TODO JBMICROCONT-132 improve <init>(String) might not be relevent?
| if (valueClass == String.class)
| {
| try
| {
| Constructor constructor = clazz.getConstructor(valueClass);
| if (Modifier.isPublic(constructor.getModifiers()))
| result = ReflectionUtils.newInstance(constructor, new Object[]{value});
| }
| catch (Exception ignored)
| {
| }
| }
| }
|
| // try progression
| result = progressValue(clazz, result);
| // return result if progression supported, else the old value
| return result != null ? result : value;
| }
|
it already checks first for valueOf method.
So I remove the usage of constructor (and test for backcompatibility)?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995582#3995582
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995582
18 years
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Metadata rewrite
by adrian＠jboss.org
I'm not sure I understand the second part, but I understand the first part.
The answer to the final question is that the cutoff for creating an instance proxy
is whether it has instance annotations.
Obviouslly if there are server annotations (like default transaction timeout)
they will be shared by all instances.
The object you are getting is the MetaData (read only and merged)
which is the object that you should use in AOP.
However, this does not tell you if there are instance annotations.
What you really need to do is the following (pseudo code):
| // Get the instance retrieval for this context
| KernelMetaDataRepository repository = kernel.getMetaDataRepository();
| MetaDataRetrieval retrieval = repository.getMetaDataRetrieval(context);
|
| if (retrieval.isEmpty() == false)
| // Need an instance proxy
|
NOTE: obviously the "isEmpty()" doesn't exist
and it would need to check for annotations, object metadata and
component metadata as well.
But, you don't have a reference to the kernel or the context in the code
where you need to do this. I'm not sure what is the best way to solve this?
I don't like the idea of reintroducing the MetaData stuff into the BeanInfo
even the getDependencies(MetaData) is ugly.
That is unless it was implemented properly with the "InstanceClassInfo"
really holding the instance annotations, but that would probably require
a lot of rework in AOP to use the ClassInfo instead of Class or CtClass?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995572#3995572
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995572
18 years