Wit pojosr you can do similar things
Sent from my pressure cooker.
On Sep 26, 2013, at 10:25, Cristiano Costantini
<cristiano.costant...@gmail.com> wrote:
> Hi All,
> I'm curios to know more about Sptring DM classloader issue: what is it
> about?
> is it something that is going to be never solved as Spring DM 1.2.1 is the
> last version before the project moved to Gemini Blueprint?
>
>
> There are 2 main reasons I prefer to use Spring:
> - ability to write a pure spring application and run (and debug!) outside
> of the OSGi environment
> - ability to use custom XML DSL (i.e. the Spring MVC)
>
>
> The first point is very useful for us and I spend some more words on it.
> In in each bundle project, we have a test class with about the following
> code:
>
> public static void main(String[] args) throws IOException {
> ConfigurableApplicationContext springContext =
> new ClassPathXmlApplicationContext("META-INF/spring/beans.xml",
> "META-INF/spring/beans-test.xml");
> }
>
> "META-INF/spring/beans-test.xml" is on "src/test/resources" so it is not
> packaged in the bundle, while on the folder
> "src/main/resources/META-INF/spring/" we also add files usually named
> "beans-osgi.xml" which use Spring DM to reference or define osgi services.
> The file "META-INF/spring/beans.xml" is the big one, which is shared
> between in "deployment" and in "debug", while usually beans-test.xml
> defines mock beans to replace the osgi services defined in beans-osgi.xml
> (but sometime we use CXF to connect to real services on the production
> server).
>
> I wonder however if it is possible to do the same with blueprint (I would
> be happy to migrate to blueprint if the above is possible).
> Anyone knows?
>
> Cristiano
>
>
>
>
>
>
> 2013/9/26 Mike K <mikek...@gmail.com>
>
>> Hi Timothy,
>>
>> Go with Blueprint.
>> To be clear - the Spring in SMX is Spring DM that allows Spring context in
>> OSGi.
>> The Spring DM has classloader issue. This impacts bundle restart and
>> upgrade.
>> If you are Ok with restarting whole SMX container than Spring DM is Ok.
>> Keep in mind that not everything might be implemented in Blueprint vs
>> Spring DM
>>
>> Mike
>>
>> -----Original Message----- From: Timothy Creswick
>> Sent: Thursday, September 26, 2013 6:29 AM
>> To: users@servicemix.apache.org
>> Subject: Blueprint vs. Spring
>>
>>
>> Hi,
>>
>> We're working with a new ServiceMix deployment (v4.5) with a view to
>> migrating a lot of distinct business process applications to the platform.
>>
>> Most of our existing web front-ends are Spring web apps, so we're very
>> familiar with using Spring Framework. Existing back-ends are a huge variety
>> of technologies and will all be re-written. We're intending for modules to
>> all communicate over JMS (so that there is requirement to have modules in
>> the same OSGi container).
>>
>> When researching ServiceMix several months ago I'm sure I read some
>> references suggesting that Blueprint is the preferred method. Right now, we
>> can [realtively] easily pick either Blueprint or Spring, although my
>> preference would be to primarily only use one in order to minimise training.
>>
>> Blueprint appears to be a bit more elegant, although I can't quite put my
>> finger on why that is. I gather it should also handle dependency injection
>> better than Spring, although we're using a relatively small subset of 3rd
>> party libs.
>>
>> I primarily wanted to get a sense of:
>>
>> 1. What are people mostly using?
>> 2. What are the advantages / issues with your chosen approach?
>> 3. With hindsight, would you change it?
>>
>> Also, are there any major gotchyas if we pick one method or the other
>> (i.e. something that we won't be able to do later without changing things)?
>>
>> Many thanks,
>>
>> Tim
>>
>>
