JBAS-2228: PropertyEditor service doesn't understand hot dep

[adrian.brock]

http://jira.jboss.com/jira/browse/JBAS-2228

I'd describe the lack of understanding of the context classloader as a bug.

However, if the use envisioned will cause a memory leak
for any hotdeployed class.

PropertyEditorManager -> Your.ear class -> Your.ear classloader

Better would be to do the registration in createService()
with register(clazz, null) in destroyService()

however that means it won't work properly since the MBean.setAttributes()
are not a part of the dependency lifecycle. There is no way to make
the setter invocations wait for the editor registration in create().

It still needs a destroyService() with the register(clazz, null) unregistration
regardless, if this MBean is going to be hotdeployed.

[genman]

It would be possible to keep a "Map" of properties and then wait to register them all during create(). However it would break this sort of usage in a jboss-service.xml:

<mbean class='PropertyEditorManagerService' ...>
 <attribute name="Editors">
 com.example.FooEditor=com.example.FooEditor
 </attribute>
 </mbean>

<mbean class='FooEditorUser' ...>
 <attribute name='Foo1'>xxx</attribute>
 <!-- xxx is a Foo -->

Perhaps the best solution is a non-symmetrical destroy().

[adrian.brock]

"genman" wrote:

Perhaps the best solution is a non-symmetrical destroy().

That would at least solve the memory leak.

[starksm64]

This is the generic problem with singleton factories that don't have an application level scope. If I have two scoped ears deploying the same propertyeditor its fubar big time for the second ear to deploy. We really should be using PropertyEditor instances without using the PropertyEditorManager. I don't think we really have much reliance on the finding a PropertyEditor using the PropertyEditorManager and its search path.

[genman]

Would it make sense to have a deployer contain a list of property editor managers?

[starksm64]

Logically, yes, but not every context that uses PropertyEditors has knowledge of/access to the deployment info.

[starksm64]

So one step forward is to have named collections of PropertyEditors in the org.jboss.util.propertyeditor.PropertyEditors class that is managed by the SARDeployer. The key could be the mbean object name string. Additional scope aware methods would be needed:

 public static PropertyEditor findEditor(final Class type, String scope)
 {
...
 }
 public static void registerEditor(final Class type, final Class editorType, String scope)
 {
...
 }
 public static void unregisterEditor(final Class type, final Class editorType, String scope)
 {
...
 }

If an editor was not found in the named scope the default scope should be consulted.

[starksm64]

I see the JBAS-2228 issue was resolved, but the more generic issue of dealing with scoped PropertyEditors with redeployment remains unsolved. I have created a http://jira.jboss.com/jira/browse/JBAS-2373 issue to track this problem.

[dimitris]

I'm looking into those 2 issues:

http://jira.jboss.com/jira/browse/JBAS-1709
http://jira.jboss.com/jira/browse/JBAS-2373

I understand that the above are not necessarily related.

JBAS-1709 needs to deal with the fact that when a property editor is executed (setAsText()/getValue()) it needs to have it's TCL properly set to the classloader of the mbean we are configuring (which maybe a scoped one). This is mostly to deal with ClassEditor & ClassArrayEditor, the only editors that will dynamically instantiate new Class objects.

JBAS-2373 deals with how we create a scoped space for property editors, thus affecting how a property editor is registered and looked-up.

So I guess they can be solved independenly? Do you see any issue applying the JBAS-1709 patch first, the deal with JBAS-2373?

Solving JBAS-1709 is essential for the usecase where a scoped mbean uses the JRMPProxyFactory to export a (scoped) interface, and naturally fails because the ClassArrayEditor doesn't have access to the scoped interfaces.

[starksm64]

I would think that solving JBAS-2373 will solve JBAS-1709 as the ServiceConfigurator will have to deal with possibly scoped property editors. JBAS-1709 could be done, but it would seem if would simply be redone to deal with scoped property editors. The JBAS-1709 change to use the class loader registered under loaderName is the correct class loader regardless.

[dimitris]

Half of the problem should be solved now (JBAS-1709).

Apparently, this affected also mbean attribute "proxy" and "javabean" injections coming from scoped deployments.

I'll look into the other half.

[dimitris]

I'm trying to see what would be a proper "scope" key for the property editor namespace.

I guess, the primary usecase is the PropertyEditorManagerService registers some property editor inside a namespace, then ServiceConfigurator/ServiceCreator look for property editors inside that namespace.

I'm not sure which mbean's name is what Scott refers to. There is also JBossXMBean10 that uses the property editors for configuration (and a couple of other classes), so how those will have access to the scope key?

Isn't that the key is really the deployment classloader? (But using it as a key make bring GC issues?)