RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Please, don't mix both things. You are on JBoss-dev = we speak about jboss-development. As such, JBoss 4.0 will have a brand new AOP infrastructure, generalized services, etc. And, on top of this, will sit the J2EE layer. No FUD please!!! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rahul Ganjoo Sent: lundi, 24. mars 2003 09:23 To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath? 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
RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
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
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
I have never heard any of the main developers talk about JBoss4 _not_ being J2EE compatible. It has always been my understanding that the AOP framework would form the underpinnings of JBoss4's EJB implementation and be available as a more-flexible, lighter weight API for people who aren't concerned with portability. Scott, Bill, Marc - can one of you clarify? thanks, danch Rahul Ganjoo wrote: 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? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Being compliant and the AOP features are not mutually exclusive. We will do both. To Brian Wallis, even if Jboss were to get certified, it would not make your J2EE compliant applications portable. Why? There are may important things considered outside the specification. For example, all database mappings for CMP are outside the spec, even using a database for CMP is outside the spec. Then you get into things like exception recovery and tuning, and you are way outside the spec. Unless you have a very simple application it will not be portable without multiple configuration files and possibly a portably a portability layer. Having the TDK would be nice to help identify new bugs, and eliminate the of the minor differences between the platforms, but I doubt it will seriously help you with making a cross platform application. -dain On Monday, March 24, 2003, at 07:52 AM, danch wrote: I have never heard any of the main developers talk about JBoss4 _not_ being J2EE compatible. It has always been my understanding that the AOP framework would form the underpinnings of JBoss4's EJB implementation and be available as a more-flexible, lighter weight API for people who aren't concerned with portability. Scott, Bill, Marc - can one of you clarify? thanks, danch Rahul Ganjoo wrote: 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? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
That is precisely correct Dan, marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of danch Sent: Monday, March 24, 2003 8:53 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath? I have never heard any of the main developers talk about JBoss4 _not_ being J2EE compatible. It has always been my understanding that the AOP framework would form the underpinnings of JBoss4's EJB implementation and be available as a more-flexible, lighter weight API for people who aren't concerned with portability. Scott, Bill, Marc - can one of you clarify? thanks, danch Rahul Ganjoo wrote: 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? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Obviously, being J2EE compliant is not my call, just expressing my opinion. Would really be nice if Marc, Bill, or Scott could chime in. You guys there? What is your plan in regards to this for JBoss 4? Dain Sundstrom wrote: Being compliant and the AOP features are not mutually exclusive. We will do both. To Brian Wallis, even if Jboss were to get certified, it would not make your J2EE compliant applications portable. Why? There are may important things considered outside the specification. For example, all database mappings for CMP are outside the spec, even using a database for CMP is outside the spec. Then you get into things like exception recovery and tuning, and you are way outside the spec. Unless you have a very simple application it will not be portable without multiple configuration files and possibly a portably a portability layer. Having the TDK would be nice to help identify new bugs, and eliminate the of the minor differences between the platforms, but I doubt it will seriously help you with making a cross platform application. -dain On Monday, March 24, 2003, at 07:52 AM, danch wrote: I have never heard any of the main developers talk about JBoss4 _not_ being J2EE compatible. It has always been my understanding that the AOP framework would form the underpinnings of JBoss4's EJB implementation and be available as a more-flexible, lighter weight API for people who aren't concerned with portability. Scott, Bill, Marc - can one of you clarify? thanks, danch Rahul Ganjoo wrote: 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? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
J2EE is our bread and butter. Its why most people initially come to JBoss.
We will continue to follow the specs religiously.
AOP + EJB:
For JB4, the average every-day J2EE developer won't notice anything. But,
implementing EJB in terms of the AOP framework will greatly enhance the
abilities of ISV's, system integrators, and third-party tool vendors to
tightly integrate with JBoss.
How?
1) The JBoss 3.x series has some limitations in regard to interceptor chains
and configuration. Sure, you can add new interceptors easily to container
configurations, but, if you want to add any time of configuration, you have
to modify JBoss code. AOP will provide a pluggable mechanism for those who
want to extend JBoss configuration. Basically, interceptors and their
configuration will be formalized into a packaged format. You'll be able to
deploy extensions to the EJB framework in much the same way you deploy a
SAR, WAR, EAR, RAR, etc
2) The AOP framework will also give third-party integrators the ability to
actually expand the EJB API. For instance, if a distributed caching vendor
wanted to provide a Caching API to every EJB deployed they could easily do
it as a deployed package. Users will be able to use these new API's simply
by typecasting:
{
MyEJB ejb = home.create();
CacheAPI cachedObj = (CacheAPI)ejb;
cachedObj.flushCache();
}
3) In JB4, metadata/configuration will be resolved through the context of
the Invocation enabling interceptors to override existing configuration on
one side, or to provide default configuration values cross-cluster.
IMHO, these features alone will make JBoss the preferred platform for ISV
integration since they will so easily, completely, and tightly be able to
integrate their products with all aspects of JBoss.
New AOP Services: Beyond J2EE
Now for beyond J2EE, we're also doing some very cool things. IMO, Aspect
Oriented Programming is the next big wave on par of what OOP did to
functional programming. One of our main goals is to totally isolate
infrastructure from business logic by providing system-level aspects for:
security, transaction demarcation, caching, ACIDity, remoteness, clustering,
and persistence. This means you can write plain old Java classes and either
statically or dynamically apply these types of aspects making your business
logic totally INDEPENDENT of any system level API's. This is a grand
departure from following specifications like CORBA or J2EE in that these
standards create specification lock-in.
AOP gives us other advantages as well by being able to dynamically attach
behavior to any type of object at runtime. Need to dynamically monitor a
specific object for debugging purposes? Deploy and aspect at runtime. Need
to expand the scope of a system-level aspect? Write your own interceptor.
Need to apply your own system-wide proprietary API? AOP will provide you
with the hooks.
Our new AOP framework and services, also, IMHO, take you beyond J2EE where
J2EE fails or is inflexible. For instance, the J2EE specification really
has no concrete concept or definition of caching or ACIDity.
Conclusion:
We are strictly adhering to the new J2EE 1.4 and EJB 2.1 specifications.
J2EE is a fine and good specification and JBoss will remain J2EE compliant.
The new AOP framework will allow JBoss extension writers better and tighter
integration with EJB and the rest of the JBoss core. The AOP framework and
AOP services will take developers beyond J2EE to simplify application
development and provide services where J2EE leaves off. Development with
JBoss AOP finally allows business logic to be totally INDEPENDENT of
system-level infrastructure.
Regards,
Bill Burke
Chief Architect
JBoss Group, LLC
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Tom
Elrod
Sent: Monday, March 24, 2003 10:54 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Obviously, being J2EE compliant is not my call, just expressing
my opinion.
Would really be nice if Marc, Bill, or Scott could chime in. You
guys there?
What is your plan in regards to this for JBoss 4?
Dain Sundstrom wrote:
Being compliant and the AOP features are not mutually exclusive. We
will do both.
To Brian Wallis, even if Jboss were to get certified, it would not make
your J2EE compliant applications portable. Why? There are may
important things considered outside the specification. For example,
all database mappings for CMP are outside the spec, even using a
database for CMP is outside the spec. Then you get into things like
exception recovery and tuning, and you are way outside the spec.
Unless you have a very simple application it will not be portable
without multiple configuration files and possibly a portably a
portability layer.
Having the TDK would be nice to help identify new bugs, and eliminate
the of the minor differences between the platforms, but I doubt
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
On Tue, 25 Mar 2003 01:16, Dain Sundstrom wrote: To Brian Wallis, even if Jboss were to get certified, it would not make your J2EE compliant applications portable. Why? There are may important things considered outside the specification. For example, all database mappings for CMP are outside the spec, even using a database for CMP is outside the spec. Then you get into things like exception recovery and tuning, and you are way outside the spec. Unless you have a very simple application it will not be portable without multiple configuration files and possibly a portably a portability layer. Yeh, well. That doesn't mean it isn't possible and that it isn't a goal required by more than one organisation that allows you to use software like JBoss (and TAO, OpenORB, etc..) See Herve Tchepannou's xpetstore for a good non-trivial example of what can be done. I have been writing more (and less) portable software for about 13 years now and know what is involved. There are always difficulties. But if there are standards used and adhered to it makes it easier. Writing an app that is portable between a J2EE server and .NET would be far more difficult, or portable to ObjectSpace's voyager or to a distributed agent platform, etc. Usually you don't need to actually do it, just convince the management that you can do it (and easily, at no cost, etc.. :-) If JBoss adheres to the standards as they are and will be then I will be able to keep using it. If it doesn't then (despite what I want to do) I probably won't be given the opportunity to keep using it. Remember, the customer is always right and you can't always punish them for the arrogance (apologies to Dogbert and Scott Adams :-) --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
If JBoss adheres to the standards as they are and will be then I will be able to keep using it. If it doesn't then (despite what I want to do) I probably won't be given the opportunity to keep using it. Please ignore the FUD from SUN. We have and always will strictly abide by the standards. Bill Burke Chief Architect JBoss Group, LLC --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
On Tue, 25 Mar 2003 17:07, Bill Burke wrote: Please ignore the FUD from SUN. We have and always will strictly abide by the standards. As I expected you would. Thanks and keep up the great work! brian wallis... --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
On Saturday, Mar 22, 2003, at 23:03 Europe/Amsterdam, Tom Coleman wrote: ... Personally, certification is irrelevant to me. My criteria is whether or not the product gets the job done. I think certification serves to answer that question for people who don't know how to figure it out for themselves. I have a different view on that. I think certification is important because by running all those tests we will find a lot of new bugs in JBoss. Certification will make it a better product because *all* parts of the specification will be touched instead of just what people are using. I agree that certification is not that important to sell the product, but from a development / testing perspective it is *very* useful. S. --- 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
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
On Sunday, March 23, 2003, at 04:19 PM, Stefan Arentz wrote: On Saturday, Mar 22, 2003, at 23:03 Europe/Amsterdam, Tom Coleman wrote: Personally, certification is irrelevant to me. My criteria is whether or not the product gets the job done. I think certification serves to answer that question for people who don't know how to figure it out for themselves. I have a different view on that. I think certification is important because by running all those tests we will find a lot of new bugs in JBoss. Certification will make it a better product because *all* parts of the specification will be touched instead of just what people are using. I agree that certification is not that important to sell the product, but from a development / testing perspective it is *very* useful. The more tests we have the better we will be, but I doubt that sun will let us check the TDK into CVS, so it will be worthless to everyone but the few JBoss employees that get access. -dain --- 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
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
--- Dain Sundstrom [EMAIL PROTECTED] wrote: The more tests we have the better we will be, but I doubt that sun will let us check the TDK into CVS, so it will be worthless to everyone but the few JBoss employees that get access. -dain Is a condition of the TDK license that you can't use the information about your source tree that it reveals to improve the product? Does it specifically bar you from writing JUnit test cases which test for a bug which just happens to be a bug regarding spec compliance? Dave __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com --- 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
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
On Sunday, March 23, 2003, at 07:30 PM, Dave Neuer wrote: --- Dain Sundstrom [EMAIL PROTECTED] wrote: The more tests we have the better we will be, but I doubt that sun will let us check the TDK into CVS, so it will be worthless to everyone but the few JBoss employees that get access. -dain Is a condition of the TDK license that you can't use the information about your source tree that it reveals to improve the product? Does it specifically bar you from writing JUnit test cases which test for a bug which just happens to be a bug regarding spec compliance? Got me. Where did you find the license to the J2EE TDK license? -dain --- 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
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
--- Dain Sundstrom [EMAIL PROTECTED] wrote: On Sunday, March 23, 2003, at 07:30 PM, Dave Neuer wrote: --- Dain Sundstrom [EMAIL PROTECTED] wrote: The more tests we have the better we will be, but I doubt that sun will let us check the TDK into CVS, so it will be worthless to everyone but the few JBoss employees that get access. -dain Is a condition of the TDK license that you can't use the information about your source tree that it reveals to improve the product? Does it specifically bar you from writing JUnit test cases which test for a bug which just happens to be a bug regarding spec compliance? Got me. Where did you find the license to the J2EE TDK license? -dain I didn't, I was asking you ;-). Seriously, I can imagine Sun has got some onerous conditions in there compatabitliy test kit license. However, if JBoss can't pass the tests, it's because of bugs (i.e., missing features) in the code, and I can't imagine that even if the license for the test kit somehow prohibits you from sharing the kit itself or the results, it would also restrict you from fixing bugs in your source code, whatever those bugs might be. I mean, Sun's J2EE specs are public. It'd be tough for their lawyers to prove you fixed a bug or added a feature just because you ran the tests. But, to an extent it would be beside the point. I'm working now on a project to replace a Lotus Notes/Domino application and the management of the company brought me on because *they* chose JBoss to replace it, and I've taken the advanced training. They didn't seem to concerned about spec compliance. They care about performance, flexibility, and no $3000/CPU licensing. Spec compliance is valuable because it provides (in theory, at least) predictable behavior when you don't have the source of the application. When you've got the source, you don't need predictable behavior; everything is completely transparent. You can turn on source-level debugging and step through the code! Don't like how it does feature X? Fix it! Certified spec compliance for JBoss would be nice for one little extra marketing buzzword. But at this point, JBoss probably has enough momentum that spec compliance could be at most icing on the cake. You know for sure that if someone out there needs some in-spec feature that JBoss doesn't have bad enough, they'll send a patch to add it. Dave __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com --- 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
RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
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. If Sun would have made this offer a year ago, might of been worth pursuing. -Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Neuer Sent: Sunday, March 23, 2003 10:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath? --- Dain Sundstrom [EMAIL PROTECTED] wrote: On Sunday, March 23, 2003, at 07:30 PM, Dave Neuer wrote: --- Dain Sundstrom [EMAIL PROTECTED] wrote: The more tests we have the better we will be, but I doubt that sun will let us check the TDK into CVS, so it will be worthless to everyone but the few JBoss employees that get access. -dain Is a condition of the TDK license that you can't use the information about your source tree that it reveals to improve the product? Does it specifically bar you from writing JUnit test cases which test for a bug which just happens to be a bug regarding spec compliance? Got me. Where did you find the license to the J2EE TDK license? -dain I didn't, I was asking you ;-). Seriously, I can imagine Sun has got some onerous conditions in there compatabitliy test kit license. However, if JBoss can't pass the tests, it's because of bugs (i.e., missing features) in the code, and I can't imagine that even if the license for the test kit somehow prohibits you from sharing the kit itself or the results, it would also restrict you from fixing bugs in your source code, whatever those bugs might be. I mean, Sun's J2EE specs are public. It'd be tough for their lawyers to prove you fixed a bug or added a feature just because you ran the tests. But, to an extent it would be beside the point. I'm working now on a project to replace a Lotus Notes/Domino application and the management of the company brought me on because *they* chose JBoss to replace it, and I've taken the advanced training. They didn't seem to concerned about spec compliance. They care about performance, flexibility, and no $3000/CPU licensing. Spec compliance is valuable because it provides (in theory, at least) predictable behavior when you don't have the source of the application. When you've got the source, you don't need predictable behavior; everything is completely transparent. You can turn on source-level debugging and step through the code! Don't like how it does feature X? Fix it! Certified spec compliance for JBoss would be nice for one little extra marketing buzzword. But at this point, JBoss probably has enough momentum that spec compliance could be at most icing on the cake. You know for sure that if someone out there needs some in-spec feature that JBoss doesn't have bad enough, they'll send a patch to add it. Dave __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com --- 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
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
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Certification tests are important for corporates - they protect their investment in development by ensuring that if one companies vision (ie jboss/websphere etc) goes belly-up then switching to another server will provide the least set of headaches. 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. If Sun would have made this offer a year ago, might of been worth pursuing. -Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Neuer Sent: Sunday, March 23, 2003 10:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath? --- Dain Sundstrom [EMAIL PROTECTED] wrote: On Sunday, March 23, 2003, at 07:30 PM, Dave Neuer wrote: --- Dain Sundstrom [EMAIL PROTECTED] wrote: The more tests we have the better we will be, but I doubt that sun will let us check the TDK into CVS, so it will be worthless to everyone but the few JBoss employees that get access. -dain Is a condition of the TDK license that you can't use the information about your source tree that it reveals to improve the product? Does it specifically bar you from writing JUnit test cases which test for a bug which just happens to be a bug regarding spec compliance? Got me. Where did you find the license to the J2EE TDK license? -dain I didn't, I was asking you ;-). Seriously, I can imagine Sun has got some onerous conditions in there compatabitliy test kit license. However, if JBoss can't pass the tests, it's because of bugs (i.e., missing features) in the code, and I can't imagine that even if the license for the test kit somehow prohibits you from sharing the kit itself or the results, it would also restrict you from fixing bugs in your source code, whatever those bugs might be. I mean, Sun's J2EE specs are public. It'd be tough for their lawyers to prove you fixed a bug or added a feature just because you ran the tests. But, to an extent it would be beside the point. I'm working now on a project to replace a Lotus Notes/Domino application and the management of the company brought me on because *they* chose JBoss to replace it, and I've taken the advanced training. They didn't seem to concerned about spec compliance. They care about performance, flexibility, and no $3000/CPU licensing. Spec compliance is valuable because it provides (in theory, at least) predictable behavior when you don't have the source of the application. When you've got the source, you don't need predictable behavior; everything is completely transparent. You can turn on source-level debugging and step through the code! Don't like how it does feature X? Fix it! Certified spec compliance for JBoss would be nice for one little extra marketing buzzword. But at this point, JBoss probably has enough momentum that spec compliance could be at most icing on the cake. You know for sure that if someone out there needs some in-spec feature that JBoss doesn't have bad enough, they'll send a patch to add it. Dave __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com --- 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
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
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Don't be too sure that there isn't a number of months of effort to pass the conformance suite. There are lots of edge cases and areas of interpretation when implementing from a spec. Unless they give the compliance testing to Bill Burke. He could probably get it done in a weekend. Personally, certification is irrelevant to me. My criteria is whether or not the product gets the job done. I think certification serves to answer that question for people who don't know how to figure it out for themselves. I'm doing an integration with a partner that uses a certified server. Their server crashes. My server doesn't. --- 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
Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Tom Coleman wrote: Don't be too sure that there isn't a number of months of effort to pass the conformance suite. There are lots of edge cases and areas of interpretation when implementing from a spec. Unless they give the compliance testing to Bill Burke. He could probably get it done in a weekend. Personally, certification is irrelevant to me. My criteria is whether or not the product gets the job done. I think certification serves to answer that question for people who don't know how to figure it out for themselves. I'm doing an integration with a partner that uses a certified server. Their server crashes. My server doesn't. So really people use certification instead of asking if the product gets the job done. Unfortunately there are a lot of people making infrastructure decisions who are either naive enough to do that or who are hamstrung by beancounters who are. Also, in a lot of cases, a certification like that can wind up as a checklist item, and a lack of a check in that column can just force technical people to have to waste a lot of time explaining the political situation, which makes executives nervous... -danch --- 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
RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
It's interesting, since I didn't think anyone in JBoss was bluffing.
Question, though: JBoss is free, right? Therefore, before Sun goes around with the
bravado, couldn't they have downloaded JBoss and run it against the compliance suite
to know if it would pass or not? It seems to me that, if anyone's bluffing, it's them.
-Original Message-
From: Jeff Haynie [mailto:[EMAIL PROTECTED]
Sent: Thu 3/20/2003 8:51 PM
To: [EMAIL PROTECTED]
Cc:
Subject: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Famous quote from Sun on News.com:
http://news.com.com/2100-1013-993471.html?tag=fd_top
'Phipps said Wednesday that making the compliance test available will
make it clear that Sun does not want to intentionally obstruct JBoss
Group's efforts to gain J2EE compliance.
However, Phipps said he doubts that JBoss software will pass the
compliance test. Basing his opinion on public information, he said,
JBoss software does not appear to implement all of the J2EE
specification.
I predict that now that we're calling their bluff, they will make up
another excuse for not doing the tests, Phipps said. '
So, Sun's calling our bluff???
---
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
+,~wzf¢+,¦o$áyyézW(ëhæ¯zxm¶ÿ¶§ÊþÇÉn,uëfz{fj)b
b²Ò[¢Ë zÙb²Û,¢êÜyú+ém¦Ïÿ+-²Ê.¢¸ ë+-³ùb²~ãn,uëfz{
RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Don't be too sure that there isn't a number of months of effort to pass the
conformance suite. There are lots of edge cases and areas of interpretation
when implementing from a spec. There are also stupid things in specs that
implementers chose to implement differently with just cause.
Certainly the bits that developers care about are compatible.
The issue may be more about putting in the effort to do marginally useful
changes just to pass the conformance suite when there are some beautiful 4.0
features to work on, but maybe both can get done if everyone submits a patch
or two...
-Fred
-Original Message-
From: Rhett Aultman [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 7:12 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
It's interesting, since I didn't think anyone in JBoss was bluffing.
Question, though: JBoss is free, right? Therefore, before Sun goes around
with the bravado, couldn't they have downloaded JBoss and run it against the
compliance suite to know if it would pass or not? It seems to me that, if
anyone's bluffing, it's them.
-Original Message-
From: Jeff Haynie [mailto:[EMAIL PROTECTED]
Sent: Thu 3/20/2003 8:51 PM
To: [EMAIL PROTECTED]
Cc:
Subject: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Famous quote from Sun on News.com:
http://news.com.com/2100-1013-993471.html?tag=fd_top
'Phipps said Wednesday that making the compliance test available
will
make it clear that Sun does not want to intentionally obstruct JBoss
Group's efforts to gain J2EE compliance.
However, Phipps said he doubts that JBoss software will pass the
compliance test. Basing his opinion on public information, he said,
JBoss software does not appear to implement all of the J2EE
specification.
I predict that now that we're calling their bluff, they will make
up
another excuse for not doing the tests, Phipps said. '
So, Sun's calling our bluff???
---
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
NX'u)Y\gbH zG( %,zZ)x%In,ufz{elqzm?X( ~zwXb?,zZ)
---
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
RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
I'll be waiting to catch the flotsam work if/when that happens. I'm sure a lot of us
minor players will.
Still, my question stands- Sun could have downloaded JBoss and tested it on their own,
couldn't they? Why make comments like we don't think they'll pass then?
-Original Message-
From: Fred Hartman [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 4:21 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Don't be too sure that there isn't a number of months of effort to pass the
conformance suite. There are lots of edge cases and areas of interpretation
when implementing from a spec. There are also stupid things in specs that
implementers chose to implement differently with just cause.
Certainly the bits that developers care about are compatible.
The issue may be more about putting in the effort to do marginally useful
changes just to pass the conformance suite when there are some beautiful 4.0
features to work on, but maybe both can get done if everyone submits a patch
or two...
-Fred
-Original Message-
From: Rhett Aultman [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 7:12 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
It's interesting, since I didn't think anyone in JBoss was bluffing.
Question, though: JBoss is free, right? Therefore, before Sun goes around
with the bravado, couldn't they have downloaded JBoss and run it against the
compliance suite to know if it would pass or not? It seems to me that, if
anyone's bluffing, it's them.
-Original Message-
From: Jeff Haynie [mailto:[EMAIL PROTECTED]
Sent: Thu 3/20/2003 8:51 PM
To: [EMAIL PROTECTED]
Cc:
Subject: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
Famous quote from Sun on News.com:
http://news.com.com/2100-1013-993471.html?tag=fd_top
'Phipps said Wednesday that making the compliance test available
will
make it clear that Sun does not want to intentionally obstruct JBoss
Group's efforts to gain J2EE compliance.
However, Phipps said he doubts that JBoss software will pass the
compliance test. Basing his opinion on public information, he said,
JBoss software does not appear to implement all of the J2EE
specification.
I predict that now that we're calling their bluff, they will make
up
another excuse for not doing the tests, Phipps said. '
So, Sun's calling our bluff???
---
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
NX'u)Y\gbH zG( %,zZ)x%In,ufz{elqzm?X( ~zwXb?,zZ)
---
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
N¬HYX¬²'²Þu¼¯*m (ZW§(¥éÆz×+iɧv· Ë^®«yú+²)Ýn
)à~éÛayÈZ§)àjp)¦W¢a¶Úý§l²«qç讧zßâúÞv*ÞrÚe¶°ÓMõzr[¢Ë zX§X¬´è²Ç^½éh¦g§¶X¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)øË z
