Original URL in FetcherEvent

[eeKnud]

Hi All,

I am having grief with HTTP 3xx redirects. Basically, I have multiple RSS aggregator clients making feed subscription requests to a RSS aggregator server. The server keeps track of requests/requestors, polls feeds periodically, and forwards feed events to the requestors based on their feed subscriptions. Since this is all asynchronous, I use tokens to match requests to event forwards, and part of the token is the original RSS/Atom URL. I need to match the received feed event to the original URL.

Though it may well be possible, I've not figured out how to get the original URL for a feed request when my listener gets a feed retrieved event.

I understand that the original URL is used as an "id" in the SyndFeedInfo, there's no get it back from the feed cache unless you have the original URL (see HttpURLFeedFetcher).

It appears that one would have to modify the HttpURLFeedFetcher, AbstractFeedFetcher, and FetcherEvent to accomplish this. Adding a new URL (maybe String) arg to various methods and adding a new URL (String?) member to FetcherEvent probably does it.

Nick L or anyone else, any comment?

Thanks,

Steven

[Nick Lothian-2]

I think that the HttpClientFetcher behaves differently here and will give you the original address.

I do remember having a similar issue and working out a solution, but it was quite a while ago. I'll take a look at some code on Monday.

On Sat, Jan 10, 2009 at 3:42 AM, Steven Knudsen <ee.knud@...> wrote:

Hi All,

I am having grief with HTTP 3xx redirects. Basically, I have multiple RSS aggregator clients making feed subscription requests to a RSS aggregator server. The server keeps track of requests/requestors, polls feeds periodically, and forwards feed events to the requestors based on their feed subscriptions. Since this is all asynchronous, I use tokens to match requests to event forwards, and part of the token is the original RSS/Atom URL. I need to match the received feed event to the original URL.
ng
Though it may well be possible, I've not figured out how to get the original URL for a feed request when my listener gets a feed retrieved event.

I understand that the original URL is used as an "id" in the SyndFeedInfo, there's no get it back from the feed cache unless you have the original URL (see HttpURLFeedFetcher).

It appears that one would have to modify the HttpURLFeedFetcher, AbstractFeedFetcher, and FetcherEvent to accomplish this. Adding a new URL (maybe String) arg to various methods and adding a new URL (String?) member to FetcherEvent probably does it.

Nick L or anyone else, any comment?

Thanks,

Steven

[eeKnud]

Thanks, Nick.

It may be that I've overlooked something in the code, but as I understand things:

1. SyndFeedInfo provides <code>public synchronized String getId() </code>

2. FeedFetcherCache provides <code>public SyndFeedInfo getFeedInfo(URL feedUrl) </code>

3. HttpClientFeedFetcher/HttpURLFeedFetcher provide <code>public synchronized FeedFetcherCache getFeedInfoCache() </code>

The use of <code>feedUrl</code> to retrieve the cache is the problem.

I'm using HttpURLFeedFetcher, but I believe the behaviour is the same for either fetcher. AFAIK, when you call <code>retrieveFeed</code> the input URL is used as a key for the SyndFeedInfo entry in the cache. It may well be that the URL key is changed under the covers to match the FetcherEvent URL string that is eventually returned. This wouldn't be the first time that I've missed something in reviewing code :-)

As I mentioned, I can't rely on the initially returned feed because I forward FetcherEvents to any and all of my RSS clients when they are received.

Anyway, any light you can shed will be much appreciated!

Best regards,

steven

On 10-Jan-09, at 12:54 AM, Nick Lothian wrote:

I think that the HttpClientFetcher behaves differently here and will give you the original address.

I do remember having a similar issue and working out a solution, but it was quite a while ago. I'll take a look at some code on Monday.

On Sat, Jan 10, 2009 at 3:42 AM, Steven Knudsen <ee.knud@...> wrote:

Hi All,

I am having grief with HTTP 3xx redirects. Basically, I have multiple RSS aggregator clients making feed subscription requests to a RSS aggregator server. The server keeps track of requests/requestors, polls feeds periodically, and forwards feed events to the requestors based on their feed subscriptions. Since this is all asynchronous, I use tokens to match requests to event forwards, and part of the token is the original RSS/Atom URL. I need to match the received feed event to the original URL.
ng
Though it may well be possible, I've not figured out how to get the original URL for a feed request when my listener gets a feed retrieved event.

I understand that the original URL is used as an "id" in the SyndFeedInfo, there's no get it back from the feed cache unless you have the original URL (see HttpURLFeedFetcher).

It appears that one would have to modify the HttpURLFeedFetcher, AbstractFeedFetcher, and FetcherEvent to accomplish this. Adding a new URL (maybe String) arg to various methods and adding a new URL (String?) member to FetcherEvent probably does it.

Nick L or anyone else, any comment?

Thanks,

Steven

[Nick Lothian]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Yes, that is an accurate summary.

 

> It may well be that the URL key is changed under the covers to match the FetcherEvent URL string that is eventually returned. This wouldn't be the first time that I've missed something in reviewing code :-)

 

You haven’t missed anything in the code, just a surprising behaviour on the part of java.net.HttpURLConnection.

 

Basically, unless setInstanceFollowRedirects is set to false, then HttpURLConnection will automatically follow 301 redirect. That is reasonable behaviour.

 

The surprise is that the url returned by connection.getURL() is now the new, redirected url. I suppose that is also reasonable, but as far as I know it isn’t documented anywhere.

 

Anyway, you can see this behaviour in HttpURLFeedFetcherTest.testRetrieveRedirectedFeed(). The output looks like this:

 

08:49:02.040 EVENT  Starting Jetty/4.2.12

08:49:02.041 EVENT  Started HttpContext[/rome]

08:49:02.050 EVENT  Started SocketListener on 0.0.0.0:8283

08:49:02.050 EVENT  Started org.mortbay.http.HttpServer@1292d26

Could not find fetcher.properties on classpath

      EVENT: Feed Polled. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE

      EVENT: Feed Retrieved. URL = http://localhost:8283/rome/FetcherTestServlet2/

08:49:02.073 EVENT  Stopping Acceptor ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8283]

08:49:02.074 EVENT  Stopped SocketListener on 0.0.0.0:8283

08:49:02.074 EVENT  Stopped HttpContext[/rome]

08:49:02.074 EVENT  Stopped org.mortbay.http.HttpServer@1292d26

 

(Note that the “Polled” and “Retrieved” events give different URLs)

 

However, the good news is that if we run the same test using HttpClientFeedFetcher you get this trace:

 

08:50:53.640 EVENT  Starting Jetty/4.2.12

08:50:53.640 EVENT  Started HttpContext[/rome]

08:50:53.652 EVENT  Started SocketListener on 0.0.0.0:8283

08:50:53.652 EVENT  Started org.mortbay.http.HttpServer@765a16

Could not find fetcher.properties on classpath

      EVENT: Feed Polled. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE

      EVENT: Feed Retrieved. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE

08:50:53.675 EVENT  Stopping Acceptor ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8283]

08:50:53.676 EVENT  Stopped SocketListener on 0.0.0.0:8283

08:50:53.676 EVENT  Stopped HttpContext[/rome]

08:50:53.676 EVENT  Stopped org.mortbay.http.HttpServer@765a16

 

I suspect that exactly what you are after, right?

 

Nick

 

From: Steven Knudsen [mailto:ee.knud@...]
Sent: Monday, 12 January 2009 1:19 AM
To: dev@...
Subject: Re: Original URL in FetcherEvent

 

Thanks, Nick.

 

It may be that I've overlooked something in the code, but as I understand things:

 

1. SyndFeedInfo provides <code>public synchronized String getId() </code>

2. FeedFetcherCache provides <code>public SyndFeedInfo getFeedInfo(URL feedUrl) </code>

3. HttpClientFeedFetcher/HttpURLFeedFetcher provide <code>public synchronized FeedFetcherCache getFeedInfoCache() </code>

 

The use of <code>feedUrl</code> to retrieve the cache is the problem.

 

I'm using HttpURLFeedFetcher, but I believe the behaviour is the same for either fetcher. AFAIK, when you call <code>retrieveFeed</code> the input URL is used as a key for the SyndFeedInfo entry in the cache. It may well be that the URL key is changed under the covers to match the FetcherEvent URL string that is eventually returned. This wouldn't be the first time that I've missed something in reviewing code :-)

 

As I mentioned, I can't rely on the initially returned feed because I forward FetcherEvents to any and all of my RSS clients when they are received.

 

Anyway, any light you can shed will be much appreciated!

 

Best regards,

 

steven

 

 

On 10-Jan-09, at 12:54 AM, Nick Lothian wrote:

I think that the HttpClientFetcher behaves differently here and will give you the original address.

I do remember having a similar issue and working out a solution, but it was quite a while ago. I'll take a look at some code on Monday.

On Sat, Jan 10, 2009 at 3:42 AM, Steven Knudsen <ee.knud@...> wrote:

Hi All,

I am having grief with HTTP 3xx redirects. Basically, I have multiple RSS aggregator clients making feed subscription requests to a RSS aggregator server. The server keeps track of requests/requestors, polls feeds periodically, and forwards feed events to the requestors based on their feed subscriptions. Since this is all asynchronous, I use tokens to match requests to event forwards, and part of the token is the original RSS/Atom URL. I need to match the received feed event to the original URL.
ng
Though it may well be possible, I've not figured out how to get the original URL for a feed request when my listener gets a feed retrieved event.

I understand that the original URL is used as an "id" in the SyndFeedInfo, there's no get it back from the feed cache unless you have the original URL (see HttpURLFeedFetcher).

It appears that one would have to modify the HttpURLFeedFetcher, AbstractFeedFetcher, and FetcherEvent to accomplish this. Adding a new URL (maybe String) arg to various methods and adding a new URL (String?) member to FetcherEvent probably does it.

Nick L or anyone else, any comment?

Thanks,

Steven

 

 

---

IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.

[eeKnud]

Thanks, Nick.

I was beginning to suspect that I chose the wrong fetcher, and your analysis/testing seems to show that. Big thanks.

So, do you think it might be nice to get both the redirected and the original URLs for both fetchers? I'm not sure it's the right thing to do, but I would like to try and save the redirect address for my RSS clients under the assumption that when I restore their state at startup, those addresses are "somehow better".

Also, did you look at the SyndFeedInfo retrieval question implied in my analysis below? That is, can one use the event supplied URL to get the SyndFeedInfo correctly?

When I get a chance, I'll look at switching fetchers in my code.

Again, thanks for the really prompt look at this.

steven

On 11-Jan-09, at 3:22 PM, Nick Lothian wrote:

Yes, that is an accurate summary.

 

> It may well be that the URL key is changed under the covers to match the FetcherEvent URL string that is eventually returned. This wouldn't be the first time that I've missed something in reviewing code :-)

 

You haven’t missed anything in the code, just a surprising behaviour on the part of java.net.HttpURLConnection.

 

Basically, unless setInstanceFollowRedirects is set to false, then HttpURLConnection will automatically follow 301 redirect. That is reasonable behaviour.

 

The surprise is that the url returned by connection.getURL() is now the new, redirected url. I suppose that is also reasonable, but as far as I know it isn’t documented anywhere.

 

Anyway, you can see this behaviour in HttpURLFeedFetcherTest.testRetrieveRedirectedFeed(). The output looks like this:

 

08:49:02.040 EVENT  Starting Jetty/4.2.12

08:49:02.041 EVENT  Started HttpContext[/rome]

08:49:02.050 EVENT  Started SocketListener on 0.0.0.0:8283

08:49:02.050 EVENT  Started org.mortbay.http.HttpServer@1292d26

Could not find fetcher.properties on classpath

      EVENT: Feed Polled. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE

      EVENT: Feed Retrieved. URL = http://localhost:8283/rome/FetcherTestServlet2/

08:49:02.073 EVENT  Stopping Acceptor ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8283]

08:49:02.074 EVENT  Stopped SocketListener on 0.0.0.0:8283

08:49:02.074 EVENT  Stopped HttpContext[/rome]

08:49:02.074 EVENT  Stopped org.mortbay.http.HttpServer@1292d26

 

(Note that the “Polled” and “Retrieved” events give different URLs)

 

However, the good news is that if we run the same test using HttpClientFeedFetcher you get this trace:

 

08:50:53.640 EVENT  Starting Jetty/4.2.12

08:50:53.640 EVENT  Started HttpContext[/rome]

08:50:53.652 EVENT  Started SocketListener on 0.0.0.0:8283

08:50:53.652 EVENT  Started org.mortbay.http.HttpServer@765a16

Could not find fetcher.properties on classpath

      EVENT: Feed Polled. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE

      EVENT: Feed Retrieved. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE

08:50:53.675 EVENT  Stopping Acceptor ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8283]

08:50:53.676 EVENT  Stopped SocketListener on 0.0.0.0:8283

08:50:53.676 EVENT  Stopped HttpContext[/rome]

08:50:53.676 EVENT  Stopped org.mortbay.http.HttpServer@765a16

 

I suspect that exactly what you are after, right?

 

Nick

 

From: Steven Knudsen [ee.knud@...] 
Sent: Monday, 12 January 2009 1:19 AM
To: dev@...
Subject: Re: Original URL in FetcherEvent

 

Thanks, Nick.

 

It may be that I've overlooked something in the code, but as I understand things:

 

1. SyndFeedInfo provides <code>public synchronized String getId() </code>

2. FeedFetcherCache provides <code>public SyndFeedInfo getFeedInfo(URL feedUrl) </code>

3. HttpClientFeedFetcher/HttpURLFeedFetcher provide <code>public synchronized FeedFetcherCache getFeedInfoCache() </code>

 

The use of <code>feedUrl</code> to retrieve the cache is the problem.

 

I'm using HttpURLFeedFetcher, but I believe the behaviour is the same for either fetcher. AFAIK, when you call <code>retrieveFeed</code> the input URL is used as a key for the SyndFeedInfo entry in the cache. It may well be that the URL key is changed under the covers to match the FetcherEvent URL string that is eventually returned. This wouldn't be the first time that I've missed something in reviewing code :-)

 

As I mentioned, I can't rely on the initially returned feed because I forward FetcherEvents to any and all of my RSS clients when they are received.

 

Anyway, any light you can shed will be much appreciated!

 

Best regards,

 

steven

 

 

On 10-Jan-09, at 12:54 AM, Nick Lothian wrote:

I think that the HttpClientFetcher behaves differently here and will give you the original address.

I do remember having a similar issue and working out a solution, but it was quite a while ago. I'll take a look at some code on Monday.

On Sat, Jan 10, 2009 at 3:42 AM, Steven Knudsen <ee.knud@...> wrote:

Hi All,

I am having grief with HTTP 3xx redirects. Basically, I have multiple RSS aggregator clients making feed subscription requests to a RSS aggregator server. The server keeps track of requests/requestors, polls feeds periodically, and forwards feed events to the requestors based on their feed subscriptions. Since this is all asynchronous, I use tokens to match requests to event forwards, and part of the token is the original RSS/Atom URL. I need to match the received feed event to the original URL.
ng
Though it may well be possible, I've not figured out how to get the original URL for a feed request when my listener gets a feed retrieved event.

I understand that the original URL is used as an "id" in the SyndFeedInfo, there's no get it back from the feed cache unless you have the original URL (see HttpURLFeedFetcher).

It appears that one would have to modify the HttpURLFeedFetcher, AbstractFeedFetcher, and FetcherEvent to accomplish this. Adding a new URL (maybe String) arg to various methods and adding a new URL (String?) member to FetcherEvent probably does it.

Nick L or anyone else, any comment?

Thanks,

Steven

 

 

---

IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.

[Nick Lothian]

>So, do you think it might be nice to get both the redirected and the original URLs for both fetchers?

Yes, I think that would be a good idea.

> Also, did you look at the SyndFeedInfo retrieval question implied in my analysis below? That is, can one use the event supplied URL to get the SyndFeedInfo correctly?

I think that will work when using HttpClientFeedFetcher.

I'm not sure about HttpURLFeedFetcher - having a close look at the code, I think that there is a subtle bug when dealing with redirected feeds. The code looks like this:

SyndFeedInfo syndFeedInfo = cache.getFeedInfo(feedUrl);
setRequestHeaders(connection, syndFeedInfo);
httpConnection.connect();
try {
        fireEvent(FetcherEvent.EVENT_TYPE_FEED_POLLED, connection);

        if (syndFeedInfo == null) {
                // this is a feed that hasn't been retrieved
                syndFeedInfo = new SyndFeedInfo();
                retrieveAndCacheFeed(feedUrl, syndFeedInfo, httpConnection);
        } else {
                // check the response code
                int responseCode = httpConnection.getResponseCode();
                if (responseCode != HttpURLConnection.HTTP_NOT_MODIFIED) {
                        // the response code is not 304 NOT MODIFIED
                        // This is either because the feed server
                        // does not support condition gets
                        // or because the feed hasn't changed
                        retrieveAndCacheFeed(feedUrl, syndFeedInfo, httpConnection);
                } else {
                        // the feed does not need retrieving
                        fireEvent(FetcherEvent.EVENT_TYPE_FEED_UNCHANGED, connection);
                }
        }

        return syndFeedInfo.getSyndFeed();
} finally {
    httpConnection.disconnect();
}

To me that looks like the initial lookup in the cache will use the url-prior-to-redirection, and then it will be saved using the url-after-redirection. If my analysis is correct it means that redirected feeds won't be cached.

I need to look at that some more - when I get time I'll try and write a test case.

Nick

----
From: Steven Knudsen [mailto:ee.knud@...]
Sent: Monday, 12 January 2009 10:11 AM
To: dev@...
Subject: Re: Original URL in FetcherEvent

Thanks, Nick.

I was beginning to suspect that I chose the wrong fetcher, and your analysis/testing seems to show that. Big thanks.

So, do you think it might be nice to get both the redirected and the original URLs for both fetchers? I'm not sure it's the right thing to do, but I would like to try and save the redirect address for my RSS clients under the assumption that when I restore their state at startup, those addresses are "somehow better".

Also, did you look at the SyndFeedInfo retrieval question implied in my analysis below? That is, can one use the event supplied URL to get the SyndFeedInfo correctly?

When I get a chance, I'll look at switching fetchers in my code.

Again, thanks for the really prompt look at this.

steven


On 11-Jan-09, at 3:22 PM, Nick Lothian wrote:


Yes, that is an accurate summary.

> It may well be that the URL key is changed under the covers to match the FetcherEvent URL string that is eventually returned. This wouldn't be the first time that I've missed something in reviewing code :-)

You haven't missed anything in the code, just a surprising behaviour on the part of java.net.HttpURLConnection.

Basically, unless setInstanceFollowRedirects is set to false, then HttpURLConnection will automatically follow 301 redirect. That is reasonable behaviour.

The surprise is that the url returned by connection.getURL() is now the new, redirected url. I suppose that is also reasonable, but as far as I know it isn't documented anywhere.

Anyway, you can see this behaviour in HttpURLFeedFetcherTest.testRetrieveRedirectedFeed(). The output looks like this:

08:49:02.040 EVENT  Starting Jetty/4.2.12
08:49:02.041 EVENT  Started HttpContext[/rome]
08:49:02.050 EVENT  Started SocketListener on 0.0.0.0:8283
08:49:02.050 EVENT  Started org.mortbay.http.HttpServer@1292d26
Could not find fetcher.properties on classpath
      EVENT: Feed Polled. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE
      EVENT: Feed Retrieved. URL = http://localhost:8283/rome/FetcherTestServlet2/
08:49:02.073 EVENT  Stopping Acceptor ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8283]
08:49:02.074 EVENT  Stopped SocketListener on 0.0.0.0:8283
08:49:02.074 EVENT  Stopped HttpContext[/rome]
08:49:02.074 EVENT  Stopped org.mortbay.http.HttpServer@1292d26

(Note that the "Polled" and "Retrieved" events give different URLs)

However, the good news is that if we run the same test using HttpClientFeedFetcher you get this trace:

08:50:53.640 EVENT  Starting Jetty/4.2.12
08:50:53.640 EVENT  Started HttpContext[/rome]
08:50:53.652 EVENT  Started SocketListener on 0.0.0.0:8283
08:50:53.652 EVENT  Started org.mortbay.http.HttpServer@765a16
Could not find fetcher.properties on classpath
      EVENT: Feed Polled. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE
      EVENT: Feed Retrieved. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE
08:50:53.675 EVENT  Stopping Acceptor ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8283]
08:50:53.676 EVENT  Stopped SocketListener on 0.0.0.0:8283
08:50:53.676 EVENT  Stopped HttpContext[/rome]
08:50:53.676 EVENT  Stopped org.mortbay.http.HttpServer@765a16

I suspect that exactly what you are after, right?

Nick

From: Steven Knudsen [mailto:ee.knud@...]
Sent: Monday, 12 January 2009 1:19 AM
To: dev@...
Subject: Re: Original URL in FetcherEvent

Thanks, Nick.

It may be that I've overlooked something in the code, but as I understand things:

1. SyndFeedInfo provides <code>public synchronized String getId() </code>
2. FeedFetcherCache provides <code>public SyndFeedInfo getFeedInfo(URL feedUrl) </code>
3. HttpClientFeedFetcher/HttpURLFeedFetcher provide <code>public synchronized FeedFetcherCache getFeedInfoCache() </code>

The use of <code>feedUrl</code> to retrieve the cache is the problem.

I'm using HttpURLFeedFetcher, but I believe the behaviour is the same for either fetcher. AFAIK, when you call <code>retrieveFeed</code> the input URL is used as a key for the SyndFeedInfo entry in the cache. It may well be that the URL key is changed under the covers to match the FetcherEvent URL string that is eventually returned. This wouldn't be the first time that I've missed something in reviewing code :-)

As I mentioned, I can't rely on the initially returned feed because I forward FetcherEvents to any and all of my RSS clients when they are received.

Anyway, any light you can shed will be much appreciated!

Best regards,

steven


On 10-Jan-09, at 12:54 AM, Nick Lothian wrote:



I think that the HttpClientFetcher behaves differently here and will give you the original address.

I do remember having a similar issue and working out a solution, but it was quite a while ago. I'll take a look at some code on Monday.
On Sat, Jan 10, 2009 at 3:42 AM, Steven Knudsen <ee.knud@...> wrote:
Hi All,

I am having grief with HTTP 3xx redirects. Basically, I have multiple RSS aggregator clients making feed subscription requests to a RSS aggregator server. The server keeps track of requests/requestors, polls feeds periodically, and forwards feed events to the requestors based on their feed subscriptions. Since this is all asynchronous, I use tokens to match requests to event forwards, and part of the token is the original RSS/Atom URL. I need to match the received feed event to the original URL.
ng
Though it may well be possible, I've not figured out how to get the original URL for a feed request when my listener gets a feed retrieved event.

I understand that the original URL is used as an "id" in the SyndFeedInfo, there's no get it back from the feed cache unless you have the original URL (see HttpURLFeedFetcher).

It appears that one would have to modify the HttpURLFeedFetcher, AbstractFeedFetcher, and FetcherEvent to accomplish this. Adding a new URL (maybe String) arg to various methods and adding a new URL (String?) member to FetcherEvent probably does it.

Nick L or anyone else, any comment?

Thanks,

Steven



________________________________________
IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.


IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[eeKnud]

Ah ha!

That's what I thought about the before and after keys.; thought that  
it may well be impossible to retrieve the cache entry. However, I  
never was really strong on HTTP and it's been awhile since I've had to  
care.

BTW, I did add some code to HttpUrlFeedFetcher to give me both the  
original and redirected URLs. If you decide that you'd like that, then  
let me know and I'll make some diffs.

Thanks for considering this question on a Sunday.

steven


On 11-Jan-09, at 5:05 PM, Nick Lothian wrote:

>> So, do you think it might be nice to get both the redirected and  
>> the original URLs for both fetchers?
>
> Yes, I think that would be a good idea.
>
>> Also, did you look at the SyndFeedInfo retrieval question implied  
>> in my analysis below? That is, can one use the event supplied URL  
>> to get the SyndFeedInfo correctly?
>
> I think that will work when using HttpClientFeedFetcher.
>
> I'm not sure about HttpURLFeedFetcher - having a close look at the  
> code, I think that there is a subtle bug when dealing with  
> redirected feeds. The code looks like this:
>
> SyndFeedInfo syndFeedInfo = cache.getFeedInfo(feedUrl);
> setRequestHeaders(connection, syndFeedInfo);
> httpConnection.connect();
> try {
>        fireEvent(FetcherEvent.EVENT_TYPE_FEED_POLLED, connection);
>
>        if (syndFeedInfo == null) {
>                // this is a feed that hasn't been retrieved
>                syndFeedInfo = new SyndFeedInfo();
>                retrieveAndCacheFeed(feedUrl, syndFeedInfo,  
> httpConnection);
>        } else {
>                // check the response code
>                int responseCode = httpConnection.getResponseCode();
>                if (responseCode !=  
> HttpURLConnection.HTTP_NOT_MODIFIED) {
>                        // the response code is not 304 NOT MODIFIED
>                        // This is either because the feed server
>                        // does not support condition gets
>                        // or because the feed hasn't changed
>                        retrieveAndCacheFeed(feedUrl, syndFeedInfo,  
> httpConnection);
>                } else {
>                        // the feed does not need retrieving
>                        
> fireEvent(FetcherEvent.EVENT_TYPE_FEED_UNCHANGED, connection);
>                }
>        }
>
>        return syndFeedInfo.getSyndFeed();
> } finally {
>    httpConnection.disconnect();
> }
>
> To me that looks like the initial lookup in the cache will use the  
> url-prior-to-redirection, and then it will be saved using the url-
> after-redirection. If my analysis is correct it means that  
> redirected feeds won't be cached.
>
> I need to look at that some more - when I get time I'll try and  
> write a test case.
>
> Nick
>
> ----
> From: Steven Knudsen [mailto:ee.knud@...]
> Sent: Monday, 12 January 2009 10:11 AM
> To: dev@...
> Subject: Re: Original URL in FetcherEvent
>
> Thanks, Nick.
>
> I was beginning to suspect that I chose the wrong fetcher, and your  
> analysis/testing seems to show that. Big thanks.
>
> So, do you think it might be nice to get both the redirected and the  
> original URLs for both fetchers? I'm not sure it's the right thing  
> to do, but I would like to try and save the redirect address for my  
> RSS clients under the assumption that when I restore their state at  
> startup, those addresses are "somehow better".
>
> Also, did you look at the SyndFeedInfo retrieval question implied in  
> my analysis below? That is, can one use the event supplied URL to  
> get the SyndFeedInfo correctly?
>
> When I get a chance, I'll look at switching fetchers in my code.
>
> Again, thanks for the really prompt look at this.
>
> steven
>
>
> On 11-Jan-09, at 3:22 PM, Nick Lothian wrote:
>
>
> Yes, that is an accurate summary.
>
>> It may well be that the URL key is changed under the covers to  
>> match the FetcherEvent URL string that is eventually returned. This  
>> wouldn't be the first time that I've missed something in reviewing  
>> code :-)
>
> You haven't missed anything in the code, just a surprising behaviour  
> on the part of java.net.HttpURLConnection.
>
> Basically, unless setInstanceFollowRedirects is set to false, then  
> HttpURLConnection will automatically follow 301 redirect. That is  
> reasonable behaviour.
>
> The surprise is that the url returned by connection.getURL() is now  
> the new, redirected url. I suppose that is also reasonable, but as  
> far as I know it isn't documented anywhere.
>
> Anyway, you can see this behaviour in  
> HttpURLFeedFetcherTest.testRetrieveRedirectedFeed(). The output  
> looks like this:
>
> 08:49:02.040 EVENT  Starting Jetty/4.2.12
> 08:49:02.041 EVENT  Started HttpContext[/rome]
> 08:49:02.050 EVENT  Started SocketListener on 0.0.0.0:8283
> 08:49:02.050 EVENT  Started org.mortbay.http.HttpServer@1292d26
> Could not find fetcher.properties on classpath
>      EVENT: Feed Polled. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE
>      EVENT: Feed Retrieved. URL = http://localhost:8283/rome/FetcherTestServlet2/
> 08:49:02.073 EVENT  Stopping Acceptor  
> ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8283]
> 08:49:02.074 EVENT  Stopped SocketListener on 0.0.0.0:8283
> 08:49:02.074 EVENT  Stopped HttpContext[/rome]
> 08:49:02.074 EVENT  Stopped org.mortbay.http.HttpServer@1292d26
>
> (Note that the "Polled" and "Retrieved" events give different URLs)
>
> However, the good news is that if we run the same test using  
> HttpClientFeedFetcher you get this trace:
>
> 08:50:53.640 EVENT  Starting Jetty/4.2.12
> 08:50:53.640 EVENT  Started HttpContext[/rome]
> 08:50:53.652 EVENT  Started SocketListener on 0.0.0.0:8283
> 08:50:53.652 EVENT  Started org.mortbay.http.HttpServer@765a16
> Could not find fetcher.properties on classpath
>      EVENT: Feed Polled. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE
>      EVENT: Feed Retrieved. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE
> 08:50:53.675 EVENT  Stopping Acceptor  
> ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8283]
> 08:50:53.676 EVENT  Stopped SocketListener on 0.0.0.0:8283
> 08:50:53.676 EVENT  Stopped HttpContext[/rome]
> 08:50:53.676 EVENT  Stopped org.mortbay.http.HttpServer@765a16
>
> I suspect that exactly what you are after, right?
>
> Nick
>
> From: Steven Knudsen [mailto:ee.knud@...]
> Sent: Monday, 12 January 2009 1:19 AM
> To: dev@...
> Subject: Re: Original URL in FetcherEvent
>
> Thanks, Nick.
>
> It may be that I've overlooked something in the code, but as I  
> understand things:
>
> 1. SyndFeedInfo provides <code>public synchronized String getId() </
> code>
> 2. FeedFetcherCache provides <code>public SyndFeedInfo  
> getFeedInfo(URL feedUrl) </code>
> 3. HttpClientFeedFetcher/HttpURLFeedFetcher provide <code>public  
> synchronized FeedFetcherCache getFeedInfoCache() </code>
>
> The use of <code>feedUrl</code> to retrieve the cache is the problem.
>
> I'm using HttpURLFeedFetcher, but I believe the behaviour is the  
> same for either fetcher. AFAIK, when you call <code>retrieveFeed</
> code> the input URL is used as a key for the SyndFeedInfo entry in  
> the cache. It may well be that the URL key is changed under the  
> covers to match the FetcherEvent URL string that is eventually  
> returned. This wouldn't be the first time that I've missed something  
> in reviewing code :-)
>
> As I mentioned, I can't rely on the initially returned feed because  
> I forward FetcherEvents to any and all of my RSS clients when they  
> are received.
>
> Anyway, any light you can shed will be much appreciated!
>
> Best regards,
>
> steven
>
>
> On 10-Jan-09, at 12:54 AM, Nick Lothian wrote:
>
>
>
> I think that the HttpClientFetcher behaves differently here and will  
> give you the original address.
>
> I do remember having a similar issue and working out a solution, but  
> it was quite a while ago. I'll take a look at some code on Monday.
> On Sat, Jan 10, 2009 at 3:42 AM, Steven Knudsen <ee.knud@...>  
> wrote:
> Hi All,
>
> I am having grief with HTTP 3xx redirects. Basically, I have  
> multiple RSS aggregator clients making feed subscription requests to  
> a RSS aggregator server. The server keeps track of requests/
> requestors, polls feeds periodically, and forwards feed events to  
> the requestors based on their feed subscriptions. Since this is all  
> asynchronous, I use tokens to match requests to event forwards, and  
> part of the token is the original RSS/Atom URL. I need to match the  
> received feed event to the original URL.
> ng
> Though it may well be possible, I've not figured out how to get the  
> original URL for a feed request when my listener gets a feed  
> retrieved event.
>
> I understand that the original URL is used as an "id" in the  
> SyndFeedInfo, there's no get it back from the feed cache unless you  
> have the original URL (see HttpURLFeedFetcher).
>
> It appears that one would have to modify the HttpURLFeedFetcher,  
> AbstractFeedFetcher, and FetcherEvent to accomplish this. Adding a  
> new URL (maybe String) arg to various methods and adding a new URL  
> (String?) member to FetcherEvent probably does it.
>
> Nick L or anyone else, any comment?
>
> Thanks,
>
> Steven
>
>
>
> ________________________________________
> IMPORTANT: This e-mail, including any attachments, may contain  
> private or confidential information. If you think you may not be the  
> intended recipient, or if you have received this e-mail in error,  
> please contact the sender immediately and delete all copies of this  
> e-mail. If you are not the intended recipient, you must not  
> reproduce any part of this e-mail or disclose its contents to any  
> other party. This email represents the views of the individual  
> sender, which do not necessarily reflect those of Education.au  
> except where the sender expressly states otherwise. It is your  
> responsibility to scan this email and any files transmitted with it  
> for viruses or any other defects. education.au limited will not be  
> liable for any loss, damage or consequence caused directly or  
> indirectly by this email.
>
>
> IMPORTANT: This e-mail, including any attachments, may contain  
> private or confidential information. If you think you may not be the  
> intended recipient, or if you have received this e-mail in error,  
> please contact the sender immediately and delete all copies of this  
> e-mail. If you are not the intended recipient, you must not  
> reproduce any part of this e-mail or disclose its contents to any  
> other party. This email represents the views of the individual  
> sender, which do not necessarily reflect those of Education.au  
> except where the sender expressly states otherwise. It is your  
> responsibility to scan this email and any files transmitted with it  
> for viruses or any other defects. education.au limited will not be  
> liable for any loss, damage or consequence caused directly or  
> indirectly by this email.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Nick Lothian]

> BTW, I did add some code to HttpUrlFeedFetcher to give me both the
original and redirected URLs. If you decide that you'd like that, then
let me know and I'll make some diffs.

That would be great.

> Thanks for considering this question on a Sunday.

It's Monday here :)


-----Original Message-----
From: Steven Knudsen [mailto:ee.knud@...]
Sent: Monday, 12 January 2009 2:34 PM
To: dev@...
Subject: Re: Original URL in FetcherEvent

Ah ha!

That's what I thought about the before and after keys.; thought that
it may well be impossible to retrieve the cache entry. However, I
never was really strong on HTTP and it's been awhile since I've had to
care.

BTW, I did add some code to HttpUrlFeedFetcher to give me both the
original and redirected URLs. If you decide that you'd like that, then
let me know and I'll make some diffs.

Thanks for considering this question on a Sunday.

steven


On 11-Jan-09, at 5:05 PM, Nick Lothian wrote:

>> So, do you think it might be nice to get both the redirected and
>> the original URLs for both fetchers?
>
> Yes, I think that would be a good idea.
>
>> Also, did you look at the SyndFeedInfo retrieval question implied
>> in my analysis below? That is, can one use the event supplied URL
>> to get the SyndFeedInfo correctly?
>
> I think that will work when using HttpClientFeedFetcher.
>
> I'm not sure about HttpURLFeedFetcher - having a close look at the
> code, I think that there is a subtle bug when dealing with
> redirected feeds. The code looks like this:
>
> SyndFeedInfo syndFeedInfo = cache.getFeedInfo(feedUrl);
> setRequestHeaders(connection, syndFeedInfo);
> httpConnection.connect();
> try {
>        fireEvent(FetcherEvent.EVENT_TYPE_FEED_POLLED, connection);
>
>        if (syndFeedInfo == null) {
>                // this is a feed that hasn't been retrieved
>                syndFeedInfo = new SyndFeedInfo();
>                retrieveAndCacheFeed(feedUrl, syndFeedInfo,
> httpConnection);
>        } else {
>                // check the response code
>                int responseCode = httpConnection.getResponseCode();
>                if (responseCode !=
> HttpURLConnection.HTTP_NOT_MODIFIED) {
>                        // the response code is not 304 NOT MODIFIED
>                        // This is either because the feed server
>                        // does not support condition gets
>                        // or because the feed hasn't changed
>                        retrieveAndCacheFeed(feedUrl, syndFeedInfo,
> httpConnection);
>                } else {
>                        // the feed does not need retrieving
>
> fireEvent(FetcherEvent.EVENT_TYPE_FEED_UNCHANGED, connection);
>                }
>        }
>
>        return syndFeedInfo.getSyndFeed();
> } finally {
>    httpConnection.disconnect();
> }
>
> To me that looks like the initial lookup in the cache will use the
> url-prior-to-redirection, and then it will be saved using the url-
> after-redirection. If my analysis is correct it means that
> redirected feeds won't be cached.
>
> I need to look at that some more - when I get time I'll try and
> write a test case.
>
> Nick
>
> ----
> From: Steven Knudsen [mailto:ee.knud@...]
> Sent: Monday, 12 January 2009 10:11 AM
> To: dev@...
> Subject: Re: Original URL in FetcherEvent
>
> Thanks, Nick.
>
> I was beginning to suspect that I chose the wrong fetcher, and your
> analysis/testing seems to show that. Big thanks.
>
> So, do you think it might be nice to get both the redirected and the
> original URLs for both fetchers? I'm not sure it's the right thing
> to do, but I would like to try and save the redirect address for my
> RSS clients under the assumption that when I restore their state at
> startup, those addresses are "somehow better".
>
> Also, did you look at the SyndFeedInfo retrieval question implied in
> my analysis below? That is, can one use the event supplied URL to
> get the SyndFeedInfo correctly?
>
> When I get a chance, I'll look at switching fetchers in my code.
>
> Again, thanks for the really prompt look at this.
>
> steven
>
>
> On 11-Jan-09, at 3:22 PM, Nick Lothian wrote:
>
>
> Yes, that is an accurate summary.
>
>> It may well be that the URL key is changed under the covers to
>> match the FetcherEvent URL string that is eventually returned. This
>> wouldn't be the first time that I've missed something in reviewing
>> code :-)
>
> You haven't missed anything in the code, just a surprising behaviour
> on the part of java.net.HttpURLConnection.
>
> Basically, unless setInstanceFollowRedirects is set to false, then
> HttpURLConnection will automatically follow 301 redirect. That is
> reasonable behaviour.
>
> The surprise is that the url returned by connection.getURL() is now
> the new, redirected url. I suppose that is also reasonable, but as
> far as I know it isn't documented anywhere.
>
> Anyway, you can see this behaviour in
> HttpURLFeedFetcherTest.testRetrieveRedirectedFeed(). The output
> looks like this:
>
> 08:49:02.040 EVENT  Starting Jetty/4.2.12
> 08:49:02.041 EVENT  Started HttpContext[/rome]
> 08:49:02.050 EVENT  Started SocketListener on 0.0.0.0:8283
> 08:49:02.050 EVENT  Started org.mortbay.http.HttpServer@1292d26
> Could not find fetcher.properties on classpath
>      EVENT: Feed Polled. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE
>      EVENT: Feed Retrieved. URL = http://localhost:8283/rome/FetcherTestServlet2/
> 08:49:02.073 EVENT  Stopping Acceptor
> ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8283]
> 08:49:02.074 EVENT  Stopped SocketListener on 0.0.0.0:8283
> 08:49:02.074 EVENT  Stopped HttpContext[/rome]
> 08:49:02.074 EVENT  Stopped org.mortbay.http.HttpServer@1292d26
>
> (Note that the "Polled" and "Retrieved" events give different URLs)
>
> However, the good news is that if we run the same test using
> HttpClientFeedFetcher you get this trace:
>
> 08:50:53.640 EVENT  Starting Jetty/4.2.12
> 08:50:53.640 EVENT  Started HttpContext[/rome]
> 08:50:53.652 EVENT  Started SocketListener on 0.0.0.0:8283
> 08:50:53.652 EVENT  Started org.mortbay.http.HttpServer@765a16
> Could not find fetcher.properties on classpath
>      EVENT: Feed Polled. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE
>      EVENT: Feed Retrieved. URL = http://localhost:8283/rome/FetcherTestServlet?redirect=TRUE
> 08:50:53.675 EVENT  Stopping Acceptor
> ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8283]
> 08:50:53.676 EVENT  Stopped SocketListener on 0.0.0.0:8283
> 08:50:53.676 EVENT  Stopped HttpContext[/rome]
> 08:50:53.676 EVENT  Stopped org.mortbay.http.HttpServer@765a16
>
> I suspect that exactly what you are after, right?
>
> Nick
>
> From: Steven Knudsen [mailto:ee.knud@...]
> Sent: Monday, 12 January 2009 1:19 AM
> To: dev@...
> Subject: Re: Original URL in FetcherEvent
>
> Thanks, Nick.
>
> It may be that I've overlooked something in the code, but as I
> understand things:
>
> 1. SyndFeedInfo provides <code>public synchronized String getId() </
> code>
> 2. FeedFetcherCache provides <code>public SyndFeedInfo
> getFeedInfo(URL feedUrl) </code>
> 3. HttpClientFeedFetcher/HttpURLFeedFetcher provide <code>public
> synchronized FeedFetcherCache getFeedInfoCache() </code>
>
> The use of <code>feedUrl</code> to retrieve the cache is the problem.
>
> I'm using HttpURLFeedFetcher, but I believe the behaviour is the
> same for either fetcher. AFAIK, when you call <code>retrieveFeed</
> code> the input URL is used as a key for the SyndFeedInfo entry in
> the cache. It may well be that the URL key is changed under the
> covers to match the FetcherEvent URL string that is eventually
> returned. This wouldn't be the first time that I've missed something
> in reviewing code :-)
>
> As I mentioned, I can't rely on the initially returned feed because
> I forward FetcherEvents to any and all of my RSS clients when they
> are received.
>
> Anyway, any light you can shed will be much appreciated!
>
> Best regards,
>
> steven
>
>
> On 10-Jan-09, at 12:54 AM, Nick Lothian wrote:
>
>
>
> I think that the HttpClientFetcher behaves differently here and will
> give you the original address.
>
> I do remember having a similar issue and working out a solution, but
> it was quite a while ago. I'll take a look at some code on Monday.
> On Sat, Jan 10, 2009 at 3:42 AM, Steven Knudsen <ee.knud@...>
> wrote:
> Hi All,
>
> I am having grief with HTTP 3xx redirects. Basically, I have
> multiple RSS aggregator clients making feed subscription requests to
> a RSS aggregator server. The server keeps track of requests/
> requestors, polls feeds periodically, and forwards feed events to
> the requestors based on their feed subscriptions. Since this is all
> asynchronous, I use tokens to match requests to event forwards, and
> part of the token is the original RSS/Atom URL. I need to match the
> received feed event to the original URL.
> ng
> Though it may well be possible, I've not figured out how to get the
> original URL for a feed request when my listener gets a feed
> retrieved event.
>
> I understand that the original URL is used as an "id" in the
> SyndFeedInfo, there's no get it back from the feed cache unless you
> have the original URL (see HttpURLFeedFetcher).
>
> It appears that one would have to modify the HttpURLFeedFetcher,
> AbstractFeedFetcher, and FetcherEvent to accomplish this. Adding a
> new URL (maybe String) arg to various methods and adding a new URL
> (String?) member to FetcherEvent probably does it.
>
> Nick L or anyone else, any comment?
>
> Thanks,
>
> Steven
>
>
>
> ________________________________________
> IMPORTANT: This e-mail, including any attachments, may contain
> private or confidential information. If you think you may not be the
> intended recipient, or if you have received this e-mail in error,
> please contact the sender immediately and delete all copies of this
> e-mail. If you are not the intended recipient, you must not
> reproduce any part of this e-mail or disclose its contents to any
> other party. This email represents the views of the individual
> sender, which do not necessarily reflect those of Education.au
> except where the sender expressly states otherwise. It is your
> responsibility to scan this email and any files transmitted with it
> for viruses or any other defects. education.au limited will not be
> liable for any loss, damage or consequence caused directly or
> indirectly by this email.
>
>
> IMPORTANT: This e-mail, including any attachments, may contain
> private or confidential information. If you think you may not be the
> intended recipient, or if you have received this e-mail in error,
> please contact the sender immediately and delete all copies of this
> e-mail. If you are not the intended recipient, you must not
> reproduce any part of this e-mail or disclose its contents to any
> other party. This email represents the views of the individual
> sender, which do not necessarily reflect those of Education.au
> except where the sender expressly states otherwise. It is your
> responsibility to scan this email and any files transmitted with it
> for viruses or any other defects. education.au limited will not be
> liable for any loss, damage or consequence caused directly or
> indirectly by this email.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...