How to dynamically add and register new attributes to mbean - jboss

Is it possible to dynamically add and register new attributes to mbean
eg :
<server>
<mbean code="org.jboss.example.MyMbean" name="jboss:service=myMbean,name=MyMbeanExample">
<attribute name="attribute1">value1</attribute>
<attribute name="attribute2">value2</attribute>
<attribute name="attribute3">value3</attribute>
<attribute name="attribute4">value5</attribute>
<attribute name="attribute5">value5</attribute>...
</mbean>
</server>
A new attribute added in jboss-service.xml should be registered in MyMbean dynamically with making any code change in Mbean, can this be done?
Thanks in Advance.

It's hard to answer your question without seeing the code of your DynamicMBean, but I suspect the answer to your question, with the proviso that there be no code changes in the MBean, is no. However, here's an overall approach (taking some liberal assumptions about your code):
A DynamicMBean like this will usually have some sort of map, keyed by the attribute name, and and containing either the value of the attribute (easy), or a value object containing some or all of the following intended to acquire/set the value of the attribute:
a target invocation object,
a method
an array of arguments to the method
When the MBeanInfo of the MBean is requested, the supplied MBeanAttributeInfos should reference the keys in this map (as well as the data type, mutability etc.) You can either generate these on the fly every time MBeanInfo is requested, or keep an updated collection of MBeanAttributeInfo which is updated whenever you add a new attribute.
The methods setAttribute and setAttributes should create a new attribute (by inserting the new key and value into the attribute map) if the set references an attribute that does not already exist.
Since you're using JBoss, if you feel you might want to implement something like this, consider extending JBoss's ServiceDynamicMBeanSupport. It does some, but not all, of the legwork for you.

Related

Number of converter instance for binding in UWP

How many instance does binding creates internally for converters.
<Image x:Uid="DisplayedImageUrl" Style="{StaticResource ImageStyle}"
Source="{Binding DisplayedImageURL, Converter={StaticResource ImageLogoConverter}}" />
How many instance does of ImageLogoConverter will be there?
Is it good idea to use converter in ViewModel, if not then what is the best way to access converted value of ViewModel property.
Is it good idea to use converter in ViewModel?
No. Why would you use a converter in a view model where you can return the converted value directly? Converters are used in the view, typically to convert a non-view friendly value that the view model returns.
If not then what is the best way to access converted value of ViewModel property?
You can simpy return an already converted value from the view model, i.e. instead of binding to a Uri property, you may bind directly to an ImageSource property.
This is the recommnded approach if you for example intend to display a lot of elements in a ItemsControl. Then you probably don't want to invoke a converter for each visible element for performance reasons.
I suppose you created the converter as a resource like this:
The number of instances now depends on the scope where the converter resource is declared. If you create it in <Page.Resources>, one instance will be created to be used by the page. If you create it in App.xaml in <Application.Resources> it will be an application-wide instance. Of course, you can even use a narrower scope - create it as a resource of a single control in your XAML tree for example - in any case, a single instance is created when instance of the parent is created.
The situation gets a bit more interesting if you embed it in a ItemTemplate of a list control. Thanks to virtualization, the system will not actually create one instance for each item. Instead, it will create only so many instances as fit on the screen and they get reused when the user scrolls.
Some MVVM developers don't like value converters, but others use them extensively. It really is a matter of preference. In cas you expect the underlying data to change often, it is advisable to keep the code in the converter as performant as possible as it runs on the UI thread.

How can I read out the "glade ID" of a gtk3 object

In glade it is possible to set an unique ID to an object. In the code one can obtain a pointer to this object by searching for it's "glade ID" via gtk_builder_get_object().
However for my current use-case I just want to read out this ID from an GObject. What's the API to do so ?
You can't. The builder ID is stored in the builder internally, not in the GObject.
The reason for this is that IDs must be unique per builder, which would be impossible to enforce if you were able to get and set them via some GObject API.
You could use gtk_widget_get_name() to identify an object.
It is possible using Gtk.Buildable.get_name(object). This method will return the Glade object id.
This snippet will print all object ids in your Glade XML:
builder = Gtk.Builder()
builder.add_from_file("my-window.glade"))
for obj in builder.get_objects():
print(Gtk.Buildable.get_name(obj))
As stated by #ptomato it's seems not possible.
I found that in that line in the documentation:
All the fields in the GObject structure are private to the
implementation and should never be accessed directly.
But you can circumvent it because at one point in your code you were refering to it by the id that you typed in (or the code you wrote type in) so you just need to store it at that point. And link it somehow (with a variable or a data structure) to the name of the variable holding the object.

How does Jackrabbit generate jcr:uuid (in AEM)?

I am trying to create an auto-generated GUID property on all cq:PageContent nodes. This will be similar to the jcr:uuid property, but will be persisted with content promotion/replication/package installs (whereas the jcr:uuid for a content item changes between different environments).
I am trying to determine how AEM/JCR generates the jcr:uuid property on node creation. The CND defining the property is:
[mix:referenceable]
mixin
- jcr:uuid (string) mandatory autocreated protected initialize
I've tried defining my GUID property in a similar manor, specifying the autocreated and initialize attributes, but this did not result in auto-generation of the property.
Could anybody point me to the source of the jcr:uuid's generation?
As an aside, I asked a related question on the Adobe Community Forum: http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manager.topic.5_ciot.html/forum__bnxr-i_am_tryingtocreat.html
You don't mention which version of AEM (so whether you're dealing with Jackrabbit or Oak), but the mechanism turns out to be basically the same.
When assigning a default value, there are a few hard-coded system property names that get special treatment (jcr:uuid being one of them). If the name of the property being assigned a default value doesn't match any of the special cases, it falls back the static list of default values from the property definition (e.g. listed in the CND file).
In summary, it looks like you cannot piggy-back on this mechanism to assign your own dynamic default value for an arbitrary property. You would need to implement your own event listener or something.
Jackrabbit: See the implementation of setDefaultValues and computeSystemGeneratedPropertyValues
Oak: See the implementation of TreeUtil autoCreateProperty

GWT: is properties global for whole application?

I've got the following config <when-property-is name="isExecute" value="true" />.
Am I able to set property isExecute for module A true and for module B false?
Am I able to change property value by Java?
Does GWT.create read property condition each call or only once (cache)?
What are you trying to achieve? Replacing implementations during runtime? You can use Generator to do this.

GWT: Replace AbstractPlaceHistoryMapper with a custom mapper using deferred binding

Looks like the class that is generated for PlaceHistoryMapper is hard-coded to use AbstractPlaceHistoryMapper as the super class.
So, I am trying to work around this by trying to replace this AbstractPlaceHistoryMapper with a custom mapper of mine using deferred binding . I am using the following rule in my *.gwt.xml:
<replace-with class="com.google.gwt.place.impl.AbstractPlaceHistoryMapper">
<when-type-is class="com.test.sampleapp.CustomPlaceHistoryMapper" />
</replace-with>
But for some reason the replace does not seem to be happening. CustomPlaceHistoryMapper is not getting kicked in and the generated class still uses AbstractPlaceHistoryMapper.
Any thoughts/pointers as to what might be resulting this behavior are much appreciated.
Note: I have also posted this on the GWT group but haven't received an answer so far.
To make the deferred binding work a class must be created with GWT.create(). However, AbstractPlaceHistoryMapper is only used as an extended class. So it will never be created via GWT.create, but always by instantiation the subclass. And therefor deferred binding won't work in this case. If you want a complete different implementation you have to implement a custom PlaceHistoryMapper, and manage the known tokens yourself. This also means you can't use the History annotations either.
As a side note the classnames in your rule should be swapped. But for the end result this doesn't matter, since it won't work in the first place.
It is absolutely possible to have custom history tokens (eg. #mail or #mail/bla instead of only #mail:inbox) using the out-of-the-box Place-related classes that GWT (2.0) provides.
Instead of replacing AbstractPlaceHistoryMapper you could instantiate the default PlaceHistoryMapper passing in it's constructor your implementation of PlaceHistoryMapper<T> or PlaceHistoryMapperWithFactory<T>.
eg.:
final PlaceHistoryHandler placeHistoryHandler = new PlaceHistoryHandler(new CustomHistoryMapper());
You will be able then to map tokens as you wish.
I personally recommend you to use an unique PlaceTokenizer in you mapper custom implementation so that I dont have to have an inner PlaceTokenizer class in each of your Places.
Hope that helps. Feel free to ask any doubts.