Petals CDK

Invalid error message if the external listener classname of the JBI descriptor contains a CR/NL

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 5.1.1
  • Fix Version/s: 5.1.2, 5.2.0
  • Component/s: configuration
  • Security Level: Public
  • Description:

    As for PETALSCDK-57, the same problem occurs on the external listener class name

  • Environment:
    -

Activity

Hide
Christophe DENEUX added a comment - Wed, 16 Feb 2011 - 17:10:17 +0100

A patch of this problem is available in the issue PETALSCDK-57

Show
Christophe DENEUX added a comment - Wed, 16 Feb 2011 - 17:10:17 +0100 A patch of this problem is available in the issue PETALSCDK-57
Hide
Christophe Hamerling added a comment - Wed, 16 Feb 2011 - 17:13:46 +0100

It is the case for all the JBI parameters if they are not trimmed at the CDK or component level...

Show
Christophe Hamerling added a comment - Wed, 16 Feb 2011 - 17:13:46 +0100 It is the case for all the JBI parameters if they are not trimmed at the CDK or component level...
Hide
Christophe DENEUX added a comment - Wed, 16 Feb 2011 - 17:36:41 +0100

I'm not sure because others parameters are not defined as string, but as integer, boolean, ... and the parser should return an explicit error if a provided value is invalid.

Show
Christophe DENEUX added a comment - Wed, 16 Feb 2011 - 17:36:41 +0100 I'm not sure because others parameters are not defined as string, but as integer, boolean, ... and the parser should return an explicit error if a provided value is invalid.
Hide
Vincent Zurczak added a comment - Thu, 17 Feb 2011 - 11:10:02 +0100

Hi guys,

Last year, I submitted a similar problem in the EJB BC.
See PETALSBCEJB-4 for more details, but it was a component parameter.

I think all the parameters values should be trimmed.
That would avoid lots of useless problems. That's what I do for all the component parameters in my components.

Show
Vincent Zurczak added a comment - Thu, 17 Feb 2011 - 11:10:02 +0100 Hi guys, Last year, I submitted a similar problem in the EJB BC. See PETALSBCEJB-4 for more details, but it was a component parameter. I think all the parameters values should be trimmed. That would avoid lots of useless problems. That's what I do for all the component parameters in my components.
Hide
Olivier Fabre added a comment - Tue, 29 Mar 2011 - 16:39:52 +0200

An other solution could be to use xml schema restrictions (like the one describe here : http://www.w3.org/TR/xmlschema-0/#CreatDt) to be able to detect problem at design time. And use regular expressions for "class names" that forbids white spaces and CR. But I'm not sure that IDE validators and jaxb validators support this type of restrictions...

Show
Olivier Fabre added a comment - Tue, 29 Mar 2011 - 16:39:52 +0200 An other solution could be to use xml schema restrictions (like the one describe here : http://www.w3.org/TR/xmlschema-0/#CreatDt) to be able to detect problem at design time. And use regular expressions for "class names" that forbids white spaces and CR. But I'm not sure that IDE validators and jaxb validators support this type of restrictions...
Hide
strino added a comment - Tue, 29 Mar 2011 - 16:42:29 +0200

Fix patch in the branch 3.1.X

Show
strino added a comment - Tue, 29 Mar 2011 - 16:42:29 +0200 Fix patch in the branch 3.1.X
Hide
Christophe DENEUX added a comment - Tue, 29 Mar 2011 - 16:48:01 +0200

Olivier, your proposal can be a solution if the validation used is able to detect such an error. I think that, in a user point of view, the user wants the best error message even with the solution. That's why I think a validation is sufficient instead of to trim each parameter value.
Perhaps the validation should be the solution to implement in trunk ?

Show
Christophe DENEUX added a comment - Tue, 29 Mar 2011 - 16:48:01 +0200 Olivier, your proposal can be a solution if the validation used is able to detect such an error. I think that, in a user point of view, the user wants the best error message even with the solution. That's why I think a validation is sufficient instead of to trim each parameter value. Perhaps the validation should be the solution to implement in trunk ?
Hide
Christophe DENEUX added a comment - Wed, 30 Mar 2011 - 10:17:40 +0200

To merge in trunk

Show
Christophe DENEUX added a comment - Wed, 30 Mar 2011 - 10:17:40 +0200 To merge in trunk
Olivier Fabre made changes - Wed, 7 Sep 2011 - 17:43:20 +0200
Assignee Sandra Trino [ strino ] Olivier Fabre [ ofabre ]
Olivier Fabre made changes - Wed, 7 Sep 2011 - 17:43:21 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Olivier Fabre made changes - Wed, 7 Sep 2011 - 17:53:11 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 5.2.0_4.0M1 [ 10267 ]
Resolution Fixed [ 1 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
40d 22h 37m
1
strino
Tue, 29 Mar 2011 - 16:44:51 +0200
Open Open In Progress In Progress
162d 58m
1
Olivier Fabre
Wed, 7 Sep 2011 - 17:43:21 +0200
In Progress In Progress Resolved Resolved
9m 50s
1
Olivier Fabre
Wed, 7 Sep 2011 - 17:53:11 +0200



People

Dates

  • Created:
    Wed, 16 Feb 2011 - 17:07:21 +0100
    Updated:
    Wed, 7 Sep 2011 - 17:53:11 +0200
    Resolved:
    Wed, 7 Sep 2011 - 17:53:11 +0200