[
https://issues.apache.org/jira/browse/MUSE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502780
]
Bogdan Solomon commented on MUSE-235:
-------------------------------------
After doing even more tests (and with a clear head in the morning), there is no
bug in the JRE either. The HashMap is storing linked lists so Eclipse only
shows the first element in the list on inspection.
My problem with the Muse exception was caused by a missing entry in service.xml
for the Configure action. So I will close this incorrect report, sorry.
> Capability by action being overwritten and resulting in a "The [action]
> cannot be processed at the receiver"
> ------------------------------------------------------------------------------------------------------------
>
> Key: MUSE-235
> URL: https://issues.apache.org/jira/browse/MUSE-235
> Project: Muse
> Issue Type: Bug
> Components: Core Engine - Resource and Capability APIs
> Affects Versions: 2.2.0
> Environment: Muse 2.2.0 running under WebSphere 6.1 and Java5 (IBM
> JRE) on WindowsXP.
> Reporter: Bogdan Solomon
> Assignee: Dan Jemiolo
>
> This is a very strange bug I found in the
> SimpleResource.addCapability(Capability capability) and it does seem to
> happen under very strict conditions.
> My capability defines four actions: Start, Stop, Remove and Configure all
> under the same namespace:
> http://tivoli.ibm.com/muse/filter/management/Configure
> http://tivoli.ibm.com/muse/filter/management/Start
> http://tivoli.ibm.com/muse/filter/management/Stop
> http://tivoli.ibm.com/muse/filter/management/Remove
> However when trying to call Configure, which gets generated fine on the proxy
> I get a "The [action] cannot be processed at the receiver" exception.
> So I traced the code through muse-core and I discovered that the
> AbstractCapability obtains all four handlers and sets them correctly in the
> _handlersByAction Map. However when the execution reaches
> SimpleResource.addCapability(Capability capability) and tries to set the
> information in the resource's map _capabilitiesByAction it actually
> overwrites the Configure action.
> The first loop through the iterator adds the correct mapping for Configure in
> the HashMap, however the second execution overwrites the Configure mapping
> with the Remove mapping. The final two Start and Stop are added correctly to
> empty locations in the Map.
> Since it does not throw a DuplicateAction exception (and I traced that part),
> it knows the map does not already contain the Remove mapping, however it
> still overwrites it.
> So I am blocked, I am not sure if this is a bug in the JRE implementation of
> the HashMap, or if it is some form of synchronization issue (although this is
> a simple serial execution from what I can tell).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
