[sakai2-tcc] Annotation based injection within Sakai components

Wed May 16 07:56:34 PDT 2012

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