Announcement Announcement Module
Collapse
No announcement yet.
Groovy bean factory? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Groovy bean factory?

    I came accross this http://www.almaer.com/blog/archives/000356.html page. Yesterday I checked out a fresh version of spring and can not see the groovy stuff.

    Where can I find it?

    I have been using Pico for a while and scripting configuration of the container is a great feature in my opinion.

  • #2
    Looks like checking this code in got lost in the shuffle. In an email dated July 30th, Rod said he wanted to check the code into the sandbox, but just wanted to make sure no other developers objected to the fact that groovy.jar would then have to also be checked in.

    I've replied to that email to try to get the code into CVS....

    Comment


    • #3
      Colin,

      The code you are refering to is already in CVS since a couple of weeks. It's in the sandbox though, it's not in the main folder yet..

      Comment


      • #4
        oh, I see ...
        I was not looking inside sandbox directory :o

        Comment


        • #5
          You are right. I got confused since the package name changed since Dion's original post.

          Comment


          • #6
            It's in the sandbox. Look at the sandbox tests for an example. IMO it's pretty cool--you can write any bean in Groovy, configuring it via DI. You can then edit the script and Spring will automatically reload it when it's changed, still honouring references held by any other objects configured by DI.

            If you decide for whatever reason that you want to rewrite your Groovy bean in Java, you can do so and just change the bean definition. Of course your Groovy bean should normally implement one or more interfaces.

            I've also verified that the same approach works for BeanShell, although I haven't checked that in. Most of the Groovy support is generic to any scripting language: bsh support was about 20 lines.

            I agree with Dion that it's a great idea (arguably an emerging best practice) to write web tier controllers in a scripting language. With a proper architecture, they do not contain core business logic.

            It will be released in 1.2.

            This allows Spring beans to be written in Groovy. We are also considering options to allow contexts to be created in Groovy, but there's no code for that yet.

            Rgds
            Rod

            Comment


            • #7
              Hello,

              Any chance the BeanShell code would be checked into the sandbox? I'd love to take a look at that and start playing with it.

              Thank!
              Seth

              Comment


              • #8
                Seth

                I've checked in beanshell support. See the org.springframework.beans.factory.script.bsh package in the sandbox. Comments welcome. The beanshell tests are a bit basic at present--I really should pull out an abstract test suite to share between different scripting languages.

                Both inline scripts (prefixed with inline and resource locations are supported.

                I've also done some refactoring and a package move on the Groovy support. However it's still the same from a user perspective.

                Rgds
                Rod

                Comment


                • #9
                  Thanks Rod!

                  We're starting a new initiative to reduce compilation and deployment time. Anything we can do to reduce starting and restarting Tomcat will be really helpful.

                  I'm going to look at this today. Thanks again!
                  Seth

                  Comment


                  • #10
                    Seth

                    I've just significantly enhanced BeanShell support to allow DI via properties on bsh scripts, and to allow bsh scripts to implement more than one interface. I do the first using CGLIB InterfaceMaker as suggested by Chris Nokleberg in another thread to create a config interface with all setters specified in the bean definition, and the second through a little trickery with Spring AOP introductions.

                    I should have time to check this in tomorrow.

                    Rgds
                    Rod

                    Comment


                    • #11
                      I hate unfinished business, so I've just checked it in...

                      Comment


                      • #12
                        Rod,

                        Can you elaborate on why you describe writing controllers in a scripting language as "an emerging best practice"?

                        I'm intrigued to know the thinking behind this statement.

                        Regards,

                        Stephen Baishya

                        Comment


                        • #13
                          Using a scripting language for controller logic usually leads to an increase in agility. It's faster to make and test changes while developing, and potentially easier to make changes even when the app is put into use. If the app is properly written so that heavy lifting is done by lower layers, the performance implications are not usually much worse than doing the controllers in Java...

                          Comment


                          • #14
                            While I agree that in principle, using a scripting language can be more agile, in practice it might not be.

                            My main concern is that much of the refactoring I do these days is through my IDE (eclipse, in this instance). If I start coding in groovy, for instance, I'll loose all the nice refactoring support that my IDE provides. Some day, of course, I'll be able to refactor my groovy code as easy as my java code.

                            For now, I think keeping everything as Java is still easier. But the ability to change the code without redeploying is a huge benefit.

                            Comment


                            • #15
                              But if, as Colin says, the "heavy lifting is done by lower layers", would you be needing to change controllers that often anyway, particularly if the controller is only dealing with some kind of facade object?

                              Comment

                              Working...
                              X