"but one of the goals of JBoss 4 is to make it so developers don't have to deal with all the J2EE APIs"
from this and the discussion in general.. Jboss4 and J2EE compliance are two entirely different "roadmaps" (IMHU).. i mean its important for everyone here to know what direction Jboss is going to take.. is j2EE compliance important and is Jboss going for it..or is it keeping up the Jboss4 AOP vision and hence chucking compliance? -----Original Message----- From: Tom Elrod [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 1:15 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath? I don't want to steal too much of Marc's thunder on this (he has a great vision for JBoss 4), but one of the goals of JBoss 4 is to make it so developers don't have to deal with all the J2EE APIs (which honestly add a lot of overhead in development time as well as training/study time to learn it all). For example, with EJBs, you have the remote, home, and implementation to keep up with. With JBoss 4, you would be able to write a POJO with all you business logic and plug-in (via configuration) all the extra pieces you want (remoting, persistence, caching, transaction, security, etc.). This makes the process much easier for you, the developer, since you won't have to worry about all the extra code (which usually ends up being 25% business logic and the rest infrastructure when you look at lines of code). Only extra effort required is to configure the extra services you want (which will take much less time than coding it). Of course, if you decide to migrate to another application server, you'll have write all the extra infrastructure code yourself to make it fully J2EE compatible. Even if for some reason you decide you want to pay for an application server where you don't have access to the source, this would probably be a good way to start a development project, since the business logic will be the core of your product. As from a corporate perspective, JBoss, in general, makes sense over other application servers. The two major reasons are both the source and the runtime are free. So the only question would be does it work well (functionality, performance, scalability) and can I get support for it? The first one is somewhat a matter of opinion, but I think it has proven itself in production. Support is available for a fee (but you're getting the guys that actually wrote it, so you know they know what they are doing). If JBoss does ever change its direction, you'll still have the source so you could still maintain what you needed. If you bought an app. server from a company that changes direction, then you would end up having to pay again for some other company's app. server to get what you want (so you're out you initial investment, plus it might happen again and you have not other course of action without source). I personally feel that the only real reason for paying for an application server is if it allows you to get a price break on some other part of a package deal (i.e. hardware). Then you have to decide if you're getting enough savings on the hardware to offset the price of the software. Of course, this is just my opinion, but would love to hear exactly why companies would want to pay for an application server. -Tom > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Brian > Wallis > Sent: Monday, March 24, 2003 1:34 AM > To: [EMAIL PROTECTED]; Tom Elrod > Subject: Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath? > > > On Mon, 24 Mar 2003 16:42, Tom Elrod wrote: > > IMHO, I don't know that passing the certification tests now > would be of > > much benefit to JBoss. The biggest drawback I can see is > that with JBoss > > 4, we will be moving people away from having to deal with > all the extra API > > non-sense that J2EE developers have to deal with today. > Just write your > > POJOs and we'll do the rest (persistence, caching, > security, remoting, > > etc.). If we get certified now, might be added pressure to > make JBoss 4 > > compliant as well, which I think would divert us from our current > > direction. > > IMHO, that would be about it for anyone (like me) who is trying to use > jboss as well as other appservers. I seriously hope that jboss 4 > will be fully > compliant with the standards or else I fear it will become > marginalised and > in all likely hood die off. > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! Get > cracking and register here for some mind boggling fun and the chance > of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
