Hi Alexander,
you can specify the profile you want to run as a System property named „spring.profiles.active“. So it looks like -Dspring.profiles.active=development or -Dspring.profiles.active=production.
If none is specified the default profile is used.
Does that answer your question?
Bye,
Jan
Von: gemini-dev-bounces@xxxxxxxxxxx [mailto:gemini-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Alexander Shutyaev
Gesendet: Montag, 21. Januar 2013 20:18
An: Gemini and sub-projects developer discussions
Betreff: Re: [gemini-dev] bean definition profiles support in gemini blueprint
Hi Glyn, Jan
Thanks for your responses!
My problem was not with the xml file, but with the context that is created automatically by the extender. I wonder how can I specify the active profiles to use
when my META-INF/spring/*.xml files are parsed and deployed? Do you have an answer?
Thanks for the point, I'll see what I can do. Although could you please clarify your phrase "if you can
make the change so that it also works with Spring framework 3.0.x"? I think that if it is Srping 3.0.x the xml definition itself would not match the xsd schema if I use profiles. Did you mean maybe that it should be an optional functionality that works if
spring is >= 3.1 and just does nothing if spring is < 3.1 ?
2013/1/21 Jan Stamer <J.Stamer@xxxxxxxxxxxxxxxxxxxx>
Hi Alexander,
actually you can use profiles along with Gemini Blueprint without problems. We are doing just that in our project.
The trick is to use the Spring 3.1 namespace and not the Blueprint one.
If you have questions feel free to contact me!
Hi Alexander
Glyn
On 21 Jan 2013, at 13:53, Alexander Shutyaev wrote:
Hi all!
Is there any support for Bean Definition Profiles [1] in gemini blueprint project?
No.
If yes, how can I specify the active profiles to use when my META-INF/spring/*.xml files are parsed and deployed? If no, then maybe you can show me some entry point in the current source code, so I can implement this support and share it.
Our app really needs this. :)
I'm afraid I don't have the Gemini Blueprint codebase in my head - I'm really only a caretaker project lead currently. But I would start with the ContextLoaderListener class as the entry point for the extender and go from there.
If you do implement support, please bear in mind that not all users will necessarily want to pre-req. Spring framework 3.1, so if you can make the change so that it also works with Spring framework 3.0.x, so much the better. We are currently
aiming to release Gemini Blueprint 2.0 around March, so that might be a good vehicle to carry your changes.
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
|