Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Conditional XML feature?


Joakime,

Implementing the full suite of logical operators is part of the slippery slope that has made me avoid this kind of thing.   If you follow this to completion you need loops and parametrised methods... soon we will have implemented java in XML.

My thought bubble is really about what can we do to avoid putting defaults values in code AND in xml AND in ini, not about providing arbitrary control semantics. We already have the module system that allows conditional switching of whole XML files.

But then on the other hand, it would not be too difficult to implement swith, else, elseif....  but then looking at spring, they have avoided it saying that it would just add another level of debugging and you'd be better off writing custom beans that contain exactly the conditional logic needed.

So I'm wondering if my use-case might be better served with a if-not-null  attribute

   <Set if-no-null name="port"><Property name="https.port"/></Set>



On 16 October 2015 at 02:20, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
Wouldn't having conditionals also mean we need AND, OR, NOT boolean operations (with grouping) as a necessary feature set?

Also what about <else> or <else-if> logic? 
(course, these could probably be handled with a simple <switch> instead of <if>)

<switch name="https.enabled">
  <condition value="true">
  </condition>
  <condition value="false">
  </condition>
</switch>

or 

<switch name="operational.mode">
  <condition value="dev">
  </condition>
  <condition value="qa">
  </condition>
  <condition value="prod">
  </condition>
  <condition> <!-- default -->
  </condition>
</switch>



Joakim Erdfelt / joakim@xxxxxxxxxxx

On Thu, Oct 15, 2015 at 8:10 AM, Tom Zeller <tzeller@xxxxxxxxxxxxxx> wrote:

> On Oct 13, 2015, at 4:36 PM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
>
> But it could also be used with a gating property name:
>
>
>    <If name="https.enabled">
>       <Set name="scheme">https</Set>
>       <Set name="port"><Property name="https.port"/></Set>
>       <Call name="addCustomizer"><Arg><New class="o.e.j.s.SecureRequestCustomizer"/></Arg></Call>
>    </If>

Thanks for engaging me, that’s kind.

Come to think of it, we (shibboleth.net identity provider) probably would use the “gating property”. For example, to control the instantiation and injection of a connector based on the existence and value of the property defining the port for that connector, as you well describe above. In our case, examples would be properties defining a commented-out-by-default non-HTTPS port and a “backchannel” port where we ignore/trust all certs (so we can handle that ourselves). As background, we ship an “embedded” Jetty, which is “embedded” only in the sense of : that’s the name of the parent directory of the jetty-base we supply. Because XML is a core competency for deployers, I doubt we would go the Java route, instead preferring XML + properties.

Thanks again.
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev



--

Back to the top