[Building Sakai] Events
Steve Swinsburg
steve.swinsburg at gmail.com
Thu Feb 25 17:01:06 PST 2010
+1 for deprecation of the covers.
When time permits, the webservices will be moved to the ComponentManager approach: http://jira.sakaiproject.org/browse/SAK-16323
cheers,
Steve
On 26/02/2010, at 11:41 AM, Noah Botimer wrote:
> So long as the covers are in the code base, they should be up to date.
>
> We may now consider their use to be a design flaw, but desynchronization is an outright bug.
>
> If it's the right plan, let's deprecate, update, announce, remove. Leaving things broken till disuse is a poor pattern. But let's also remember that contrib tools and web services use them often -- removing in one shot is plainly unfair.
>
> If there is no JIRA ticket for this, there should be. Regenerating a synchronized cover is trivial.
>
> Thanks,
> -Noah
>
> On Feb 25, 2010, at 5:37 AM, Aaron Zeckoski <aaronz at vt.edu> wrote:
>
>> Steve is right, you should either use the spring injection:
>> <bean id="org.sakaiproject.yourapp.logic.YourAppClass"
>> class="org.sakaiproject.yourapp.logic.impl.YourAppClassImpl">
>> <property name="eventTrackingService"
>> ref="org.sakaiproject.event.api.EventTrackingService" />
>> </bean>
>>
>> Or use the ComponentManager methods to get the service.
>> import org.sakaiproject.component.cover.ComponentManager;
>> import org.sakaiproject.event.api.EventTrackingService;
>>
>> EventTrackingService eventTrackingService = (EventTrackingService)
>> ComponentManager.get(EventTrackingService.class.getName());
>>
>> Either way you should not use the service covers for any new code.
>> Hope that helps!
>> -AZ
>>
>>
>> On Thu, Feb 25, 2010 at 10:21 AM, Steve Swinsburg
>> <steve.swinsburg at gmail.com> wrote:
>>> I think the general feeling is that the covers are discouraged in favour of Spring or the ComponentManager so it was probably overlooked when that new method went in. It does make updating older code a pain though since you need to change the entire approach if you can't use the cover...
>>>
>>> cheers,
>>> Steve
>>>
>>>
>>>
>>> On 25/02/2010, at 8:43 PM, Adrian Fish wrote:
>>>
>>>> I'm using the cover and the cover doesn't have the appropriate newEvent method. I need to inject the EventTrackingService.
>>>>
>>>> Shouldn't the EventTrackingService cover be updated though?
>>>>
>>>> Cheers,
>>>>
>>>> Adrian.
>>>>
>>>> Adrian Fish wrote:
>>>>> I've not got that method in my trunk docs. I think I need to update them :(
>>>>>
>>>>> Many thanks,
>>>>>
>>>>> Adrian.
>>>>>
>>>>> Steve Swinsburg wrote:
>>>>>> Ah, I didn't even see that constructor:
>>>>>>
>>>>>>
>>>>>> newEvent
>>>>>>
>>>>>> Event <file:///Users/steve/dev/javadocs/sakai-kernel-api-1.0.14-SNAPSHOT-javadoc/org/sakaiproject/event/api/Event.html> *newEvent*(String <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html> event,
>>>>>> String <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html> resource,
>>>>>> String <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html> context,
>>>>>> boolean modify,
>>>>>> int priority)
>>>>>>
>>>>>> Construct a Event object.
>>>>>>
>>>>>> *Parameters:*
>>>>>> |event| - The Event id.
>>>>>> |resource| - The resource reference.
>>>>>> |context| - The Event's context (may be null).
>>>>>> |modify| - Set to true if this event caused a resource
>>>>>> modification, false if it was just an access.
>>>>>> |priority| - The Event's notification priority. Use
>>>>>> NotificationService.NOTI_OPTIONAL as default.
>>>>>> *Returns:*
>>>>>> A new Event object that can be used with this service.
>>>>>>
>>>>>>
>>>>>> cheers,
>>>>>> Steve
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 25/02/2010, at 4:35 PM, Stephen Marquard wrote:
>>>>>>
>>>>>>> In 2.6+, you can explicitly pass the context when posting the event.
>>>>>>>
>>>>>>> Regards
>>>>>>> Stephen
>>>>>>>
>>>>>>>>>> Steve Swinsburg <steve.swinsburg at gmail.com <mailto:steve.swinsburg at gmail.com>> 2/25/2010 1:12 AM >>>
>>>>>>> Hi Adrian,
>>>>>>>
>>>>>>> It looks like it's set in BaseEvent which implements Event:
>>>>>>>
>>>>>>> kernel-impl/src/main/java/org/sakaiproject/event/impl/BaseEventTrackingService.java
>>>>>>>
>>>>>>> // Find the context using the reference (let the service that it belongs to parse it)
>>>>>>> if (resource != null && !"".equals(resource)) {
>>>>>>> Reference ref = entityManager().newReference(resource);
>>>>>>> if (ref != null) {
>>>>>>> m_context = ref.getContext();
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> // If we still need to find the context, try the tool placement
>>>>>>> if (m_context == null) {
>>>>>>> Placement placement = toolManager().getCurrentPlacement();
>>>>>>> if (placement != null) {
>>>>>>> m_context = placement.getContext();
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> So the context comes from either the entity reference or from the tool placement. I'll take a stab and assume you are working on events for the system wide chat? You probably don't have either so its null and SiteStats can't determine where they came from. Might need to extend Event to take a context parameter in its constructor, or run a regular quartz job over it to fix all of the null context events (any from <2.5 will be null also) so they can be collected in SiteStats.
>>>>>>>
>>>>>>> cheers,
>>>>>>> Steve
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 25/02/2010, at 4:09 AM, Adrian Fish wrote:
>>>>>>>
>>>>>>>> I'm hoping someone can shed some light on a little problem I'm having. The events generated by my tool (snigger) are getting rejected by site stats due to Event.getContext returning null.
>>>>>>>>
>>>>>>>> Does anybody know how the EventTrackingService populates the context field in the Events that it creates?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Adrian.
>>>>>>>>
>>>>>>>> --
>>>>>>>> ==================================
>>>>>>>> Adrian Fish
>>>>>>>> Software Engineer
>>>>>>>> Centre for e-Science
>>>>>>>> Bowland Tower South C Floor
>>>>>>>> Lancaster University
>>>>>>>> Lancaster
>>>>>>>> LA1 4YW
>>>>>>>> email: a.fish at lancaster.ac.uk <mailto:a.fish at lancaster.ac.uk>
>>>>>>>>
>>>>>>>> http://confluence.sakaiproject.org/display/YAFT/Yaft
>>>>>>>> http://confluence.sakaiproject.org/display/BLOG/Home
>>>>>>>> http://confluence.sakaiproject.org/display/AGORA/Home
>>>>>>>>
>>>>>>>> <a_fish.vcf>_______________________________________________
>>>>>>>> sakai-dev mailing list
>>>>>>>> sakai-dev at collab.sakaiproject.org <mailto:sakai-dev at collab.sakaiproject.org>
>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>>>
>>>>>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sakai-dev mailing list
>>>>> sakai-dev at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>
>>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>>
>>>> --
>>>> ==================================
>>>> Adrian Fish
>>>> Software Engineer
>>>> Centre for e-Science
>>>> Bowland Tower South C Floor
>>>> Lancaster University
>>>> Lancaster
>>>> LA1 4YW
>>>> email: a.fish at lancaster.ac.uk
>>>>
>>>> http://confluence.sakaiproject.org/display/YAFT/Yaft
>>>> http://confluence.sakaiproject.org/display/BLOG/Home
>>>> http://confluence.sakaiproject.org/display/AGORA/Home
>>>>
>>>> <a_fish.vcf>
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>
>>
>>
>>
>> --
>> Aaron Zeckoski (azeckoski (at) vt.edu)
>> Senior Research Engineer - CARET - University of Cambridge
>> https://twitter.com/azeckoski - http://www.linkedin.com/in/azeckoski
>> http://aaronz-sakai.blogspot.com/ - http://tinyurl.com/azprofile
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3689 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100226/5aa27711/attachment.bin
More information about the sakai-dev
mailing list