Announcement Announcement Module
Collapse
No announcement yet.
Spring vs. ATG Nucleus Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Well, we did not migrate any application (yet). We just stopped writing more applications on top of the ATG framework.

    Mainly due to the fact that Spring is so much better than the ATG framework for our purpose.

    (Spring is really much better, but honostly the main reason was $$$$ )

    We did migrate some components from ATG nucleus to Spring. For stateless Nucleus components it was quite easy: Replace all the ATG logging with log4j, remove all the exceptions from the startService() method and convert the .properties files into Spring context xml file....

    Comment


    • #32
      The way that I tackled it was in two ways:

      1.) Created a custom Nucleus ConfigurationFinder to support Spring. Nucleus started off using Java as it's configuration mechanism (kind of like what Rod just released, just 9/10 years earlier. I'm not sure if Rod's supports dynamic compilation (ala JSP) of configuration though) and added a PropertyConfigurationFinder later. The idea here is that the custom ConfigurationFinder starts an ApplicationContext with all of your Spring configured beans that are then visible to Nucleus controlled beans (i.e. Say you had a properties file with prop=/spring/based/bean. Nucleus will ask your ConfigurationFinder for a bean named '/spring/based/bean'. I just had all of my Spring based beans be name='/spring/based/bean' so that I could do a simple appContext.containsBeanDefinition(), appContext.getBean(), etc ). To do the reverse (make Nucleus beans visible to Spring beans), I just created a custom FactoryBean that either did a static lookup (Nucleus.resolveName) or if it was in the context of a request base it off of that (i.e request.resolveName). I created a custom xml def (ala Spring 2.0) so that it looks like this:

      <bean name="FooBar" class="Test">
      <property name="foo"><dynamo:resolveName absoluteName="/atg/dynamo/Configuration"/></property>
      </bean>

      This way I could have all of my ATG specific stuff (Droplets, Formhandlers, JHTML, etc) stay under ATG and port the whole 'back end' (Managers/Services, DAOs, etc) to Spring with no impact at all. Hibernate was used as a Repository replacement (JPA would have been nice, but DAS is JDK 1.4.2 only). Then the only thing to do was to create a new 'front end' on top of it (Spring MVC, Tapestry, etc) and cut over.

      2.) Use the PropertyConfigurationFinder to create a Spring xml generator. PropertyConfigurationFinder will take all of your config layers (something that Spring still doesn't have) and provide you with the final bean definition. I just created a generator from there that would take my whole config path and dump it out in the format that Spring expects. From there you can use diff (or even do it in code) to mark the differences between the xml files that you create between stages (DEV, QA, PRODUCTION, etc) and replace them with PropertyFileConfigurers (check the docs closely; the Resources that they draw from can be configured via env settings or jvm (-D) settings (similar to CONFIGPATH). Check out:

      http://forum.springframework.org/showthread.php?t=25677

      Overall, pretty painless (except for creating a new 'front end').

      Comment


      • #33
        ATG's GenericService

        I agree with one poster's comment that ATG's nucleus was ahead of its time. The one issue I've always had with it is that every component had to extend GenericService in order to get configured by the nucleus. This made writing components that could be run on other platforms difficult without wrapping generic implementations in an object that extended this class. This is one clear advantage (IMHO) that Spring has over the ATG approach.

        Comment


        • #34
          I'd like to point out that the comment about GenericService is absolutely incorrect. ATG Nucleus does not require you to subclass any particular class. The GenericService class provides a preconfiguration for a component into other portions of the ATG system. For instance, it automatically hooks into the logging system, no configuration required. It also provides methods for accessing the service's configuration, getting lifecycle event notifications, accessing the name space and for providing custom administrative code for the admin user interfaces in ATG. It is a good idea to extend GenericService if you can. but there is no requirement to do so.

          Additionally, ATG provides an infrastructure called DynamicBeans that I've not seen used anywhere else. This allows classes that do not implement regular bean methods to operate in the ATG system as though they are Beans. For instance, the java.util.HashMap class can be registered as a component in Nucleus and then all keys in the map used as though they are bean attributes. So your JSP code can simply say "/my/path/MyHashMap.someKey" and ATG does the right thing. These DynamicBeans are used extensively in ATG to simplify page coding and rules definitions.

          Comment


          • #35
            Greetings Rod,

            I'm a big fan of Spring and even successful in convincing our client in moving from ATG/Nucleus to JBoss/Spring.

            It would be of great help, if you can pls share your thoughts on,especially how Multi Level Configuration provided by Nucleus is handled in Spring :-) .

            Awaiting your reply.

            Thanks in Advance.

            -SpringAdmirer

            Comment


            • #36
              Relief

              Very happy to see that there's some people out there who're treading the same path that we're considering!

              Our project is using Dynamo 7.1 on top of Websphere and we're looking to migrate to Spring/Hibernate. We only really use the ATG core of Nucleus, Repositories and the jst taglibs - all the other things like DPS, etc are not used (or are used very sparingly). Naturally, it's difficult to justify spending all that money on license fees when there's a lovely OS framework like Spring!

              Having read the other posts in this thread, I can see that others have seen the similarities in the IoC frameworks employed by both ATG and Spring and it's one of the key draws for us. The similarity between Repositories and Hibernate is another.

              However, we're obviously coming to this at quite a late point compared to some and I was wondering if there are any more opinions or bits of advice people have regarding this migration?

              We're looking at several ideas for making the migration easier;
              - writing a script for converting our properties files to Spring XML configuration files
              - writing a script for converting Repository XML def files to Hibernate XML
              - Using JST taglibs with Spring - has anyone tried this?
              - creating a wrapper for our Repository code that allows it to talk to Hibernate

              I know that these are all issues that others have addressed in the past so it would be very interesting to hear of your experiences.

              Finally, thanks to anyone who takes the time to read this and especially those who respond!

              Cheers
              Sharpy

              Comment


              • #37
                - writing a script for converting our properties files to Spring XML configuration files
                Whatever do, you should consider writing common configuration constants to a properly file as well and use a PropertyPlaceHolderConfigurer to inject the properties into your XML. Mixing properties with object hierarchy can make changing those values harder. Especially if those values change between environments.

                Comment


                • #38
                  joe plet,

                  stop polluting this forum with irrelevant posts and ignorant "infomercials." Seriously. At the very least, read the thread you are posting in - before you post! This is not what the thread was about. Plus, it is almost 4 years old! And your comparison of Spring to... Shine and JSF just gives me the creeps...

                  Thank you.

                  Comment


                  • #39
                    ofcource!

                    you're right! Shine is really a dream!

                    It is really powerful & simple!

                    it has whatever a developer need to!

                    I find to picture about JWMS architecture!

                    JWMS:
                    http://j2sos.org/pics/jwms.JPG
                    Example:
                    http://j2sos.org/pic/soa.JPG
                    Last edited by Artmis; Dec 17th, 2008, 03:24 PM.

                    Comment


                    • #40
                      Originally posted by constv View Post
                      joe plet,

                      stop polluting this forum with irrelevant posts and ignorant "infomercials." Seriously. At the very least, read the thread you are posting in - before you post! This is not what the thread was about. Plus, it is almost 4 years old! And your comparison of Spring to... Shine and JSF just gives me the creeps...

                      Thank you.
                      hi constv!

                      your post give me the creeps more!

                      Shine is really powerful and you cant deny it swimmingly!

                      test it one time then deny it, my friend!

                      Comment

                      Working...
                      X