|
Rome Fetcher - FetcherEventListener issue
Some parts of this message have been removed.
Learn more about Nabble's security policy.
While I was playing with Rome Fetcher using BSF4REXX, the developer (Rony Flatcher) of BSF4REXX discovered a problem with Fetcher.
Because BSF uses the java.beans.Introspector, the method name FetcherEventListener should be changed to FetcherListener as otherwise the java.beans.Introspector is not able to infer events.
Rony did complete the changes including preparing the diffs. However, as I am new to open source development and in particular to java.net, I am not sure what procedures I need to follow to submit the zip file with the new sources including the diffs.
Thanks for any help you could provide.
Rae
p.s. I am attaching the zip file for review just in case. ---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
RE: Rome Fetcher - FetcherEventListener issue
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Thanks for this report. I’m a little concerned that changing the name of an interface may cause problems for people who have coded against it.
Do you have any details of the algorithm java.beans.Introspector uses to infer events? I’m not overly familiar with the java beans event model.
Would it be possible to create a BeanInfoClass to do a similar thing?
Nick
From: Rae Egli [mailto:regli@...]
Sent: Monday, 23 June 2008 1:25 PM
To: dev@...
Subject: Rome Fetcher - FetcherEventListener issue
While I was playing with
Rome Fetcher using BSF4REXX, the developer (Rony Flatcher) of BSF4REXX discovered a problem with Fetcher.
Because BSF uses the java.beans.Introspector, the method name FetcherEventListener should be changed to FetcherListener as otherwise the java.beans.Introspector is not able
to infer events.
Rony did complete the changes including preparing the diffs. However, as I am new to open source development and in particular to
java.net, I am not sure what procedures I need to follow to submit the zip file with the new sources including the diffs.
Thanks for any help you could provide.
p.s. I am attaching the zip file for review just in case.
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 limited 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.
|
|
 Re: Rome Fetcher - FetcherEventListener issue
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I am forwarding the full message from Rony which addresses the issue quite nicely IMO.
Rae
----- Forwarded Message ---- From: Rony G. Flatscher < Rony.Flatscher@...> To: Rae Egli < regli@...> Sent: Monday, June 23, 2008 7:29:37 AM Subject: Re: Fw: Rome Fetcher - FetcherEventListener issue Hi Rae, please see comments inline. Rae Egli wrote:
Could you comment on this?
----- Forwarded Message ---- From: Nick Lothian nlothian@...To: dev@... dev@...Sent: Sunday, June 22, 2008 9:32:28 PM Subject: RE: Rome Fetcher - FetcherEventListener issue
Thanks for this report. I’m a little concerned that changing the name of an interface may cause problems for people who have coded against it. In general this is true (it's quite a drawback for using interfaces, unfortunately; this area is a case where multiple inheritance would solve the problem quite elegantly, would Java introduce this concept). However, one could still deprecate that particular interface (and let it stay to be usable for the existing code-base), but define a new one that gets used in new implementations. Not nice, but feasible (that's why the deprecate attribute exists). --- If he wants to leave everything in place, but make the "java.beans.Introspector" work, then only the following two methods need to be *added* to the "com.sun.syndication.fetcher.impl.AbstractFeedFetcher.java"
class: ------------------ cut here -----------------
/**
* @see com.sun.syndication.fetcher.FeedFetcher#addFetcherEventListener(com.sun.syndication.fetcher.FetcherListener)
*/
public void addFetcherListener(FetcherListener listener) {
if (listener != null) {
fetcherEventListeners.add(listener);
}
}
/**
* @see com.sun.syndication.fetcher.FeedFetcher#removeFetcherEventListener(com.sun.syndication.fetcher.FetcherListener)
*/
public void removeFetcherListener(FetcherListener listener) {
if (listener != null) {
fetcherEventListeners.remove(listener);
}
}
------------------ cut here -----------------That's all. [But of course creating distinct event methods for a new FetcherListener2 interface would be much more elegant and robust.]
Do you have any details of the algorithm java.beans.Introspector uses to infer events? I’m not overly familiar with the java beans event model. Sun has quite a few tutorials and articles on the JavaBeans architecture (a strategic part of the class library!) in which he should find plenty of information.
Would it be possible to create a BeanInfoClass to do a similar thing? Unfortunately, this would not be an option for any of the existing libraries that employ the Introspector. HTH, ---rony P.S.: The above suggestion has been tested and works with the BSF4Rexx script.
|
|
RE: Rome Fetcher - FetcherEventListener issue
Some parts of this message have been removed.
Learn more about Nabble's security policy.
>>Do you have any details of the algorithm java.beans.Introspector uses to infer events? I’m not overly familiar with the java beans event
model.
>Sun has quite a few tutorials and articles on the JavaBeans architecture (a strategic part of the class library!) in which he should find plenty of information.
Mmm.
>>Would it be possible to create a BeanInfoClass to do a similar thing?
>Unfortunately, this would not be an option for any of the existing libraries that employ the Introspector.
Could you elaborate on the reasons why this is?
The BeanInfo class (http://java.sun.com/j2se/1.5.0/docs/api/java/beans/BeanInfo.html)
has a method called getEventSetDescriptors() (http://java.sun.com/j2se/1.5.0/docs/api/java/beans/BeanInfo.html#getEventSetDescriptors())
It would seem to me that this should do exactly what is required. To quote the Javadoc “An array of EventSetDescriptors
describing the kinds of events fired by this bean. May return null if the information should be obtained by automatic analysis.”
Nick
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 limited 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.
|
|
RE: Rome Fetcher - FetcherEventListener issue
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Replying to
dev@... – I’d prefer to keep this conversation on the list.
Perhaps I don’t understand something. If put the attached BeanInfo class in the classpath then the following code works:
BeanInfo beanInfo = Introspector.getBeanInfo(HttpURLFeedFetcher.class);
EventSetDescriptor[]
ests = beanInfo.getEventSetDescriptors();
System.out.println(ests[0].getName());
(Will print out “fetcherEvent”).
Now this isn’t a complete solution (I’d like it to work for all possible FeedFetcher implementations), but to me it does appear to solve your problem.
“Just to make it very clear: currently, the problem with ROME-fetcher occurs employing Java's own (!) introspection facility java.beans.Introspector),
it is therefore a ROME-fetcher problem!”
Won’t this approach solve the problem?
Nick
From: Rae Egli [mailto:regli@...]
Sent: Thursday, 26 June 2008 12:55 AM
To: Nick Lothian
Subject: Rome Fetcher - FetcherEventListener issue
Here is Rony's response to your query.
----- Forwarded Message ----
From: Rony G. Flatscher <Rony.Flatscher@...>
To: Rae Egli <regli@...>
Sent: Wednesday, June 25, 2008 12:47:16 AM
Subject: Re: Fw: Rome Fetcher - FetcherEventListener issue
Hi Rae,
just forwarded from
dev@.... Could you respond again, please?
Sure, please see inline comments.
----- Forwarded Message ----
From: Nick Lothian nlothian@...
To: dev@...
dev@...
Sent: Tuesday, June 24, 2008 5:58:11 PM
Subject: RE: Rome Fetcher - FetcherEventListener issue
>>Do you have any details of the algorithm java.beans.Introspector uses to infer events? I’m not overly familiar with the java beans event model.
>Sun has quite a few tutorials and articles on the JavaBeans architecture (a strategic part of the class library!) in which he should find plenty of information.
Mmm.
Well, given the fundamental nature of JavaBeans and Java events I feel that one would "stumble" over what constitutes the Java event pattern, if one starts to read/research into this corner.
As I have already elaborated, this is the simple pattern to Java events, which among others BeanInfo looks for:
add<EVENT_SET_NAME>Listener (<EVENT_SET_NAME>Listener l)
remove<EVENT_SET_NAME>Listener (<EVENT_SET_NAME>Listener l)
get<EVENT_SET_NAME>Listeners ()
where the interface "<EVENT_SET_NAME>Listener" defines the event methods, which usually expect one argument only, namely one of type "<EVENT_SET_NAME>Event".
BTW, the get-method is missing from ROME-fetcher (however, it is not mandatory for Java introspection to find the event pattern).
BeanInfo is *not* a class, but an interface!
As mentioned in an earlier remark, the "java.beans.Introspector" class is used to carry out the analysis (this is the standard Java means to employ Java introspection). Its method "getBeanInfo(...)" returns an object implementing the BeanInfo interface, and
it is in that method's "getEventSetDescriptors()" which will not be able to identify and return any ROME-fetcher event set information.
The reason for this is, that the ROME-fetcher package does not follow the above, simple pattern. (I assume that it was an oversight by the original implementor. At least the "add<EVENT_SET_NAME>Listener(...)" and "remove<EVENT_SET_NAME>Listener(...)" methods
need to be present.)
Here is the link to the Introspector's 1.5 Java docs (using your URL as a starting point):
<http://java.sun.com/j2se/1.5.0/docs/api/java/beans/Introspector.html>, and there you see the method getBeanInfo(...), which then links to the BeanInfo interface description, arriving at the link that you have supplied above.
---
So the situation at present is, that, unfortunately, the ROME-fetcher event is *not* introspectable by the standard Java introspection means! This is not the fault of the implementation of the Java introspection mechanism (it works for practically all other
class libraries).
There are two possible solutions for ROME-fetcher, which would not break existing programs:
-
supply the two (according to the event pattern) missing methods in the AbstractFeedFetcher, or
-
deprecate "FeedFetcher", define a new interface "FeedFetcher2" with the correctly named add/remove methods and supply an implementation of it (e.g. as a class "AbstractFeedFetcher2").
-
and while being there, please consider to redefine the "FeedListener" to explicitly list event methods for each of the three events that you have defined for it (e.g. "polled", "retrieved", "unchanged"). It makes coding much easier, if one is not forced by
default to get at the event object and analyze it (this should be only necessary for special needs; in your case the URL is known already outside of the event, such that a normal program is not dependent on that information from the event object; OTOH, for
reflection/introspection kind of analysis software, that piece of information migth be very useful nevertheless)
The second solution would document the problem explicitly, and no coder would mistakingly use the wrong interface definition in the future, yet it would not break existing programs. The naming may be a bit ugly, but then it would resolve
the issue once and forever.
It would seem to me that this should do exactly what is required. To quote the Javadoc “An array of EventSetDescriptors describing the kinds of events fired
by this bean. May return null if the information should be obtained by automatic analysis.”
Just to make it very clear: currently, the problem with ROME-fetcher occurs employing Java's own (!) introspection facility (java.beans.Introspector), it is therefore a ROME-fetcher problem!
If you have any further questions/comments relating to this, then please do not hesitate to come forward with them.
---rony
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 limited 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@...
|
|
FW: Rome Fetcher - FetcherEventListener issue
Some parts of this message have been removed.
Learn more about Nabble's security policy.
From: Rae Egli [mailto:regli@...]
Sent: Friday, 27 June 2008 3:12 AM
To: Nick Lothian
Subject: Rome Fetcher - FetcherEventListener issue
I am forwarding two emails from Rony that might be combined into one for the mailing list.
*---------------------------------------------
* Rae Egli
*
* (760) 684-4650 - regli@...
*---------------------------------------------
----- Forwarded Message ----
From: Rony G. Flatscher <Rony.Flatscher@...>
To: Rae Egli <regli@...>
Sent: Thursday, June 26, 2008 12:45:28 AM
Subject: Re: Rome Fetcher - FetcherEventListener issue
Hi Raetus,
I am forwarding again. :)
:)
See comments inside.
p.s. I do appreciate your efforts in this.
You are very welcome!
Replying to
dev@... – I’d prefer to keep this conversation on the list.
Perhaps I don’t understand something. If put the attached BeanInfo class in the classpath then the following code works:
Ah, this is the third possible solution (which I did not want to suggest as it meant to dig more into the java.beans specs)! Going back to the conversation it was probably me who misunderstood what you were meaning by referring to the BeanInfo
"class".
BeanInfo beanInfo = Introspector.getBeanInfo(HttpURLFeedFetcher.class);
EventSetDescriptor[] ests = beanInfo.getEventSetDescriptors();
System.out.println(ests[0].getName());
(Will print out “fetcherEvent”).
Now this isn’t a complete solution (I’d like it to work for all possible FeedFetcher implementations), but to me it does appear to solve
your problem.
Won’t this approach solve the problem?
Yes, it does!
Regards,
---rony
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 limited 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.
|
|
FW: Rome Fetcher - FetcherEventListener issue
Some parts of this message have been removed.
Learn more about Nabble's security policy.
From: Rae Egli [mailto:raeegli@...]
Sent: Friday, 27 June 2008 3:21 AM
To: Nick Lothian
Subject: Rome Fetcher - FetcherEventListener issue
Yahoo mail gave me some headaches. This is the second message from Rony. It belongs together with the first one.
----- Forwarded Message ----
From: Rony G. Flatscher <Rony.Flatscher@...>
To: Rae Egli <regli@...>
Sent: Thursday, June 26, 2008 1:10:54 AM
Subject: Re: Rome Fetcher - FetcherEventListener issue
Hi Raetus,
just saw, that my remark about the supplied edited version of the BeanInfo class did not make it into my e-mail:
-
Rather than defining the BeanInfo for "HttpURLFeedFetcher", it is probably better to define it for its superclass "AbstractFeedFetcher"; this way all subclasses would get at that information via the Introspector,
-
I changed the syntax to allow the program to be compilable under Java 1.4 (it would only compile from 1.5 onwards), reasoning: most deployed Java-based applications in a commercial environment is on Java 1.4.
Just to make this e-mail "self-contained", I attach the edited version to this e-mail too.
Regards,
---rony
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 limited 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.
package com.sun.syndication.fetcher.impl;
import java.beans.EventSetDescriptor;
import java.beans.IntrospectionException;
import java.beans.SimpleBeanInfo;
import java.lang.reflect.Method;
import com.sun.syndication.fetcher.FetcherEvent;
import com.sun.syndication.fetcher.FetcherListener;
public class AbstractFeedFetcherBeanInfo extends SimpleBeanInfo {
public EventSetDescriptor[] getEventSetDescriptors() {
try {
Class clz=AbstractFeedFetcher.class; // get the class object which we'll describe
Method addMethod = clz.getMethod("addFetcherEventListener", new Class [] {FetcherListener.class} );
Method removeMethod = clz.getMethod("removeFetcherEventListener", new Class [] {FetcherListener.class} );
Method listenerMethod = FetcherListener.class.getMethod("fetcherEvent", new Class [] {FetcherEvent.class} );
EventSetDescriptor est = new EventSetDescriptor("fetcherEvent", clz, new Method[] {listenerMethod}, addMethod, removeMethod);
EventSetDescriptor[] results = new EventSetDescriptor[] {est};
return results;
} catch (IntrospectionException e) {
e.printStackTrace();
return null;
} catch (SecurityException e) {
// TODO Auto-generated catch block
e.printStackTrace();
return null;
} catch (NoSuchMethodException e) {
// TODO Auto-generated catch block
e.printStackTrace();
return null;
}
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
RE: Rome Fetcher - FetcherEventListener issue
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Thanks for this.
I’ll commit this stuff to CVS,
Nick
From: Nick Lothian [mailto:nlothian@...]
Sent: Monday, 30 June 2008 8:29 AM
To: dev@...
Subject: FW: Rome Fetcher - FetcherEventListener issue
From: Rae Egli [mailto:raeegli@...]
Sent: Friday, 27 June 2008 3:21 AM
To: Nick Lothian
Subject: Rome Fetcher - FetcherEventListener issue
Yahoo mail gave me some headaches. This is the second message from Rony. It belongs together with the first one.
----- Forwarded Message ----
From: Rony G. Flatscher <Rony.Flatscher@...>
To: Rae Egli <regli@...>
Sent: Thursday, June 26, 2008 1:10:54 AM
Subject: Re: Rome Fetcher - FetcherEventListener issue
Hi Raetus,
just saw, that my remark about the supplied edited version of the BeanInfo class did not make it into my e-mail:
-
Rather than defining the BeanInfo for "HttpURLFeedFetcher", it is probably better to define it for its superclass "AbstractFeedFetcher"; this way all subclasses would get at that information via the Introspector,
-
I changed the syntax to allow the program to be compilable under Java 1.4 (it would only compile from 1.5 onwards), reasoning: most deployed Java-based applications in a commercial environment is on Java 1.4.
Just to make this e-mail "self-contained", I attach the edited version to this e-mail too.
Regards,
---rony
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 limited 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 limited 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.
|
|
RE: Rome Fetcher - FetcherEventListener issue
Some parts of this message have been removed.
Learn more about Nabble's security policy.
This change is now in CVS, and on the fetcher changelog:
http://wiki.java.net/bin/view/Javawsxml/RomeFetcherChanged#1_BeanInfo_class_added_for_Abstr
Thanks to all involved!
From: Nick Lothian [mailto:nlothian@...]
Sent: Monday, 30 June 2008 9:15 AM
To: dev@...
Subject: RE: Rome Fetcher - FetcherEventListener issue
Thanks for this.
I’ll commit this stuff to CVS,
Nick
From: Nick Lothian [mailto:nlothian@...]
Sent: Monday, 30 June 2008 8:29 AM
To: dev@...
Subject: FW: Rome Fetcher - FetcherEventListener issue
From: Rae Egli [mailto:raeegli@...]
Sent: Friday, 27 June 2008 3:21 AM
To: Nick Lothian
Subject: Rome Fetcher - FetcherEventListener issue
Yahoo mail gave me some headaches. This is the second message from Rony. It belongs together with the first one.
----- Forwarded Message ----
From: Rony G. Flatscher <Rony.Flatscher@...>
To: Rae Egli <regli@...>
Sent: Thursday, June 26, 2008 1:10:54 AM
Subject: Re: Rome Fetcher - FetcherEventListener issue
Hi Raetus,
just saw, that my remark about the supplied edited version of the BeanInfo class did not make it into my e-mail:
-
Rather than defining the BeanInfo for "HttpURLFeedFetcher", it is probably better to define it for its superclass "AbstractFeedFetcher"; this way all subclasses would get at that information via the Introspector,
-
I changed the syntax to allow the program to be compilable under Java 1.4 (it would only compile from 1.5 onwards), reasoning: most deployed Java-based applications in a commercial environment is on Java 1.4.
Just to make this e-mail "self-contained", I attach the edited version to this e-mail too.
Regards,
---rony
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 limited 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 limited 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 limited 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 indirect |
rome-fetcher-0.9rgf-20080621.zip-zip (104K)