[Design of OSGi Integration] - Updated OSGi/MC prototype
by adrian＠jboss.org
Since Ales and Thomas have been nagging me (you should already know
I don't respond to private e-mails for open source stuff - use the forums :-)
I've committed what I've done so far for the OSGi implementation on top of the
deployers/classloading.
I've kind of changed the priorities for this prototype to do it in a more incremental way.
The basic priority is to be able to deploy osgi bundles within JBoss5+ and use
the OSGi api if you are an osgi deployment. With that in mind I've reworked the
previous prototype to do only that for now.
I realised after trying to "fix" the previous prototype and then failing in that, rewriting it
but trying to do all the changes at once was getting messy and those changes
(e.g. to the classloading or MC) would make it very hard to "drop in" the osgi
layer into existing versions of JBoss5.
So what I've committed is a cut down version of the "rewrite" which while incomplete
(at the moment) does most of the stuff that you want to do with OSGi.
I've removed the old code that is no longer used.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249944#4249944
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249944
17 years, 1 month
[Design of POJO Server] - Re: profile service overview?
by emuckenhuber
"jhalliday" wrote : > The persisted changes will get applied to the BeanMetaData directly before the bean is handed over to MC and installed - so before the bean is instantiated.
|
| huh? The MC is the only thing that knows how to instantiate some beans - the wiring for the factory method is part of the -beans.xml You are saying the profile service inserts itself after the process that parses the -beans.xml but before the bit that uses the resulting data, then takes upon itself to use the factory to instantiate the bean in place of MC doing that?
We are updating the meta data only, we don't instantiate/touch the bean itself.
Given you have a bean:
| public class MyBean {
| int timeout;
| @ManagementProperty
| public int getTimeout() { ... };
| public void setTimeout(int timeout) { ... };
|
| }
|
With it's -beans.xml:
| <bean name="TimoutBean" class="MyBean">
| <property name="timeout">12</property>
| </bean>
|
If there are persisted changes e.g. the timout value was changed to 15 then ProfileService would update the meta data like:
BeanMetaData.setProperty("timeout", 15):
So MC would create the bean still based on the on the -beans.xml descriptor from above, but would inject a value of 15 instead of 12.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249906#4249906
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249906
17 years, 1 month
[Design of POJO Server] - Re: profile service overview?
by emuckenhuber
"jhalliday" wrote : Thanks for the pointers.
| What's the problem with that? Type limitations?
|
Basically all values of ManagedProperties are exposed as a MetaType and MetaValue pair consisting only of simple types.
As this is a very generic processing it could happen that in some cases we cannot recreate the actual object, if we don't have additional information (e.g. a MetaMapper). That's why it would be good to review what's exposed and provide additional mappings if needed.
This really depends on the complexity of e.g. your TSConfigurationBean.
"jhalliday" wrote :
| I definitely don't want a compile time dependency on profile service, so it looks like using annotations in the -beans.xml is the way to go.
|
Hmm i've never tried to put property annotations for profileservice in the -beans.xml directly, but should work. That's also why we are also working on a xml descriptor for this view.
"jhalliday" wrote :
| What's the relationship between MC injection and profile service overriding the values using those from it's saved settings? I need very specific timing - the values must be set before certain events in the startup sequence if the value set is going to have an effect. When is this currently done and is there a way to control it?
The persisted changes will get applied to the BeanMetaData directly before the bean is handed over to MC and installed - so before the bean is instantiated.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249902#4249902
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249902
17 years, 1 month
[Design of POJO Server] - Re: profile service overview?
by jhalliday
Thanks for the pointers.
> Although the generated default view is most probably not usable for persistence, as it would try to persist all properties.
What's the problem with that? Type limitations?
I definitely don't want a compile time dependency on profile service, so it looks like using annotations in the -beans.xml is the way to go.
I can see how profile service can walk the bean properties and squirrel them aways for safe keeping (assuming they are serializable) but I'm less clear on the startup lifecycle.
What's the relationship between MC injection and profile service overriding the values using those from it's saved settings? I need very specific timing - the values must be set before certain events in the startup sequence if the value set is going to have an effect. When is this currently done and is there a way to control it?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249893#4249893
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249893
17 years, 1 month