[Building Sakai] Events
Adrian Fish
a.fish at lancaster.ac.uk
Thu Feb 25 03:18:32 PST 2010
As a rule I do use injection but it is nice to be able to use the covers
when your working up a prototype. All that XML can be a drag. I've also
got a nagging feeling that the loose coupling that dependency injection
engenders in Sakai is rarely exploited.
I got my events working now, so ta very much.
Cheers,
Adrian.
Aaron Zeckoski 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"
>>
>>
>
>
>
>
--
==================================
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a_fish.vcf
Type: text/x-vcard
Size: 299 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100225/99600b18/attachment.vcf
More information about the sakai-dev
mailing list