WSAD to RAD question - Websphere

This is a discussion on WSAD to RAD question - Websphere ; In WSAD the connection pool and datasource setup was done at the server perspective. Where do we do that in RAD . I don't see any of those when I open the server configuration in RAD...

+ Reply to Thread
Results 1 to 12 of 12

Thread: WSAD to RAD question

  1. WSAD to RAD question


    In WSAD the connection pool and datasource setup was done at the server
    perspective.

    Where do we do that in RAD . I don't see any of those when I open the
    server configuration in RAD


  2. Re: WSAD to RAD question

    Look in the Enhanced EAR file.

    me wrote:

    >
    > In WSAD the connection pool and datasource setup was done at the
    > server perspective.
    >
    > Where do we do that in RAD . I don't see any of those when I open the
    > server configuration in RAD
    >


    --
    Jim Palistrant
    Market Manager, Rational SOA Solutions

  3. Re: WSAD to RAD question

    Jim

    thanks , I got it.

    Does that mean the server is attached to one ear always?

    Jim Palistrant wrote:
    > Look in the Enhanced EAR file.
    >
    > me wrote:
    >
    >>
    >> In WSAD the connection pool and datasource setup was done at the
    >> server perspective.
    >>
    >> Where do we do that in RAD . I don't see any of those when I open the
    >> server configuration in RAD
    >>

    >



  4. Re: WSAD to RAD question

    No, it means that the datasource definition is now associated with the
    APPLICATION and not with the SERVER on which the application runs, which
    is much more logical.

  5. Re: WSAD to RAD question

    Chris

    Thanks for the response.

    But if i have 2 applications that use the same data source , does that
    mean I have to create 2 connection pool and data source or share the same



    Chris Gage wrote:
    > No, it means that the datasource definition is now associated with the
    > APPLICATION and not with the SERVER on which the application runs, which
    > is much more logical.



  6. Re: WSAD to RAD question

    In practice yes, you do end up with a datasource definition and
    therefore a connection pool per application, although if you were really
    determined to do it, you could probably hack/lash/stickytape the two
    applications together and share a single one. I would doubt whether the
    complexity and interdependence that you would get as a result would be
    worth it.

    In fact, on reflection, I'd go further -- don't do it :-)

    Remember separation of concerns. If the two applications do not _need_
    to depend on each other, or on a shared third party entity, don't make them.

    Chris

  7. Re: WSAD to RAD question

    Chris

    Thanks for the input , I am not goin to hack around it , if that is how
    it is going to be , creating another datasource is not a big deal
    eventhough I don't really see the need for it

    Is this only in websphere or this will be the way to go in other
    application servers also.




    Chris Gage wrote:
    > In practice yes, you do end up with a datasource definition and
    > therefore a connection pool per application, although if you were really
    > determined to do it, you could probably hack/lash/stickytape the two
    > applications together and share a single one. I would doubt whether the
    > complexity and interdependence that you would get as a result would be
    > worth it.
    >
    > In fact, on reflection, I'd go further -- don't do it :-)
    >
    > Remember separation of concerns. If the two applications do not _need_
    > to depend on each other, or on a shared third party entity, don't make
    > them.
    >
    > Chris



  8. Re: WSAD to RAD question

    Chris

    With the enhanced EAR file. the datasource setup will be part of the
    ..ear when exporting out of RAD.

    we have dev,QA and prod environments for the DB

    The ip address to the server running Database is different and this will
    be attached to the connection pool.

    I assume RAD will have the dev ip .

    So do we have to change the connection pool setting after deploying the
    EAR in the target servers. Is that true??

    A lil confused here



    me wrote:
    > Chris
    >
    > Thanks for the input , I am not goin to hack around it , if that is how
    > it is going to be , creating another datasource is not a big deal
    > eventhough I don't really see the need for it
    >
    > Is this only in websphere or this will be the way to go in other
    > application servers also.
    >
    >
    >
    >
    > Chris Gage wrote:
    >
    >> In practice yes, you do end up with a datasource definition and
    >> therefore a connection pool per application, although if you were
    >> really determined to do it, you could probably hack/lash/stickytape
    >> the two applications together and share a single one. I would doubt
    >> whether the complexity and interdependence that you would get as a
    >> result would be worth it.
    >>
    >> In fact, on reflection, I'd go further -- don't do it :-)
    >>
    >> Remember separation of concerns. If the two applications do not
    >> _need_ to depend on each other, or on a shared third party entity,
    >> don't make them.
    >>
    >> Chris

    >
    >



  9. Re: WSAD to RAD question

    Normally in practice you might want to consider avoiding using the EAR
    file created by the development tool for a build that would ship to
    production, or even to system test. It likely that you don't have
    enough control over it if you continue using RAD-generated EAR files.

    When your application reaches that stage, it should probably be built
    not by developers but by a build/test person, using an ant script
    running against source code extracted directly from your source control
    system. Of course this person would be you if you wear all the hats
    yourself! :-)

    You would set up the appropriate data source definitions (XML files) for
    each build flavour you need, in your source control. Then when you run
    ant, you get a deliverable entity for whichever target audience you are
    aiming at, ie system test, production test, production, etc.


    Chris

  10. Re: WSAD to RAD question

    Chris

    I wear all the hats here ):

    Until now I created the EAR from WSAD.

    Other than the best practice , is there a problem to use the ear file
    from the studio(i dint see any problems yet ,but !!)

    Am not famililar with ANT , but can we make it work from any souce
    control system , we use CVS


    Chris Gage wrote:
    > Normally in practice you might want to consider avoiding using the EAR
    > file created by the development tool for a build that would ship to
    > production, or even to system test. It likely that you don't have
    > enough control over it if you continue using RAD-generated EAR files.
    >
    > When your application reaches that stage, it should probably be built
    > not by developers but by a build/test person, using an ant script
    > running against source code extracted directly from your source control
    > system. Of course this person would be you if you wear all the hats
    > yourself! :-)
    >
    > You would set up the appropriate data source definitions (XML files) for
    > each build flavour you need, in your source control. Then when you run
    > ant, you get a deliverable entity for whichever target audience you are
    > aiming at, ie system test, production test, production, etc.
    >
    >
    > Chris



  11. Re: WSAD to RAD question

    The EAR file generated by WSAD or RAD is correct - it wouldn't be any
    use if it were not correct, and yes, you can use ant with CVS. It's a
    question of where you should use that EAR, and where you should perhaps
    not use it.

    Many larger projects (commercial software written by IBM for example)
    confine the use of the IDE-generated deliverables to the development
    environment only, ie for unit test. To meet the needs of the more
    formal process of system testing and shipping the product, someone
    writes an ant script to extract the current source from CVS and build
    only the code that has been formally "checked in". This allows the
    developers to have more freedom working with the code and reduces (but
    does not eliminate) the number of times the build gets broken by some
    enhancement or bug-fix.

    In my case over the last ten years or so I was fortunate enough to have
    a couple of really top-notch wizards half my age doing that part for me,
    and they never failed to make me look good.

    The case for doing this is mostly a matter of choices. It isn't cast in
    stone. I am trying to think of a good book on the subject but right now
    I can't think of one. Perhaps one of our fellow posters may have a
    suggestion. You should at least look at the ant web site
    http://ant.apache.org/ and take a look at some of the examples there.
    In my view in the long term you will not be sorry you did.

    Chris

  12. Re: WSAD to RAD question

    Thanks Chris for the detilaed reply

    Chris Gage wrote:
    > The EAR file generated by WSAD or RAD is correct - it wouldn't be any
    > use if it were not correct, and yes, you can use ant with CVS. It's a
    > question of where you should use that EAR, and where you should perhaps
    > not use it.
    >
    > Many larger projects (commercial software written by IBM for example)
    > confine the use of the IDE-generated deliverables to the development
    > environment only, ie for unit test. To meet the needs of the more
    > formal process of system testing and shipping the product, someone
    > writes an ant script to extract the current source from CVS and build
    > only the code that has been formally "checked in". This allows the
    > developers to have more freedom working with the code and reduces (but
    > does not eliminate) the number of times the build gets broken by some
    > enhancement or bug-fix.
    >
    > In my case over the last ten years or so I was fortunate enough to have
    > a couple of really top-notch wizards half my age doing that part for me,
    > and they never failed to make me look good.
    >
    > The case for doing this is mostly a matter of choices. It isn't cast in
    > stone. I am trying to think of a good book on the subject but right now
    > I can't think of one. Perhaps one of our fellow posters may have a
    > suggestion. You should at least look at the ant web site
    > http://ant.apache.org/ and take a look at some of the examples there. In
    > my view in the long term you will not be sorry you did.
    >
    > Chris



+ Reply to Thread