[sakai2-tcc] Annotation based injection within Sakai components

Tue May 15 17:00:45 PDT 2012

Wall of text details:

I was originally playing with Selenium tests with Watir (watir-webdriver gem). I drove the tests with RSpec and Cucumber and it was pretty sweet (even if Cucumber was overkill for my need). I also tried straight selenium-webdriver, which uses a slightly different API. They both use the WebDriver stuff underneath, so it's pretty interchangeable. I imagine the first-party stuff will win long-run. Note, there were timing gotchas with our iframes, where I needed some explicit waits that single-page testing doesn't need.

I've also done some more unit/integration test stuff with RSpec straight from Maven with maven-rspec-plugin. Very sweet and allows you to drive your Java code really easily. To be perverse, I used Mockito for the mocks and expectations and it actually worked rather nicely, even as Java-written-in-Ruby. I still want to see how much boilerplate can go away by trying the RSpec mocks/expectations straight away -- I'm very impressed with the Java-Ruby binding/imports, so I'm hopeful here.

As far as wrapping up Rails apps, it was a bit tenuous. Our RequestFilter gives things a small headache. I used jruby-rack, which is quite impressive. It implements the Rack infrastructure on top of the servlet container and is implemented as a filter. I used Warbler to package up WAR files to drop into Tomcat. It gets out of your way and works pretty well, but there were a few snags, namely around the database connection. I was able to expose the Sakai datasource up with JNDI and use the DBI-JDBC bridge (activerecord-jdbc), but the Rails environment was a little flaky. On the plus side, the ComponentManager and service beans work just fine. This is all under active development, so I wouldn't be surprised if the issues are solved. Using Rails or other Rack tools (Padrino, Ramaze, Camping, etc.) is very fast and well supported in JRuby (especially 1.7), but I do think our Tomcat/Spring shenanigans pose a few things to untangle before I'd go full speed ahead (ignoring the issue we already face of so much duplicative library infrastructure in our gazillion WAR files).

Thanks,
-Noah

On May 15, 2012, at 7:00 PM, 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20120515/a49e1383/attachment-0001.html 