[sakai2-tcc] Annotation based injection within Sakai components

Wed May 16 07:32:10 PDT 2012

> 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