You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by "Bogdan Solomon (JIRA)" <ji...@apache.org> on 2007/06/07 19:17:26 UTC
[jira] Created: (MUSE-235) Capability by action being overwritten
and resulting in a "The [action] cannot be processed at the receiver"
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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
[jira] Commented: (MUSE-235) Capability by action being overwritten
and resulting in a "The [action] cannot be processed at the receiver"
Posted by "Bogdan Solomon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MUSE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502453 ]
Bogdan Solomon commented on MUSE-235:
-------------------------------------
After doing some more tests I have reached the conclusion this is a bug in the IBM JRE that WebSphere runs under. The HashMap behaves as expected while running SUN's JDK, but when I run the following code in WebSphere6.1:
HashMap map = new HashMap();
map.put("http://tivoli.ibm.com/muse/filter/management/Configure", "a");
map.put("http://tivoli.ibm.com/muse/filter/management/Remove", "a");
it results in the second addition overwriting the first one (for some reason they both map to the 5th index in the hashmap's table and the container does not seem to do the collision detection).
So, I am not sure if I should close this or not.
> 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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
[jira] Closed: (MUSE-235) Capability by action being overwritten
and resulting in a "The [action] cannot be processed at the receiver"
Posted by "Bogdan Solomon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MUSE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bogdan Solomon closed MUSE-235.
-------------------------------
Resolution: Invalid
> 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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
[jira] Commented: (MUSE-235) Capability by action being overwritten
and resulting in a "The [action] cannot be processed at the receiver"
Posted by "Bogdan Solomon (JIRA)" <ji...@apache.org>.
[ 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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org