Development/Code Release mechanism for a J2EE project

Discussions

EJB design: Development/Code Release mechanism for a J2EE project

  1. Hi everyone.

    This is a rather lengthy question, but all relate to setting up an efficient J2EE project environment.

    I am trying to plan the most appropriate development environment for a team of 20 developers - 12 JSP/Servlet developers and 8 EJB developers. The JSP/Servlet team will use the EJB beans from team2 as they become available (i.e. EJB and JSP being developed in parallel - detailled design has been complete though). I am trying to figure out what development environment is most appropriarte, and how it will work. My thoughts/questions:

    1) Should the EJB developers each have their own EJB container?

    2) EJB developers can use each others code by using some sort of version control software - However, EJBs need to be deployed (not just copied across to a developers local environment) - So can scripts be written to allow each developer to easily deploy ALL the EJBs without each EJB developer spending loads of time going through a manual deploy process each time? What tools?

    3) The JSP developers could each have their own Servlet engine, or perhaps each have a context in a central installation (though the latter would be slow) - What are the group's thoughts on this?

    4) Now, the JSP developers also need access to the EJBs - Should each JSP developer have their own EJB container as well, or share a central one? Remember that there will be on-going development, bugs, changes etc in the EJBs in paralell with the JSP development - the restaring of servers etc will have huge impact on developers - What are the recommended practices here?

    5) Do EJB containers also support the notion of a "context" and multiple developers can operate from a central EJB container, yet be totally independent of each other (and hence no impact of one developer having to re-start their EJB context to allow re-dployment of a JAR]?

    6) Assume that the final implementation will seperate the JSP/Servlet container from the EJB container - There will be certain classes that will be required to be present in both the EJB container and in the JSP engine (e.g. EJB home and remote interfaces, value objects, etc). Thus, there may be certain classes within a large number of the EJB packages that need to be "picked out" and included in our WAR file.It seems to me like a HUGE job to figure out what exactly needs to be where, and then to extract it all! So, what tools/techniques can be used to assist in this rather tedious and very error-prone process? Or perhaps, I need to design my packages more appropriately - Is it normal to have the home and remote interfaces of an EJB in the same package as the implementation of the EJB?

    7) Any of the above effected by the hefty task of debugging the application?

    8) Have any of you any opinions on the latest IDEs, some of which include a Servlet engine (thus allowing easier debugging), and others actially including some sort of minature EJB container?

    I look forward to your responses;

    Thanks

    Paddy

    Threaded Messages (23)

  2. I had to set this up for a client recently, so I will annotate your questions below with what we did. I am not saying this is the "best" way, but it did work.

    I have always found it best to get this set up at the very beginning. We have always made sure that within 1 week of starting the "build it" phase, we have a process which we can extend and use to reliably build the application, as and when we need to. That way we know what we need to build the thing and we can trap little problems like junior developers hard coding things that need to be configurable etc etc.


    1) Should the EJB developers each have their own EJB container?

    *** Absolutely, everyone had their own NT instance of WebLogic. That allows them to isolate their work from other people until they are ready to check it into version control. A central server was chaos during a prototype phase, as people were perpetually overwriting each others work. For a full scale project, with deadlines to meet, we determined it was too big a dependency to put it in the middle of everyone.

    I should also point out that we standardised on our packages, source code control directory structure, and developer workstation set up. This includes what directories you put your local sand box in. This makes it much easier for developers to help each other without having to learn how each others machines are set up. This is true for all members of each team.



    2) EJB developers can use each others code by using some sort of version control software - However, EJBs need to be deployed (not just copied across to a developers local environment) - So can scripts be written to allow each developer to easily deploy ALL the EJBs without each EJB developer spending loads of time going through a manual deploy process each time? What tools?

    *** You can use ANT, make or any other build tools to do this. We used make, which simply recompiles, creates JARs, invokes ejbc, and then deploys the bean to the running server. (We actually didn't do the last step, we restarted the server, but you just add another rule to the makefile and it works.) Under NT, ANT works fine, for make you will need to install CygWin or similar to make it work, but it's not that hard.


    3) The JSP developers could each have their own Servlet engine, or perhaps each have a context in a central installation (though the latter would be slow) - What are the group's thoughts on this?

    *** As with the EJB developers, each developer should have access to his or her own servlet container. This could be internal to the IDE (As in VAJ) or it could be that everyone has Tomcat / WebLogic installed. That way you have the latest version of everyone elses code, plus your own work. Let the SCM system take care of the check in check out process.

    4) Now, the JSP developers also need access to the EJBs - Should each JSP developer have their own EJB container as well, or share a central one? Remember that there will be on-going development, bugs, changes etc in the EJBs in paralell with the JSP development - the restaring of servers etc will have huge impact on developers - What are the recommended practices here?

    *** What we did here was as follows.

    1) Each developer works on the beans as in (1) of your question.

    2) When a developer was satisfied that his code was "stable" we did a build, using a quick procedure, using make. (By quick I mean the whole build process including releasing it and restarting weblogic was < 2 minutes.)

    3) We released this stable build to a CLEAN WEBLOGIC ENVIRONMENT. We keep other teams informed as to when we are doing these releases and what things were changing.

    4) The servlet team pointed their code at this stable environment. The EJB team view this stable environment as a production style system.




    5) Do EJB containers also support the notion of a "context" and multiple developers can operate from a central EJB container, yet be totally independent of each other (and hence no impact of one developer having to re-start their EJB context to allow re-dployment of a JAR]?

    *** As far as I know, if a bean is deployed as jndi.Name then you can't deploy another bean as jndi.Name in the same server, which is in essence what you would be talking about. If you use the ejb-ref tags correctly then you could have jndi.DeveloperLoginID.Name which would help you out here. You can certainly deploy beans to most servers without restarting them.

    6) Assume that the final implementation will seperate the JSP/Servlet container from the EJB container - There will be certain classes that will be required to be present in both the EJB container and in the JSP engine (e.g. EJB home and remote interfaces, value objects, etc). Thus, there may be certain classes within a large number of the EJB packages that need to be "picked out" and included in our WAR file.It seems to me like a HUGE job to figure out what exactly needs to be where, and then to extract it all! So, what tools/techniques can be used to assist in this rather tedious and very error-prone process? Or perhaps, I need to design my packages more appropriately - Is it normal to have the home and remote interfaces of an EJB in the same package as the implementation of the EJB?

    *** We split our project into logical groups, one of which we called shared_components. Common code went in there. This was NOT EJB classes, it was utility classes, the log4j.jar file, etc etc. You get the idea.

    This was the only CVS project that any other project was allowed to depend on. No other cross dependencies between projects was allowed.

    When we wanted to provide our bean clients with access, our build process produces a client JAR file that contains the required classes. This is then used in the classpath of the client.


    7) Any of the above effected by the hefty task of debugging the application?

    *** Here, we go with the fact that each developer has his own environment, plus we had an effective logging strategy using log4j defined, which makes things a lot easier.

    8) Have any of you any opinions on the latest IDEs, some of which include a Servlet engine (thus allowing easier debugging), and others actially including some sort of minature EJB container?


    *** The VAJ IDE has a servlet container in it, but I think it's behind the spec. It also contains a mini WebSphere EJB container, again behind the spec if memory serves.

    Things like Visual Cafe integrate with WebLogic apparently but I have always found these things painful to deal with. It has always been easier to simply have some simple NT scripts (that are in source code control and common to all developers) which let you run up a servlet engine quickly. Tomcat for instance, starts in next to no time.

    Hope this helps. Get back to me with any questions.

    Chz

    Tony
  3. Tony, Excellent response -

    Thanks

    Paddy
  4. I have gone through the same process, and used the same
    setup as you have.

    Cygwin to allow for shell scripts / make to work on both the production system (unix) and developer machines (NT or linux).

    I have used JavaDeps (http://www.vet.com.au/java/javadeps/)to handle the java dependancies in the makefiles (so we don't recompile everything).

    JUnit (http://www.junit.org) for unit testing. Setup "make test" to run your test suites. The checkin process is "if make test doesn't run then you don't check in!"

    JIndent (http://home.wtal.de/software-solutions/jindent/frameset.html) for code standards.
    Again, youu can setup the checkin process to enforce the code through jindent.

    You have to think about the build process. We did a lot
    of work with CVS tagging to help us build different versions
    of the code. Different tags defined whether the code was "ok as far as the developer was concerned", "gone through testing", "production", etc etc.

    I have used EJBGen (http://www.beust.com/cedric/ejbgen/) to handle generating the home/remote/deployment descriptors for the beans. This allows us NOT to force certain IDEs on the developers.

    I would consider using ANT instead of Make.

    IDE-wise, I love TogetherSoft products, and JBuilder is nice.

    Cheers,

    Dion
  5. These postings bring to the front what i really hate about the ejb spec (and how developers write to it).

    i strongly agree with:
    * getting the build going immediately
    * standardizing packages
    * using standard build/deploy scripts, etc.

    but i have serious issues with how ejb development is done:

    1) Should the EJB developers each have their own EJB container?

    no! if you have a good architect, design the app with two communincation layers (between presentation/midtier (using url to communicate) and midtier to dbtier (using "finders" to communicate).

    if you do this correctly and ensure:
    * all dbtier calls return implementation of "base" interfaces (i.e. the business object pattern)
    * all business facades (which will become session beans) DO NOT CONTAIN ANY CODE other than delegate calls (to a non-ejb which will do the business work)

    you don't need to care about ejbs at all. in the deployment phase, you can spend time ejbing things and caring about jndibinding all all the crap that you shouldn't care about in development. will it take time? yes. but how much faster is it to restart a java process than jboss or (much worse) weblogic. also, when you're developing, you're using local calls anyway, so why use rmi (so you don't need to rermic). and if you use jboss with embedded tomcat, you don't even need to use a url between jsp/ejb, just call methods directly (and create a deployment process which uses urls).

    how else will this help?
    * developers won't use weblogic.io.* or any vendor specific code because they won't have access to it!
    * it'll differentiate the roles of development (create the correct business value) from deployment (let's add a naming layer) which all ejb developement teams need.
    * integration will be nearly foolproof. just have a config file in source control which has a) classpath b) db connection and you're done.

    what else would i suggest:
    * everyone having the same package structure (all the way to to the root)
    * testing/testing/testing. if it works in your unit test on your machine but not in production but does in staging, that's a configuration problem, not a development problem.

    what objections will i get:
    * not all environments are the same and there's value in having development done in exactly the same environment as staging/production. that's true but not failsafe. we've all spent time determining how different machines were configured (even when we were using exactly the same setup). any intelligent developer can find the problems with the same amount of work.

    on a "good project" note, i'd recommend using idea's ide called intellij. why? because it allows quick refactoring, dead code finding, code scrubbing, auto-imports, etc. which make me a much faster developer.

    csb

  6. 1) Should the EJB developers each have their own EJB container?


    no! if you have a good architect, design the app with two communincation layers (between presentation/midtier (using url to communicate) and midtier to dbtier (using "finders" to communicate).

    You make an _enourmous_ assumption here. That the EJBs are merely facades onto other code, not EJB related. This _might_ be the case (It is on the project I am working on right now) but it isn't always the case. What if I am specifically using the transactionality functionality of EJB? Or am declaring UserTransaction objects, which I know are available from some JNDI supporting service? In these situations I have no choice but to use the J2EE interfaces and I need a server. In these situations, then it's easier for each developer to have his own server, or you end up with serialized access to the thing!

    The rest of your comment goes more to how you design your system, but the premise here was that the design had been done and there was necessary development of more elaborate EJBs than you suggest.

    >>>> how else will this help?
    >>> * developers won't use weblogic.io.* or any vendor specific code because they won't have access to it!

    Use of weblogic.io.... is not something that necessarily happens just because you are using J2EE. Not using vendor specific classes is a good development practise, not something you should enforce with the environment you present.

    >>> * integration will be nearly foolproof. just have a config file in source control which has a) classpath b) db connection and you're done.

    Don't agree. WebLogic has a massive properties file. Apache is no better and that's just a web server, to name but two examples. Configuration is as painful as code integration a lot of the time. In the past I have spent days trying to tidy up configuration of a 30 odd server installation. Saying that all you have to worry about is configuration does not mean it's foolproof!


    >>> what else would i suggest:
    * everyone having the same package structure (all the way to to the root)

    I agree, right back to the directory they put their local copy of said environment in, so that developer A doesn't have to learn how developer B has his machine set up when he needs to help him!

    >>> * testing/testing/testing. if it works in your unit test on your machine but not in production but does in staging, that's a configuration problem, not a development problem.

    NOT TRUE!! Staging could well be connected to different databases (it ought to be!) so the data could be a big factor here. The odds are the production environment has the more accurate data (whether that is correct is not the main point here, assume it is for the moment), if your code can't handle it then it's a development problem, your unit tests are probably wrong, or incomplete, but it's not a configuration problem. It _might_ be, but to say that it is definitely not a development problem is inaccurate.

    >>> what objections will i get:
    * not all environments are the same and there's value in having development done in exactly the same environment as staging/production. that's true but not failsafe. we've all spent time determining how different machines were configured (even when we were using exactly the same setup). any intelligent developer can find the problems with the same amount of work.

    Actually no, I don't disagree (suprise! :-))
    What I would say is that it has to be tested in the environment it will be run in, but not developed (testing = all testing except unit testing which is a development role.)

    Chz

    Tony
  7. You make an _enourmous_ assumption here. That the EJBs are merely facades onto other code, not EJB related.


    this is true. you do make a good point. although this solution may not be always applicable, for the example of UserTranaction i'd create a factory onto the transaction service (like TranasactionFactory.createUserTransaction( SessionContext context, Connection connection )). it would ignore the context passed in and return an implementation of the UserTransaction interface (5 methods which will be delegated to the connection in my *temporary* implementation). when you go to production, you swap out the crappy impl and to a jndi bind in that factory.

    even if you disagree with this approach, you must agree that you should pass the UserTransaction to a delegate class so you don't have to regen the ejb. yes/no?

    what a pain? no. the factory/impl will take 10 minutes, people don't have to reejbc/deploy there code everytime anything changes. (what would you think if you were running a company and you knew you had 8 developers making $80,000/yr avg. and they spent 30 minutes/day ejbc/deploying). i'm sure you would want that to change.

    >>> * integration will be nearly foolproof. just have a config file in source control which has a) classpath b) db connection and you're done.

    sorry, i mean development integration (i.e. nothing during the first x months of development (when you will be coding business funcationality without worrying about deployment issues) will use ejb container) will be foolproof.

    >>>NOT TRUE!! Staging could well be connected to different databases (it ought to be!) so the data could be a big factor here.

    nothing about spending time caring about HOW an app should run will fix broken junit tests/db configurations. i'm just trying to reduce the number of issues during the start/middle of a product and have business developers concentrate on business code and other developers concentrate on deployment (i.e. what should the isolation level and number of instances be for this method/bean).

    why is apache's implemenation of soap allow for quick development? you create a soaprequest/response and CONFIGURE which "invoker" will work on it. pool objects and connections and handle security etc but do that at deployment, not during development. it's a waste of time.

    csb
  8.  >>> You make an _enourmous_ assumption here. That the EJBs are merely facades onto other code, not EJB related.

    this is true. you do make a good point. although this solution may not be always applicable, for the example of UserTranaction i'd create a factory onto the transaction service (like TranasactionFactory.createUserTransaction( SessionContext context, Connection connection )). it would ignore the context passed in and return an implementation of the UserTransaction interface (5 methods which will be delegated to the connection in my *temporary* implementation). when you go to production, you swap out the crappy impl and to a jndi bind in that factory.

    *** Perhaps I would do this, it depends on how much my overall architecture was tied to EJB. If you assume that the project in question requires high levels of OLTP, then, as a developer I have to work out how to build the beans, and what transaction descriptors to set on them (You could argue that was the deployers job, but when did you see a project that used Sun's roles in practise?)

    If a project needed that kind of development, and I know my design is J2EE tied, then why build the factory? I accept your point, it's a standard OO point that interface and implementation should be separate, but I would stand by my earlier comment, that some projects are EJB through and through. I don't like those projects, I'll happily say that, but that doesn't mean they don't exist.


    even if you disagree with this approach, you must agree that you should pass the UserTransaction to a delegate class so you don't have to regen the ejb. yes/no?

    *** To answer your question, yes I'd probably write a factory. I just spent 4 months building a system that is nothing to do eith EJB, except it has one stateless session bean, and guess what? It's a facade with one method, that has one line of code which calls my internal facade class, which is the one I used in development! :-)


    what a pain? no. the factory/impl will take 10 minutes, people don't have to reejbc/deploy there code everytime anything changes. (what would you think if you were running a company and you knew you had 8 developers making $80,000/yr avg. and they spent 30 minutes/day ejbc/deploying). i'm sure you would want that to change.

    *** You can say that about almost any technology. I've seen that used as a reason to upgrade from a Sparc 20 to an E4500 (time taken waiting for Solaris C++ compiler to run etc. Ironically enough, it worked!) Where do you draw the line? Do you assume that the time spent deploying is time the developer doesn't put to some other use? (I usually get on with something else while this is going on.) All arguments of this nature assume that the activity in question prohibits the developer from doing something else. Is that true?

    >>> * integration will be nearly foolproof. just have a config file in source control which has a) classpath b) db connection and you're done.

    sorry, i mean development integration (i.e. nothing during the first x months of development (when you will be coding business funcationality without worrying about deployment issues) will use ejb container) will be foolproof.

    >>>NOT TRUE!! Staging could well be connected to different databases (it ought to be!) so the data could be a big factor here.

    nothing about spending time caring about HOW an app should run will fix broken junit tests/db configurations. i'm just trying to reduce the number of issues during the start/middle of a product and have business developers concentrate on business code and other developers concentrate on deployment (i.e. what should the isolation level and number of instances be for this method/bean).

    *** If you think you can truly separate them that much, then that's great. I don't see a very good utilization graph for deployers to be honest. They'd probably be technical people who were doing testing, otherwise their resource usage will be very peaky.

    why is apache's implemenation of soap allow for quick development? you create a soaprequest/response and CONFIGURE which "invoker" will work on it. pool objects and connections and handle security etc but do that at deployment, not during development. it's a waste of time.

    *** Having some idea of the performance characteristics of your system is very important. If you don't look at this properly until deployment you get class waterfall late problem discovery.

    Chz

    Tony
  9. Tony, which IDE tool are you recomending? (I know there are many commercial tools available like Visual Age, JBuilder, Forte, etc...)

    In environment that you are describing, which one would you select?
  10. Personally I would have used Visual Age when I first posted.

    Now however, I would probably use Eclipse. It's a wonderful IDE which answers most, if not all, of the criticisms levelled at Visual Age.

    Chz

    Tony
  11. I just wanted to first say that this is a great thread with some very good points and/or arguments for running a J2EE team.

    In regards to the IDE question if I were starting a project now I would really look into IBM's new WebSphere Studio Application Developer(WSAD from here on out) which is currently in a pretty stable beta. Expected to go gold sometime in December but don't quote me on that. I have been using it for the past phew weeks and being I long time forced user of VAJ I am very pleased with IBM's new direction with WSAD. WSAD is built on top of the Eclipse project and has addressed many of the short comings of VAJ save the still heavy memory requirements.

    Highlights of IDE.

    1. Complete IDE for anything for the web you may wish to create as it relates to J2EE. From JSP to Servlets to EJB to XML to HTML it doese it all.

    2. It supports a plug able JDK. From what I can tell if you wish to use JDK 1.4 and J2EE 1.3 just place the runtime in the build path and away you go. You will still be limited however, by what is supported by WebSphere Application Server for testing in the integrated Test Environment.

    3. For the integrated Test Server you have a couple of choices as of now. First the WebSphere Test Environment WTE (A subset of the WebSphere Application Server 4.0) or Tomcat for servlets and JSP. You do with the WTE get an EJB 1.1 container, JSP 1.1, Servlet 2.2 support and the Java 1.3 JDK out of the box, not that this is the absolute latest and greatest but the new plug able architecture should allow IBM to ramp up sooner I hope.

    4. Fully J2EE Compliant.

    5. Ships with CVS interface (takes a bit to get used to terms used but seems to work pretty well) and as you can guess the Object based Repository of VAJ that hid our java code from us is gone.

    6. As the open source community provides new tools and or servers to be used with it the more options you will have. This you will not get from any other commercial vendor as the base code (Eclipse Project) is open source.

    7. The user interface is very flexible and pretty quick once things get loaded into memory (again it is very memory hungry I recommend 384MB min. 512MB would be nice). This UI on J Builder is still a bit slow and choppy for my taste.

    I am forced to use WebSphere and IBM development tools however I have used others such as J-Builder and Café but I would now say that nobody matches the level of integration that IBM provides with the WSAD. The only thing it needs now is an integrated UML modeler but hay that could easily be provided by some low cost offering such as MagicDraw. They have already hinted at it and are probably working on it currently.
  12. I am trying to deploy an EJB in Weblogic6.1 Could you please tell me what are the steps that I need to follow to deploy it on 'myServer'? I am looking for the steps such as providing some properties in build.xml file etc. Your inputs will be of great help to me.
  13. You need a neutral IDE which support J2EE development
    lifecycle - which is JBUILDER form famous Borland.

    80% of the questions have been answered by the tool itself.

    Tieu Chu
  14. Hi Guys,

    From my experience with J2EE (I'm using the VA for Java 3.5 and Websphere route on time and BEA Weblogic and TextPad for the other), I've found the following:

    * Go with a central EJB server, in the case with Websphere and Weblogic, we found it better that everyone worked off of the same machine because integrating everyone's code at the end was a nightmare. Yes, everyone had the same version of App Server but it required too hardware resouces on the development team (Running your IDE and App Server made apps crawl and thus productivity was down) and it was a maintence nightmare because somebody's app server was funny or it didn't work right or someone code didn't migrate well.

    * What is did after learning this, was run multiple instances of the app server on the server machine. That allowed us to test and whatever was 'final' was submitted to the SCM. Every couple of days, we would backup the contents and do a fresh reload from SCM and continue (this was done off hours or lunch)

    Another tip:
    If you have guys or gals who are doing it for the first time, try to do a dry run so that they can get familiar with the env and tools (we did a tournament app for our foosball. Great... 4 CMP EJBs just so we can see how many times who beat who)

    Also have a good Architect to draw up good design docs. This will definatelly help with the interfacing between components.

    Last thing, personally I do this, I take my best jsp/servlet developer and make it work along side my best EJB developer. When the Jsp/servlet or the EJB have team meetings, the best developer of each side has insight on each other and thus the left hand knows what the right hand is doing.

    Have fun!
    -aw
  15. Hi,

    Some comments:
    ** * Go with a central EJB server, in the case with Websphere and Weblogic, we found it better that everyone worked off of the same machine because integrating everyone's code at the end was a nightmare.

    You are absolutely correct - integrating code at the end of the developement process leads to chaos. Integration should begin when you start writing the code - when two interacting modules interfaces are defined before all the functionality is written and available and a mockup implementation is done. This supplies an isolation level and also promotes problems to surface early in the developement process.
    When implementing this scheme of work, you will find coders able to proceed in parallel after a 'contract-interface' is defined. The unit-testing is also easy because you have a mockup implementation code and can 'feel' a modules behavior before it is finished.

    Yuval.

  16. Hello
    I have done some projets, and here some tips what I have used. They may not suitable for your environments, just for your reference.
    1.Should the EJB developers each have their own EJB container?
      Yes, Abosultely yes.
    2.Question 2.
      It depends on what servers you choose. If you choose weblogic6.0, you can code a script and deploy all this ejbs
    many machines. But, if you use weblogic5.1, it will take some while to target all these ejbs to different machines.
    3. The JSP developer don't need their own commercial
       servlet engine. but, they can download a free servlet
       engine just for syntax error. If you these jsp need to
       contact ejb tier, the jsp developer can use a central
       machine.
    4. IDE
       we are using Webgain profession 4.1. It is pretty good.
       the latest version for Webgain profession 4.1 can
       combine weblogic6.0 for debugging.
    Best Regards
    Yihua He


  17. As you will have seen from the discussions the configuration and deployment is by no means straight forward. Additional configuration issues such as databases, version control, properties files and inter-system connectivity add to the challenge of getting every thing to work together smoothly.

    I would strongly suggest that you appoint a specialist "configuration management" / deployment person to be responsible for all of this lot reporting in to your technical lead. They are generally cheaper than Java Developers. Developers have been known to focus on getting their bit of code to work and not paying too much attention to standards. Depending on the project size this person might also verify junit tests are done, javadoc is appropriate etc etc. They should be sufficiently hands on to use and develop scripts etc themselves rather than beating up on programmers to follow some half baken "standard" they have invented.

    Rgds
    David

  18. I will just give the comments

    1. It probably best for each developer to have there only copy of the server. Many companies use JBoss for development and then move it to weblogic after its developed. JBoss uses less resources than weblogic.

    2. With Together ControlCenter http://www.togethersoft.com you can model, build, and deploy applications as well as debug JSP's, servlets, and EJB's all while sharing the codebase among all members of the team via a standard version control interface. Check it out!

    3. Together ControlCenter comes buyndle with Tomcat for testing and debugging your JSP's and then you can just deploy the app to your webserver.

    4. No, Together supports redeployment of beans so the a central server should not be a problem.

    5.

    6. Together Control Center provides diagrams for deploying ear, war, and ejb archives. The process just makes sense because its built to support the J2EE Architecture. No descriptor stuff and 1 click ejb development.

    7. I suggest taking a look at manyof the IDE's out there, but definetly check out Together ControlCenter. Each of the items you mentioned is supported by Together.

    Hope this helps!
  19. Hi,
    I recently lead a team which was involved in J2EE platform based development with BEA WLS6.0 Application Server.
    I exactly was concerned with same issues as faced by you. But here was the stratagay that I practised in my team.

    1) Should the EJB developers each have their own EJB container?

    Ans:
    Yes, each dev. should have their own EJB conatiners. The most obvious reason for this is to reduce component dependensies and increase isolation. Dependency b/w the components can result in increase dev. and intigration time.


    2) EJB developers can use each others code by using some sort of version control software - However, EJBs need to be deployed (not just copied across to a developers local environment) - So can scripts be written to allow each developer to easily deploy ALL the EJBs without each EJB developer spending loads of time going through a manual deploy process each time? What tools?

    Ans:
    Yes, any source code control can be used to control the code. But, EJBs need to be deployed on the app. server. And deployement process differs from one app. server to another.
    For our dev. we created bat files on NT. They were responsible for compiling, genereating containers for EJBs and then deploying.
    Deployment wasn't done using bat. files as I faces few issues in WLS6.0 command line deployment utility.


    4) Now, the JSP developers also need access to the EJBs - Should each JSP developer have their own EJB container as well, or share a central one? Remember that there will be on-going development, bugs, changes etc in the EJBs in paralell with the JSP development - the restaring of servers etc will have huge impact on developers - What are the recommended practices here?


    Ans:
    Yes, each JSP dev. should have his own conatainers once again to reduce dependency, restarting problems, etc.


    6) Assume that the final implementation will seperate the JSP/Servlet container from the EJB container - There will be certain classes that will be required to be present in both the EJB container and in the JSP engine (e.g. EJB home and remote interfaces, value objects, etc). Thus, there may be certain classes within a large number of the EJB packages that need to be "picked out" and included in our WAR file.It seems to me like a HUGE job to figure out what exactly needs to be where, and then to extract it all! So, what tools/techniques can be used to assist in this rather tedious and very error-prone process? Or perhaps, I need to design my packages more appropriately - Is it normal to have the home and remote interfaces of an EJB in the same package as the implementation of the EJB?

    Ans:

    In our case, we also had few utility classess which were common among several components e.g. servlets, ejbs and apps. What we did was, we used WLS classpaths to place such utility files in jar format/ dir. expanded format.
    This way we reduced the doplication of class file placment at different places.

    7) Any of the above effected by the hefty task of debugging the application?

    Ans:
    IBM VAJ is good in terms of dev. and deb. But I haven't used it for WLS dev. as VAJ is behind the specs. and we used EJB2.0.

    8) Have any of you any opinions on the latest IDEs, some of which include a Servlet engine (thus allowing easier debugging), and others actially including some sort of minature EJB container?

    Ans:
    VAJ is good if it start supporting latest specs.
    I haven't tried Visual Cafe's abilities for ejb debugging as it was not integrated for WLS6.0.
    But, we used a logging framework of our own to log and debug activities which atleast worked for us because we were logging most of the critical activities.


  20. Hi *,

    I just couldn't resist answering. You are interested in the question of how to achieve the most productive development process for J2EE applications and I enjoyed following the discussion.

    "
    2) EJB developers can use each others code by using some sort of version control software - However, EJBs need to be deployed (not just copied across to a developers local environment) - So can scripts be written to allow each developer to easily deploy ALL the EJBs without each EJB developer spending loads of time going through a manual deploy process each time? ***What tools?***
    "

    "
    6) Assume that the final implementation will seperate the JSP/Servlet container from the EJB container - There will be certain classes that will be required to be present in both the EJB container and in the JSP engine (e.g. EJB home and remote interfaces, value objects, etc). Thus, there may be certain classes within a large number of the EJB packages that need to be "picked out" and included in our WAR file.It seems to me like a HUGE job to figure out what exactly needs to be where, and then to extract it all! So, what ***tools***/techniques can be used to assist in this rather tedious and very error-prone process? Or perhaps, I need to design my packages more appropriately - Is it normal to have the home and remote interfaces of an EJB in the same package as the implementation of the EJB?
    "

    You are right: a tool can help you very much, here is the one I use:

    I never write any build scripts or deployment descriptors by hand - I generate everything using the ArcStyler (www.ArcStyler.com). Actually it generates a lot more, and it is container-independent. The idea is that developers can focus on the business logic and don't need to care about the diffences between containers and such things.

    Note that I work for Interactive Objects, the company developing the ArcStyler Tool Suite - I am not going to fill this mail with marketing stuff, if you are interested, you should check our website and test yourself.

    ciao, Philip
  21. For the last 2 1/2 years I have been developing J2EE web applications and here is my advice to you.

    Answer to #1
    ------------
      Yes, every developer that is developing EJBs should have their own container when it is time. What I mean by that is this, EJB development is very slow when you have to stop and start an application server every time you want to make a change.(specially weblogic). My advice is to develop your biz objects as regular java objects then at the end, if it make sense, convert them to EJBs.

    Answer to #2
    ------------
      Jbuilder, JBuilder, JBuilder enterprise has the best features for sharing and deploying EJBs. They use EJB groups to build, run, and deploy EJBs to a verity of application servers. We check our EJB jar files into source control, so developers don't have to build other peoples EJBs.

    Answer to #3
    ------------
    Once again use JBuilder. Tomcat is integrated into the IDE which makes life real easy for developing servlet's/jsp's.

    Answer to #4
    ------------
    I have taken two approaches on this one. First, where everyone had the application server on their machines and all development was done in the applications server. The development cycle for this was painfully slow. The time it takes weblogic to start and deploy 20 beans in debug mode, I could have lunch. The second approach I took was to use Tomcat and not use the application server until it was absolutely necessary. This work great!! This evolves not developing EJBs until you were sure your biz objects were ready for prime time.

    Answer to #5
    ------------
      Do you mean hot deployment?

    Answer to #6
    ------------
      This is a problem that I am also trying to find a best practice for. The big problem comes when you want to update a live system. You might have reference to a class in your EJB jar and you WAR file.(=EAR) I thought about separating my packages but that seemed like a "hack" and would confuse the situation even more.

    Answer to #7
    ------------
      Debugging gets a little tricky in some of the new application servers because you don't put your files in the classpath. You point to a war,ear,jar file and the application server loads them dynamically. This makes debugging a little tricky.

    Answer to #8
    ------------
      As one can see I'm a big fan of JBuilder. It is by far the best IDE on the market. I've tried to use Visual Cafe(drop off the face of the earth) and Visual Age(cumbersome), but JBuilder blows them away!! I would go request a 30 day eval of JBuilder enterprise.

    I hope this helped,
    -cb
  22. I was using JBuilder for the past few months and it is a major memory hog. I had an IBM T20 with 700Mhz processor and 256Mb RAM. At least half a dozen times per day it 'went to sleep' for a couple of minutes which became very annoying. The only reason I would use JBuilder would be :
    1. If I had no choice - like this project or
    2. I had at least 512MB RAM

    All developers on the team suffered similar expericences.
    I am not saying that other IDEs are better though!!!
  23. Paddy,
    I work on IONA iPortal Application Server and I will be presenting a developer to developer webcast on the iPAS development environment on Wed 17th at 1pm EST. See http://www.iona.com/info/aboutus/events/dd.htm for registration details. This webcast will address many of the issues you have raised here.

    Regards,
    Tom Byrne
    iPAS Engineering Manager
  24. A short suggestion to a lengthy question: visit www.sygel.com. The WMEE will do a great job in your project.

    Regards,

    Bart.