[sakai2-tcc] Annotation based injection within Sakai components

Berg, Alan A.M.Berg at uva.nl
Wed May 16 08:29:10 PDT 2012 

After writing a couple of BasicLTI tools. I would agree with mostly with Aarons assessment. I also think tool building in Sakai CLE is doable and even at times great fun. In a wider Universe both live happily.

Regards,

Alan

Alan Berg

Group Education and Research Services
Central Computer Services
University of Amsterdam

________________________________________
From: sakai2-tcc-bounces at collab.sakaiproject.org [sakai2-tcc-bounces at collab.sakaiproject.org] on behalf of Aaron Zeckoski [azeckoski at unicon.net]
Sent: 16 May 2012 17:25
To: John Bush
Cc: sakai2-tcc Committee
Subject: Re: [sakai2-tcc] Annotation based injection within Sakai components

Interesting way of using LTI. Losing the general compatibility seems
like it eliminates a lot of the value proposition to me.

I guess I am pretty used to Sakai development so I don't find it takes
me very long to make a new tool (using Spring MVC for example) and
then I don't have to hope that all the webservices I need are there
(or have to incur the performance penalty).

-AZ


On Wed, May 16, 2012 at 10:56 AM, John Bush <john.bush at rsmart.com> wrote:
> well that hasn't been my experience, LTI + soap calls/rest calls.  You
> can do just about anything.  Yes those calls bind you to a specific
> LMS, but the speed at which you can develop, and the operational
> gains,  make it worth that price, imho.
>
> On Wed, May 16, 2012 at 7:32 AM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>> I can't see why anyone would even want to build a new tool in sakai at
>>> this point, at least if you believe OAE will get off the ground at
>>> some point.  LTI makes much more sense, since anything you do there
>>> can run in OAE when its ready.
>>
>> Mostly because LTI is extremely limited in what it can do (especially
>> in terms of manipulating or accessing service data in the LMS). For
>> simple stuff or things which are loosely coupled to the LMS, LTI makes
>> a lot of sense, but often it just isn't powerful or flexible enough.
>>
>> I am going to avoid commenting on any sort of belief in OAE or
>> prognosticating about when it might be feature equivalent with CLE or
>> even basic LMS functionality.... but I think that we can safely say it
>> won't be soon.
>>
>> -AZ
>>
>>
>>
>> On Wed, May 16, 2012 at 10:22 AM, John Bush <john.bush at rsmart.com> wrote:
>>> well right.  I guess what I'm saying is a reaction to matthews email.
>>> Little incremental changes like moving to this version of spring or
>>> that version of whatever aren't any sort of game changer for Sakai,
>>> they aren't going to solve the fundmental problems.  So if those
>>> incremental changes lead to a bunch of problems for no real gain, I
>>> don't see the point, it seems like a giant waste of effort.
>>>
>>> The fact that its a giant pain in the ass to do Sakai development
>>> isn't going to be solved by these little things.  Its still going to
>>> be a giant pain in the ass.  Maybe a little better, but still way too
>>> hard.
>>>
>>> I can't see why anyone would even want to build a new tool in sakai at
>>> this point, at least if you believe OAE will get off the ground at
>>> some point.  LTI makes much more sense, since anything you do there
>>> can run in OAE when its ready.
>>>
>>> That said I don't object to a kernel 2.0, it can go off and do its own
>>> little thing.  But I'm very doubtful that it would have much adoption
>>> at this point, outside of a few places, so in reality I'm not worried
>>> about it breaking anything, because I don't think anyone will even use
>>> it.
>>>
>>> On Wed, May 16, 2012 at 3:26 AM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>>> Just FYI that the idea of having reloadable services was one of the
>>>> first ideas that lead to the development of OAE (or K2 as it was known
>>>> as back then).
>>>>
>>>> If we really wanted something like that it would mean using spring
>>>> dynamic modules or some other OSGi framework.
>>>> http://www.springsource.org/osgi
>>>>
>>>> You can get reloadable services without that but it involves a LOT of
>>>> manual effort.
>>>>
>>>> I'm not sure anyone is ready to refactor the sakai kernel to use OSGi
>>>> (Spring DM or other). That effort would be massive.
>>>>
>>>> -AZ
>>>>
>>>>
>>>> On Wed, May 16, 2012 at 1:10 AM, John Bush <john.bush at rsmart.com> wrote:
>>>>> I've worked on a few projects recently: oae, spring3, and tapestry
>>>>> that do injection without xml, and I have to say I do not miss xml.  I
>>>>> think if we go this route we'd want to be able to support annotations
>>>>> or xml wiring which I think spring can do.  The idea of a giant
>>>>> refactoring effort or breaking existing tools does not appeal to me.
>>>>> The ability for folks to innovate at a faster pace does appeal to me.
>>>>> So I'm for solutions that allow us to move out of 2005 with minimal
>>>>> pain for the legacy code.
>>>>>
>>>>> I don't see injection configuration as the big road block right now,
>>>>> its the lack of runtime configurability and hot swapping components
>>>>> that slow me down more than anything, and the technology soup issue
>>>>> Matthew brought up.  Now if kernel 2.0 was going to start tackling
>>>>> those types of issues I'd get interested.
>>>>>
>>>>> On Tue, May 15, 2012 at 5:31 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>>>>> Depending on how cutting edge spring we are trying to use (i.e. how
>>>>>> much we are willing to break), the XML file is still required. It just
>>>>>> doesn't have to have a bunch of beans defined in it. However, it does
>>>>>> typically still have some tags to tell it to scan for beans in the
>>>>>> classloader.
>>>>>>
>>>>>> Normally, this is done by specifying a domain to scan for like
>>>>>> org.sakaiproject (so anything not using that class path would not be
>>>>>> auto-injected).
>>>>>>
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>> <beans xmlns="http://www.springframework.org/schema/beans"
>>>>>>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>>    xmlns:p="http://www.springframework.org/schema/p"
>>>>>>    xmlns:context="http://www.springframework.org/schema/context"
>>>>>>    xsi:schemaLocation="http://www.springframework.org/schema/beans
>>>>>> http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
>>>>>> http://www.springframework.org/schema/context
>>>>>> http://www.springframework.org/schema/context/spring-context-3.0.xsd">
>>>>>>
>>>>>>    <context:component-scan base-package="org.sakaiproject" />
>>>>>> </beans>
>>>>>>
>>>>>> Either way, most likely we would still require an XML file for every
>>>>>> component so therefore we would be supporting the XML method
>>>>>> intrinsically and optionally also supporting the annotations method
>>>>>> (if the component-scan tag was included in that component).
>>>>>>
>>>>>> -AZ
>>>>>>
>>>>>>
>>>>>> On Tue, May 15, 2012 at 8:14 PM, Steve Swinsburg
>>>>>> <steve.swinsburg at gmail.com> wrote:
>>>>>>> Maybe we should start planning Kernel 2.0 then? The CLE is going to be
>>>>>>> around for quite some time. I'd hate to see us stagnate for the next few
>>>>>>> years.
>>>>>>>
>>>>>>> Would there be a way to support both approaches for dependency injection?
>>>>>>> Then it could be an optional thing that tools can adopt as they move
>>>>>>> forward, and not break everything. Of course it means that tool wouldn't
>>>>>>> work going backwards but in the ideal world, it would still be supported via
>>>>>>> a maintenance branch, as most are now.
>>>>>>>
>>>>>>> cheers,
>>>>>>> Steve
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 16/05/2012, at 9:00 AM, Matthew Jones wrote:
>>>>>>>
>>>>>>> Well the things you mention (api changes) *can* be often easily remedied via
>>>>>>> reflection or wrappers if a tool developer cared about that. Annotations for
>>>>>>> spring however which is in shared mean that we'll either require branches,
>>>>>>> patches or just say "this version doesn't work anymore". That sounds like a
>>>>>>> Kernel 2.0 thing like Dave was talking about if it did happen, because
>>>>>>> almost everyone isn't going to back-port to multiple older versions. We
>>>>>>> can't even support 2.7.x and 2.8.x very well.
>>>>>>>
>>>>>>> I'd argue that coding anything in Java is *so 2005*, and we'd see
>>>>>>> significant developer improvements just rewriting tools in
>>>>>>> jruby/jython/groovy and going forward with that. Even junit tests written in
>>>>>>> java feel like a waste of developer time, and often either eventually break,
>>>>>>> only test the happy path, or and are never fixed because only the original
>>>>>>> author knows what they did (gradebook unit tests?).
>>>>>>>
>>>>>>> A few months ago Noah started some great rspec experiments with gradebook
>>>>>>> and also had some jruby/rails apps that looked pretty easy to deploy against
>>>>>>> the rest of Sakai. These looks incredibly easier to maintain than anything
>>>>>>> currently in the code. If I started a new tool it would have been in this.
>>>>>>> (Or completely external hooked up with LTI)
>>>>>>>
>>>>>>> But I still think we need to weigh every change with it's likely-hood of
>>>>>>> increasing CLE adoption verses discouraging CLE adoption. Also figuring out
>>>>>>> what things at this point are must have and what things are nice.
>>>>>>>
>>>>>>> If the Sakai CLE would have had less ways to do the same thing
>>>>>>> (rsf/velocity/jsf/hibernate/springmvc/wicket/ambrosia/...) then it we'd be
>>>>>>> in a better place right now. :)
>>>>>>>
>>>>>>> I also love Ian Boston's blog post: (emphasis mine)
>>>>>>>
>>>>>>> "Could the same be done in Java?
>>>>>>>
>>>>>>> Probably, but the pace of development would be considerably less (DJango
>>>>>>> development follows a edit-save-refresh pattern and requires far fewer lines
>>>>>>> of code than Java). Also, a mature framework that had solved all the
>>>>>>> problems DJango has addressed would be needed to avoid the curse of all Java
>>>>>>> developers, the temptation to write their own framework."
>>>>>>> - http://blog.tfd.co.uk/2012/04/10/pyoae/
>>>>>>>
>>>>>>> On Tue, May 15, 2012 at 6:29 PM, Steve Swinsburg <steve.swinsburg at gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> There have been previous breaking API changes, specifically when a new
>>>>>>>> class/method is introduced and tools then use it, which mean they cannot be
>>>>>>>> used in older versions.
>>>>>>>>
>>>>>>>> One that comes to mind is the ActivityService API which was added in
>>>>>>>> Kernel 1.2, and Profile2 1.4+ use it, so you cannot use Profile2 1.4 in
>>>>>>>> Sakai 2.7 or previous.[1]
>>>>>>>>
>>>>>>>> I think at some point we need to be able to make choices that move us
>>>>>>>> forward, sometimes at the expense of tool or legacy code that cannot keep
>>>>>>>> up. It would certainly highlight code which is unsupported but just hanging
>>>>>>>> on. So I'd be all for incorporating a number of additional changes as David
>>>>>>>> lists, so that it's all out of the way at once.
>>>>>>>>
>>>>>>>> Making this change would theoretically mean that a tool wouldn't need to
>>>>>>>> worry about XML wiring and they can just get busy writing code. It's a small
>>>>>>>> improvement, but it's really useful. The other benefit is the combination
>>>>>>>> with annotation based autowiring of dependencies in JUnit tests, which I
>>>>>>>> have been unable to get working with a mix of Sakai specific components.xml
>>>>>>>> and annotations. It's either one or the other.
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> Steve
>>>>>>>>
>>>>>>>> p.s. By the way, the lombok thing is easily done, in any layer since it is
>>>>>>>> (mostly) a compile time annotation. I don't even use getters/setters
>>>>>>>> anymore, they are so 2011.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://confluence.sakaiproject.org/display/PROFILE/Profile2+-+Version+Compatibility
>>>>>>>>
>>>>>>>> On 16/05/2012, at 1:56 AM, David Horwitz wrote:
>>>>>>>>
>>>>>>>> > If we are going to make a non-backward compatible kernel (i.e. Kernel
>>>>>>>> > 2.0). We should consider other changes that are queued for this:
>>>>>>>> >
>>>>>>>> > 1) Spring 3
>>>>>>>> > 2) Moving to the tomcat 6/7 classloader layout
>>>>>>>> > 3) Removal of deprecated API methods
>>>>>>>> > 4) anything I missed?
>>>>>>>> >
>>>>>>>> > D
>>>>>>>> >
>>>>>>>> > On 05/15/2012 05:39 PM, John Bush wrote:
>>>>>>>> >> what specifically is going to break backwards compatibility ?
>>>>>>>> >>
>>>>>>>> >> On Mon, May 14, 2012 at 7:17 PM, Steve Swinsburg
>>>>>>>> >> <steve.swinsburg at gmail.com>  wrote:
>>>>>>>> >>> Hi all,
>>>>>>>> >>>
>>>>>>>> >>> I've just filed a feature request for annotation based injection
>>>>>>>> >>> within Sakai components. Currently it is not possible and changes need to be
>>>>>>>> >>> made to the kernel to do this:
>>>>>>>> >>> https://jira.sakaiproject.org/browse/KNL-923
>>>>>>>> >>>
>>>>>>>> >>> In discussions with Aaron, this is a relatively simple job, but will
>>>>>>>> >>> be a backwards incompatible change. I'm interested to know more about this
>>>>>>>> >>> and to get the discussion going.
>>>>>>>> >>>
>>>>>>>> >>> Also interested to know if the incompatibility means that:
>>>>>>>> >>>
>>>>>>>> >>> 1. You won't be able to use a newer kernel in an older version of
>>>>>>>> >>> Sakai (ie you won't be able to use the 1.3 kernel for Sakai 2.9 in Sakai
>>>>>>>> >>> 2.8) - does anyone even do that?
>>>>>>>> >>> 2. Tools won't work.
>>>>>>>> >>>
>>>>>>>> >>> thanks,
>>>>>>>> >>> Steve
>>>>>>>> >>> _______________________________________________
>>>>>>>> >>> sakai2-tcc mailing list
>>>>>>>> >>> sakai2-tcc at collab.sakaiproject.org
>>>>>>>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > sakai2-tcc mailing list
>>>>>>>> > sakai2-tcc at collab.sakaiproject.org
>>>>>>>> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> sakai2-tcc mailing list
>>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sakai2-tcc mailing list
>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>>>> _______________________________________________
>>>>>> sakai2-tcc mailing list
>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> John Bush
>>>>> 602-490-0470
>>>>> _______________________________________________
>>>>> sakai2-tcc mailing list
>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>
>>>>
>>>>
>>>> --
>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>> _______________________________________________
>>>> sakai2-tcc mailing list
>>>> sakai2-tcc at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>
>>>
>>>
>>> --
>>> John Bush
>>> 602-490-0470
>>> _______________________________________________
>>> sakai2-tcc mailing list
>>> sakai2-tcc at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>>
>>
>> --
>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
>
>
> --
> John Bush
> 602-490-0470
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



--
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
_______________________________________________
sakai2-tcc mailing list
sakai2-tcc at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

More information about the sakai2-tcc mailing list