Discussions

News: Richard Monson-Haefel asks for your opinion on EJB 3.0

  1. Richard has come out and said "You can make EJB better". Richard is working on EJB 3.0 (JSR 220). He says "I'm an independent. I don't represent a vendor. Instead I try to represent the interests of J2EE application developers. To do that, I need to know what the development community wants." So, what do we want?

    Many people have opinions, and many people will no doubt say "get rid of EJB" and "EJB sucks", but how about something constructive?

    I would love for the Enterprise in EJB to be emphasized. I am all for "ease of use", but how about getting in features that enterprise projects want (like the worker threads, real security, etc).

    Long term, I would love for EJB to basically mean standards around enterprise aspects.

    Go to You can make EJB better

    Threaded Messages (209)

  2. A better CMP 3.0. With Hibernate/JDO taking up to market speed any optimizations on the CMP would be greatly appreciated.

    Support for read only entity beans.

    Thanks
  3. Beans Shmeans[ Go to top ]

    How about we get rid of the "beans" moniker and stop forcing people to butcher their code by writing getters and setters for everything.
  4. Beans Shmeans[ Go to top ]

    How about we get rid of the "beans" moniker and stop forcing people to butcher their code by writing getters and setters for everything.


    I second this option. But, I think that it should be in the Java language istelf that this is replaced. So, instead of:
       y.setXXX( y.getXXX( ) )

    it should look like

       y.XXX = x.XXX ;

    Compiler figures out which is the getter and which is the setter.
  5. Entity Beans[ Go to top ]

    I believe it would be very wise to deprecate Entity Beans completely - seriously. Some things are so broken that you shouldn't attempt to fix it but rather scrap it in the first place. The last two years have undeniably proven that Hibernate/JDO-style lightweight POJO persistence is far preferable to a persistent component model like Entity Beans. Leave persistence to JDO vendors and co; let those products evolve independently.

    So the only sensible thing to do is to admit the failure of Entity Beans and move forward with a tightended EJB focus, i.e. Session Beans and Message-Driven Beans. Full circle, in some respect... after all, Entity Beans weren't required at the time of EJB 1.0, were they? Deprecating them now would allow EJB container vendors to concentrate on things that really add value, like reliable remoting with Session Beans.

    The above has been pointed out so often, by so many different people, that it feels odd to have to repeat it here... If you need confirmation, do a poll on whether to deprecate Entity Beans, and act accordingly. Don't waste your time considering improvements to the persistence side of things that are much better covered by Hibernate and JDO already, and will be even better covered by future versions of Hibernate respectively JDO 2.0.

    Juergen
  6. simplicity needed[ Go to top ]

    Would highly appreciate removing all non-business-logic files like home/remote/locale interfaces, deployment descriptor.
  7. I totally agree. There is a JSR (I forget the number right now, and I'm on the wrong side of a slow link, so I won't look it up) out there to add attribute-oriented programming support to the JLS. I have a feeling it's scheduled to be released as part of Tiger (Java 1.5). Assuming EJB 3.x is targetted at J2EE1.5, which will presumably depend on J2SE 1.5, would would make sense to leverage this to define what is accessible locally, remotely etc.

    Concievably you could generate 'interfaces' based on this, but that's little better than XDoclet currently provides (not that I'm complaining, it's a fantastic tool). That said, I /like/ the fact that when you're coding against a local interface, you can only call methods the bean author intends you to call.

    I have to say, I don't agree with people who say that we should deprecate, remove or otherwise render useless J2EE's current support for Entity Beans (or the whole EJB concept, as some people seem to be suggesting). To be frank, we're in a world where we /need/ more than one way to achieve a given problem. I have looked at JDO several times, and came to the conclusion that for what I want, it wasn't the right tool for the job. Personally, I find Entity Beans a highly effective programming model now CMP2 is out there and generally available.

    I certainly don't begrudge people who wish to use JDO, Hibernate, Castor JDO or any other framework -- there are no right answers. BUT: I am qualified and entitled to make my own decisions about the right tool for the job, please do not take that choice away from me by deprecating a much valued feature!

    Cheers,


    Paul
  8. Hi,
    I developed quite a bit of J2EE applications and components and I find several things as problematic in the current EJB spec:

    1. Local interfaces are a BAD idea - why separate everything to two interfaces so you at compile time decide how to deploy a bean??? Thats just ridiculous... The whole idea was to do it in deploy time.
    However the other notion that all remote interfaces should throw RemoteException all around is also annoying and redundant since the EJB's are supposed to handle that. While I am all for checked exceptions, when it comes to something that should be all over the code (such as null pointer) I would make it an unchecked exception. So essentially I'm advocating a new interface that will be "optionally" remote and would receive elements either by value or by reference and that could be determined in the deployment descriptor.

    2. I use CMP a lot, I think its generally OK but unusable in its standard form. We need the following features in CMP in order to have a somewhat useable solution:
       a. Auto increment PK - yes there are several patterns to generate unique strings but lets face it most DBA's would want to kill you. Every application server worth a dime has some form of solution to this problem since it is essential, but the standard doesn't. There needs to be at least a guideline.
       b. Ranges - Practically every CMP developer I know wrote a "findAll()" method. This is very inefficient since we can't really specify the range of actual information that will be loaded from the database. This was probably not specified since it is not standard SQL, however every decent DB supports it and it can be emulated for compatability by the application server.
       c. EJB-QL without entities - The general idea is to use the applications schema for queries rather than none portable SQL. Several application servers offer this with entity beans, however there is no reason not to allow session beans to have access to this functionality. Furthermore I would add syntax for other queries in EJB-QL such as update etc... I wouldn't however use the existing ResultSet or JDBC classes.

    3. Swing/J2ME client integration - The mantra today is web services... However when writing a client in Java that communicates with a server in Java where both of them have to parse/generate XML is redundant to most of the projects I worked with. Theoretically you can use RMI, but this doesn't work since you need both the client stubs (that are generated dynamically and need packageing) and the EJB API in the classpath, I don't want to install J2EE for every client out there. What I ended up doing in one project was creating an RMI server that invoked EJB calls for me which is both redundant and problematic since many application servers aren't very clear on how a role is assigned for anything that doesn't come over HTTP. Generating "pure" RMI stubs on deployment seems reasonable enough to ask. For J2ME parsing SOAP XML files is not realistic (anyone who hasn't programmed a 16mhz device with battery constraints just doesn't know) there needs to be a solution.

    4. While role based security is simple and elegant it is very hard to learn and the most missunderstood/used feature of J2EE. Frankly other than my own projects, I have yet to run into a single project that makes use of role based security as defined in J2EE. Lots of small things are not clear or supported with the JAAS integration and code is still not 100% portable between vendors. One of the main problems I had is with setting up a system on startup, I used the servlet init method but I didn't have permissions to invoke the startup functionality.

    5. A startup service - while using the servlet init() as a way to setup a system when it loads, thats a really poor excuse for a startup/shutdown event that can allow users to setup the database etc...

    6. Mutable ejb context data - Most of the state/session data is held within the web tier using the application context/session context. This is problematic since the EJB's can't access these elements and may need some information. Stateful session beans aren't really appropriate since their usage isn't really portable (some application servers fail when a single instance is accessed by multiple threads). Normally we just pass all the data in the stack, which requires that everyone would accept value objects as parameters in case we want to add a parameter. A decent solution for J2SE is to use the thread context but that won't work through remote calls, so I think we need to show the data available is the session/application context through the EJB context.

    7. I'd like to join other posters in encoraging the use of meta data in the new spec. As I understand this is the direction already...

    8. Triggers - Something I'd like to see is the quivalent of database triggers. The default implementation can get invoked when an ejbStore() is invoked and changes data, but application servers can implement them as callbacks from the database thus support external modification.

    9. Please don't use generics/enums etc... other than whats really necessary. I can live with meta data since it really makes a difference, but there is a large number of people who don't like these features and would rather not use them (please don't turn this into a flamewar, lets leave it as a matter of taste).

    10. Allow EJB inheritance - while we can inherit the implementation and Component interface its really cumbersome. I have to create multiple "create" methods to allow different return types all because of poorly defined semantics from the 1.0 spec. I think you should feel free to break these semantics and allow an ejbCreate method to return Object etc...

    These are just things that immediately spring to mind, don't get me wrong I like EJB's and think their great but there is quite a bit of work to do to make them "real".
  9. |
    |Local interfaces are a BAD idea - why separate everything to two interfaces so
    |you at compile time decide how to deploy a bean???
    |

    In my experience, remote and local bean *implementations* have very different semantics.

    e.g. Remote beans usually have the last say in exception handling and transaction management (roll back / commit).

    Local beans, must be called from within the container, so they are unlikely to have the last say in anything...

    -Nick
  10. |

    > |Local interfaces are a BAD idea - why separate everything to two interfaces so
    > |you at compile time decide how to deploy a bean???
    > |
    >
    > In my experience, remote and local bean *implementations* have very different semantics.
    >
    > e.g. Remote beans usually have the last say in exception handling and transaction management (roll back / commit).
    >
    > Local beans, must be called from within the container, so they are unlikely to have the last say in anything...

    While that is valid, not all cases are clear cut for all circumstances and when talking about a component framework we need to make everything as generic as possible and not add another layer of complexity to the developer. I find that when I have to teach EJB's the cofusion due to remote/local interfaces is quite serious, it might be due to my personal taste being reflected onto the students but I personally doubt it.

    BTW notice that I didn't recommend the Remote interface as an alternative but something in between, I don't want to catch (or throw) RemoteExceptions in every single block of code.
  11. Having seen EJB's evolve, it strikes me, that what was once a simple idea adressing a simple need (removing the burden of serverside infrastructure coding from application programmers), has evoloved into a complex framework, meaning different things to different people.

    I have no specific suggestions but would like to make a general point. KEEP IT SIMPLE! POJOs and replacing descriptors with a meta-language like XDoclet could be a good thing if it is kept simple (simplicity meaning not complete, but the vital few).

    Some of the other suggestions I've read are OK in the rarefied atmosphere of specification committees, but in the real world keeping up with all this proliferation of standards and ideas takes real time and costs real money. A clear statement of the goal of EJBs and what they they DO NOT do would help. Given a clear focus - I believe that the new EJB standard should aim to improve developer productivity through better tool integration (rather than re-defining EJBs altogether). Other issues and approaches should be tackled by other frameworks/standards I believe.

    BTW could anyone point me to a clear goal statement for EJBs? I fear that in recent years a clear focus as been lost and replaced with the business goal of beating MS .NET (along with providing an opportunity for gurus to write and sell even more books).

    A bit cynical I know. But I do wish sometime that our industry would slow down, and take a more evolutionary approach to change.
  12. We know that EJB has provided us the facility to put the security at method level for a Bean which we mention on the deployment descriptor of the bean.

    I think this would be a great feature for the Entity Beans if EJB API provide us the facility to put the security at attributes level too.
  13. hi,

    I really think J2EE architecture is flawed somewhat.

    It is over architected in security / persistance / load balancing.

    All J2EE specification should be implemented only by VENDORS.

    EJB should be scrapped completely simply because developers should only concern about business objects and service it provides not all this technical things which can be handles by vendors (duplicates).

    I don't know why people (SUN) force every standards into Developers instead of vendors, to take care of security / loadbalancing /clustering through interceptors.

    If this architecture is so good , why i or every project team should worry about configuring for load balancing/clustering/caching. It has to be done automatically.

    J2ee is overarchitected and trying to give one major solution for every small problem.

    May be they need to provide light weight J2EE (without EJB).

    That is my cents worth.

    Alex
  14. TESTING[ Go to top ]

    One more major thing , TESTING.

    With this so much complexity like load balancing / clustering / caching / persistance ...we need comprehensive RUNTIME TEST / DEBUG ENVIRONMENT..like which EJB invoked , How container did , how much speed it performed on which server on which m/c....

    Every damn thing should be logged concurrently as we step into one Component to another.

    Alex
  15. Question the premise[ Go to top ]

    I don't know the creation story of EJB's but my software archeology leads me to believe they were conceived in the image of CORBA distributed objects which were based on three now discredited ideas; that every business object may be distributed, the overhead of distributed objects isn't important, and that it would become the standard distributed object interface.

    J2EE Design Patterns advocate local EJB's to remedy the sad performance of remote EJB calls. This begs the question of why incur the overhead to support remote transactions and security if you don't use it. What good does it do for an EJB to call isCallerInRoll() when the caller is always the local Servlet?

    Why should my product cost more just to pay for unused components. Why should my product be delayed because coding and testing with an EJB container is slow?

    At this point die hards will bring up standards. Fine, let me mix and match. Why can't I drop a “standard” Websphere component into WebLogic? Entity Beans are a standard that doesn't have reason to exist when it's called locally, as it should be, so why foist them on the inexperienced?

    I've been harping on this for some time and don't feel like going point by point but the problem of EJB's are clear and the clear first step is to offer developers an incremental path from proof of concept desktop application to integrated N-tier enterprise applications where services from any vendor are added as needed.

    Message Driven Beans are useful, Session Beans don't make sense if they're called locally, and Entity Beans don't make sense.

    Richard, thanks for a great book. I was at BEA's WebLogic training in San Jose when your second edition came out. I picked up a copy at Computer Literacy, across the street, and brought it back to class. The next day most of the class had your book and used it instead of BEA's documentation.

    Gary
  16. Question the premise[ Go to top ]

    Read this: http://www.softwarereality.com/programming/ejb/index.jsp

    We work with a prototype ERP framework. The company which makes it, uses Entity Beans for their framework. But because Entity Beans is too hard to learn and too cumbersome, they reinvented the wheel by inventing and creating an own persistance framework on top of Entity Beans. Their own persistence framework is even more unproductive than Entity Beans.

    I think JDO goes in a better direction. It seems much more "natural" than Entity Beans. I'm always against having to read and remember a lot of things until I can do something. JDO has a much flatter learning curve than Entity Beans. Hibernate seems to be even better than JDO. Its no standard, but I don't care as long as it is good and open source.

    Why do you spend time in improving Entity Beans when JDO and Hibernate provide better solutions? Or try to look at least at the good things in Hibernate and use them to improve Entity Beans.

    Use Test Driven Development, so that you see how hard it gets using your improved Entity Beans persistance framework, so that you wish eagerly to improve it.
  17. Security[ Go to top ]

    Right now EJB's specification has very coarsed grained security. Especially the Authorization part of the security model needs to improved.
  18. Shoulds[ Go to top ]

    Many "shoulds"/"should nots" in the spec makes your application not portable between application servers.
  19. Question the premise[ Go to top ]

    I've never used MDBs, but to me, entity beans are the only EJBs I see worthwhile. They provide a persistent, distributed domain object without all that much fuss coding. (Deploying & testing is another matter...)

    Only they suck.

    So what happens? We end up writing persistence (and sacrifice caching) directly into our objects. Or using an O/R tool and hoping the tool (or database) caches for us.

    We *do* need a container to handle this. And remoting, and I could see the use for transactional objects (I don't need them though.)

    I'm a scripter by preference, and would use perl, php, or python if it weren't for the fact that you can't really provide persistent, clusterable objects. So I'm using Java, because it has application servers that do this. But we need EJBs that aren't EJBs.

    I, for one don't care about EJB querying and "scalability" as much as simpler deployability and testing, but still having persistent, cacheable objects.
  20. room for improvement[ Go to top ]

    Somehow the bean object that you write (lets say you will use Xdoclet to generate the rest) should inherit from some interface all the methods like ejbCreate() and so forth that only the container contract enforces currently. I believe this might make it easier for beginning ejb programmers to understand how to write a bean.

    Another other thing I would suggest is to standardise the generative tag language, i.e. Xdoclet/EJBdoclet.

    Also, I would specify some further aspects of the EAR file class loading. If I want to bundle some lib jars up in my EAR file (in websphere 5.0 at least), there is a disconnect;

     - For given XYZ.jar file containing some EJBs, I have to specify the libraries I want to be available through the classloader in the EJB's MANIFEST.MF file.

     - However the paths have to be specified as they appear in the EAR file.

     - The library jar files live in the EAR file.

    The problem I have with this, is one of isolation of the ejb.jar file from the EAR file. The inner artifact has to know something about the containing artifact's composition (i.e. paths to other jars contained in it). Which I find sometimes unwieldly and certainly unfriendly.

    So, I say; why can't EAR files have a standardised lib path the way WAR files do? Or can the specifying of extra entries in the classpath be done in the EAR file's MANIFEST.MF or in the application.xml or otherwise in a way that the ejb.jar and the libraries it depends on can be specified seperately in an otherwise self-contained EAR file?

    thankyou
    scot mcphee.
  21. I agree with this but to what level should this be applied? Around the whole application (ear file) or just ejbs?

    If you want to go the full way why not something like having at the ear level an:
    * APP-INF/application.xml
    * APP-INF/libs
    * APP-INF/classes
    This level (APP-INF) contains libs/classes specific to the whole application (ie war files and ejb-jar files can share these libraries.

    at the ejb level:
    * EJB-INF/ejb-jar.xml
    * EJB-INF/libs
    * EJB-INF/classes

    and keep the WEB-INF as it is.

    I know this breaches the topic outside of EJB's specifically, but wouldn't this have been a sensible step from the start?

    At least for the next gen EJB's this could be made an option but the APP-INF may be a much larger step.
  22. Make it easier to test![ Go to top ]

    There are no doubt many who fall into the "Get rid of EJB" camp - many, that is, who dont need it.

    However, for NON-WEB serverside applications (you could be forgiven for thinking all apps are web apps, reading some vocal anti-EJB activists) EJB is very useful indeed.

    IMO, the largest failing that EJB2.x has is the difficulty (impossibility) of performing out-of-container testing. In-container testing is a pain to set up and too time consuming insofar as round-trip development is concerned. It is certainly no push-button affair.

    The first distinction to make (as many blur this distinction) is between CMP and EJB in general - I see this as two seperate areas.

    EJB in general:
    The majority of (non-entity) EJB's are stateless - and as such have more moving parts than required. Stateful and Stateless beans should be completely seperate components (not just a deployment option).
    1) The EJBHome is large unecessary. A SLSB has no ejbCreate parameters - hence a generic factory - ala StatelessEJBHome.create(MySuperFlyStatelessRemote.class) - would be all that would be necessary.
    2) The decoupling between Interface and Implementation should be removed. The container could easily perform byte-code modification to alter any instances of "return this". (Having a proper proxy in Java would be even better)
    3) Support for dependancy injection / IOC rather than JNDI. Most developers I speak to dont just dont get JNDI - and if some of more clever developers cant, then it says something. In any case, decoupling of the component from its environment (development/production) - one of the main points of JNDI - could be more better achieved through ejb container providing IOC services.


    O-R Mapping:
    Many argue that CMP is complex - and they are not wrong. However, they misplace the blame : the complexity is not purely CMP - O/R Mapping in general is a complex animal.

    Many of the complexities surrounding CMP (2.x) are common to any other O/R mapping implementation. However, there are certain complexities that are unique to CMP.

    1) The vendor/implementation independance comes at a high cost. The deployment descriptors are tedious to manage/synch. Auto-generation (xdoclet) has its own overheads in the round-trip cycle.
    2) Out of container testing with Entity beans is *practically* impossible.
    3) Independance from the appserver - it is not possible to use the entity beans in a non-appserver environment (testing being the first obvious driver).

    It is difficult to see how these could be solved easily.
    1) Seperation of CMP from EJB - a more generalised persistance service - that doesnt require a server would be a step in the right direction.
    2) A less intrusive coding model - reflection based.
    3) A heavy leaning to O-R mapping. 98% of developers of enterprise applications dont give a toss about flat file persistance or XML persistance, etc, etc - a capability often lauded by JDO. They are usually only interested in relational persistance.


    Asynchronous EJB:
    A final area for improvement would be around Message Driven Beans. Message driven beans are an excellent idea - and perfect for consuming messages transactionally from a queue (many weaknesses for topics). However, they have some shortcomings in real applications.

    1) Being able to "pause"/"restart" an MDB. It is a common requirement to be able to pause consumption from a particular destination - either programmatically or administratively - and to later restart it. (A resource that the MDB depends on may be down - e.g. a database - we want to pause it rather than fill logs with 1000's of errors)
    2) Guarantee of message consumption order. Some appservers allow the throttling of MDBs down to one MDB per server - but ideally, guaranteeing 1 per cluster would be required.
    3) Simplification of programming model. In many cases, it would be much simpler to code a stateless session bean, and mark it as asynchronous and let the container do the rest - rather than manual coding of all the pack/unpacking of call parameters as a JMS message.

    IMO there are many improvements to be made in EJB - and most of them center around making it simpler. Simpler to code. Simpler to test.

    -Nick
  23. room for improvement[ Go to top ]

    Somehow the bean object that you write (lets say you will use Xdoclet to generate the rest) should inherit from some interface all the methods like ejbCreate() and so forth that only the container contract enforces currently. I believe this might make it easier for beginning ejb programmers to understand how to write a bean.

    Another other thing I would suggest is to standardise the generative tag language, i.e. Xdoclet/EJBdoclet.

    Also, I would specify some further aspects of the EAR file class loading. If I want to bundle some lib jars up in my EAR file (in websphere 5.0 at least), there is a disconnect;

     - For given XYZ.jar file containing some EJBs, I have to specify the libraries I want to be available through the classloader in the EJB's MANIFEST.MF file.

     - However the paths have to be specified as they appear in the EAR file.

     - The library jar files live in the EAR file.

    The problem I have with this, is one of isolation of the ejb.jar file from the EAR file. The inner artifact has to know something about the containing artifact's composition (i.e. paths to other jars contained in it). Which I find sometimes unwieldly and certainly unfriendly.

    So, I say; why can't EAR files have a standardised lib path the way WAR files do? Or can the specifying of extra entries in the classpath be done in the EAR file's MANIFEST.MF or in the application.xml or otherwise in a way that the ejb.jar and the libraries it depends on can be specified seperately in an otherwise self-contained EAR file?

    thankyou
    scot mcphee.
  24. Easier SOA[ Go to top ]

    This may be my C# experience talking, but persistence probably shouldn't be handled by the app server. Most of the other comments seem to agree, stating that JDO and Hibernate provide better solutions that are independant of an app server.

    With entity beans out of the way, the focus should clearly be on session beans. POJOs could be used in place of the 3 to 5 classes/interfaces that are required today. Switching on web services should be nothing more than a change in the deployment descriptor. When beans are deployed, why can't reflection be used by the container to determine funcionality and types?

    Look at how easy it is to enable a C# class to be transactional or web service enabled.

    There's no reason C# guys should have all the fun.
  25. Interception![ Go to top ]

    ServletFilters have alredy proven very useful since they were introduced, and I have seen marvelous things made with them. Why not have the same concept possibly being applied to EJBs?

    I see a SessionBeanFilter as a quite useful addition. You could do instance-based security and authentication this way, plug validators, add some kind of dependency injection, and lots of other usefull stuff that today is somewhat "hardcoded" in the spec.

    Any negative points about this idea?
  26. +1 On That Idea[ Go to top ]

    Although some proprietary implementations of this idea are already available, the spec seems matrue and stable enough to add in interceptors at this point.

    You have my vote. Great idea.
  27. While Java and J2EE continue to grow as a platform, Sun focuses more on adding features but fails to improve the poor peformance of J2EE. Let's face it, nothing in J2EE has better performance than its competitors! Even those Java competitors. .Net has better performance in web application. CORBA event (in Java) has better much performance than JMS. Entity Bean is so slow, it is unuseable.

    Compared with what we have 3 years ago, today's J2EE development tools are much better. However, J2EE applications are still very hard to develop. One of the ojbectives of J2EE is to let programmer focusing on writing code, but it fails to delivery that. Programmers often spend excessive amount of time fighting with environment, starting servers and mysterious app server glitchs.
  28. why difficult ?[ Go to top ]

    Peoples who says EJB entity are hard to developp must not know XDoclet
    You kust declare getset methodes and persistance is done..
    i don't c how u can find it difficult !
  29. Dear Sirs!

    I think, when we talking "deprecate EntityBeans" , make JDO/Hibernate etc. as repsistence, we miss whole point.

    I think, the persistence now in Java world separated it 3 areas:

    1. Hibernate - no standards, simple to use, many features, ideal for small-middle size applications.

    2. JDO - standard, less simple of use, many vender specific features, ideal for middle - big size applications

    3. Entity EJB - standard, much less simple of use, huge amount of vendor specific features, ideal for big - huge size application

    When I developing standard apps - I use Hibernate with greate success.

    Now, I am developing on Weblogic cluster with 40 nodes. Am I ever use Hibernate/JDO here? NO! Weblogic have extremly amount of features to work in such environment.

    So, lets talk from huge development perspective to EJB 3.0

    1. We need get the best from Hibernate, KODO and others
    2. Inheritance.
    3. We should add concept of domains (grouping beans in domain etc. This allow optimistic locking with version on top bean of domain)
    4. We should add Query By Criteria API and Query By Example API
    5. Clear integration with Cache systems (JCache usage here?), caching collections, fields... (declarative caching)
    6. Cluster/Not cluster beans.
    7. Specification of eager/pre fetching (and large collections (large resultsets) such as in KODO)

    Regs,
       Dmitriy
  30. Entity Beans[ Go to top ]

    Nick,

    First of all, I was specifically suggesting to deprecate *Entity Beans* rather than to "get rid of EJB"; please re-read my post.

    > 1) Seperation of CMP from EJB - a more generalised persistance service - that doesnt require a server would be a step in the right direction.

    That's exactly what I'm recommending: Leave persistence to the likes of JDO and Hibernate (independent from an EJB container in the first place); let EJB vendors concentrate on infrastructure for distributed services instead.


    Dmitriy,

    > 1. Hibernate - no standards, simple to use, many features, ideal for small-middle size applications.
    >
    > 2. JDO - standard, less simple of use, many vender specific features, ideal for middle - big size applications
    >
    > 3. Entity EJB - standard, much less simple of use, huge amount of vendor specific features, ideal for big - huge size application

    Why do you consider Entity Beans "ideal for big size applications"? What do Entity Beans give you that you cannot achieve with Hibernate or Kodo in combination with clustered caching (e.g. provided by Tangosol Coherence)?

    I wonder whether a re-evaluation of your use of Entity Beans would show that this can be equally well addressed by persistence tools that are capable of clustered caching. Do you have specific requirements beyond clustered caching?

    Juergen
  31. Entity Beans[ Go to top ]

    Nick,

    >
    > First of all, I was specifically suggesting to deprecate *Entity Beans* rather than to "get rid of EJB"; please re-read my post.

    Just saw that you weren't specifically reacting to my suggestion, so please forget about the re-reading ;-)

    Juergen
  32. Entity Beans[ Go to top ]

    Nick,

    > >
    > > First of all, I was specifically suggesting to deprecate *Entity Beans* rather than to "get rid of EJB"; please re-read my post.
    >
    > Just saw that you weren't specifically reacting to my suggestion, so please forget about the re-reading ;-)
    >
    > Juergen


    I was reading top-down .... :-)

    -Nick
  33. Entity Beans[ Go to top ]

    |
    |Nick,
    |
    |First of all, I was specifically suggesting to deprecate *Entity Beans*
    |rather than to "get rid of EJB"; please re-read my post.
    |

    Are you replying to me?
    Because I wasnt replying or referring to you...
    :-)

    -Nick
  34. Dmitriy,

    Why do you say?:
    > Now, I am developing on Weblogic cluster with 40 nodes. Am I ever use Hibernate/JDO here? NO! Weblogic have extremly amount of features to work in such environment.

    Are you concerned about Hibernate's cache behavior in a large cluster or did you have something else in mind? I'm just curious as to why you feel the transparent architectures are less able to handle an extremely large application and then list for enhancements the good things we get from the Hibernate/JDO persistence models.

    > So, lets talk from huge development perspective to EJB 3.0
    >
    > 1. We need get the best from Hibernate, KODO and others
    > 2. Inheritance.
    > 3. We should add concept of domains (grouping beans in domain etc. This allow optimistic locking with version on top bean of domain)
    > 4. We should add Query By Criteria API and Query By Example API
    > 5. Clear integration with Cache systems (JCache usage here?), caching collections, fields... (declarative caching)
    > 6. Cluster/Not cluster beans.
    > 7. Specification of eager/pre fetching (and large collections (large resultsets) such as in KODO)

    It seems all of the features in your enhancement lists are features of Hibernate/JDO except for #3 & #6 although I'm not sure what #6 means. Could you elaborate?

    Thanks,

    Wayne
  35. Wayne,

    Mainly, I think about clustering environment.

    Do Hibernate communicate each other in cluster environment? Partially.
    Only by cluster cache.

    Do Weblogic? Yes. What weblogic do, it can, depended of loading, not created cache of certain type of beans on each machine, but just redirect the whole process to machine that allready have them.
       That just a example, how BigServers can work in clusters.

    Personally, I am not against Hibernate. More over, I think it a best persistence framework now. But it nature is lightweigth. And it should stay lightweigth.

        Regs,
           Dmitriy
  36. EJB-QL & XQuery[ Go to top ]

    I think better optimization of EJB-QL would be helpful and may be incorporation of XQuery.
  37. Better EJBs ? POJO[ Go to top ]

    In my personal opinion an EJB 3.0 should be as simple as a POJO (Plain Old Java Object). I really do hope in the future we will have POJO-like EJB for:

    - persistence (see JDO, Hibernate, ...)
    - transaction demarcation
    - service remoting and clustering (see JBoss 4.0)
    - security constraints

    I guess the first step is to start a JSR inside the JCP that define a standard for AOP programming, maybe based on JSR 175.
  38. Open up the EJB model, please[ Go to top ]

    Some of this has been mentioned already, but I feel the best thing that can be done to EJBs is to open them up completely. Today's technology is ready for it. See below.

     - Nail down the J2EE classloader infrastructure once and for all: whether the web tier classloader delegates to its parent first; how web tier classloaders, EJB classloaders, and the shared classloader interact; whether Class-Path in MANIFEST.MF is honored in wars and other resources; and so on.

     - Treat persistence options other than entity beans as first-class citizens. I accept that entity beans work for some, but many are disillusioned with them. Certainly entity EJBs have little to do with object-oriented persistence.

     - Treat co-locating web and EJB tier as a first-class architectural choice. Maybe you could even make the aspects mentioned above available to the web tier, blurring the distinction between the web container and the EJB container.

     - Support IoC... I mean dependency injection. It is so much less painful than looking stuff up in JNDI, and most of the time it's exactly what you need. Of course JNDI would still be there for compatibility and in case you need active lookup.

     - Consider introducing a jini-like ability to automatically ship business delegates to EJB clients, so that (1) the distinction between local and remote operation can to some extent be abstracted away from the client and (2) the bean developer gets more control over what work gets done on what tier.

     - Introduce a threading API that would allow the use worker threads without bypassing the server's thread pool. This would require clear semantics on the propagation (or lack thereof) of security and transaction contexts, etc.

     - Support for JDK 1.5 metadata as an alternative to XML configuration files is, I believe, already being planned.

     - Provide a standard, *lightweight* way of interfacing the EJB tier with code that needs to escape the EJB constraints in some way. Yes, this would to some extent break container resource management and transparent distributability, and put the onus on the developer to ensure he knows what he's doing. So what? The container may not need to manage all of our resources, distributability isn't transparent anyway, and developers already have to know about most of the things that we once imagined would remain hidden inside the J2EE black box.

     - This is not exactly a new observation, but the EJB tier can be regarded as an AOP container addressing a fixed set of aspects: pooling, transactions, persistence, role-based security, distribution... The best thing that can happen to EJB is for this to be generalized into a model where the programmer has full control over the advice applied to a given bean. For example, the developer may omit pooling if the bean is threadsafe, or replace the security interceptor by a custom one if role-based security is insufficient, or drop in a wholly new aspect. JBoss and Spring are leading the way here. The current EJB stack can be the default to retain backwards compatibility.

     - Simplify the programming model by splitting up the current EJB interfaces into small lifecycle interfaces that you only need to implement if you're interested in the callbacks and/or if you're using the aspects that are associated with them. If the AOP stack gets opened up then the set of interfaces that you implement will have to be much more flexible anyway.

     - Don't stop simplifying until the developer may implement a stateless session bean by just implementing the business interface and exposing resource dependencies (e.g. a setDataSource(DataSource) method), indicating the services it needs using metadata, and sticking its class name in a configuration file somewhere.

    That's my wishlist, and probably quite reflective of the things I happen to be doing right now. And of the fact that I happen to be doing a lot of them with Spring :)

     - Peter
  39. Open up the EJB model, please[ Go to top ]

    Nail down the J2EE classloader infrastructure once and for all: whether the web tier classloader delegates to its parent first; how web tier classloaders, EJB classloaders, and the shared classloader interact; whether Class-Path in MANIFEST.MF is honored in wars and other resources; and so on.

     
    Good point. I do see the value in separating classloaders for isolated components - as opposed to local components within an application, running in the same classloader. But a once-and-for-all clarification about classloader interaction is very important.

    > (...) For example, the developer may omit pooling if the bean is threadsafe, or replace the security interceptor by a custom one if role-based security is insufficient, or drop in a wholly new aspect.

    Another good point. Most SLSBs that I've come across are actually implemented in a thread-safe fashion: There is no need for locking during method invocations and thus pooling in such a scenario. SLSBs should make the common case the default here: Then there would finally be a clear singleton scope for SLSB instance variables, e.g. to keep a Hibernate SessionFactory or the like (instead of having them once per pooled bean instance).

    > JBoss and Spring are leading the way here. The current EJB stack can be the default to retain backwards compatibility.

    Note that there is a difference in philosophy between Spring and JBoss respectively Spring and EJB: Spring offers a lightweight container to be *embedded* in applications, be it a J2EE web application or a desktop application, for holding *logical* middle tiers and resources within an application (in a single classloader).

    In contrast, JBoss and standard EJB offer physically separated components: even if co-located, a separated classloader is a quite strong separation in deployment terms. Furthermore, EJB is essentially about distributed, self-contained components, while Spring hosts POJOs within a locally wired-up application (which I consider more appropriate for typical web apps, and the only way to go for desktop applications).

    So even if Spring allows you to have proper logical POJO middle tiers with a lot of conveniences like declarative transaction etc, this is "just" an alternative for using local SLSBs: Many local application components are better off hosted close to the callers (in the same classloader) but can still benefit from declarative transactions etc; this is what Spring addresses.

    To a large degree, Spring and EJB are more complementary than people might believe. Spring even offers dedicated EJB access and implementation support classes. Of course, if you just use local SLSBs for CMT, Spring provides a compelling alternative; local SFSBs are arguably somewhat meaningless anyway; remote SLSBs and SFSBs can be accessed and implemented with Spring's help (so can local SLSBs and MDBs, if desired).

    Juergen
  40. Open up the EJB model, please[ Go to top ]

    So even if Spring allows you to have proper logical POJO middle tiers with a lot of conveniences like declarative transaction etc, this is "just" an alternative for using local SLSBs: Many local application components are better off hosted close to the callers (in the same classloader) but can still benefit from declarative transactions etc; this is what Spring addresses.

    >

    Juergen, great posts in general, I don't mean to pick out one and be negative but I couldn't resist the classloaders point. (it is a bit of a pet peeve).

    You are confusing the point of classloaders in middleware with sharing classes within one class loader. In JBoss, since the 3.0 series for example we support

    1- complete cyclability of classes (through classloader instanciation)
    2- complete visibility of classes (through flat delegation).

    That model is the way to go for middleware where you have cyclability of services but still retain the possibility to collocate and share in memory.

    So most of your points about collocation and classloaders are wrong.

    marcf
     
    > To a large degree, Spring and EJB are more complementary than people might believe. Spring even offers dedicated EJB access and implementation support classes. Of course, if you just use local SLSBs for CMT, Spring provides a compelling alternative; local SFSBs are arguably somewhat meaningless anyway; remote SLSBs and SFSBs can be accessed and implemented with Spring's help (so can local SLSBs and MDBs, if desired).
    >
    > Juergen
  41. A J2EE specification feature rather than an EJB one: Specify the JNDI location of the javax.transaction.TransactionManager. Application code may not need it (it uses javax.transaction.UserTransaction), but many frameworks and tools do, like Hibernate and JDO implementations (for registering transaction completion callbacks). Currently, those tools need to implement some sort of pluggable TransactionManagerLookup, because every J2EE server uses a different JNDI location or even some static accessor method.

    Juergen
  42. Juergen: Currently, those tools need to implement some sort of pluggable TransactionManagerLookup, because every J2EE server uses a different JNDI location or even some static accessor method.

    And herein lies the crux of my problem with various J2EE specs: They are built on the assumption that the gifted geniuses that are designing a spec should protect the poor slobs that have to use it from themselves.

    Or, as has long been said in our industry: "Build a system so simple that even a fool can use it, and only a fool will use it."

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  43. Currently I have a need to add spatial data types to CMP. Because this is not easy to do in a portable manner, I'm being forced to use BMP, which I'm less than thrilled to maintain. If there was a best practice for entending the data types in CMP no doubt this would be a very valuable addition to anyone dealing with custom data types in the database.
  44. Light Weight Asynchronous Processing Capabilities and Better Warnings at compile time:

    One of the problems that I have seen in last 2-3 projects is lack of available alternatives in EJB for performance improvement. For some reason, majority of the code that I had seen was running under EJB. There are literally tons of EJBs in projects. In one case, I saw log4j being called from Stateless EJB. Code does not perform well and management asks for improving it. There was an attempt to improve the performance by using parallel processing of JDBC queries by spawning new threads from EJB. Needless to say that new solution is much more dangerous than the old non performing code.

    If possible, real light weight parallel processing framework callable WITHIN EJB will go long way in improving its usability. I know that WorkManager API is being worked on, but it should be seamlessly accessible from EJB.

    If you are looking to *improve* EJB, please consider that it is being misused heavily. EJB specs are too strict and hence they get broken. May be one way is to improve warnings/error given at the compile time and also focusing on implications of such a misuse in documentation rather than being silent about the effects of wrong usage.

    My 1 cent.

    - Parag
  45. Keep

    - Session Beans (Local/Remote)
    - Message Driven Beans (Local/Remote)


    Replace

    - CMP/BMP with an abstract Data Access Layer that can talk to Hibrenate, JDO or even Web Services. The Abstract layer will be necessary to enforce transaction demarcation in the session beans and message driven beans


    Add

    - Data Access Layer support for Cached Result Sets
    - Enhance Web Services support. Add web services wrapper beans that can automatically (minimal coding) communicate to an existing web service.
  46. Away with entity beans[ Go to top ]

    Do what Juergen says. Seriously, entity beans are a disaster and need to be put out of their (and our) misery.
  47. This is fantastic stuff[ Go to top ]

    GUYS,

    THIS IS TRULY FANTASTIC STUFF. I THINK WE ARE ALL PRETTY MUCH ON THE SAME PAGE AS TO WHAT POJO MIDDLEWARE SHOULD BE LOOKING LIKE. Lightweight EJB are the way to go.

    You will see some code coming out of us pretty soon.

    Long live JBoss.

    marcf
  48. This is fantastic stuff[ Go to top ]

    Marc, I don't mean this as offensive or flame bait but this seens quite a bit far from the "I love EJB's" caching mantra you were using before?
    I personally had a very bad OODBMS experience not due to faults of the DBMS itself but mostly to the people using it, which is why I am skeptical towards POJO persistance.
    I think CMP is OK it just needs some fixes and the implementations leave a lot to be desired (JBoss CMR is completely broken http://sourceforge.net/tracker/?group_id=22866&atid=376685&func=detail&aid=878879 and I personally couldn't get many features working in CMP). While I think everyone agrees EJB's should be simpler, I don't think the POJO approach will simplify anything, it will only move the complex stuff to XML files (that can't be compiled to find problems) and will make the lifecycle of the object even more complicated. In that sense I think Entity beans are very simple, they have an ugly but very well defined contract with the container and they are REALLY simple in the true sense of simplicity, they become complicated when we want to:
    A. Write them by hand.
    B. Use them in ways they were not intended to (which is pretty much any real world application see my previous posting).

    Anyway can you please share your current opinion on Entity beans? Has it changed since you wrote about them a couple of years ago or did you refine your ideas?
  49. This is fantastic stuff[ Go to top ]

    While I think everyone agrees EJB's should be simpler, I don't think the POJO approach will simplify anything, it will only move the complex stuff to XML files (that can't be compiled to find problems) and will make the lifecycle of the object even more complicated. In that sense I think Entity beans are very simple, they have an ugly but very well defined contract with the container and they are REALLY simple in the true sense of simplicity, they become complicated when we want to:
    > A. Write them by hand.
    > B. Use them in ways they were not intended to (which is pretty much any real world application see my previous posting).
    >
    > Anyway can you please share your current opinion on Entity beans? Has it changed since you wrote about them a couple of years ago or did you refine your ideas?

    I was a very big EJB fan a few years ago too, but I found more simple ways to implement the same things.
    Simple helpers for JDBC like iBatis or Voruta are more simple to learn, faster to code and test, and it is better for performance tuning (Old Plain SQL).
    I think there is no advantages in "hidden" SQL and criptic XML descriptors.
    I agree with people in this forum, CMP is useles for RDBMS. RDBMS is better solution itself than EJB or JDO, it is based on math theories, reserch. "Transparent Object Persitence" is just a dream at this time, is not it ?
  50. This is fantastic stuff[ Go to top ]

    I was a very big EJB fan a few years ago too, but I found more simple ways to implement the same things.

    > Simple helpers for JDBC like iBatis or Voruta are more simple to learn, faster to code and test, and it is better for performance tuning (Old Plain SQL).
    > I think there is no advantages in "hidden" SQL and criptic XML descriptors.
    > I agree with people in this forum, CMP is useles for RDBMS. RDBMS is better solution itself than EJB or JDO, it is based on math theories, reserch. "Transparent Object Persitence" is just a dream at this time, is not it ?


    I think the general uses for CMP are 2 fold:
    1. In heavy enterprise environments
    2. When you want things to be very componentised and don't really care about speed/some degree of flexability.

    I usually fall into the second. Most of the systems in which we use CMP's are systems where performance is important but not critical, only one or two features have extreem performance requirements in which case we use a fast lane reader.

    Flexebility in CMP helped us componentise large parts of the user management code for many projects (we have a single code base for multiple projects) and several other code bases such as inventory management.

    CMP didn't add much development overhead thanks to XDoclet and frankly it was rather efficient once slightly tuned.

    So, my bottom line is that CMP is good for what its intended to be: A pluggable component framework that can be tailored for needs on site. Sure it needs a lot of work but I don't think the concept or approach are fundamentally flawed.
  51. This is fantastic stuff[ Go to top ]

    So, my bottom line is that CMP is good for what its intended to be: A pluggable component framework that can be tailored for needs on site. Sure it needs a lot of work but I don't think the concept or approach are fundamentally flawed.


    Probably it is true, we develop a lot of trivial web/messaging applications in our company, so it can depend on my expierence. I just do not have any use case for CMP and probably I misused it a few years ago. Looks like it is designed for more trivial, single user applications where performance and development/testing time is not critical, but is it an enterprise application ?
    I see the single pragmatic solution in the market at this time (Hibernate), but
    some people are very sceptical about it too, CMP made this opinion about all of O/R mapping tools in JAVA (It is known as "slow","untestable","criptic")
    I think CMP deprication can help for more realistic solutions, It is very hard to sell any solution for object persistence at this time, most of people I know think "Object Persistence" == "Crap like CMP".
    It was unsuccessful experiment, It can be used for trivial use cases, but it is not so important to be in j2ee, the best results in our expierence are with Old Plain SQL anyway ( performance and "time to market" ).
  52. This is fantastic stuff[ Go to top ]

    I think there is no advantages in "hidden" SQL and criptic XML descriptors.

    > I agree with people in this forum, CMP is useles for RDBMS. RDBMS is better solution itself than EJB or JDO, it is based on math theories, reserch. "Transparent Object Persitence" is just a dream at this time, is not it ?

    That's exactly my opinion also. I tried some of the persistence frameworks and while there is a great benefit in the beginning(at least you generate classes for all the tables:-)) they get in your way eventually, and you still end up writing SPs. Yes, it's great to have master detail generated for you, but let's be serious, this is the easy 80% part of an application. A persistence layer is nothing else than dropping the D in ACID.
  53. This is fantastic stuff[ Go to top ]

    Shai,

    no problem on calling me on the "why I love EJB" paper. It is my story and I will stick to it. I am not deviating, more on this.

    >
    EJB's should be simpler, I don't think the POJO approach will simplify anything, it will only move the complex stuff to XML files (that can't be
    >

    We are about to find out for real if it is that complex. I DO share your concern on the complexity of container configuration and we have some ideas on how to do it clean in JBoss. We got the basic aspects done in JBoss 4.0, including some not that basic at all (JBossCache). what you will see is an assembly of aspects (like EJB is) so you can bring in some services to the pojo and make it behave *like* an EJB.

    >
    Anyway can you please share your current opinion on Entity beans? Has it changed since you wrote about them a couple of years ago or did you refine your ideas?
    >

    LOVE ENTITIES :) I haven't changed my opinion except for one part in fact.

    Basically I argued in "why I love EJB's" that EJB is an pre-AOP framework. It bundles all the services middleware should provide (cache, persistence, remoteness, threading, pooling, transactions, security) and exposes metatags for it. Trivial. Generalized interception and security as the basis for an EJB design is the real insight of that paper. I was glad to see many people reference these ideas here in this thread (including Spring :))

    It seems people get bogged down in interfaces (true) and we must solve the "complex problem" of JNDI lookups (!!!!please!) but the automated caching and persistence of entities always was the best feature of entities, something that many posts seem to miss here. The "entities must go" posts are idiotic :)

    One post here comes closer to the truth with "persistence + cache" are equivalent to entities, yes that is what entities are. Does that mean we should get rid of them? AU CONTRAIRE!!!! it means that we have a standard way of doing it. EJB introduced all that to the market 4 years ago. That is mostly why I still love EJB. They provide a packaged, standard, easy way of doing these core features.

    Also market standards are important, i predict a LONG lifetime for EJB, limitations and future versions included. This is a very wide basis to build upon (we know in our business). So I am looking forward to the iterations on EJB standards and we will probably be having this discussion on EJB 5.0, market standards have momentum on the upside and inertia on the downside. I am amused when I see people hailing their little framework-du-jour, backed by 2 clowns and their dog, as the "EJB killer", it is cute and oh so revolutionary, I relate. Market standard are powerful, very powerful. They are markets makers, period.

    The one thing where I have change my stance is on the persistence layer. I think we need an alternative to CMP 2.0 "mon amour" :) I thought JDO was a mess of a spec and had little hope it would see the light of day. However I don't like getters and setters on EJB and AOP/bytecode manipulation showed us they are un-necessary. JDO gets that simple point. It is a contender today imho if and only if they can simplify JDO2.0 which is becoming a bit of a beast in its own right. CMP 2.0 was what 60 pages long? couldn't the JDO guys do it right?

    Since then also we recruited Hibernate into the JBoss.com project family (like tomcat and jgroups). A decent EJB model on JDO could be a good one to have. So I am totally open either way, we make money either way ;) we will let you guys decide.

    marcf
  54. This is fantastic stuff[ Go to top ]

    It is a contender today imho if and only if they can simplify JDO2.0 which is becoming a bit of a beast in its own right. CMP 2.0 was what 60 pages long? couldn't the JDO guys do it right?
    Observing how badly you have your facts wrong here made me much less bothered about the offensive nature of the rest of your post. You might like to count how far you're out, before you call people "idiotic". (Hint, it's a lot more than a hundred pages.)


    I am amused when I see people hailing their little framework-du-jour, backed by 2 clowns and their dog, as the "EJB killer", it is cute and oh so revolutionary,

    If you're referring to Spring, at least have the guts to say so. It has a lot more than two clowns and a dog behind it. Like published AOP code used in production in real applications (including investment banking)... And a large user community. Why don't you concentrate about what's good in JBoss 4--and perhaps share some dates for release of your AOP stuff--rather than spread FUD about projects you obviously perceive as a threat? I wasn't going to bite, but this is the second recent thread in which you've attempted to smear other projects such as Spring and Pico/Nanning, so I can't resist.

    Btw the declarative service model in Spring is completely portable. We have it in production on WebLogic, WebSphere, etc. (even JBoss :-)

    Regards,
    Rod
  55. Redundant effort[ Go to top ]

    I'm not lazy learning new things. But I'm lazy learning obsolete stuff.

    As many people said before, persistance is a general issue. It is not J2EE specific. So there should be a uniform solution for all types of applications, not just for J2EE applications.

    Entity Beans are just meant for J2EE applications, aren't they? So for J2EE I have to learn Entity Beans stuff, for other kinds of applications I have to learn Hibernate or JDO. If I am coding J2EE applications and non J2EE applications and want to use a persistance framework, I have to learn two complex things, Entity Beans and Hibernate or JDO or some other ORM.

    What is productivity? Spend time learning two persistance frameworks instead of one all purpose persistance framework?

    I think there are so many things to learn, the head is so small and the day has only 24 hours. Nothing of it will change in the next centuries. So why not be smart and do it the Microsoft way or the Highlander way: There can only be one [persistance technology]. I don't mean it so extreme of course. Competition must not end. Lets save our brain and time for learning non redundand technologies, things which are easy to learn, which are natural, which are the opposite of Entity Beans...

    EJB 3.0 is like fairytale. If you improve it, it will completely change. Like the frog which becomes a prince.

    Whatever you do, do it the lightweight way, not the heavyweight way.
  56. This is fantastic stuff[ Go to top ]

    you call people "idiotic". (Hint, it's a lot more than a hundred pages.)


    Ok so the spec on CMP is 100 pages not 60. Big deal. Thanks for that insight.

    >
    >
    > I am amused when I see people hailing their little framework-du-jour, backed by 2 clowns and their dog, as the "EJB killer", it is cute and oh so revolutionary,
    >

    > If you're referring to Spring,

    1- Don't call me on guts, it is a mistake
    2- Actually I wasn't. I was talking in general.

    >
    I wasn't going to bite, but this is the second recent thread in which you've attempted to smear other projects such as Spring and Pico/Nanning, so I can't resist.
    >

    It isn't the particular projects that I was talking about, I met with aslak et al and they are good guys, fun to hang out with. I am sure you are a fine fellow as well if we only met. It isn't the people or the projects I have a problem with it is the "atomization" of the projects and efforts with little units of ego squandered around that piss me off.

    There is SO MUCH work in getting market penetration, SO MUCH WORK, and as developers we sit here and think we are on top of the world with our little projects including JBoss. Bah, this is where I disconnect profoundly. Any standard that is established will sweep any framework. We are being naive as only developers can be, starring at our navels.

    I am trying to be constructive and am reading this with great interest and we will try and put our code there.

    marcf

    PS: why? do you hail Spring as an EJB killer? it is news to me, for me it was an AOP framework.

    > Btw the declarative service model in Spring is completely portable. We have it in production on WebLogic, WebSphere, etc. (even JBoss :-)
    >
    > Regards,
    > Rod
  57. This is fantastic stuff[ Go to top ]

    There is SO MUCH work in getting market penetration, SO MUCH WORK, and as developers we sit here and think we are on top of the world with our little projects including JBoss. Bah, this is where I disconnect profoundly. Any standard that is established will sweep any framework. We are being naive as only developers can be, starring at our navels.

    >

    Standards might be important but individual developers are more important. If the standards fail to deliver what a lot of individual developers need, then they will come up with their own solutions, circumventing the standards if necessary. If nobody was interested, there would not be much attention paid to the handful of developers that are exploring alternative solutions to the heavy weight containers. You can say that's like "starring at our navels" but you can also say that the people involved in the standards need to "get their heads out of the sand" and start incorporating these new features.

    I'd like to see the J2EE split into a J2EE Web and a J2EE EJB standard. In my opinion they have nothing more in common than a few shared APIs. Give us a J2EE Web Certified and a J2EE EJB Certified brand. This will give the container providers more flexibility in what they want to provide.

    Thomas
  58. There is a huge hole in the specification around authentication.

    BEA have done some work (on the whole pretty good IMO with some omissions I hope they will address in the next release) with their security provider APIs. (In particular things like their role mapper or equivalent are essential for large scale applications). However much or all of this should really be standardised.

    JAAS was never designed for distributed computing or J2EE and on its own is not sufficient.

    --Robert
  59. This is fantastic stuff[ Go to top ]

    It isn't the particular projects that I was talking about, I met with aslak et al and they are good guys, fun to hang out with. I am sure you are a fine fellow as well if we only met. It isn't the people or the projects I have a problem with it is the "atomization" of the projects and efforts with little units of ego squandered around that piss me off.

    >
    > There is SO MUCH work in getting market penetration, SO MUCH WORK, and as developers we sit here and think we are on top of the world with our little projects including JBoss. Bah, this is where I disconnect profoundly. Any standard that is established will sweep any framework. We are being naive as only developers can be, starring at our navels.
    >
    > I am trying to be constructive and am reading this with great interest and we will try and put our code there.

    All other things being equal, standards are great. However, (and as an open-source advocate you should know this), a non-standard, open-source product which works great, can effectively become its own standard. 9 out of 10 developers I meet who've used both Entity EJBs and Hibernate (or another decent O/R mapper like TopLink), would rather cut off their right arm than go back to EJBs. This says to me the standard is more than just a little bit suboptimal.

    Would I like to use a standard persistence mechanism? You bet! If JDO 2.0 or some future standard works as well as Hibernate (or TopLink), then I will jump on it. In the meantime, Hibernate is it; EJB 2.0 doesn't cut it, and it's very hard to see it evolving somewhere where it will maintain backwards compatibility and still be a pleasure to use.

    Regards,
    Colin
  60. This is fantastic stuff[ Go to top ]

    Marc,

    Ok so the spec on CMP is 100 pages not 60. Big deal. Thanks for that insight.
    It's a lot more than 100 pages, but we're getting there :-) The point is that you implied that CMP was simpler than JDO 1.0. It isn't--especially in its implications for domain models. So it was worth correcting your mistake regarding the page count.

    Any standard that is established will sweep any framework
    Which is why everyone uses CMP in new projects instead of Hibernate, and why CORBA took over the world. Seriously, look at Hibernate (now in the JBoss stable). A product that good will succeed, regardless of whether it's outside a spec, if there isn't a spec that addresses that problem well. Furthermore Hibernate (like Spring) is about POJOs. Not much to standardize there: with Hibernate I can transparently persist my domain model. With Spring I can have declarative transaction management (in any server or in Tomcat) for any POJO. With CMP I can't persist my domain model without making it jump through hoops. I can't make POJOs transactional using EJB without at least an EJB facade etc.

    Standards are important. But they have to deliver. And your own strategy with JBoss 4 is about trying to push beyond the spec. JBoss right now is a J2EE server. It competes on price with the likes of WebLogic. You want to make JBoss 4 a different beast, offering AOP capabilities beyond the standard, but which will sacrifice portability. I share many of your goals for JBoss 4, but I'm not totally convinced by your "standards rule" argument.

    Regards,
    Rod
  61. can post XML?[ Go to top ]

    <some>
      <xml>
      </xml>
    </some>
  62. This is not fantastic stuff[ Go to top ]

    It is a contender today imho if and only if they can simplify JDO2.0 which is becoming a bit of a beast in its own right. CMP 2.0 was what 60 pages long? couldn't the JDO guys do it right?

    > Observing how badly you have your facts wrong here made me much less bothered about the offensive nature of the rest of your post. You might like to count how far you're out, before you call people "idiotic". (Hint, it's a lot more than a hundred pages.)
    >
    >
    > I am amused when I see people hailing their little framework-du-jour, backed by 2 clowns and their dog, as the "EJB killer", it is cute and oh so revolutionary,
    >

    > If you're referring to Spring, at least have the guts to say so.

    The "new" Marc may shy away from trashing you, but I won't. Spring, Nanning, PicoContainer are nothing more than cutsy little frameworks implementing low hanging fruit problems. I find it very humerous how you wrap yourselves in cutsy academic language like "Inversion of Control" and expect the rest of us to go oooo, and aahhh!

    First let's compare your cutsy little framework to JBoss 3.x microkernel(and yes, it can be complete run without any J2EE component. Comes with "minimal" configuration). Not JBoss 4, we'll save that for later, just JBoss 3.x. Let's look at XML from Spring:

    <bean>
      <bean id="exampleBusinessObject" class="example.ExampleBusinessObject">
        <property name="transactionManager"><ref bean="myTransactionManager"/></property>
        <property name="dataAccessObject"><ref bean="exampleDataAccessObject"/></property>
        <property name="exampleParam"><value>someOtherValue</value></property>
      </bean>
    </beans>

    Then similar XML from JBoss 3.x:

    <server>
      <mbean name="some:name=MyService" xmbean-dd="myOptionalDD.xml" class="example.ExampleBusinessObject">
        <depends optional-attribute-name="TransactionManager">jboss:service=TM</depends>
        <attribute name="exampleParam">someOtherValue</attribute>
      </mbean>
    </server>

    What we see from these two XML fragments is that they both support some component loading, lifecycle, and IoC. IoC parting being abstracting out how the reference to the TM is set in the POJO class. I'll give Spring the benefit of the doubt and assume it waits to deploy MyService until TM has been deployed, so I'll assume you support dependency management.

    Interceptors. Spring also seems to have the ability to define interceptors. JBoss's XMBean descriptor also has the ability.

    Metadata? Didn't see it within Spring, but JBoss XMBeans allow the definition of other metadata like security, persistence(lightweight), method descriptions (for UI see later), or any other arbitrary, user-defined metamodel.

    Ok, now let's compare other features and Spring just starts to fall apart (Pico has already fallen apart when we got to interceptors)....

    ClassLoading. JBoss container has the abilityto flatten out classloader hierarchies so that all code gets to access any class in any jar/component. If you need more fine-grained control, you can define classloader sandboxes that can span one or multiple component packages, if, for example you have different versions of the same class you need to access within different components.

    Next, full support for hot-deployment and class cycling.

    Next, a pluggable Deployer mechanism in which you can plug-in your own packaging (jars) and configuration (DDs) AND get all the hot-deployment, dependency management features.

    ---- Now let's look at the optional features you can snap on -----

    Next, full GUI management through our web-console. Generic management screens rendered from the exposed API of your POJO. In JBoss 3.2.3, the ability to show a live graph of numeric attributes. In JBoss 3.2.4 (released this month), the ability to create alert monitors on any component attribute and to receive EMAIL or SNMP events when monitors reach their threshold. Also the ability to record and save a snaphost of attribute data in a given time period and graph it.

    Next, how about remoting? How about invoking on these services remotely? Yes, JBoss 3.2 has connectors for this(SOAP connector in JBoss 4). And yes, you can hook in user transactions and role-based security.

    All available NOW in JBoss 3.2 already in production in thousands of sites worldwide, downloaded 200K per month, etc...

    > It has a lot more than two clowns and a dog behind it. Like published AOP code used in production in real applications (including investment banking)... And a large user community. Why don't you concentrate about what's good in JBoss 4--and perhaps share some dates for release of your AOP

    Ok, let's jump into JBoss 4 now. First let me say that we will have another beta release of JBoss 4 in March with an iteration of our AOP stuff as well as new J2EE 1.4 features that are ready. While JBoss 3.x architecture focused on POJO based services, instance interceptions, and such, JBoss 4 brings interception to the Class level in the ability to define interception points on construction, field access, and method invocations.

    We have a bunch of aspects written on top of our framework

    - JBossCache (beta released in November) uses AOP to transparently provide transactional versioning and cluster-wide replication to POJOs. (courtesy of Bela Ban and Ben Wang based on another JBoss.org project JGroups).

    - J2EE a la carte. We could already do tx and security in JBoss 3.2 at the instance level, but these interceptors have been ported to the AOP framework to provide it declaratively at the Class level to any POJO.

    - Fully transparent remoting. Based on JBoss Remoting project (courtesy of Tom Elrod and Jeff Haynie) provides remoting capabilities to any POJO as well as clustering (failover, loadbalancing)

    - Simple Asynchronous communication. Putting a face on JMS. CORBA oneway invocations or asynch communication between POJO's via JMS or JGroups.

    - Misc. transactional locking aspects, full thread logging api, etc...

    > stuff--rather than spread FUD about projects you obviously perceive as a threat?

    Threat my ass. We had this technology long before you even had your first download, so to put it bluntly, piss off. Our sole mistake was that we haven't marketed our solutions.

    > I wasn't going to bite, but this is the second recent thread in which you've attempted to smear other projects such as Spring and Pico/Nanning, so I can't resist.
    >

    And I can't resist either.... I still find it funny you all come to us for persistence (Hibernate) and eventually will come to us for clustering (JGroups).

    Bill
  63. First of all I'd like to say I'm not going to repond to any useless comments around here.

    You're comparing things that can't be compared. JBoss is a full-fledged J2EE-server including EJB support. Spring is a J2EE application framework, suitable for all kinds of applications, capable of running in just an application, also for most of the usage scenario's requiring an application.

    But, to get into some of the things you seems to think Spring is lacking:
    Metadata? Didn't see it within Spring, but JBoss XMBeans allow the definition of other metadata like security, persistence(lightweight), method descriptions (for UI see later), or any other arbitrary, user-defined metamodel.
    .NET style attributes, providing out-of-the-box, possibility of defining you're own source-level metadata format.

    ClassLoading. JBoss container has the abilityto flatten out classloader hierarchies so that all code gets to access any class in any jar/component. If you need more fine-grained control, you can define classloader sandboxes that can span one or multiple component packages, if, for example you have different versions of the same class you need to access within different components.
    Spring's objective is not to provide the best J2EE-server out there, including non-spec-compatible features. Spring wants to make ease the pain with respect to J2EE development, using WebLogic, Tomcat, Resin, Jetty but also JBoss (yes, I've personally got three applications in production using a Spring-JBoss combo) as a supporting platform. Being portable is one of the ideas and providing custom classloading issues would prevent us from being portable. Juergen earlier comments on the classloading were focussed on the specs/standards, not on existing products.

    Next, full support for hot-deployment and class cycling
    If JBoss supports hot-deployment, so does Spring, Spring uses JBoss, remember...

    Next, a pluggable Deployer mechanism in which you can plug-in your own packaging (jars) and configuration (DDs) AND get all the hot-deployment, dependency management features.
    See comment above.
     
    Next, full GUI management through our web-console. Generic management screens rendered from the exposed API of your POJO. In JBoss 3.2.3, the ability to show a live graph of numeric attributes. In JBoss 3.2.4 (released this month), the ability to create alert monitors on any component attribute and to receive EMAIL or SNMP events when monitors reach their threshold. Also the ability to record and save a snaphost of attribute data in a given time period and graph it.
    You've somewhat got a point here, although again, I have to say, we don't aim to provide a management server. But I like those features, really I do!

    Next, how about remoting? How about invoking on these services remotely? Yes, JBoss 3.2 has connectors for this(SOAP connector in JBoss 4). And yes, you can hook in user transactions and role-based security.
    Out-of-the box Burlap, Hessian, RMI and JaxRPC support is what Spring provides.

    All available NOW in JBoss 3.2 already in production in thousands of sites worldwide, downloaded 200K per month, etc
    All available now in SpringM4 (RC1 due next week). Of course Spring isn't final yet, so you can't expect a project that young to be in production at thousands of site (although it wouldn't amaze me). About quality: one thing I'm sure of. Whenever Spring reaches version 3.2.2, it won't have nasty classloading bugs that I've been fixing with dozens of customers.

    I'm sure other people will comment some more, so I'll leave it with this. And please, stop throwing mud, I don't like to take yet another shower...
  64. First of all I'd like to say I'm not going to repond to any useless comments around here.

    >
    > You're comparing things that can't be compared. JBoss is a full-fledged J2EE-server including EJB support. Spring is a J2EE application framework, suitable for all kinds of applications, capable of running in just an application, also for most of the usage scenario's requiring an application.
    >

    And our microkernel can be used to implement just about any application as well. You and others have to stop doing your own subtle FUD and painting us as solely a J2EE-server. JBoss 3 was not designed as a J2EE-server, but rather an abstract, enterprise container in which J2EE is just a personality of.

    > But, to get into some of the things you seems to think Spring is lacking:
    > Metadata? Didn't see it within Spring, but JBoss XMBeans allow the definition of other metadata like security, persistence(lightweight), method descriptions (for UI see later), or any other arbitrary, user-defined metamodel.
    > .NET style attributes, providing out-of-the-box, possibility of defining you're own source-level metadata format.
    >

    Same here as far as .Net style attributes (a la XDoclet). Didn't know about this. it is not on your website at first glance. I guess we're both guilty of not marketing our stuff well.

    > ClassLoading. JBoss container has the abilityto flatten out classloader hierarchies so that all code gets to access any class in any jar/component. If you need more fine-grained control, you can define classloader sandboxes that can span one or multiple component packages, if, for example you have different versions of the same class you need to access within different components.
    > Spring's objective is not to provide the best J2EE-server out there, including non-spec-compatible features.

    And JBoss's objective is not to hobble user applications with spec-compatible features that are hobbling. It's like saying, "We can't offer caching because the EJB spec doesn't define the interaction with Entities very clearly"

    >Spring wants to make ease the pain with respect to J2EE development,

    While you aim to ease J2EE development by being a container within a container, our aim is to be THE container. While you delegate the difficult problems to the real containers, we aim to actually solve these problems. While you are dependent on a uber container like JBoss, Weblogic or Websphere, we are an uber container, we are a solution. A solution in which you decide which components you want a la carte. A solution in which you can plug-in third-party implementations if you decide ours isn't up-to-par. Spring has to work within other containers as it is the only way you have a chance to be adopted. We just don't have that disadvantage.

    >using WebLogic, Tomcat, Resin, Jetty but also JBoss (yes, I've personally got three applications in production using a Spring-JBoss combo)
    > as a supporting platform. Being portable is one of the ideas and providing custom classloading issues would prevent us from being portable. Juergen earlier comments on the classloading were focussed on the specs/standards, not on existing products.

    The problem is again that "standard" class loading behavior hobbles many applications which is why the classloading mechanism of JBoss was invented. When you find that you want your "container" to go beyond cutsy, you'll find you want this type of flexibility. But then again, maybe you're only interested in the easy problems and choose to delegate those problems to a real container.

    >
    > Next, full support for hot-deployment and class cycling
    > If JBoss supports hot-deployment, so does Spring, Spring uses JBoss, remember...
    >

    If you can package Spring in a JAR, drop it in JBoss's deploy directory and have it deploy Spring services automatically, then sure you gots. But do you gots?

    > Next, a pluggable Deployer mechanism in which you can plug-in your own packaging (jars) and configuration (DDs) AND get all the hot-deployment, dependency management features.
    > See comment above.
    >

    Stupid and probably false answer. Do you have a way to package custom configured deployment mechanisms that can boot into your Spring runtime AND be hotdeployable and be able to hook into classloading schemes? Doubt it. When you decide that you want to go beyond cutsy, you'll see that these types of things will be necessary.

    > Next, full GUI management through our web-console. Generic management screens rendered from the exposed API of your POJO. In JBoss 3.2.3, the ability to show a live graph of numeric attributes. In JBoss 3.2.4 (released this month), the ability to create alert monitors on any component attribute and to receive EMAIL or SNMP events when monitors reach their threshold. Also the ability to record and save a snaphost of attribute data in a given time period and graph it.
    > You've somewhat got a point here, although again, I have to say, we don't aim to provide a management server. But I like those features, really I do!
    >

    Which brings me to my cutsy point. You want to solve real problems and go beyond cutsy, you need to start looking into adding these types of features. We've only just begun and have a long way to go in this area.

    > Next, how about remoting? How about invoking on these services remotely? Yes, JBoss 3.2 has connectors for this(SOAP connector in JBoss 4). And yes, you can hook in user transactions and role-based security.
    > Out-of-the box Burlap, Hessian, RMI and JaxRPC support is what Spring provides.
    >

    Ok, fine. Wrong, apologies. Again, didn't see this at first glance on your website.

    > All available NOW in JBoss 3.2 already in production in thousands of sites worldwide, downloaded 200K per month, etc
    > All available now in SpringM4 (RC1 due next week).

    Sigh...RC1 when JBoss 3.2 has been around for 1 year, JBoss 3 two years.

    >Of course Spring isn't final yet, so you can't expect a project that young to be in production at thousands of site (although it wouldn't amaze me). About quality: one thing I'm sure of. Whenever Spring reaches version 3.2.2, it won't have nasty classloading bugs that I've been fixing with dozens of customers.
    >

    All software has bugs. I'm sure Spring has plenty.

    > I'm sure other people will comment some more, so I'll leave it with this. And please, stop throwing mud, I don't like to take yet another shower...

    Mud, shmud. I'm just tired of you guys crying revolution when the revolution was already planned and implemented long before you wrote a line of code. We take a lot of heat whenever we post about anything, its time others were put under the same microscope.

    Bill
  65. Flame Warz[ Go to top ]

    C'mon guys, lets calm down a bit, I hate to see my friends fighting with each other!

    It is true that JBoss 3.x microkernal architecture is perhaps the most underappreciated thing in Java open source. Here is something truly practical, truly elegant that really actually works in some huge mission critical applications (now that I have inside knowledge of some of the places where JBoss is deployed, I gotta say that some people here would just choke if they found out). This stuff really is far ahead of what other EJB container vendors are providing.

    It is also true that the design of the JBoss anticipates many of the notions that we now find in the lightweight container space (Spring/Pico/etc). However, it is my personal view that lightweight containers =do= bring something new to the table and that, for example, I could see myself wanting to run the Spring BeanFactory as an MBean on top of the JBoss JMX bus. It is equaly true that there are some things I can do in JBoss JMX container that I simply couldn't do in Spring or Pico - the new HibernateDeployer/.har archives will demonstrate this - and Bill mentions some of these things (hot deploy etc).

    While I wish I could run HibernateDeployer or something like it in any J2EE container, I know I can't, so I'm glad that I can at least run Spring/Pico.

    P.S. In response to the completely off-topic criticisms of the JBoss CMP engine, I would like to note that the people who had previously been responsible for the implementation of JBoss CMP have now left the company and formed CDN. Currently the CMP engine is maintained by Alex Loubayansky who has apparently been doing a great job with it. Alex and myself are working on a "CMP on Hibernate" implementation. A prototype exists already, and most of the changes that were required on our (Hibernate) side of the fence already exist in the Hibernate 2.2 branch. I can assure the community that this will be the most sophisticated CMP engine available.
  66. Flame Warz[ Go to top ]

    C'mon guys, lets calm down a bit, I hate to see my friends fighting with each other!

    >

    Eh! They deserve some trash talking. We get enough of it, I'm tired of receiving. It is a time for some giving (As Cameron would say "Fight! Fight! I wanna see a fight!". Surprised he isn't egging us on!) Without this trash talking, TSS would truly be a boring read :)

    > It is true that JBoss 3.x microkernal architecture is perhaps the most underappreciated thing in Java open source. Here is something truly practical, truly elegant that really actually works in some huge mission critical applications (now that I have inside knowledge of some of the places where JBoss is deployed, I gotta say that some people here would just choke if they found out). This stuff really is far ahead of what other EJB container vendors are providing.
    >
    > It is also true that the design of the JBoss anticipates many of the notions that we now find in the lightweight container space (Spring/Pico/etc). However, it is my personal view that lightweight containers =do= bring something new to the table and that, for example, I could see myself wanting to run the Spring BeanFactory as an MBean on top of the JBoss JMX bus. It is equaly true that there are some things I can do in JBoss JMX container that I simply couldn't do in Spring or Pico - the new HibernateDeployer/.har archives will demonstrate this - and Bill mentions some of these things (hot deploy etc).
    >

    Gavin, I agree with you in part. JBoss microkernel does already provide most of the features of Pico and Spring(without the MVC). The lifecycle, dependency management, and IoC. What we need to do is package it, productize it and drive it as a separate framework and test it as a container within another container and rework any issues that are there.

    Bill
  67. Flame Warz[ Go to top ]

    Bill: (As Cameron would say "Fight! Fight! I wanna see a fight!". Surprised he isn't egging us on!)

    Well, you guys are doing fine without me. ;-)

    While I enjoy a good ruckus as much as the next person, I do think that it's important to maintain respect for others' points of view. So while I do my share of trash talking (and as you said, I probably egg others on a bit,) I also try to listen hard.

    And while Rod and Juergen are definite hype-monkeys, they've obviously got some good ideas to back up at least some of it. I've talked to a couple Springiacs, and they really like how Spring simplifies various parts of their development ... you know, what J2EE was supposed to do for us ;-) ... so give them their due. And heck, if you like parts of it, copy it. Isn't that what open source is supposed to be about? Not hoarding, but freely taking and encouraging others to do the same.

    BTW One other question -- any ETA on the J2EE cert for JBoss?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  68. Flame Warz[ Go to top ]

    Bill: (As Cameron would say "Fight! Fight! I wanna see a fight!". Surprised he isn't egging us on!)

    >
    > Well, you guys are doing fine without me. ;-)
    >

    Going to parade? I'm sick as a dog...watching it on TV.

    Bill
  69. Flame Warz[ Go to top ]

    While I enjoy a good ruckus as much as the next person, I do think that it's important to maintain respect for others' points of view. So while I do my share of trash talking (and as you said, I probably egg others on a bit,) I also try to listen hard.


    > And while Rod and Juergen are definite hype-monkeys, they've obviously got some good ideas to back up at least some of it. I've talked to a couple Springiacs, and they really like how Spring simplifies various parts of their development ... you know, what J2EE was supposed to do for us ;-) ... so give them their due.

    Cameron, thanks for your respect. BTW, I haven't heard the term "hype-monkey" before ;-)

    Note that while we certainly do our share of early promotion, our stuff is already used in production in quite a lot of places, despite not officially being "1.0 final" yet (we will be shortly). Anyone using JBoss 4's early access AOP framework in production yet? Anyone likely do use it in production within the next half year?

    By all appropriate respect, JBoss 4 has been hyped at least as much as Spring has been, particularly compared to what has actually been delivered. And as pointed out numerous times, they're different beasts anyway (application framework vs application server): Spring is happy to run on JBoss (3/4/whatever); it complements JBoss' J2EE personality.

    Juergen
  70. Flame Warz[ Go to top ]

    I haven't heard the term "hype-monkey" before ;-)

    I don't know ... maybe I made it up, but it's hard to believe that I could be so creative. ;-)

    Anyone using JBoss 4's early access AOP framework in production yet? Anyone likely do use it in production within the next half year?

    It's probably already used in production somewhere; not everyone is risk averse. Like you said, people are using Spring and it's not even 1.0 ... even if it's good, there's still a lot of risks with using a prenatal product.

    By all appropriate respect, JBoss 4 has been hyped at least as much as Spring has been, particularly compared to what has actually been delivered.

    Marc's a hype-monkey too ... certainly one of the best in open source. It's a tricky game, but so far he's played it quite well, considering how much free press and interest he's garnered.

    And as pointed out numerous times, they're different beasts anyway (application framework vs application server): Spring is happy to run on JBoss (3/4/whatever); it complements JBoss' J2EE personality.

    Yes, true enough, but they still will compete for mindshare and eyeball-time, and ultimately dollars (consulting, training, etc.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  71. Flame Warz[ Go to top ]

    Spring is pure hype. Anytime I see long names like org.springframework.aop.framework.autoproxy.metadata.AttributesThreadLocalTargetSourceCreator, I just avoid that stuff.
  72. Flame Warz[ Go to top ]

    Gavin, I agree with you in part. JBoss microkernel does already provide most of the features of Pico and Spring(without the MVC). The lifecycle, dependency management, and IoC. What we need to do is package it, productize it and drive it as a separate framework and test it as a container within another container and rework any issues that are there.


    Well, you'd have to add interception and a few other things, but great. I wish you would have done it years ago. The more choice the better. In late 2000 or so when Rickard first created the JMX based container I killed some significant time duplicating this functionality for a company I was working in. (Had they been willing to accept LGPL code, I could have of course ripped out just that code from the JBoss distro)...

    Regards,
    Colin
  73. Flame Warz[ Go to top ]

    Gavin, I agree with you in part. JBoss microkernel does already provide most of the features of Pico and Spring(without the MVC). The lifecycle, dependency management, and IoC. What we need to do is package it, productize it and drive it as a separate framework and test it as a container within another container and rework any issues that are there.

    >
    > Well, you'd have to add interception

    Got interception in 3.2.

    > and a few other things,

    Like? I'll give you one. We can only inject proxies, need to be able to inject direct references. We'll be able to do this and keep interception as we have our AOP framework. I'm excited about what we're doing.

    >but great. I wish you would have done it years ago.

    Years ago not possible. Last year, shoulda...

    >The more choice the better. In late 2000 or so when Rickard first created the
    JMX based container I killed some significant time duplicating this

    Marc is always thankful to Rickard.

    Bill
  74. Flame Warz[ Go to top ]

    C'mon guys, lets calm down a bit, I hate to see my friends fighting with each other!

    >

    Gavin, thanks for bringing some calm to the discussion. The mudslinging aside, it's been an entertaining and enlightening thread. Regarding the HibernateDeployer and the new "CMP on Hibernate" implementation -- how will they work for testing outside the J2EE container? Beeing able to run unit tests on their own is one of the great advantages of using POJOs with Spring or Pico and Hibernate. If you could combine this easy out-of-container testing with JBoss Hibernate/CMP, then you might see some developers take a look at CMP again.

    Thomas
  75. CMP on Hibernate[ Go to top ]

    P.S. In response to the completely off-topic criticisms of the JBoss CMP engine, I would like to note that the people who had previously been responsible for the implementation of JBoss CMP have now left the company and formed CDN. Currently the CMP engine is maintained by Alex Loubayansky who has apparently been doing a great job with it. Alex and myself are working on a "CMP on Hibernate" implementation. A prototype exists already, and most of the changes that were required on our (Hibernate) side of the fence already exist in the Hibernate 2.2 branch. I can assure the community that this will be the most sophisticated CMP engine available.



    Gavin,
    that is very interesting to me as a heavy user of CMP, are there any other details you can divulge?

    Will it be in the 3.2.x branch or will it only be a feature of 4.x?
    Will we have access to the full feature set of Hibernate, without code modification?
    Do you think CMP on top of Hibernate is a good solution performance wise, I assume it has a penalty but is it/will it be serious?
    How soon (no commitment, unofficially I won't tell anyone... promiss) will it be out?
  76. CMP on Hibernate[ Go to top ]

    Will we have access to the full feature set of Hibernate, without code modification?


    That was a good one! (Please compare CMP 2.1 and Hibernate in terms of object model requirements, query API, etc, and you'll see what I mean.)

    Juergem
  77. CMP on Hibernate[ Go to top ]

    Will we have access to the full feature set of Hibernate, without code modification?

    >
    > That was a good one! (Please compare CMP 2.1 and Hibernate in terms of object model requirements, query API, etc, and you'll see what I mean.)
    >

    Juergem,
    I meant without modifying the EJB code!
    You could do most of this stuff using additional XML and additional classes in deployment and not touch the actual binary EJB. I am obviously not talking about lightweight features that are of no use to CMP developers.
  78. One point[ Go to top ]

    .NET style attributes, providing out-of-the-box, possibility of defining you're own source-level metadata format.

    > >
    >
    > Same here as far as .Net style attributes (a la XDoclet). Didn't know about this. it is not on your website at first glance. I guess we're both guilty of not marketing our stuff well.
    >

    No, not a la XDoclet (unless you meant XDoclet-like syntax). Programmatic attributes accessible at runtime. Currently there is an implementation based on Commons Attributes, but the facade will allow for hierarchical access to any attributes implementation, including the JSR175 one.
  79. This is not fantastic stuff[ Go to top ]

    Bill, I think you must be living in some sort of fantasy land where saying (or writing) that your product has a feature actually equates to that feature existing in a usable fashion.

    Let me state up front that I think that parts of JBoss are rock solid. (I even use it on some projects on a day to day basis, mostly due to some third party EJB dependencies). Other parts are mediocre and buggy.

    Let's talk about JBoss 3.0, released around Spring of 2002, which finally became usable some time that fall, when _some_ of the serious classloading issues plaguing more serious deployements where resolved. How about a JMS implementation that can't handle more than lightweight scenarios. How about a CMP 2.0 engine that after a couple of years is finally becoming usable? (anybody interested in the state of classloading and CMP in JBoss should take a look at their issue database). As for JBoss 4.0, sorry, until it's out in a solid, usable state, it's vaporware...

    > ClassLoading. JBoss container has the abilityto flatten out classloader hierarchies so that all code gets to access any class in any jar/component. If you need more fine-grained control, you can define classloader sandboxes that can span one or multiple component packages, if, for example you have different versions of the same class you need to access within different components.

    Please! I wish you could have shared my pain when I had to spend two days over the Christmas period debugging classloading hell in JBoss. A previously working J2EE app, with MVCSoft CMP 2.0 persistence, decided to start breaking when I innocently added some unrelated code. I hit some sort of magic threshold. All of a sudden, traversing EJB relations resulted in a ClassCastException as another copy of the class from another clasloader was encountered. Same deal with jobs fired from Quartz and OsWorkflow. Re-arranging jars (both configurations fully legal according to the spec), produced a situation where on every startup JBoss would complain about a random 3-4 of my EJBs (who's code was unchanged), as being illegal.

    The farther you stay away from the JBoss classloader in the presence of EJBs, the better...

    > Next, full support for hot-deployment and class cycling.

    Find me somebody able to use JBoss hot-deployment in production. JBoss hot-deploy chews up memory like there's no tomorrow. It is usable in development, but you will run out of memory periodically and have to restart from scratch.

    I could go on...

    > And I can't resist either.... I still find it funny you all come to us for persistence (Hibernate) and eventually will come to us for clustering (JGroups).

    This statement is laughable. Hibernate is a great product, but don't tell me the JBoss group or the way the JBoss group develops its software had almost anything to do with the 2.1 version of the product. It's been just a few months since you started sponsoring Gavin.

    And yes, the whole Spring approach is to use the best tool for the job, and make the Spring code itself rock solid and usable. Features (not that they aren't there in the total solution, aka Spring+other products) can wait...

    Regards,
    Colin
  80. This is not fantastic stuff[ Go to top ]

    Colin Sampaleanu wrote:
    > Bill, I think you must be living in some sort of fantasy land where saying (or writing) that your product has a feature actually equates to that feature existing in a usable fashion.
    >

    The features I compared with Spring have been in use for years by our own J2EE implementation. A large online gaming company (Marc can I use their name?) actually our microkernel alone to run a 10,000 user base online community.

    > Let me state up front that I think that parts of JBoss are rock solid. (I even use it on some projects on a day to day basis, mostly due to some third party EJB dependencies). Other parts are mediocre and buggy.
    >

    Let's keep the focus on this mini thread on why Spring is (not) so great or revolutionary rather than bringing in what is buggy about JBoss. We're a complicated set of complicated technology that solves complicated problems. We're an easy target. So is Weblogic, so is Websphere. Spring is not such an easy target, well..., because it is solving simple problems. If Spring aims to be a container(and don't tell me that it is not), well, then they are going to have to be compared to existing, more robust, more complete, more mature containers.

    > > And I can't resist either.... I still find it funny you all come to us for persistence (Hibernate) and eventually will come to us for clustering (JGroups).
    >
    > This statement is laughable. Hibernate is a great product, but don't tell me the JBoss group or the way the JBoss group develops its software had almost anything to do with the 2.1 version of the product. It's been just a few months since you started sponsoring Gavin.
    >

    What you don't understand is that the main Hibernate and JGroup developers ARE JBoss Group. They have bought into the vision of the company and already are seeing the adoption soar at fortune 100 companies because of the alliance with JBoss Group. Marc and I have stated over and over that the strength of the business and strength of the technology compliment one another quite nicely.

    > And yes, the whole Spring approach is to use the best tool for the job, and make the Spring code itself rock solid and usable. Features (not that they aren't there in the total solution, aka Spring+other products) can wait...
    >

    I've stated before, the Spring approach tries to be a container within a container while JBoss chooses to be THE container. Spring is dependent on another container, while JBoss is not. On the flip side, you can plug-in a variety of third-party open source and commercial solutions for most parts of JBoss if you decide our implementation is not up to par.

    Bill

    P.S. As for the classloading hell. Apologies. I have lived through the opposite end of classloading hell in Weblogic land. Other have lived through the same thing in Websphere land. The differense between us and them is that we aim to please everybody. To have classloader isolation and/or having classloader sharing. Different applications have different classloading requirements.

    P.P.S. What version did hotdeployment chew up memory? It is not supposed to behave in this way and should be stabilizing in the 3.2 series. www.jboss.org is running on Nukes/JBoss 3.2.3 and has survived 6 full hot-redeployments over the past 3 weeks. Let me know...thanks.
  81. This is not fantastic stuff[ Go to top ]

    |
    |are seeing the adoption soar at fortune 100 companies because of the alliance
    |with JBoss Group
    |

    Really?

    Perhaps their adoption is soaring because they were good products/implementations to begin with - before they became JBoss projects...?

    -Nick
  82. This is not fantastic stuff[ Go to top ]

    |

    > |are seeing the adoption soar at fortune 100 companies because of the alliance
    > |with JBoss Group
    > |
    >
    > Really?
    >
    > Perhaps their adoption is soaring because they were good products/implementations to begin with - before they became JBoss projects...?
    >
    > -Nick

    Exactly! Now you get it! They were GREAT products/implementations before they became JBoss projects! The strength of the business, availability of training, consulting, and 24x7 production support has amplified their strengths and is speeding their adoption.

    Bill
  83. This is not fantastic stuff[ Go to top ]

    Exactly! Now you get it!


    Do I ?

    |
    |The strength of the business, availability of training, consulting, and 24x7
    |production support has amplified their strengths and is speeding their
    |adoption.
    |

    Fair enough.

    FWIW, for us (investment bank) the JBoss association makes zero difference...

    -N
  84. This is not fantastic stuff[ Go to top ]

    FWIW, for us (investment bank) the JBoss association makes zero difference...


    it may make zero difference to you as a developper, it makes a lot of difference to decision makers as to adoption and availability of support. IN the past 2 weeks Gavin has been on 2 MAJOR jobs. Not at your "bank" since you seem to be a cheap ass.

    Also you may be a cheap ass but we are not and Gavin gets paid to work full time on hibernate to give you a better product. so, there it is.

    marcf
  85. This is not fantastic stuff[ Go to top ]

    |
    |it may make zero difference to you as a developper, it makes a lot of
    |difference to decision makers
    |

    Who are these mythical "decision makers"?
    Perhaps we are in the luxuriously sensible position where the "decision makers" have a clue ... er US?

    |
    |Not at your "bank" since you seem to be a cheap ass.
    |

    As cheap as they come :-)

    -N
  86. This is not fantastic stuff[ Go to top ]

    Let's keep the focus on this mini thread on why Spring is (not) so great or revolutionary rather than bringing in what is buggy about JBoss. We're a complicated set of complicated technology that solves complicated problems. We're an easy target. So is Weblogic, so is Websphere. Spring is not such an easy target, well..., because it is solving simple problems. If Spring aims to be a container(and don't tell me that it is not), well, then they are going to have to be compared to existing, more robust, more complete, more mature containers.


    You're actually making my point and are paraphrasing what I said before. JBoss tries to solve a lot of problems, some of them complicated, some of them less complicated. This makes it harder for an entity with limited resources to focus and produce the same level of product (never mind the fact that we are also comparing apples to oranges when we compare CMP to something like Hibernate, which adds a whole other dimension to the arguments). Spring tries to solve less problems (I would disagree about how simple a few of them are, but anyways), so has an easier time producing consistently high quality code.

    But so what? And this gets into your container aspect. Spring wants to be a container in a container sometimes. Sometimes it is the only container. The Spring message is that for many situations, JBoss+Spring, or TomCat+Spring, or Spring by itself, is better than JBoss alone, or TomCat alone, or some totally hand-rolled solution.

    I will stand by my assertion that right now, JBoss+(Spring for tx and persistence with Hibernate), or even TomCat/Jetty+(Spring for tx and persistence with Hibernate) if no session beans are needed, would be a better solution for many people than JBoss+CMP alone, or even JBoss+Hibernate alone. This comes down to the amount of code you have to write, how easy it is to write that code due to support libs and the like, how easy it is to write IOC style code, how quick and easy the build/test/deploy cycle can be made, and the stability of the environment.

    Is this going to be the case forever. Who the hell knows? I am a pragmatist. If in a year's time JBoss has so many compelling features that the equation says 'drop Spring' and use JBoss alone, then so be it. In the meantime, my job is a lot easier. (and before somebody mentions legacy code, I think this is a non-issue. The whole point of IOC is not to have many dependencies on your container. Almost none of my code knows about Spring. Anything that makes JBoss+CMP that compelling is going to require even more pain to move to). FWIW the trend seems to be the other way; as Spring matures I seems to have less and less need for JBoss, but we'll see. In any case, everybody has different needs.

    > > This statement is laughable. Hibernate is a great product, but don't tell me the JBoss group or the way the JBoss group develops its software had almost anything to do with the 2.1 version of the product. It's been just a few months since you started sponsoring Gavin.
    > >
    >
    > What you don't understand is that the main Hibernate and JGroup developers ARE JBoss Group. They have bought into the vision of the company and already are seeing the adoption soar at fortune 100 companies because of the alliance with JBoss Group. Marc and I have stated over and over that the strength of the business and strength of the technology compliment one another quite nicely.

    Great. I really (and I mean this) hope Hibernate prospers off the JBoss relationship in the future. It's good for everybody. Just don't tell me that JBoss had an incredible amount to do with 2.1...

    > P.S. As for the classloading hell. Apologies. I have lived through the opposite end of classloading hell in Weblogic land. Other have lived through the same thing in Websphere land. The differense between us and them is that we aim to please everybody. To have classloader isolation and/or having classloader sharing. Different applications have different classloading requirements.

    Believe me. I've been through WebLogic bug hell in years past; aka waiting months and months for a service pack which might or might not fix an issue that you're having; completely at their whim.

    > P.P.S. What version did hotdeployment chew up memory? It is not supposed to behave in this way and should be stabilizing in the 3.2 series. www.jboss.org is running on Nukes/JBoss 3.2.3 and has survived 6 full hot-redeployments over the past 3 weeks. Let me know...thanks.

    We are running JBoss 3.2.2RC3. (Unfortunately 3.2.3 causes something to blow up in a (working fine in 3.2.2RC3) older OsWorkflow version that has a few customizations but unfortunately has had its source lost. I haven't had time to decompile it and try to trace through the issue in a debugger). So with 3.2.2RC3, an EAR file consisting of about 20MB of code (3 WARs, about 7-8 Session EJBs, no more Entity EJBs, and a bunch of other code, seems to cause JBoss to run out of memory (given 256MB) pretty regularly, when redeploying. I've never actually counted it, but perhaps it's on the order of 20-30 redeploys. Some time this week I will have finished upgrading the problem OSWorkflow to the current version, and will be able to properly debug that in JBoss 3.2.3 and see if it works properly, and also if the hot deploy is better. As I said, it's quite usable and useful for development, even now, in any case.

    Regards,
    Colin
  87. This is not fantastic stuff[ Go to top ]

    Wow, you're feeling a bit agressive today Bill. However, it's reassuring to see that one of you is behaving in good old JBoss style. I'm going to skip the offensive stuff. But rest assured we're not going to "piss off". Remember also that Marc fired the first shot in this thread.

    I've stated before, the Spring approach tries to be a container within a container while JBoss chooses to be THE container. Spring is dependent on another container, while JBoss is not.
    Typically true in a J2EE environment, although you can use Spring as a entire container outside if you want. (I've even heard of people using it in applets.) The point, however, is that this is an advantage.

    Why should Spring reinvent the app server? App servers are a commodity. Projects are often committed to their app servers. Different app servers have different strengths. For example, if I had an absolute requirement for maximum performance, I know which server I would use and it sure isn't JBoss. Switching large projects from one server to another is a big deal. So having the IoC+AOP functionality available in any app server (even a servlet engine) is extremely valuable.

    Maybe you could do that by productizing your micokernel. Why don't you try? You don't have a solution in that space now, so you not in a strong place to attack products that do.

    So the comparison is not between JBoss 3 and Spring, as you're trying to make out. It's between Spring and the "declarative services for POJOs" part of JBoss 4 that hasn't yet appeared in a usable form, despite your publicity about it for months. We have "enterprise aspects" too: such as declarative transaction management with a lot of cool features. The difference is that they're portable. And no, you didn't invent AOP or the application of AOP to J2EE.

    Regards,
    Rod
  88. This is not fantastic stuff[ Go to top ]

    Typically true in a J2EE environment, although you can use Spring as a entire container outside if you want. (I've even heard of people using it in applets.) The point, however, is that this is an advantage.


    We also have a noteworthy number of people that use Spring as their middle tier backbone for Swing desktop applications. This is an area that J2EE in general totally neglects: There is a significant number of scenarios where you'd like to have basic middle tier services (like high-level transaction management and O/R mapping) in a standalone app, completely outside an app server. Spring (in combination with Hibernate or JDO) serves this purpose well.

    A cornerstone of Spring's philosophy is to allow for reusable business logic that can run in any Java environment. Such logic does not depend on specific services but is still able to leverage them when they're available. The same piece of business logic can be used in a standalone app with a local JDBC DataSource and Spring's JDBC transaction strategy; when running in a J2EE container, it can leverage a container DataSource and JTA. So besides wiring them and configuring them, Spring essentially decouples POJO business objects from specific environments.

    > Why should Spring reinvent the app server? App servers are a commodity. Projects are often committed to their app servers. Different app servers have different strengths.

    Spring generally doesn't aim to reinvent the wheel: We do offer our own JDBC abstraction layer, but we also ship with pre-built Hibernate, JDO, and iBATIS SQL Maps integration. Note that Spring can be used as middle tier framework with any web framework (despite the fact that we provide our own web MVC framework as an option): Numerous users choose to combine Spring with Struts, WebWork, WebWork2, or Tapestry. And, as earlier noted, a Spring-powered app can run on *any* J2EE server; the actual choice depends on your application's needs (not Spring's needs).

    In many respects, Spring is complementary to both a J2EE container and a web MVC framework: It addresses common needs inbetween, bridging gaps and replacing ad-hoc solutions that are found in many of today's J2EE apps. Of course, Spring offers alternatives to *some* J2EE container services (like declarative transactions and a lightweight transaction strategy for a single database), just like it offers an alternative web MVC framework: The choice is up to the application developer; Spring does not restrict you here in any way.

    Juergen
  89. Container vs. Lightweight Container[ Go to top ]

    It's very interesting to watch the discussion about JBoss and Spring (also the comparison) although this forum should be about EJB ;-)

    IMO, the term of "container" and "lightweight container" is the problem here. We all surely agree that JBoss, JOnAS are J2EE container. Tomcat, Jetty are Web container. But how do you define Spring, Pico, Avalon? Many of you define them as "lightweight container". This sounds for me like "a better" "a faster" "an easy to learn" "container" and this is surely *not* the case.

    It is also not applicable to compare JBoss and Spring as they are playing on different level. But as we can use lightweight containers everywhere (at server-side, client-side), we can also use the real containers everywhere (server-side, client-side) as I always try to say in the whole discussions about containers vs. lightweight containers. Thanks to Bill Burke, who explained, how you can also use JBoss everywhere with its microkernel architecture. So, for me it is clear that real "containers" is the way to go:
    - Standardized (JMX, J2EE) and thanks to Richard Monson-Haefel who has done and
      *will* do a great work in EJB ;-) and all the inputs from community to make EJB
      better. I agree with Marc Fluery that the power of Open Source lies on the
      standardization.
    - Can be used everywhere (client and server-side) thanks to:
      JBoss: microkernel.
      JOnAS: service oriented.
    - No need to make the complexity of your application higher by adding container
      within container, which is not standardized. We should go for a
      higher abstraction level not complexity level ;-) -> MDA.

    J2EE containers everywhere!

    BTW. there is a project, which allows you to run EJB out of containers: http://mockejb.sourceforge.net/

    Cheers,
    Lofi.
  90. This is not fantastic stuff[ Go to top ]

    We have "enterprise aspects" too: such as declarative transaction management with a lot of cool features. The difference is that they're portable.


    I just want to add my 2c. Those AOP aspects are extremly easy to use and have been incorporated and deployed on many mission critical production applications. That's the fact.

    Regards,
    Dmitriy.
  91. class loading[ Go to top ]

    ClassLoading. JBoss container has the abilityto flatten out classloader hierarchies so that all code gets to access any class in any jar/component. If you need more fine-grained control, you can define classloader sandboxes that can span one or multiple component packages, if, for example you have different versions of the same class you need to access within different components.

    >

    on classloaders.

    Class loaders in JBoss actually solve the problems listed at the beginning of this thread. Namely that we don't have to do a package hell to get class visibility. Anybody here tired of packaging interfaces across deployment units? and the EARs needing their own copy of the parsers and then the fact that the web layers don't share class loaders with the EJB layers so you can't collocate etc?

    Flat visibility of the classes is the way to get cyclability of the classes while retaining class visibility.

    If a third party package doesn't delegate to its context class loader (hence not seeing the classes from JBoss) then it is a bug. I am serious on this. All "3rdparty" should do class visibility by

    myClassloader = new myClassloader(Thread.currentThread().getContextClassLoader()));

    otherwise it is a bug on the original codebase.

    marcf
  92. JBoss is not the only option[ Go to top ]

    Some of the items you are talking about JBoss supporting are not exactly, cutting edge--like for example, MBean metadata. Sun's base JMX RI, jakarta-commons modeler, and MX4J provide similiar capabilities, which I and at least several others are using with Spring to JMX-enable our POJOs for management by any JMX client. And JMX clients aren't exactly cutting edge either--heck, even Sun ships one for free (albeit a ugly one), and there is the eye-candy Extreme J.

    I evaluated the JBoss microkernel for use as a IoC container for my applications and server-side agents, but became convinced that making JMX the core of my architecture would be a mistake, not to mention overkill. To me, a JMX-based microkernel is like trying to put a square peg in a round hole. The Spring approach, IMHO, is much cleaner because you're working with richly typed POJOs, rather than cumbersome ObjectNames. Spring, to me, really facilitates and promotes solid OO practices and designs, something that I believe is often forgotten in this techno-happy land of buzzwords and acronyms. Spring simplifies my life so I get results for my customers faster. If I need the capabilities of JMX to enable management of my components in a standard way (which I do), big deal, I've can have it (a la Sun JMX RI 1.2 + modeler), and that management capability is treated as distinct (and optional) separation of concern. I'm curious: exactly how can you wire up dependencies between components in JBOSS without spreading JMX ObjectNames and other technology-specific APIs around your codebase? With Spring I can *honestly* code my applications and servers in elegant IoC fashion--with centralized, externalized configuration--to POJO interfaces with no dependency on the container. Zero.

    In addition, JBOSS was not a fit for us as a base JMX implementation because it lacked JMX 1.2 support and (*I believe*) is still lacking JSR 160 support. For that reason our team went with Sun's RI 1.2--Eamonn McManus and his team at SUN simply produced a tangible 1.2/JSR 160 implementation much faster--it's been available last July actually. Where is JSR160 support today in JBOSS or am I missing something?

    Keith
    http://www.jroller.com/page/kdonald
  93. JBoss is not the only option[ Go to top ]

    I evaluated the JBoss microkernel for use as a IoC container for my


    here we go again with the gay IoC stuff. Can you guys get over JNDI? oy!

    it has got to be the BIGGEST EYE CANDY that go the girls excited. Its eye candy.

    onto the real point.

    >
    applications and server-side agents,
    >

    Server side agents? sounds cutsy again.

    >
     To me, a JMX-based microkernel is like trying to put a square peg in a round hole.
    >

    For exactly what? JMX is there to provide

    1- A REAL MICROKERNEL (with cyclability, lifecycle for it (in JBoss), loading, decoupling, yada yada)
    2- A STANDARD FOR MANAGEMENT. These are key, we talk to telco guys, JBoss runs MCI's provisioning system, this is not some IT website fluff on the side, this is hardcore telephone system. JBoss powers AMD's next generation "lights out fab" meaning automated robots. Do you think these guys will go with vanilla flavor of the month stuff? get real... they need JMX. And by the way JMX was invented by telcos. bottom line? JMX is a GREAT way to provide controllable system.

    >
    (*I believe*) is still lacking JSR 160 support.>

    Tom Elrod (JSR 160) is a JBoss employee. He has done the JMX remoting framework.

    marcf
  94. JBoss is not the only option[ Go to top ]

    I evaluated the JBoss microkernel for use as a IoC container for my

    >
    > here we go again with the gay IoC stuff. Can you guys get over JNDI? oy!
    >
    > it has got to be the BIGGEST EYE CANDY that go the girls excited. Its eye candy.
    >
    > onto the real point.
    >
    > >
    > applications and server-side agents,
    > >
    >
    > Server side agents? sounds cutsy again.
    >
    > >
    > To me, a JMX-based microkernel is like trying to put a square peg in a round hole.
    > >
    >
    > For exactly what? JMX is there to provide
    >
    > 1- A REAL MICROKERNEL (with cyclability, lifecycle for it (in JBoss), loading, decoupling, yada yada)
    > 2- A STANDARD FOR MANAGEMENT. These are key, we talk to telco guys, JBoss runs MCI's provisioning system, this is not some IT website fluff on the side, this is hardcore telephone system. JBoss powers AMD's next generation "lights out fab" meaning automated robots. Do you think these guys will go with vanilla flavor of the month stuff? get real... they need JMX. And by the way JMX was invented by telcos. bottom line? JMX is a GREAT way to provide controllable system.
    >

    Marc we dropped the ball on this stuff by not packaging, marketing, and documenting it a long time ago. Many in our user base gets it and uses it, we need to expose the rest to what's going on.

    Bill
  95. JBoss is not the only option[ Go to top ]

    Marc we dropped the ball on this stuff by not packaging, marketing, and documenting it a long time ago. Many in our user base gets it and uses it, we need to expose the rest to what's going on.

    >
    > Bill

    yeah you are right, our bad on that one. The technology has been there for ages and we must package and market it clearly.

    marcf
  96. JBoss is not the only option[ Go to top ]

    yeah you are right, our bad on that one. The technology has been there for ages and we must package and market it clearly.


    No, please, no more overblown marketing statements!
  97. JBoss is the oldest option[ Go to top ]

    No, please, no more overblown marketing statements!


    There is nothing overblown here. We are talking about pojo middleware and the microkernel at heart. JBoss since 3x. is widely used in that capacity already, microkernel based designs where we support hot deploy of new services to a kernel. Done in production.

    The marketing works the other way. To some degree it seems we are all talking about the same thing. or how to apply services to objects. EJB is today the standard way of doing it. I would like to see the EJB spec moving towards POJO stuff. If we can get there it would be great.

    The discussion started with a revamp of EJB. I believe in standards and good implementation. JBoss has had this vision for quite a while with code tested in production.

    Bottom line. If it goes that way for us to support the spec would mean repackaging (you won't have the old EJB container you would have the new generalized containers). Easy for us to do it, we are already there.

    There are 2 statements I really made in this thread
    1- Before the JBoss barking-dogs came along we were discussing standards evolution and it was good stuff
    2- the POJO approach to middleware is easy for JBoss to implement as it is repackaging.

    onward,

    marcf
  98. JBoss is not the only option[ Go to top ]

    yada yada)
    > 2- A STANDARD FOR MANAGEMENT. These are key, we talk to telco guys, JBoss runs MCI's provisioning system, this is not some IT website fluff on the side, this is hardcore telephone system. JBoss powers AMD's next generation "lights out fab" meaning automated robots. Do you think these guys will go with vanilla flavor of the month stuff?

    Probably yes. Y'a plein d'imbecilles dans tous les coins d'monde. The fact that you are cheap is probably the biggest factor in choosing your product.

    And with this kind of attitude you still make money?
  99. JBoss is not the only option[ Go to top ]

    Some of the items you are talking about JBoss supporting are not exactly, cutting edge--like for example, MBean metadata. Sun's base JMX RI, jakarta-commons modeler, and MX4J provide similiar capabilities, which I and at least several others are using with Spring to JMX-enable our POJOs for management by any JMX client. And JMX clients aren't exactly cutting edge either--heck, even Sun ships one for free (albeit a ugly one), and there is the eye-candy Extreme J.

    >
    > I evaluated the JBoss microkernel for use as a IoC container for my applications and server-side agents, but became convinced that making JMX the core of my architecture would be a mistake, not to mention overkill. To me, a JMX-based microkernel is like trying to put a square peg in a round hole. The Spring approach, IMHO, is much cleaner because you're working with richly typed POJOs, rather than cumbersome ObjectNames. I'm curious: exactly how can you wire up dependencies between components in JBOSS without spreading JMX ObjectNames and other technology-specific APIs around your codebase?

    How? ModelMBeans/JBoss XMBeans are POJOs. You can pass in references in the following way:

    <mbean name="*:name=SomeService" class="org.jboss.SomePOJO" xmbean-dd="dd.xml">
    <depends optional-attribute-name="TransactionManager"
    proxy-type="attribute">
    jboss:service=TransactionManager"
    </depends>
    </mbean>

    public class SomePOJO
    {
       TransactionManager tm;
       public TransactionManager getTransactionMananger() { return tm; }
       public void setTransactionManager(TransactionManager tm) { this.tm = tm; }
    }

    SomePOJO doesn't even need to implement an interface.

    What we need to add is default xmbean-dd generation at runtime and the ability to pass in direct references rather than just proxies.

    Sure, you have to deal with ObjectNames within the XML, but it is worth it for some of the querying advantages that the MBeanServer can give you. Not to mention lightweight Notifications.

    > With Spring I can *honestly* code my applications and servers in elegant IoC > fashion--with centralized, externalized configuration--to POJO interfaces with no dependency on the container. Zero.

    You have a dependency on a container. Spring is a container. With a JBoss microkernel you get centralized, externalized configuration to POJO interfaces as well. The difference being from spring is that spring is usually (always?) a container within a container, and JBoss is just a container period.

    >
    > In addition, JBOSS was not a fit for us as a base JMX implementation because it lacked JMX 1.2 support and (*I believe*) is still lacking JSR 160 support.

    I think it is there in HEAD. I'll doublecheck. Tom Elrod committed a bunch of 1.2 stuff a couple months back. Again, another JB4 DR in march. What exactly is so critical for you in JSR 160? Connectors?

    Bill
  100. JBoss is not the only option[ Go to top ]

    I know this is a bit off-topic, but bear with me... I try to make relavent contributions to this thread (albeit a bit indirectly.)

    Bill Burke said:
    >ModelMBeans/JBoss XMBeans are POJOs. You can pass in references in the >following way:

    Well kind of, but they're all also MBeans right? And you just mentioned you're passing in a proxy, not a direct reference? Is this a proxy to a MBean instance which lets you make calls on the object as if it was a POJO? That's where I'm a skeptic, that's where I smell an anti-pattern. Generally, the interface I want to expose for management and configuration (at least through JMX anyway), is different from the *business* interface used by application components to do the 'real work.' As a simple example, I might have a management interface defined for a cache component that lets me monitor the size of the cache via the JMX protocol (or using a JMX adaptor, SNMP or CIM/WBEM.) A simple JMX monitor might alert me by publishing JMX notifications or sending e-mail when some observed threshold is met. However, what is important is this cache's JMX management interface should NOT expose the *business methods* that access the cache's contents -- that is not management, that is what application objects use in the system to get/put stuff in/out of the cache. Management via JMX is a separation of concern. Spring gives me the flexibility in that I work with POJOs and if I have the requirement to register one or more of them as MBeans I can do that, and I can do that through a separate management interface which *makes sense* for that component.

    So in Spring, yes, you deal with direct POJO interface (or class) references. These are the core interfaces an application or server needs to do its job. As I mentioned, separate interfaces may exist for management purposes, and that's where JMX MBeans fit into the picture. Believe me, I like JMX, I've worked in the network management business for 4 years now--JMX is instrumental to my system and JSR160 is instrumental to my system's centralized management capability.

    One other thing: you mentioned I am dependent on the Spring container. No, I'm not. I am not dependent on any Spring container APIs. If I choose to use a Spring API, it's because it provides real value in terms of directly supporting my application -- for example, like the JDBC or Hibernate or MVC infrastructure classes... And this is a *good* thing as these classes save me time because they address common problems every system must address, many problems related to *desiging systems well*, not just providing the plumbing. For the plumbing type stuff, I don't want that crap in my code, and with Spring it's NEVER in my code. None of my classes are dependent on the Spring bean container APIs (or any other 'plumbing' API like EJB for that matter.) This makes my code extremely portable accross different environments. This is very important for me because -- based on my requirements -- different scales of systems for different customers make sense. For example, for one customer, a fat Swing client with a direct DB connection is GOOD ENOUGH, for another, it's time for a app server. Spring lets me port my business logic accross those environments with ease. That's why I love Spring.

    Bill - I do appreciate the professional response to my post.
  101. JBoss is not the only option[ Go to top ]

    I know this is a bit off-topic, but bear with me... I try to make relavent contributions to this thread (albeit a bit indirectly.)

    >
    > Bill Burke said:
    > >ModelMBeans/JBoss XMBeans are POJOs. You can pass in references in the >following way:
    >
    > Well kind of, but they're all also MBeans right? And you just mentioned you're passing in a proxy, not a direct reference? Is this a proxy to a MBean instance which lets you make calls on the object as if it was a POJO?

    I don't know, you'll have to answer me, but Spring MUST require a proxy to do interception, but does it always require a proxy?

    > That's where I'm a skeptic, that's where I smell an anti-pattern. Generally, the interface I want to expose for management and configuration (at least through JMX anyway), is different from the *business* interface used by application components to do the 'real work.' As a simple example, I might have a management interface defined for a cache component that lets me monitor the size of the cache via the JMX protocol (or using a JMX adaptor, SNMP or CIM/WBEM.) A simple JMX monitor might alert me by publishing JMX notifications or sending e-mail when some observed threshold is met. However, what is important is this cache's JMX management interface should NOT expose the *business methods* that access the cache's contents -- that is not management, that is what application objects use in the system to get/put stuff in/out of the cache. Management via JMX is a separation of concern. Spring gives me the flexibility in that I work with POJOs and if I have the requirement to register one or more of them as MBeans I can do that, and I can do that through a separate management interface which *makes sense* for that component.
    >

    First of all you wince because you think of MBeans as heavyweight. They are as heavy as Spring beans, at least the Spring beans that don't require a proxy. Second, if you want to have a business interface and a separate management interface, then well, create another MBeanServer and register that bean with different metadata. Besides, you're muddying the issue because I'm talking about using our stuff for IoC, not for exposing management interfaces, and this is exactly what we use our microkernel for, to build our J2EE personality. You have a point though in that it would be nice to say what is the management interface and what is the business interface

    Another thing, with our microkernel, you have complete control of the interface passed to the POJO attribute. Either you can have the microkernel create a proxy from the type of the attribute:

       <mbean code="org.jboss.test.jmx.proxy.ProxyTests"
              name="jboss.test:name=ProxyTestsAttribute">
          <depends optional-attribute-name="Proxy"
                   proxy-type="attribute"
          >jboss.test:name=ProxyTarget</depends>
       </mbean>

    Or, you can specify a proxy type and that interface will be used to pass to the MBean's attribute.

       <mbean code="org.jboss.test.jmx.proxy.ProxyTests"
              name="jboss.test:name=ProxyTestsNested">
          <depends optional-attribute-name="Proxy"
                   proxy-type="org.jboss.test.jmx.proxy.TargetMBean">
    jboss.test:name=ProxyTargetNested
          </depends>
       </mbean>

    > So in Spring, yes, you deal with direct POJO interface (or class) references. These are the core interfaces an application or server needs to do its job. As I mentioned, separate interfaces may exist for management purposes, and that's where JMX MBeans fit into the picture. Believe me, I like JMX, I've worked in the network management business for 4 years now--JMX is instrumental to my system and JSR160 is instrumental to my system's centralized management capability.
    >

    Our microkernel expands JMX. It is JMX based. What we've added is dependency, IoC, service lifecycle management, classloading, interception. Well beyond the spec.

    > One other thing: you mentioned I am dependent on the Spring container. No, I'm not. I am not dependent on any Spring container APIs. If I choose to use a Spring API, it's because it provides real value in terms of directly supporting my application --

    Again, same for us. See my Model/XMBean examples before. Again, the difference is that for any enterprise features you require another container, we do not. We have a lot of critical features whenever you need to go beyond the cutsy that Spring is. If you don't, then you are not required to use those features.

    > for example, like the JDBC or Hibernate or MVC infrastructure classes... And this is a *good* thing as these classes save me time because they address common problems every system must address, many problems related to *desiging systems well*, not just providing the plumbing. For the plumbing type stuff, I don't want that crap in my code, and with Spring it's NEVER in my code.

    Yawn, this is the cutsy stuff I talk about. MVC I'd use Struts or WebWorks in a heartbeat over Spring. All those other wrapper classes can be written better in about 30 seconds of coding. Cutsy bullshit that requires you to insert CRAP spring code. I trust myself more than spring to keep up to date with JDBC and Hibernate APIs.

    >None of my classes are dependent on the Spring bean container APIs (or any other 'plumbing' API like EJB for that matter.)

    Except when you use the JDBC/Hibernate/MVC wrapper/infrastructure classes you talk about above ;)


    >This makes my code extremely portable accross different environments. This is very important for me because -- based on my requirements -- different scales of systems for different customers make sense. For example, for one customer, a fat Swing client with a direct DB connection is GOOD ENOUGH, for another, it's time for a app server. Spring lets me port my business logic accross those environments with ease. That's why I love Spring.
    >

    And our microkernel can do the same, except better, and with more optional features that have been in production around the world in thousands of sites for years. It is our fault for not providing the correct literature so that you understand that this is so. I'm glad that at least some of our userbase gets it and uses it.

    > Bill - I do appreciate the professional response to my post.

    Thanks, same to you.

    Bill
  102. JBoss is not the only option[ Go to top ]

    ... but does Spring always require a proxy?


    No. I'm talking direct references, I'm talking about plain-old-java-objects instantiated for me by the Spring BeanFactory. Spring instanties them, configures them, and wires up dependencies between them. Claiming "Spring beans" are just as heavy weight as MBeans is incorrect--to reiterate, a "Spring bean" is simply a regular java object (POJO - no proxy) with at least one public constructor. Heck, I could choose to instantiate them all programatically by hand without using Spring at all--but Spring is there to help alleviate that burden by instantiating, configuring, and wiring up my entire array of application objects for me automatically. It removes a lot of that grunt work, not to mentioning giving me one place for all my configuration needs. (for the record, I've never been able to consistently build such easily configurable applications since Spring came along...my customers love me for it...)

    I currently have my own proprietary code that JMX-enables my POJOs with distinct management interfaces and registers them -- the ones I need to be manageable -- as MBeans in a MBeanServer powered by JMX RI 1.2 (which is pretty dang good for a Sun JMX reference implementations.) I also leverage jakarta-modeler for associating ModelMBean metadata with a particular management type.

    >I trust myself more than spring to keep up to date with JDBC and Hibernate >APIs.

    That's where we simply differ. I look to find solutions I can leverage that save me time and promote well-designed applications. Spring is a big one, as is Hibernate, as is jakarta-commons. At the end of the day, I'm glad my codebase is compact, clean, and manageable. I've come to trust the quality of certain open source projects, and Spring is definitely one of them. But that's where -- I guess -- we differ.

    What seems to me is the difference between you and Spring, when talking about you as a so-called "lightweight container" or microkernel -- is you make JMX the core of your architecture. IMHO, as someone whose used JMX for about 4 years now, that was not what JMX was intended to be used for (as you said, it's not in the spec...:))
  103. JBoss is not the only option[ Go to top ]

    Yawn, this is the cutsy stuff I talk about. MVC I'd use Struts or WebWorks in a heartbeat over Spring. All those other wrapper classes can be written better in about 30 seconds of coding. Cutsy bullshit that requires you to insert CRAP spring code.


    You don't get the point about Spring's core service: configuring and wiring logical middle tiers. People are happily using Struts, WebWork, Tapestry on a logical Spring middle tier. Quite a few of them currently deploy those application on JBoss, actually; some of them might reconsider that choice looking at whose product they are using there.

    Every single word you say indicates "hey, I'm afraid that even more people might adopt Spring, so I better condemn it in the most rude fashion that I'm capable of"... If we wouldn't do something right and wouldn't have a chance for broad adoption, you'd simply ignore us - so thanks for the recognition.

    Juergen
  104. thank you![ Go to top ]

    I liked very much the "pre spring" framework in Rod Johnson’s book but haven't been able to check up thoroughly the (almost) finished Spring 1.0, being tied up with all that .NET work you know. But thanks to this discussion and to the vehemence of Bill I am now convinced that Spring is much much more - maybe it can even replace the whole J2EE server?

    Regards
    Rolf Tollerud
  105. thank you![ Go to top ]


    - maybe it can even replace the whole J2EE server?
    >

    we are back to square one. I am really tired of the TSS discussions (who can call them discussions really).

    If you go back to the beginning of the thread you will see that what pisses me off is us sitting here talking about "replacing J2EE", with 2 guys and their dog. So we looped the loop.

    Building an open source infrastructure that is unified under standards is the way to go. Rather than this we have outlandish claims to replacing a 3B industry overnight. And I am the one who gets accused for making marketing statements.

    JBoss is used in production today from MCI to AMD to EAGames, for many of the features we are talking about. Easy to use, easy to install, microkernel pojo approach, services and FULL J2EE.

    JBoss as a Job move is real today, you can find 200 jobs on JBoss on your average job search sites. The market is exploding. JBoss is used at 27% in 20043 (BEA at 34%, SDTimes). JBoss was the 2nd fastest growing certification before Microsoft DB certification (CRN mag) ***at large SI***. SIs ARE LOOKING FOR JBOSS TALENT RIGHT NOW. Meaning JBOSS IS A CAREER MOVE.

    So other framework get real and grow out of "green/cute stage" one day? either we make sure there is no competitive advantage by copying what actually works or we ask you guys to join JBoss 'professional open source" and make a living at it. But first, and I don't mean this in an elitist way, there needs to be a real market, then there is a real business, hence real open source. Hibernate, Tomcat, JGroups were all real businesses before they joined JBoss.com.
     
    Or you can sit here and argue with us :)

    Thanks for your time, I want to see EJB3.0 really easy to use.

    marcf
  106. thank you![ Go to top ]

    If you go back to the beginning of the thread you will see that what pisses me off is us sitting here talking about "replacing J2EE", with 2 guys and their dog. So we looped the loop.


    But I for one do not agree that standards are essential when it comes to open-source products. The point of a standard is either to a) ensure interoperability or b) ensure replace-ability. Now, the first point is usually a matter of protocols. For example, that's why J2EE includes support for RMI over IIOP. However, replaceability is really a technique for managing risk. If my vendor folds, I want to be able to port my code at zero or little cost to another vendor. However, this is also achieved automatically by open source projects which have the required transparency and market share (which are linked, btw.)

    Apache and Linux are good examples of this. If you are worried about your vendor leaving you out in the cold, they are a great choice. The community support out there is great.

    So, as far as JBoss is concerned, the features which are really needed are the interoperability features, e.g. RMI/IIOP, JDBC and JTA, web services, etc. not support for specs like entity beans. In fact, it's pretty obvious that these committee-generated specs are just holding you back. That's why the two-guys-and-a-dog projects keep popping up all around you. Examples

    Eclipse (which doesn't use Swing)
    Struts
    Hibernate (which has always locked horns with JDO)
    JavaGroups (instead of JMS - I know, long discussion)
    JBoss AOP
    Spring
  107. thank you![ Go to top ]

    Guglielmo: JavaGroups (instead of JMS - I know, long discussion)

    JavaGroups has protocol. JMS is only an API. So they are hardly competitive -- you could implement the JMS API on top of JavaGroups for example.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  108. thank you![ Go to top ]

    Guglielmo: JavaGroups (instead of JMS - I know, long discussion)

    >
    > JavaGroups has protocol. JMS is only an API. So they are hardly competitive -- you could implement the JMS API on top of JavaGroups for example.

    Like I said, long discussion!

    Bela would say that you can JMS as a transport, which is fine. But group communication also fills a need which is generally not met, so in certain ways they compete.
  109. thank you![ Go to top ]


     But I for one do not agree that standards are essential when it comes to open-source products. The point of a standard is either to a) ensure interoperability or b) ensure replace-ability. Now, the first point is usually a matter of protocols. For example, that's why J2EE includes support for RMI over IIOP. However, replaceability is really a technique for managing risk. If my vendor folds, I want to be able to port my code at zero or little cost to another vendor. However, this is also achieved automatically by open source projects which have the required transparency and market share (which are linked, btw.)
    >

    for me the power is not the RMI/IIOP (serious WHO uses it, can one person here say "I use it" without lying) but purely the risk minimization. I am less optimistic than you when it comes to open source risk minimization, and I should know, i try selling it every day). I will write a blog entry... Basically it is an issue of trust. When I talk about 2 dogs I talk about perception of "small". For all the "reasoning" you expose, they are good arguments but not real in "reality".

    In reality, for all its successes, (JBoss 27% market share when BEA is at 34%, #1 in dev, #1 in ISV, #2 SI growth bla bla bla) selling JBoss and open source in general is difficult when you reach a certain level of company. Tis about piece of mind associated with companies rather than open source. We are not yet at a point where "no one gets fired for choosing open source".

    JBoss is still a small company even though the project adoption is big, and for all the touting that we do in sales, in the minds of some people the company is important, part of the message of "professional open source". We are trying to systematically remove objections people have to open source.

    Indemnification, 24x7 support, STANDARD COMPLIANCE AND TCK BUYING (and our interest in EJB), partner programs JASP. All thes are there to make sure the sale of JBoss is equal to a proprietary framework.

    > Apache and Linux are good examples of this. If you are worried about your vendor leaving you out in the cold, they are a great choice. The community support out there is great.
    >

    And yet it took RedHat and SUSE to make it "real" and more importantly the backing of IBM with $2B in marketing to make open source palatable, it is still underway in Linux btw Linux is still fighting that "adoption battle". Apache isn't an example to emulate from a professional standpoint, imho. There is no professional model. Maybe because httpd isn't that complex to maintain and service?
     
    >
     not support for specs like entity beans. In fact, it's pretty obvious that these committee-generated specs are just holding you back.
    >
     
    Dude, we have been pushing JBoss4.0 AOP and associated aspects for the past year or so. You know we have worked beyond entities. However entities are very useful (cache + persistence) I would rather that be the EJB standard than not. If you follow my drift.

    > Eclipse (which doesn't use Swing)
    > Struts
    > Hibernate (which has always locked horns with JDO)
    > JavaGroups (instead of JMS - I know, long discussion)
    > JBoss AOP
    > Spring

    You are funny, well we recruited 3 of these projects for the professional open source ride. One thing that you must understand is that JBoss.com is a business proposition for these projects. We see potential in these projects and want to help build a real business around them. I won't ra ra ra too much but since gavin has been here in ATL, we sent him to 2 big gigs, both under NDA but it is becoming real.

    The vision is to be that professional open source company in 3 years. If you guys come up with something significant you will want to talk to us to become pro and take the business to the next level. It is just business from that angle.

    JBoss.com regroups, JBoss.org, Hibernate, Tomcat, JavaGroups under a professional umbrella, we all see eye to eye on the business side of things. JBoss has the sales to help with the company angle on these projects. TOGETHER we are a real company.

    So there it is. I think just like EJB, JBoss wants to be here for many years, with a simple vision for professional open source.

    And if you don't get it? you are free to piss off.

    marcf
  110. No, thank you[ Go to top ]

    \marc fleury\
    for me the power is not the RMI/IIOP (serious WHO uses it, can one person here say "I use it" without lying)
    \marc fleury\

    "I use it", and I'm not lying. Sad that an interesting thread got hijacked by JBoss and Spring, again. Well, I might as well throw myself into the melee....

    \marc fleury\
    ... but purely the risk minimization.
    \marc fleury\

    Horse hockey! Maybe you've made another side trip to Amsterdam, Marc, but businesses don't talk about risk minimization. They talk about understanding risk, and balancing risk vs. reward. Risk analysis isn't about minimizing risk, it's about understanding what risks you are taking, and whether they the upside is worth the potential downsides.

    \marc fleury\
    In reality, for all its successes, (JBoss 27% market share when BEA is at 34%, #1 in dev, #1 in ISV, #2 SI growth bla bla bla) selling JBoss and open source in general is difficult when you reach a certain level of company. Tis about piece of mind associated with companies rather than open source. We are not yet at a point where "no one gets fired for choosing open source".
    \marc fleury\

    I'll leave the mind-deadening chanting of the bogus market share numbers to others to debate.

    As for the rest - maybe you're having problems because you obviously don't understand that you're a services company, not a product company. You. Have. No. Product. To. Sell.

    \marc fleury\
    Indemnification, 24x7 support, STANDARD COMPLIANCE AND TCK BUYING (and our interest in EJB), partner programs JASP. All thes are there to make sure the sale of JBoss is equal to a proprietary frameworks.
    \marc fleury\

    <sigh> You're still a services company. And your only diffentiator in the market is that your guys have insight into the internals of JBoss. Go to Websphere, Weblogic, etc and you're just another very small consultancy. At last count you have, what, 14 developers on staff in JBoss Group LLC (at least according to http://www.jboss.org/team)? And of the 13, Bela and Gavin appear to be concentrating primarily on their own pieces, not JBoss. Andy is strictly in self-imposed exile writing a hopeless mail server. Remy's mostly Tomcat.

    So in reality, and at best, you have 9 people working part time on the main JBoss code base. Your sales message keeps hammering on an illusionary JBoss product, for which you make no product revenue. You only make money from training, and support contracts, and (maybe now?) documentation. In fact, _you_ realize where your money comes from because almost none of your developers have commmited anything to CVS in a coon's age. DR3 is supposedly in March 2004, at this rate JBoss 4.0 will go final sometime around my retirement dinner.

    Funny, how you focus on the app server upon which you make no money, and which your developers are letting whither on the vine at the same time.

    \marc fleury\
    Dude, we have been pushing JBoss4.0 AOP and associated aspects for the past year or so. You know we have worked beyond entities. However entities are very useful (cache + persistence) I would rather that be the EJB standard than not. If you follow my drift.
    \marc fleury\

    _All_ you've been doing is "pushing" JBoss 4.0 for the past year. You sure as hell haven't coded any meaningful piece of it. The only saving grace has been Ben Wang banging out updates to JBoss Cache (and perversely giving Bela 95% of the credit for it).

    \marc fleury\
    You are funny, well we recruited 3 of these projects for the professional open source ride. One thing that you must understand is that JBoss.com is a business proposition for these projects. We see potential in these projects and want to help build a real business around them. I won't ra ra ra too much but since gavin has been here in ATL, we sent him to 2 big gigs, both under NDA but it is becoming real.
    \marc fleury\

    Gee marc, I thought JBoss group was about training and support contracts. What you're describing sounds an awful, awful lot like you've got Gavin hired out as a consultant. I thought JBoss would never, ever, ever do the consultant thing?

    \marc fleury\
    And if you don't get it? you are free to piss off.
    \marc fleury\

    Get what? A services bizness made up of 20 people including the admin staff? My, my, you are taking the world by storm!!! A glorified consultancy that pays people to create Yet Another Mail Server?

    Maybe you should take a more objective view of the primary assets involved here that people care about (I think few give a durn about JBoss Group LLC, but may have an interest in JBoss-the-code). Take a look at the dribbles of CVS commits in your own project, and then take a peek over at the torrent of CVS activity in the Geronimo CVS. Look at the byplay of ideas on their developer list vs. the anemic trickle on JBoss'.

    Seriously, I understand why you want to promote your own company, but a tiny little consultancy which is supporting an open source project is not going to impress people very much. I've worked on single enterprise projects that employed more people than your entire company does.

    This is not to say that your company's work is good, bad, or indifferent. It's just that it's a tiny ripple in the market. Maybe you could convince people otherwise with a bigger company, and some impressive _recent_ code tucked away in CVS - but neither exists right now, do they?

        -Mike
  111. Spille, short for idiot[ Go to top ]

    As I read his latest rant, I find it totally commical. Who is this clown? What has he ever accomplished in his career? The thing I would like to know is as follows:
    How do you define these numbers as momentum?

    These represent the number of posts on the Generimo lists

    Month #of posts
    Aug 2003 2748
    Sep 2003 1185
    Oct 2003 650
    Nov 2003 726
    Dec 2003 515
    Jan 2004 404

    How is this exactly momentum? This looks like negative momentum from where I come from. Next, look at the people who are active coders:
    David Jencks - Anyone use the first version of the JBoss JCA implementation?
    Dain Sundstrom - Didn't someone on this list say the JBoss CMP engine was crap? And until recently has gotten better.
    Jeremy Boynes - Can not even name what this guy has ever done in his career
    Greg Wilkins - The guy who just can not give up, and realize that Tomcat is the servlet spec
    I think this is one other dude as well.
     Perhaps Mike Spille is lending his XA insights to their code, but someone I doubt it, as he seems like more of an architect who is allergic to code.

    So Mike, do everyone a favor here, go hang with you cats and leave the rest of us alone. And most importantly, get some work done, do something meaningful, and most importantly get a clue!
  112. Spille, short for idiot[ Go to top ]

    \Arun Patel\
    As I read his latest rant, I find it totally commical. Who is this clown? What has he ever accomplished in his career?
    \Arun Patel\

    My resume's online. Feel free to peruse it at your leisure.

    \Arun Patel\
     The thing I would like to know is as follows:
    How do you define these numbers as momentum?

    These represent the number of posts on the Generimo lists

    Month #of posts
    Aug 2003 2748
    Sep 2003 1185
    Oct 2003 650
    Nov 2003 726
    Dec 2003 515
    Jan 2004 404

    How is this exactly momentum? This looks like negative momentum from where I come from.
    \Arun Patel\

    I agree the numbers look that way at first blush. Until you realize that "Aug 2003" is literally the project start. Projects always have the most messages in the first couple of months as it gets organized. You can disagree, but from reading the list daily it looks to me like they've settled down into a very solid development cycle. And if the e-mails have gone down, the CVS traffic has gone up.

    \Arun Patel\
    Next, look at the people who are active coders:

    David Jencks - Anyone use the first version of the JBoss JCA implementation?

    Dain Sundstrom - Didn't someone on this list say the JBoss CMP engine was crap? And until recently has gotten better.

    Jeremy Boynes - Can not even name what this guy has ever done in his career

    Greg Wilkins - The guy who just can not give up, and realize that Tomcat is the servlet spec I think this is one other dude as well.

     Perhaps Mike Spille is lending his XA insights to their code, but someone I doubt it, as he seems like more of an architect who is allergic to code.
    \Arun Patel\

    I can only judge by code and designs, and what I see in Geronimo looks pretty good to me. As for me, I have probably a couple of hundred thousands of lines of real code at least under my belt from a 14 year career, from C to C++ to perl to Java, thank you very much.

    \Arun Patel\
    So Mike, do everyone a favor here, go hang with you cats and leave the rest of us alone. And most importantly, get some work done, do something meaningful, and most importantly get a clue!
    \Arun Patel\

    Ah, another person with a seeming obsession with my three cats. You must be very close to Andy O., who shares your obsession. Oh, and great TSS posting history too - all pro-JBoss and Sun bashing. You serve as a shining model as to how I should spend my time.

         -Mike
  113. Open Source and Standards[ Go to top ]

    I 100% agree with Marc that Open Source only can be successful with standards. Example:

    - Apache Webserver. This OSS product supports standard protocol: HTTP. Man, don't forget this! Apache Webserver does not build its own protocol!
    - Linux OS. Linux has a lot of components. As a whole operating system maybe it's not a standard (no standard in operating system) but please take a look at its components! FTP, HTTP, SMTP, etc. So, please do not say that Linux does not support standards! Linux is also quite successful because it offers samba: interoperability!

    Open Source and Standards are important. No Open Source products will survive long without standard! Let's take Hibernate. The product is very good and will be used everywhere as long as there is other Open Source products which support JDO. I'll bet if we had an Open Source JDO product, which is good enough, everybody will leave Hibernate. But I cannot imagine that Gavin won't support JDO for Hibernate, as soon as this is possible (becareful ObjectWeb Speedo JDO is on its way ;-)).

    Folks, standards are important to be able to interoperate. This is also why MDA is different than CASE tools in 80. Standards!

    So, in this case I agree with Marc.

    For EJB 3.0: I hope that they put all those additional frameworks like OpenSymphony OSCore in their core distro directly (Adapter classes, HomeFactory, etc.), so we don't need to use outside frameworks.

    In my experience, it's worth it to implement your business components in EJB. It is reusable and works just fine. For example I'm able to deploy the EJBs from LPortal to be used in OpenUSS. LPortal uses JBoss and I'm using JOnAS. Just change the dependent deployment descriptors, redeploy, that's it. The difficult thing is to see what kind of libraries I have to add into OpenUSS, which are used by LPortal (dependencies problems with Hibernate as LPortal uses Hibernate instead of EntityBean). Tips to all EJB developers, especially for Open Source EJB (because OpenUSS is always searching for Open Source EJB components to be integrated ;-)):
    - Please, do not use so many other external libraries. It makes them difficult to reuse.
    - Please, package them in seperate ejb.jar for each component. Do not put them in one big jar file.
    - Please, show the dependency in good manner, so it's easy to see all those dependencies.
    - Please, do "separation of concerns" well. Do not put any security, transaction code in your EJB code. This will make them unusable.
    - Please, design with "reuse in mind"!

    As many people say, that we need AOP in EJB container, this is just IMO non-sense. As an application developer I don't see any difference between all those AOP middlewares and just an EJB container. EJB container is AOP. I really don't care how it is implemented (with compilers, reflections, AOP frameworks, etc), the main thing it has to work. This is also one big question for me, why should one use Spring within EJB container? If you put Spring on your EJB container, it will make the dependency problem bigger. I'm not against Spring, but if you want to make reusable EJBs, please do not put a lot of dependencies with outside libraries. This is horrible and this should be addressed in the coming EJB 3.0.

    Cheers,
    Lofi.
  114. No, thank you[ Go to top ]

    "I use it", and I'm not lying. Sad that an interesting thread got hijacked by JBoss and Spring, again. Well, I might as well throw myself into the melee....

    >

    Mike,

    Good to see you back in the scrum. And injecting some common sense in the thread. I mean, this guy started as the "Highly skilled lowly paid french programmer" and now he spreads around MBA wisdom. Minimizing risks, TCKI, TCO, Fedex(the ad)... Give me a break
  115. thank you![ Go to top ]

    In reality, for all its successes, (JBoss 27% market share when BEA is at 34%, #1 in dev, #1 in ISV, #2 SI growth bla bla bla) selling JBoss and open source in general is difficult when you reach a certain level of company. Tis about piece of mind associated with companies rather than open source. We are not yet at a point where "no one gets fired for choosing open source".


    I didn't mean to suggest that even the most successful open source project can reach 100% market share. You can't brainwash people like that. And there is always Microsoft to take into account.

    Now, if it's true that JBoss runs in 27% of production deployments, then this may well be the best that you can do for now, and it's not bad. But I want to see your source for that number.

    > JBoss is still a small company even though the project adoption is big, and for all the touting that we do in sales, in the minds of some people the company is important, part of the message of "professional open source". We are trying to systematically remove objections people have to open source.

    Good luck.

    > Indemnification, 24x7 support, STANDARD COMPLIANCE AND TCK BUYING (and our interest in EJB), partner programs JASP. All thes are there to make sure the sale of JBoss is equal to a proprietary framework.

    What I was proposing was to aim higher. An open source project is *better* than a closed one, IF it has the right penetration. But frankly, I don't think people have the perception that JBoss is the obvious choice for an app server. With open source, you have to start at the bottom, but I think (I know) that at the bottom a lot of people think EJBs are totally unnecessary. So how are you going to get in at the bottom if people don't want to use EJBs? However, people at the bottom ARE interested in POJOs. So, way to go putting them in.

    > And yet it took RedHat and SUSE to make it "real" and more importantly the backing of IBM with $2B in marketing to make open source palatable, it is still underway in Linux btw Linux is still fighting that "adoption battle".

    Why, you doubt that it would have happened anyway?

    > Apache isn't an example to emulate from a professional standpoint, imho. There is no professional model. Maybe because httpd isn't that complex to maintain and service?

    You are right. There is no professional model because the code and the community support are so good, that Apache is a GIVEN. It's not because it's simple - it's not. It's entirely due to slow market penetration over the years, and a solid implementation.

    > You know we have worked beyond entities.

    That's what I am saying. I do know. But I am also saying that you are not sending a clear message that your new design is *better* than entities. I haven't seen it, but it has to be better than entity beans ;-)

    > However entities are very useful (cache + persistence) I would rather that be the EJB standard than not. If you follow my drift.

    But Hibernate should work just fine. That's why it is successful. It's used by people who think that entity beans are too much work.

    > You are funny, well we recruited 3 of these projects for the professional open source ride.

    Yes. But now you want to change them, don't you?

    > So there it is. I think just like EJB, JBoss wants to be here for many years, with a simple vision for professional open source.
    >
    > And if you don't get it? you are free to piss off.

    You too then.
  116. yawn[ Go to top ]

    You are funny, well we recruited 3 of these projects for the professional open source ride.


    >Yes. But now you want to change them, don't you?

    One of the absolutely surefire ways to detect someone with absolutely preconcieved opinions, impervious to actual evidence, is to notice when they ignore what their "adversary" *says* they are doing, and concoct outlandish explanations for what they "really" are doing.

    A fantastic example of this - by way of illustration - is when GW Bush and Tony Blair say "we are going to invade Iraq 'cos we think Saddam is a threat to world peace". Then the far left come back and say "oh no, its really all about ooiil". Yet, it is quite impossible that they know and understand the motivations of GWB better than he himself does!

    Sometimes, it makes far more sense to take things that a person you may happen to disagree with /says about themself/, simply, at face value.

    So, even if you happen to disagree with Marc on many things, if I, Marc, Christian, Bill, Max, etc, tell everyone loudly and proudly what the future of Hibernate is, why not, in the absence of any contradicting evidence, just accept what we say?

    Do we strike you as people who are /ashamed/ of what we are doing? Do we seem like /secretive/ people? Do you really think it is likely that Marc and I have cooked up a hidden plan to hijack the Hibernate project and wreck it so noone wants to use it anymore?? Do you have a *shred* of evidence for that?? How could it possibly be in our interest? Don't you think that I of all people would have the greatest interest in preserving our philosophy and achievements? And that the person with the second-greatest interest would be the person who is paying a lot of money for the opportunity to take commercial advantage of those achievements, ie. Marc?

    Well, perhaps it is because I am a blunt and uncomplicated Australian that I am inclined to accept the simplest possible explanations for things. I'm sure the rest of you guys are much more sophisticated than I.
  117. Bad choice of analogy there Gavin[ Go to top ]

    You'll never hear the end of this one.

    Gary
  118. Re: yawn[ Go to top ]

    You are funny, well we recruited 3 of these projects for the professional open source ride.

    >
    > >Yes. But now you want to change them, don't you?
    >
    > One of the absolutely surefire ways to detect someone with absolutely preconcieved opinions, impervious to actual evidence, is to notice when they ignore what their "adversary" *says* they are doing, and concoct outlandish explanations for what they "really" are doing.

    What I find funny about this whole "recruit these projects" thingy is
    the term "recruit". Why? Because when SuSE employs lead developers of open
    source projects like ALSA, KDE, etc. they never swallow the project and claim it to be part of SuSE. They simply are sponsoring work on these projects by way of a pay check. In my opinion this is a more honest approach.

    See, JBoss Group can't recruit OS projects. Only the/some people behind these projects.

    Regards,
    T.V.
  119. Re: yawn[ Go to top ]

    What I find funny about this whole "recruit these projects" thingy is

    > the term "recruit". Why? [..] See, JBoss Group can't recruit OS projects. Only the/some people behind these projects.

    Thank you for articulating that. This whole recruitment business is there to create the perception that all these projects are controlled by a single group. But to me that makes these projects less, not more attractive.

    Marc in particular has amazing chutzpah :) He is saying that Tomcat is a JBoss project? What is that supposed to mean? I hope it doesn't mean that the docs are going to get locked up soon.
  120. yawn[ Go to top ]

    A fantastic example of this - by way of illustration - is when GW Bush and Tony

    > Blair say "we are going to invade Iraq 'cos we think Saddam is a threat to world
    > peace". Then the far left come back and say "oh no, its really all about
    > ooiil". Yet, it is quite impossible that they know and understand the
    > motivations of GWB better than he himself does!

    Note that it is technically possible to not lie and still not tell the truth. The trick is to believe what you are saying, even if what you're saying has nothing to do with actual reality.
  121. yawn[ Go to top ]

    One of the absolutely surefire ways to detect someone with absolutely preconcieved opinions, impervious to actual evidence, is to notice when they ignore what their "adversary" *says* they are doing, and concoct outlandish explanations for what they "really" are doing.


    I agree with you. But in this case I am not guessing. I am specifically referring to "professional open source" vs. Apache-style open-source, say.

    Professional open source is what Marc is all about. He is the one who believes that it's different. And I agree with him. From my end, these are the innovations brought to the open source model by JBoss:

    1. An aggressive attitude. Typically, boasting of being the best in the world. Also of taking over the world. Don't make me dig up the 2-year old claim that JBoss was going to put BEA out of business.

    2. A lack of transparency, as a way of promoting the role of the authors of the code. In practice this has translated into charging for documentation. But there is also a less tangible issue of not exactly bending over backwards to tell the truth about what JBoss can and cannot do.

    So things are definitely different with JBoss.

    Hibernate, however, is a shining example of an open-source project. It's wide open. That's why I am worried about it getting closed. Now, you are free to do whatever you like to it, because if you (Gavin) need the work, then that's your choice. But if Marc gets to determine the future direction of Hibernate then Hibernate is definitely going to change.

    Good enough?
     
    > A fantastic example of this - by way of illustration - is when GW Bush and Tony Blair say "we are going to invade Iraq 'cos we think Saddam is a threat to world peace". Then the far left come back and say "oh no, its really all about ooiil". Yet, it is quite impossible that they know and understand the motivations of GWB better than he himself does!

    I support the war in Iraq. In fact, we should have done it earlier. And I agree with you that GWB knows critical things that I will only (maybe) find out in ten or twenty years. No yellow-dog democrats here.

    > Sometimes, it makes far more sense to take things that a person you may happen to disagree with /says about themself/, simply, at face value.

    I am totally taking Marc' word at face value. And what I am hearing doesn't sound too good.
     
    > So, even if you happen to disagree with Marc on many things, if I, Marc, Christian, Bill, Max, etc, tell everyone loudly and proudly what the future of Hibernate is, why not, in the absence of any contradicting evidence, just accept what we say?

    Fine. I look forward to hearing more from you then.

    > Do we strike you as people who are /ashamed/ of what we are doing? Do we seem like /secretive/ people? Do you really think it is likely that Marc and I have cooked up a hidden plan to hijack the Hibernate project and wreck it so noone wants to use it anymore?? Do you have a *shred* of evidence for that?? How could it possibly be in our interest? Don't you think that I of all people would have the greatest interest in preserving our philosophy and achievements? And that the person with the second-greatest interest would be the person who is paying a lot of money for the opportunity to take commercial advantage of those achievements, ie. Marc?

    I don't see it in such terrifying terms. But I am intrigued that you have an apocalyptic view of this ..

    > Well, perhaps it is because I am a blunt and uncomplicated Australian that I am inclined to accept the simplest possible explanations for things. I'm sure the rest of you guys are much more sophisticated than I.

    Not me.
  122. yawn[ Go to top ]

    You are funny, well we recruited 3 of these projects for the professional open source ride.

    >
    > >Yes. But now you want to change them, don't you?
    >
    > One of the absolutely surefire ways to detect someone with absolutely preconcieved opinions, impervious to actual evidence, is to notice when they ignore what their "adversary" *says* they are doing, and concoct outlandish explanations for what they "really" are doing.
    >
    > A fantastic example of this - by way of illustration - is when GW Bush and Tony Blair say "we are going to invade Iraq 'cos we think Saddam is a threat to world peace". Then the far left come back and say "oh no, its really all about ooiil". Yet, it is quite impossible that they know and understand the motivations of GWB better than he himself does!


    Did the real Gavin King really write this crap? If so, did he leave his f****g brain at home for the day?


    >... because I am a blunt and uncomplicated Australian that I am inclined to accept the simplest possible explanations for things. I'm sure the rest of you guys are much more sophisticated than I.

    Evidently.
  123. yawn[ Go to top ]

    Re-reading my above post, it seems like a needless flame. No offence meant to Gavin (great framework, use it all the time), honest, it was his choice of analogy that bugged me, rather than his actual sentiment.
  124. , Open Source or not

    For many years ago there was a synthesizer that was named Synclavier, very expensive (1+ million dollar) that was the state of the art in the music industry and affordable only by guys like Stevie Wonder, Frank Zappa, Sting, Pete Townsend- etc. Probably the best synthesizer ever made.

    And yet. Today the Synclavier is extinct. Why?

    Because it is out-competed by small black boxes for 50-100 dollar a piece. Put together 8-10 of these boxes in a studio and you have the equivalent of a Synclavier system, for a fraction of the price.

    And yet when the first boxes appeared on the market, the mighty Synclavier owners were arrogant, conceited, overbearing and self-complacent! But they snigger no more..

    There are two (obvious) reasons for this:
    1) Big systems can never be up-to date, all systems should ideally instead be build by replaceable small modules.

    2) Big systems, with all parts more or less depending on its others are very vulnerable to bugs.

    I have never been able to understand how any software engineer is willing to place hundreds of thousands of lines of code between himself and the customer. Never heard of Murphy's Law? > "If anything can go wrong, it will". Big J2EE Servers track record = 80% project failure rate, down one of seven days.

    "Think of the poor customers! One of theme might had become your good friend."

    Regards
    Rolf Tollerud
  125. <quote>
    There are two (obvious) reasons for this:
    1) Big systems can never be up-to date, all systems should ideally instead be build by replaceable small modules.
    2) Big systems, with all parts more or less depending on its others are very vulnerable to bugs.
    </quote>

    Yes, componentized, modularized, separation of concerns, etc. are always the target. Therefore we need EJB. Standardized and reuse! Thanks for adding these comments. I agree with you.

    Cheers,
    Lofi.
  126. Hi Lofi,

    I think your post was sarcastic! (just so we have the 80% with us). But still, what is the difference between a "componentized, modularized, separation of concerns" system build upon a Big J2EE server and a system of black boxes?

    The key factor is that the pieces should be replaceable.

    "Hey the aaa module from x company is not working! OK, replace it tomorrow with bbb module from company y".

    So maybe sometimes in the future when the software world is organized like you advocate in your very good post "Foundation and Consortium"
    http://www.theserverside.com/news/thread.jsp?thread_id=23651#108935

    Then we possible could speak of the return of the dinosaurs.

    Regards
    Rolf Tollerud
  127. Hi Rolf,

    <quote>
    I think your post was sarcastic!
    </quote>
    Sorry, no, I don't mean that to be sarcastic. I really agree with your points. EJB is only one way what we have now... We all surely search for "a better" way, at least that's what we are staying for, right?

    <quote>
    The key factor is that the pieces should be replaceable.
    "Hey the aaa module from x company is not working! OK, replace it tomorrow with bbb module from company y".
    </quote>
    Again, agreed. I just want to see software like batteries, you know... ;-) I really don't care what companies produce those batteries but as long as I take a "AA" type batteries, I can use them everywhere I need them. I just have to decide for the quality (long-life), the price (cheap/expensive), the extension (rechargable or not), etc.

    Reusing in "big programming" could be solved by Webservice. If I need a discussion component, I don't care whether I run .NET (MS), J2EE (Java) or whatever, I just can buy a Webservice discussion component and integrate it in my application.

    The problem is the reusing in "small programming", because at the end we have to install that Webservice discussion component (yes, the Webservice discusion component is written in one of the programming language and can only run in one platform) in our platform (.NET, J2EE, etc.) and this is the problem. So, the problem lies on details as usual ;-) I would like to see that at least in this "small programming" area in Java, that we have such a standard to allow reusing business components easily. JavaBeans is succesful for GUI components, why not trying to push EJB for the business components? In the beginning EJB only push for the "real" business components on the server-side (heavy transaction, etc.). But now you also can use it "lightweight" on the client (local interface). I'm sure it's just a matter of time that EJB experts will add more options on "lightweight" EJB... At the end if you have a lightweight client application and you use some of your business components, you still need transaction, right?
    This is why I feel pitty, that those clever people from Spring (which has the same target = lightweight business components) don't join the EJB group to solve or add the "lightweight EJB" with the standards. Instead it creates a new deployment descriptors for those lightweight components... I know consortium / JSR works is hard but at least it could be good for many...

    I know EJB needs some rework, but don't throw it, because it could be the way to the "batteries" reuse ;-)

    Regards,
    Lofi.
  128. how JBoss can stay in fashion[ Go to top ]

    Hi Lofi,

    The "AA" type batteries are a good analogy. I remember an article by a journalist that had a very good and simple method for finding out if the society he was visting was functioning. Whenever he comes to a new country he tries to buy replacement batteries for his recorder. In the old eastern block communist countries he very often couldn't find any but when he got to Iran there was no problem. Whatever other faults it was with Iran at least the market was working!

    IMO, the best way that JBoss could do is to create such a "Foundation and Consortium" that you describe around it just the way IBM have done with Eclipse.

    Lightweight business components are what we need. Give it to me. Now.

    Regards
    Rolf Tollerud
  129. SaMEJB[ Go to top ]

    <quote>
    Lightweight business components are what we need. Give it to me. Now.
    </quote>

    Yep. I hope all those experts hear us: We need lightweight standardized business components:

    SaMEJB (read: same jay-be) = Small and Medium Enterprise JavaBeans ;-)

    Regards,
    Lofi.
  130. were is the key.[ Go to top ]


    > Hibernate, Tomcat, JGroups were all real businesses before they joined JBoss.com.
    >

    And they siezed to be once they joined JBoss. Tomcat? Since when did they joined you? It's happy and alive at Apache.
  131. This is fantastic stuff[ Go to top ]

    Marc, thanks for your reply. A couple of questions though:

    > LOVE ENTITIES :) I haven't changed my opinion except for one part in fact.

    Glad to hear this.
     
    > It seems people get bogged down in interfaces (true) and we must solve the "complex problem" of JNDI lookups (!!!!please!) but the automated caching and persistence of entities always was the best feature of entities, something that many posts seem to miss here. The "entities must go" posts are idiotic :)

    I think the component element attracts me more than these features. Entities are very modular and yet strict but they still make a pretty decent persistence framework.

     
    > Also market standards are important, i predict a LONG lifetime for EJB, limitations and future versions included. This is a very wide basis to build upon (we know in our business). So I am looking forward to the iterations on EJB standards and we will probably be having this discussion on EJB 5.0, market standards have momentum on the upside and inertia on the downside. I am amused when I see people hailing their little framework-du-jour, backed by 2 clowns and their dog, as the "EJB killer", it is cute and oh so revolutionary, I relate. Market standard are powerful, very powerful. They are markets makers, period.


    Finally, you had me worried with all those AOP statements that JBoss is going to neglect the spec. I do hope this is the case because this is what I find most attractive about J2EE.

     
    > The one thing where I have change my stance is on the persistence layer. I think we need an alternative to CMP 2.0 "mon amour" :) I thought JDO was a mess of a spec and had little hope it would see the light of day. However I don't like getters and setters on EJB and AOP/bytecode manipulation showed us they are un-necessary. JDO gets that simple point. It is a contender today imho if and only if they can simplify JDO2.0 which is becoming a bit of a beast in its own right. CMP 2.0 was what 60 pages long? couldn't the JDO guys do it right?


    So you will CMP become a secondary citizen, or will it be actively supported and reccomended by JBoss?

    > Since then also we recruited Hibernate into the JBoss.com project family (like tomcat and jgroups). A decent EJB model on JDO could be a good one to have. So I am totally open either way, we make money either way ;) we will let you guys decide.

    Thats good to hear.
  132. CMP as a second class citizen[ Go to top ]


    > So you will CMP become a secondary citizen, or will it be actively supported and reccomended by JBoss?
    >

    CMP will be actively supported within JBoss as we are committed to J2EE certification. What we hope to do is build JBoss CMP on top of Hibernate. Alex Loubyansky, our CMP lead, has already done a prototype in this area. No rush though as our current CMP implementation is becoming more and more solid.

    But will CMP become a secondary citizen? At least in mainstream applications it should, mainly because the CMP spec sucks. The fact that you have to plug-in your own value object concept or that fact that EJBQL is hobbled enough so that you must sprinkle in JDBC code everywhere in a complex application are just a few of the reasons why CMP sucks. As Marc said, this is one of the reasons we recruited Hibernate (and why the JDO 2 committee recruited Gavin to join them).

    Bill

    P.S. As Marc said, we don't care who wins as one JBoss support contract covers any JBoss.org project including Tomcat, Hibernate, JBoss/J2EE, AOP, Nukes, JGroups, Mail Services, etc. One-stop support for a variety of open source products.
  133. This is fantastic stuff[ Go to top ]


     So you will CMP become a secondary citizen, or will it be actively supported and reccomended by JBoss?
    >

    CMP as the standard will remain the first citizen of our EJB implementation.

    CMP is first an API, queries and metadata. Hibernate as the back end for that engine is the plan but the API is the standard. STANDARDS ARE IMPORTANT, we always stuck by them.
     
    marcf
  134. This is fantastic stuff[ Go to top ]

    Shai,

    >
    > One post here comes closer to the truth with "persistence + cache" are equivalent to entities, yes that is what entities are. Does that mean we should get rid of them? AU CONTRAIRE!!!! it means that we have a standard way of doing it. EJB introduced all that to the market 4 years ago. That is mostly why I still love EJB. They provide a packaged, standard, easy way of doing these core features.
    >
    > Also market standards are important, i predict a LONG lifetime for EJB, limitations and future versions included. This is a very wide basis to build upon (we know in our business). So I am looking forward to the iterations on EJB standards and we will probably be having this discussion on EJB 5.0, market standards have momentum on the upside and inertia on the downside. I am amused when I see people hailing their little framework-du-jour, backed by 2 clowns and their dog, as the "EJB killer", it is cute and oh so revolutionary, I relate. Market standard are powerful, very powerful. They are markets makers, period.

    Hmm, I'm not sure if you're trying to put a dig into Spring here, but if so, I would suggest that you (the JBoss group) concentrate on getting _your_ cards in order. Never mind the mediocre usability aspects of the Entity ejb API, I would suggest an application stack consisting of Spring Transactions + Hibernate for the tx+persistence aspects is going to be more performant than a JBoss EJB implementation, if properly tuned, but more importantly, more reliable. The CMP EJB implementation and EJB related classloading in JBoss has gone from ridiculously buggy about 15-16 months ago to just somewhat buggy now. When I install a new JBoss point release, it's a complete crapshoot as to what quality level it is at, and even what existing features will be broken. For example, in early June, a JBoss 3.2.x TomCat version was released without TomCat even inside it. When prodding produced a release with TomCat, it wouldn't even start up. These are gross errors, but point releases have in the past broken or changed things such as fundamental classloading behaviour, etc., which are harder to detect.

    Now what I'm trying to do here is not blame you guys, but suggest that it hard for the JBoss group, with limited resources, to follow a spec as big (and mediocre in parts) as J2EE and produce a quality product. Fundamentally, I think a smaller project like Spring, Hibernate, you name it, produced by a small team of dedicated individuals, has a much better chance of putting out a quality product with tight, well-tested code. Try pulling Spring out of CVS right now (v1.0RC1 is almost ready to be released in less than a week). You'll find that test code coverage over the last 4-5 months has consistently stayed over 80%, and is in fact over 90-95% in some of the more complex areas. If you were using daily CVS builds, never mind release versions, you would find that there is almost never any breakage.

    In this respect, I think it's good (for the JBoss group) that you have latched on to Hibernate. It's a quality product put out by a smart, focused individual (not to belittle the big contributions of Christian and others). The same strategy will hopefully improve JBoss in the future in a number of areas (caching, etc.). Perhaps you could pick up a decent JMS implementation instead of trying to build it from scratch.

    In the meantime, please refrain from throwing barbs at products which in fact work great and are better built (in terms of quality level) than yours. It's very insulting...

    Regards,
    Colin
  135. You are saying that a 1.0 RC1 is more stable than a product used in production by a lot of very large companies all over the world. I read through Marc's post and could not find one place in which he ripped on Spring. I think he just talked about standards will win the battles, not little groups huddled in their own corners.

    You are mighty defensive is there something that people should know?

    I do agree with your post on the JBoss CMP engine being caca. I think it has gotten better now, as the guy who wrote it left and the others started to make it better. I had a ton of problems with the CMP engine in 3.0.x, but have seen it improve in 3.2.x significantly. I read something that they are going to build CMP on top of Hibernate, which should really scream.

    I would like to add something about being united. If we can all agree on things that need to get done, we have a chance, if we all have own own idea of how to change the world, the world is never going to change. Just my thoughts after reasding this thread. There are some good ideas going on and for some reason, it seems that people just can not resist throwing mud.
  136. You are saying that a 1.0 RC1 is more stable than a product used in production by a lot of very large companies all over the world. I read through Marc's post and could not find one place in which he ripped on Spring. I think he just talked about standards will win the battles, not little groups huddled in their own corners.


    Please read my post. I was referring to the EJB (persistence) portions of JBoss, and a few areas such as classloading. Some pieces of JBoss are rock solid, some are much worse.

    > You are mighty defensive is there something that people should know?

    I am being defensive because I read the 'two guys and their dog' comment as a direct dig at Spring (Rod J. and Juergen are the main contributors). Considering Marc's message was about Entity EJB persistence, I take umbrage at the suggestion that JBoss has a better solution in this part of the stack (than something like Spring and Hibernate). It's that simple...

    > I do agree with your post on the JBoss CMP engine being caca. I think it has gotten better now, as the guy who wrote it left and the others started to make it better. I had a ton of problems with the CMP engine in 3.0.x, but have seen it improve in 3.2.x significantly. I read something that they are going to build CMP on top of Hibernate, which should really scream.

    Agreed. Unfortunately, that only solves the quality issue. It doesn't resolve any issues with usability of the API in typical development scenarios.

    > I would like to add something about being united. If we can all agree on things that need to get done, we have a chance, if we all have own own idea of how to change the world, the world is never going to change. Just my thoughts after reasding this thread. There are some good ideas going on and for some reason, it seems that people just can not resist throwing mud.

    Let me tell you, (mediocre) standards only go so far. I'm glad Gavin King decided to change the world a year and a half ago. Hopefully his success will make EJB 3.0 or JDO 2.0 a better standard.

    Regards,
    Colin
  137. I am being defensive because I read the 'two guys and their dog' comment as a direct dig at Spring (Rod J. and Juergen are the main contributors).

    >

    I didn't know spring was really 2 guys and their dogs. That's cool. JBoss was 2 guys and my dog, for a long time :) (rickard and I, then Scott and I, then...). we finally got to 26 guys and their dogs full time, but still.

    >
    Considering Marc's message was about Entity EJB persistence, I take umbrage at the suggestion that JBoss has a better solution in this part of the stack (than something like Spring and Hibernate). It's that simple...
    >

    oy, HIBERNATE IS A JBOSS.COM PROJECT. CONNECT THE DOTS YET? THINK.. WHY DID WE GET THEM ON BOARD? BECAUSE WE BASE OUR CMP ENGINE ON IT :). Mr King is a full time employee.

    Frankly, the number of beers I have downed trying to convince Gavin that standard are important for market creation is crazy. I remember one particular night in amsterdam with bob bickel. Smashed. We couldn't get it done he is slowly turning around. Standards are important, we will work it out.

    I would rather see Hibernate give us a good EJB 3.0 (getters and setters gone) or JDO than have to fight a costly dual battle.

    Obviously! that is just business common sense

    marcf
  138. I would like to add something about being united. If we can all agree on things that need to get done, we have a chance, if we all have own own idea of how to change the world, the world is never going to change. Just my thoughts after reasding this thread. There are some good ideas going on and for some reason, it seems that people just can not resist throwing mud.


    I want to add something more to my previous comment...

    We are totally f*cked without standards. Standards are, in one way or another, the basis of all the great products and libraries that have been produced in the Java world. Without standards we are nothing.

    But my point is exactly that there is incredible value in these small projects that try to change the world. The standards process tends to be very slow, and produce mediocre results, left on its own. The ideas, big and small, which sprout all over the place in Java land (outside of the JCP) end up having a big influence on how the standard APIs evolve, and how well and efficiently people get their job done. And finally, it's the very nature (produced by people of varying skill and dedication) of how they are produced, that each should be examined on its own. Generalizations such as '2 clowns and their dog' serve no constructive purpose in this discussion.

    Regards,
    Colin
  139. Top-down or bottom-up?[ Go to top ]

    I'd just like to interject that I think standards work best when you have a bunch of competing solutions, and one rises above the rest to become a standard.

    The other approach -- having some monolithic body/group/whatever "define" a standard -- is not, in my opinion, the best approach.

    Then again, this opinion is worth exactly what you just paid for it.
  140. Top-down or bottom-up?[ Go to top ]

    I'd just like to interject that I think standards work best when you have a bunch of competing solutions, and one rises above the rest to become a standard.
    I'd like to see a bunch of competing solutions to all contribute their part to a standard (not just one rising above the rest to become a standard). That's what this whole discussion is about in my opinion. Some people fail to see how standards are realized, in history, and also in the future. Small groups of people, putting together high-quality projects, implementing new ideas is the way it's always been and as it - IMHO - always should be. Competition has always been the basis for innovation and as a result, standards. So uniting as far as I'm concerned, is indeed *not* the way to go...

  141. We are totally f*cked without standards. Standards are, in one way or another, the basis of all the great products and libraries that have been produced in the Java world. Without standards we are nothing.
    >

    amen

    Open Standards have historically been the drivers of the computing industry. Open Source coupled with Open standards is a very powerful thing.

    marcf
  142. Simplify.[ Go to top ]

    Many things come to mind, but these two are most important IMO:

    1. Take all those bizarre extra interfaces up into the container and let the developer work with a POJO. As much as I have grown to love XDoclet, it is not the solution, it is a symptom of a larger problem.

    2. Make testing out of the container possible without a lot of heartache.
  143. clusters[ Go to top ]

    Now, I am developing on Weblogic cluster with 40 nodes. Am I ever use Hibernate/JDO here? NO! Weblogic have extremly amount of features to work in such environment.


    >Are you concerned about Hibernate's cache behavior in a large cluster or did you have something else in mind? I'm just curious as to why you feel the transparent architectures are less able to handle an extremely large application and then list for enhancements the good things we get from the Hibernate/JDO persistence models.

    I'd also love to see some answer to this question. I'm no WebLogic expert; I've only perused the WebLogic documentation. From what I can see, however, WebLogic offers *no* entity bean clustering functionality that is not VERY easily available for session bean + Hibernate + SwarmCache/JBossCache/Coherence. In fact, I'd say that Hibernate's 2+1 cache architecture (session cache + granular second-level cache + granular query cache) looks much more sophisticated than what WebLogic offers. (Certainly it is much more sophisticated than what WebSphere has.)

    But, of course, I may be missing something.

    Perhaps Cedric would also like to comment.
  144. clusters[ Go to top ]

    Gavin,

    What WebLogic provides in a cluster is optimistic caching by pkey with async invalidation. In English, that means that cluster nodes only cache locally, only for primary key lookups, and have to be prepared to handle the case that stale data were used (i.e. optimistic concurrency checks must be utilized for updates.) For 80% of applications, this is probably sufficient. For the rest ... ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  145. clusters[ Go to top ]

    Thanks Cameron, this confirms my understanding; indeed this is very similar behavior to Hibernate running with SwarmCache as a second-level cache (and no query cache).
  146. I have a simple idea on how to replace the current EJB structure:

    Let J2EE application servers have a directory (say, $SERVER_HOME/public) where you put those classes that you want to expose to the network.

    Example:
    let's say we have a machine called 'marge.mydomain'. On 'marge', we have an appserver containing the class 'mydomain.OrderClerk' in it's /public dir.

    To use the mydomain.OrderClerk (a plain old java class, no specific interface needs to be implemented) from the machine 'bart', you just write:

       RemoteProvider remote = new RemoteProvider("marge.mydomain");
       mydomain.OrderClerk clerk = remote.lookup("mydomain.OrderClerk");
       // clerk.addOrder(new Order(..))

    No remote/local/localhome (etc.) interfaces, just a directory where classes accessible from the network are placed.

    Can it be much simpler?
  147. Oh, and for persistence (ie for replacing entity beans, previous message was about replacing/simplifying Session Beans), something like Hibernate should be used. Ie, mapping objects to RDBMS:es is done via XML files.

    Err, why not even *add Hibernate* to the official J(3?)EE codebase?? :)

    Just my €0.02.
  148. Re-read the original post and noticed that you requested constructive suggestions for security as well - what about letting the server keep an XML file for host-based access control to the publicly exposed classes?

    Something like:

    <access-control>
       <host name="bart.mydomain">
          <allowed-class>mydomain.OrderClerk</allowed-class>
          <allowed-class>mydomain.ProductClerk</allowed-class>
          <allowed-class>mydomain.ContactClerk</allowed-class>
       </host>
    </access-control>
  149. Concerning how to separate stateful classes from stateless, just keep two directories under /public:

    /public/stateful
    /public/stateless

    Classes put under /public/stateful are "session wide", classes under /public/stateless are not.

    Actually, $SERVER_HOME/published might be a better name for the root dir when I think of it, as it otherwise might lead you to think that all classes under that dir is public("remotely accessible", as some might interpret it). You may want to publish some classes only on the local appserver (to other apps), thus, $SERVER_HOME/published might be a better name for the dir.
  150. need remote security context autogeneration so when initialcontext constructor called with no parms, local server, principal/subject identifier, server identifier, method of authentication is stored and used on subsequent remote calls, say to create ejb home and get the stub or for use on WS invocation.

    glue standards based security to EJB container and grid will be interoperable.
  151. Currently trying to move a bea Weblogic 8.1 EJB 2.0/CMP Application to WebSphere 5.x, one of most painful development experiences I've encountered. I would like standard deployment descriptors across all vendors, with perhaps a single file for vendor (non J2EE standard) specific features.
  152. My wishlist[ Go to top ]

    I've written at least 7 different EJB systems from scratch and maintained about the same number. Lately I've desserted EJB entirely because I frankly do not believe it adds enough value for the pain you have to go through to create them.

    These are the areas that EJB needs to be approved:
    1. Testability, at the moment there's no standard way of writing (fast-running) unit-tests of an EJB outside the container. It should be possible to just instantiate an EJB without requiring an entire container.
    2. Ease-of-use. It should be possible to write an EJB without using code-generation techniques such as XDoclet or an IDE. The fact that an architecture relies on these work-arounds is a sure smell that something is not entirely right.
    3. Extensibility. EJBs currently offer a limited set of services: security, transactions, persistence, distribution. But there's no way of adding new services in a standard way.

    These are some "action-points" that could remedy some of the problems:
    1. No more deployment descriptors, with the birth of JSR-175 meta-data that should no longer be necessary.
    2. No more intf/impl-separation for local EJBs (the app-server is in control of the class-loader and could use that or deployment time transformations to do bytecode injection).
    3. No more JNDI. Okay, maybe not that drastic, I realize some other specs like JMS, JDBC rely on JNDI but maybe some more easy-to-use lookup mechanism (sorry? did you say "dependency injection"? oh, that'd be an excellent idea!).
    4. No more home-interfaces. The home-interfaces are a pain to maintain or generate but on the other hand I'm not sure how you would do factory/lookup/queries without them. In the case of stateless session-beans (the most useful part of EJB) they are certainly not needed.
    5. Interceptors. This is perfect way of adding extensions and has been explored a whole lot currently in the AOP-community and previously in CORBA. I'm really surprised it's still not in EJB. (I suspect political reasons behind this and not technical.)
    6. Just drop the whole Entity-beans/CMP part, or at least have the decency to replace it with proper OR-mapping (like... JDO?).

    Ok, can't come up with anything more at the moment.
  153. Two big features:

    1) Evolvability - some support for replacing applications without turning them off all at once. I don't know enough about this field, but the pros could look into it and try to come up with something.

    2) Fault-tolerance by replication. See CORBA Fault Tolerance specification for ideas.

    They may be too big for 3.0, or perhaps even too big for EJB, but at least they are interesting.
  154. Thanks to all - we are listening[ Go to top ]

    Hello all,

    Just want to say thank you to everyone who posted here and to assure you that the JSR-220 Expert Group is listening. I have read every word in this thread - even the (boring) flame war - and I know Richard has pointed the EG at it so several others are doing so as well.

    Sooner or later we will be ready with community and public drafts of the spec. At that time I hope you will all (a) agree your most important concerns are being addressed, and (b) give us feedback with as much energy and thought as you have done here.

    Cheers
    Scott Crawford
    One of the five individcual members on the JSR-220 Expert Group
    http://www.scottcrawford.com
  155. Thanks to all - we are listening...[ Go to top ]

    Who are you? You seem like someone who who has not done much. Is this a spec committee of people who have not done much? Who is on this group? To me, this expert group should be someone from BEA, IBM, JBoss, Oracle, and that's about it. Even RMH while a great writer, what has he implemented?
  156. Thanks to all - we are listening...[ Go to top ]

    Who are you? You seem like someone who who has not done much. Is this a spec committee of people who have not done much? Who is on this group? To me, this expert group should be someone from BEA, IBM, JBoss, Oracle, and that's about it. Even RMH while a great writer, what has he implemented?


    I think Richard has done quite a bit of implementation. But I think it's also vitally important that independents are on spec committees. If Scott is listening, that's great and we should try to give him something more interesting to listen to.

    Scott, what I hope to see in EJB 3.0 is a real simplification of the programming model. Using EJB now is too complex. There have been some good suggestions in this thread that might help. I would love to see the spec group look at some real, complex applications using EJB and see how they could improve the spec to make such applications easier to build and maintain. Real-world experience of application development is important--as of course is experience of building EJB containers.

    Regards,
    Rod
  157. Thanks to all - we are listening...[ Go to top ]

    If you are interested in the membership of the Expert Group, have a look at the official page for this JSR:

    http://www.jcp.org/en/jsr/detail?id=220

    If you are trying to start another flame war, bait someone else.
  158. Thanks to all - we are listening...[ Go to top ]

    Arun Patel: Who are you? You seem like someone who who has not done much.

    And who is Arun Patel? Or are you getting tired of being asked that yet?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  159. Please:[ Go to top ]

    - specify classloading.

     - specify deployment descriptors.

     - add a tester role to J2EE, and just follow the use cases.

     - start to move off CMP/BMP in favour of OR/JDO.

     - unspecify any code that can be generated. XDoclet/ejbgen are band-aids around a broken API.

    Fwiw, I don't think the J2EE bean model is that difficult - but it's downright clumsy to use and doesn't maintain or evolve particulary well.
  160. To bring this back to the topic[ Go to top ]

    I think it is fair to say that it would be useful to have J2EE classloading specified and standised.

    Look at the discussion in this thread about that JBoss classloader - this kind of pain is something we don't need, and could be quite easily avoided by standardising the behaviour. (Of course app server could modify that behaviour with non-standard switches if they decide to)

    Nick
  161. To bring this back to the topic[ Go to top ]

    I think it is fair to say that it would be useful to have J2EE classloading specified and standised.

    >
    > Look at the discussion in this thread about that JBoss classloader - this kind of pain is something we don't need, and could be quite easily avoided by standardising the behaviour. (Of course app server could modify that behaviour with non-standard switches if they decide to)
    >
    > Nick

    If the standardization is to be as flexible as JBoss classloading than I am all for it. Different applications have different requirements. Besides, you have different classloading problems with different app servers, its just a different hell wherever you go.

    Bill
  162. To bring this back to the topic[ Go to top ]

    <Bill Burke>
    Except when you use the JDBC/Hibernate/MVC wrapper/infrastructure classes you talk about above ;)
    </Bill Burke>

    He was talking about _framework_ code. You are talking about _library_ code.

    Pratheep
  163. J2EE made easy[ Go to top ]

    Having used CMP and SSLB's in JBoss previously, my last few projects have used Spring (Hibernate & SSLB). One thing I've noticed is that Spring just makes things easier.
    Isn't that what we're pushing for?
  164. J2EE made easy[ Go to top ]

    Isn't that what we're pushing for?


    yes,

    SSLB is a clear case, but entities with Hibernate exposed inlieu of CMP is also a clear case. We wrap up of Hibernate essentially.

    I am working through a port of petstore to make sure we understand all the issues here, but simply it reads

    marcf
  165. Add 'em all[ Go to top ]

    I say we add ALL these suggestions to the spec. Make it as complicated and diverse as possible so that:

    * No one can use it anymore and we all give up trying and go back to doing things more simply - god forbid; and/or;

    * Those that do understand it can charge through the nose for consulting services and make themsleves very rich.

    Either way I'd be happy ;-P
  166. Bully-boy[ Go to top ]

    Mike Spille, please go away.

    * You have contributed nothing to open source or to the open source community.

    * You have no insight at all into JBoss Group and clearly have absolutely no idea of what you are talking about.

    * You have an opinion on everything, and, unlike a clock, you are right only about twice a month.

    * You have never stated a single opinion on /anything/ without combining it with outrageous ad hominem.

    Everyone else in this particular flamewar has made significant contributions; they are all people I know and love; they all have strong technical insight, even when they disagree with each other. They are arguing because they are passionate about technology and about what they are doing in their lives. *You* argue with everyone and everything, merely to aggrandize yourself. They (and I) are sometimes intemperate. *You* are a bully.

    Just Shut Up. Please.

    FYI, I am right /here/ in Atlanta /right now/, and believe me, this is the most exciting time of my life. JBoss business success is quite breathtaking and it is absolutely fantastic to see it rubbing off on Hibernate. A dream come true for me.
  167. Re: Bully-boy[ Go to top ]

    Mike Spille, please go away.

    >
    > * You have contributed nothing to open source or to the open source community.

    As if this would be precondition to post one's opinion here.

    > * You have no insight at all into JBoss Group and clearly have absolutely no idea of what you are talking about.

    Well, you are free to correct him on any errors I guess.

    > * You have an opinion on everything, and, unlike a clock, you are right only about twice a month.

    Way off base, Gavin. Mike's a bright man, don't belittle him in such a cheap way. Start reading his blog ;-)

    > * You have never stated a single opinion on /anything/ without combining it with outrageous ad hominem.

    A game your new boss and working partners are playing pretty well themselves if I might add.

    > Everyone else in this particular flamewar has made significant contributions; they are all people I know and love; they all have strong technical insight, even when they disagree with each other. They are arguing because they are passionate about technology and about what they are doing in their lives. *You* argue with everyone and everything, merely to aggrandize yourself. They (and I) are sometimes intemperate. *You* are a bully.
    >
    > Just Shut Up. Please.

    Oh well, a wise man once said that the way how you handle your critics shows a lot about one's character and confidence. From my perspective here, following all the discussions on this forum in the last months, JBoss Group does not do well in that respect.

    > FYI, I am right /here/ in Atlanta /right now/, and believe me, this is the most exciting time of my life. JBoss business success is quite breathtaking and it is absolutely fantastic to see it rubbing off on Hibernate. A dream come true for me.

    Good for your, I guess.
  168. Re: Bully-boy[ Go to top ]

    Oh well,

    Hibernate was nice while it lasted. Looks like Marcf has gotten through to Gavin in the worst way... ideologically. Too bad...

    I had once hoped that Hibernate would remain a solid stand alone product. However, to see the way Gavin is now responding to criticism (the good 'ol JBoss way), points to the all but inevitable future of Hibernate becoming an inseparable, bug ridden and completely useless "feature" of JBoss. Because obviously, Hibernate on its own and not intimately tied to JBoss internals, is not "Professional Open Source" or whatever the JBoss mantra of the month is.

    I'll give you the same advice all boy bands should take: be sure to save some money, the ride won't last long.

    Cheers
  169. Bully-boy[ Go to top ]

    \Gavin King\
    Mike Spille, please go away.
    \Gavin King\

    I wasn't aware that TSS was by invitation only, and that you were the gatekeeper. Lots of people love your product, Marc F pays you to do what you love, and even buys you a plane ticket to fly from Australia to Atlanta, so I guess you feel you're about king of the world now. Shall we call you Master Gavin and beg to lick your boots?

    \Gavin King\
    * You have contributed nothing to open source or to the open source community.
    \Gavin King\

    Gavin, I'm impressed. You've checked the entire open source community to make sure I've contributed nothing, right? Right?

    Funny...after I extensively criticized Bill Burke's TxCache, it was scrapped in favor of TreeCacheAOP. About a week after I pointed out some strange exception handling practices in JGroups, Bela mysteriously went in and made changes to exactly the code areas I pointed out. I'm an active contributor on the HOWL mailing lists (journalling system to be used by JOTM), and in some minor ways have helped out with the designs there. My "XA Exposed" articles engendered a very wide positive response, and resulted in several in-depth private conversations with both open and closed source people via e-mail - conversations where I certainly learned alot, but where also I perhaps pointed out some subtlies to others in XA handling which may help them improve their code. My two NIO articles have sparked alot of interesting discussions, and perhaps may bear some fruit in code some day.

    These are admittedly small potatoes in the grand scheme of things, and don't hold a candle to something like Hibernate. But I've tried to contribute where and how I could, even if the attempts didn't exactly take the world by storm.

    On contributing code, I've been unable to for legal reasons until very recently. Employees of large corporations may be familiar with "invention assignment" clauses in their contracts, and with the time and effort it takes to amend such clauses to get permission to work on open source work. Well, I actually took that time and effort, and can now actually release selected code out into the wild. If you want to see details, feel free to read my blog :-)

    \Gavin King\
     * You have no insight at all into JBoss Group and clearly have absolutely no idea of what you are talking about.
    \Gavin King\

    So please, Gavin, tell me where my analysis went wrong. Does your company employ more than 14 developers? Have y'all been doing magic CVS commits in a super-secret server that only you can see? If I'm wrong, I'd actually like to hear where I am wrong, and in detail.

    \Gavin King\
     * You have an opinion on everything, and, unlike a clock, you are right only about twice a month.
    \Gavin King\

    Wow, we're on a generalizing roll today. Actually, if you look closely I only hold opinions on a very small number of subjects. Check around here on TSS - I actually contribute only to a minority of the threads.

    You might want to also check out the various articles here that were triggered by my blog entries. Check them out and note that not a single flame war erupted in any of those discussions. Funny how the flames come out most often when JBossians (and a few select others) get involved....

    \Gavin King\
    * You have never stated a single opinion on /anything/ without combining it with outrageous ad hominem.
    \Gavin King\

    OK, let's keep this simple: point out where I attacked a person in the post you're responding to. Not a company - a company isn't a "hominem". Not a person's actions - a person's actions are also not a "hominem". Nor are a person's statements a "hominem".

    I also doubt you'll note the irony of ranting about my supposed personal attacks while you are quite specifically attacking me.

    \Gavin King\
    Everyone else in this particular flamewar has made significant contributions; they are all people I know and love; they all have strong technical insight, even when they disagree with each other. They are arguing because they are passionate about technology and about what they are doing in their lives. *You* argue with everyone and everything, merely to aggrandize yourself. They (and I) are sometimes intemperate. *You* are a bully.
    \Gavin King\

    If you feel that all of Rod and Bill and Marc's posts here were "significant contributions", more power to you.

    But I think you have blinders on if you think the arguments here are about technological passion. The majority of the posts on this thread (all 150 some hard, of which I have contributed _2_) have been about two things: money and ego. If you fail to understand that, Gavin, you're going to get hurt bad working for a company like JBoss Group.

    \Gavin King\
    Just Shut Up. Please.
    \Gavin King\

    Ah, I see. _I'm_ the bully here.

    \Gavin King\
    FYI, I am right /here/ in Atlanta /right now/, and believe me, this is the most exciting time of my life. JBoss business success is quite breathtaking and it is absolutely fantastic to see it rubbing off on Hibernate. A dream come true for me.
    \Gavin King\

    Congratulations. I'm happy for you, as I'm sure many people are. May I now bow down and licks your boots, Master? Please, pretty pretty please? Just a touch of the mud from your sacred boot heels on my lips will surely bless my life forever more.

         -Mike
  170. Bully-boy[ Go to top ]

    "The majority of the posts on this thread (all 150 some hard, of which I have contributed _2_) have been about two things: money and ego."

    Mike, I couldn't agree more with the comment above. Frankly your obsession with JBoss doesn't make sense coming from a person who doesn't use their product, has never personally been associated with the developers and doesn't compete with them on an economic basis. Even someone whose writing is devoted to de-bunking ego and puff, like Hani, finds far more material than just them in this community. It is hard to believe that you actually care about them making improvements in the codebase, as some of your comments suggested, given the tone you habitually use when discussing the developers and the project.
  171. Bully-boy[ Go to top ]

    \Chip Tyler\
    Mike, I couldn't agree more with the comment above. Frankly your obsession with JBoss doesn't make sense coming from a person who doesn't use their product, has never personally been associated with the developers and doesn't compete with them on an economic basis.
    \Chip Tyler\

    Who said I don't use their product? As it turns out, I'm forced to support groups within my company that are using JBoss. I am not a direct user, but I have to deal with it on a semi-regular basis, and I occaissionally have to patiently explain to some why an all JBoss solution isn't right for what they're trying to do - lack of recoverable XA being just one example. The public statements of people like Fleury and Burke make my job much harder, becuase people actually believe some of it and start clamoring for it in-house. The most effective educational tool I have in those instances is to fire up the old browser and point people to the CVS tree. "OK, here's the transaction code, here's the grand Aspect code - still think it's a good idea to use this?".

    The reality is that the combined weight of constant grand proclamations from JBossians does have an impact on people's opinions, and that sometimes filters down to someone like me who has to deal with the reality of the code, not someone's marketing speak. If posting countervailing information to counteract some of that marketing speak makes even a small difference, then to me it seems a worthwhile endeavor. And I have no problem with people choosing JBoss based on consdiered reasoning and analysis - it works just fine for some purposes. But I do have a problem with people believing the PR, and having to endure multi-month efforts to get blood from a stone.

    \Chip Tyler\
     Even someone whose writing is devoted to de-bunking ego and puff, like Hani, finds far more material than just them in this community. It is hard to believe that you actually care about them making improvements in the codebase, as some of your comments suggested, given the tone you habitually use when discussing the developers and the project.
    \Chip Tyler\

    Well, if you look around you might see that JBoss is hardly the only project I complain about :-) If you look on my blog JBoss actually isn't mentioned very much at all. But JBoss stuff is probably the most visible, because of the personalities involved. They have a special way of making my blood boil, and they in turn seem uniquely able to turn almost any discussion, no matter how bland, into a catfight. Hell, people are telling each other to piss off in this thread without me being involved at all!

         -Mike
  172. Bully-boy[ Go to top ]

    Hell, people are telling each other to piss off in this thread without me being involved at all!


    Ehm, that was just Bill telling Rod and me to piss off; noone else has told anyone else to piss off here. And despite your new-found professional attitude, you made yourself guilty of using the same level of language a while ago - remember Rod's interview from last year?

    I despise that level of offensive disrespect from *anyone*: It tells more about one's character and attitude than open source contributions or a series of articles that showcase technical expertise. For me, such a person loses all credibility in an instant.

    So don't accuse others of "money and ego" here; take a careful look at your own ego and your profound disrespect for anything that you consider unworthy first.

    Juergen
  173. Bully-boy[ Go to top ]

    \Juergen Hoeller\
    Ehm, that was just Bill telling Rod and me to piss off; noone else has told anyone else to piss off here.
    \Juergen Hoeller\

    That was only one instance. I think it's pointless to enumerate all of the flames in this 170-post thread, such as Marc's repeated two guys and their dogs things and the like, don't you?

    \Juergen Hoeller\
    And despite your new-found professional attitude, you made yourself guilty of using the same level of language a while ago - remember Rod's interview from last year?
    \Juergen Hoeller\

    Guilty as charged. Sometimes frustration and friction runs high, and heated words are exchanged.

    \Juergen Hoeller\
    I despise that level of offensive disrespect from *anyone*: It tells more about one's character and attitude than open source contributions or a series of articles that showcase technical expertise. For me, such a person loses all credibility in an instant.
    \Juergen Hoeller\

    Respect is earned, Juergen. You can't respect everyone - expecting such a thing devalues the term to the point of making it meaningless. Quite frankly I think that Rod was acting in such a manner back then that in my opinion he deserved the moniker I hung on him. Feel free not to respect me for some of the more vulgar spouting I do from time to time. At the same time, understand why others may not respect bald-faced tooting of one's horn over and over again. I'm sure there's a group of people who look down on me due to my style and the content of what I say. But please realize there's also a group who looks down on how you and Rod yell "Spring! Spring!" every 12 nanoseconds, and how JBoss Group employees shout "JBoss! JBoss!" just as often. You probably don't realize it but _alot_ of people look down on your behavior just as much as mine.

    \Juergen Hoeller\
    So don't accuse others of "money and ego" here; take a careful look at your own ego and your profound disrespect for anything that you consider unworthy first.
    \Juergen Hoeller\

    I don't disqualify myself from the ego side of the equation - I never did. I stand by the assertion that both money and ego play a part in Spring and JBoss.

    Perhaps the cognitive dissonance here is truly that yourself, and Rod, and Gavin, and others appear to be _demanding_ respect, and not understanding the difference between demanding it and earning it. You guys act like you walk on water and heal the maimed and sick because you wrote some code and released it open source.

    Or look at it another way - why should anyone respect something they feel is unworthy? Do you honestly, Juergen, go around respecting everything in the world, the good, bad, and ugly? Or do you, too, have opinions and pick and choose what earns your respect and what earns your scorn? Are you brave enough to shock the PC police and actually take a stand and criticize things you feel are deserving of it, or do you live in a happy smurfy world of veiled emotions and comfortable euphemisms?

         -Mike
  174. Bully-boy[ Go to top ]

    That was only one instance. I think it's pointless to enumerate all of the flames in this 170-post thread, such as Marc's repeated two guys and their dogs things and the like, don't you?


    Yep. But there's a difference between using language like "piss off" and calling a project team "two guys and their dog". Admitted, the latter is a flame too; but it's still a different level of offence.
     
    > Guilty as charged. Sometimes frustration and friction runs high, and heated words are exchanged.

    Granted, we are all humans. But I prefer people to stand any sort of confrontation without ever resorting to four-letter words.
     
    > Respect is earned, Juergen. You can't respect everyone - expecting such a thing devalues the term to the point of making it meaningless.

    There's a level inbetween: You can respect someone, explictly disrespect someone, or simply not bother. Offensive disrespect - even including four-letter words - when you really shouldn't bother is despisable, IMHO. Bill has joined you in that club.

    > But please realize there's also a group who looks down on how you and Rod yell "Spring! Spring!" every 12 nanoseconds, and how JBoss Group employees shout "JBoss! JBoss!" just as often. You probably don't realize it but _alot_ of people look down on your behavior just as much as mine.

    Point taken that we do our share of marketing; still, there's more substance to our Spring claims than you would ever admit. I don't think that we deserve to be thrown into the same bucket as JBoss though, not in terms of substance and particularly not in terms of style. You may disagree, of course; I don't care.

    Of course, you can choose to despise marketing of a particular product - you're free to do so. But don't compare this with personal affronts and throwing four-letter words at people in technical forums; this is a completely different sort of offence.

    > I don't disqualify myself from the ego side of the equation - I never did. I stand by the assertion that both money and ego play a part in Spring and JBoss.

    Surprise surprise, money and ego play a part in everything that goes on in this world of ours. Good to see that you include yourself here, at least.
     
    > Perhaps the cognitive dissonance here is truly that yourself, and Rod, and Gavin, and others appear to be _demanding_ respect, and not understanding the difference between demanding it and earning it. You guys act like you walk on water and heal the maimed and sick because you wrote some code and released it open source.

    Include yourself in that equation too. Frankly, you leave a similar aftertaste when you try to give the impression of saving the world from oh-so-false marketing claims. And from oh-so-broken XA implementations - note that you may be right in that respect (I'm no expert there), but so may we in our affairs.

    > Or look at it another way - why should anyone respect something they feel is unworthy? Do you honestly, Juergen, go around respecting everything in the world, the good, bad, and ugly? Or do you, too, have opinions and pick and choose what earns your respect and what earns your scorn?

    You don't need to respect something you feel is unworthy; it's your opinion after all. I just prefer to refrain from offensive disrespect in that case; a matter of modesty and politeness - traits that do not show up in your personality. As I indicated, there's more than black and white.

    Juergen

    P.S.: I'm outta here. I think everything that's relevant has been said here or in earlier threads that degenerated like this. Thanks for listening, anyway.
  175. Bully-boy[ Go to top ]

    But please realize there's also a group who looks down on how you and Rod yell "Spring! Spring!" every 12 nanoseconds


    A quick point - I think you'll find more often than not that Spring gets brought up not by Rod or Juergen, or any of the Spring dev team necessarily, but by developers who (like myself) use Spring daily and find it *highly* valuable. Just check for the first mention of Spring in this thread for example.

    Spring is not being hyped up by its developers to the extent that is made out in this forum - rather it is being advocated by people with positive experiences of it.
  176. Bully-boy[ Go to top ]

    The most effective educational tool I have in those instances is to fire up the old browser and point people to the CVS tree. "OK, here's the transaction code, here's the grand Aspect code - still think it's a good idea to use this?".


    I am starting to use that method too. The other day I told a guy here that the JBoss TM doesn't have a redo log. It definitely had an impact.

    What I don't like, again, is that they are not up front about this stuff. They take care of marketing first and implementation later. There should be a big sign on the jboss web site that says DO NOT USE IF YOU USE DISTRIBUTED TRANSACTIONS.
  177. Bully-boy[ Go to top ]

    Spille Wrote:
    > \Gavin King\
    > Mike Spille, please go away.
    > \Gavin King\
    >

    No, don't go away, just admit to having a personal agenda. You should learn something from Cameron. He is critical, yet fair.

    > I wasn't aware that TSS was by invitation only, and that you were the gatekeeper. Lots of people love your product, Marc F pays you to do what you love, and even buys you a plane ticket to fly from Australia to Atlanta, so I guess you feel you're about king of the world now. Shall we call you Master Gavin and beg to lick your boots?
    >
    > \Gavin King\
    > * You have contributed nothing to open source or to the open source community.
    > \Gavin King\
    >
    > Gavin, I'm impressed. You've checked the entire open source community to make sure I've contributed nothing, right? Right?
    >

    ROTFL! Here we goes the Great Spille!

    > Funny...after I extensively criticized Bill Burke's TxCache, it was scrapped in favor of TreeCacheAOP.

    ROTFL! Now who is making the big claims or overstating themselves! My TxCache was scrapped because of Mike Spille. WOW! Did you ever think it was because that somebody finally volunteered to implement what we wanted to implement? No, it must have been because you exposed me for the fraud I am.

    >About a week after I pointed out some strange exception handling practices in JGroups, Bela mysteriously went in and made changes to exactly the code areas I pointed out.

    Wow! You pointed out a bug and Bela fixed it! You are so special Mike. If I had a Lira for every bug somebody pointed out in our codebase, I would be rich. If I had a dollar for every bug somebody actually posted a patch for, I would be just as rich. Your "help" is worth a Lira.

    > I'm an active contributor on the HOWL mailing lists (journalling system to be used by JOTM), and in some minor ways have helped out with the designs there.

    I remember back in the old days when on the JBoss dev lists people were talking about how clustering should be implemented and what would be the best solution and such. People saying HOW it should be done were numerous. A dime a dozen. The one rarity was Sacha Labourey who actually implemented a working prototype. One person out of tens of HOWs. We have plenty of people telling us HOW we should do things, but rarely do we have somebody step up and DO IT. These are the special people. These are the people that deserve attention. JBoss, Hibernate, Spring, Pico, etc... deserve critique, deserve comparisions, because, well, they are actually trying to do something. You, on the other hand...well......

    > My "XA Exposed" articles engendered a very wide positive response, and resulted in several in-depth private conversations with both open and closed source people via e-mail - conversations where I certainly learned alot, but where also I perhaps pointed out some subtlies to others in XA handling which may help them improve their code. My two NIO articles have sparked alot of interesting discussions, and perhaps may bear some fruit in code some day.
    >

    Dime a dozen. Doers are needed in open source. As somebody (Arun?) said, open source needs doers not architechs that are allergic to code.


    > These are admittedly small potatoes in the grand scheme of things, and don't hold a candle to something like Hibernate. But I've tried to contribute where and how I could, even if the attempts didn't exactly take the world by storm.
    >
    > On contributing code, I've been unable to for legal reasons until very recently. Employees of large corporations may be familiar with "invention assignment" clauses in their contracts, and with the time and effort it takes to amend such clauses to get permission to work on open source work. Well, I actually took that time and effort, and can now actually release selected code out into the wild. If you want to see details, feel free to read my blog :-)
    >

    LOL. You sound like Rickard and his AOP framework. "My AOP framework is so much better than everybody else's, but unfortunately, I can't release it."

     [snip]
    > \Gavin King\
    > FYI, I am right /here/ in Atlanta /right now/, and believe me, this is the most exciting time of my life. JBoss business success is quite breathtaking and it is absolutely fantastic to see it rubbing off on Hibernate. A dream come true for me.
    > \Gavin King\
    >
    > Congratulations. I'm happy for you, as I'm sure many people are. May I now bow down and licks your boots, Master? Please, pretty pretty please? Just a touch of the mud from your sacred boot heels on my lips will surely bless my life forever more.
    >

    You would never be able to get close to Gavin's boots because they would be too far up your ass.

    Bill
  178. Bully-boy[ Go to top ]

    \Bill Burke\
    No, don't go away, just admit to having a personal agenda. You should learn something from Cameron. He is critical, yet fair.
    \Bill Burke\

    My main "agenda" is finding out what code actually does, as opposed to what people say it does. JBoss has a quite horrible record on that score. When your code matches your words, then I'll stop being critical.

    \Bill Burke\
    ROTFL! Here we goes the Great Spille!

    [...]

    ROTFL! Now who is making the big claims or overstating themselves! My TxCache was scrapped because of Mike Spille. WOW! Did you ever think it was because that somebody finally volunteered to implement what we wanted to implement? No, it must have been because you exposed me for the fraud I am.

    [...]

    Wow! You pointed out a bug and Bela fixed it! You are so special Mike. If I had a Lira for every bug somebody pointed out in our codebase, I would be rich. If I had a dollar for every bug somebody actually posted a patch for, I would be just as rich. Your "help" is worth a Lira.

    \Bill Burke\

    I make no claims to greatness. As I said in my post "These are admittedly small potatoes in the grand scheme of things, and don't hold a candle to something like Hibernate. But I've tried to contribute where and how I could, even if the attempts didn't exactly take the world by storm". There was no irony or sarcasm intended there - it's literal truth.

    When I see something that looks wrong to me, I point it out. This apparently really, really pisses you off. I don't think I'm changing the face of open source, or should be celebrated or have the tag "Greatness" associated with my name - if you read your own posts, Bill, you'll find that such bravado and egotism is your specialty and that of your JBoss brethren.

    \Bill Burke\
    I remember back in the old days when on the JBoss dev lists people were talking about how clustering should be implemented and what would be the best solution and such. People saying HOW it should be done were numerous. A dime a dozen. The one rarity was Sacha Labourey who actually implemented a working prototype. One person out of tens of HOWs. We have plenty of people telling us HOW we should do things, but rarely do we have somebody step up and DO IT. These are the special people. These are the people that deserve attention. JBoss, Hibernate, Spring, Pico, etc... deserve critique, deserve comparisions, because, well, they are actually trying to do something. You, on the other hand...well......
    \Bill Burke\

    Yes, Bill, I understand. You guys are the special people. I am dirt, nothing, and a pig wallowing in the mud. All of my contributions are pathetic and laughable. I'll try to remember from now on who the Special People are, and that us poor, sorry idiots should be doing nothing but kissing your asses.

    \Bill Burke\
    Dime a dozen. Doers are needed in open source. As somebody (Arun?) said, open source needs doers not architechs that are allergic to code.
    \Bill Burke\

    OK, Bill, I guess 99% of the developers on the planet who aren't Special People should pack it in and let you Special People work their magic.

    \Bill Burke\
    LOL. You sound like Rickard and his AOP framework. "My AOP framework is so much better than everybody else's, but unfortunately, I can't release it."
    \Bill Burke\

    LOL - there wouldn't be a JBoss without Rickard (but I believe JBoss would get along just fine without a Bill Burke). In any case, as I mentioned I am releasing code as open source, mostly NIO related and maybe transaction log related as well. I rather doubt that anyone will confuse this sort of thing with putting together an entire application server, but it fits what I know and the time I have available. If you want to criticize it, ridicule it, or print it out for toilet paper when I release it, knock yourself out.

    \Bill Burke\
    You would never be able to get close to Gavin's boots because they would be too far up your ass.
    \Bill Burke\

    He must be a very pleasant fellow to work with by that description!

         -Mike
  179. Bully-boy[ Go to top ]

    \Bill Burke\

    > You would never be able to get close to Gavin's boots because they would be too far up your ass.
    > \Bill Burke\
    >
    > He must be a very pleasant fellow to work with by that description!

    I was always fond of Hibernate because of its apparent focus on performance. I never got a chance to try it. Now that I see what kind of people Gavin is associating with, I would spend considerable time find reasons not to use Hibernate.

    The effects of this JBoss-Hibernate venture are already taking shape.
  180. Bully-boy[ Go to top ]

    One quick comment on "Mike the Bully" and this whole flame-war. Mike and I had our own little war a couple months ago and I took offense to a few things Mike said. Mike responded "It wasn't meant as an attack, although I understand how it might read that way." which I considered enough "apology/acknowledgement" to end the "war" at that point, and we continued with the more technical discussion. I do find Mike "inflammatory" but he's not often "offensive" barring a few incidents (and I've done those myself). I think of Mike like Don Cherry (for any Canadians on the board) - loud and knowledgable (this isn't meant as a flame Mike :) ). It would be nice if someone would have the guts to do what Mike did and say "I stepped unintentionally stepped out of bounds, sorry, lets get back to business". Just my 2 cents (1.6 cents US).

    <Bill Burke>
    Dime a dozen. Doers are needed in open source. As somebody (Arun?) said, open source needs doers not architechs that are allergic to code.

    LOL. You sound like Rickard and his AOP framework. "My AOP framework is so much better than everybody else's, but unfortunately, I can't release it."
    </Bill Burke>

    It does take somebody extra-special to do the real coding (like Juergen with Spring - thanks), but without the armchair architects/users you wouldn't explore the various ideas fully enough to implement them in the best way. As good as a single mind might be, they're never perfect. If it weren't for real-user feedback (from people who may never contribute to the project), Spring wouldn't be what it is today.

    As far as not being able to release code, lots of us are in that boat. A year ago, I was able to actively participate with Spring in both the discussion and code contribution. Due to time constraints with work, that fell to just list participation and recently I've mainly just been lurking (with the desperate desire to contribute some code once work calms down). It takes all kinds: "special" key contributors, part-time/periodic contributors, and those who just inject comments/ideas (both good and bad). To discount someone as unworthy simply because they don't actively submit code is to destroy the community MOST oss projects are striving to create. There are only about a dozen contributors for Spring with only a few being extremely active, but the target market is not "Spring developers" but "developers who use Spring".

    You can think what you want about "lowly users", we welcome them.

    Trevor D. Cook
  181. Bully-boy[ Go to top ]

    Trevor, thanks for the comments.

    I can be inflammatory at times. I try to keep it toned down, but sometimes it just pops out anyway. And sometimes you can cross over that invisible line during a discussion, often without even realizing it - and yet there's still useful technical bits that can and should be said. I've made a few apologies and outright retractions in my time, and they're painful, but it's worth it.

    But true offensiveness, as opposed to crossing that subtle line, most often happens when one party isn't communicating, they're just spouting a pre-prepared speech and are obviously uninterested in alternate viewpoints or exchanging information - and the other side just gets fed up.

    In this thread and a few others, several parties aren't trying to hold a technical discussion. They're totally disinterested in opposing viewpoints. When presented with pretty concrete information which contradicts what they're saying, they're not interested in pursing the discrepancies, or perhaps trying to find a point of misunderstanding - they get pissed that someone is interrupting their marketing spiel.

    Oh, I know some people consider me offensive. But I do try to be accurate, and I admit it when I screw up. For several individuals on this thread, try to find one instance where they said "Oh, I was wrong". I've tried, and haven't found any. The flaming core of many of these wars is really rooted, I believe, in a few select individuals who are incapable of admitting error, and will in fact do _anything_ to avoid such an admission.

    \Trevor Cook\
    It does take somebody extra-special to do the real coding (like Juergen with Spring - thanks), but without the armchair architects/users you wouldn't explore the various ideas fully enough to implement them in the best way. As good as a single mind might be, they're never perfect. If it weren't for real-user feedback (from people who may never contribute to the project), Spring wouldn't be what it is today.
    \Trevor Cook\

    I agree, and I look at Linux as one of the better models of this. The grand coders of Linux gave it its heart and soul, but it's the thousands of people contributing little patches and reports like "hey, linux crashes on my XYZ box in this environment", or the guy who contributes a little driver here and there, that have made its use so wide spread. And the steady, almost plodding, developers who do the unsexy bits like installers and the like that give it the extra polish that makes it truly high-quality software.

    In stark contrast, Marc and Bill have repeatedly dissed everyone but the elite core commiters in public. They do everything but spit on their little cadre of insiders. Even worse, they actively hide problems instead of getting them out into the open. They are the most "closed" open source software I've come across.

    For anyone who wants to really experience frustration, read the repeated writings of JBoss people gushing about AOP and Aspect work, and watch zero activity in the CVS tree for 5 months or so. That's frustrating - you hear someone talking about how some technology's going to rule the world, and you see that no actual work has been done on it for half of a year. It's very tough to be level headed and polite when you _know_ the slick salesman in front of you is very politely telling you a pack of lies.

    \Trevor Cook\
    As far as not being able to release code, lots of us are in that boat.
    \Trevor Cook\

    Time is definitely a big issue. In my case, legalities are an even bigger problem. I'm sure Bill will scoff at this, but in my "default" employee status literally any code I write belongs to the company (and they do _not_ have an open source policy). If, prior to January 2004, I went out writing open source in my free time, I'd be jeopardizing the projects I worked on. I'd be releasing it as open source without being the legitimate owner of the code. I personally was motivated enough to get involved with open source to tackle my company's bureacracy over a two month time span. And finally, the effort has paied off, and SIAC has granted me permission to persue certain open source projects and to retain ownership of my own works in those instances. Bill can make fun of it all he wants, but conservative firm with thousands of employees are _not_ very amenable to new-fangled ideas like open source.

        -Mike
  182. Bully-boy[ Go to top ]

    To Trevor:
    Trevor, I think you misinterpreted my statements. I was strictly talking about development, not users. In most projects (open source and commercial) you have many many people with voices that talk about what should be done. In open-source, it is rare for somebody to step up and actually DO what SHOULD be done. (Commercial world is different because your boss can tell you what to do.).

    /Spille/
    LOL - there wouldn't be a JBoss without Rickard (but I believe JBoss would get along just fine without a Bill Burke).
    /Spille/

    I disagree and agree. There would be a JBoss without Rickard. Marc gives Rickard too much credit. Orbix2000's architecture (at Iona), was similar (and better). They had a kernel, interceptors, etc. A microkernel or interceptors are not exactly new technology even back when Rickard was here. JBoss has gotten along without Rickard for years as Rickard left at the 2.0 stage.

    As far as JBoss would get along just fine without Bill Burke, well, honestly, I agree. I'm no more than a productive coder that is passionate about the technology I work with.

    Bill
  183. Bully-boy[ Go to top ]

    \Bill Burke\
    Trevor, I think you misinterpreted my statements. I was strictly talking about development, not users. In most projects (open source and commercial) you have many many people with voices that talk about what should be done. In open-source, it is rare for somebody to step up and actually DO what SHOULD be done. (Commercial world is different because your boss can tell you what to do.).
    \Bill Burke\

    In either the closed or open source world, you certainly need "doers" who bang out code. The problem, which I think you fail to see, is that the doers do not always bang out the best code for the situation at hand. I know lots of people, closed and open, who can write lots of code that mostly works. And even for people who primarily write lots of good code that's appropriate to the situations at hand, everybody has a bad day (or even a bad year :-/).

    The true value of open source is people beyond the "doers" can look at the code and offer alternatives. Maybe it's another "doer" who comes in and does a re-write. Maybe someone alters a patch. Or maybe it's someone on the dev list, or a forum, or a blog, who describes an issue with a module or component and offers suggestions on how to do it better.

    True, there are always cranks who just spit out worthless "suggestions". But buried in the cranks are some highly knowledgable people who have information of value to contribute.

    Good open source leaders have the patience to listen to suggestions. They can recognize the cranks and politely pat their heads but otherwise ignore them. They can recognize experts who might have a valuable insight. And they can even recognize the inbetweeners - people who may not seem to have much of worth to say, but once in awhile have a blinding insight that no one else has seen.

    These sort of leaders take the time to answer questions, to regularly read the development lists and forums, to troll the 'net in general for new viewpoints. Above all, their honest about their own flaws, and realize that someone might be able to help a certain design jump from OK to really, really good.

    The majority of people involved in JBoss development these days - the leaders and "doers" - in my opinion show none of these traits. Y'all seem to think the nine or so guys doing development are the sufficient to create truly great software by yourselves. You've seen a number of cranks, and have made the critical mistake of assuming that since there are alot of cranks out there, everybody is a crank.

    You abuse people on forums. People offer bug reports and even potential code fixes, and you let those messages just sit unresponded to indefinitely. People develop entire systems that define the state of the art in a given field, and you plain _ignore_ them (e.g. you personally show only the shallowest understanding of AspectJ, and yet think you can create a state of the art AOP system on your own without understanding how true experts who have been doing it for years have approached the problem). You get pissy if someone offers a suggestion on a forum like TSS, and refuse to answer them because it's not on the official JBoss forums (which is a double joke - you won't answer here, and have stated publically that you hate JBoss forums and so almost never venture there, either).

    The real underlying issues are two fold - lack of patience, and out of control hubris.

    JBossians as a rule have no patience to listen to anyone, to take the time to stop and understand. With the exception of Bela, nobody on the team has the patience to do design - you just _have_ to start banging out code right away. There's no concept of making code work first, announcing it later - the minute it passes compilation and a 20 line unit tests passes, out comes the grand announcement. No patience, everything now now now, and a vague promise that someday, real soon now, it'll all pull together. Even in the Geronimo/JBoss copyright debacle, there was no patience shown in understanding the two code bases and all of the ownership issues involved - just bang out some diffs, see some vague similar names, see that Marc hung his name on something, and out goes the legal letter.

    Even on TSS - no time is taken to actually read all the posts in a thread. A Jbossian sees his name, scans the offending post over 30 seconds, and then furiously types out a reply without having a clue what the surrounding context was.

    The hubris side is, ahem, rather obvious and I don't think needs any further belaboring.

    With some patience and alot less ego, JBoss could be a great product - as opposed to a large amount of code banged out in quick spurts that mostly works.

         -Mike
  184. Bully-boy[ Go to top ]

    \Bill Burke\

    > Trevor, I think you misinterpreted my statements. I was strictly talking about development, not users. In most projects (open source and commercial) you have many many people with voices that talk about what should be done. In open-source, it is rare for somebody to step up and actually DO what SHOULD be done. (Commercial world is different because your boss can tell you what to do.).
    > \Bill Burke\
    >
    > In either the closed or open source world, you certainly need "doers" who bang out code. The problem, which I think you fail to see, is that the doers do not always bang out the best code for the situation at hand. I know lots of people, closed and open, who can write lots of code that mostly works. And even for peoplw who primarily write lots of good code that's appropriate to the situations at hand, everybody has a bad day (or even a bad year :-/).
    >

    You have to multiply zero by a very big number to get 1. Until a piece of code is written you have nothing that works.

    > The true value of open source is people beyond the "doers" can look at the code and offer alternatives. Maybe it's another "doer" who comes in and does a re-write. Maybe someone alters a patch. Or maybe it's someone on the dev list, or a forum, or a blog, who describes an issue with a module or component and offers suggestions on how to do it better.
    >

    I agree with all of what you are saying about the true value of open source. But I'm saying that in open source that are two orders of magnitude of people that offer alternatives versus those who actually implement the alternatives.

    >
    > JBossians as a rule have no patience to listen to anyone, to take the time to stop and understand.


    No, actually, its just you Mike.

    > With the exception of Bela, nobody on the team has the patience to do design - you just _have_ to start banging out code right away.

    Yes, JBoss is just a mess of undesigned, crappy code. Only Bela has designed something good. The rest of us are a bunch of hacks while the "good" ones left for Geronimo.

    > There's no concept of making code work first, announcing it later - the minute it passes compilation and a 20 line unit tests passes, out comes the grand announcement.

    Now this is funny. How is this any different from Geronimo? At least this JBoss code you talk about has at least one unit test that works. It is at least downloadable and runnable if even in the most simplest examples. When did we ever state that JBoss 4 last June was anything more than a Developer Release? We put a stake in the ground of what we were doing with AOP and what pre-packaged aspects we were writing. The responses we got on TSS and "BLog land" (or should I say Ego Land) were as expected.

    Instead of stating, "you don't listen to any feedback", you should go back and review the history. Rickard in his blog trashed us on performance. Jonas Boner trashed us for not having finer-grained pointcuts. Both were addressed in DR2 as performance improved an order of magnitude, and pointcut expressions expanded. Gregor suggested we separate pointcut definitions from advice bindings and we are implementing this now. So, to state that we don't listen to feedback is false. Now, if you revise your statement to "you don't listen to any of MY feedback", then sure that is true, as I wouldn't exactly call your posts feedback.


    >
    > With some patience and alot less ego, JBoss could be a great product - as opposed to a large amount of code banged out in quick spurts that mostly works.
    >
    > -Mike

    The above should be revised to "JBoss will never be a great product until I, Mike Spille, says it so."

    Bill
  185. Bully-boy[ Go to top ]


    > The above should be revised to "JBoss will never be a great product until I, Mike Spille, says it so."

    You know, I've stayed out of this whole flamefest, but this has gotten old now.

    Bill, lots of us have had quality, management, and lack of documentation issues with JBoss. We tried to use it a couple of years ago during the release candidate phase of 3.0, and eventually abandoned it due to the issues. I'm sure it's gotten better, but I think we'd all feel better if you just ADMITTED THERE ARE ISSUES.

    I admit that Mike can be abrasive, as can we all, but he's at least brought up valid technical issues. I haven't heard you answer or discuss any technical issues, just resorted to name calling and bringing up old arguments. I think if you've got such a good story to tell, technically, then just stick to that and drop the attitude.

    As far as your attacks on Spring, I think you're really REALLY missing the point. Let's imagine I'm an ISV that has to support more than one application server (oh, wait, I work for such a beast). Now, am I going to want to build my application around JBoss? You think I want to try to bring pieces of JBoss into WebLogic and WebSphere? Especially when noone else is doing this? I'm actually impressed by the examples you can give of EAGames and the network switching app, but we're not all building these kind of single-user applications where we get to define the runtime environment.

    Plus, I'm unimpressed with your discussion of the JMX microkernel for the core of an application. It doesn't seem like it would scale down for small applications, and seems too heavyweight for the general case. Better, I think, to be able to add JMX as an optional service on top when I need it.

    Even your examples show that Spring is just more straightforward and easier to understand, just by looking at the configuration files.

    Bill, I think it's time to admit when others might have a point.
  186. Bully-boy[ Go to top ]

    \Bill Burke\
    You have to multiply zero by a very big number to get 1. Until a piece of code is written you have nothing that works.
    \Bill Burke\

    I'm not seeing this as a binary yes or no proposition. As I said in my previous post, "you certainly need doers who bang out code". I think we actually agree there - but it's also where your viewpoint seems to mostly stop.

    Open source projects always have a small core of people who write the great majority of the code. This is so obvious that it almost doesn't bear mentioning. But you get little or no "open source benefit" from this sort of model - a small core of productive indivudals doing closed source will accomplish about the same as a small core of productive individuals doing open source. Where the true benefits of open source come into play is the hundreds of thousands of people who can offer small patches, and insights into the code, but for one reason or another aren't writing tons of code. All of those people's little patches and suggestions add up to take a code base from mostly good to being very comprehensive.

    I'll use Linux again as an example. If Linux stuck primarily to its core developer base, you'd have a very nice OS core. But Joe Schmoes in various environments would try it out, find it crashes on their machine, or is unsuitable for their requirements, and then just write it off. People would say, "Yeah, Linux is great if you're running on this tiny list of hardware, and you're only trying to do XYZ like the core guys are".

    As it is, Linux isn't great solely because of the core developers. It's not great solely because of the mass of people contributing little bits, either in code or information or suggestions. It's the combination of the two groups, acting in concert and iterating endlessly that makes Linux as wide spread and widely applicable as it is today. The core guys provided the core, all the other people rounded out the corners to take it from a niche product to something with a wide range of uses.

    Now look at JBoss. It is plain that the core team has written alot of code, and that code is useful in a range of applications. But it's not really all that wide of range. The corners are largely unfilled. There are tons of people who try out JBoss in their own environments, and find out _for their needs_, and for _their environments_, JBoss is either lacking a feature or is throwing a confounding exception. The end result is that JBoss, as I described, "mostly works", just like Linux many years "mostly worked". So long as an end user's needs and goals and environments largely coincide with what the core developers were aiming for, all is well. Diverge, and you see enough problems that it's not worth the effort.

    \Bill Burke\
    I agree with all of what you are saying about the true value of open source. But I'm saying that in open source that are two orders of magnitude of people that offer alternatives versus those who actually implement the alternatives.
    \Bill Burke\

    I believe you miss the point. The weight of code people contributes means nothing to the end user. All that matters is what the end product does, and if it fits peoples' needs. The problem is that, taken as an aggregate, all the little corner cases cover a huge number of people. Your team might write a million lines of code this year, but if it doesn't cover the corners - if it's not polished - it won't matter all that much. All of your efforts come to naught if someone finds JBoss doesn't work for them. In the end, nine guys, or whatever, can only do so much. They may provide the bulk of the core functionality, but they physically can't round out all the corners and provide all the polish that end users expect of enterprise solutions these days.

    Where you see the value in open source is when you have a group of doers doing the heavy lifting, and scores upon scores of other people rounding out those corners and adding that polish, either through patches, or through suggestions and comments on the existing source.

    What you don't get is that it only takes one missing feature, or one critical bug, most likely in a corner area that the core hasn't the inclination or time to address, to sour someone on a product. Look on your own forums for endless examples. The gross examples are easy - "No recovery log for XA transactions, that's a show stopper for me. "The JMS impl is weak, I don't care about everything else". Etc. Etc. The more subtle examples lose far more people, though. And nine guys can't address all that. You need the larger community to fill out all the niches that the core team can't.

    \Bill Burke\
    No, actually, its just you Mike.
    \Bill Burke\

    Well, this is quite simple to test. Look at all the JBoss mailing lists, JBoss.org forums, and other places like here where I have not interacted, and see what the results have been. Despite what people like Andy O. have to say, I am not quite as ubiqutious as some believe. There are lots of places where I have had no presence where an almost complete lack of patience has been exhibited by JBossians.

    \Bill Burke\
    Now this is funny. How is this any different from Geronimo? At least this JBoss code you talk about has at least one unit test that works. It is at least downloadable and runnable if even in the most simplest examples. When did we ever state that JBoss 4 last June was anything more than a Developer Release? We put a stake in the ground of what we were doing with AOP and what pre-packaged aspects we were writing. The responses we got on TSS and "BLog land" (or should I say Ego Land) were as expected.
    \Bill Burke\

    The differences between the two projects - Geronimo and JBoss 4.0 - are quite striking. I don't think anyone has confused Geronimo with a finished product in any sense of the word. It is quite obviously an initial development, pre-alpha effort.

    Let's look at JBoss 4.0 in contrast. In case you haven't noticed, Marc Fleury _very_ often talks of JBoss 4.0 in the present tense. He goes on and on about the what your team has accomplished in JBoss 4.0. He makes a press release about JBoss cache when it's still pretty rough (it has potential, but even calling it beta is a long stretch to me).

    The telling part is where you say "The responses we got on TSS and 'BLog land' (or should I say Ego Land) were as expected". I have to laugh when I read that. Most organizations, closed or open, take steps to make sure that they're not opening themselves up to unnecessary criticism. This does not mean that you tailor your approach to your critics - that would be really crazy. But it does mean that you listen to them, and see if maybe there's a kernel of truth in what's being said. If you're at a point where any time you make a release you expect a hail of negative criticism to follow, maybe you should listen to that criticism and see if there might not be some simple steps that could be taken to avoid the bulk of it. Maybe, just maybe, the approach you're taking isn't the best. And maybe, just maybe, if you stopped and listened, really listened, you might find that there may be some valid ideas on how to better deliver a product that would silence those critics once and for all.

    \Bill Burke\
    Instead of stating, "you don't listen to any feedback", you should go back and review the history. Rickard in his blog trashed us on performance. Jonas Boner trashed us for not having finer-grained pointcuts. Both were addressed in DR2 as performance improved an order of magnitude, and pointcut expressions expanded. Gregor suggested we separate pointcut definitions from advice bindings and we are implementing this now. So, to state that we don't listen to feedback is false. Now, if you revise your statement to "you don't listen to any of MY feedback", then sure that is true, as I wouldn't exactly call your posts feedback.
    \Bill Burke\

    I think it would be more accurate to say that there were holes that were so large in DR1 that they had to be addressed. You weren't meeting the bare minimum requirements. To draw an analogy, if an RDBMS system had crippled support for "select" statements, or was running at 3 transactions per second, well you'd obviously just have to change that. Likewise, DR1 was so far behind every other AOP implementation on the planet that you had no choice but to change.

    On the more subtle issues that are not absolute deal breakers, the JBoss developers have been far more, shall we say, resistant to advice. As I said, the mentality is "mostly works". DR1 didn't mostly work, it barely worked (this isn't a criticism - I accept that it was a DR1 release).

    Now you're rapidly approaching the "mostly works" phase, and based on past performance it seems highly unlikely that you're going to ever get to the "works" phase. It's far more likely that "mostly works" will be sufficient, and development efforts will shift to some other hot spot that Marc want's to highlight a year from now.

    \Bill Burke\
    The above should be revised to "JBoss will never be a great product until I, Mike Spille, says it so."
    \Bill Burke\

    I am hardly alone in my criticism. The consensus on JBoss 4.0 that I have seen in the industry is that it's largely vaporware, and will likely remain so for quite some time.

         -Mike
  187. Bully-boy[ Go to top ]

    Ack - where I said "hundreds of thousands" I meant "hundreds _or_ thousands".

        -Mike
  188. Bully-boy[ Go to top ]

    The differences between the two projects - Geronimo and JBoss 4.0 - are quite striking. I don't think anyone has confused Geronimo with a finished product in any sense of the word. It is quite obviously an initial development, pre-alpha effort.


    I had never bothered to look at Geronimo, so I took a quick look. It looks very open, and seems to have the right kind of approach. I was pleased to see that they don't have a picture of a data center on their web site, which means that they leave it to the user to see if they like the product or not. And they are not hiding the products' features behind proprietary documentation.

    Most of all, I am starting to wonder if a BSD-style license might not be the only viable license for a J2EE product. With J2EE you can't escape the fact that there is a company that can make or break your product (Sun.) I think the certification process goes agains the GPL. I like the GPL better but then it's probably better not to support EJBs.

    I wouldn't be surprised if Geronimo became the default app server for J2EE (eventually) and JBoss stopped supporting J2EE and ended being more original. IMHO it wouldn't be a bad scenario. Then Marc can knock himself out ...
  189. a modest proposal[ Go to top ]

    Excuse me Bill, just want to check what Mike said about "out of control hubris".

    I hope you don not really think you are up to the class of Richard Öberg, Juergen Mueller, Rod Johnsson or Mike Spille do you? Because if you do you are victim of a serious delusion!

    Without seeing *any* code at all, just by reading your posts and Mike's it is pretty obvious to a neutral observer which one is that is the intelligent one! He is the master - you are the student. So a more humble attitude would definitely suit you better.. And when you’re at it, take a trip to http://www.artima.com/intv/anders.html

    and read another master, Anders Hejlsberg. So you can have two role models - father figures so to speak - to look up to.

    Regards
    Rolf Tollerud
  190. a modest proposal[ Go to top ]

    [ROTFL]

    Well played, Rolf. I do have some ego problems of my own to wrassle with.

        -Mike
  191. a modest proposal[ Go to top ]

    Excuse me Bill, just want to check what Mike said about "out of control hubris".

    >
    > I hope you don not really think you are up to the class of Richard Öberg, Juergen Mueller, Rod Johnsson or Mike Spille do you? Because if you do you are victim of a serious delusion!
    >
    > Without seeing *any* code at all, just by reading your posts and Mike's it is pretty obvious to a neutral observer which one is that is the intelligent one! He is the master - you are the student. So a more humble attitude would definitely suit you better.. And when you’re at it, take a trip to http://www.artima.com/intv/anders.html
    >
    > and read another master, Anders Hejlsberg. So you can have two role models - father figures so to speak - to look up to.
    >
    > Regards
    > Rolf Tollerud

    Rolf, personally, I could care less whether I am well below, above, or equal to any of the "gods" you listed.

    I saw an interview of Jim Lehrer once. He stated that once he got past that he wasn't always going to be the most talented or intelligent writer, that there always will be somebody smarter than him, is when his career started taking off. That there were a lot of more talented people than him capable of writing better books, but far less people willing to actually write the book. This is the approach I take to life.

    To sound corny, paraphrase Morpheus, there's a difference between knowing the path and walking the path.

    Bill
  192. Bully-boy[ Go to top ]

    FYI, I am right /here/ in Atlanta /right now/, and believe me, this is the most exciting time of my life.

    And that is just the ride to work! (I go to Atlanta with my wife for her business.)

    BTW, Gavin, much thanks to your input to OSS.
  193. Gavins blog entry[ Go to top ]

    http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/02/05#pigs
  194. New to EJB[ Go to top ]

    Hi everyone,

    I'm new to the EJB. I just started to read some books on it.
    Reading the posting on the forum is very interesting, because
    I can get an opinion from people who really using the J2EE and EJBs
    in particular. On the other hand it is very confusing, because it looks
    like that nobody is really happy with the technology.

    We have a new project coming up and I was planning to use EJBs. After reading your messages I have some doubts. Should I start using EJBs or wait until
    the new spec will come and hope that it will better than the current one?

    The suggestion from experienced people like you would be very valuable.

    Thank you very much.
  195. New to EJB[ Go to top ]

    Hi Leonid,

    Ask yourself a simple question: why do you plan to use EJBs on your new project ? It all depends on your answer really.

                    Yann
  196. New to EJB[ Go to top ]

    We have a new project coming up and I was planning to use EJBs. After reading your messages I have some doubts. Should I start using EJBs or wait until

    > the new spec will come and hope that it will better than the current one?

    My two cents:

    A) If the application is large and complex and you can't escape having a large team, then you might consider using EJBs because of staffing reasons. If you get on the bandwagon, then you will find plenty of people to hire, because those people are on the same bandwagon. A similar case would be if you are a consultant and want to make it easy to find a replacement for yourself. In that case it's good for your client if you write boring rather than original code.

    B) If you want to use EJBs in order to put it on your resume that's also a plausible reason. If that's the case then you probably will no regret using EJBs.

    C) If you are writing an application by yourself or in a very small team, maybe with a small budget or short time constraints, and therefore require really high productivity, then you should consider the problem from the top down.

    D) You may want to choose EJBs if you want to use some app server's features which are most easily (or only) available through EJBs, e.g. entity beans on a cluster with multicast invalidation.

    E) If you are using JMS queues, then MDBs are definitely worth it.

    Other than that it's worth mentioning that JTA is the really critical standard that you want to use, because it allows to associate threads with transactions, so you don't have to pass java.sql.Connection objects around your persistence code, and also allows 2-phase commits if you want to put in a JMS queue and/or resource managers.
  197. New to EJB: Thanks for help[ Go to top ]

    Thanks you very much to all of you. Your sugestions really help.

    To better understand what is the project:

    >A) If the application is large and complex and you can't escape having a large >team, then you might consider using EJBs because of staffing reasons. If you >get on the bandwagon, then you will find plenty of people to hire, because >those people are on the same bandwagon. A similar case would be if you are a >consultant and want to make it easy to find a replacement for yourself. In >that case it's good for your client if you write boring rather than original >code.

    The project is small to mid size and not to complex. I'm an employee.

    >B) If you want to use EJBs in order to put it on your resume that's also a >plausible reason. If that's the case then you probably will no regret using >EJBs.

    This is the last reason for me.

    >C) If you are writing an application by yourself or in a very small team, >maybe with a small budget or short time constraints, and therefore require >really high productivity, then you should consider the problem from the top >down.

    I'm the only developer on the project


    >D) You may want to choose EJBs if you want to use some app server's features >which are most easily (or only) available through EJBs, e.g. entity beans on a >cluster with multicast invalidation.

    If the project is a success we might use clusters

    >E) If you are using JMS queues, then MDBs are definitely worth it.
    This is what we are going to use. The standard in our bank is TIBCO.


    Overall, the application should have scalability, high availability. This is mission-critical application. We going to receive feeds from all back offices in the bank and results will be used by head treaders of the bank to make decisions on how to fund the bank.

    Thanks again for your help.
  198. New to EJB: Thanks for help[ Go to top ]

    The project is small to mid size and not to complex. I'm an employee.

    [..]
    > I'm the only developer on the project
    [..]
    > If the project is a success we might use clusters
    [..]
    > >E) If you are using JMS queues, then MDBs are definitely worth it.
    > This is what we are going to use. The standard in our bank is TIBCO.
    [..]
    > Overall, the application should have scalability, high availability. This is mission-critical application. We going to receive feeds from all back offices in the bank and results will be used by head treaders of the bank to make decisions on how to fund the bank.

    You can definitely benefit from using MDBs then. MDBs are pretty low overhead. And the app server will start a transaction for you so if you roll back you'll receive the message again.

    IMHO you should only use a cluster if a) you don't have the money for a single big SMP machine or b) if you need a certain level of application availability that a simple warm backup will not provide. The reason is because concurrency control on a cluster is more problematic. Usually you will have to put up with rollbacks, and therefore will need a re-try mechanism. Fortunately for you, you have a retry mechanism because the input comes from a JMS queue.

    Have you thought about which app server you might be using? Since you use queues you probably want to use XA transactions (or have a really adventurous nature) and therefore you should only use app servers that have a full-fledged transaction manager with a redo log.

    Depending on which app server you are considering look at what kind of clustering support they have for entity beans.
  199. New to EJB: Thanks for help[ Go to top ]

    The standard in the bank is BEA Weblogic.

    As I understand from what I've read, I can publish
    a message and insert into the database in the same
    transaction. Is it true in real life projects. I think
    this is one of the options I would need to implement,
    because one fo the requirements is the ability to display
    historic data.

    Thanks for your time
  200. New to EJB: Thanks for help[ Go to top ]

    The standard in the bank is BEA Weblogic.


    That's what I am using too. Since you have a company-wide standard, that means you don't have to evaluate a lot of stuff.

    > As I understand from what I've read, I can publish
    > a message and insert into the database in the same
    > transaction.

    Right.

    > Is it true in real life projects.

    Yes. High-volume, too.

    > this is one of the options I would need to implement,
    > because one fo the requirements is the ability to display
    > historic data.

    I don't see the connection with historic data, but the basic reason why you do it is because if the database decides to roll back your writes, then the JMS server should know to re-send the message.
  201. New to EJB: Thanks for help[ Go to top ]

    I don't see the connection with historic data, but the basic reason why you do >it is because if the database decides to roll back your writes, then the JMS >server should know to re-send the message.


    What I meant is that the users should be able to view last 3 month of data using a GUI, so I need to store it. Otherwise, if they would not need to see the data again I would use just JMS. On the other hand I probably will need to store the data anyway (e.g., audit).


    Thanks for your time. I really appritiate your help. Now, I have more clear idea on how to make a decision.
  202. New to EJB[ Go to top ]

    I would say whether or not EJB is a good choice for you depends on what your project requirements are, and what technical issues those requirements require you to address. You need to first understand those and then understand what EJB brings to the table from a cost/benefit standpoint. Benefits wise, most importantly EJB provides a way to build scalable distributed applications. It removes the complexity associated with concurrency issues in high-volume environments, it provides declarative transacation management, and it provides services for server-side object pooling.

    With those benefits, however, comes increased cost and complexity--you must make an investment in an appserver, EJBs are complex to test, deployment in general is a pain, and IMHO with EJB it's easy to design business logic in a way which very much *couples* your code to the EJB component model, making your business logic less portable and 'more cluttered' with framework code (framework code that has absolutely nothing to do with your business logic...)

    EJB does do things well, as I mentioned, and many of the experts here can tell you all about them (recommendation: read their books) but you need to seriously ask yourself if you need all those things. IMHO when you need those things, it's better to go with EJB than try to build your own homegrown solution.

    Speaking for myself, in many of my projects EJB is "too much" for the job. A lighter weight solution provides better value, quicker time-to-market, and more flexibility. My requirements frequently just don't demand a high-concurrent-user, distributed application in many cases. Do yours? I don't know. But my advice to you is to very carefully consider your requirements before you commit to any implementation technology. And I would highly recommend taking a look at the lighter weight solution alternatives out there that can provide some of the benefits of EJB in a simpler, easier-to-use & less invasive environment.

    The last bit of advice is this--let your business needs drive your technology decisions, not the other way around. Don't fall for all this tech-happy hype.
  203. Richard Monson-Haefel's book[ Go to top ]

    I closed the book after reading only the preface of Richard Monson-Haefel's book. After coming from a failed project, he sees the light and knows what is good by intuition. Well, we know what works not by failures but by successes. If something went wrong for you, doesn't give you right to know what would be correct. The book may be a good reference to a ill-thought technology.

    I can see how EJB spec would have been developed. They wanted a better way to do RMI, so they said all right, forget all the IDL-corba crap, let's just put the info in an XML file (deployment desciptors). Cool so far. Then the wise ass thought hay look, we are pushing bytes through this single port and calling methods, we can call some other method before and after the actual one requested on RMI. So, there came declarative transactions and security.

    Now the suckers, who saw painless transactions and automatic security, said, what the hell, I am getting declarative transactions and security, I will pay the price of pushing everything through RMI. They just wanted transactions and security, they got it but got RMI (distributed objects) as well along with it.

    If you really need RMI, EJB may be able to help. But if all you need is declarative transactions and security, no need to use EJB anymore.

    J2EE != EJB. And Tomcat is a standard compliant J2EE container that doesn't support EJB. Tomcat + Spring + hibernate + iBatis will be more than enough for 90% of web applications.

    Using EJB for enterprise integration is laughable at best. Why would you pin your integration hopes on propritory techonology. Web services/REST would fair much better at integration than EJB. Has anybody heard of python/perl/ruby/C# API for accessing EJBs? How many know they can consume a web service in python/perl/ruby/C#? The answer is clear. Code generation for web services can automatically create client side stubs for comsumption of web services, the client doesn't even need to know it's going over web service, as far as client is conserned it's using an API.

    My 2 cents.
  204. why are entity beans serializable?[ Go to top ]

    got nothing personal against any of the emearging/emerged technologies.. also i confess i havent read all of the stuff available on java/j2ee. it has become an ocean out there for a slow reader like me.

    anyways, back to the subject, why should entity beans be implementing serializable? ejbStore is the way to persist these and i havent realized if the beans are ever tranferred over wire? is this to enable code from ejbStore to be able to serialize itself and save it in files maybe? if thats the case, then its an incidental requirement.. maybe a SerializabeEntityBean can be derived from EntityBean for this purpose. But i guess i am missing somthing obvious. Would request a kind soul to help me.


    But.... the still more interesting question is: WHY NOT SERIALIZE THE ENTITY BEANS AND SEND THEM OVER THE WIRE! They say all the time that calling methods on entity beans is expensive then why no just send the whole bean at one go? Infact dont we start doing something similar when we create Transfer/Value Objects and send those over the net. Then the client uses the TO (transfer object) to get/set values and then finally send it to the bean on the other side to read values from there and update the bean data. Well this whole paradigm of using TOs defeats the selling point of "pooling" the Entity beans. Because finally we end up using TOs that are not pooled (at least not by a middleware!). So why do we go thru this additional layer of TO and why not just Serialize the Bean and send it to the client? Well a reason can be that lazy loading cant be supported with this. how would it have worked anyways with TO pattern? I guess you'll fetch more TOs from the TO you got in hand and that code to fetch more TOs will use Entity Bean's remote interface... i guess you'll so sth similar.. or there is sth more to it? Well this sounds like a valid justification for not blindly serializing a Bean instance. But NO! I guess we are approaching the actual problem that needs to be solved. The issue was that the a connection (e.g. to a JDBC data source) cant be fetched from the client. well then shouldnt the problem be solved by the Connector Architecture? I think, IMHO, what is needed is to enhance the Connector architecture (already being a critical part of middleware) to reach the "Home" of the "Connection to the DataSource" instead of forcing the whole entity bean to become immobile!?! So, what i am sugegsting is: serialize the bean and alongwith it somehow carry the information of the connections to datasources that it depends on. Now when a method call on a entity bean that was tranfered to a client tries to open a connection or get/set data using a connection it is the connector architecture that locates the Home of that Connection and then redirects the command made on the connection to the home of that connection (maybe the place where the bean was originally created) to actally execute it. Well proceeding on this line of thought will raise issues like where is a bean created first? Or how is the connection's home detected got the a newly craeted bean? I think these problems are solvable if we focus on the Connector Architecture and using JNDI for lookups. As a side effect, this architecure will give more flexibility for entity bean composition, better distribution of load and cleaner code. All this becasue we solve the problem where it actually is?
  205. My suggestions on the future, EJB 3.x and beyond spec.:

    Propose a EJB Lite API. Why, and what should it be?

    * It should be a more focused API on doing one thing, and doing it well.
      Be it remoting, scalability, ... I am keeping it open. I would actually
      take the aspect lesson and maybe make it do one thing, but make it easily
      enriched by other aspects such as persistence, remoting, ...

    * It should be a political way of hushing up the complex, bloated, de-focused
      EJBs as they are now, without de-facto killing the API and leaving current
      users on the "dry land".

    As a must incorporate lessons learned with J2EE and open source such as:

    1. Hibernate: do one thing, and do it right
    2. Aspects: Infrastructure should be extrinsic to the business objects
    3. Agile modelling: Apply patterns lightly, make things simple.
    4. Servlets: Lightweight, simple, highly scalable workhorse of the web app.
    5. WebService: forget obsession to mimic CORBA, RPC, COM like models. Focus
       on the most unifying emerging distributed computing model, and build in
       "on click" suppport for WebServices into EJB spec.


    I did not read every single post because I got distracted by "flame throwers",
    so there is a chance that someone has already suggested this. If not, I hope my post will be helpful to your(Richard Monson-Haefel) future efforts.

    Best regards,
    Edmon Begoli
  206. I am fairly new to EJBs. Just jumped into this few months back. What pissed me off initially was the inconsistency in the element naming in ejb-jar.xml. Not sure how many times I cursed those involved while preparing for SCBCD. Anyway, using a good Java IDE (Jbuilder in my case) takes care of this, as I do not have to sit and write it myself.

    What surprises me a lot is that most of the App Server vendors are member of this so called EJB 3.0 (JSR 220) expert group. Why did they all not suggest the additional functionality that they have provided as extension to standard EJB in their respective product( BEA, IBM, Borland). To be specific, lets take of EJB-QL. I found lot of useful functionality (like Dynamic Queries) being implemented by each of this vendors as extension to EJB-QL. But there are difference in the way each of them implements it. So this is a huge portability issue as you have to sit down and rewrite those part of code, if you change the app server. This bring us back to square one (Microsoft :-))

    I feel EJB-QL need to be super charged. Currently the query support is very rudimentary (what were you thinking guys??). One the one hand you guys are pushing towards CMP and on the other hand, EJB-QL has got very limited features.Where are dynamic queries, outer joins,sub queries, returning multiple columns ...?

    Some of the EJB pitfalls have been taken care of by the various EJB design patterns. The group should have a serious look into the EJB design patterns.


    Peter Vennel.
  207. There is no need of re-inventing the wheel every time..

    Why can we make a solid framework ,part of EJB..
    like sun's WAF

    JOSEPH
  208. Add a way of achieving the OR mapping like Toplink, but more driven through ejbgen like tags, instead of through Toplink's GUI. In fact, generate the SQL script for database tables from the entity bean's pre ejbgen .java file. Without this feature, entity beans require too much work.

    Have a more standardized way for value objects (no separate classes for each entity bean) - the primary key fields in one set, and the others in another. Put in 2 serializable property lists. basically no need to have getXYZ(), setXYZ() for each entity bean attribute, just do get("XYZ"), more like JMX MBean attribute. Downside is the value object is fatter (store name and value instead of storing values only), but still the upside is no special value object is required for each class of entity bean. Basically making possible that everything about the entity bean is present in one bean class with ejbgen tags.

    For relations, the value objects could send the shallow other-end of the relation, which is the primary key of the other object, over the wire. Or choose not to send that. Again specifiable through ejbgen like tag.

    Amit Basu.
  209. Just got back from a JUG meeting where Marc Fleury of JBoss was giving a great speech on EJB 3.0. At first glance, looks great. No more writing things like deployment descriptors and home/remote interfaces. Beans can extend whatever they want and still comply to the spec. Just stick an annotation on your method to tell the container what you want this method to do, and you get it. Sounds wonderful. But certain questions arise. The way Marc explained it, in 3.0 world lookups are gone. No more initial context. POJO “new()” is all you need.

    But all these niceties are possible because it is assumed that all your beans are local. If you happen to have a remote bean, you have to jump through hoop to get your container to give you your remote components (by using things like dependency injections). From what Marc told us, this is because 90% of all developers are using beans locally, and the idea of JSR 220 is to improve the life of the majority. A lot of thought, he says, is given to how EJB can be utilized more effectively with MVC frameworks like Struts, because most of us use Struts these days. Further, the way things are working on the server/container level will remain almost exactly the same. Servers will still be generating interfaces of all kinds, but because of annotations, this process will be completely transparent to developers. Servers will simply apply aspects to annotated code.

    Ok, that’s all great, but isn’t this supposed to be a general spec? The way I understand it, a general spec should describe how things should generally look and vendors can take it from there. In my humble opinion, EJB 2.1 did a wonderful job as a general spec. I want my spec to tell me “Here is what you need to comply to me. At the end of the day you should look like this.” And how I get to “looking like this” is left to the vendors. If a vendor wants to make my life easier and provide me with a way to make my life really easy by letting me use annotations on a POJO instead of defining home interfaces, great! I will be the first one to jump on board with any open source project that will make it possible. But put it in a spec and make everyone do it? I’m not sure. I’m debating whether this is a step backwards from what was meant to be a general integrated framework for distributed, component-based computing.

    anton@idelphia.com
  210. u might want to post to the more recent topics about EJB 3.0 This thread's been dead for a while and there have been recent news in the last few days.