Petals Sample Client

Endpoint mismatch when interface/service are the same

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.5.1
  • Fix Version/s: 1.5.2, 1.8.0
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    Deploy 2 endpoints with same interface / service.
    Let's say : IF1 / SVC1 / EP1 and IF1 / SVC1 / EP2 .

    Invoke EP1 with sample client : works fine.

    Undeploy EP1 (su), and do the same invocation again (on missing endpoint EP1).

    EP2 is invoked by Petals.

    Wondering wether it is a bug... or a (undocumented) functionality ??

    Not that deploying 2 different EPs with same IF/SVC is definitely not a good SOA practice, if they are really supposed different - but this is not the point.

    Show
    Deploy 2 endpoints with same interface / service. Let's say : IF1 / SVC1 / EP1 and IF1 / SVC1 / EP2 . Invoke EP1 with sample client : works fine. Undeploy EP1 (su), and do the same invocation again (on missing endpoint EP1). EP2 is invoked by Petals. Wondering wether it is a bug... or a (undocumented) functionality ?? Not that deploying 2 different EPs with same IF/SVC is definitely not a good SOA practice, if they are really supposed different - but this is not the point.
  • Environment:
    Linux / JDK 1.6

Activity

Hide
Christophe DENEUX added a comment - Thu, 1 Sep 2011 - 15:10:41 +0200

The problem seems to be due to the component petals-sample-client that does not manage correctly unregistered endpoint.
If the endpoint name is filled in the UI, the petals sample client try to get the associated service endpoint (using ComponentContext.getEndpoint(...)) that will be set in the message exchange. If the service endpoint does not exist, the value null is returned by ComponentContext.getEndpoint(...).
As this value null is not managed but directly set in the message exchange, the router will resolved interface name and service name to find a registered endpoint.

Show
Christophe DENEUX added a comment - Thu, 1 Sep 2011 - 15:10:41 +0200 The problem seems to be due to the component petals-sample-client that does not manage correctly unregistered endpoint. If the endpoint name is filled in the UI, the petals sample client try to get the associated service endpoint (using ComponentContext.getEndpoint(...)) that will be set in the message exchange. If the service endpoint does not exist, the value null is returned by ComponentContext.getEndpoint(...). As this value null is not managed but directly set in the message exchange, the router will resolved interface name and service name to find a registered endpoint.
Hide
Pierre-Yves Gibello added a comment - Thu, 1 Sep 2011 - 15:21:03 +0200

Not sure, because the problem was discovered using the BC-SOAP as a client.
In the report, the sample-client has been used, only to make the test scenario shorter.
Does the BC-SOAP have the same bug as the one you suggest for the sample-client, I don't know, but it looks quite weird.

Show
Pierre-Yves Gibello added a comment - Thu, 1 Sep 2011 - 15:21:03 +0200 Not sure, because the problem was discovered using the BC-SOAP as a client. In the report, the sample-client has been used, only to make the test scenario shorter. Does the BC-SOAP have the same bug as the one you suggest for the sample-client, I don't know, but it looks quite weird.
Hide
Christophe DENEUX added a comment - Thu, 1 Sep 2011 - 15:53:25 +0200

Fixed in petals-entreprise-3.1.x

Show
Christophe DENEUX added a comment - Thu, 1 Sep 2011 - 15:53:25 +0200 Fixed in petals-entreprise-3.1.x
Hide
Christophe DENEUX added a comment - Thu, 1 Sep 2011 - 15:53:34 +0200

To merge in trunk

Show
Christophe DENEUX added a comment - Thu, 1 Sep 2011 - 15:53:34 +0200 To merge in trunk
Hide
Christophe DENEUX added a comment - Mon, 12 Mar 2012 - 18:39:21 +0100

Merged in trunk

Show
Christophe DENEUX added a comment - Mon, 12 Mar 2012 - 18:39:21 +0100 Merged in trunk

People

Dates

  • Created:
    Wed, 31 Aug 2011 - 16:26:35 +0200
    Updated:
    Mon, 12 Mar 2012 - 18:39:21 +0100
    Resolved:
    Mon, 12 Mar 2012 - 18:39:21 +0100