From baszero at gmail.com  Tue Jan  3 17:05:03 2012
From: baszero at gmail.com (basZero)
Date: Tue, 3 Jan 2012 17:05:03 +0100
Subject: [Yanel-dev] xinclude
In-Reply-To: <4EF47636.20901@wyona.com>
References: <CAOXzDSG6467UMEeY+qT02EPGsPfgTb0sr3vz2LWsOFDC4JxorA@mail.gmail.com>
	<4EF40A68.8050308@wyona.com>
	<CAOXzDSGYC3GaKn4hV-SapFMvA1ZwDdzVRwy60vyyLm2-p3ZCuw@mail.gmail.com>
	<4EF47636.20901@wyona.com>
Message-ID: <CAOXzDSFHzTGE62CjwduK0Ui_E=qnGE1CefNMcciAvBPJopJWGA@mail.gmail.com>

Hi Michael,
first of all, happy new year! I hope you had relaxing days over christmas.

I tested a bit further and I am still not able to produce the expected HTML.

So to sum up again, what I want to achieve is this:
- from XSL A (rendered as text/html) I do an xinclude of XSL B
(application/xml)
- within XSL B, I would like to produce this HTML at the end:

<script type="text/javascript">
<!-- Hi Michael //-->
</script>

While this can easily be achieved without using an xinclude (e.g. by
directly producing it in XSL A), I always end up in encoded characters:
HTML looks like this:

<script type="text/javascript">
&lt;!-- Hi Michael //-->
</script>
In XSL B, I tried many combinations, like:

<script type="text/javascript">
<![CDATA[<!--  Hi Michael //-->]]>
</script>

or

<script type="text/javascript">
&lt;!--  Hi Michael //-->
</script>

I currently think that it is impossible to produce the expected HTML if
application/xml has been chosen as mime type of the resource rendering XSL
B.

Maybe you have further thoughts about this, I'll try to implement a
workaround.
Cheers
Balz


On Fri, Dec 23, 2011 at 1:38 PM, Michael Wechner
<michael.wechner at wyona.com>wrote:

>  Dear Balz
>
> Am 23.12.11 10:16, schrieb basZero:
>
> Dear Michael,
> thanks for your reply.
> The scenario I was laying out is as follows:
> you have a page (served resource A) using the global.xsl. Resource A is
> configured to produce text/html at the end (mime property in yanel-rc).
>
>  In any XSL, executed in the context of resource A, I am able to produce
> this kind of HTML:
> <script type="text/javascript"><!--
> google_ad_client = "ca-pub-4234093452213266";
> /* Right Sidebar */
> google_ad_slot = "1819825771";
> google_ad_width = 160;
> google_ad_height = 600;
> //-->
> </script>
>
>  Every new line and every single character must exactly look like this in
> the resulting HTML (that's the rule given by Google AdSense, can't change
> that).
>
>  But when I want to produce that HTML in a resource configured with
> mimetype xhtml (like the header or the sidebar), It can not be rendered
> like that (because it's not XHTML)...
>
>
> I think the above script snippet is well-formed (at least when using
> xmllint).
>
> Maybe you have to add <?xml version="1.0"?> and include it as
> application/xml, whereas the page including the above
> then can be serialized as text/html
>
>
>
>  So this is how I came to the question, why can I not run the Header and
> Sidebar resource with mime type text/html :)
>
>  However, I can also embed the code in an XSL that is used by a text/html
> resource, so It will work, I just wondered, whether somebody knows...
>
>  If you have an idea, let me know.
>
>  Merry Christmas to you Michael and all others listening on this list!
>
>
> Very merry christmas to you and everybody else as well :-)
>
> Michael
>
>
> Gruess
> Balz
>
> On Fri, Dec 23, 2011 at 5:58 AM, Michael Wechner <
> michael.wechner at wyona.com> wrote:
>
>>  Am 22.12.11 16:49, schrieb basZero:
>>
>> dear all,
>>
>>  I have a general question:
>>
>>  usually the menu gets included via xinclude from the global XSL:
>>
>>  e.g.:
>>
>>         <xi:include href
>> ="yanelresource:/de/header.yanel?path={$yanel.path}"/>
>>
>>  it seems that the resource serving the content for that included
>> content must deliver content in mime type "application/xhtml+xml".
>> when changing it into "text/html" it throws many exceptions in the log.
>>
>>
>>  yes, because it's not considered to be well-formed
>>
>>
>>  does anybody have used includes with "text/html" content?
>>
>>
>>  why do you want to include something inside XML/XHTML, which might not
>> be XML/XHTML?
>>
>> Or otherwise you might want to consider to use CDATA, but I guess then
>> you would have to use something
>> different than xi:include, because I would assume that XInclude would
>> always require some well-formed XML/XHTML per definition.
>>
>> HTH
>>
>> Michael
>>
>>
>>  Thanks
>> cheers
>> Balz
>>
>>
>>
>>
>> --
>> Yanel-development mailing list Yanel-development at wyona.com
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>
>
>
>
>
> --
> Yanel-development mailing list Yanel-development at wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120103/7f2e6f5f/attachment-0001.html>

From michael.wechner at wyona.com  Fri Jan  6 00:39:28 2012
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri, 06 Jan 2012 00:39:28 +0100
Subject: [Yanel-dev] xinclude
In-Reply-To: <CAOXzDSFHzTGE62CjwduK0Ui_E=qnGE1CefNMcciAvBPJopJWGA@mail.gmail.com>
References: <CAOXzDSG6467UMEeY+qT02EPGsPfgTb0sr3vz2LWsOFDC4JxorA@mail.gmail.com>
	<4EF40A68.8050308@wyona.com>
	<CAOXzDSGYC3GaKn4hV-SapFMvA1ZwDdzVRwy60vyyLm2-p3ZCuw@mail.gmail.com>
	<4EF47636.20901@wyona.com>
	<CAOXzDSFHzTGE62CjwduK0Ui_E=qnGE1CefNMcciAvBPJopJWGA@mail.gmail.com>
Message-ID: <4F0634B0.8010207@wyona.com>

Hi Balz

Am 03.01.12 17:05, schrieb basZero:
> Hi Michael,
> first of all, happy new year!

the same to you
> I hope you had relaxing days over christmas.

thanks very much, hope you had a nice time as well
>
> I tested a bit further and I am still not able to produce the expected 
> HTML.
>
> So to sum up again, what I want to achieve is this:
> - from XSL A (rendered as text/html) I do an xinclude of XSL B 
> (application/xml)
> - within XSL B, I would like to produce this HTML at the end:
>
> <scripttype="text/javascript">
> <!-- Hi Michael //-->
> </script>
>
> While this can easily be achieved without using an xinclude (e.g. by 
> directly producing it in XSL A), I always end up in encoded characters:
> HTML looks like this:
>
> <script type="text/javascript">
> &lt;!-- Hi Michael //-->
> </script>
>
> In XSL B, I tried many combinations, like:
>
> <script type="text/javascript">
> <![CDATA[<!--  Hi Michael //-->]]>
> </script>
>
> or
>
> <script type="text/javascript">
> &lt;!--  Hi Michael //-->
> </script>
>
> I currently think that it is impossible to produce the expected HTML 
> if application/xml has been chosen as mime type of the resource 
> rendering XSL B.

thanks for describing the issue. I will try to reproduce what you 
describe above and give you some feedback as soon as possible.

Thanks

Michael
>
> Maybe you have further thoughts about this, I'll try to implement a 
> workaround.
> Cheers
> Balz
>
>
> On Fri, Dec 23, 2011 at 1:38 PM, Michael Wechner 
> <michael.wechner at wyona.com <mailto:michael.wechner at wyona.com>> wrote:
>
>     Dear Balz
>
>     Am 23.12.11 10:16, schrieb basZero:
>>     Dear Michael,
>>     thanks for your reply.
>>     The scenario I was laying out is as follows:
>>     you have a page (served resource A) using the global.xsl.
>>     Resource A is configured to produce text/html at the end (mime
>>     property in yanel-rc).
>>
>>     In any XSL, executed in the context of resource A, I am able to
>>     produce this kind of HTML:
>>     <scripttype="text/javascript"><!--
>>     google_ad_client ="ca-pub-4234093452213266";
>>     /* Right Sidebar */
>>     google_ad_slot ="1819825771";
>>     google_ad_width =160;
>>     google_ad_height =600;
>>     //-->
>>     </script>
>>
>>     Every new line and every single character must exactly look like
>>     this in the resulting HTML (that's the rule given by Google
>>     AdSense, can't change that).
>>
>>     But when I want to produce that HTML in a resource configured
>>     with mimetype xhtml (like the header or the sidebar), It can not
>>     be rendered like that (because it's not XHTML)...
>
>     I think the above script snippet is well-formed (at least when
>     using xmllint).
>
>     Maybe you have to add <?xml version="1.0"?> and include it as
>     application/xml, whereas the page including the above
>     then can be serialized as text/html
>
>>
>>
>>     So this is how I came to the question, why can I not run the
>>     Header and Sidebar resource with mime type text/html :)
>>
>>     However, I can also embed the code in an XSL that is used by a
>>     text/html resource, so It will work, I just wondered, whether
>>     somebody knows...
>>
>>     If you have an idea, let me know.
>>
>>     Merry Christmas to you Michael and all others listening on this list!
>
>     Very merry christmas to you and everybody else as well :-)
>
>     Michael
>
>>
>>     Gruess
>>     Balz
>>
>>     On Fri, Dec 23, 2011 at 5:58 AM, Michael Wechner
>>     <michael.wechner at wyona.com <mailto:michael.wechner at wyona.com>> wrote:
>>
>>         Am 22.12.11 16:49, schrieb basZero:
>>>         dear all,
>>>
>>>         I have a general question:
>>>
>>>         usually the menu gets included via xinclude from the global XSL:
>>>
>>>         e.g.:
>>>
>>>         <xi:include
>>>         href="yanelresource:/de/header.yanel?path={$yanel.path}"/>
>>>
>>>
>>>         it seems that the resource serving the content for that
>>>         included content must deliver content in mime type
>>>         "application/xhtml+xml".
>>>         when changing it into "text/html" it throws many exceptions
>>>         in the log.
>>
>>         yes, because it's not considered to be well-formed
>>
>>>
>>>         does anybody have used includes with "text/html" content?
>>
>>         why do you want to include something inside XML/XHTML, which
>>         might not be XML/XHTML?
>>
>>         Or otherwise you might want to consider to use CDATA, but I
>>         guess then you would have to use something
>>         different than xi:include, because I would assume that
>>         XInclude would always require some well-formed XML/XHTML per
>>         definition.
>>
>>         HTH
>>
>>         Michael
>>>
>>>         Thanks
>>>         cheers
>>>         Balz
>>>
>>>
>>
>>
>>         --
>>         Yanel-development mailing list Yanel-development at wyona.com
>>         <mailto:Yanel-development at wyona.com>
>>         http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>
>
>     --
>     Yanel-development mailing list Yanel-development at wyona.com
>     <mailto:Yanel-development at wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120106/0089a7ca/attachment-0001.html>

From baszero at gmail.com  Fri Jan  6 07:24:53 2012
From: baszero at gmail.com (basZero)
Date: Fri, 6 Jan 2012 07:24:53 +0100
Subject: [Yanel-dev] xinclude
In-Reply-To: <4F0634B0.8010207@wyona.com>
References: <CAOXzDSG6467UMEeY+qT02EPGsPfgTb0sr3vz2LWsOFDC4JxorA@mail.gmail.com>
	<4EF40A68.8050308@wyona.com>
	<CAOXzDSGYC3GaKn4hV-SapFMvA1ZwDdzVRwy60vyyLm2-p3ZCuw@mail.gmail.com>
	<4EF47636.20901@wyona.com>
	<CAOXzDSFHzTGE62CjwduK0Ui_E=qnGE1CefNMcciAvBPJopJWGA@mail.gmail.com>
	<4F0634B0.8010207@wyona.com>
Message-ID: <CAOXzDSHwYxDXe+w=Fp1hs-XWtLiQBUS6x+3xjVBiwt6JPqBErw@mail.gmail.com>

Hi Michael,
thanks for having a look at it, as it is a general question in XSLT I guess.
But just to let you know, I've implemented a workaround now, so it is not
urgent anymore for me, but I'd be still interested, if it is possible in
any way to solve it :)

Thanks
Cheers
Balz

On Fri, Jan 6, 2012 at 12:39 AM, Michael Wechner
<michael.wechner at wyona.com>wrote:

>  Hi Balz
>
> Am 03.01.12 17:05, schrieb basZero:
>
> Hi Michael,
> first of all, happy new year!
>
>
> the same to you
>
>  I hope you had relaxing days over christmas.
>
>
> thanks very much, hope you had a nice time as well
>
>
>  I tested a bit further and I am still not able to produce the expected
> HTML.
>
>  So to sum up again, what I want to achieve is this:
> - from XSL A (rendered as text/html) I do an xinclude of XSL B
> (application/xml)
> - within XSL B, I would like to produce this HTML at the end:
>
>  <script type="text/javascript">
> <!-- Hi Michael //-->
> </script>
>
>  While this can easily be achieved without using an xinclude (e.g. by
> directly producing it in XSL A), I always end up in encoded characters:
> HTML looks like this:
>
> <script type="text/javascript">
> &lt;!-- Hi Michael //-->
> </script>
>  In XSL B, I tried many combinations, like:
>
> <script type="text/javascript">
> <![CDATA[<!--  Hi Michael //-->]]>
> </script>
>
> or
>
>  <script type="text/javascript">
> &lt;!--  Hi Michael //-->
> </script>
>  I currently think that it is impossible to produce the expected HTML if
> application/xml has been chosen as mime type of the resource rendering XSL
> B.
>
>
> thanks for describing the issue. I will try to reproduce what you describe
> above and give you some feedback as soon as possible.
>
> Thanks
>
> Michael
>
>
> Maybe you have further thoughts about this, I'll try to implement a
> workaround.
> Cheers
> Balz
>
>
>  On Fri, Dec 23, 2011 at 1:38 PM, Michael Wechner <
> michael.wechner at wyona.com> wrote:
>
>>  Dear Balz
>>
>> Am 23.12.11 10:16, schrieb basZero:
>>
>> Dear Michael,
>> thanks for your reply.
>> The scenario I was laying out is as follows:
>> you have a page (served resource A) using the global.xsl. Resource A is
>> configured to produce text/html at the end (mime property in yanel-rc).
>>
>>  In any XSL, executed in the context of resource A, I am able to produce
>> this kind of HTML:
>> <script type="text/javascript"><!--
>> google_ad_client = "ca-pub-4234093452213266";
>> /* Right Sidebar */
>> google_ad_slot = "1819825771";
>> google_ad_width = 160;
>> google_ad_height = 600;
>> //-->
>> </script>
>>
>>  Every new line and every single character must exactly look like this
>> in the resulting HTML (that's the rule given by Google AdSense, can't
>> change that).
>>
>>  But when I want to produce that HTML in a resource configured with
>> mimetype xhtml (like the header or the sidebar), It can not be rendered
>> like that (because it's not XHTML)...
>>
>>
>>  I think the above script snippet is well-formed (at least when using
>> xmllint).
>>
>> Maybe you have to add <?xml version="1.0"?> and include it as
>> application/xml, whereas the page including the above
>> then can be serialized as text/html
>>
>>
>>
>>  So this is how I came to the question, why can I not run the Header and
>> Sidebar resource with mime type text/html :)
>>
>>  However, I can also embed the code in an XSL that is used by a
>> text/html resource, so It will work, I just wondered, whether somebody
>> knows...
>>
>>  If you have an idea, let me know.
>>
>>  Merry Christmas to you Michael and all others listening on this list!
>>
>>
>>  Very merry christmas to you and everybody else as well :-)
>>
>> Michael
>>
>>
>> Gruess
>> Balz
>>
>> On Fri, Dec 23, 2011 at 5:58 AM, Michael Wechner <
>> michael.wechner at wyona.com> wrote:
>>
>>>  Am 22.12.11 16:49, schrieb basZero:
>>>
>>> dear all,
>>>
>>>  I have a general question:
>>>
>>>  usually the menu gets included via xinclude from the global XSL:
>>>
>>>  e.g.:
>>>
>>>         <xi:include href
>>> ="yanelresource:/de/header.yanel?path={$yanel.path}"/>
>>>
>>>  it seems that the resource serving the content for that included
>>> content must deliver content in mime type "application/xhtml+xml".
>>> when changing it into "text/html" it throws many exceptions in the log.
>>>
>>>
>>>  yes, because it's not considered to be well-formed
>>>
>>>
>>>  does anybody have used includes with "text/html" content?
>>>
>>>
>>>  why do you want to include something inside XML/XHTML, which might not
>>> be XML/XHTML?
>>>
>>> Or otherwise you might want to consider to use CDATA, but I guess then
>>> you would have to use something
>>> different than xi:include, because I would assume that XInclude would
>>> always require some well-formed XML/XHTML per definition.
>>>
>>> HTH
>>>
>>> Michael
>>>
>>>
>>>  Thanks
>>> cheers
>>> Balz
>>>
>>>
>>>
>>>
>>> --
>>> Yanel-development mailing list Yanel-development at wyona.com
>>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>>
>>
>>
>>
>>
>>
>> --
>> Yanel-development mailing list Yanel-development at wyona.com
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>
>
>
>
>
> --
> Yanel-development mailing list Yanel-development at wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120106/53a19add/attachment-0001.html>

From simon at 333.ch  Wed Jan 18 10:10:19 2012
From: simon at 333.ch (simon)
Date: Wed, 18 Jan 2012 10:10:19 +0100
Subject: [Yanel-dev] deployment
Message-ID: <4F168C7B.5030603@333.ch>

hi all

just wondering why yanel resp. tomcat is mostly deployed behind an apache?
what's the reason and does someone has experience in using the tomcat 
without an apache web server in front?

cheers
simon

From baszero at gmail.com  Wed Jan 18 10:19:15 2012
From: baszero at gmail.com (basZero)
Date: Wed, 18 Jan 2012 10:19:15 +0100
Subject: [Yanel-dev] deployment
In-Reply-To: <4F168C7B.5030603@333.ch>
References: <4F168C7B.5030603@333.ch>
Message-ID: <CAOXzDSGxJs+6L-8+th45HKn5x61vQhiP+MeJpCTBs58x6Gtu=A@mail.gmail.com>

Hi Simon,

in larger enterprise setups there is always a web server in front of the
application server (tomcat, glassfish, etc.).
there are many advantages for having a web server in front of the app
server:
- you can scale better (with plugins like mod_jk or alike you can
distribute the load over N application servers. Of course, the plugin must
support session stickyness, so that request with the same session cookie
gets forwarded to the same app server.
- you can serve static content from the web server. this way you have much
less "noise" on the app server. Of course: web server must have access to
the content, so the deployment model might look different, if web and
appserver are on physically different machines
- you can easily switch to a static maintenance page: you configure the web
server to show a certain page. during this time, you can modify the app
servers in the back end. if done, you can go back to the normal
configuration where requests are routed to the app servers
- for highly secure applications, it's probably a must to introduce a web
server, as you can much better protect your app server from unwanted
requests (see for instance "perimeter authentication")

downside of it is:
- you have more infrastructure to maintain
- more complex monitoring setup
- more expensive
- more complex support demand (if something goes wrong, you have to analyze
more)

cheers
balz



On Wed, Jan 18, 2012 at 10:10 AM, simon <simon at 333.ch> wrote:

> hi all
>
> just wondering why yanel resp. tomcat is mostly deployed behind an apache?
> what's the reason and does someone has experience in using the tomcat
> without an apache web server in front?
>
> cheers
> simon
> --
> Yanel-development mailing list Yanel-development at wyona.com
> http://lists.wyona.org/cgi-**bin/mailman/listinfo/yanel-**development<http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120118/a8210139/attachment.html>

From simon at 333.ch  Wed Jan 18 10:29:59 2012
From: simon at 333.ch (simon)
Date: Wed, 18 Jan 2012 10:29:59 +0100
Subject: [Yanel-dev] deployment
In-Reply-To: <CAOXzDSGxJs+6L-8+th45HKn5x61vQhiP+MeJpCTBs58x6Gtu=A@mail.gmail.com>
References: <4F168C7B.5030603@333.ch>
	<CAOXzDSGxJs+6L-8+th45HKn5x61vQhiP+MeJpCTBs58x6Gtu=A@mail.gmail.com>
Message-ID: <4F169117.1070508@333.ch>

thanks very much for your fast and detailed answer.

cheers
simon



Am 18.01.2012 10:19, schrieb basZero:
> Hi Simon,
>
> in larger enterprise setups there is always a web server in front of 
> the application server (tomcat, glassfish, etc.).
> there are many advantages for having a web server in front of the app 
> server:
> - you can scale better (with plugins like mod_jk or alike you can 
> distribute the load over N application servers. Of course, the plugin 
> must support session stickyness, so that request with the same session 
> cookie gets forwarded to the same app server.
> - you can serve static content from the web server. this way you have 
> much less "noise" on the app server. Of course: web server must have 
> access to the content, so the deployment model might look different, 
> if web and appserver are on physically different machines
> - you can easily switch to a static maintenance page: you configure 
> the web server to show a certain page. during this time, you can 
> modify the app servers in the back end. if done, you can go back to 
> the normal configuration where requests are routed to the app servers
> - for highly secure applications, it's probably a must to introduce a 
> web server, as you can much better protect your app server from 
> unwanted requests (see for instance "perimeter authentication")
>
> downside of it is:
> - you have more infrastructure to maintain
> - more complex monitoring setup
> - more expensive
> - more complex support demand (if something goes wrong, you have to 
> analyze more)
>
> cheers
> balz
>
>
>
> On Wed, Jan 18, 2012 at 10:10 AM, simon <simon at 333.ch 
> <mailto:simon at 333.ch>> wrote:
>
>     hi all
>
>     just wondering why yanel resp. tomcat is mostly deployed behind an
>     apache?
>     what's the reason and does someone has experience in using the
>     tomcat without an apache web server in front?
>
>     cheers
>     simon
>     -- 
>     Yanel-development mailing list Yanel-development at wyona.com
>     <mailto:Yanel-development at wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120118/5719f717/attachment.html>

From michael.wechner at wyona.com  Wed Jan 18 10:32:06 2012
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed, 18 Jan 2012 10:32:06 +0100
Subject: [Yanel-dev] deployment
In-Reply-To: <CAOXzDSGxJs+6L-8+th45HKn5x61vQhiP+MeJpCTBs58x6Gtu=A@mail.gmail.com>
References: <4F168C7B.5030603@333.ch>
	<CAOXzDSGxJs+6L-8+th45HKn5x61vQhiP+MeJpCTBs58x6Gtu=A@mail.gmail.com>
Message-ID: <4F169196.4040204@wyona.com>

Hi Simon

I can confirm what Balz is saying, whereas I would emphasize that it is 
mostly about flexibility.

You can find some examples under "Deployment" of the documentation:

http://www.yanel.org/en/documentation/index.html

whereas I just realize that we need to replace the svn links by git.

HTH

Michael

Am 18.01.12 10:19, schrieb basZero:
> Hi Simon,
>
> in larger enterprise setups there is always a web server in front of 
> the application server (tomcat, glassfish, etc.).
> there are many advantages for having a web server in front of the app 
> server:
> - you can scale better (with plugins like mod_jk or alike you can 
> distribute the load over N application servers. Of course, the plugin 
> must support session stickyness, so that request with the same session 
> cookie gets forwarded to the same app server.
> - you can serve static content from the web server. this way you have 
> much less "noise" on the app server. Of course: web server must have 
> access to the content, so the deployment model might look different, 
> if web and appserver are on physically different machines
> - you can easily switch to a static maintenance page: you configure 
> the web server to show a certain page. during this time, you can 
> modify the app servers in the back end. if done, you can go back to 
> the normal configuration where requests are routed to the app servers
> - for highly secure applications, it's probably a must to introduce a 
> web server, as you can much better protect your app server from 
> unwanted requests (see for instance "perimeter authentication")
>
> downside of it is:
> - you have more infrastructure to maintain
> - more complex monitoring setup
> - more expensive
> - more complex support demand (if something goes wrong, you have to 
> analyze more)
>
> cheers
> balz
>
>
>
> On Wed, Jan 18, 2012 at 10:10 AM, simon <simon at 333.ch 
> <mailto:simon at 333.ch>> wrote:
>
>     hi all
>
>     just wondering why yanel resp. tomcat is mostly deployed behind an
>     apache?
>     what's the reason and does someone has experience in using the
>     tomcat without an apache web server in front?
>
>     cheers
>     simon
>     -- 
>     Yanel-development mailing list Yanel-development at wyona.com
>     <mailto:Yanel-development at wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120118/a3bc62e2/attachment.html>

From Wayne.Bunting at gurit.com  Wed Jan 18 11:00:44 2012
From: Wayne.Bunting at gurit.com (Wayne.Bunting at gurit.com)
Date: Wed, 18 Jan 2012 10:00:44 +0000
Subject: [Yanel-dev] AUTO: Wayne Bunting is out of the office. (returning
	19/01/2012)
Message-ID: <OF4E404146.C267EB82-ON80257989.0036FFDC-80257989.0036FFDC@gurit.com>


I am out of the office until 19/01/2012.

I will respond to your message when I return.


Note: This is an automated response to your message  "[Yanel-dev]
deployment" sent on 18/01/2012 09:10:19.

This is the only notification you will receive while this person is away.

*********************************************************************
All sales of goods are subject to the terms and conditions of sale (the 
Conditions) of Gurit (UK) Limited (the Company) which are available on request from the Company or may be viewed on the Gurit Website http://www.gurit.com

Any advice given by the Company in connection with the sale of goods or the provision of technical, engineering or other services is given in good faith but the company only warrants that advice in writing and in relation to specific services or a specific project is given with reasonable skill and care. All advice is otherwise given subject to the Conditions.

The contents of this message and any attachments are confidential and are intended solely for the attention and use of the addressee only. Information contained in this message may be subject to legal, professional or other privilege or may otherwise be protected by other legal rules. This message should not be copied or forwarded to any other person without the express permission of the sender. If you are not the intended recipient you are not authorised to disclose, copy, distribute or retain this message or any part of it.

Gurit (UK) Limited registered offices are:
St. Cross Business Park, Newport, Isle of Wight, PO30 5WU, UK
The Company is registered in England and Wales. Reg No. 1368806 

*********************************************************************

From simon at 333.ch  Wed Jan 18 17:46:25 2012
From: simon at 333.ch (simon)
Date: Wed, 18 Jan 2012 17:46:25 +0100
Subject: [Yanel-dev] deployment
In-Reply-To: <4F169196.4040204@wyona.com>
References: <4F168C7B.5030603@333.ch>
	<CAOXzDSGxJs+6L-8+th45HKn5x61vQhiP+MeJpCTBs58x6Gtu=A@mail.gmail.com>
	<4F169196.4040204@wyona.com>
Message-ID: <4F16F761.5020704@333.ch>

Am 18.01.2012 10:32, schrieb Michael Wechner:
> Hi Simon
>
> I can confirm what Balz is saying, whereas I would emphasize that it 
> is mostly about flexibility.
>
> You can find some examples under "Deployment" of the documentation:
>
> http://www.yanel.org/en/documentation/index.html
i was just reading 
http://www.yanel.org/en/documentation/how-to-add-ssl-to-apache-httpd.html and 
it seems to be a bit outdated , at least if you use an recent linux 
distro where apache above 2.2.13.  is bundled.
then  just enter

apt-get install apache2

sudo a2enmod proxy
sudo a2enmod proxy_http

HTH
simon

>
> whereas I just realize that we need to replace the svn links by git.
>
> HTH
>
> Michael
>
> Am 18.01.12 10:19, schrieb basZero:
>> Hi Simon,
>>
>> in larger enterprise setups there is always a web server in front of 
>> the application server (tomcat, glassfish, etc.).
>> there are many advantages for having a web server in front of the app 
>> server:
>> - you can scale better (with plugins like mod_jk or alike you can 
>> distribute the load over N application servers. Of course, the plugin 
>> must support session stickyness, so that request with the same 
>> session cookie gets forwarded to the same app server.
>> - you can serve static content from the web server. this way you have 
>> much less "noise" on the app server. Of course: web server must have 
>> access to the content, so the deployment model might look different, 
>> if web and appserver are on physically different machines
>> - you can easily switch to a static maintenance page: you configure 
>> the web server to show a certain page. during this time, you can 
>> modify the app servers in the back end. if done, you can go back to 
>> the normal configuration where requests are routed to the app servers
>> - for highly secure applications, it's probably a must to introduce a 
>> web server, as you can much better protect your app server from 
>> unwanted requests (see for instance "perimeter authentication")
>>
>> downside of it is:
>> - you have more infrastructure to maintain
>> - more complex monitoring setup
>> - more expensive
>> - more complex support demand (if something goes wrong, you have to 
>> analyze more)
>>
>> cheers
>> balz
>>
>>
>>
>> On Wed, Jan 18, 2012 at 10:10 AM, simon <simon at 333.ch 
>> <mailto:simon at 333.ch>> wrote:
>>
>>     hi all
>>
>>     just wondering why yanel resp. tomcat is mostly deployed behind
>>     an apache?
>>     what's the reason and does someone has experience in using the
>>     tomcat without an apache web server in front?
>>
>>     cheers
>>     simon
>>     -- 
>>     Yanel-development mailing list Yanel-development at wyona.com
>>     <mailto:Yanel-development at wyona.com>
>>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120118/c33593ce/attachment.html>

From michael.wechner at wyona.com  Wed Jan 18 20:09:56 2012
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed, 18 Jan 2012 20:09:56 +0100
Subject: [Yanel-dev] deployment
In-Reply-To: <4F16F761.5020704@333.ch>
References: <4F168C7B.5030603@333.ch>
	<CAOXzDSGxJs+6L-8+th45HKn5x61vQhiP+MeJpCTBs58x6Gtu=A@mail.gmail.com>
	<4F169196.4040204@wyona.com> <4F16F761.5020704@333.ch>
Message-ID: <4F171904.50306@wyona.com>

Am 18.01.12 17:46, schrieb simon:
> Am 18.01.2012 10:32, schrieb Michael Wechner:
>> Hi Simon
>>
>> I can confirm what Balz is saying, whereas I would emphasize that it 
>> is mostly about flexibility.
>>
>> You can find some examples under "Deployment" of the documentation:
>>
>> http://www.yanel.org/en/documentation/index.html
> i was just reading 
> http://www.yanel.org/en/documentation/how-to-add-ssl-to-apache-httpd.html 
> and it seems to be a bit outdated , at least if you use an recent 
> linux distro where apache above 2.2.13.  is bundled.

I would argue it's rather build from source versus using aptitude
> then  just enter
>
> apt-get install apache2
>
> sudo a2enmod proxy
> sudo a2enmod proxy_http

Thanks very much for these notes. I will add them to the documentation 
as alternative.

Thanks

Michael

>
> HTH
> simon
>
>>
>> whereas I just realize that we need to replace the svn links by git.
>>
>> HTH
>>
>> Michael
>>
>> Am 18.01.12 10:19, schrieb basZero:
>>> Hi Simon,
>>>
>>> in larger enterprise setups there is always a web server in front of 
>>> the application server (tomcat, glassfish, etc.).
>>> there are many advantages for having a web server in front of the 
>>> app server:
>>> - you can scale better (with plugins like mod_jk or alike you can 
>>> distribute the load over N application servers. Of course, the 
>>> plugin must support session stickyness, so that request with the 
>>> same session cookie gets forwarded to the same app server.
>>> - you can serve static content from the web server. this way you 
>>> have much less "noise" on the app server. Of course: web server must 
>>> have access to the content, so the deployment model might look 
>>> different, if web and appserver are on physically different machines
>>> - you can easily switch to a static maintenance page: you configure 
>>> the web server to show a certain page. during this time, you can 
>>> modify the app servers in the back end. if done, you can go back to 
>>> the normal configuration where requests are routed to the app servers
>>> - for highly secure applications, it's probably a must to introduce 
>>> a web server, as you can much better protect your app server from 
>>> unwanted requests (see for instance "perimeter authentication")
>>>
>>> downside of it is:
>>> - you have more infrastructure to maintain
>>> - more complex monitoring setup
>>> - more expensive
>>> - more complex support demand (if something goes wrong, you have to 
>>> analyze more)
>>>
>>> cheers
>>> balz
>>>
>>>
>>>
>>> On Wed, Jan 18, 2012 at 10:10 AM, simon <simon at 333.ch 
>>> <mailto:simon at 333.ch>> wrote:
>>>
>>>     hi all
>>>
>>>     just wondering why yanel resp. tomcat is mostly deployed behind
>>>     an apache?
>>>     what's the reason and does someone has experience in using the
>>>     tomcat without an apache web server in front?
>>>
>>>     cheers
>>>     simon
>>>     -- 
>>>     Yanel-development mailing list Yanel-development at wyona.com
>>>     <mailto:Yanel-development at wyona.com>
>>>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120118/aa5f5c88/attachment.html>

From michael.wechner at wyona.com  Tue Jan 24 10:12:22 2012
From: michael.wechner at wyona.com (Michael Wechner)
Date: Tue, 24 Jan 2012 10:12:22 +0100
Subject: [Yanel-dev] Minor bug re user aliases
In-Reply-To: <4E0ED00B.1010101@wyona.com>
References: <4E0ED00B.1010101@wyona.com>
Message-ID: <4F1E75F6.7090405@wyona.com>

Am 02.07.11 10:00, schrieb Michael Wechner:
> Hi
>
> I have noticed a minor re user aliases.
>
> If the collection node "aliases" does not exist yet, then no alias can 
> be created.
> At the moment one has to add such a node manually, e.g.
>
> src/realms/from-scratch-realm-template/ac-identities/data/aliases
>
> but I have improved the yarep security implementation that it will be 
> added automagically
> if it does not exist yet:
>
> Sending        
> src/impl/java/org/wyona/security/impl/yarep/YarepUserManager.java
> Transmitting file data .
> Committed revision 59126.
>
> Yanel itself is not using this revision yet, but I will update it 
> shortly.

this should be working now.

Thanks

Michael
>
> Thanks
>
> Michael


From bugzilla at wyona.com  Tue Jan 24 11:09:29 2012
From: bugzilla at wyona.com (bugzilla at wyona.com)
Date: Tue, 24 Jan 2012 10:09:29 -0000
Subject: [Yanel-dev] [Bug 8228] Add "alias" to user interface for creating a
	new user
Message-ID: <mailman.16.1327399771.866.yanel-development@wyona.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=8228


michael.wechner at wyona.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

From michael.wechner at wyona.com  Tue Jan 24 11:08:29 2012
From: michael.wechner at wyona.com (Michael Wechner)
Date: Tue, 24 Jan 2012 11:08:29 +0100
Subject: [Yanel-dev] Checking if an alias already exists
In-Reply-To: <4D95978D.4060003@wyona.com>
References: <4D94B999.7060908@wyona.com> <4D95978D.4060003@wyona.com>
Message-ID: <4F1E831D.2040601@wyona.com>

Hi

I have implemented now the functionality of "existsAlias(String)", 
whereas it is being used for example inside

src/resources/registration/src/java/org/wyona/yanel/resources/registration/UserRegistrationResource.java

Thanks

Michael

Am 01.04.11 11:14, schrieb Michael Wechner:
> Hi Ioannis
>
> On 3/31/11 6:27 PM, Ioannis Iordanidis wrote:
>> Hi Michael,
>>
>> We don't seem to have a method to check if a String is already in use 
>> as an alias. It seems that one can create identical aliases across 
>> different user accounts.
>
> you're right, whereas the Yarep implementation does do a check
>
> src/impl/java/org/wyona/security/impl/yarep/YarepUserManager.java#createAlias 
>
>
> or rather see
>
> http://svn.wyona.com/repos/public/security/trunk/src/impl/java/org/wyona/security/impl/yarep/YarepUserManager.java 
>
>
> and will throw an exception if an alias already exists.
>
> But I agree it would be nice to have a method to catch this more 
> gracefully and also
> not to depend on an implementation actually checking on this.
>
> We would have to add it to the interface, e.g.
>
> Index: src/core/java/org/wyona/security/core/api/UserManager.java
> ===================================================================
> --- src/core/java/org/wyona/security/core/api/UserManager.java    
> (revision 56962)
> +++ src/core/java/org/wyona/security/core/api/UserManager.java    
> (working copy)
> @@ -114,6 +114,15 @@
>      boolean existsUser(String id) throws AccessManagementException;
>
>      /**
> +     * Indicates whether an alias with the given id exists.
> +     *
> +     * @param id ID of alias
> +     * @return true if an alias with the given id exists.
> +     * @throws AccessManagementException
> +     */
> +    boolean existsAlias(String id) throws AccessManagementException;
> +
> +    /**
>       * Get the true ID of a user
>       *
>       * @param id Either pseudonym or true ID
>
> but this will break the backwards compatibility.
>
> Let me think about it ....
>> maybe need to open a new bug for this in bugzilla?
>
> yes, please a bug :-)
>
> Thanks
>
> Michael
>>
>> Cheers
>> Giannis
>


From michael.wechner at wyona.com  Tue Jan 24 14:43:53 2012
From: michael.wechner at wyona.com (Michael Wechner)
Date: Tue, 24 Jan 2012 14:43:53 +0100
Subject: [Yanel-dev] Resource configuration parameters: Differentiating
 between Development, Testing, Staging and Production
In-Reply-To: <CAOXzDSHfxBPDGUF_6tn7ssrAW=ZExNH1SzZz6qK5otnz5i0MAQ@mail.gmail.com>
References: <4E949D47.7060208@wyona.com>
	<CAOXzDSHfxBPDGUF_6tn7ssrAW=ZExNH1SzZz6qK5otnz5i0MAQ@mail.gmail.com>
Message-ID: <4F1EB599.9000402@wyona.com>

Hi Balz

Am 13.10.11 17:31, schrieb basZero:
> sounds great, but I would not reinvent the wheel.
> checkout Maven Profiles, they do exactly this.
>
> if I remember correctly, Maven Profiles existed as separate files in 
> version 2.x, from 3.x they have been integrated into Maven's 
> settings.xsml:
>
> http://maven.apache.org/settings.html#Profiles
>
> http://maven.apache.org/guides/introduction/introduction-to-profiles.html

Thanks very much for these links, but it's not really about the build 
process, but rather about resource configurations of realms, which have 
nothing to do with the build process.

I will do an experimental implementation in a separate git branch and 
try to make it available for testing shortly.

Thanks

Michael


>
> Cheers
> Balz
>
> On Tue, Oct 11, 2011 at 9:47 PM, Michael Wechner 
> <michael.wechner at wyona.com <mailto:michael.wechner at wyona.com>> wrote:
>
>     Hi
>
>     Based on some other work it occured to me that it would be nice if
>     one could easily differentiate configuration parameters for
>     various scenarios/environments, e.g. Development, Testing, Staging
>     and Production.
>
>     The Yanel configuration itself already provides "local"
>     configuration files, but in the case of resource configurations
>     this is not the case, e.g.
>
>     src/realms/yanel-website/res-configs-repo/data/en/contact.html.yanel-rc
>
>     and in particular a parameter like
>
>     <yanel:property name="to" value="contact at wyona.com
>     <mailto:contact at wyona.com>"/>
>
>     needs to be changed for development or testing. At the moment one
>     has to keep editing these files
>     with the risk to use a value actually intended for another
>     scenario/environment and hence creating errors.
>
>     I think we could solve this problem in a very elegant way by
>     introducing an attribute, e.g.
>
>     <yanel:property name="to" value="contact at wyona.com
>     <mailto:contact at wyona.com>" env="production"/>
>     <yanel:property name="to" value="michael.wechner at wyona.com
>     <mailto:michael.wechner at wyona.com>" env="development"/>
>
>     whereas inside
>
>     WEB-INF/classes/yanel.xml
>
>     the scenario/environment could be set globally, e.g. production or
>     development or whatever and based on
>     that the right value selected.
>
>     WDYT?
>
>     Thanks
>
>     Michael
>
>
>     -- 
>     Yanel-development mailing list Yanel-development at wyona.com
>     <mailto:Yanel-development at wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120124/a90b06d2/attachment.html>

From michael.wechner at wyona.com  Tue Jan 24 20:32:01 2012
From: michael.wechner at wyona.com (Michael Wechner)
Date: Tue, 24 Jan 2012 20:32:01 +0100
Subject: [Yanel-dev] Resource configuration parameters: Differentiating
 between Development, Testing, Staging and Production
In-Reply-To: <4F1EB599.9000402@wyona.com>
References: <4E949D47.7060208@wyona.com>
	<CAOXzDSHfxBPDGUF_6tn7ssrAW=ZExNH1SzZz6qK5otnz5i0MAQ@mail.gmail.com>
	<4F1EB599.9000402@wyona.com>
Message-ID: <4F1F0731.4040004@wyona.com>

Am 24.01.12 14:43, schrieb Michael Wechner:
> Hi Balz
>
> Am 13.10.11 17:31, schrieb basZero:
>> sounds great, but I would not reinvent the wheel.
>> checkout Maven Profiles, they do exactly this.
>>
>> if I remember correctly, Maven Profiles existed as separate files in 
>> version 2.x, from 3.x they have been integrated into Maven's 
>> settings.xsml:
>>
>> http://maven.apache.org/settings.html#Profiles
>>
>> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
>
> Thanks very much for these links, but it's not really about the build 
> process, but rather about resource configurations of realms, which 
> have nothing to do with the build process.
>
> I will do an experimental implementation in a separate git branch and 
> try to make it available for testing shortly.

I have started this implementation inside the branch

remotes/origin/target-environment

whereas one wants to have a look at

conf/yanel.xml

where one can set a target environment.

Thanks

Michael
>
> Thanks
>
> Michael
>
>
>>
>> Cheers
>> Balz
>>
>> On Tue, Oct 11, 2011 at 9:47 PM, Michael Wechner 
>> <michael.wechner at wyona.com <mailto:michael.wechner at wyona.com>> wrote:
>>
>>     Hi
>>
>>     Based on some other work it occured to me that it would be nice
>>     if one could easily differentiate configuration parameters for
>>     various scenarios/environments, e.g. Development, Testing,
>>     Staging and Production.
>>
>>     The Yanel configuration itself already provides "local"
>>     configuration files, but in the case of resource configurations
>>     this is not the case, e.g.
>>
>>     src/realms/yanel-website/res-configs-repo/data/en/contact.html.yanel-rc
>>
>>     and in particular a parameter like
>>
>>     <yanel:property name="to" value="contact at wyona.com
>>     <mailto:contact at wyona.com>"/>
>>
>>     needs to be changed for development or testing. At the moment one
>>     has to keep editing these files
>>     with the risk to use a value actually intended for another
>>     scenario/environment and hence creating errors.
>>
>>     I think we could solve this problem in a very elegant way by
>>     introducing an attribute, e.g.
>>
>>     <yanel:property name="to" value="contact at wyona.com
>>     <mailto:contact at wyona.com>" env="production"/>
>>     <yanel:property name="to" value="michael.wechner at wyona.com
>>     <mailto:michael.wechner at wyona.com>" env="development"/>
>>
>>     whereas inside
>>
>>     WEB-INF/classes/yanel.xml
>>
>>     the scenario/environment could be set globally, e.g. production
>>     or development or whatever and based on
>>     that the right value selected.
>>
>>     WDYT?
>>
>>     Thanks
>>
>>     Michael
>>
>>
>>     -- 
>>     Yanel-development mailing list Yanel-development at wyona.com
>>     <mailto:Yanel-development at wyona.com>
>>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120124/f5cc0b91/attachment.html>

From michael.wechner at wyona.com  Thu Jan 26 13:10:05 2012
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu, 26 Jan 2012 13:10:05 +0100
Subject: [Yanel-dev] [Announcement] Target environment implementation
 finished [WAS Re: Resource configuration parameters: Differentiating
 between Development, Testing, Staging and Production
In-Reply-To: <4F1F0731.4040004@wyona.com>
References: <4E949D47.7060208@wyona.com>
	<CAOXzDSHfxBPDGUF_6tn7ssrAW=ZExNH1SzZz6qK5otnz5i0MAQ@mail.gmail.com>
	<4F1EB599.9000402@wyona.com> <4F1F0731.4040004@wyona.com>
Message-ID: <4F21429D.1080006@wyona.com>

Hi

I am happy to announce that the functionlity of "target environments" is 
now implemented. Please see
the documentation at

http://www.yanel.org/en/documentation/target-environment.html

Please let me know if it is not clear enough or something does not work 
as expected.

Thanks

Michael

Am 24.01.12 20:32, schrieb Michael Wechner:
> Am 24.01.12 14:43, schrieb Michael Wechner:
>> Hi Balz
>>
>> Am 13.10.11 17:31, schrieb basZero:
>>> sounds great, but I would not reinvent the wheel.
>>> checkout Maven Profiles, they do exactly this.
>>>
>>> if I remember correctly, Maven Profiles existed as separate files in 
>>> version 2.x, from 3.x they have been integrated into Maven's 
>>> settings.xsml:
>>>
>>> http://maven.apache.org/settings.html#Profiles
>>>
>>> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
>>
>> Thanks very much for these links, but it's not really about the build 
>> process, but rather about resource configurations of realms, which 
>> have nothing to do with the build process.
>>
>> I will do an experimental implementation in a separate git branch and 
>> try to make it available for testing shortly.
>
> I have started this implementation inside the branch
>
> remotes/origin/target-environment
>
> whereas one wants to have a look at
>
> conf/yanel.xml
>
> where one can set a target environment.
>
> Thanks
>
> Michael
>>
>> Thanks
>>
>> Michael
>>
>>
>>>
>>> Cheers
>>> Balz
>>>
>>> On Tue, Oct 11, 2011 at 9:47 PM, Michael Wechner 
>>> <michael.wechner at wyona.com <mailto:michael.wechner at wyona.com>> wrote:
>>>
>>>     Hi
>>>
>>>     Based on some other work it occured to me that it would be nice
>>>     if one could easily differentiate configuration parameters for
>>>     various scenarios/environments, e.g. Development, Testing,
>>>     Staging and Production.
>>>
>>>     The Yanel configuration itself already provides "local"
>>>     configuration files, but in the case of resource configurations
>>>     this is not the case, e.g.
>>>
>>>     src/realms/yanel-website/res-configs-repo/data/en/contact.html.yanel-rc
>>>
>>>     and in particular a parameter like
>>>
>>>     <yanel:property name="to" value="contact at wyona.com
>>>     <mailto:contact at wyona.com>"/>
>>>
>>>     needs to be changed for development or testing. At the moment
>>>     one has to keep editing these files
>>>     with the risk to use a value actually intended for another
>>>     scenario/environment and hence creating errors.
>>>
>>>     I think we could solve this problem in a very elegant way by
>>>     introducing an attribute, e.g.
>>>
>>>     <yanel:property name="to" value="contact at wyona.com
>>>     <mailto:contact at wyona.com>" env="production"/>
>>>     <yanel:property name="to" value="michael.wechner at wyona.com
>>>     <mailto:michael.wechner at wyona.com>" env="development"/>
>>>
>>>     whereas inside
>>>
>>>     WEB-INF/classes/yanel.xml
>>>
>>>     the scenario/environment could be set globally, e.g. production
>>>     or development or whatever and based on
>>>     that the right value selected.
>>>
>>>     WDYT?
>>>
>>>     Thanks
>>>
>>>     Michael
>>>
>>>
>>>     -- 
>>>     Yanel-development mailing list Yanel-development at wyona.com
>>>     <mailto:Yanel-development at wyona.com>
>>>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120126/fbda4343/attachment.html>

From baszero at gmail.com  Thu Jan 26 13:24:55 2012
From: baszero at gmail.com (basZero)
Date: Thu, 26 Jan 2012 13:24:55 +0100
Subject: [Yanel-dev] [Announcement] Target environment implementation
 finished [WAS Re: Resource configuration parameters: Differentiating
 between Development, Testing, Staging and Production
In-Reply-To: <4F21429D.1080006@wyona.com>
References: <4E949D47.7060208@wyona.com>
	<CAOXzDSHfxBPDGUF_6tn7ssrAW=ZExNH1SzZz6qK5otnz5i0MAQ@mail.gmail.com>
	<4F1EB599.9000402@wyona.com> <4F1F0731.4040004@wyona.com>
	<4F21429D.1080006@wyona.com>
Message-ID: <CAOXzDSH_PzBONGYk0zau+0NGGE_fK9r7ZvzG3=mdR4ErCKOC8A@mail.gmail.com>

Hi Michael,
sounds great.

Regarding documentation: it would save some time if you would link source
code pointers with github.
e.g. you could make a hyperlink to
https://github.com/wyona/yanel/blob/master/src/realms/yanel-website/res-configs-repo/data/en/contact.html.yanel-rc

Cheers
Balz

On Thu, Jan 26, 2012 at 1:10 PM, Michael Wechner
<michael.wechner at wyona.com>wrote:

>  Hi
>
> I am happy to announce that the functionlity of "target environments" is
> now implemented. Please see
> the documentation at
>
> http://www.yanel.org/en/documentation/target-environment.html
>
> Please let me know if it is not clear enough or something does not work as
> expected.
>
> Thanks
>
> Michael
>
> Am 24.01.12 20:32, schrieb Michael Wechner:
>
> Am 24.01.12 14:43, schrieb Michael Wechner:
>
> Hi Balz
>
> Am 13.10.11 17:31, schrieb basZero:
>
> sounds great, but I would not reinvent the wheel.
> checkout Maven Profiles, they do exactly this.
>
>  if I remember correctly, Maven Profiles existed as separate files in
> version 2.x, from 3.x they have been integrated into Maven's settings.xsml:
>
>  http://maven.apache.org/settings.html#Profiles
>
>  http://maven.apache.org/guides/introduction/introduction-to-profiles.html
>
>
> Thanks very much for these links, but it's not really about the build
> process, but rather about resource configurations of realms, which have
> nothing to do with the build process.
>
> I will do an experimental implementation in a separate git branch and try
> to make it available for testing shortly.
>
>
> I have started this implementation inside the branch
>
> remotes/origin/target-environment
>
> whereas one wants to have a look at
>
> conf/yanel.xml
>
> where one can set a target environment.
>
> Thanks
>
> Michael
>
>
> Thanks
>
> Michael
>
>
>
>  Cheers
> Balz
>
>  On Tue, Oct 11, 2011 at 9:47 PM, Michael Wechner <
> michael.wechner at wyona.com> wrote:
>
>> Hi
>>
>> Based on some other work it occured to me that it would be nice if one
>> could easily differentiate configuration parameters for various
>> scenarios/environments, e.g. Development, Testing, Staging and Production.
>>
>> The Yanel configuration itself already provides "local" configuration
>> files, but in the case of resource configurations this is not the case, e.g.
>>
>> src/realms/yanel-website/res-configs-repo/data/en/contact.html.yanel-rc
>>
>> and in particular a parameter like
>>
>> <yanel:property name="to" value="contact at wyona.com"/>
>>
>> needs to be changed for development or testing. At the moment one has to
>> keep editing these files
>> with the risk to use a value actually intended for another
>> scenario/environment and hence creating errors.
>>
>> I think we could solve this problem in a very elegant way by introducing
>> an attribute, e.g.
>>
>> <yanel:property name="to" value="contact at wyona.com" env="production"/>
>> <yanel:property name="to" value="michael.wechner at wyona.com"
>> env="development"/>
>>
>> whereas inside
>>
>> WEB-INF/classes/yanel.xml
>>
>> the scenario/environment could be set globally, e.g. production or
>> development or whatever and based on
>> that the right value selected.
>>
>> WDYT?
>>
>> Thanks
>>
>> Michael
>>
>>
>> --
>> Yanel-development mailing list Yanel-development at wyona.com
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>
>
>
>
>
>
>
>
>
>
>
> --
> Yanel-development mailing list Yanel-development at wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120126/38d0301e/attachment.html>

From michael.wechner at wyona.com  Thu Jan 26 13:43:58 2012
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu, 26 Jan 2012 13:43:58 +0100
Subject: [Yanel-dev] [Announcement] Target environment implementation
 finished [WAS Re: Resource configuration parameters: Differentiating
 between Development, Testing, Staging and Production
In-Reply-To: <CAOXzDSH_PzBONGYk0zau+0NGGE_fK9r7ZvzG3=mdR4ErCKOC8A@mail.gmail.com>
References: <4E949D47.7060208@wyona.com>
	<CAOXzDSHfxBPDGUF_6tn7ssrAW=ZExNH1SzZz6qK5otnz5i0MAQ@mail.gmail.com>
	<4F1EB599.9000402@wyona.com> <4F1F0731.4040004@wyona.com>
	<4F21429D.1080006@wyona.com>
	<CAOXzDSH_PzBONGYk0zau+0NGGE_fK9r7ZvzG3=mdR4ErCKOC8A@mail.gmail.com>
Message-ID: <4F214A8E.7010701@wyona.com>

Am 26.01.12 13:24, schrieb basZero:
> Hi Michael,
> sounds great.
>
> Regarding documentation: it would save some time if you would link 
> source code pointers with github.
> e.g. you could make a hyperlink to
> https://github.com/wyona/yanel/blob/master/src/realms/yanel-website/res-configs-repo/data/en/contact.html.yanel-rc

done:

http://www.yanel.org/en/documentation/target-environment.html

Thanks very much for your feedback

Michael
>
>

From baszero at gmail.com  Thu Jan 26 13:49:37 2012
From: baszero at gmail.com (basZero)
Date: Thu, 26 Jan 2012 13:49:37 +0100
Subject: [Yanel-dev] [Announcement] Target environment implementation
 finished [WAS Re: Resource configuration parameters: Differentiating
 between Development, Testing, Staging and Production
In-Reply-To: <4F214A8E.7010701@wyona.com>
References: <4E949D47.7060208@wyona.com>
	<CAOXzDSHfxBPDGUF_6tn7ssrAW=ZExNH1SzZz6qK5otnz5i0MAQ@mail.gmail.com>
	<4F1EB599.9000402@wyona.com> <4F1F0731.4040004@wyona.com>
	<4F21429D.1080006@wyona.com>
	<CAOXzDSH_PzBONGYk0zau+0NGGE_fK9r7ZvzG3=mdR4ErCKOC8A@mail.gmail.com>
	<4F214A8E.7010701@wyona.com>
Message-ID: <CAOXzDSF25U7VY_C9CbigP9Nh-YNsputkvkytq19tyEyOj4xOjg@mail.gmail.com>

Cool... but I just didn't see the links, because they are also "grey" like
the normal text, after you have clicked once on a link.
Maybe you change your global.css into

a:visited {

   1. text-decoration: none;
   2. color: #06C;

}

Cheers
Balz
On Thu, Jan 26, 2012 at 1:43 PM, Michael Wechner
<michael.wechner at wyona.com>wrote:

> Am 26.01.12 13:24, schrieb basZero:
>
>  Hi Michael,
>> sounds great.
>>
>> Regarding documentation: it would save some time if you would link source
>> code pointers with github.
>> e.g. you could make a hyperlink to
>> https://github.com/wyona/**yanel/blob/master/src/realms/**
>> yanel-website/res-configs-**repo/data/en/contact.html.**yanel-rc<https://github.com/wyona/yanel/blob/master/src/realms/yanel-website/res-configs-repo/data/en/contact.html.yanel-rc>
>>
>
> done:
>
> http://www.yanel.org/en/**documentation/target-**environment.html<http://www.yanel.org/en/documentation/target-environment.html>
>
> Thanks very much for your feedback
>
>
> Michael
>
>>
>>
>>  --
> Yanel-development mailing list Yanel-development at wyona.com
> http://lists.wyona.org/cgi-**bin/mailman/listinfo/yanel-**development<http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120126/b4c18b71/attachment-0001.html>

From michael.wechner at wyona.com  Tue Jan 31 09:02:08 2012
From: michael.wechner at wyona.com (Michael Wechner)
Date: Tue, 31 Jan 2012 09:02:08 +0100
Subject: [Yanel-dev] [Announcement] Target environment implementation
 finished [WAS Re: Resource configuration parameters: Differentiating
 between Development, Testing, Staging and Production
In-Reply-To: <CAOXzDSF25U7VY_C9CbigP9Nh-YNsputkvkytq19tyEyOj4xOjg@mail.gmail.com>
References: <4E949D47.7060208@wyona.com>
	<CAOXzDSHfxBPDGUF_6tn7ssrAW=ZExNH1SzZz6qK5otnz5i0MAQ@mail.gmail.com>
	<4F1EB599.9000402@wyona.com> <4F1F0731.4040004@wyona.com>
	<4F21429D.1080006@wyona.com>
	<CAOXzDSH_PzBONGYk0zau+0NGGE_fK9r7ZvzG3=mdR4ErCKOC8A@mail.gmail.com>
	<4F214A8E.7010701@wyona.com>
	<CAOXzDSF25U7VY_C9CbigP9Nh-YNsputkvkytq19tyEyOj4xOjg@mail.gmail.com>
Message-ID: <4F27A000.4080409@wyona.com>

Am 26.01.12 13:49, schrieb basZero:
> Cool... but I just didn't see the links, because they are also "grey" 
> like the normal text, after you have clicked once on a link.
> Maybe you change your global.css into
>
> a:visited {
>
>  1. text-decoration: none;
>  2. color: #06C;
>
> }
>

thanks, done now, will apply it on the productive environment shortly.

Thanks

Michael
> Cheers
> Balz
> On Thu, Jan 26, 2012 at 1:43 PM, Michael Wechner 
> <michael.wechner at wyona.com <mailto:michael.wechner at wyona.com>> wrote:
>
>     Am 26.01.12 13:24, schrieb basZero:
>
>         Hi Michael,
>         sounds great.
>
>         Regarding documentation: it would save some time if you would
>         link source code pointers with github.
>         e.g. you could make a hyperlink to
>         https://github.com/wyona/yanel/blob/master/src/realms/yanel-website/res-configs-repo/data/en/contact.html.yanel-rc
>
>
>     done:
>
>     http://www.yanel.org/en/documentation/target-environment.html
>
>     Thanks very much for your feedback
>
>
>     Michael
>
>
>
>     -- 
>     Yanel-development mailing list Yanel-development at wyona.com
>     <mailto:Yanel-development at wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120131/c8ea341f/attachment.html>