Announcement Announcement Module
Collapse
No announcement yet.
Trying out a new route... Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Trying out a new route...

    As you've all noticed, there hasn't been a lot of movement in the Spring RCP codebase lately. But that doesn't mean we've been sitting on our butts (at least I haven't ).

    There have been some things we were planning on changing in the current codebase, but the changes were of such magnitude, it would mean we'd have to rethink the entire system. Which I did.

    I started with the existing codebase from the ground up (starting point was the ApplicationLauncher), changing the parts I wanted to change for a while now. Things like the Application.getInstance(), the service accessor pattern (ApplicationServices.getInstance()...) and the complexity of the configuration when starting an RCP application. And off course the fact that it had to be Spring 3. Wherever I could, I also adapted some of Bluebell's features, as some of them were quite nice (the OverlayService concept is a nice one).

    The result came out quite nice (it only took me about a week) and now most of the core codebase has been ported (except for some non-urgent components, but those will be ported shortly). The simple sample works perfectly. Other samples will follow shortly.

    The code is currently under the codename Valkyrie and is found on Gitorious (www.gitorious.org/valkyrie-rcp). Valkyrie is completely operational, but still lacks some critical elements in order to use it in production (unit tests being the most important one, I didn't make time to port those as well). Which brings up the question what to do next... As I see it, we have multiple options: we can port Valkyrie to Spring RCP (in effect, creating a 2.0 version, as this'll break about every RCP code out there) or let Valkyrie live on as a project on it's own (perhaps merging it with Bluebell?). In that case there the second question: what to do with Spring RCP?

    Suggestions, ideas, comments?

  • #2
    It sounds interesting. Just how dramatically different is it from current RCP code?

    i.e. if we declare Valkyrie as 2.0, how much effort would be involved to actually port older 1.x code to 2.0?

    Comment


    • #3
      Well, for one it uses the annotation-config system in Spring 3.0 in order to facilitate easier config through inheritance and overrides, and uses AOP compile-time weaving for Spring configuration of non-container managed beans, which in RCP tend to pop up easily (like programmatically created commands).
      Normally views, binders and such shouldn't take too much effort in porting, but like I said, some things are gone, like the Application singleton, the ApplicationServices locator (now services are just injected using @Autowired or are already available as injected objects on superclasses), RCPSupport is gone (again, you can use injected services now).
      The simple sample was quite easy to port, most of the issues were due to the use of the RCPSupport class. Most of the effort goes into setting up the @Configuration classes.
      And then there's off course the package name change. I couldn't just use the org.springframework package for something not related to SpringSource .
      I suggest you take a look at the simple sample, it nicely shows the new way of configuring and RCP.

      Comment


      • #4
        It will be a pleasure for me to adapt Bluebell to new Spring 3 approach.

        Please, keep us well informed about new version publishing.

        Lieven, you can contact with me at julio.arguello at gmail dot com.

        Comment


        • #5
          RepaintManager issue

          Lieven, take into account the followin link before integrating Bluebell OverlayService support:
          http://jirabluebell.b2b2000.com/browse/BLUE-50

          Comment


          • #6
            See it, implemented it . I'm on BlueBell trunk

            Comment


            • #7
              And we're off... Most of the functionality has now been ported, next up is pulling some stuff out of the sandbox (some of it already has been) and looking into the integrations with VLDocking and others.
              I'm even kinda surprised... The new version feels quicker.
              My initial goal was no xml configs, but unfortunately, that was a no go. Unless someone can point me on how to map <context:spring-configured/> to an @Configuration class, we're stuck with a little XML. And so that no-one will share my pain, here's a hint: if you're including an @Configuration class into a Spring XML context file and your @Configuration class includes a BeanPostProcessor, don't expect it to work. It won't .
              To end with a positive note, a screenshot attached.

              Comment


              • #8
                So your employing aspectJ weaving, sounds nice.

                I think remaining XML is not a problem, the objetive is to reduce them not to kill them at all.

                One question (may be to soon for it), how do you provide developers the oportunity to inject and employ their own services implementation?

                Comment


                • #9
                  I would've been nice, but it's not that bad, the remaining XML is something like 10 lines long, including a Spring Security AuthenticationManager .

                  Anyway, if you mean by injecting their own services, like a ComponentFactory, ApplicationWindowFactory, PageComponentPaneFactory, ... the answer is yes. You just subclass the default configuration and override the appropriate methods (in this case, componentFactory(), applicationWindowFactory(), pageComponentPaneFactory(), ...). As I said, ApplicationServices.getService(...) is no more, so injecting is used a lot more in Valkyrie (hence the need for the AspectJ weaving for non-Spring managed beans).

                  Comment


                  • #10
                    I suggest you emplying the following approach. Does not need subclassing:
                    - Use @Resource annotation referencing "aliases".
                    - Define "aliases" referencing placeholders.
                    - Define placeholder values into a properties file located inside the jar file.
                    - Define a property placeholder configurer for unless this properties file (aka PPC)
                    - User can override default configuration employing prior PPC's.

                    Comment


                    • #11
                      Julio,

                      I've tried that approach too, but I ended up not choosing it for various reasons:
                      - dependency on "magic" strings (your aliases)
                      - the default implementations would still get loaded even if you provide your own implementation, which means a larger memory footprint (could be mediated with lazy beans, but still something to be avoided).
                      - it just ended up more difficult than the current solution (now you have type safety, something you don't have when using property file based injection with aliases, and something I find quite important)

                      Also, the only reason why I'd use a property file for certain things, is for those things I expect to change in production environments. As far as I know, being able to switch implementations of services while in production isn't a good practice. Which implementations you inject just isn't something you should be able to configure and change at runtime.
                      Perhaps a couple percent of the applications out there may need a functionality like this, but that doesn't justify the potential increased complexity.

                      Comment


                      • #12
                        Thanks indeed for you response.

                        IMHO:
                        1. Magic string
                          - dependency on "magic" strings (your aliases)
                          It is not really a pitfall, anyway you can access al declared services at a single point. It's just a question of convention CoC
                        1. Overriden implementations
                          the default implementations would still get loaded even if you provide your own implementation
                          It sounds good but I don't know how to avoid loading overriden implementations. May be I need to learn more about Spring 3 (annotations support).
                        1. Type safety
                          it just ended up more difficult than the current solution
                          I agree with you.

                        Comment


                        • #13
                          Build errors

                          Hi Lieven,

                          Many thanks for working on the project again. I've pulled the code from the repo and had to manually remove 2 imports to get it run (after importing the jide-oss to my repo).
                          Is there any location (JIRA ?) set up where we can provide patches?

                          Cheers
                          Andi

                          Comment


                          • #14
                            When pulling the main trunk from the repository and trying to build I also had trouble building it. Only 2 issues though, one bad jar version.

                            --- aspectj-maven-plugin:1.3:compile (default) @ valkyrie-rcp-core ---
                            [WARNING] bad version number found in <my base dir>\.m2\repository\org\aspectj\aspectjrt\1.6.8\as pectjrt-1.6.8.jar expected 1.6.7 found 1.6.8
                            [WARNING] advice defined in org.springframework.orm.jpa.aspectj.JpaExceptionTr anslatorAspect has not been applied [Xlint:adviceDidNotMatch]
                            ... some more warnings like this one ...


                            and the missing jides-oss stuff. According to https://jide-oss.dev.java.net/ at the bottom of the page under the Maven Repository section is mentions specifying the repository in the pom. I'm don't use maven much, so it looks like the pom should have something like this in it to access the jides-oss jar.

                            <repositories>
                            <repository>
                            <id>maven2-repository.dev.java.net</id>
                            <name>Java.net Repository for Maven</name>
                            <url>http://download.java.net/maven/2/</url>
                            <layout>default</layout>
                            </repository>
                            </repositories>

                            But I'm not sure where to put it. I tried putting it in the top level Valkyrie pom, and it compiles, but it complains something about a 'system' scoped dependency being found. And if I put it in the Valkyrie Jide OSS integration pom it downloads the jar, but then complains about a 'system' scope dependency not being found. So *shrug*.

                            As for the BlueBell OverlayService and its custom RepaintManager, here is another way you can get the same effect without providing a custom RepaintManager or GlassPane. I tend to favor JXLayer whenever I am tempted to use glass panes or repaint managers, as those are problematic if for some reason an application is using its own custom implementation of one of those.

                            http://free-the-pixel.blogspot.com/2...-overlays.html

                            Comment


                            • #15
                              Unfortunately the latest version of jide-oss is not in the repo you specified (just up to 2.10.2). But you can either download the newest version of jide-oss and put it into your local repo or change the version that is used to 2.10.2 (hoping that nothing was fixed since this version that is needed).

                              Comment

                              Working...
                              X