Hi Marjan,
I haven't used the PullPoint implementation yet, but for your question
about the filter, I think you would pass that in the Subscribe
operation.  So the subscription does the filtering on the "server" end,
instead of the PullPoint "consumer" end.  Of course, you can still take
advantage of the notification consumer framework to apply further
filtering on the consumer end.  The PullPoint itself can just act as a
storage.


-----Original Message-----
From: Marjan Sterjev [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 12, 2007 2:35 AM
To: [email protected]
Subject: PullPoint default (simple) implementation bug

Hi,

 

I didn't get any response on my question about PullPoint working
example, so I was investigating and digging the source code in the mean
time (it is always about time).

 

I added the required WSDL modifications for PullPoint and
CreatePullPoint port types and I was able to create PullPoint. However
GetMessages operation returns no messages at all. Why?

 

The Muse PullPoint simple implementations didn't work without
modifications and recompilation of the code. The problem is with the
class org.apache.muse.ws.notification.impl.SimplePullPoint in the method
accepts().

 

public boolean accepts(NotificationMessage message)

    {

        EndpointReference subEPR = message.getSubscriptionReference();

        //return subEPR != null && getSubscription().equals(subEPR);

        return subEPR != null &&
subEPR.equals(getSubscription().getEndpointReference());

    }

 

I commented the wrong line and added the correct line comparing objects
of the same type, i.e. getSubscription()  should be replaced with
getSubscription().getEndpointReference()).

 

The Muse PullPoint implementation mechanism is rather strange. The
specification (wsn-ws_base_notification-1.3-spec-os.pdf page 25) says:
The intended pattern of use is that a Subscriber or other party creates
a PullPoint through the factory interface, and then uses it as the
ConsumerReference in one or more Subscribe requests. The actual consumer
then pulls Notifications from the PullPoint. 

 

I was following this pattern, i.e. I created PullPoint and after that I
was using the returned ConsumerReference in a separate Subscribe
request. I found that this way we get 2 subscriptions. 

 

We can see that in the class
org.apache.muse.ws.notification.impl.SimplePullPointCreation
subscription is automatically created when the PullPoint is created. Is
this correct?
Subscription on what? The Simple implementation produces subscription
using
PublishAllMessagesFilter:

 

public Filter getFilter()

{

        return PublishAllMessagesFilter.getInstance();

 }

 

Ok, someone can argue that we can write our own implementations that
will support filtering. However the question is how we can supply filter
parameters? The interface org.apache.muse.ws.notification.Interface
PullPointCreation has method createPullPoint(), i.e. there are no
arguments at all.
 
Am I missing something?
 
Regards
 
Marjan

 

 

 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to