Petals SE XSLT

Properties of the incoming message should be passed to the XSL stylesheet as parameter

Details

  • Type: Improvement Request Improvement Request
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 2.3.2
  • Fix Version/s: 2.4
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    An XSL stylesheet is able to use global parameters set when the transformation is invoked.

    Example of XSL with global parameters:

    <?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
     xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xsl:param name="day"></xsl:param>
<xsl:param name="year"></xsl:param>
<xsl:param name="weather"></xsl:param>


<xsl:template match="/">

    Global parameters are set using javax.xml.transform.Transformer.setParameter(name, value).

    Please add support of global parameters that are defined using the properties of the incoming message as following:

    • property name defines the global parameter name,
    • property value defines the global parameter value.

    Add a new attribute 'overridable' for each xsl-parameter to manage conflict between input properties and xsl-parameter:

    • if true, the input property override the xsl-parameter by the input property, no warning log message
    • if false, a fault is returned
    • default value: false
    Show
    An XSL stylesheet is able to use global parameters set when the transformation is invoked. Example of XSL with global parameters: 
    <?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
     xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xsl:param name="day"></xsl:param>
<xsl:param name="year"></xsl:param>
<xsl:param name="weather"></xsl:param>


<xsl:template match="/">
    Global parameters are set using javax.xml.transform.Transformer.setParameter(name, value). Please add support of global parameters that are defined using the properties of the incoming message as following:
    • property name defines the global parameter name,
    • property value defines the global parameter value.
    Add a new attribute 'overridable' for each xsl-parameter to manage conflict between input properties and xsl-parameter:
    • if true, the input property override the xsl-parameter by the input property, no warning log message
    • if false, a fault is returned
    • default value: false
  • Environment:
    -

Issue Links

Depends
 

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Vincent Zurczak added a comment - Thu, 16 Sep 2010 - 20:23:37 +0200

Commit # 15784

Show
Vincent Zurczak added a comment - Thu, 16 Sep 2010 - 20:23:37 +0200 Commit # 15784
Hide
Permalink
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 07:49:58 +0200

The first implementation needs two collection go-through.
It can be reduced to a single one.

Show
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 07:49:58 +0200 The first implementation needs two collection go-through. It can be reduced to a single one.
Hide
Permalink
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 07:55:18 +0200

Commit # 15785

Show
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 07:55:18 +0200 Commit # 15785
Hide
Permalink
Christophe DENEUX added a comment - Fri, 17 Sep 2010 - 08:56:32 +0200

Can you add a conflict warning log message if a input property has the same name than a xsl-parameter, specifying which is used (property or SU parameter) ?
Can you change the level (INFO -> WARNING) of the log message in case of MessagingException. It's an error but not sufficient to block completely the processing.

Show
Christophe DENEUX added a comment - Fri, 17 Sep 2010 - 08:56:32 +0200 Can you add a conflict warning log message if a input property has the same name than a xsl-parameter, specifying which is used (property or SU parameter) ? Can you change the level (INFO -> WARNING) of the log message in case of MessagingException. It's an error but not sufficient to block completely the processing.
Hide
Permalink
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 10:21:00 +0200

Is it really important if there is a conflict in the properties?
I mean, in some case, overriding the SU configuration will be the goal of the properties setting.
Anyway, would "INFO" be enough?

And about the warning, we really need to update the logging rules.
For the moment, warning is supposed to be avoided.
Or would like to return a fault in case of MessagingException?
That would make sense.

Show
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 10:21:00 +0200 Is it really important if there is a conflict in the properties? I mean, in some case, overriding the SU configuration will be the goal of the properties setting. Anyway, would "INFO" be enough? And about the warning, we really need to update the logging rules. For the moment, warning is supposed to be avoided. Or would like to return a fault in case of MessagingException? That would make sense.
Hide
Permalink
Christophe DENEUX added a comment - Fri, 17 Sep 2010 - 11:02:57 +0200

Yes, it's important because:

  • in one hand, some clients will want to override xsl-parameters with input properties,
  • in other hand, some clients will NOT want to overriding
    So, the best way is to add a new parameter to drive the overriding

And I will update rules against operator needs

Show
Christophe DENEUX added a comment - Fri, 17 Sep 2010 - 11:02:57 +0200 Yes, it's important because:
  • in one hand, some clients will want to override xsl-parameters with input properties,
  • in other hand, some clients will NOT want to overriding So, the best way is to add a new parameter to drive the overriding
And I will update rules against operator needs
Hide
Permalink
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 11:07:37 +0200

And in case of conflict, and if overriding is not allowed by the SU configuration, do we agree a fault should be raised?

Show
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 11:07:37 +0200 And in case of conflict, and if overriding is not allowed by the SU configuration, do we agree a fault should be raised?
Hide
Permalink
Christophe DENEUX added a comment - Fri, 17 Sep 2010 - 11:19:52 +0200

Yes.

I update the description with results of this exchange

Show
Christophe DENEUX added a comment - Fri, 17 Sep 2010 - 11:19:52 +0200 Yes. I update the description with results of this exchange
Hide
Permalink
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 14:40:46 +0200

Commit # 15787
A new attribute "overridable" was added in the SU.
If a XSL parameter from the exchange tries to override a SU XSL parameter while it can't, then an exception is thrown.
The class loader restoration was moved in a finally block.

Notice that a fault is not thrown in case of unsuccessful overriding.
In fact, this component does not set any fault.
When something fails (invalid operation, transformation failure), it only sets errors on the exchanges.

That should be differed in a different bug, meaning replacing the setError by setFault, with a custom exception.
At least, that would be compatible with the InOut MEP of the operations.

Show
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 14:40:46 +0200 Commit # 15787 A new attribute "overridable" was added in the SU. If a XSL parameter from the exchange tries to override a SU XSL parameter while it can't, then an exception is thrown. The class loader restoration was moved in a finally block. Notice that a fault is not thrown in case of unsuccessful overriding. In fact, this component does not set any fault. When something fails (invalid operation, transformation failure), it only sets errors on the exchanges. That should be differed in a different bug, meaning replacing the setError by setFault, with a custom exception. At least, that would be compatible with the InOut MEP of the operations.
Hide
Permalink
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 15:52:49 +0200

Now, a fault is set instead of an error (see PETALSSEXSLT-14).

Show
Vincent Zurczak added a comment - Fri, 17 Sep 2010 - 15:52:49 +0200 Now, a fault is set instead of an error (see PETALSSEXSLT-14).

People

Dates

  • Created:
    Thu, 16 Sep 2010 - 17:56:48 +0200
    Updated:
    Fri, 17 Sep 2010 - 15:52:49 +0200
    Resolved:
    Fri, 17 Sep 2010 - 14:40:46 +0200
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.