[Building Sakai] Events
Noah Botimer
botimer at umich.edu
Thu Feb 25 16:41:48 PST 2010
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"
More information about the sakai-dev
mailing list