Apache Beehive Tech Talk

Discussions

News: Apache Beehive Tech Talk

  1. Apache Beehive Tech Talk (19 messages)

    BEA recently moved various parts of Workshop into the open source community via the Beehive project. Garrett Conaty is a principal technologist on the Beehive team, and has a good insight on how this happened and what it means for developers. This interview discusses what Beehive consists of, how developers can use it, building controls and page flows, as well as other open source efforts such as XMLBeans.

    Apache Beehive Tech Talk

    Threaded Messages (19)

  2. Beehive[ Go to top ]

    I wouldn't advise anyone to put their hands in a Beehive.
  3. Beehive[ Go to top ]

    Would be nice to justify your comments with something more substantial than just your advice, unfounded that it is.
  4. Beehive[ Go to top ]

    Would be nice to justify your comments with something more substantial than just your advice, unfounded that it is.

    I believe n n is currently unable to write something more substantial on this issue due to swelling in his hands. I appreciate him breaking the pain barrier to warn us of the dangers though.
  5. Beehive[ Go to top ]

    Would be nice to justify your comments with something more substantial than just your advice, unfounded that it is.

    I think it was a joke ;) Beehive looks interesting, I would really like to look at it some more. Anyone have any experience with it?
      .adam
  6. Wicket[ Go to top ]

    Beehive is a cornucopia of various technologies (Struts, JSF, Pageflows which used to be Webflows, etc.) hacked together with presentation views (JSF, JSP) resembling abandoned Porto-johns. The industry is in dire need of a clean room implementation and not a stack of outdated technologies and half-baked ideas cobbled together within an IDE to draw pretty lines and boxes.

    BEA donated Beehive to Apache in hopes of riding the open source wave because their customer base wanted nothing to do with it. In hopes of capitalizing on their futile endeavors - decided to open source it. It's like going to dotcom party where everyone is disguised as millionaires with leased underwear.

    Have a look at this framework implementing OOP within ALL its tiers, clean presentation views, and session management to name a FEW highlights:

    http://wicket.sourceforge.net/Introduction.html
  7. Wicket versus Beehive[ Go to top ]

    Man, you really are mad at those bees!

    Are you one of the developers for Wicket? I tried to view some of your past messages to get an idea, but apparently, you've never offered anything of substance to this forum that might indicate your area of "expertise". If you are, I would be interested to how you think Wicket is better than Beehive.

    I'll give you my take on the differences from what I've gathered from the Wicket website.

    Beehive:

    BEA decided to base the Beehive PageFlows on one of the most widely used frameworks for Web app development--Apache Struts. Pageflow builds on the basic Struts infrastructure (Actions, FormBeans, etc.), adding Java Controls (POJOs with metadata) as a simple way of building an object model. PageFlows also simplify Web App construction, offering more intuitive state management and data binding. Finally, PageFlows aggregate multiple Actions, FormBeans, and XML configuration into logical application component groups, making it easier for developers to collaborate and for tool vendors to ease configuration tasks and integrate with version control systems.

    While PageFlow current uses its own JSP tag libraries for data binding and presentation, the idea of PageFlow is that some JSF-like standards for page development will eventually stablize to the point where we will see widespread tool support for a standard Java markup.

    Wicket:

    The introduction page to Wicket starts by saying there are too many Web App frameworks available for Java Developers today (I agree), then attempts to justify why we need yet another Java Framework. The framework inself seems focused on trying to do HTML without new tags. The examples all require a .java file to interpret each .html file, which seems like overkill and a version control nightmare. The links and forwards are buried in the source code. Also, Wicket allows Java programmers to define design-level behavior (like popups), which are likely to complicate Web designers lives, user testing, etc.

    Frankly, I don't see anything revolutionary in Wicket that would justify the "clean room implementation" you say is necessary, and, while I agree that JSP and JSF are not perfect, creating a set of standard tags and extensions to HTML for Java Web App development would allow tool developers to offer better support for Java/HTML binding, solving the most pressing problem with the technology, i.e. allowing page designers to collaborate with Java developers without loosing this important binding information.
  8. That's not cricket[ Go to top ]

    Me thinks you misunderstand the history of BEA/Workshop/ and Beehive. My view as a WebLogic user is thus. First came WebLogic, then enabling technologies, then Workshop, and then more enabling technologies.

    WebLogic is only useful if you can deploy your apps to it. Workshop was evolved to make this happen. BEA targeted Microsoft shops(Visual Studio types) that had to make a tough decision about going to .Net. The various enabling technologies like xmlbeans, pageflows, jws, and controls make Workshop very Visual Studio-ish. But this created the threat of vendor lock. Tis a fine edge between adding value by pushing the technology and adding value by submitting to specification committees. BEA, which has always done a good job at complying with J2EE specs and defacto standards, had to get back to its core competency of selling app server licenses (WLS, WLP, and WLI). And thus BEA begat Beehive. This removed vendor lock. Users exhaled with relief that they could use Workshop and port apps and underlying enabling technologies if necessary.

    Making Beehive available through Apache is half the equation. Thier integration into Workshop and the productivity and lower learnig curve that came from that really made them special. It's the integration! I think Pollinate will do a lot to make Beehive technologies accessible and special outside of Workshop. One thier own as raw technolgies they look like yet-another-this-or-that to a technology skimmer like yourself. Try Workshop, (it's free) and feel the productivity. Just try and stop yourself from deploying.
  9. That's not cricket[ Go to top ]

    I don't think wicket even comes into the equation because it is too great an abstraction above the HTTP underpinnings. The JSF spec did a great job of creating a framework that allows simple event handling without impeding developers from working at the protocol level when needed, but it is beyond me why they didn't implement a better integration layer with JSP.

    I spent quite a bit of time working with jsf implementations to see if it was time to migrate, particularly after reading rick hightower's blog, but simply could not drop jsp support. So I'm in two minds, stick with struts for old apps, or copy jsf and implement jsp integration correctly. When you are managing beans on the server side it becomes trivial to select multiple pojos on from a select box for instance.

    There are too many hymn sheets kicking around!
  10. That's not cricket[ Go to top ]

    The JSF spec did a great job of creating a framework that allows simple event handling without impeding developers from working at the protocol level when needed,

    Hmm, it seems like that feature was available in Tapestry long before JSF arrival. Not to mention clearest possible separation between designers and developers. Personally I made my mind in favor of Tapestry and simply waiting for Tapestry 3.1 to arrive with two important (for me) fixes: allowing page specs in subdirectories ( cannot tolerate all of them in one directory ) and friendly links (http://howardlewisship.com/blog/2004/12/tapestry-31-update.html )
  11. Beehive is good BUT.....[ Go to top ]

    ok, Beehive is certainly very good its page flow is very robust ,natural,easy to understand and mentain
    the controls are lightweight and compatible with the JSTL (in contrust with JSF)
    BUT,is it the future? actually i donot know but although JSF is not mature right now (lack of proper and complex layout, and lack of compatability with jstl) it seems that the community is moving toward it , even struts encourage jsf for front end and the next release(codename shale) focus on the controller part and inclusion of IoC container...etc
    So,beehive is good.... but is that enough?????
  12. Apache Beehive Tech Talk[ Go to top ]

    Funny transcript:
    >>it was a project that we open sourced out to the Apache community and it’s now in the Apache inhibitor.

    I am sure he said ‘incubator’ but Apache ‘inhibitor’ is a brilliant idea! People could vote to put projects and technologies in ‘Inhibitor’ to slow down hype and growth of unwanted dead-end technologies.
    I suggest SOAP as a first candidate to be placed there.
  13. Apache Beehive Tech Talk[ Go to top ]

    rofl, can i nominate XSL as a technology that should be inhibited too?
  14. scribing not so crash hot[ Go to top ]

    The scribing obviously was not done by anyone remotely technical - "but you can build Beehive applications with eMax".

    Someone really should have glanced through the script guys :)
    ==

    I keep waiting for beehive to get some critical mass before looking at it - has it done much in the last 8 months?
  15. Controls a powerful feature[ Go to top ]

    I've been using BEAs platform and one of things I like the most is the notion of controls which basically makes a simple uniform API for accessing J2EE resources.

    Why is this good? Personally I always forget how the API toward JMS looks like because I don't use that often. Having controls in front of a JMS resource makes the API the same as when I'm accessing the database, ejbs, jca adapters ++. For people being new to J2EE this is extremely valuable.

    On the downside, I'm not too happy about BEA WebLogic Workshop as an IDE. I prefer IDEA. There's an Eclipse project called pollinate which might make Eclipse an option. A side effect of using controls is that tools easily can use controls instead of doing resource specific tools support.

    My personal Christmas wish would be if JetBrains would use Beehive/Controls in IDEA to simplify J2EE development instead of Fabrique.
  16. What is a control?[ Go to top ]

    What is the difference between "control" and "java class"?
  17. RE: What is a control?[ Go to top ]

    It's actually a JavaBean. Recommend to download the Beehive presentation from www.javapolis.com.

    There's also article about Controls. And the Beehive project has an Controls overview document.
  18. Apache Beehive Tech Talk[ Go to top ]

    I've been working with pageflows in Weblogic Workshop for some time and I find that most important improvements over struts is introduction of new reusable component - pageflow, which is graph of actions and pages. Pageflows are nestable - you can call one pageflow from another and have control returned to caller once nested pageflow is finished. Pageflow scope allows data to be stored as long as its pageflow is active.

    The negative aspect is that netui taglib is awkward in comparison to beauty of JSTL. I believe that with moving pageflows to open source community (significant step forward, I'd say) things will get better more and more.

    Anyway, idea of pageflow is a very good one.
    Having no intend to name netui pageflows a best presentation framework ever, I would really want any competent presentation framework to have such feature.
  19. Apache Beehive Tech Talk[ Go to top ]

    I've been working with pageflows in Weblogic Workshop for some time and I find that most important improvements over struts is introduction of new reusable component - pageflow, which is graph of actions and pages. Pageflows are nestable - you can call one pageflow from another and have control returned to caller once nested pageflow is finished. Pageflow scope allows data to be stored as long as its pageflow is active.The negative aspect is that netui taglib is awkward in comparison to beauty of JSTL. I believe that with moving pageflows to open source community (significant step forward, I'd say) things will get better more and more.Anyway, idea of pageflow is a very good one.Having no intend to name netui pageflows a best presentation framework ever, I would really want any competent presentation framework to have such feature.


    Hi guys, I've been using BEA Workshop IDE for Pageflows for a few months and I must comment that the idea of pageflows is quite revolutionary but the IDE is still years behind Eclipse and IDEA (or even JBuilder :O )

    I've been trying out the Pollinate Project recently. However I find it quite difficult to migrate an existing pageflow project into Pollinate. The pageflow classes do not seem to render the flow diagrams at all in Pollinate but they work fine in Workshop IDE. Any old timers here care to enlighten me?

    Thanks
  20. i first used controls with bea weblogic workshop 8.1 back in '05 (before bea open-sourced them). i also recently used beehive web service controls on an soa project (the customer originally hired bea to architect the project). but, outside of bea's or apache beehive's own websites, i haven't come across many objective, independent discussion of the technology. myself, i think they are a neat technology. but i wonder why more developers don't use them in their j2ee projects? is it because people have opted for spring instead? i noticed there are practically zero jobs requiring beehive control experience posted on the job boards? i did come across a couple on monster and dice; but it was bea systems themselves who were looking for people. what would it take to get you to consider using beehive controls (web service controls, ejb controls, jms controls, jdbc controls, etc.) in your j2ee projects? thanks in advance for your replies.