While reviewing the Mule Management Console i needed to install a Enterprise Edition of the Mule ESB. To start quickly with the review i took a application that we developed on the Mule Community Edition. The software that i took was based on the Community Edidtion version 2.2.1 and i would not expect any problem between the versions 2.2.1 and 2.2.5. After installing Mule ESB I deployed the Mule Mangement Console i was ready to start the mule application thinking that it all would work fine. But while starting mule i got the following message:
Caused by: java.lang.NoSuchMethodError: org.mule.api.transport.PropertyScope.getScope()Ljava/lang/String;
I found the API of Mule ESB 2.2.1 nicely online but the API documentation of version 2.2.5 i could not find online but luckly Mulesoft includes the documentation in their download files so i had them on the server. Comparing the documentation of PropertyScope results in the following:
version 2.2.1
version 2.2.5
This is something i didn’t expect because it’s still in version 2.2 is it then allowed to make such changes in the interfaces? I have to make now some changes to the code before i can continue.
Popularity: 14% [?]
Theo van Arem is a Integration specialist working at 
2 Responses to “Mule conversion from Community Edition 2.2.1 to Enterprise 2.2.5”
Hi Theo,
I perfectly understand your question, but in reality this classic convention isn’t always feasible. I’m surprised this slight api change even surfaced in your code, but then, it might have been a custom transport that uses it. I expect those people to be advanced users
Anyway, there were a number of internal changes to enable some nifty features for MMC, but they weren’t really user-facing. Mind it, blindly updating minor version number would scare away many customers needing stability of the codebase.
Hope this clarifies it a little.
Andrew
Andrew,
Thanks for the clarification. I just took a Mule application we developed and deployed it to the Enterprise Edition to evaluate the MMC. It’s of course not a good idea to blindly versions without testing it
.
It still stands that i didn’t expect this change in the API in a minor version. That you are maintaining the API’s in a structured way is a good thing but to rename them withing the 2.2 versions i just didn’t expect it.
Theo