Loading ...
Sorry, an error occurred while loading the content.

J2EEUnit

Expand Messages
  • Vincent Massol
    I am a fan of JUnit ! I have been working with it for some time now and I have come up with an extension of it for testing server-side java code that is called
    Message 1 of 19 , Nov 6, 2000
    View Source
    • 0 Attachment
      I am a fan of JUnit ! I have been working with it for some time now
      and I have come up with an extension of it for testing server-side
      java code that is called either by Servlets or JSP. I thought that
      you could find this of interest ...

      Please have a loot at it at http://sourceforge.net/projects/j2eeunit/
      and tell me what you think

      Thanks.
      Vincent.
    • Erik Meade
      Hi Vincent, I m the only person subscribed to this list other than you. :) I haven t announced it yet, but will soon. How did you find it so fast? I just
      Message 2 of 19 , Nov 6, 2000
      View Source
      • 0 Attachment
        Hi Vincent,

        I'm the only person subscribed to this list other than you. :)
        I haven't announced it yet, but will soon. How did you find it
        so fast? I just created it last night.

        Erik

        > -----Original Message-----
        > From: Vincent Massol [mailto:vmassol@...]
        > Sent: Monday, November 06, 2000 8:11 AM
        > To: junit@egroups.com
        > Subject: [junit] J2EEUnit
        >
        >
        > I am a fan of JUnit ! I have been working with it for some time now
        > and I have come up with an extension of it for testing server-side
        > java code that is called either by Servlets or JSP. I thought that
        > you could find this of interest ...
        >
        > Please have a loot at it at http://sourceforge.net/projects/j2eeunit/
        > and tell me what you think
        >
        > Thanks.
        > Vincent.
        >
        >
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > junit-unsubscribe@egroups.com
        >
        >
      • Jonathan Rasmusson
        Hi Vincent! I am a big fan of JUnit also. I too was once working on a framework much like the one you posted j2eeunit. Them someone showed me HttpUnit (which
        Message 3 of 19 , Nov 10, 2000
        View Source
        • 0 Attachment
          Hi Vincent!

          I am a big fan of JUnit also.

          I too was once working on a framework much like the one you posted
          j2eeunit.

          Them someone showed me HttpUnit (which did was I was already doing but
          in a more fully featured way).

          I have not had a chance to go through all your docs yet but you can
          check out HttpUnit at:

          http://httpunit.sourceforge.net/

          I would very much like to hear your comments on features j2eeunit
          provides vs HttpUnit.

          Have a good weekend.

          Jonathan

          > Please have a loot at it at
          http://sourceforge.net/projects/j2eeunit/
          > and tell me what you think
          >
          > Thanks.
          > Vincent.
        • Vincent Massol
          Hi Jonathan, HttpUnit and J2EEUnit are doing different things : - HttpUnit tests the result of calling a JSP or Servlet, i.e. it gets the HTML/XML/WML/...
          Message 4 of 19 , Nov 11, 2000
          View Source
          • 0 Attachment
            Hi Jonathan,

            HttpUnit and J2EEUnit are doing different things :

            - HttpUnit tests the result of calling a JSP or Servlet, i.e. it gets
            the HTML/XML/WML/... returned and let you verify HTTP headers,
            cookies, ... + some regexps to check the returned content

            - J2EEUnit (in its initial version) does unit testing of server-side
            java code, i.e. it executes on the server and let you unit test
            methods of your java classes called by the JSPs and Servlets.

            Now, I intend to improve J2EEUnit in the following 2 fields :
            - Let it do what HttpUnit does (actually Russell, who did the
            HttpUnit framework, haas contacted me to check what synergy we could
            have to merge the two),
            - Add EJB unit testing

            Thanks.
            Vincent.
          • Vincent Massol
            He, he ! It seems it existed before you created it last night !, because I subscribed to it a week ago ... :)
            Message 5 of 19 , Nov 11, 2000
            View Source
            • 0 Attachment
              He, he !
              It seems it existed before you created it last night !, because I
              subscribed to it a week ago ... :)

              --- In junit@egroups.com, "Erik Meade" <emeade@g...> wrote:
              > Hi Vincent,
              >
              > I'm the only person subscribed to this list other than you. :)
              > I haven't announced it yet, but will soon. How did you find it
              > so fast? I just created it last night.
              >
              > Erik
              >
            • David Corbin
              ... How is this different from simply using JUnit? I can test java classes with it too. -- David Corbin Mach Turtle Technologies, Inc.
              Message 6 of 19 , Nov 11, 2000
              View Source
              • 0 Attachment
                Vincent Massol wrote:
                >
                > - J2EEUnit (in its initial version) does unit testing of server-side
                > java code, i.e. it executes on the server and let you unit test
                > methods of your java classes called by the JSPs and Servlets.
                >

                How is this different from simply using JUnit? I can test java classes
                with it too.
                --
                David Corbin
                Mach Turtle Technologies, Inc.
                http://www.machturtle.com
                dcorbin@...
              • Vincent Massol
                Yes, you re right but some of these java classes need to have access to valid HttpServletRequest, HttpServleetResponse and HttpSession objects. One other
                Message 7 of 19 , Nov 11, 2000
                View Source
                • 0 Attachment
                  Yes, you're right but some of these java classes need to have access
                  to valid HttpServletRequest, HttpServleetResponse and HttpSession
                  objects. One other workaround solution would be to put a facade in
                  front of all these objects for your classes. However, this can be
                  difficult to do when you need to manipulate intensively these objects
                  in your classes. Moreover, even if you use the facade, you may still
                  need to test your servlets ...

                  Thanks.
                  Vincent.

                  --- In junit@egroups.com, David Corbin <dcorbin@m...> wrote:
                  > Vincent Massol wrote:
                  > >
                  > > - J2EEUnit (in its initial version) does unit testing of server-
                  side
                  > > java code, i.e. it executes on the server and let you unit test
                  > > methods of your java classes called by the JSPs and Servlets.
                  > >
                  >
                  > How is this different from simply using JUnit? I can test java
                  classes
                  > with it too.
                  > --
                  > David Corbin
                  > Mach Turtle Technologies, Inc.
                  > http://www.machturtle.com
                  > dcorbin@m...
                • Jonathan Rasmusson
                  ... Thats great to hear. I have done a considerable amount of EJB tests with JUnit and may be able to contribute. Cheers Jonathan
                  Message 8 of 19 , Nov 13, 2000
                  View Source
                  • 0 Attachment
                    --- In junit@egroups.com, "Vincent Massol" <vmassol@o...> wrote:

                    > - Add EJB unit testing
                    >

                    Thats great to hear. I have done a considerable amount of EJB tests
                    with JUnit and may be able to contribute.

                    Cheers

                    Jonathan
                  • Vincent Massol
                    Hi Jonathan, With the current J22EUnit, it is already possible to unit test EJBs. In your testXXX() method just do a lookup on the home, create the bean and
                    Message 9 of 19 , Nov 16, 2000
                    View Source
                    • 0 Attachment
                      Hi Jonathan,

                      With the current J22EUnit, it is already possible to unit test EJBs. In your
                      testXXX() method just do a lookup on the home, create the bean and call it's
                      remote methods. I am still wondering what I could add to make EJB testing
                      attractive and useful :
                      - I could first hide calling an EJB remote method by automatically setting
                      JNDI, doing the lookup, create the bean instance and calling the remote
                      method,
                      - What could I do more ?

                      Thanks and please feel free to contribute.
                      Vincent

                      ----- Original Message -----
                      From: "Jonathan Rasmusson" <jr@...>
                      To: <junit@egroups.com>
                      Sent: Tuesday, November 14, 2000 4:57 AM
                      Subject: [junit] Re: J2EEUnit


                      > --- In junit@egroups.com, "Vincent Massol" <vmassol@o...> wrote:
                      >
                      > > - Add EJB unit testing
                      > >
                      >
                      > Thats great to hear. I have done a considerable amount of EJB tests
                      > with JUnit and may be able to contribute.
                      >
                      > Cheers
                      >
                      > Jonathan
                      >
                      >
                      >
                      > To unsubscribe from this group, send an email to:
                      > junit-unsubscribe@egroups.com
                      >
                      >
                      >
                      >
                      >
                    • Vera Peeters
                      Hi, We apply the following strategies to make our EJB s *fully* testable. 1. EJB s are thin. They are really really thin. The EJB is in fact an interface into
                      Message 10 of 19 , Nov 17, 2000
                      View Source
                      • 0 Attachment
                        Hi,

                        We apply the following strategies to make our EJB's *fully* testable.

                        1. EJB's are thin. They are really really thin. The EJB is in fact an
                        interface into a "Box". Each Box owns some tables in the database. Each Box
                        has its private DB package (we do bean-managed), its own EJB (that acts ass
                        an interface into the box), and one or more so-called Business Logic
                        packages. These BL packages do all the work. The BL code is Unit Tested in a
                        very detailed way. The only thing the EJBs do is communicate with other
                        EJB's and then call the BL code with the retrieved data.

                        2. We also test the EJBs, but only very roughly. Every remote method is
                        called, just to see that they work. The details are not tested here, because
                        they are covered in the BL Unit Tests.

                        3. To be able to work quickly (hot deployment with underlying packages is
                        not really possible) we use bipolar EJB creators iso the regular EJB Home
                        for the session EJBs. That is a factory that returns the EJB in the normal
                        way (created by the EJB Home) *or* as a simple local object, depending on a
                        property that can be specified in a config file. While developing, we
                        usually run the tests on the local session EJBs. Very nice for debugging
                        too.

                        4. Only when development of the EJB function is finished, we run the tests
                        on the remote EJB.

                        bye,
                        vp


                        > -----Original Message-----
                        > From: Vincent Massol [mailto:vmassol@...]
                        > Sent: donderdag 16 november 2000 22:23
                        > To: junit@egroups.com
                        > Subject: Re: [junit] Re: J2EEUnit
                        >
                        >
                        > Hi Jonathan,
                        >
                        > With the current J22EUnit, it is already possible to unit test
                        > EJBs. In your
                        > testXXX() method just do a lookup on the home, create the bean
                        > and call it's
                        > remote methods. I am still wondering what I could add to make EJB testing
                        > attractive and useful :
                        > - I could first hide calling an EJB remote method by automatically setting
                        > JNDI, doing the lookup, create the bean instance and calling the remote
                        > method,
                        > - What could I do more ?
                        >
                        > Thanks and please feel free to contribute.
                        > Vincent
                        >
                      • Ilja Preuß
                        ... So you don t implement business logic as session beans??? Sounds weird... ciao, Ilja
                        Message 11 of 19 , Nov 17, 2000
                        View Source
                        • 0 Attachment
                          > 1. EJB's are thin. They are really really thin. The EJB is in fact an
                          > interface into a "Box". Each Box owns some tables in the
                          > database. Each Box
                          > has its private DB package (we do bean-managed), its own EJB
                          > (that acts ass
                          > an interface into the box), and one or more so-called Business Logic
                          > packages. These BL packages do all the work. The BL code is
                          > Unit Tested in a
                          > very detailed way. The only thing the EJBs do is communicate
                          > with other
                          > EJB's and then call the BL code with the retrieved data.

                          So you don't implement business logic as session beans??? Sounds
                          weird...

                          ciao, Ilja
                        • David Corbin
                          ... Why? I m not an EJB guy, but it seems like responsibility of an EJB thing is to present network accessible interface. Since good OO design avoids many
                          Message 12 of 19 , Nov 17, 2000
                          View Source
                          • 0 Attachment
                            Ilja Preuß wrote:
                            >
                            >
                            > So you don't implement business logic as session beans??? Sounds
                            > weird...
                            >
                            > ciao, Ilja

                            Why? I'm not an EJB guy, but it seems like responsibility of an EJB
                            thing is to present network accessible interface. Since good OO design
                            avoids many responsibilities in a given class, this makes complete sense
                            to me. Plus it makes things much more flexible and easier to test.
                            Just like I wouldn't have my GUI classes implement business logic.

                            >
                            >
                            > To unsubscribe from this group, send an email to:
                            > junit-unsubscribe@egroups.com

                            --
                            David Corbin
                            Mach Turtle Technologies, Inc.
                            http://www.machturtle.com
                            dcorbin@...
                          • Ilja Preuß
                            ... But an interface to *what*? ... EJB is a distributed component modell. Why distributed? Mainly for reliability and scalability: As you don t care where a
                            Message 13 of 19 , Nov 17, 2000
                            View Source
                            • 0 Attachment
                              > > So you don't implement business logic as session beans??? Sounds
                              > > weird...
                              > >
                              > > ciao, Ilja
                              >
                              > Why? I'm not an EJB guy, but it seems like responsibility of an EJB
                              > thing is to present network accessible interface.

                              But an interface to *what*?

                              > Since good OO design
                              > avoids many responsibilities in a given class, this makes
                              > complete sense
                              > to me. Plus it makes things much more flexible and easier to test.
                              > Just like I wouldn't have my GUI classes implement business logic.

                              EJB is a distributed component modell. Why distributed? Mainly for
                              reliability and scalability: As you don't care where a component
                              actually resides, you can put work-intensive components on there own
                              cluster, and one cluster can stand in for another one if it fails for
                              some reason.

                              There are two main types of EJBs: entity beans and session beans. Entity
                              beans are data classes, they are responsible for persistence. Session
                              beans are the 'working horses', in a typical J2EE application, here
                              resides your business logic.

                              ciao, Ilja
                            • Vera Peeters
                              In my implementation, the EJB is in fact an interface into a Box . The clients of my Boxes don t know anything about Boxes. From their point of view,
                              Message 14 of 19 , Nov 18, 2000
                              View Source
                              • 0 Attachment
                                In my implementation, the EJB is in fact an interface into a "Box". The
                                clients of my "Boxes" don't know anything about Boxes. From their point of
                                view, they're simply using EJBs. Also, I do use session beans and entity
                                beans just as you describe them.

                                The thing I'm trying to say is not so weird: the EJB-*classes* themselves
                                don't *implement* business logic, but they do *provide* it to its clients by
                                calling the appropriate classes in its private BL package (because they're
                                the interface into the Box).

                                The task of the EJB *class* is to provide everything that EJBs are designed
                                for to provide: network access, transaction management, resource management,
                                multi-thread behaviour (euh..., I think I forgot some but you've got the
                                point), and I'm very happy with that.

                                The task of the Box is to provide Business Logic to its clients. The Box is
                                accessible only through an EJB interface. The Business Logic package of a
                                Box is private to the Box. It can't be accessed from outside the Box (not
                                even from other Boxes).






                                > -----Original Message-----
                                > From: Ilja Preu? [mailto:ilja.preuss@...]
                                > Sent: vrijdag 17 november 2000 21:55
                                > To: junit@egroups.com
                                > Subject: RE: [junit] Re: J2EEUnit
                                >
                                >
                                > > > So you don't implement business logic as session beans??? Sounds
                                > > > weird...
                                > > >
                                > > > ciao, Ilja
                                > >
                                > > Why? I'm not an EJB guy, but it seems like responsibility of an EJB
                                > > thing is to present network accessible interface.
                                >
                                > But an interface to *what*?
                                >
                                > > Since good OO design
                                > > avoids many responsibilities in a given class, this makes
                                > > complete sense
                                > > to me. Plus it makes things much more flexible and easier to test.
                                > > Just like I wouldn't have my GUI classes implement business logic.
                                >
                                > EJB is a distributed component modell. Why distributed? Mainly for
                                > reliability and scalability: As you don't care where a component
                                > actually resides, you can put work-intensive components on there own
                                > cluster, and one cluster can stand in for another one if it fails for
                                > some reason.
                                >
                                > There are two main types of EJBs: entity beans and session beans. Entity
                                > beans are data classes, they are responsible for persistence. Session
                                > beans are the 'working horses', in a typical J2EE application, here
                                > resides your business logic.
                                >
                                > ciao, Ilja
                                >
                                >
                                >
                                > To unsubscribe from this group, send an email to:
                                > junit-unsubscribe@egroups.com
                                >
                                >
                                >
                              • David Corbin
                                ... I think Vera described it better than I can. ... -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com dcorbin@machturtle.com
                                Message 15 of 19 , Nov 18, 2000
                                View Source
                                • 0 Attachment
                                  Ilja Preuß wrote:
                                  >
                                  > > > So you don't implement business logic as session beans??? Sounds
                                  > > > weird...
                                  > > >
                                  > > > ciao, Ilja
                                  > >
                                  > > Why? I'm not an EJB guy, but it seems like responsibility of an EJB
                                  > > thing is to present network accessible interface.
                                  >
                                  > But an interface to *what*?

                                  I think Vera described it better than I can.

                                  >
                                  > > Since good OO design
                                  > > avoids many responsibilities in a given class, this makes
                                  > > complete sense
                                  > > to me. Plus it makes things much more flexible and easier to test.
                                  > > Just like I wouldn't have my GUI classes implement business logic.
                                  >
                                  > EJB is a distributed component modell. Why distributed? Mainly for
                                  > reliability and scalability: As you don't care where a component
                                  > actually resides, you can put work-intensive components on there own
                                  > cluster, and one cluster can stand in for another one if it fails for
                                  > some reason.
                                  >
                                  > There are two main types of EJBs: entity beans and session beans. Entity
                                  > beans are data classes, they are responsible for persistence. Session
                                  > beans are the 'working horses', in a typical J2EE application, here
                                  > resides your business logic.
                                  >
                                  > ciao, Ilja
                                  >
                                  >
                                  > To unsubscribe from this group, send an email to:
                                  > junit-unsubscribe@egroups.com

                                  --
                                  David Corbin
                                  Mach Turtle Technologies, Inc.
                                  http://www.machturtle.com
                                  dcorbin@...
                                • Jonathan Rasmusson
                                  ... testable. ... packages is ... Home ... normal ... depending on a ... we ... debugging ... I think this is a great idea. Does this mean you essentially
                                  Message 16 of 19 , Nov 19, 2000
                                  View Source
                                  • 0 Attachment
                                    --- In junit@egroups.com, "Vera Peeters" <vera.peeters@t...> wrote:
                                    > Hi,
                                    >
                                    > We apply the following strategies to make our EJB's *fully*
                                    testable.
                                    > 3. To be able to work quickly (hot deployment with underlying
                                    packages is
                                    > not really possible) we use bipolar EJB creators iso the regular EJB
                                    Home
                                    > for the session EJBs. That is a factory that returns the EJB in the
                                    normal
                                    > way (created by the EJB Home) *or* as a simple local object,
                                    depending on a
                                    > property that can be specified in a config file. While developing,
                                    we
                                    > usually run the tests on the local session EJBs. Very nice for
                                    debugging
                                    > too.
                                    > >

                                    I think this is a great idea.

                                    Does this mean you essentially duplicate you code? Once for the
                                    EJBBean class and once for your simple local object?

                                    I did something like this in an effort to minimize client code
                                    changes in my application regardless of whether I was running within
                                    an EJB container or not.

                                    You must then define a common interface between your EJB and the
                                    simple local object so the the client does not care whether it gets a
                                    Customer EJB Remote stub or a Customer simple local object.

                                    Also where do you write tests that test your transaction processing.
                                    I find I like to write tests against the EJB container to ensure
                                    things that should get rolled back do. I guess you can not write
                                    these against your simple local objects unless your are demarking the
                                    transactions yourself via BMP.

                                    Thanks for sharing.

                                    Jonathan
                                  • Vera Peeters
                                    ... No code duplication. ... No client code changes. My clients don t even notice wether they re running with a local or a remote EJB. ... We use the following
                                    Message 17 of 19 , Nov 20, 2000
                                    View Source
                                    • 0 Attachment
                                      > -----Original Message-----
                                      > From: Jonathan Rasmusson [mailto:jr@...]
                                      > Sent: zondag 19 november 2000 17:28
                                      > To: junit@egroups.com
                                      > Subject: [junit] Re: J2EEUnit
                                      >
                                      >
                                      > --- In junit@egroups.com, "Vera Peeters" <vera.peeters@t...> wrote:

                                      > > 3. To be able to work quickly (hot deployment with underlying
                                      > packages is
                                      > > not really possible) we use bipolar EJB creators iso the regular EJB
                                      > Home
                                      > > for the session EJBs. That is a factory that returns the EJB in the
                                      > normal
                                      > > way (created by the EJB Home) *or* as a simple local object,
                                      > depending on a
                                      > > property that can be specified in a config file. While developing,
                                      > we
                                      > > usually run the tests on the local session EJBs. Very nice for
                                      > debugging
                                      > > too.
                                      > > >
                                      >
                                      > I think this is a great idea.
                                      >
                                      > Does this mean you essentially duplicate you code? Once for the
                                      > EJBBean class and once for your simple local object?


                                      No code duplication.


                                      >
                                      > I did something like this in an effort to minimize client code
                                      > changes in my application regardless of whether I was running within
                                      > an EJB container or not.


                                      No client code changes.
                                      My clients don't even notice wether they're running with a local or a remote
                                      EJB.


                                      >
                                      > You must then define a common interface between your EJB and the
                                      > simple local object so the the client does not care whether it gets a
                                      > Customer EJB Remote stub or a Customer simple local object.
                                      >

                                      We use the following mechanism:




                                      client--------------------> theMyEJBCreator (singleton)
                                      / \ /
                                      / \ uses / holds
                                      / \ /
                                      / \ /
                                      v v v
                                      returns
                                      MyEJBIF (interface) <------------ bipolarMyEJBCreator (interface)
                                      ^ ^
                                      | |
                                      | |
                                      | ----------| |-----------|
                                      | | | |
                                      MyEJBImpl MyEJBRemote localMyEJBCreator remoteMyEJBCreator
                                      ^
                                      |
                                      |
                                      |
                                      MyEJBStub (generated)



                                      (pfffff... I would say it's a little bit easier to draw it on a
                                      whiteboard... )

                                      The client asks theMyEJBCreator to deliver a bipolarMyEJBCreator.
                                      The theMyEJBCreator looks in the configuration properties file to know
                                      wether he has to create a localMyEJBCreator or a remoteMyEJBCreator.

                                      Client asks this bipolarMyEJBCreator to deliver a MyEJBIF.
                                      If the bipolarMyEJBCreator is a remoteMyEJBCreator, the returned object will
                                      be a MyEJBStub.
                                      If the bipolarMyEJBCreator is a localMyEJBCreator, the returned object will
                                      be a MyEJBImpl.

                                      This works very well for session ejbs. For entity ejbs, the container does a
                                      lot of work that I didn't want to duplicate, so I don't use this mechanism
                                      there.


                                      If we run the EJB locally, a MyEJBImpl is instantiated on the client side as
                                      if it was a simple object.
                                      If we run the EJB remote, a MyEJBStub is instantiated and talks to the
                                      MyEJBImpl that lives in the container on the server side.



                                      > Also where do you write tests that test your transaction processing.
                                      > I find I like to write tests against the EJB container to ensure
                                      > things that should get rolled back do. I guess you can not write
                                      > these against your simple local objects unless your are demarking the
                                      > transactions yourself via BMP.
                                      >


                                      To be honest, we don't test the transaction rollback in the Unit Tests.
                                      We do test wether exceptions are thrown by the EJB in certain situations,
                                      which will normally imply that the transaction is rolled back.
                                      If you would want to test wether the transaction is really rolled back, I
                                      guess you should define a separate Unit Test that should run only on the
                                      remote EJBs, and not on the local EJBs.
                                    • Jonathan Rasmusson
                                      ... container does a ... mechanism ... side as ... the ... Thanks for the diagram! I know those are a pain to draw. I understand much more clearly what you
                                      Message 18 of 19 , Nov 20, 2000
                                      View Source
                                      • 0 Attachment
                                        >
                                        > This works very well for session ejbs. For entity ejbs, the
                                        container does a
                                        > lot of work that I didn't want to duplicate, so I don't use this
                                        mechanism
                                        > there.
                                        >
                                        >
                                        > If we run the EJB locally, a MyEJBImpl is instantiated on the client
                                        side as
                                        > if it was a simple object.
                                        > If we run the EJB remote, a MyEJBStub is instantiated and talks to
                                        the
                                        > MyEJBImpl that lives in the container on the server side.
                                        >

                                        Thanks for the diagram! I know those are a pain to draw.

                                        I understand much more clearly what you are doing now. A couple of
                                        questions:

                                        a) Does your << MyEJBIF >> throw remote exceptions in the local case?

                                        i.e. if I am the client and I want to run locally, I wouldn't expect
                                        any remote exceptions. I have seen this handled both ways where the
                                        RemoteException are caught and where they are thrown to the client
                                        (regardless of local or distributed).

                                        b) Would it be possible to use the EJB's Remote Interface as your <<
                                        MyEJBIF >>?

                                        What is the difference between << MyEJBIF >> and the EJB's Remote
                                        Interface?

                                        The first time I approached this problem I made a special business
                                        interface for my objects and then realized I could just use the EJB
                                        Remote interface itself. The only draw back is my client must catch
                                        Remote, Create, Finder EJB Exceptions (even though they may not be
                                        thrown) in the local case.

                                        PS I like you choice of names i.e. biPolar... I have an Electrical
                                        Engineering background and it brings back memories of Bipolar Junction
                                        Transistors (BJT's). I understood exactly what you meant.

                                        Cheers

                                        Jonathan
                                      • Vera Peeters
                                        ... Yes, the declarations of the functions in MyEJBIF do mention RemoteExceptions. I like it this way because the declaration of the RemoteMyEJB simply
                                        Message 19 of 19 , Nov 22, 2000
                                        View Source
                                        • 0 Attachment
                                          > -----Original Message-----
                                          > From: Jonathan Rasmusson [mailto:jr@...]
                                          > Sent: maandag 20 november 2000 20:29
                                          > To: junit@egroups.com
                                          > Subject: [junit] Re: J2EEUnit
                                          >


                                          > a) Does your << MyEJBIF >> throw remote exceptions in the local case?


                                          Yes, the declarations of the functions in MyEJBIF do mention
                                          RemoteExceptions.
                                          I like it this way because the declaration of the RemoteMyEJB simply
                                          becomes:

                                          public interface MyEJBRemote extends EJBObject, MyEJBIF {
                                          }


                                          (and I never need to change it anymore)


                                          >
                                          > i.e. if I am the client and I want to run locally, I wouldn't expect
                                          > any remote exceptions. I have seen this handled both ways where the
                                          > RemoteException are caught and where they are thrown to the client
                                          > (regardless of local or distributed).

                                          In reality, I never *throw* a RemoteException myself in the MyEJBImpl. The
                                          RemoteExceptions are thrown by the container. If something goes wrong in
                                          *my* code, I normally throw a MyEJBException.
                                          So, if I run myEJBImpl locally, we will never really get a remote exception.
                                          If we run remote, the container will take care that a remote exception is
                                          thrown if something goes wrong in the container.

                                          Although RemoteExceptions are never really thrown, the clients still have to
                                          catch them, that's true. But I don't care about that, because I want to
                                          reuse my clients for the local and the remote EJBs. The client simply uses
                                          the theMyEJBCreator. The theMyEJBCreator decides wether a local or remote
                                          EJB is created. In my case, it looks in a properties file.

                                          I don't have to change 1 line of code to run the tests on local or on remote
                                          EJBs.


                                          >
                                          > b) Would it be possible to use the EJB's Remote Interface as your <<
                                          > MyEJBIF >>?

                                          Well, we chose not too, because now our clients are independent of the
                                          EJBObject interface. The only thing they need to know about EJBs are these
                                          exceptions. The clients don't import any other EJB stuff.


                                          >
                                          > What is the difference between << MyEJBIF >> and the EJB's Remote
                                          > Interface?


                                          Only difference is the extension of EJBObject.

                                          >
                                          > The first time I approached this problem I made a special business
                                          > interface for my objects and then realized I could just use the EJB
                                          > Remote interface itself. The only draw back is my client must catch
                                          > Remote, Create, Finder EJB Exceptions (even though they may not be
                                          > thrown) in the local case.
                                          >
                                          > PS I like you choice of names i.e. biPolar... I have an Electrical
                                          > Engineering background and it brings back memories of Bipolar Junction
                                          > Transistors (BJT's). I understood exactly what you meant.


                                          Comes from a JavaReport some time ago. Ronald Mak described Bipolar Corba
                                          Objects in Java. We figured it was exactly the same thing we were doing (and
                                          renamed them).


                                          bye,
                                          vp
                                        Your message has been successfully submitted and would be delivered to recipients shortly.