[#MULE-2795] Duplicate bean when ID set

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: 2.0.0-M2
Fix Version/s: 2.0.0-RC1
Component/s: Core: Configuration
Labels:
None

User impact:
Medium
Similar Issues:
~~MULE-1239~~ Mule Manager ID is not set when using Mule+Spring configuration
~~MULE-2142~~ Server ID is automatically generated in spite of that "id" attribue is set in mule-configuration
MULE-5196 Ambiguous bean naming causes spurious errors with parent bean context
MULE-5838 JMSMessageToObject fails to set Correlation-ID when passed as inbound property
MULE-4746 Inconsistent bean name generation causes double instantiation
MULE-5107 Advancement of a jBPM process with a manually set process ID is broken
~~MULE-2083~~ Improve handling of global (default) beans in config
~~MULE-180~~ Can't set a transformer as a bean property when defined in a <properties> element
MULE-5216 Setting the payload to a spring bean ref on an quartz:event-generator-job causes an exception
~~MULE-31~~ Duplicate class

Description

there's a util method we should be using (can't remember where) that will do this - check that all name/id use is regularized.

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

andrew cooke added a comment - 11/Dec/07 01:24 PM

from email:

I am writing some examples based on Mule Configuration and Spring configuration intertwined.
In case that spring bean ID is set (and the name isn't set), I can see that the instance created and registered twice, first time with his id and the second time .:id

It happens in MuleHierarchicalBeanDefinitionParserDelegate.java

protected String generateChildBeanName(Element e)
{
String id = e.getAttribute("name"); //isn't it suppose to check also the id ?
if (StringUtils.isBlank(id))

{ //same thing can happen here. String parentId = ((Element) e.getParentNode()).getAttribute("name"); id = e.getLocalName(); return "." + parentId + ":" + id; }

else

{ return id; }

}

Show

andrew cooke added a comment - 11/Dec/07 01:24 PM from email: I am writing some examples based on Mule Configuration and Spring configuration intertwined. In case that spring bean ID is set (and the name isn't set), I can see that the instance created and registered twice, first time with his id and the second time .:id It happens in MuleHierarchicalBeanDefinitionParserDelegate.java protected String generateChildBeanName(Element e) { String id = e.getAttribute("name"); //isn't it suppose to check also the id ? if (StringUtils.isBlank(id)) { //same thing can happen here. String parentId = ((Element) e.getParentNode()).getAttribute("name"); id = e.getLocalName(); return "." + parentId + ":" + id; } else { return id; } }

Hide

Permalink

andrew cooke added a comment - 11/Dec/07 01:31 PM

i cannot reproduce this! i can certainly see how the problem could arise if the code was called, but that code is not called for spring namespace elements (as far as i can tell), and when it is called with mule elements they are restricted by their schema to have "name" and not "id".

the email says that the config is mixing mule and spring configurations, so i assume i am missing some corner case (or perhaps something obvious). but for the following simple case, the code in question is not called (the "if" statement for id being empty never succeeds; verified in debugger):

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:spring="http://www.springframework.org/schema/beans"
      xsi:schemaLocation="
      http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
      http://www.mulesource.org/schema/mule/core/2.0 http://www.mulesource.org/schema/mule/core/2.0/mule.xsd">

    <spring:bean name="beanNameOnly" class="java.lang.Object"/>
    <spring:bean id="beanIdOnly" class="java.lang.Object"/>
    <spring:bean id="beanBothName" name="beanBothId" class="java.lang.Object"/>
    <spring:bean id="beanBothConflict" name="beanBothConflict" class="java.lang.Object"/>

</mule>

i'd really like to be able to duplicate this before i add a test for it.

Show

andrew cooke added a comment - 11/Dec/07 01:31 PM i cannot reproduce this! i can certainly see how the problem could arise if the code was called, but that code is not called for spring namespace elements (as far as i can tell), and when it is called with mule elements they are restricted by their schema to have "name" and not "id". the email says that the config is mixing mule and spring configurations, so i assume i am missing some corner case (or perhaps something obvious). but for the following simple case, the code in question is not called (the "if" statement for id being empty never succeeds; verified in debugger):

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:spring="http://www.springframework.org/schema/beans"
      xsi:schemaLocation="
      http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
      http://www.mulesource.org/schema/mule/core/2.0 http://www.mulesource.org/schema/mule/core/2.0/mule.xsd">

    <spring:bean name="beanNameOnly" class="java.lang.Object"/>
    <spring:bean id="beanIdOnly" class="java.lang.Object"/>
    <spring:bean id="beanBothName" name="beanBothId" class="java.lang.Object"/>
    <spring:bean id="beanBothConflict" name="beanBothConflict" class="java.lang.Object"/>

</mule>

i'd really like to be able to duplicate this before i add a test for it.

Hide

Permalink

andrew cooke added a comment - 12/Dec/07 09:46 AM

this now clarified and fixed. there were two issues, really:

we didn't handle 3rd party BDPs that set "id" rather than "name"
our own code's handling of name/id was less than exemplary
so i cleaned up our own code and made sure that we better handle 3rd party parsers.

Show

andrew cooke added a comment - 12/Dec/07 09:46 AM this now clarified and fixed. there were two issues, really:

we didn't handle 3rd party BDPs that set "id" rather than "name"
our own code's handling of name/id was less than exemplary so i cleaned up our own code and made sure that we better handle 3rd party parsers.

Hide

Permalink

andrew cooke added a comment - 12/Dec/07 09:47 AM

req merge into RC1 (although best check next CI build ok first!)

Show

andrew cooke added a comment - 12/Dec/07 09:47 AM req merge into RC1 (although best check next CI build ok first!)

Hide

Permalink

Andrew Perepelytsya added a comment - 12/Dec/07 09:57 AM

And the revision number is...

Show

Andrew Perepelytsya added a comment - 12/Dec/07 09:57 AM And the revision number is...

Hide

Permalink

andrew cooke added a comment - 12/Dec/07 10:08 AM

...10069

Show

andrew cooke added a comment - 12/Dec/07 10:08 AM ...10069

People

Assignee:

Travis Carlson

Reporter:

andrew cooke

Vote (0)

Watch (0)

Dates

Created:

11/Dec/07 12:16 PM

Updated:

13/Dec/07 02:18 PM

Resolved:

13/Dec/07 02:18 PM