JBoss 4 DR2 Released with expanded AOP, JDO, JMS Features

Home

News: JBoss 4 DR2 Released with expanded AOP, JDO, JMS Features

  1. JBoss has posted developer release 2 of JBoss 4 which improves over previous releases with more AOP functionality, C# like Metatags, the firt iteration of JDO, and P2P JMS Topics over reliable multicast. An AOP framework that can run separate from the application server is also provided.

    Visit http://www.jboss.org/.

    Specific additions to this release include:

    AOP:
    * C#-like Metatags with our XDoclet Integration. From the excellent work of Andy Godwin.
    * Expanded AOP Pointcuts. Caller pointcuts. Metatag pointcuts. Per-method, field, and constructor pointcuts/interceptor chains
    * Framework performance Improvements. (Factor of 6)

    JDO:
    * JBossDO. JDO for transperent persistence for POJOs.
    * First iteration from the hard work of Alex Loubyansky.

    JMS:
    * JMS rewrite. First iteration from Nathan Phelps with help from Bela Ban and Adrian Brock.
    * P2P serverless topics by way of reliable multicast.

    Threaded Messages (117)

  2. Sweet. Congrats to Nathan on new JMS! The old one has been limping along for a while.

    Steve
  3. Is ther any docs on JBoss 4.0 or do the things in 3.0 still apply?

    .V
  4. JDO[ Go to top ]

    JDO support is really welcome. I'm looking forward to checking this out.
  5. JDO[ Go to top ]

    JDO support is really welcome. I'm looking forward to checking this out.


    hmmm haven't you tried to use Castor JDO ?
  6. JDO[ Go to top ]

    Just in case you were wondering, Castor JDO is a proprietary persistence product with no relationship to the JSR-12 Java Data Objects specification, except that it has the letters 'J', 'D' and 'O' in its name.

    Please do not judge JDO on your experience of Castor JDO since it's not the same thing at all.

    Kind regards, Robin.
  7. * Expanded AOP Pointcuts. Caller pointcuts. Metatag pointcuts. Per-method, field, and constructor pointcuts/interceptor chains

    > * Framework performance Improvements. (Factor of 6)

    Nice to see them address the performance that those in the blogosphere were beating them up over.
  8. JDO[ Go to top ]

    It seems we have the first fruits of the 4th Open Source JDO initiative to enjoy. Congratulations to Alex Loubyansky.

    Are BEA, IBM and Oracle taking note?

    Kind regards, Robin.
  9. JDO[ Go to top ]

    It seems we have the first fruits of the 4th Open Source JDO initiative to enjoy. Congratulations to Alex Loubyansky.

    >
    > Are BEA, IBM and Oracle taking note?
    >
    > Kind regards, Robin.

    Yes there are... trying to kill it. Do they think JDO is dangerous ?
  10. Open Source as a leader[ Go to top ]

    Are BEA, IBM and Oracle taking note?

    > >
    > > Kind regards, Robin.
    >
    > Yes there are... trying to kill it. Do they think JDO is dangerous ?

    This industry is looking more and more like a joke. JBoss leads and BEA copies. I wouldn't be surprised if BEA announced support for JDO and AOP pretty soon.

    I sit here looking at the innovation and can't help but wonder, why does open source like JBoss go way faster than BEA? Is it because most of the brilliant minds are working in open source today and corporate development doesn't breed the same quality because they don't have the same pressure?

    Sometimes I wonder where all this will end up, if intelligent life exists in open source and jboss keeps on proving they can lead the field I wonder why I should pay for a container...

    It is not meant as a bait just seriously wondering, jboss' development is a fascinating thing.

    AOP on weblogic anyone? it would be such a joke and validation of the work the technologists at JBoss are doing, way to go bill.
  11. Open Source as a leader[ Go to top ]

    Lawrence: This industry is looking more and more like a joke. JBoss leads and BEA copies. I wouldn't be surprised if BEA announced support for JDO and AOP pretty soon.

    BEA announced their AOP project at the TSS Symposium last week-end. However, I heard of it a couple of months ago, so it is nothing new. There's a big difference between what BEA is doing (I'll compliment it by calling it "customer-driven AOP") versus what JBoss is doing (I'll compliment it by calling it "AOP-based application server architecture"), but at this point, they're both just prototypes, because everyone is still trying to figure out what AOP is and how it is useful to people in the real world.

    As far as BEA adopting JDO, I've been trying to convince them to do that for at least half a year, but so far, they're viewing it as a competitor to Entity EJB, so it isn't gaining traction inside their organization. Unfortunately, it's a loss to their customers, and certainly not a loss to their competitors. I am still suggesting that at least one major app server vendor (besides JBoss) is seriously looking at JDO inclusion ....

    Who knows, though, maybe WebLogic will come with Hibernate instead? ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  12. Open Source as a leader[ Go to top ]

    Cameron: BEA announced their AOP project at the TSS Symposium last week-end.


    thanks cameron, this is interesting news indeed. BEA is following the lead then. An open source player is establishing a track record for innovation in technology and has a crazy business model (give it away charge for support) and I wonder where this will end.

    I will tell you my fear, that they destroy the server side java market with their disruptive model because they are in fact leading in innovation and giving it away. Already it is clear that the major force today is open source and with a company born out of it it is even scarier. Sustained open souce is a new phenomena. Intelligent life in an open source business is disruptive.

    You don't seem worried but with AOP, better JMS, JDO and god knows what coming in the pipe all I see is blind momentum and good products but at what price to the rest of the industry. Competition is the basis but proprietary vendors don't compete, can't compete with Open Source, or can they?

    Do you think it is healthy? I can't sort it out.

    larry
  13. Hi there

    BEA ships an almost undocumented feature allowing to preprocess the bytecode of any class loaded during the deployement process of any app. This excludes app server wide libs / classes.

    Some tools like Willy Technology (performance management) relies on this stuff since many years (don't know for 6.0 but here since 6.1). That's not really AOP - ok - but you could pack an AOP solution for BEA since 2 years. BEA is innovative - you folks did not follow fast enough and waited JBoss noise to wake up.

    Search for "weblogic.classloader.preprocessor" system property.
    You ll find some stuff and Bob Lee JAdvise port to WebLogic - thus prior to JBoss AOP - (december 2002).

    System wide AOP in WebLogic can be set thru precompilation, or java.lang.classloader overloading.

    Alex
    --
    http://www.gnilux.com
  14. That's quite funny. Why didn't BEA document it? Why didn't they tell anyone about it with all their marketing might? :) If they wanted any credit, they really should have made it more prominent, and they should have said "Oh, we've had that for years" when AOP came around. But they didn't. And they sure didn't present it in an elegant manner, which is what AOP does.
    Steve
  15. Hi there

    >
    > BEA ships an almost undocumented feature allowing to preprocess the bytecode of any class loaded during the deployement process of any app. This excludes app server wide libs / classes.
    >


    Massaging byte code is not AOP. In order to have a valid claim about implementing AOP, you have to be able to weave functionality into classes and provide an easy to use mechanisim to selectively weave different functionality into classes without having to write a custom classloader of custom code.
  16. Crazybob Lee integrated his AOP solution with BEA long before jboss launched AOP. Not that it matters, it is just a fact.

    More on this and jAdvise on his site: http://crazybob.org/roller/page/crazybob/20021205
  17. You are right.

    Seems that "Peter English" did not took time to read my post completely since I stated JAdvise integration in WebLogic provided by Bob Lee was done in december 2002.
    http://www.theserverside.com/home/thread.jsp?thread_id=20171&article_count=99#88309

    Thanks for posting its blog entry.

    Moreover weblogic "hook" means not rewriting a class loader, but just a weaver.
    Note that JAdvise is also a source of inspiration to JBoss AOP - search and you will find evidences, or ask directly to Bob Lee or Bill Burke.

    By the way JMangler provides JVM wide hook since more than a year and is registered in AOSD.net... Based on that I think it is true to say BEA shipped an "AOP ready" server since more than a year - or just ask for JMangler unregistration...

    Note also BEA made it easy to stay open : you can just plug any AOP framework in it, thus even the JBoss one. Is this the "JBoss innovative" position you tried to argument ?

    Alex
    --
    Folks are listening to the crowd and missing innovative ideas...
    The way you are "reading" (?) the posts is just another evidence...
  18. Providing a hook into a class loader is not AOP either. While someone may have used it to provide AOP functionality as an add-on, the original undocumented functionality in BEA is not AOP.
  19. That weblogic.classloader.preprocessor is _not_ AOP is one thing (and quite obvious). That it allows an external AOP framework to be plugged in is another.

    I guess I don't really see your point here. To me the preprocessor approach of weblogic is actually pretty clever, because they didn't need to spend resources on implementing their own AOP framework.

    Maybe the difference between the jboss kind of approach and the bea kind of approach is, that jboss supports it out of the box (and actually might depend on it), whereas BEA just enables it. If this is important or even good can be argued about: Out of the box is more comfortable. But then, at some point, you might run into some restrictions of jboss aop, which other frameworks do not have. Then, out-of-the-box becomes uncomfortable and you wish you wouldn't have bet your ass on it. Then, pluggable is better. Just look at the improvements, that were made from jboss AOP DR1 to DR2:

    - C# Metatags with our XDoclet Integration
    - per method, field, and constructor interceptor-chains/pointcuts
    - caller pointcuts
    - factor of 6 performance improvements

    None of these are innovations. All of those are there e.g. in aspectwerkz, which is LGPL licensed. JBoss is no AOP leader like they like to make everybody believe. But they catch up quickly, that sure is demonstrated by this quick release. Big credits for that. Now, just please somebody from jboss join the AOP alliance guys, so the future of AOP is one future, not a jboss future and a different AOPI future. That'd be really nice!
  20. Is it because most of the brilliant minds are

    > working in open source today and corporate development
    > doesn't breed the same quality because they don't
    > have the same pressure?

    Perhaps. Or perhaps it's because corporate developers are working for money, whereas Open Source developers are working because they care.

    Cheers,
    Clinton
  21. Perhaps. Or perhaps it's because corporate developers are working for money, whereas Open Source developers are working because they care.

    >
    > Cheers,
    > Clinton

    Bill, I am not sure I buy that. I work because I care but also for the money, I can't believe that caring individuals innovate like corporate labs do, which is why I view JBoss as an anomaly. Innovation in Open Source is disruptive.

    If open source creates an incentive to innovate with money then it is powerful if it is 'flower power' stuff then it is doomed. There is no free lunch you know.
  22. No free lunch?[ Go to top ]

    There is no free lunch you know.


    Well, I'm eating pretty darn well and not paying a dime.

    It's just perspective. From my side of the fence I use software every day for free, with no compromises. In fact, where I work, people are begging to use JBoss and Tomcat instead of the commercial crap that we are doomed to deploy on.

    BTW: Who's Bill? ;-)

    Cheers,

    Clinton
    www.ibatis.com
  23. No free lunch?[ Go to top ]

    There is no free lunch you know.

    >
    > Well, I'm eating pretty darn well and not paying a dime.
    >
    > It's just perspective. From my side of the fence I use software every day for free, with no compromises. In fact, where I work, people are begging to use JBoss and Tomcat instead of the commercial crap that we are doomed to deploy on.

    Sounds like someone has been using WebSphere lately...

    I am also doomed to work with an app server that goes a long way to make my life a real nightmare...

    We use JBoss for development purposes, but it is funny to see it performing MUCH better and beeing MUCH more stable than the CCTWADDO (commercial crap that we are doomed to deploy on).
  24. From what I've seen, corporate developers often are constrained by a number of market forces. Specifically for corporate developers in product companies - they must often do very specific work to keep certain high-profile clients happy, and additionally do work that the company perceives as keeping/gaining marketshare.

    Also - in many cases product development people _can_ be somewhat removed from people using their products (or only have limited direct experience with them).

    Open source developers, at least on the best projects, are often trying to solve a very specific problem of their own. They don't have to worry about the market or sales, and they often _are_ the end user, so their needs get very specifically translated into their code. JBoss is a funny case in between somewhere - there is obviously some market force pressure brought from the JBoss group, but at the same time, it's not the same kind of pressure that a traditional product company would feel (after all, they're not selling the product itself, just ancillaries around it). Where something like JBoss will lead in the end, I can't say - it's still too new to judge IMHO.

         -Mike
  25. Mike,

    For the most part, I agree with you. I didn't mean to imply that corporate developers are selfish money-grubbing pigs --after all, I am a corporate developer. :-)

    But I'm guessing that the JBoss feature request list, bug list and flame-box are as full as BEA or IBM.

    The difference that I see is that in determining what new features get implemented, which bugs get fixed and which flamers to suck up to...JBoss and other OSS teams do what's right, what's most popular and what makes sense. On the other hand, BEA and IBM do whatever the customer with the deepest pockets decides...and of course they also do whatever the competition is doing.

    I don't blame them for this. After all, they have to do that to stay in business --and money talks. But from my perspective, with OSS, *I* get what *I* want more often than I do with commercial products.

    There are exceptions of course: I think IntelliJ IDEA is just about the best IDE ever conceived. IMHO there's simply no equivalent in OSS or otherwise...sorry Eclipse has a long way to go --IMHO.

    Cheers, :-)

    Clinton
    www.ibatis.com
  26. very specifically translated into their code. JBoss is a funny case in between somewhere - there is obviously some market force pressure brought from the JBoss group, but at the same time, it's not the same kind of pressure that a traditional product company would feel (after all, they're not selling the product itself, just ancillaries around it).

    >      -Mike


    mmmmm, I think it is a good think that they mix "traditional company reliability" with "open source passion". It means that we can use the product with the assurance of a real structure and accountability.
  27. Open Source as a leader[ Go to top ]

    Like mentioned in my previous post, BEA and AOP was already demonstrated with jAdvise last year. Besides jAdvise, you can also use aspectwerkz with BEA - checkout the aw offline mode.

    Personally I find it kind of weird that jBoss is coming out with its own AOP framework, while there are so many others that work which they could have just used. Then, launching this "AOP" implementation in DR1 and then argumenting that they didn't have the time to come up with a halfway decent join point model combined with the loudness/massive marketing around their launch, that is not good style I think.

    Also, is there anyone from jBoss like Bill Burke on the AOSD list? Not that I'd know of. What are you expecting? Jboss leads and AOSD must follow?
  28. Forgot to provide JMS link[ Go to top ]

    It is a little hard to find on the website.

    http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/jboss/jms
  29. JMS Implementation[ Go to top ]

    I'm glad to see that you're starting fresh with JMS - the original was rather long in the tooth. And it's exciting for me to see that JBoss is using JavaGroups to implement the underlying P2P transport. I've been investigating doing something very similar in my own environment, but JBoss beat me to it.

    I was wondering about how to deal with persistence and durable subscribers in the event that a publisher isn't up...and I'm sorry to see that you guys haven't solved it yet, either. That said, I've always thought the JMS spec was a disappointment in mandating persistent & durable support. Baseline JMS should be just what you guys have created - fast point-to-point and little else. Persistence issues should have (IMHO) been mandated at a different level - sort of a software stack if you will, with a low-level JMS with basic (but speedy) features, and a higher level JMS with persistence features. Sort of of like UDP vs. TCP.

    Anyway, I'm not much on JDO or AOP, but it's nice to see something different in the open source JMS world.

        -Mike
  30. JMS Implementation[ Go to top ]

    Hi Mike,

    The next thing you will probably see out of this project is support for non-persistent point-to-point because, as you have mentioned, the persistence thing is a more difficult problem to solve. I've thought of many different ways to implement this in a pure P2P fashion, but I always get about 65% there (in my mind) and then run into an issue. So, what we'll probably end up doing is only supporting non-durable publish and subscribe and non-persistent point to point for P2P clients. If you require persistent messages or durable subscriptions, you'll have to use the traditional client-server JMS implementation we're working on. However, the plan is to allow P2P clients to seamlessly use the traditional (server based) JMS via multicast. In short, the server (or servers in a clustered environment) would be a member of the multicast group, and when a persistent message was sent (or a durable subscriber created) the server would handle these operations. To the P2P clients, the server would just be another client on the network, but really the server would be a super client that can persist messages, manage durable subscriptions, etc. In addition, non P2P clients would be able to bridge into the P2P network via the server as well. This architecture would provide a very flexible arrangement—allowing users to decide what they need and where they need it.

    How does this architecture sound to you Mike? Any suggestions?
  31. JMS Implementation[ Go to top ]

    \Nathan Phelps\
    I've thought of many different ways to implement this in a pure P2P fashion, but I always get about 65% there (in my mind) and then run into an issue.
    \Nathan Phelps\

    Well, as I see it there are several interrelated basic issues with a non-server solution and JMS persistence:

       - How do you deal with publishers who aren't up, and you need their published data for a durable sub?
       - Where do you persist data to?
       - Can your JMS clients be pinned to a specific machine, or use a shareable drive of some sort?
       - How performance conscience are you?

    But those are the obvious ones...there's some subtle aspects as you dig into it...:-)

    In general, you have the JMS client library take over most of the job that the server would normally perform. Then you just have to deal with recording persistent data to a store that all your P2P clients can get to, and coding your subscribing clients to get data from that store.

    Another presupposition is you generally want to identify your publishers uniquely on the network, and you want to use monotonically increasing sequence numbers per publisher/message/topic tuple. If you do this, you can fake a JMS ack model, but really use a NACK model under the covers. The NACK model relies on the publisher identity and monotonically increasing sequence numbers to see that messages are coming in from various publishers in order. ACKs are basically swallowed at the client library - you record the last sequence you got for a given publisher, and that's that. In general, you only need to hold a list of the last-ACKed message per publisher. So if you're subscribing to 3 topics, and there are 2 publishers on each, you need only 6 records of last-ACKed message.

    If there's a gap in your sequence, then you effectively halt delivery, find the missing messages, get them into sequence, and then restart delivery. As a performance optimization, you can use DUPS_OK mode to allow you to durably record ACKs only ever N messages and/or seconds. When you find a dupe, then a NACK effectively goes out and you backfill your gap.

    This sort of approach eliminates a whole boatload of problems of not having a server, and is wicked fast to boot. But now you still have the problem of "if there's a GAP, where do I get my data from?!?!".

    If you can live with an RDBMS solution, then your JMS client library hits the RDBMS anytime it sees a gap, and gets the missing records from there. This presumes, of course, that publishing persistently records data in the same spot. Retrieval is basically by publisher name and a range of sequence numbers (gimmee 50-80, or what have you).

    If you can't live with everyone hitting an RDBMS, you can utilize a specialized server process whose sole purpose in life is listening for re-fill requests over your multicast network, hit the database for missing messages (maybe with a cache :-), and return the missing messages. A smart re-fill server can also batch up requests into one lump by delaying slightly when it gets a request. This deals with a bunch of durable guys coming up all at once demanding their messages.

    If you can guarantee everyone has access to a shared file system of sometype (please, not NFS!!!), then you can make things very fast by writing messages out in files per-publisher, and utilizing a simple sorted index to index your messages for you (multiple publishers writing to the same file can be problematic and involves a whole bunch o' locking issues you probably don't want to get into). Durable subs in this scheme can use a simple file which contains the last ACKd message # per subscriber. If you can pin a sub down to a specific location, you can even write this ACK'd message list to local disk.

    There are many little details (like non-persistent messages should be tagged so they're not in the same ordering scheme as persistent ones, hence their loss shouldn't trigger a re-fill request), but that's the gist.

    ...On your wider architecture, it sounds quite nice and very flexible. The P2P arch I've described can be faster in many ways, and is nice if you don't want to pay the cost of having a server, but the ability to connect "P2P" and "non-P2P" clients seems very worthwhile.

        -Mike
  32. JMS Implementation[ Go to top ]

    Hi Mike,

    thanks for your suggestions; Nathan and I plan to sit together and have another design session during JBoss bootcamp in Atlanta in mid-August. We're glad for feedback like yours and will definitely discuss all points/issues raised.

    A few ideas on serverless JMS I have (note that I'm not really a JMS expert):

    - There is no dedicated JMS server. A bunch of designated members in a JavaGroups group take turns playing the server. This server is a singleton group member.

    - The member currently being the server takes upon it to save messages for durable topics to the DB. It does so by listening to all topics, and all messages published on them, and (if durable) by persisting them. This server is simply another subscriber for *all* topics and persists them.

    - Issue: a publisher will be able to publish a message, and all subscribers will receive it *even if the server crashed* (and before the new server took over). In such a case, we have to come up with a mechanism to retrieve the messages that were missed and persist them.

    - For p2p on queues: every client always 'knows' who the current server is, and sends a unicast to the destination. This is the same as the traditional client/server approach

    - Transactions: this will be supported. Whether XA or regular TXs, JavaGroups will be used to transport them to the subscribers/receivers.

    - Note that we will effectively offer 2 JMSs: one that uses the traditional client/server transport based on the JBoss Remoting framework, and another one based on JavaGroups. Which one you use will be based on a deployment property. We will also talk to Tom Elrod and Jeff Hayne in Atlanta to see whether we can accommodate a point-to-multipoint paradigm in their Remoting framework, so we could integrate the JavaGroups JMS transport.

    My 2 cents.

    Bela
  33. JMS Implementation[ Go to top ]

    \Bela Ban\
    - There is no dedicated JMS server. A bunch of designated members in a JavaGroups group take turns playing the server. This server is a singleton group member.
    \Bela Ban\

    I'm not sure you need anyone to play server, and if you go that route you have problems in terms of collisions (what if two guys try to be the server?), gaps (what if nobody is the server right now?) and general failover issues. These are solvable, but involve alot of code complexity (and testing the failure conditions are pretty torturous). It makes much more sense to me to have your JMS client library persisting directly to your datastore. And if you use a publisher identity/monotonically increasing sequence concept, subscribers can always know if they're current or not based strictly on the message stream, without having to poll the database or anything.

    Likewise, a client can pull directly from the database, and the beauty is it knows what it's missed, so it hits with a single quick query on a primary key. If database concerns are an issue, you may want a refill server somewhere on the network. This can be a truly tiny server whose only purpose is to serve refill requests.

    \Bela Ban\
     - The member currently being the server takes upon it to save messages for durable topics to the DB. It does so by listening to all topics, and all messages published on them, and (if durable) by persisting them. This server is simply another subscriber for *all* topics and persists them.
    \Bela Ban\

    It may sound strange, but you don't need to persist non-persistent messages which happen to have a durable subscriber or three. In fact, you really don't want to for a number of reasons. Persistence is up to the publisher, not the subscriber. A durable subscriber is allowed to miss non-persistent messages, most especially if it's inactive at the moment. To say that eases the implementors burden is quite a massive understatement :-)

    \Bela Ban\
    - For p2p on queues: every client always 'knows' who the current server is, and sends a unicast to the destination. This is the same as the traditional client/server approach
    \Bela Ban\

    Queues are going to be very, very tough for you guys to support with no true server running. The problem is guaranteeing only one queue listener gets any given message and no other listener on the same queue gets it for any reason.

    \Bela Ban\
    - Transactions: this will be supported. Whether XA or regular TXs, JavaGroups will be used to transport them to the subscribers/receivers.
    \Bela Ban\

    Regular TX's are pretty easy to handle under JMS. But XA implies you've got a transaction manager hanging around coordinating things for you. Are you envisioning doing publishing directly to the point-to-point piece out of JBoss transactional components? Either way, XA recovery and transaction logging should be a very interesting problem for you guys to tackle as P2P (in particular if a given XA P2P guy doesn't want to come back up, and you've got in-doubts locking up your database).


    All in all, it sounds like some cool stuff. And apologies to TSSers who are undoubtedly hearing more than ever wanted to about the guts of JMS implementations....

        -Mike
  34. JMS Implementation[ Go to top ]

    \Bela Ban\

    > - There is no dedicated JMS server. A bunch of designated members in a JavaGroups group take turns playing the server. This server is a singleton group member.
    > \Bela Ban\
    >
    > I'm not sure you need anyone to play server, and if you go that route you have
    > problems in terms of collisions (what if two guys try to be the server?),

    This doesn't happen, unless you have a network partition and run into a split brain situation. Every JavaGroups member has the *same* ordered list of members. That way, we can make deterministic decisions without communication.


    > gaps (what if nobody is the server right now?) and general failover issues. These
    > are solvable, but involve alot of code complexity (and testing the failure conditions
    > are pretty torturous).

    That's what JavaGroups does best. Note though that I'm not handling Byzantine failures, the current model assumes a stop-fail model.

    > It makes much more sense to me to have your JMS client library persisting directly
    > to your datastore.

    This would involve distributed knowledge at each client. Doable, but possibly more costly and complex than having a dynamic 'coordinator' acting as JMS server.


    > And if you use a publisher identity/monotonically increasing sequence concept,
    > subscribers can always know if they're current or not based strictly on the message
    > stream, without having to poll the database or anything.

    This is what the NAKACK protocol does.

     


     
    > \Bela Ban\
    > - For p2p on queues: every client always 'knows' who the current server is, and sends a unicast to the destination. This is the same as the traditional client/server approach
    > \Bela Ban\
    >
    > Queues are going to be very, very tough for you guys to support with no true server
    > running. The problem is guaranteeing only one queue listener gets any given
    > message and no other listener on the same queue gets it for any reason.


    My thought here is that if we have a (dynamic) server, then we can provide exactly the same model as in the client/server approach, right ?



    Bela
  35. JMS Implementation[ Go to top ]

    \Bela Ban\
    This doesn't happen, unless you have a network partition and run into a split brain situation. Every JavaGroups member has the *same* ordered list of members. That way, we can make deterministic decisions without communication.
    \Bela Ban\

    You have clients A, B, C, D. Let's say "A" is playing server. "A" bounces (by bounce, it goes down for some reason and comes back very fast - perhaps just a network glitch). I presume the fact it went down is detected somehow.

    Now - at the bounce, I presume "B" becomes the server now. But what happens if A bounces very fast (or wasn't really down)? You can easily hit a situation where some people think A is the server, and some think B is the server, unless you have some very clever synchronization happening. It's unlikely, but possible. And it's these sorts of things that keep me awake at night.

    <Me> It makes much more sense to me to have your JMS client library persisting directly to your datastore.
    </Me>
    \Bela Ban\
    This would involve distributed knowledge at each client. Doable, but possibly more costly and complex than having a dynamic 'coordinator' acting as JMS server.
    \Bela Ban\

    Why do you need distributed knowledge? Each peer only cares about what he subscribes to and publishes. He keeps a list of what he's published, and his last received message from each publisher on a topic he's subscribed to. If there's a gap (such as especially if he was down for a period, or a publisher crashed along with message loss on the network), he needs to gap fill.

    That's it. Nothing else is needed. Of course, this is for topics. For queues, it's dicier, but then I worry about the multiple-server issue I talked about above for a dynamic server situation. This is actually _much_ easier than guaranteeing only one dynamic server is ever up, and that there always is one (that everyone agrees to!), plus cost of creating the specialized dynamic-server code itself.

    <Me>
    And if you use a publisher identity/monotonically increasing sequence concept,
    subscribers can always know if they're current or not based strictly on the message stream, without having to poll the database or anything.
    <Me>

    <Bela Ban>
    This is what the NAKACK protocol does.
    <Bela Ban>

    What if a publisher goes down? What if a durable subscriber hasn't been up for the last half hour and missed 100 messages? It sounds like JavaGroups handles ordering for you for live data on the network with live processes - but does it handle recovery when the originator isn't around anymore, or when a subscriber isn't around to get something he's supposed to?

    \Bela Ban\
    [On queues...]
    My thought here is that if we have a (dynamic) server, then we can provide exactly the same model as in the client/server approach, right ?
    \Bela Ban\

    A client server approach is much simpler for the reasons I stated above - ensuring there always is a server, and that it's always the only one.

    ...

    I've been thinking about your dynamic server approach, and it seems you have another problem: scalability (plus latency I've described before). How is your single dynamic server going to respond if there's a spike in message publishing? You have a double-whammy here: first, an innocent process might end up being a dynamic server, and getting hammered by a message spike (so it's spending all it's time acting as the dynamic server, and not so much doing its own processing). Second, one guy is handling everyone's traffic.

    This can be solved if you allow multiple servers - but then handling queues becomes even more difficult, and you need to coordinate your multiple servers, which is also difficult.

    In all, I don't see what a dynamic server concept buys you. You have a benefit of not needing a server, and auto-failover. But on the other hand, you're also throttling scalability, and you have big headaches coordinating failover to an alternate server. In addition, in a corporate environment, they _are_ going to care about trying to audit what's happening. And this goes triply for any choke point like a dynamic server. The problem here is they need to _find_ who the dynamic server is at this moment, and play hunt-the-logs in case there's a problem (and no matter what you do, there will always be problems).

    In other words - in P2P, OK, you find the publishers, you find the subscribers. In client/server messaging, you add in well-known servers.

    In a dynamic messaging server, it's P2P with a moving-target phantom server out there somewhere. Seems cool, but hunting down problems becomes much more difficult.

    Plus what about a situation where one hackneyed, wheezing client happens to have an out of date version of the JMS software after an update due to a slip up, and by the luck of the draw ends up becoming the server and serves up everything wrong?

    What if the "server" is a really oddball client that's coming in 56K over a modem? What if the server responds to pings, but otherwise is setup wrong or makes a hash of things?

    I dunno. Dynamic server sounds seductive, but when I close my eyes and think of the IT environments I've seen (and the weird situations that come up in production), it seems like an operations managers worst dreams come true.

    I'm not purposely ripping your idea - it just goes against alot of practical knowledge and seems like it might be a source of headaches if things hit the fan in production.

         -Mike
  36. JMS Implementation[ Go to top ]

    All in all, it sounds like some cool stuff. And apologies to

    > TSSers who are undoubtedly hearing more than ever wanted to about
    > the guts of JMS implementations....

    No need to apologize, you're making reading TSS worthwhile again.

    /T
  37. Re: JMS implementation[ Go to top ]

    Mike-

    If I understand correctly, you just described how TIBCO RendezVous works? Also, some of Nathan's ideas seem to be in line with the D-MQ concepts (TIBCO RV, again). What do you guys think of the RV architecture, their strengths and weaknesses? Thanks.
  38. Re: JMS implementation[ Go to top ]

    I don't really know Rendezvous. What I described is very common for high-throughput messaging in the financial services arena - things like stock tickers and the like. In general, a NACK based model based on publisher identity and monotonically increasing sequence numbers has been proven to be reliable and to have very high performance. Hell, it's pretty much what TCP/IP does under the covers :-)

    Some of my ideas have come from work in the mid-90s with Reuters Triach, some with studying early TIBCO products, some with some dot-com proprietary sort of work I did in the late 90s, some from Talarian SmartSockets, and a whole bunch from recent proprietary work I'm doing in messaging for a "major financial services company".

    Sorry I can't discuss Rendezvous in detail....

        -Mike
  39. Re: JMS implementation[ Go to top ]

    Hi Sergey,

    I have actually never used TIBO, but one of my previous colleagues has, and very early in the development process of the JMS rewrite, I had some conversations with him about TIBCO and I must admit that I wasn't much interested in the P2P model for JMS. My colleague, on the other hand, wasn't much interested in the client-server model, LOL.

    Anyway, after Bela pitched the idea of doing JMS over JavaGroups (and I discovered how cool JavaGroups is), I decided to give it a try. So, over the development of the software I've been looking around to see what else is out there and in the process I ran across some talk of TIBCO.

    Interesting, the underlying concepts are very much the same. They have a library (which they have open sourced) very much like JavaGroups (though not in Java) which adds reliability over UDP. They, like we, expose that library via the JMS API. Unfortunately, that is all I know about TIBCO, so I can directly address your question.

    On a similar note, however, Bela and I both spoke to Arjuna about their JMS product (which they integrated into JBoss along side their DTM), and they do the same thing in their JMS product, except they use a different library like JavaGroups (older and now unmaintained according to Bela). SoftWired (another JBoss partner) is another company that offers a similar multicast JMS product. So there are several organizations aside from TIBCO that offer such implementations. My hunch is that we all sort of doing things in similar ways.
  40. JMS Implementation[ Go to top ]

    \Mike\
    If there's a gap in your sequence, then you effectively halt delivery, find the missing messages, get them into sequence, and then restart delivery. As a performance optimization, you can use DUPS_OK mode to allow you to durably record ACKs only ever N messages and/or seconds. When you find a dupe, then a NACK effectively goes out and you backfill your gap.
    \Mike\

    Very interesting discussion on JMS. We are currently using JMS point-to-point messaging with no persistance as our transport medium and we use a ACK/NACK/Sequence number model to detect lost messages. The JMS client is responsible for recovering lost messages using the RDBMS. We can live with the RDBMS solution for the gain in performance by turning off the message persistence offered by JMS.

    Vincent
  41. JMS Implementation[ Go to top ]

    Very interesting discussion on JMS. We are currently using JMS point-to-point messaging with no persistance as our transport medium and we use a ACK/NACK/Sequence number model to detect lost messages.


    JavaGroups provides both positive (ACK) and negative (NACK) based retransmission, both being optional (provided as protocols). That way, we can forget about retranmission, ordering, gaps etc in the message stream from the conceptual server (publisher) to all clients (subscribers): JavaGroups does it for us. Or at least makes it easier.

    Bela

    P.S.: I forgot to mention in my earlier post that I wrote JavaGroups
  42. JMS Implementation[ Go to top ]

    \Bela Ban\
    JavaGroups provides both positive (ACK) and negative (NACK) based retransmission, both being optional (provided as protocols). That way, we can forget about retranmission, ordering, gaps etc in the message stream from the conceptual server (publisher) to all clients (subscribers): JavaGroups does it for us. Or at least makes it easier.
    \Bela Ban\

    Not, I believe, for persisted messages with the publisher down w/ network message loss, or for durable subscribers.

    Plus, you still have to deal with JMS' acking model, which can throw a small curve ball in normal layered ordering schemes.

         -Mike
  43. JMS Implementation[ Go to top ]

    \Bela Ban\

    > JavaGroups provides both positive (ACK) and negative (NACK) based retransmission, both being optional (provided as protocols). That way, we can forget about retranmission, ordering, gaps etc in the message stream from the conceptual server (publisher) to all clients (subscribers): JavaGroups does it for us. Or at least makes it easier.
    > \Bela Ban\
    >
    > Not, I believe, for persisted messages with the publisher down w/ network message loss, or for durable subscribers.
    >

    For durable subscribers, the JBoss app-server will itself be a subscriber in the P2P web and save durable messages. At least that's the idea.

    > Plus, you still have to deal with JMS' acking model, which can throw a small curve ball in normal layered ordering schemes.
    >

    We'll see....I think Nathan and Bela have a good handle on this.

    Bill
  44. JMS Implementation[ Go to top ]

    \Bill Burke\
    For durable subscribers, the JBoss app-server will itself be a subscriber in the P2P web and save durable messages. At least that's the idea.
    \Bill Burke\

    Well, you only need to save messages marked as persistent. Durable subscribers are allowed to miss non-persistent messages.

    The interesting bit for a P2P JMS, to me at least, is deciding exactly who saves persistent messages, and how redelivery happens a) for failed publishers who have dropped off the net, and b) for durable subscribers that need messages that were sent while they were inactive.

    Queues are a whole 'nuther matter, that IMHO should be dealt seperately from pub/sub, and in many ways they're more challenging than pub/sub.

    Anyway, it sounds like you're still working out final designs for this sort of thing. Nathan it appears to be still working through ideas, Bella is favoring a dynamic server idea, and you've brought up the idea of using a JBoss server component as subscriber to do this sort of work. For my part, I've put in my 2 cents on possibilities for a pure P2P solution that I think can support all pub/sub JMS functions. I think a pure P2P solution would be a very interesting option for people to have, and the idea of not needing a JBoss server around is quite attractive for some applications. And it's about time someone's built some JMS functionality layered on top of JavaGroups. I'm crossing my fingers that your nacent P2P implementation will stay seperate from the larger one, and that you continue to develop it out as pure P2P.

        -Mike
  45. JDO implementation of JBoss[ Go to top ]

    Just a curious question to the JDO implementation of JBoss. Why does JBoss make a new Open Source implementation of the JDO specification? There are already some Open Source implementations for JDO as far as I know... OK, they all are not ready yet, but bundling the capacity would be a better solution, IMO. Are there any special stuffs on that implementation so that JBoss team cannot "reuse" other Open Source JDO implementations?

    Thanx,
    Lofi.
    http://openuss.sourceforge.net
  46. JDO implementation of JBoss[ Go to top ]

    I'm sure Alexy will reply in due course.

    From an outsider's perspective, JBossDO was written by their CMP Lead. I suspect they wanted to leverage their existing CMP engine codebase and felt this would yield a better result.

    I presume that JBossDO cannot operate in a non-managed environment, i.e. outside the confines of the JBoss application server. Of course that's not their target market segment! Once again, I hope that Alexy will comment.

    Kind regards, Robin.
  47. JDO implementation of JBoss[ Go to top ]

    First of all, thank you all for kind words on this release!

    > I'm sure Alexy will reply in due course.
    >
    > From an outsider's perspective, JBossDO was written by their CMP Lead.

    It's so happened that at the moment I am CMP Lead at JBoss Group and JBossDO is my work. So, Robin, you are right ;)

    > I suspect they wanted to leverage their existing CMP engine codebase and
    > felt this would yield a better result.

    No. There is no a line of code in JBossDO from the current CMP engine that is in 3.x branch. We plan to completely rewrite current CMP engine. The reason? We still and constantly grow up! :) The time has come and current engine does not allow us to scale well.

    In JBoss4, we are moving towards generic persistence engine on top of which will be EJB/CMP and JDO. Maybe even something other, but CMP and JDO is our minimum. And that was also one of the reasons to start our own development instead of integrating one of the existing projects.

    > I presume that JBossDO cannot operate in a non-managed environment, i.e.
    > outside the confines of the JBoss application server. Of course that's not
    > their target market segment! Once again, I hope that Alexy will comment.
    >
    > Kind regards, Robin.

    This is true. JBossDO works only in a managed environment, more exactly in managed by JBoss environment ;) It is possible, that one day it will operate in a non-managed environment. But it is a low-priority point. We need to get it up first.

    alex
  48. This is true. JBossDO works only in a managed environment, more exactly in managed by JBoss environment ;) It is possible, that one day it will operate in a non-managed environment. But it is a low-priority point. We need to get it up first.

    >

    If it was standard JDO then it would work outside of JBoss, so it sounds like it's not standard JDO. I see good and bad sides to this. On the bad side, several vendors are all supporting the JDO standard and it's nice to have an application that isn't tied to a specific vendor. On the other hand, SUN is not giving JDO the attention it deserves and the spec is moving very slowly. Hibernate seems to have some nice features that would be great in JDO, but we'll have to wait until the next version who knows when. So it's an interesting choice this JBossDO. Now we have: JDO, Hibernate, & JBossDO. Why use JBossDO instead of JDO or Hibernate?

    Michael
  49. Now we have: JDO, Hibernate, & JBossDO. Why use JBossDO instead of JDO or Hibernate?

    >
    > Michael

    I don't see your point it seems JBossDO is standard JDO. It is JBoss so what? a thread here a couple of days ago showed the spec lead at SUN praising JBoss for taking the pain to offer a JDO face.

    What would really be interesting would be if JBoss built JBossDO ontop of hibernate. That would be something, a good engine and a standard face on it. But I wonder about the implications for the O/R mapper vendors out there. I am afraid for their future if JBoss embraces hibernate for example.

    Larry
  50. --
    I don't see your point it seems JBossDO is standard JDO. It is JBoss so what? a thread here a couple of days ago showed the spec lead at SUN praising JBoss for taking the pain to offer a JDO face.
    --

    You have a point, I think I confused the fact that JBossDO only works with JBoss and being JDO Compliant. It can be JDO Complaint but still not run outside JBoss. But still I believe that's a strong limitation. For one thing, it puts JBossDO out of reach of lots of projects that use other appservers, or projects that don't use appservers at all. My last two projects were done with Tomcat & JDO. For the JDO I used Kodo, a commercial product although not very expensive. I'd love to use Tomcat & JBossDO to take advantage of an open source JDO but it sounds like I won't be able to do that.

    Michael
  51. projects were done with Tomcat & JDO. For the JDO I used Kodo, a commercial product although not very expensive. I'd love to use Tomcat & JBossDO to take advantage of an open source JDO but it sounds like I won't be able to do that.
    >
    > Michael

    I see your point. When I read the JBoss AOP stuff and the aspects that go with it I read it as perfect for tomcat containers. Tomcat is already integrated in JBoss and I would remove the EJB container SAR and all and just keep native objects in the weblayers while leveraging the aspects from JBoss, from JDO to Acidity.

    I am thinking about starting my next tomcat project to leverage the JBoss AOP enterprise features (I want clustering and acidity) without leaving the web container. I think the integrated Tomcat SAR in JBoss is just that thing. That or I code EJB's

    Larry
  52. JDO implementation of JBoss[ Go to top ]

    As long as it's possible to write domain objects and application objects without compile-time dependencies on any JBossDO-specific classes, then the fact that JBossDO is currently tied to the JBoss architecture is not an issue.

    Clients requiring alternative deployment options not supported by JBossDO will have to source an alternative JDO implementation runtime for those particular deployments. But the code they have written should be entirely portable. And if, one day, JBossDO can run in an unmanaged environment, or in the managed environment of arbitrary J2EE servers, then JBG can "compete" for that business.

    In the mean time I do not perceive any problems with Alex's approach.

    Alex, can you clarify whether JBossDO can be used directly by Web components hosted in a JBoss container - or is it only accessible to EJB components?

    If JBossDO can be exploited directly by a Web application which has no EJB components, then I would have thought that the "resource cost" of an unused EJB capability in the server would not be excessive. Certainly applications based on Web-JDO are very elegant. Once JDO supports attachment / detachment and long-lived optimistic transactions (you don't have long to wait now), the Web-JDO combination will be extremely compelling.

    I ramble....

    Kind regards to you all, Robin.
  53. JDO implementation of JBoss[ Go to top ]

    Not to ramble, but Robin said exactly what I was thinking this morning. If they can glue tomcat into JBoss so that they can instrument objects in the web tier, we'll use that all day long.
    Steve
  54. JDO implementation of JBoss[ Go to top ]

    Alex, can you clarify whether JBossDO can be used directly by Web components

    > hosted in a JBoss container - or is it only accessible to EJB components?

    JBossDO is available for any component deployed in JBoss.
    You just deploy a JAR package. The only difference in the deployment process is that, if there is JDO metadata found in the JAR, the classes are enhanced according to the metadata. Nothing else. The classes are put in the classpath according to the JBoss classloading architecture. They are available for any component deployed in the JBoss.

    alex
  55. Three ways to win with JDO[ Go to top ]

    "You have a point, I think I confused the fact that JBossDO only works with JBoss and being JDO Compliant. It can be JDO Complaint but still not run outside JBoss. But still I believe that's a strong limitation. For one thing, it puts JBossDO out of reach of lots of projects that use other appservers, or projects that don't use appservers at all. My last two projects were done with Tomcat & JDO."

    A couple of points. First, as Alex has explained in this thread, the intent is that JBossJDO works with the JBoss containers including Tomcat.

    Second, it may be a significant limitation of JBossJDO that it works only with JBoss, but it can also be a stength. Integrating the JDO implementation tightly with JBoss may yield some significant optimizations.

    From the point of view of an application's architect or a programmer's manager, there are three wins with JDO: your people need only one set of skills, your application is portable to different database architectures and runtime environments, and whatever JDO implementation that you pick can be optimal for its target environment and database. Just as you wouldn't think of using an Oracle JDBC driver with DB2, there is no particular reason to expect that a JBossJDO jar will work with a WebLogic server.

    David Ezzio

    To play with JDO today, download the JDO Learning Tools at http://jdo-tools.sourceforge.net.
  56. Similar to JORM from JOnAS?[ Go to top ]

    <quote>
    In JBoss4, we are moving towards generic persistence engine on top of which will be EJB/CMP and JDO. Maybe even something other, but CMP and JDO is our minimum. And that was also one of the reasons to start our own development instead of integrating one of the existing projects.
    </quote>

    So, something similar that JOnAS has done, by using JORM?

    FYI:
    "JORM (Java Object Repository Mapping) is an adaptable persistence service offering variuos personalities, including one compliant with the CMP EJB specification and another with the JDO (Java Data Objects) specification. JORM provides object persistency through differennt secondary storage supports, such as file, relational databses or object-oriented databases. JORM includes an implementation of the JCA (Java Connector Architecture) specifications."

    As far as I know, the CMP implementation of JOnAS from ObjectWeb, Speedo (JDO implementation) also from ObjectWeb are based on JORM... Correct me if I'm wrong...

    Lofi.
    http://openuss.sourceforge.net
  57. Similar to JORM from JOnAS?[ Go to top ]

    FOI, JOnAS is not hip! It doesnt get mentioned in US centric sites. This is my experience. I belive JOnAS is in many ways far superior to any of the "hip" appservers, but any mention of JOnAS will be ignored. I cant for my life understand it! I wouldn't even consider using anything other than JOnAS. Anyone, pleas inform me why JOnAS is never mention in the "media". Would they need someone who shouted strange things now and then? Does it need a counter on the website (informing of the 5:th million d/l)? Or some verbal character stating that JOnAS is superior to everything on this earth and in the rest of the universe?? Please inform me.

    Mo
  58. JBoss[ Go to top ]

    Alex:

    It's so happened that at the moment I am CMP Lead

    Happend? Everybody who has eyes can see what's going on. You have replaced Dain Sundstrom from Core Developer Network (CDN). And this is likely the reason to switch to JDO and not some limits of the current CMP.

    I see further that David "Mr. JCA" Jencks, CDN, was kicked as the JCA and JTA lead. Adrian Brock, your JBoss forum answer machine, has to do the job now.

    And a few days ago I read in the Inquirer that you've kicked Jetty and now use Tomcat as the default. So this move kicked Greg Wilkins from CDN.

    I guess you guys are very keen to remove the cvs rw of the boys above but that will certainly create too heavy waves at the moment.

    -- Andreas
  59. JBoss[ Go to top ]

    What do you expect them to do, NOT fill open positions? :D There's nothing wrong with JBG protecting their direct interests. People want JDO anyways.
    Steve
  60. JBoss[ Go to top ]

    Steve:

    What do you expect them to do, NOT fill open positions? :D There's nothing wrong with JBG protecting their direct interests.

    It was expected, of course. But it shows how different JBoss from Jakarta is, for example. Nobody will loose a project lead job at Jakarta if he left a company and joins another. Jakarta stuff is free stuff while JBoss is taken as a property of JBoss Group.

    And don't think forking the code is easy. First, MF has the trademark so a fork cannot have the same name. I don't know if it is possible to change the package name at all. All changes have to go back to the original code base due to the LGPL. If someone forks and will have success, be sure he will be sued.

    I really hope that CDN has some more in the back than just to participate on support contracts. I really hope you CDN boys have a plan to fork the code incl. how to deal with the laywers. Many people and companies count on you to free JBoss from this ill people.

    -- Andreas
  61. JBoss[ Go to top ]

    What do you expect them to do, NOT fill open positions? :D There's nothing wrong with JBG protecting their direct interests.

    I say it is a great thing in fact, that a commercial spine is backing the open source endeavour. Someone else says JBoss==JBossGroup and JBossGroup==JBoss, see that is VERY REASSURING to me as a customer. It is even sexy as a business model.

    If I understand the business model right, the health of the two entities are in fact one and the same. That is how they solve the "no free lunch dilemma". All the new developments are done by JBoss Group employees as developers of JBoss from what I can tell.
  62. JBoss[ Go to top ]

    This does not look good.

    Andreas M. pretty much describes the situation - at least that's the way it looks like from the outside. JBossGroup is jealously removing any dependencies on CDN members in the JBoss Open Source codebase. This is ugly. I might be dead wrong - but in that case someone from JBoss(Group?) should come forward and explain the issues. This makes JBoss, as well as JBossGroup, look really really bad.

    Sure - you can always fork JBoss to a new project - but that would be a pitty.

    -- Anders
  63. JBoss[ Go to top ]

    Anders - I also find it extremely worrying - if you look at the members of CDN and what they contributed to JBoss - then look at these new features, the correlation is staggering:

    Change to use Tomcat by default (All Jetty guys at CDN)
    Emphasis on JDO instead of CMP (Jeremy Boynes - mainainer of JBoss CMP - gone to CDN)

    New version of JMS (Remigio Chirino wrote the original and has gone to ... CDN)
  64. JBoss[ Go to top ]

    Some things that should be set straight:

    > Emphasis on JDO instead of CMP (Jeremy Boynes - mainainer of JBoss CMP)

    Jeremy Boynes has never been an active maintainer of the JBoss CMP, Alexey took over maintaining this module more than 6 months ago (major new features in 3.2 are from Alexey).

    > New version of JMS (Remigio Chirino wrote the original)

    Hiram Chirino did NOT write the original JMS version (Norbert Lataille did) nor has he been an active maintainer of it for more than a year now. Adrian Brock has been doing the critical JMS maintenance for a long time now (and looking at the track record of bug fixes Adrian has done he is doing a lot better job than Mr. Chirino ever did).

    Credit where credit is due. If you don't maintain your codebase, what are you good for?
  65. Too tight...[ Go to top ]

    I think, this is generally the problem, if an Open Source project is just too tight with the its business group.

    Apache Jakarta, ObjectWeb -> "consortium type": can you see a company directly behind Apache, ObjectWeb? Although there are a lot of business built upon Apache, their sites are just free of businesses.

    JBoss: you can directly see that (JBoss = JBossGroup) and (JBossGroup = JBoss). They even use the same address (www.jboss.org).

    IMO, it won't be easy for CDN members to build businesses around JBoss.

    Lofi.
    http://openuss.sourceforge.net
  66. Imagine...[ Go to top ]

    I think, this is generally the problem, if an Open Source project is just too tight with the its business group.

    It is a great thing in fact. I want to see some control and accountability. In the spirit of there is no free lunch I am glad to see JBossGroup == JBoss and the money that will keep on fueling innovation like what we are seeing today.

    The DR2 announcement is extremelly significant to me as it says JBossGroup is on top and driving the industry in all the right directions, BEA is playing catch up in AOP? funny don't you think?. BEA had grown complacent with marketing talk and sub-par/buggy implementations with a lack of vision, and I am glad to see a group on top of it and driving.

    Software isn't free, JBoss Group can distribute JBoss for free, they (JBoss Group) still incurs the cost of maintaining and developing the project from what I can tell. Q/A people, roadmap people, vision people, distribution packaging, support staff, documentation staff, training staff, marketing staff, PR staff, sales staff, development staff, all the normal people you will find in a company need to be found in Open Source (no free lunch remember?)

    > Apache Jakarta, ObjectWeb -> "consortium type": can you see a company directly behind Apache, ObjectWeb? Although there are a lot of business built upon Apache, their sites are just free of businesses.
    >

    ah! That is just not true. In the no free lunch analysis you will realize that Apache is just a perfect example. First a bunch of sys-admins and now mostly corporate development (jakarta == IBM + SUN and even BEA). afaict ObjectWeb is INRIA, meaning salaried people and also their lack of marketing and sexyness is appaling.

    I want to see the JBoss Group maintain their momentum and sustain their model. The implications of a succesful JBoss Group are mind boggling, they are reinventing part of the infrastructure development model. Speaking of which, does anyone know where I can find "red"? the whitepaper? I could find blue and white but not red. I want to read it if possible.

    Blue, white, red... happy 4th of july, may the independence of JBoss Group/JBoss be proven.

    > JBoss: you can directly see that (JBoss = JBossGroup) and (JBossGroup = JBoss). They even use the same address (www.jboss.org).
    >

    Right, that is the great part imho, otherwise it is impossible to build a real business.
  67. You are right... I think, it would be very interesting to watch both business models, the "Consortium Type" (Apache, ObjectWeb) and the "One Company Show Type" (JBoss/JBoss Group).

    "Consortium Type":
    <lawrence>
    First a bunch of sys-admins and now mostly corporate development (jakarta == IBM + SUN and even BEA).
    </lawrence>
    Also don't forget about Covalent Technologies. There are a lot of other companies backing up the Apache Foundation projects for services, value added products, trainings, etc. Not only IBM, SUN and BEA.

    <lawrence>
    afaict ObjectWeb is INRIA, meaning salaried people and also their lack of marketing and sexyness is appaling.
    </lawrence>
    INRIA is only one of the research entity within the ObjectWeb Consortium. You also have Bull (If I'm not wrong, Bull offers 24x7 support on JOnAS for example), etc. inside ObjectWeb. Just like Apache Foundation you can be a member of the ObjectWeb Consortium as legal entities or individuals (see ObjectWeb site).

    Those companies (IBM, SUN, BEA, Bull, Covalent, etc.) building services, value added products, trainings around Apache and ObjectWeb products are doing real business as well ;-)

    "One Company Show Type":
    Yes, JBossGroup is also doing a real business around JBoss products, no doubt on it ;-) My opinion is just CDN has a little chance to build businesses around JBoss products, because of this business type (JBossGroup == JBoss). For CDN would be easier to build business around the "Consortium Type" Open Source products.

    Each type has its own advantages and disadvantages.

    Regards,
    Lofi.
    http://openuss.sourceforge.net
  68. I didn't have any problem to run my application from 3.2.1 to the new release 2. I am using Session Beans,JMS with temporary queue,Struts,Tiles and the concurrent package.

    No problem also to add some "toys interceptors" to trace method-calls and performance-calls.I am now developing some more usefull interceptors
    to support asynchronous calls.

    Thx to the Jboss team for the great work and Bill for his exciting presentation in Boston.

    Claude
  69. CDN vs. JBoss Group[ Go to top ]

    I guess the fact that the CDN also (openly) supports the development of (Apache) Geronimo seems the biggest pain in the "ASs" for JBoss which is the leading OS AppServer so far (be JonAS better or not, and be the first version ever of JBoss still named EJBoss just a clone of the JonAS back then which only little people still might know? JBoss has marketed itself much better maybe cause Marc Fleury is French, but worked in the US so he got influence on both sides of the "Ocean", while JonAS'es range is limited to France and some parts of Germany ?;)

    Since JBoss being a new pioneer in a lot of areas has more and more challenged the "old" commercial appserver vendors (like BEA, IBM, Sun or Oracle) the introduction of a new additional OS appserver does not really harm the developer community (the more the better), but might harm the sales force and (commercial) consulting activities of the JBoss Group some day (if Geronimo might succeed like e.g. Tomcat did over Jetty, where both are free and Open Source)
  70. Red, white, and blue[ Go to top ]

    <
    Perhaps I just missed the joke. Can you explain?
  71. La Liberté[ Go to top ]

    (hope I got that accent right on the "e", not being French native ?;)

    The "pun" behind those papers and colors is simply they make up the French national flag ;)

    (and Marc Fleury is French)
  72. Red, white, and blue[ Go to top ]

    "Speaking of which, does anyone know where I can find "red"? the whitepaper? I could find blue and white but not red. I want to read it if possible."

    Let me try again. The blue paper is referenced elsewhere in this thread, but I'm curious about the white and red papers that you mentioned.
  73. JDO implementation of JBoss[ Go to top ]

    Hi,
    I hope JBoss will support pluggable JDO implementations. This allow to use Pure Object Database with JDO interface or other products ;-)

    bye,
    Luca Garulli
    Orient Technologies
    http://www.orientechnologies.com
  74. JDO implementation of JBoss[ Go to top ]

    Are there any special stuffs on that implementation so that JBoss team cannot "reuse" other Open Source JDO implementations?
    >

    They are reusing their EJB CMP components to manage the data store, and now they only must implement the interfaces and behaviour required by JDO.
  75. Just a curious question to the JDO implementation of JBoss. Why does JBoss make a new Open Source implementation of the JDO specification? There are already some Open Source implementations for JDO as far as I know... OK, they all are not ready yet, but bundling the capacity would be a better solution, IMO. Are there any special stuffs on that implementation so that JBoss team cannot "reuse" other Open Source JDO implementations?

    >
    > Thanx,
    > Lofi.
    > http://openuss.sourceforge.net

    JDO is not a persistence engine, just a user interface. JDO was designed to provide a standard interface to an object-relational mapper, an object database, or an object-whatever engine.

    This is similar to the goal of CMP, which is to standardize the user interface to relational databases, regardless of the underlying technology.

    In the case of JBoss, they already have an object-relational mapping engine that they use for CMP. Writing a JDO layer on top of their engine means that they can reuse all that code, and make it available to users on any tier. Win-win.

    Note that JBoss folks originally intended to use CMP for non-EJB environments, but realized that CMP really is only suitable for Containers that Manage Persistence.

    Craig
  76. I had just download DR1 yesterday when today I find DR2 is released! I'm pleased to see the JBoss team making rapid progress. I'm curious if there is a release roadmap for JBoss 4.0? Any estimated dates for a 4.0 alpha & beta?

    Michael
  77. You can see the 'roadmap' for JBoss 4.0 here

    http://www.jboss.org/index.html?module=html&op=userdisplay&id=features/4.0

    ... full release of 4.0 November/December.
  78. Why JDO now ?[ Go to top ]

    In Marc's Blue paper (http://www.jboss.org/modules/html/blue.pdf), he said (page 7) "While it was widely used in designs a year ago, JDO will probably go down in hisotry as the proverbial chicken that corssed the road when the CMP2.0 truck came along." If that's the view, why do we need JBossDO now ? Thanks.
  79. Why JDO now ?[ Go to top ]

    If that's the view, why do we need JBossDO now ? Thanks.


    Views change.

    Over the last year a lot of FUD and misconception about JSR-12 JDO has been dispelled:
    - many user group and conference presentations have taken place,
    - there has been much on-line debate (on TSS and elsewhere),
    - whitepapers, commentaries and tutorials have been published,
    - commercial implementations have matured
    - open source projects have emerged
    - three JDO books have been published and widely disseminated in PDF and printed form (another, the Sun Press book, is imminent)
    - other books are now discussing JDO in depth as part of a related subject

    The massively increased availability of factually based material has enabled people to make much better-informed decisions about JDO's positioning.

    Views change.
  80. I haven't DL'd DR2 yet but I am told that Tomcat has replaced Jetty as the servlet container.

    I haven't heard any reasons why but some have guessed it is because of the Core Developers vs. JBoss Group split...

    Anyone have any info? I really like Jetty, much more so than Tomcat and would prefer that Jetty remain the default container.
  81. Hmm.. I've always used Tomcat instead, I never understood why they chose Jetty as their default in the first place. Tomcat seems by far the more popular servlet container. I'm glad I can get Tomcat out of the default distribution *again*.

    /T
  82. Hmm.. I've always used Tomcat instead, I never understood why they chose Jetty as their default in the first place. Tomcat seems by far the more popular servlet container. I'm glad I can get Tomcat out of the default distribution *again*.

    >
    > /T

    This is exactly the reason we switched.
  83. Hmm.. I've always used Tomcat instead, I never understood why they chose Jetty as their default in the first place. Tomcat seems by far the more popular servlet container. I'm glad I can get Tomcat out of the default distribution *again*.

    > >
    > > /T
    >
    > This is exactly the reason we switched.

    Last year at JBossOne we were told to use Jetty instead of Tomcat. Jetty was a JBoss partner, it could be embedded, was faster etc. So taking their advice, we switched, now we should switch back because Greg Wilkins joined CoreDevelopers.

    Gary
  84. I wasn't a part of the organization when the decision was made to make Jetty the default. However, I did ask when I came on board (because I personally thought it was odd to be using something other then Tomcat) and was told that Marc simply didn't feel comfortable with Tomcat at the time because we didn't have anyone in the core team who was involved in Tomcat development. The Mortbay folks, however, approached JBoss Group about doing the integration. So they produced and maintained code to tightly integrate Jetty into JBoss. Now, however, we have a member of the Tomcat 5 team onboard with JBoss Group and we've integrated Tomcat into the container just like Jetty (it is a SAR). We will (as far as I know) continue to make the jbossweb-jetty.sar available. The only thing that has changed is that we have elected to ship jbossweb-tomcat.sar as the default.
  85. Hmm.. I've always used Tomcat instead, I never understood why

    > > > they chose Jetty as their default in the first place. Tomcat
    > > > seems by far the more popular servlet container. I'm glad I
    > > > can get Tomcat out of the default distribution *again*.
    > > >
    > > > /T
    > >
    > > This is exactly the reason we switched.
    >
    > Last year at JBossOne we were told to use Jetty instead of Tomcat.
    > Jetty was a JBoss partner, it could be embedded, was faster etc.
    > So taking their advice, we switched, now we should switch back
    > because Greg Wilkins joined CoreDevelopers.

    What's the big deal with the switch? Granted, I've been using Tomcat all along so I may be missing some details but... I've always built standard J2EE WAR files, and on occasion dropped them on JBoss with Jetty distribution. They seemed to work just fine -- although I do admit I did not do extensive testing.

    Does Jetty have problems with standard J2EE Web Archives?! Do people use Jetty extensions that are not portable to Tomcat?

    Curious to know, I always thought WARs were pretty portable (more so than EJBs for sure).

    As for the speed issue, I believe the differences have been marginal ever since the 4.x releases of Tomcat. At some point Jetty was even slower! I find it hard to believe there is that much of a speed difference today (and Jetty is still using Tomcat's JSP engine as far as I know). Certainly people who claim Tomcat is 'dog slow' compared to Jetty are full of it.

    /T
  86. The only issue for me with the switch is that they still make the Jetty option available ... and they (JBoss group) say they will do that. My preference will remain to download the Jetty version for the same reasons stated by another poster ...

    a). Jetty is faster than Tomcat for all cases I have deployed (Tomcat is not 'dog slow' like it was in 3.*, but there are still differences).
    b). Jetty has a smaller memory footprint than Tomcat for all cases I have deployed.
    c). Error diagnostics out of JSP part of Jetty (Jasper) are much better than what you get with Tomcat.

    There are NO issues about standard J2EE Web Archives. Both servlet/JSP containers handle them fine. Jetty allows some extensions, but I will always code to the 'standard'. Whether Tomcat is the most downloaded or not is irrelevant to me ... Tomcat has had far more political backing than Jetty so that is the reason it is better known - what matters is performance.
  87. As for the speed issue, I believe the differences have been marginal ever since the 4.x releases of Tomcat. At some point Jetty was even slower! I find it hard to believe there is that much of a speed difference today (and Jetty is still using Tomcat's JSP engine as far as I know). Certainly people who claim Tomcat is 'dog slow' compared to Jetty are full of it.

    >
    > /T

    Really? Find yourself a Tomcat 4.0 (anything pre 4.1.4 actually) and test a jsp page containing a couple of hundred body tags. You will then seize to be amazed as to why tomcat got the reputation of being a bit on the slow side of things...
  88. As for the speed issue, I believe the differences have been marginal

    >> ever since the 4.x releases of Tomcat. At some point Jetty was even
    >> slower! I find it hard to believe there is that much of a speed
    >> difference today (and Jetty is still using Tomcat's JSP engine as far
    >> as I know). Certainly people who claim Tomcat is 'dog slow' compared
    >> to Jetty are full of it.
    >>
    >> /T
    >
    > Really? Find yourself a Tomcat 4.0 (anything pre 4.1.4 actually) and
    > test a jsp page containing a couple of hundred body tags. You will
    > then seize to be amazed as to why tomcat got the reputation of being
    > a bit on the slow side of things...

    But Jetty uses the same JSP engine, so where's the difference? Also I only use the versions that come bundled with JBoss which has been something like 4.1.18 or 4.1.24 for ages now.

    /T
  89. HI!

    I don´t understand why people say that Tomcat is slower than Jetty. Since Tomcat 4.1.12, my own personal tests shows Tomcat consistently 30% faster than
    Jetty. Am I missing something??

    Andre
  90. I don´t understand why people say that Tomcat is slower than Jetty.

    > Since Tomcat 4.1.12, my own personal tests shows Tomcat consistently
    > 30% faster than Jetty. Am I missing something??

    No you're not. The fact is that the performance difference between the two is neglible -- depending on your benchmark or web application profile you may see either one of them to perform faster.

    That is, their performance is similar. I would take anyone's claim that one is significantly faster than the other with a grain of salt. It is likely they don't have hard facts to back it up.

    Plus with JBoss' architecture, you can always plug in either one of the two.

    /T
  91. "No you're not. "

    YES, I AM.

    I´ve followed the evolution of both Tomcat and Jetty more than a year. And Jetty was always slower for me (sometimes 5%, sometimes 30%), except when comparing with Tomcat 3.x/4.0.X branch.

    I have a lot of data to backup it, I can e-mail you pvt, if you want. The tests I make use an application that is in production in Jboss/Jetty (because, indeed, Jetty IS more stable than Tomcat).

    This application does not use Custom Tags, so maybe it can explain the difference (someone said that Tomcat custom tags implementation sucks).

    Anyway, as you said, it´s meaningless, with Jboss you can always plugin in either one of the two. Anyway, I´m using J2EE, and the application is portable -that´s the beauty of it.

    Andre
  92. But Jetty uses the same JSP engine, so where's the difference? Also I only use the versions that come bundled with JBoss which has been something like 4.1.18 or 4.1.24 for ages now.

    >
    > /T

    Yeah, but so does WebSphere, only they tend to fix some bugs before putting it up for production use...

    Anyway, I have made no performance comparisons between jetty and tomcat, nor claimed that either is faster than the other. I merely commented on the fact that tomcat has on occasion warranted the reputation of being a bit slow...
  93. Last year at JBossOne we were told to use Jetty instead of Tomcat. Jetty was a JBoss partner, it could be embedded, was faster etc. So taking their advice, we switched, now we should switch back because Greg Wilkins joined CoreDevelopers.

    >
    > Gary

    Ah, yes, the reason why we are doomed to deploy on commercial crap...
  94. Hmm.. I've always used Tomcat instead, I never understood why they chose Jetty as their default in the first place. Tomcat seems by far the more popular servlet container. I'm glad I can get Tomcat out of the default distribution *again*.

    > >
    > > /T
    >
    > This is exactly the reason we switched.

    This reason was in place when you switched from Tomcat to jetty (Tomcat has ever been more popular then Jetty, thanks to good job done by media and by Apache Group proponents). But after MortBay joined JBoss Group, you had choosen only Jetty (more compact and quick, IMHO) to be included into the binary builds and left Tomcat as a second choice. Now when Mortbay decided to do consulting and marketing with CDN, you remind that Tomcat is more popular, and switch the build back to Tomcat. Do you really beleive somebody can beleive this explanation?
    What is even more interesting, the last update of Jetty related files in JBOSS-HEAD CVS (JBoss 4) has been dated by .
    The question is, do Greg and other MortBay developers still participate in JBoss-Jetty integration efforts, and if they don't, what is the reason?
    And even more important question is, what's going on inside the core development team?
    I can see only 2 reasons:
    1. Mark, Bill and Scott are seing the open source JBoss project as their property and cut those who does not fit their business model or those who can compete with them in JBoss-based business.
    2. Those who left The JBoss Group to join CDN, are going to also leave the project without any pressure from JBoss Group, whichis unbeleivable for me.
    Both these choices are too bad for community and create FUD among JBoss users because as for me, I am not sure I can depend on an "open source" tool been developed according to the business interests of a small group of project leaders instead of technical excellence.
    This is just my though and I hope I am wrong, but I need more transparence in what's happening inside JBoss development team. I'd be glad to hear if Mark is ready to continue collaboration with CDN members on JBoss project.
  95. It's not any worse than any of the changes that BEA can throw at you. Besides, web containers are pretty well standardized, so if you're not using any proprietary stuff, you're fine.

    As for us, we're staying with Jetty until we move from 3.2 to 4.0. That should be a while. More than enough time for us to work out any kinks in that particular part.

    Steve
  96. But after MortBay joined JBoss Group, you had choosen only

    > Jetty (more compact and quick, IMHO) to be included into the
    > binary builds and left Tomcat as a second choice.

    There was always a binary build available with Tomcat. There was always two equally supported servlet containers for JBoss. Granted, the Jboss Group seemed to advertize Jetty more (hardly anyone knew about Jetty before that, did they?) which seems fair as Tomcat already had name recognition amongst all servlet developers.

    And the download numbers at Sourceforge do show that Tomcat was still the more popular choice.


    > Now when Mortbay decided to do consulting and marketing with CDN,
    > you remind that Tomcat is more popular, and switch the build back
    > to Tomcat.

    I was thinking, maybe they left because they knew of the decision? Maybe Marc and others looked at the situation and decided Jetty was not going to make it after the one year experiment and Tomcat was still the more popular and more in demand? Maybe that's why they left?

    You're making an assumption on the order of the events to the opposite but to me it seems both are as likely.

    Not that I mind at all that Tomcat is the default again. It was always my choice -- even during the past year's unsuccessful Jetty experiments.

    /T
  97. Jetty will continue to be supported in JBoss.

    We still have write permission into JBoss CVS and we
    intend to keep the jbossweb-jetty.sar tightly integrated.

    Hopefully the JBossGroupLLC will continue to allow us to make
    this contribution to an open project and will continue to
    build releases with Jetty available. If not, then Mort Bay
    or Core Developers will continue to make a Jetty.sar available.

    Some of the JBossGroupLLC employees have asked for and
    been given write access to Jetty CVS - so I assume that
    means that JBossGroup will continue to sell commercial support
    for JBossJetty. Of course commercial support is also available
    from CoreDevelopers for all of JBoss and other OS projects.

    This I don't think any users of Jetty in JBoss need worry about
    continued Open or commercial support.

    As for the Vs tomcat thing. For many users, it should make
    very little difference what web container is deployed - they
    both implement the same spec and pass the same test suite.

    For for some uses, there are differences. Tomcat has more
    connector options and more brand awareness and is easier to
    get developers who know it. But Jetty continues to be a
    more stable under load, a touch faster, and have a smaller
    foot print.

    Also Tomcats development is not as focused on it
    being embedded in other applications containers - thus more
    of it's own "personality" is visible even when embedded.

    Jetty is primarily focused on being embedded and tries
    to take on the personality of its wrapper - be that
    JBoss, JOnAS, Phoenix, JXTA, or one of the many commercial
    apps (IBM, Cisco, tmobile, ...) that ship with Jetty. This
    approach is good technically, but gives us low
    visibility - even JBossGroup renamed us to jbossweb.

    I think many people download the jboss-tomcat bundle
    simply because they know the tomcat brand - not because
    they have done a head-to-head technical evaluation.
    Even I do a bit of work for clients with tomcat - sometimes
    there are good (non-technical ;-) reasons to use it.

    whatever - diversity is good.

    And Jetty does use the Jasper JSP engine from jakarta.
    It get's a lot of criticism, but it is improving over the
    years. Also it is still just another servlet and its
    performance and stability can be effected by the servlet
    engine it runs in.
  98. Tomcat is dog slow. I was happy when Jetty became the default.
    BTW: Next time when you have an exception in your web app then look the
    stacktrace of Tomcat. Do you how many lines are generated all from org.apache?
    Now just imagine that every request has to travel throught this amount of
    code. Amazing, right? Now do the same with Jetty. You will be surprised.
    Oh, and the JSP container is so much better (it tells you the line in
    your JSP file where the error is). Tomcat just shows the line in the generated
    java class (a bit useless).
  99. I've always preferred Tomcat to Jetty, but the rumination about the switch and its relation to the CDN group split seems silly. At the Atlanta bootcamp back in February 2003, marcf flat out said Tomcat was now the preferred web server option. I would guess that CDN was only a shine in Dain's eyes at that time, if anything at all.
  100. "I've always preferred Tomcat to Jetty, but the rumination about the switch and its relation to the CDN group split seems silly. At the Atlanta bootcamp back in February 2003, marcf flat out said Tomcat was now the preferred web server option. I would guess that CDN was only a shine in Dain's eyes at that time, if anything at all."

    I'd like to corroborate this comment. I was there at the same bootcamp, Marc was talking about Tomcat 5 and how its new architecture was really nice. Maybe this is why I'm not really shocked or surprised.

    Steve
  101. Has the JBoss JDO implementation passed the JDO compatibility test suite (CTS)?
  102. Has the JBoss JDO implementation passed the JDO compatibility test suite (CTS)?


    I think you're jumping the gun a bit here Geoff. After all, this is a first developer release of a product which the author admits is still functionally incomplete.

    The question you perhaps should be asking is: does JBG intend JBossDO to pass the JDO compatibility test suite?

    Kind regards, Robin.
  103. The question you perhaps should be asking is: does JBG intend JBossDO

    > to pass the JDO compatibility test suite?

    The question is is the compatibility test suite freely available to everyone?

    /T
  104. The question is is the compatibility test suite freely available to everyone?

    >
    > /T

    I'll put that one to Craig Russell....
  105. Well, IANAL, and IANCR, but I'd guess that the JDO1 TCK is not freely available for all the same reasons that other early (pre-six-months-or-so-ago) JSRs do not have freely available TCKs.

    However, thanks to the diligent work of the folks at Apache (Jason Hunter in particular, IIRC), the licensing for all future (as of six-months-or-so-ago) JSRs will be such that TCKs will be available to non-commercial organizations for no fee.

    Now, I know absolutely none of the details involved, but that's my impression of the situation.

    -Patrick
  106. Aargh! I left out an important bit.

    So, if I'm right, then it's unlikely that JBoss will be able to (officially) pass the JDO1 TCK, but the JDO2 TCK will be available to them. And yes, the JDO2 spec is something that will happen, and will happen in the relatively near term.

    -Patrick
  107. JDO TCK license terms[ Go to top ]

    The JDO TCK is currently available to anyone (in the countries approved by Sun for downloads) using a click-through license. Follow the "Final Release" link on the JSR12 page at jcp.org.

    This may change at the release of JDO 1.0.1, due to be officially released shortly.
  108. Hi People,

    I think its good that at least an app server (JBOSS) is ready to support JDO out of the box. This is a step in the right direction IMHO as it gives us developers more choice for persisting data. Like Cameron said earlier I still think a "major/certified" appserver needs to support JDO as well for it to gain more momentum.


    But I have a question... the CMP Persistence manager on SunONE Appserver7 is also based on JDO. Does that mean we can actually use JDO without CMP within the SunOne application server. Anyone familiar with SunONE have any Ideas?
    Cheers,

    Smythe...
  109. Tomcat all the way.[ Go to top ]

    I am MUCH more interested in JBoss becuase of Tomcat and JDO.

    Is there any place I can find docs on how to deploy wars with 4.02?
    All the docs are 3.0.

    .V
  110. Tomcat & JDO all the way.[ Go to top ]

    A web container combined with JDO makes a wonderful technology base....
  111. Tomcat & JDO all the way.[ Go to top ]

    I just got feedback from client of a JDO application.. here what he says:

    "JDO is much faster than CMP. I'm very impressed."
  112. JBoss JDO appears to be odd[ Go to top ]

    Yes. This is because, when I code my EJBs, I actually first write Business Object. I take (sometimes) months to develop business object and test them standalone without any J2EE (JBoss) server.

    Once stable, I generate my EJBs.

    How are people who develop with such elegent ways going to be able to use JBossJDO without an EJB server during the initial development phase?

    (My concern is based on the observation that this won't work in plain Java environmnt). (For God'd sake, why are people not allowed to code just Java any more). I still have batch jobs written in Java and many more to come.


    Any one?

    Thanks,

    Vinay
  113. JBoss JDO appears to be odd[ Go to top ]

    Based on my very unscientific survey of the JBoss code bases, it appears to be a fundamental design principal to consolidate/re-use JBoss server code whenever possible. An unfortunately side effect of this is that it can be difficult to extract a certain feature set from "JBoss-the server" and use it stand alone. The P2P JMS features seemed to be a break from that pattern, but recent comments from JBoss team members seemed to sqash that hope for me. They seem to want to use the server-side code for as much as possible. There's a certain elegance to this, and it's always nice to re-use code when possible, but it does make things difficult (if not impossible) to use small isolated pieces without sucking in the whole kit'n'kaboodle.

        -Mike
  114. JBoss JDO appears to be odd[ Go to top ]

    There's a certain elegance to this, and it's always nice

    > to re-use code when possible, but it does make things difficult
    > (if not impossible) to use small isolated pieces without sucking
    > in the whole kit'n'kaboodle.

    It is certainly not impossible. If you study the JMX microkernel architecture in JBoss you will find that is in fact quite trivial to build a server that contains only those J2EE services that you require.

    For instance it is quite possible to build a server configuration where you drop most J2EE services (such as EJB containers, the web schmervices etc.) and only keep the messaging service and a few others you want/need to have with JMS (naming, transaction and security services).

    The default JBoss distribution contains three different configurations to start with but most users are encouraged to build their own. Most people don't need a monolithic J2EE servers that contains every service including the kitchen sink. The JBoss architecture has always been geared towards building your custom application server (in your case a messaging server).

    HTH,

    /T
  115. JBoss JDO appears to be odd[ Go to top ]

    If JBossDO's tight integration with the server causes you problems during the initial development phase, then code against a lighter-weight JDO implementation first and port to JBossDO later in the cycle. There are a number of JDO implementations to choose from, most of which do not require (although they do support) an application server.
  116. Code against another JDO?[ Go to top ]

    How many changes would I have to make to the "vendor" tags?

    I have 200 entities.

    How about batch applications?
  117. Code against another JDO?[ Go to top ]

    Ok, I'll really go out on a limb here and risk everything....

    In the timescales in which JBossDO will be a functionally complete and commercially stable release, the JDO 2.0 mapping tag set will be available. Even if the spec is not yet ratified by the JCP, the public draft will be available and the mappings it lays out will already be implemented by the most agile JDO vendors. So you will have lots of portable datastore mapping tags and very few non-portable vendor extension tags in your persistence descriptor.

    Knid regards, Robin.
  118. JBoss JDO appears to be odd[ Go to top ]

    \Thomas Mattson\
    It is certainly not impossible. If you study the JMX microkernel architecture in JBoss you will find that is in fact quite trivial to build a server that contains only those J2EE services that you require.

    For instance it is quite possible to build a server configuration where you drop most J2EE services (such as EJB containers, the web schmervices etc.) and only keep the messaging service and a few others you want/need to have with JMS (naming, transaction and security services).
    \Thomas Mattson\

    JBoss is quite flexible in allowing you to create minimal server configurations.
    It's certainly ahead of the pack in that regard. But it would be nice to be able to go server-free for certain types of functionality.

        -Mike