JBoss 4.0 Developers Version #1 Released

Discussions

News: JBoss 4.0 Developers Version #1 Released

Bookmark and Share Get thread feed

  1. JBoss 4.0 Developers Version #1 Released (38 messages)

    The first developer's release of JBoss 4.0 is available. It boasts the industry's first AOP framework which, according to JBoss Group, allows developers to interact with the server in an intuitive manner.

    Some of the services that will be available via this new framework include object persistence, caching, acidity, remoteness, transactions and security. Developers can, among other things, apply these enterprise services to plain Java objects.

    Here is the JBoss 4.0 Roadmap:

    Developer Release 1, June 2

        * Aspect-Oriented Framework
        * Aspect-Oriented Services
        * Full Distributed Transaction Manager
        * Fully J2EE 1.4 and EJB 2.1 based
        * UDDI server with JUDDI
        * Enhanced Management Console
        * Eclipse integration

    Developer Release 2, June 11

        * XDoclet support for AOP
        * JBossDO. JDO for JBoss. Persistence with POJOs.

    Developer Release 3, August-September

        * Fully transactional, distributed, clustered Entity Bean cache
        * Enterprise Media Beans. Streaming video and audio.
        * JMS rewrite with some clustering features
        * Integration between AOP framework and EJB. Tighter integration for JBoss integrators and tool vendors.

    JBoss 4.0 Release, November-December


    Check it out at http://www.jboss.org

    Cheers
    Ray
    Reply to this

    Threaded Messages (38)

  2. Nukes on Jboss released as well[ Go to top ]

    JBoss/Nukes runs on Jboss 3.2.1.

    tx

    Matt
    Reply to this Reply to original

  3. JBoss Nukes is very interesting[ Go to top ]

    I am really interested in the fact that JBoss ported the PHPNukes/PostNukes idea from PHP land to Java. I think it is a really cool framework, and wished that I could write modules in Java instead of PHP.

    Now Java developers have the ability to use a simple CMS system with plugable components, and I am sure the list of components will only grow and grow!

    Has anyone had any experience with the JBoss/Nukes or PHP/PostNukes that they want to mention?
    Reply to this Reply to original

  4. Nukes on Jboss released as well[ Go to top ]

    JBoss/Nukes runs on Jboss 3.2.1.


    I wonder how relevant this will be considering that the Portlet API will soon (!finally!) be available. I've read the spec (through community review), and I was really impressed with it. We'll implement it ourselves, and I think many other portal/CMS vendors will do the same. At that point it's going to be much more interesting to write to that API rather than some proprietary API I think. Writing portlets/modules that are portable to a number of containers/portals should be more useful.
    Reply to this Reply to original

  5. Nukes on Jboss released as well[ Go to top ]

    JBoss/Nukes runs on Jboss 3.2.1.

    >
    > I wonder how relevant this will be considering that the Portlet API will soon (!finally!) be available. I've read the spec (through community review), and I was really impressed with it. We'll implement it ourselves, and I think many other portal/CMS vendors will do the same. At that point it's going to be much more interesting to write to that API rather than some proprietary API I think. Writing portlets/modules that are portable to a number of containers/portals should be more useful.

    We earlier used PostNuke for www.jboss.org because we liked the functionality and it seemed to have a thriving community behind it. I especially liked the security model.

    Unfortunately, the switch to PHP and PostNuke at www.jboss.org was a miserable failure. Our website was brought to a grinding halt because PHP and PostNuke just didn't scale at all!!! On the same hardware(500mgz W2k pIII) where we used to be able to service 500-1000+ concurrent users with around 50% cpu utilization, we could only support around 50-70 users with PHP and PostNuke. Hence, Nukes on JBoss was born.

    Bill
    Reply to this Reply to original

  6. Nukes on Jboss released as well[ Go to top ]

    We earlier used PostNuke for www.jboss.org because we liked the functionality

    > and it seemed to have a thriving community behind it. I especially liked the
    > security model.
    >
    > Unfortunately, the switch to PHP and PostNuke at www.jboss.org was a miserable
    > failure. Our website was brought to a grinding halt because PHP and PostNuke
    > just didn't scale at all!!! On the same hardware(500mgz W2k pIII) where we used
    > to be able to service 500-1000+ concurrent users with around 50% cpu
    > utilization, we could only support around 50-70 users with PHP and PostNuke.
    > Hence, Nukes on JBoss was born.

    I understand the story behind Nukes, and you probably did the right thing, at that point. I'm just wondering if using a Nukes-based API *now* is the best way for people to create modular webcomponents. Maybe if Nukes on JBoss was ported to use the Portlet API. That would make it more interesting.
    Reply to this Reply to original

  7. Nukes on Jboss released as well[ Go to top ]

    What is impressive about the Portlet API? I'm curious. We've been using WL Portal for a while and while it's nifty, there's nothing really groundbreaking except that it might be nice to have a standard.

    But from my POV, you still have to integrate all your portlets together. It's nice for silo-like snippets of functionality, but to have a usable suite of tools, you'll have to have portlets know about each other at some level, even if it's just at the data level.

    Steve
    Reply to this Reply to original

  8. Nukes on Jboss released as well[ Go to top ]

    What is impressive about the Portlet API? I'm curious. We've been using WL

    > Portal for a while and while it's nifty, there's nothing really groundbreaking
    > except that it might be nice to have a standard.

    It may not be ground-breaking, but that's not really the purpose. It's like servlets: it does what it's supposed to do, and does it well. There are no real screwups in there, and plenty of room for clean improvements in the next version. Also, it's easy to extend it without breaking the API, which is nice.

    > But from my POV, you still have to integrate all your portlets together. It's '
    > nice for silo-like snippets of functionality, but to have a usable suite of
    > tools, you'll have to have portlets know about each other at some level, even if
    > it's just at the data level.

    I agree, but if the basic foundation is not good then that's not going to be much fun coding.

    /Rickard
    Reply to this Reply to original

  9. SiteVision and Portlets[ Go to top ]

    Rickard,
    I'm just guessing... SiteVision will be Portlets-compliant? Can't wait to see it running :-)
    Reply to this Reply to original

  10. SiteVision and Portlets[ Go to top ]

    Rickard,

    > I'm just guessing... SiteVision will be Portlets-compliant?

    Yup. I've already implemented half of the spec, and the rest shouldn't be that difficult. I'll have to wait until the final release to say for sure though.

    > Can't wait to see it running :-)

    You already can: http://freeroller.net/page/rickard/20030524
    Reply to this Reply to original

  11. php nuke it[ Go to top ]

    not to mention that php nuke is a security nightmare every other day someone posts flaws in it, mostly trivial in nature
    Reply to this Reply to original

  12. Nukes on Jboss released as well[ Go to top ]

    Huh! I just woke up here and am somewhat slow...
    What I understand is that this isnt an j2ee app but
    rather an API?? There's not an archive I can deploy on
    another(say JOnAS) appserver? Sorry for the confusion

    Eder Veggie
    Reply to this Reply to original

  13. Nukes on Jboss released as well[ Go to top ]

    I am awake and ask you to ignore my prev stupid question, however,
    I have a new one, on the jcp site it says (about jsr 168) that:
    <snip>
    2.11 Please describe the anticipated schedule for the development of this specification.

    Community Review: 04/03
    Public Review: 06/03 /*when o when*/
    Release: 08/03
    </snip>

    Ary You saying that jboss implementation isn't using this spec in "Their" nukes?

    Still confused...
    Reply to this Reply to original

  14. How about some good documentation around december[ Go to top ]

    I dont see any note related to the documentation .... usual JBOSS way ..
    Reply to this Reply to original

  15. How about some good documentation around december[ Go to top ]

    Documentation????????? There's only way to get it (as MarcF mentioned sometime ago) ... so please step up if you are up to the task :-)
    Reply to this Reply to original

  16. JBoss 4 --- Expect ...[ Go to top ]

    Hi Rickard Oberg :

     Are you still in JBoss team.

     The features stated in JBoss 4 is cool. But
     I want to ask where is the documentation ...

     It is very very very important for us (as developer) to work
     on the platform. !!!!!!! (Even if I want to buy !)
    Reply to this Reply to original

  17. JBoss 4 --- Expect ...[ Go to top ]

    Hi Rickard Oberg :

    >
    > Are you still in JBoss team.

    Nope.
    Reply to this Reply to original

  18. JBoss 4 --- Expect ...[ Go to top ]

    Rickard Öberg:
    Sorry to jump on you with this personal question(answer is optional ;))
    Have You consider joining some other open source(inkl documentation) project?

    I got the nukes from the jboss cvs, looks nice, will I be able to build it on
    on JOnAS?
    Reply to this Reply to original

  19. JBoss 4.0 Developers Version #1 Released[ Go to top ]

    Developer Release 2, June 11

    >
    >     * JBossDO. JDO for JBoss. Persistence with POJOs.

    JDO for JBoss is not the JDO standard, but congratulations to all developers.
    Reply to this Reply to original

  20. JBoss 4.0 Developers Version #1 Released[ Go to top ]

    Strange thing. How JBoss may "fully" implemet J2EE 1.4 & EJB 2.1 if these specifications are not finalized yet?

    AOP and JDO are great news. But what is "Media Beans"? Where I can read about it? Is it JBoss initiative?
    Reply to this Reply to original

  21. JBoss 4.0 Developers Version #1 Released[ Go to top ]

    Probably complaint? If Weblogic can do it (BEA did it with 1.3), so can JBoss. Maybe you're disagreeing with the terminology they use.
    Steve
    Reply to this Reply to original

  22. JBoss 4.0 Developers Version #1 Released[ Go to top ]

    It is not released yet, by the time it released the spec hopefully will be finalized, and this means that the release version of the Jboss is spec compliant i.e. it means we will implement everything which is in the spec.
    Reply to this Reply to original

  23. JBoss 4.0 Developers Version #1 Released[ Go to top ]

    I hope so. Declared features are very progressive, let's hope it will be different story than Apache 2.0. Good luck with Sun compliance certification :)
    Reply to this Reply to original

  24. JBoss 4.0 Developers Version #1 Released[ Go to top ]

    BEA is always adopting this to promote their product is leader in spec implemenation. JBoss can do the same thing, but I think a strong ORB based IIOP implementation, INS support, etc. is also desirable for JBoss.
    Reply to this Reply to original

  25. Bytecode Enhancement?[ Go to top ]

    Hi All

    Strange that no one has complained about all the *runtime* bytecode manipulation done by the aspect stuff yet. The *compile time* enhancement done by JDO implementations is completely trivial by comparison yet any thread on JDO quickly draws fire about bytecode enhancement and how bad it is.

    Personally I think the aspect approach is great. I think critism of applications and standards that use bytecode manipulation is misguided. Its no different to extending javac really.

    Cheers
    David
    Reply to this Reply to original

  26. What is JBossDO?[ Go to top ]

    I'm curious what JBossDO is? They say "JBossDO. JDO for JBoss. Persistence with POJOs." but is it really JDO? If it's JDO then I'm really happy, this will give JDO the exposure it deserves. If it's not JDO but yet another persistence framework then I'm a little disappointed.

    Michael
    Reply to this Reply to original

  27. What is JBossDO?[ Go to top ]

    I'm curious what JBossDO is? They say "JBossDO. JDO for JBoss. Persistence with POJOs." but is it really JDO? If it's JDO then I'm really happy, this will give JDO the exposure it deserves. If it's not JDO but yet another persistence framework then I'm a little disappointed.

    >
    > Michael

    I was looking the Jboss CVS and it not seems to be JDO standard.
    Reply to this Reply to original

  28. What is JBossDO?[ Go to top ]

    I was looking the Jboss CVS and it not seems to be JDO standard.


    Actually, I browsed some of the CVS source and it looks like it IS an attempt at using the JDO standard. It includes sources in the package javax.jdo.

    That's news to me. These sources are only hours old as of the time of this post, so it might be news to everyone here. It looks like Alex Loubyansky is the committer for this stuff. I wonder what Marc Fleury thinks of JbossDO afer trashing JDO in his "Why I Love EJBs" paper.

    --matthew
    Reply to this Reply to original

  29. What is JBossDO?[ Go to top ]

    I was looking the Jboss CVS and it not seems to be JDO standard.

    >
    > Actually, I browsed some of the CVS source and it looks like it IS an attempt at using the JDO standard. It includes sources in the package javax.jdo.

    Yes, it seems to be based on JDO standard
    Reply to this Reply to original

  30. Patents and AOP?[ Go to top ]

    As a side note, JBoss includes AOP technologies. Someone recently pointed out that AOP has patents on it:
       http://www.isr.uci.edu/~lopes/patents.html

    I don't know the details of the patents or how broad they are, but patents generally don't mix well with GPLed software (unless the patents have a no-cost/no--use-restriction license).

    I suspect that the patents must be pretty narrow and easy to work around because patenting AOP is sort of like patenting OOP or structured programming.

    But insane patents have been granted before, so I'm wondering how these patents affect JBoss. Does anyone have any details?
    Reply to this Reply to original

  31. Patents and AOP?[ Go to top ]

    http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/%20srchnum.htm&r=1&f=G&l=50&s1=6,467,086.WKU.&OS=PN/6,467,086&RS=PN/%206,467,086
    Is this what U need? I think Mr Öberg had a blog on the subject or something..

    I dont know if this should be a problem, Xerox is such a nice company ;)
    Reply to this Reply to original

  32. Patents and AOP?[ Go to top ]

    http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/%20srchnum.htm&r=1&f=G&l=50&s1=6,467,086.WKU.&OS=PN/6,467,086&RS=PN/%206,467,086

    > Is this what U need? I think Mr ?berg had a blog on the subject or something..

    Yeah, basically I phoned Xerox to talk about this patent, since we also wrote an AOP framework that might be affected by the patent.

    First of all it turned out that it only applies in the US, and since we're based in Sweden and don't target the US market we're in the clear. However, Xerox (or at least the Business Development guy
    Reply to this Reply to original

  33. Patents and AOP?[ Go to top ]

    (TSS cut my reply in half. Here's what I really posted)

    Yeah, basically I phoned Xerox to talk about this patent, since we also wrote an AOP framework that might be affected by the patent.

    First of all it turned out that it only applies in the US, and since we're based in Sweden and don't target the US market we're in the clear. However, Xerox (or at least the Business Development guy I talked to) made it very clear that they enforce their patents "vigourously". He also said that it was possible to get a license for this patent, but there had to be a "business reason" for Xerox to do so. His main question to me was: how will Xerox benefit from there being two OpenSource projects that implement AOP? As above, I didn't have to answer this question, but others may well have to do so.

    Whether Xerox intends to enforce this patent or not with regards to JBoss I don't know. Probably not, just as Sun probably won't enforce the legalese around the J2EE certification. Legally they could (it seems), but from most other perspectives it'd be a bad idea. But IANAL so who knows...
    Reply to this Reply to original

  34. Patents and AOP?[ Go to top ]

    I dont want to be the source of FUD, having said that, remember the SCO-IBM hallabaloo.
    <snip>
    But IANAL so who knows...
    </snip>
    <rant>
    Neither am I (anyone here??)...As to how reinforceble the patent is outside the US, I think it is(agin ANAL). Just gambling on the probability of the *current* owner not enforcing a patent isn't something I would do(yes the SCO case again), actually this is a great example of how a company (which one, which one..) can manipulate its surrondings to cause havoc.</rant>
    Reply to this Reply to original

  35. Patents and AOP?[ Go to top ]

    (TSS cut my reply in half. Here's what I really posted)

    >
    > Yeah, basically I phoned Xerox to talk about this patent, since we also wrote an AOP framework that might be affected by the patent.
    >
    > First of all it turned out that it only applies in the US, and since we're based in Sweden and don't target the US market we're in the clear. However, Xerox (or at least the Business Development guy I talked to) made it very clear that they enforce their patents "vigourously". He also said that it was possible to get a license for this patent, but there had to be a "business reason" for Xerox to do so. His main question to me was: how will Xerox benefit from there being two OpenSource projects that implement AOP? As above, I didn't have to answer this question, but others may well have to do so.
    >
    > Whether Xerox intends to enforce this patent or not with regards to JBoss I don't know. Probably not, just as Sun probably won't enforce the legalese around the J2EE certification. Legally they could (it seems), but from most other perspectives it'd be a bad idea. But IANAL so who knows...

    I am of the personal opinion that there is a lot of "prior art" for the concept of AOP. But I am no patent lawyer.

    Besides, we're more concerned about the definition of pre-packaged aspects anyways.

    Bill
    Reply to this Reply to original

  36. Patents and AOP?[ Go to top ]

    Yes that's the key patent I meant.

    Hmmm, since they're ambigious on the enforcement of this patent, maybe it's better to downplay the AOP aspect and call it something like "Attribute Based Metaprogramming" so as not to aggrevate Xerox.

    From what I understand of the JBoss implementation, what they're doing is not much different than what XDoclet and .NET does, except that it does it more dynamically (and thus uses a different implementation -- JVM rewriting instead of forwarding proxy). If JBoss adds too many AOP features and Xerox decides to get nasty, it should be possible to retreat back to the current ABM-level without giving up too many of the advantages of JBoss 4.0.
    Reply to this Reply to original

  37. Re: Patents and AOP?[ Go to top ]

    The patent also states the researh was funded in part by AirForce/DARPA and the US governement has certain rights to it. Can't really confirm it but by this source(http://www.fbodaily.com/cbd/archive/1997/08(August)/19-Aug-1997/Aawd009.htm), they received around USD 1.1 million for 36-month contract(http://www.rl.af.mil/tech/programs/edcs/Admin_Data/c3-edcs-XeroxParc-Kean.htm).
    Reply to this Reply to original

  38. hey i like the web-console...[ Go to top ]

    http://localhost:8080/web-console/
    Reply to this Reply to original

  39. Eclipse based JBoss console is available[ Go to top ]

    If you use Eclipse, you can download XtremeJ Management Console from http://www.xtremej.com. The JBoss 4 DR1 support has just been added.
    Reply to this Reply to original