New Article: Java EE 6 Overview

Home

News: New Article: Java EE 6 Overview

  1. New Article: Java EE 6 Overview (154 messages)

    Java EE 6 is well on its way. The spec has been released as a draft for public review and comment. To provide an overview and summary of that spec, Reza Rahman looks into it and describes how it might affect your development efforts in the future. Read article

    Threaded Messages (154)

  2. It seems a bit aggressive decision to remove JSR-88 Java EE Application Deployment from platform. Despite the fact that it's not widely supported this standard gives hope to standardize deployment process in future. Pruning this API will prevent work in this direction for years. Features distribution between Web and Full profiles seems a bit confusing. There are features like JAX-WS and JAXB that are already part of Java SE but they included to Full Profile only. Furthermore, since such features are in Java SE it seems like Basic profile is superfluous. Regards, Vladimir
  3. JSR-299 and JPA entities[ Go to top ]

    A small correction: the article states that "It does this by registering EJB 3 beans, JPA entities as well as plain JavaBeans as WebBeans components". JSR-299 doesn't cover JPA entities (Seam 2 does, though)
  4. Re: JSR-299 and JPA entities[ Go to top ]

    Nicklas,
    A small correction: the article states that "It does this by registering EJB 3 beans, JPA entities as well as plain JavaBeans as WebBeans components".

    JSR-299 doesn't cover JPA entities (Seam 2 does, though)
    Thanks for pointing this out, I'll follow-up on it. My current understanding is that it would simply treat JPA entities as JavaBeans. Thanks, Reza
  5. Re: New Article: Java EE 6 Overview[ Go to top ]

    Vladimir,
    It seems a bit aggressive decision to remove JSR-88 OK, point taken. Keep in mind though, just because something is not in Java EE, does not stop the JSR from being worked on, granted interop becomes a lot harder. Also, it could easily be re-integrated when neccessary. Cheers, Reza
  6. Disappointing.[ Go to top ]

    I’ve been following EE 6 quite closely for some time and I have to say I find some of the decisions made by the expert group in the current spec unfathomable. It feels like everything good since EE 5 hasn’t made it. WebBeans isn’t part of EE6? Beans validation isn’t part of EE6? JAX-RS isn’t part of the web profile? Oh and JPA 2.0 is which I find surprising given that there is no clear agreement on the criteria API for it yet which is surely one of the more important bits (see http://www.infoq.com/news/2009/01/jpa20 for a summary).
  7. Re: Disappointing.[ Go to top ]

    William, Firstly, let's kindly try to be a little more constructive - the point of the article, after all, is to hear what you have to say and understand why you are saying it...it's hard to pay attention to someone that seems like they are more intersted in shouting rather than conversing on the basis of mutual respect.
    WebBeans isn’t part of EE6?
    - It is likely, but not certain, that WebBeans will be included in Java EE 6. If you believe it should be, that is certainly useful feedback.
    Beans validation isn’t part of EE6?
    - The inclusion of JRS 303 is also a very likely possibility and is currenly under active discussion.
    JAX-RS isn’t part of the web profile?
    - Can you kindly explain why this should be the case? I personally can't see why JAX-RS should be in the Web Profile (and that is the consensus in the Java EE 6 EG), hence the public draft.
    Oh and JPA 2.0 is which I find surprising given that there is no clear agreement on the criteria API.
    - Firstly, this is patently innacurate since nothing gets into a public draft without high levels of consensus amongst folks in an EG - and Red Hat is part of JPA 2.0. Secondly, I am sure the post you mentioned will be considered carefully and the spec will change if the comment has merit. One good indication of this was the recent TSS article commenting on Servlet 3.0 - Rajiv, the spec lead, poined out that all the objections in the article were already addressed by the EG (independent of the article author, I might add). Best regards, Reza
  8. JEE6 contents[ Go to top ]

    WebBeans isn’t part of EE6?
    Beans validation isn’t part of EE6?
    I think it is crucial to have stable versions of these JSR's in JEE6. While JavaOne is a good whip to get the expert groups moving, it should not cause an incomplete JEE6. The call for OSGI on the other hand arrives so late in the JEE discussions that it is a good candidate to evaluate for JEE7. For now, if you want an OSGI based server, just get one. jan
  9. Re: JEE6 contents[ Go to top ]

    Jan,
    I think it is crucial to have stable versions of these JSR's in JEE6. While JavaOne is a good whip to get the expert groups moving, it should not cause an incomplete JEE6.
    - Agreed 100%. Luckily, looks like both the JSRs are stabilizing gracefully...
    The call for OSGI on the other hand arrives so late in the JEE discussions that it is a good candidate to evaluate for JEE7. For now, if you want an OSGI based server, just get one.
    - Amen :-) Cheers, Reza
  10. Re: JEE6 contents[ Go to top ]

    The call for OSGI on the other hand arrives so late in the JEE discussions that it is a good candidate to evaluate for JEE7. For now, if you want an OSGI based server, just get one.
    ... and forget about JEE.
  11. Re: Disappointing.[ Go to top ]

    Sorry if I caused offense.  I’ll pull on my flame redundant jacket and try and risk a response. Both 299 and 304 seem to be strong contenders for inclusion in the spec and I guess I was surprised that the expert group is waiting for the community to deamnd this rather than simply putting it in. That said that they are on the possible include list is a good thing.  299 finally offers  a standard  dependency management solution for the platform which seems to me to be a no brainer.  Moreover it has been able to learn the lessons of a number of widely used open source alternatives such as Spring and GUICE and seems to be a really elegant solution to the problem.  304 offers a standard way of doing validation, at least partially based on the popular Hibernate validator, and opens up the tantalising possibility of eliminating a whole category of common bugs in enterprise apps by having a common set of validations applied across all the different application tiers from the web client to the server side code to the database or whatever.   So again I feel very strongly it should be included. In terms of the Web Profile and the REST API all but one of the web applications I’ve built this centaury have needed to consume web services and increasingly these are REST based so having this available out of the box seems right to me.  I have also seen it argued, I’ve no idea how seriously, that it is the right solution for building actually building a web framework and I know of one Java web framework that does exactly that. In terms of JPA2 criteria API the InfoQ piece I linked to before is pretty recent and has the expert group debating two radically different proposals for the criteria API, so, assuming the article is an accurate representation of what is going on I don’t consider this a consensus proposal as yet.  Moreover none of the open source attempts at solving this problem (Liquidform and the like) seem to have gained all that much traction in the market so I’m not convinced we even know how to solve it.  Both the expert group proposal and King’s alternative have what seem to me to be fairly fundamental problems; they both suffer from verbosity/complexity relative to just writing SQL, and the King proposal relies on compiler hacks so I don’t think you can’t build up dynamic queries within code.  I suspect that the problem here is that Java 6 isn’t actually able to support development of a query API without some form of DSL support in the Java language - method and attribute literals at the very least.  So my thought here would be to push for inclusion of the relevant changes in Java 7, build a solution on top of Java 7 that can be plugged into JPA2, and see if it gains any traction before formally adopting nto EE7.
    What it comes down to is I have no idea what standard the Expert Group is using for inclusion – both WebBeans and Validations seem to me closer to a consensus/ready proposal than JPA 2.0 appears to be.  
  12. Re: Disappointing.[ Go to top ]

    William,
    Sorry if I caused offense.
    - No offence taken here. The problem is that non-constructive tonality has a sort of "broken windows" syndrome that devolves quicky. It's easy to let your guard down in the spur of the moment, though.
    Both 299 and 304 seem to be strong contenders for inclusion in the spec
    - I agree, but neither are as problem free as they might seem. If you want, we can talk in detail about what I think the issues are. It's not really correct to think the EG is waiting to see what the demand for these featues are. To be honest, most folks in the EG are not the "popularity contest" types and thus or not all that driven by numbers instead of solid reasoning. In fact, too much premature support for these JSRs could stop valid concerns from being addressed and folks getting too lax...
    So again I feel very strongly it should be included.
    - OK, point taken.
    In terms of the Web Profile and the REST API all but one of the web applications I’ve built this century have needed to consume web services and increasingly these are REST based so having this available out of the box seems right to me.
    - I don't doubt that experince and it's useful feedback. However, I do think the evidence for this is underwhelming and clearly I'm not alone in that opinion. That all being said, point taken and let's see what other folks have to say.
    JPA2 criteria API the InfoQ piece I linked to before is pretty recent and has the expert group debating two radically different proposals for the criteria API.
    - Frankly, this is one of the pitfalls of the greater "openness" for the JCP that some people are calling for. As you noted, these are complex issues that need to be worked through to reach consensus on. Just because there is a debate (perhaps even a heated debate) doesn't mean the issues won't be resolved the best it is possible. Neither does it mean the solution can't evolve if something better comes along. Material like the one you posted seem problematic to me because they have an element of mass-media style sensationalism instead of focusing on facts, solutions and solid engineering... Cheers, Reza
  13. Re: Disappointing.[ Go to top ]

    Just because there is a debate (perhaps even a heated debate) doesn't mean the issues won't be resolved the best it is possible.
    To correct this and clear up any possible misconceptions: there is no especially "heated debate" surrounding the criteria API, and I don't know where you guys got the impression that there is. The EG is working very constructively on this very important new feature of JPA.
  14. Re: Disappointing.[ Go to top ]

    Both 299 and 304 seem to be strong contenders for inclusion in the spec and I guess I was surprised that the expert group is waiting for the community to deamnd this rather than simply putting it in.
    Why is this surprising? The platform belongs to the community, and the EGs respond to demands that come from the community. If the community behaves apathetically, we get the platform release we deserve: a boring, incomplete one. If that's not what you want, you should communicate exactly what you *do* want to the EGs.
    That said that they are on the possible include list is a good thing. 299 finally offers a standard dependency management solution for the platform which seems to me to be a no brainer.
    Just because it seems like a no brainer to you does not mean that it automatically gets included in the platform. Those of us who are killing ourselves trying to make this happen would very much appreciate a bit of moral support.
    In terms of JPA2 criteria API the InfoQ piece I linked to before is pretty recent and has the expert group debating two radically different proposals for the criteria API, so, assuming the article is an accurate representation of what is going on I don’t consider this a consensus proposal as yet.
    This isn't an accurate summary of the situation. My proposal built upon the previous criteria proposal, adding type safety, and the EG is currently working through various issues that came up relating to my proposal. At this point I'm not even very much involved anymore, since I have to focus on 299.
    Both the expert group proposal and King’s alternative have what seem to me to be fairly fundamental problems; they both suffer from verbosity/complexity relative to just writing SQL
    Erm, *any* criteria API is going to be more verbose than writing SQL. If you want a dedicated query language, we already have one: JPA-QL. In essence, the criteria API has exactly one advantage over JPA-QL: the queries can be validated at compile-time, especially dynamic queries. The cost is verbosity.
    the King proposal relies on compiler hacks
    How is a standard, portable extension point of javac a "hack"? Actually it's not hackish at all. It always just amazes me how much people freak out when they encounter new language features. I vividly remember the intense negative response to the annotation-based programming model we proposed for EJB and JPA. And now? Not so much negativity. Think of all the real "hacks" that could have been avoided over the past 10 years if Java would have had these features earlier!
    so I don’t think you can’t build up dynamic queries within code.
    Absolutely not correct. You can definitely do that.
    I suspect that the problem here is that Java 6 isn’t actually able to support development of a query API without some form of DSL support in the Java language - method and attribute literals at the very least.
    The point is that I "discovered" a form of "DSL support" that actually does already exist in Java6: Processors. Yes, I understand that the rest of the community has not yet clicked to how powerful this new-ish feature is, but in future we might see this used for a lot more than just the criteria API. And unlike in Ruby, Groovy, etc, you can use this feature to build type safe DSLs. Which means authoring support (autocompletion, etc) and full compile-time validation. Oh, and by the way, simply supporting method and field literals would NOT be enough to guarantee the typesafety that my proposal gives you. It's absolutely critical that the objects that represents attributes are parameterized also by the type they belong to. So even if we did have method and field literals in Java, there would still be a good reason to use a Processor for this problem.
  15. Re: Disappointing.[ Go to top ]

    Gavin, Firstly, thanks very much for posting. I can only imagine how hectic things must be for you, so I appreciate the effort..
    Those of us who are killing ourselves trying to make this happen would very much appreciate a bit of moral support.
    A little off-topic as it may be, I wanted to make sure to let you know that I do appreciate the thought leadership and support on your part, even if we may not neccessarily agree on everything all the time...
    This isn't an accurate summary of the situation.
    - Thanks for stating that clearly. I suspected this is the case, but certainly don't want to speak for anyone else... Thanks again for your time and effort. Cheers, Reza
  16. Hype here, hype there...[ Go to top ]

    "or even mature APIs like Servlet 3.0" WTF!
  17. Re: Hype here, hype there...[ Go to top ]

    "or even mature APIs like Servlet 3.0"
    WTF!
    Could you please elaborate more on what is the problem with Servlet 3.0 ?
  18. Re: Hype here, hype there...[ Go to top ]

    "or even mature APIs like Servlet 3.0"
    WTF!

    Could you please elaborate more on what is the problem with Servlet 3.0 ?
    Servlet 3.0 can hardly be called 'mature'.
  19. Re: Hype here, hype there...[ Go to top ]

    "or even mature APIs like Servlet 3.0"
    WTF
    Not sure there is really a point to responding to this, but I'll give it fair treatment anyways (I most certainly would ignore this in any other setting than on-line given the unfortunate choice of language and tonality) - the Servlet API is definitely one of the oldest APIs in Java EE, albeit we can quibble about the definition of "mature" or how a purely technical discussion from an indepenedent non-vendor pertains to "hype"... Peace, Reza
  20. No OSGI?[ Go to top ]

    Is it too late for collaboration between OSGI and Java EE in the spec?
  21. Re: No OSGI?[ Go to top ]

    Is it too late for collaboration between OSGI and Java EE in the spec?
    Probably. While it'd be a good idea, the two module specifications are a little far-apart to really be an easy merge. That said, various OSGi-aware vendors seem to be working on it - and they should, considering how convenient the ability would be.
  22. Re: No OSGI?[ Go to top ]

    Is it too late for collaboration between OSGI and Java EE in the spec?
    I agree with Joe in that I think it's best to revisit this in the future after vendors embrace OSGi a bit more. Cheers, Reza
  23. Re: No OSGI?[ Go to top ]

    Is it too late for collaboration between OSGI and Java EE in the spec?


    I agree with Joe in that I think it's best to revisit this in the future after vendors embrace OSGi a bit more.

    Cheers,
    Reza
    OSGi is overrated IMO. Not needed in most cases either because the user is running only one application, or the Java EE or vendor classloader scoping policies. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com http://jboss.org/resteasy
  24. Re: No OSGI?[ Go to top ]

    @Bill, both arguments are nonsens: "Not needed in most cases either because the user is running only one application" Yes, and thats why you break applications into layers,modules,components where CL separation, a service infrastructure and the package oriented scoping helps a lot. "Java EE or vendor classloader scoping policies" Well, we are talking about Java EE to embrace OSGi here. Just because it was up to vendors to solve that does not mean it was/is good. Toni
  25. OSGi overrated?[ Go to top ]

    Application developers and framework designers DO need a proper modularization support. OSGi enables the development of clean and dynamic application architectures. IMO OSGi - enabling the application servers would a big step in the rigth direction for application developers. Regards, Sandro
  26. Re: OSGi overrated?[ Go to top ]

    The thing is, the actual OSGi capabilities are pretty limited, and the architecture is a bit behind. Its main value is a jar introspection and jar-loader introspection mechanism, which is a good idea because there's no JavaEE capability for learning about the currently-loaded jars. It has a notion of versioning, although I'd argue that Maven or Ivy would be a better basis. It does add a convoluted classloader scheme, which can give you isolation in the case of multiple jars with different versions. I'm not sure if this is a good thing. It does let you add jars on the fly, which isn't hugely valuable in an enterprise context, since you normal already have the jars available, but it's something. The jar registry/introspection above is useful. It has an old-fashioned service registration and lookup facility that really need to be updated and modernized. That's it really. It's useful, but not a wonder-spec. I'd argue that you really want to take the good ideas in OSGi and make them more modern: clean up the Jar registration and introspection APIs (the most useful part) register services and manage lifecycle with Java CanDI (the spec formerly known as WebBeans) make OSGi jars configurable with CanDI META-INF/beans.xml use Maven or Ivy for the dependency management dunno about the classloading. It's a bit overcomplicated.
  27. Re: OSGi overrated?[ Go to top ]

    The thing is, the actual OSGi capabilities are pretty limited, and the architecture is a bit behind.

    Its main value is a jar introspection and jar-loader introspection mechanism, which is a good idea because there's no JavaEE capability for learning about the currently-loaded jars.
    Actually its main value is managing modularity not introspection, that's only a small part of the puzzle.
    It has a notion of versioning, although I'd argue that Maven or Ivy would be a better basis.
    FYI the Maven team are thinking about using the OSGi version scheme in Maven 3.
    It does add a convoluted classloader scheme, which can give you isolation in the case of multiple jars with different versions. I'm not sure if this is a good thing.
    It is a good thing :) Having worked on the internals of several major JVMs I can say that the OSGi classloader spec is the best solution I've seen (so far) for managing dynamic modular apps. Of course if you have the ability to make changes to the underlying runtime then you can do even more, which is why the Jigsaw project is interesting - but I hope they retain compatibility with core OSGi standards.
    It does let you add jars on the fly, which isn't hugely valuable in an enterprise context, since you normal already have the jars available, but it's something.
    Having redeployed a number of web applications over the years I personally like being able to upgrade individual JARs with the minimum disturbance to customers.
    The jar registry/introspection above is useful.

    It has an old-fashioned service registration and lookup facility that really need to be updated and modernized.
    Shh... the service registry is the best kept secret of OSGi! All kidding aside, while the raw service API can suck it is really flexible and dynamic. And there are plenty of frameworks that can hide the raw API beneath a more modern dependency injection model (see below). The next version of the spec will also add support for distributed OSGi services (currently being prototyped with CXF).
    That's it really. It's useful, but not a wonder-spec.

    I'd argue that you really want to take the good ideas in OSGi and make them more modern:

    clean up the Jar registration and introspection APIs (the most useful part)
    register services and manage lifecycle with Java CanDI (the spec formerly known as WebBeans)
    You'll be glad to hear both Spring and Guice support injection of OSGi services, along with Resin and many more... and there is a group looking at making the API more modern while retaining compatibility with mobile/embedded devices.
    make OSGi jars configurable with CanDI META-INF/beans.xml
    use Maven or Ivy for the dependency management
    That's also being discussed.
    dunno about the classloading. It's a bit overcomplicated.
    aw, but that's the best bit ;)
  28. Re: OSGi overrated?[ Go to top ]

    Stuart, I don't usually judge people based on who they are, but what they say. However... Your name seemed familiar and looks like you are an OSGi framework developer and the author of OSGi in Action. I'll have to admit, for a skeptic like me, it does make me question the merit of some of what you say... I apologize profusely if I'm off-base. Perhaps the best thing is to add who you are to your signature?...speaking of which, I should probably do the same... Cheers, Reza ---------------------- Independent Consultant Expert Group Member, Java EE 6, EJB 3.1 Author, EJB 3 in Action
  29. Re: OSGi overrated?[ Go to top ]

    Stuart,

    I don't usually judge people based on who they are, but what they say. However...

    Your name seemed familiar and looks like you are an OSGi framework developer and the author of OSGi in Action. I'll have to admit, for a skeptic like me, it does make me question the merit of some of what you say...
    interesting, by that logic I should question this article as you're a member of the EJB expert group and author of EJB 3 in Action ;) However as you have the same first name as my new nephew (born last December) I will take what you say on trust :D [Side-rant... I don't understand why having experience of something automatically means you're less qualified to explain it. Should I keep quiet and not share my views?] by all means be skeptical, that can definitely be a good thing, but I do hope there are people in the EJB expert group that have time to look more closely at OSGi - if only to learn from the collected experience. I've been putting links in so people can get more detail on what I've been saying and make up their own minds.
    I apologize profusely if I'm off-base. Perhaps the best thing is to add who you are to your signature?...speaking of which, I should probably do the same...

    Cheers,
    Reza
    ----------------------
    Independent Consultant
    Expert Group Member, Java EE 6, EJB 3.1
    Author, EJB 3 in Action
    sure, in the interests of full disclosure... Stuart ------------------------------------------------------------ Developer/consultant at CodeDragons Malaysia (specialists in OSGi, Java MicroEdition and Open Source development) Co-author, OSGi in Action Project lead for peaberry Project lead for the maven-bundle-plugin Project lead for pax-construct Apache Felix committer and PMC member Ex-member of the OSGi Enterprise Expert Group :) In my past life I was a senior developer for the IBM JVM (both classic and J9) and before that I worked on ATC simulations in a variety of languages. I also help out in my spare time on the OPS4J, Maven, and Guice mailing lists - answering questions and doing problem determination. Both my boss and my wife say I do way too much work for free ;)
  30. Re: OSGi overrated?[ Go to top ]

    Stuart,
    I should question this article as you're a member of the EJB expert group and author of EJB 3 in Action
    That's a fair question and I'm glad you brought it up. Here is what I have to say for myself - First and foremost, I do hope that folks read the article with a healthy dose of skepticism and verify/investigate things on their own. One vehicle to do this, of course, is to ask me questions (pointed questions, even:-)). As to the question of conflict of interest, it honestly can't be discounted altogether. My consulting practice is not based on Java EE solely. Indeed, I've recently taken on a Rails project (which I must say I like so far) and a significant portion of my customer base use non-standard Java EE solutions, which I do recommend depending on the project/customer. Also, I generally stay clear of partnerships with larger organizations/vendors, beyond loose alliances with other unaffiliated independent consultants. However, I do directly benefit from the proceeds of the book and indirectly benefit from working in the JCP. I am also a strong believer in the value of having competing, but compatiple choices for developers.
    you have the same first name as my new nephew
    It's always amazing to see the walls we've built around ourselves as human beings dessolve as the world becomes smaller! However, I do sometimes wonder if the walls are coming down too quickly for smooth adjustments across the globe...
    I don't understand why having experience of something automatically means you're less qualified to explain it.
    To state what's probably obvious, the question is not qualification, interest or even perhaps ideology, but of financial motivations in an imperfect world.
    Should I keep quiet and not share my views?
    Of course not! Shame on me if that's how it came across...the issue is that it was an unpleasant surprise that can be easily avoided. As you can probably appreciate, no one particularly enjoys feeling as though they are being deliberately manipulated...
    I do hope there are people in the EJB expert group that have time to look more closely at OSGi
    OK, I'll look again myself and see if it can be brought up in JSR 318. As I mentioned, more importantly, it was already discussed in JSR 318. As you can see from the responses of folks like Bill Burke from Red Hat and Scott Furguson from Cuacho, the opinions vary widely. Mine is that it is too early to be talking about OSGi at this point. And even if and when the time comes, it should largely be implemented as an infrastructure concern mostly separated from the developement concerns of enterprise Java developers. Best regards, Reza ----------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  31. Re: OSGi overrated?[ Go to top ]

    Stuart,

    I don't usually judge people based on who they are, but what they say. However...

    Your name seemed familiar and looks like you are an OSGi framework developer and the author of OSGi in Action. I'll have to admit, for a skeptic like me, it does make me question the merit of some of what you say...

    I apologize profusely if I'm off-base. Perhaps the best thing is to add who you are to your signature?...speaking of which, I should probably do the same...

    Cheers,
    Reza
    ----------------------
    Independent Consultant
    Expert Group Member, Java EE 6, EJB 3.1
    Author, EJB 3 in Action
    Reza, Remember, Stuart stated that he is not trying to convince anybody to include OSGi in JEE6. He's just trying to correct some of the more egregious misconceptions about it, as I'm sure you would if somebody posted nonsense about EJB3. Regards, Neil Bartlett Author of OSGi in Practice (Stuart's competitor, sort of)
  32. Re: OSGi overrated?[ Go to top ]

    Neil,
    Stuart stated that he is not trying to convince anybody to include OSGi in JEE6. He's just trying to correct some of the more egregious misconceptions about it, as I'm sure you would if somebody posted nonsense about EJB3.
    Agreed. Again, not saying the discussion is not valid and valuable, just that it was somewhat of a nasty surprise and there is an easy way to avoid it... Cheers, Reza ---------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  33. Re: OSGi overrated?[ Go to top ]

    Actually its main value is managing modularity not introspection, that's only a small part of the puzzle.
    Well, "introspection" may not be exactly the right term. I meant exposing a usable object (Bundle in OSGi) for each installed jars, exposing the metadata, and providing general, useful capabilities. It's similar in concept to introspection. I do think that kind of jar management/introspection capability should be part of JavaEE 7.
    FYI the Maven team are thinking about using the OSGi version scheme in Maven 3.
    I was thinking of the pom.xml in META-INF. The OSGi version string itself is fine. It's the MANIFEST.MF and the package combinations that get ugly. Using something like a cleaned-up and simplified pom.xml would be an improvement.
    It is a good thing :)

    Having worked on the internals of several major JVMs I can say that the OSGi classloader spec is the best solution I've seen (so far) for managing dynamic modular apps. Of course if you have the ability to make changes to the underlying runtime then you can do even more, which is why the Jigsaw project is interesting - but I hope they retain compatibility with core OSGi standards.
    Ok. As long as most users can ignore the complexity :). Although I think the concept is fine (if a bit mindbending to implement), the actual import/export definition in the MANIFEST.MF is clunky. (Again a pom-style definition might be clearer and fit nicely into people's development.) Again, I do think the concepts are fine, but just like Java CanDI (JSR-299) cleans up and modernizes dependency injection based on years of experience, I do think the concepts behind OSGi need cleaning and simplification before going into JavaEE 7. (i.e. junk the service API, use pom.xml, use META-INF/beans.xml - webbeans, and simplify Bundle.).
  34. Re: New Article: Java EE 6 Overview[ Go to top ]

    profiles? just another way to sell licenses/support for tomcat. who really needs an app server nowadays? just go for an osgi container with servlet+cluster support and an administration console.
  35. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik,
    profiles? just another way to sell licenses/support for tomcat.
    - Not sure what you are getting at here. There are plenty of open source vendors that won't charge you a penny to use their Java EE compatible container. That being said, I can undestand if this is just a matter of venting frustrations at what you perceive as "evil" vendors - that's why I personally am agnostic of anyone that looks and smells like they are just another vendor, perhaps in a glossier, more deceptive package.
    who really needs an app server nowadays?
    - FYI, plenty of people term Tomcat an application server. Indeed, one goal of the web profile is to blur some of these lines so that it is not a false dichotomy.
    just go for an osgi container with servlet+cluster support and an administration console.
    - That's pretty close to what a Web Profile compatible application server will look like, BTW. To boot, your applications would be 100% open, interoperable and portable. Cheers, Reza
  36. Re: New Article: Java EE 6 Overview[ Go to top ]

    just go for an osgi container with servlet+cluster support and an administration console.


    - That's pretty close to what a Web Profile compatible application server will look like, BTW. To boot, your applications would be 100% open, interoperable and portable.

    Cheers,
    Reza
    The point i raise in here is that profiles are pretty close to letting users choose what they want in their prefered app server. While OSGi, mature for years, enables much finer control over the components enabled in the infrastruture and the applications running on it, so why not using it today? Because, "evil" app server vendors predict lightweight servers (osgi based), the new generation of servers, taking some market share, while they are not capable to deliver a decent one (osgi based server) in the timeframe expected by market, they create a lightweight app server profile called web as a transition and keep their consumer base alive. why deploying ears, wars? let's deploy osgi bundles with ejb services, servlet services, ...
  37. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik, Not to be facetous, the issue, as Bill Burke pointed out, is that OSGi on it's own does not really offer much in terms of bread-and-butter concerns, as much as Java EE does, in my opinion. In fact, the only real-world OSGi deployment I have seen, solves a pretty high-end problem pretty far away from the average developer's concerns. That means that while OSGi is perhaps an interoperability concern for high-end Java EE servers, on it's own it's really not a useful Java EE "replacement". Perhaps a more helpful and relevant discussion is what you believe Java EE should adopt from the stack you suggest? Cheers, Reza
  38. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik,

    Not to be facetous, the issue, as Bill Burke pointed out, is that OSGi on it's own does not really offer much in terms of bread-and-butter concerns, as much as Java EE does, in my opinion. In fact, the only real-world OSGi deployment I have seen, solves a pretty high-end problem pretty far away from the average developer's concerns.
    Have you seen Eclipse deployed on any machines? It's a pretty popular IDE. http://www.eclipse.org/osgi/
  39. Re: New Article: Java EE 6 Overview[ Go to top ]

    James,
    Have you seen Eclipse deployed on any machines? It's a pretty popular IDE.

    http://www.eclipse.org/osgi/
    OK, I think now you are being a little facetious :-). To repeat my question, what do you think Java EE needs to take into consideration vis-a-vis *OSGi enterprise applications*? Do most real-world Java EE applications really need pluggability (which is what the goal of OSGi in Eclipse is)? If the answer is no, why should we pursue this instead of more mundane/prevalent concerns? Cheers, Reza
  40. Re: New Article: Java EE 6 Overview[ Go to top ]

    @Reza, but the answer is yes of cause. No need to question that. Put it that way: If you are not aware of the internet for example you would not miss it. (what have people done past 2000 years without it ?). Still it gives us new oportunities. Same thing with pluggable enterprise apps.
  41. James,

    Have you seen Eclipse deployed on any machines? It's a pretty popular IDE.

    http://www.eclipse.org/osgi/


    OK, I think now you are being a little facetious :-).

    To repeat my question, what do you think Java EE needs to take into consideration vis-a-vis *OSGi enterprise applications*? Do most real-world Java EE applications really need pluggability (which is what the goal of OSGi in Eclipse is)?
    actually OSGi is all about modularity, so the question should be:   do Java EE applications need modularity? perhaps the ongoing work at LinkedIn is a better example:   http://blog.linkedin.com/2008/06/10/osgi-at-linkedin/   http://raibledesigns.com/rd/entry/building_linkedin_s_next_generation I'd also suggest you skim through our introduction to OSGi at:   http://manning.com/hall/Hall_MEAP_01.pdf because it's not an all-or-nothing solution, you can use as much or as little as you like.
    If the answer is no, why should we pursue this instead of more mundane/prevalent concerns?

    Cheers,
    Reza
    ah, but what if the answer is yes?
  42. Stuart, OK, let's try this discussion another way -- the trouble is that I've looked at OSGi and it really seems like bloatware that is likely to make application servers heavier - not more lightweight. Hence, it's a throwback to the past, hardly anything to stive for. In essence, Java EE, .NET, Rails, etc are going the opposite diection and driving towards perfecting basic usability for mere mortals instead distant concerns that seem academic/exploratory at best. Now, I'll readily admit I can afford to be more anti-hype than the average individual. For one, I have the luxury of having interesting work, not being too worried about padding my resume with buzz-words or be under any compulsion to sell "innovative" products or services to my clients. Indeed, my clients in particular rely on me to give them solid solutions, not necessarily "cool" solutions. Truth be told, I secretly hope that era is dead with the current global down-turn... Sadly, this isn't true of vendors (although clearly, Bill Burke of JBoss seems to be foregoing hype too). Hence, a lot of them are or will finds ways to incorporate an OSGi container to their application servers in ways that interoprtate pretty seamlessly with Java EE. I would suspect almost all application servers that sell features like clusering and load balancing will have these features soon. So, in effect, the folks that really believe OSGi is worth their while will have access to it, effectively being test subjects without dragging the rest of us along for the ride. If these "test cases" do indeed succeed and there are more real world deplyements of OSGi outside of a niche market, you can bet it will be in Java EE. Until then, the wisest course is to treat it like a vendor-specific feature or just an optional JSR or two that aren't a required part of the platform. Make sense? Or do folks really that sure they desparately need OSGi enough to encumber the rest of us with heavier servers? Cheers, Reza
  43. Re: New Article: Java EE 6 Overview[ Go to top ]

    the trouble is that I've looked at OSGi and it really seems like bloatware that is likely to make application servers heavier - not more lightweight. Hence, it's a throwback to the past, hardly anything to stive for.
    That's the most ironic comment I've read in a while. Calling OSGi bloatware in a discussion about JEE? Are you on drugs? OSGi came from the mobile device space. The equinox 3.4.2 jar is under a meg.
  44. Re: New Article: Java EE 6 Overview[ Go to top ]



    Make sense? Or do folks really that sure they desparately need OSGi enough to encumber the rest of us with heavier servers?

    Cheers,
    Reza
    OSGi heavier server? I don't want to discuss the merits of the OSGi implementation. but what can you tell me of applications deployed to application servers, with inside the ear files numerous jars that are duplicated in each application? Why numerous jars inside each ear? because you have to isolate the types in the application classpath, avoid classloader conflicts on application levels, and to avoid deploying application types in app server classloader since this could cause conflicts on the app server or applications. The classloading model in JEE can quickly lead to a much heavier app server and/or applications! See you in JEE 7
  45. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik, OK, this post sheds a bit more light on what the underlying miscommunication is. The problems you are mentioning are far more prevalent/acute in Tomcat based applications that depend on large amounts of third-party libraries specific to an application. Most Java EE 5 applications, on the other hand tend to have far fewer jar depenencies to begin with because the container runtime provides a vast majority of the functionality. Now, if you are not going the Java EE route, it indeed might make a lot of sense for you to look into OSGi... About the "OSGi is lightweight" comment, I think that's pretty easy to clarify - Tomcat+OSGi or just Tomcat - which is lighter? Clearly the latter, correct? The same would be true of any application server conforming to the Web or Basic Profile... A relatively mechanical repetition of the "Java EE is heavyweight" charge is unfortunete at best. An interesting discussion could be why you would believe this vis-a-vis the current content of the profiles?. Peace, Reza
  46. Re: New Article: Java EE 6 Overview[ Go to top ]


    The problems you are mentioning are far more prevalent/acute in Tomcat based applications that depend on large amounts of third-party libraries specific to an application. Most Java EE 5 applications, on the other hand tend to have far fewer jar depenencies to begin with because the container runtime provides a vast majority of the functionality.
    Actually until recently I was employed by one of the leading app server vendors, and most of the customers issues are related to classloading, clustering, jdbc or jms in general. Lots of bad practices are applied by developers, and the practice of numerous jars added to ears is more common than one could imagine. Sometimes you find one application server sized amount of jars inside an ear.... While a number of types in the application classpath might be helpful, in most of the time you dont need them, or they cause side effects. (Ideally, only JEE API interfaces should be in the application classpath, nothing more). When you need some types, first of all you dont know if the library is in your classpath, since this is not documented by the vendor neither in JEE standard, and secondly, you find out that you need a different version of that library, so you embed it and its dependencies inside your ear. This vast set of types in the app classpath will vary by app server / version.
    An interesting discussion could be why you would believe this vis-a-vis the current content of the profiles?.

    Peace,
    Reza
    I have no problem with the content, neither I'm tagging JEE as heavy. I want JEE running and providing a decent component system with classpath isolation, predictable and with dependency management capabilities... so OSGi.
  47. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik, OK, point taken. I'll mention it in the EG, although I don't necessarily agree that these are generally applicable concerns. If nothing else, it might accelerate the development of JSR 277 and JSR 291 that I just mentioned in the previous post, not to mention the vendor specific support...I know a number of larger vendors are hankering after this anyhow...believe it or not, it has come up a few times in JSR 316... Happy now, I hope? :-) Cheers, Reza
  48. If nothing else, it might accelerate the development of JSR 277 and JSR 291 that I just mentioned in the previous post
    JSR 291 has been approved and released while JSR 277 is still MIA ... did you perhaps mean JSR 294?
  49. Stuart,
    did you perhaps mean JSR 294?
    Not sure exactly what the current status of the OSGi/Java (dynamic) modularity specs are. As I said, I am currently an OSGi skeptic and am really waiting to see what happens after the dust settles a bit more. If you are familiar with the Gartner Hype Cycle, I looks to me as if OSGi is currently in the "Inflated Expectations" phase... Anyways, no one is insisting that you agree with me :-). Cheers, Reza
  50. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik, Looks like you are a SpringSource consultant? I'll admit that's a bit uneasy in terms of using what you say as the basis for input to the EG. After all, SpringSource is represented in the Java EE 6 EG, so viewpoints should be expressed directly there? Again, perhaps the best thing to do in order to remove the appearance of impropriety is add a signature? Regards, Reza ---------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  51. Re: New Article: Java EE 6 Overview[ Go to top ]

    Stuart, I don't usually judge people based on who they are, but what they say. However... Your name seemed familiar and looks like you are an OSGi framework developer and the author of OSGi in Action. I'll have to admit, for a skeptic like me, it does make me question the merit of some of what you say... I apologize profusely if I'm off-base. Perhaps the best thing is to add who you are to your signature?...speaking of which, I should probably do the same... Cheers, Reza ---------------------- Independent Consultant Expert Group Member, Java EE 6, EJB 3.1 Author, EJB 3 in Action
    Erik,

    Looks like you are a SpringSource consultant? I'll admit that's a bit uneasy in terms of using what you say as the basis for input to the EG. After all, SpringSource is represented in the Java EE 6 EG, so viewpoints should be expressed directly there?

    Again, perhaps the best thing to do in order to remove the appearance of impropriety is add a signature?

    Regards,
    Reza
    ----------------------
    Independent Consultant
    Author, EJB 3 in Action
    Expert Group Member, Java EE 6 and EJB 3.1
    Hmm, anyone could argue that you don't publish the source of your income so it is unknown who pays your bill. Try again. Guido
  52. Re: New Article: Java EE 6 Overview[ Go to top ]

    Guido,
    anyone could argue that you don't publish the source of your income so it is unknown who pays your bill.
    Actually, it is standard practice to disclose who you are in this sort of discussion, especially for many commercial vendors. In fact, it is standard practice for folks that work with me as consultants, so I have been lax myself. That being said, I know many open source and consulting companies believe these practices do not apply to them... And I'm proud to say I don't have any problems disclosing how my bills get paid :-). So what are you hiding (just kidding)? :-). Cheers, Reza ---------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  53. Re: New Article: Java EE 6 Overview[ Go to top ]

    Guido,

    anyone could argue that you don't publish the source of your income so it is unknown who pays your bill.


    Actually, it is standard practice to disclose who you are in this sort of discussion, especially for many commercial vendors. In fact, it is standard practice for folks that work with me as consultants, so I have been lax myself. That being said, I know many open source and consulting companies believe these practices do not apply to them...

    And I'm proud to say I don't have any problems disclosing how my bills get paid :-). So what are you hiding (just kidding)? :-).

    Cheers,
    Reza
    ----------------------
    Independent Consultant
    Author, EJB 3 in Action
    Expert Group Member, Java EE 6 and EJB 3.1
    Nothing to hide and nothing personal, really. And I agree that is a good practice to disclose our own "interests" when the elements put into discussion are not limited to "pure" technical points but are biased by other factors (I guess you know what I mean). But I simply think that stating "Independent Something" means nothing. It doesn't prevent someone from expressing (undisclosed) biased opinions. Guido. P.S. I don't know if the evil mix of my limited english knowledge and "interaction thru writings" can cause some misunderstanding, but I would ensure that there is no offensive intents in what is expressed here.
  54. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik,

    Looks like you are a SpringSource consultant? I'll admit that's a bit uneasy in terms of using what you say as the basis for input to the EG. After all, SpringSource is represented in the Java EE 6 EG, so viewpoints should be expressed directly there?

    Again, perhaps the best thing to do in order to remove the appearance of impropriety is add a signature?

    Regards,
    Reza
    ----------------------
    Independent Consultant
    Author, EJB 3 in Action
    Expert Group Member, Java EE 6 and EJB 3.1
    Gosh, Spring consultant? you really trying VERYYY far I think signatures might leads one to wrongly judge another ones background, and only attitudes counts. You can search my name on internet, you will find that I never touched one line of code from Spring, but I'm very active in open source. By the way, I really appreciate SpringSource adopting OSGi, but even more I appreciate Glassfish, since it's a container implementing standards (JEE) and runs on OSGi. ... and I've been working with OSGi long before SpringSource was founded and OSGi was hype. Is that so rough to understand that java/jEE needs a module system just like OSGi?
  55. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik,
    Gosh, Spring consultant?
    OK, my bad. Upon closer inspection, it looks like you work/worked for a company called "Spring Consulting", not SpringSource. Sorry for the confusion. Cheers, Reza
  56. Re: New Article: Java EE 6 Overview[ Go to top ]

    Upon closer inspection, it looks like you work/worked for a company called "Spring Consulting", not SpringSource.
    He doesn't/didn't (unless Belgium is now part of Norway), but don't let that spoil your fun ;-) Andy -- More Independent than anyone else Consultant DataNucleus
  57. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik,

    Gosh, Spring consultant?


    OK, my bad. Upon closer inspection, it looks like you work/worked for a company called "Spring Consulting", not SpringSource. Sorry for the confusion.

    Cheers,
    Reza
    Too many Erik Bengtson's in this little world, and you got the file. Here the "original" ;-) http://www.linkedin.com/pub/0/602/2b8
  58. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik,
    Too many Erik Bengtson's in this little world
    OK, again, thanks and sorry for the confusion. Just to make sure, this isn't anything personal - for better or for worse, things just smelled a little fishy and I will admit the discussion around OSGi did seem a little too persistent/tangential (but that could be purely a matter of perspective)... After all, I spent a bit of my own time writing the article and trying to respond to questions the best I can. Obviuosly, I'd rather the discussion doesn't veer too far off center...but it's fine if it has to - hey, maybe I learn something useful :-). Cheers, Reza ---------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  59. Re: New Article: Java EE 6 Overview[ Go to top ]

    I will admit the discussion around OSGi did seem a little too persistent/tangential (but that could be purely a matter of perspective)...
    Partially this is because many of us in the OSGi community believe quite seriously that OSGi is the future of all Java development, and certainly of enterprise development. Therefore it cannot be tangential. You can disagree of course, that's fine, but you will be assimilated.
  60. Re: New Article: Java EE 6 Overview[ Go to top ]

    Neil,
    Partially this is because many of us in the OSGi community believe quite seriously that OSGi is the future of all Java development, and certainly of enterprise development. Therefore it cannot be tangential. You can disagree of course, that's fine, but you will be assimilated.
    I know (or hope!) that this is a joke, but the scary part is that is really how many people in Java "thought leadership" think, leading to a ton of nasty, unproductive and downright evil actions that nothing short of a "crusade" (or even worse, remeniscent of the fascist movements of the more modern times). It might be useful to remind ourselves that "the world is just too large and complex to be one empire" :-). Admittedly, some of the early proponents of Java EE had such an attitude too. I am glad that at least that aspect of Java EE as a standard is a thing of the past... Cheers, Reza ---------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  61. About the "OSGi is lightweight" comment, I think that's pretty easy to clarify - Tomcat+OSGi or just Tomcat - which is lighter? Clearly the latter, correct?
    OK, but what about this:   Tomcat + N x WARs with duplicate copies of libraries   Tomcat + OSGi + N x bundles with shared libraries now it's not so clear, as sharing libraries can save a lot of space... [PS. I'm not pushing for OSGi to go into Java EE 6, but I want to clear up misconceptions about it]
  62. Stuart,
    I'm not pushing for OSGi to go into Java EE 6, but I want to clear up misconceptions about it
    Understood. Maybe folks like yourself are indeed right, it's just that I think it's still way too early to tell and this stuff is not exactly vanilla...it'd be a shame to add something prematurely just to regret it later... Cheers, Reza
  63. OK, but what about this:

      Tomcat + N x WARs with duplicate copies of libraries

      Tomcat + OSGi + N x bundles with shared libraries

    now it's not so clear, as sharing libraries can save a lot of space...
    But, seriously, in most contexts the space saved is marginal. Most of it is disk space, and only some of it is actual memory consumed by byte codes of class libs. Contrast that space savings with the, ideally, standalone nature of a WAR deployment. A standlone WAR is just that. Standalone. You take the WAR, you plop it in your container, and, shazam, it works. Kind of like the difference betwee a Windows EXE or Linux binary and all their dependencies and "DLL Hell" vs a Mac and its "drag and drop install". As a whole, Java has succeeded really well in being able to almost painlessly deliver binary applications. And the WAR has been particularly successful I think. Setting up a web app on a server in Java is typically far easier than the shenanigans involved with a typical Apache fronted application. I appreciate the desire for jar file and CLASSPATH clarity, there's a lot of rope within the JEE spec to hang folks relying on specific classloader functionality and dependencies. But the problem, to me, isn't so much duplicating jars in deployments as just being able to clearly specify which jars to use (including those bundled within the WAR file).
  64. Re: New Article: Java EE 6 Overview[ Go to top ]

    Kind of like the difference betwee a Windows EXE or Linux binary and all their dependencies and "DLL Hell" vs a Mac and its "drag and drop install".
    It would be interesting to know whether this is accomplished on the Mac by ignoring dependencies or by dealing with them in a structured way. I have no knowledge of this but I'd be surprised if it's the former.
    As a whole, Java has succeeded really well in being able to almost painlessly deliver binary applications.

    And the WAR has been particularly successful I think. Setting up a web app on a server in Java is typically far easier than the shenanigans involved with a typical Apache fronted application.

    I appreciate the desire for jar file and CLASSPATH clarity, there's a lot of rope within the JEE spec to hang folks relying on specific classloader functionality and dependencies.

    You've never dealt with dependency conflicts within a war?
    But the problem, to me, isn't so much duplicating jars in deployments as just being able to clearly specify which jars to use (including those bundled within the WAR file).
    OSGi provides equivalent functionality and more. I've found it much easier to get a bundle working on an OSGi container than to get a war working in say, websphere or weblogic or JBoss. I don't know if you've tried OSGi for yourself (if you use Eclipse 3+ you are already using it) but if you haven't you should really give it a try.
  65. Re: New Article: Java EE 6 Overview[ Go to top ]

    It would be interesting to know whether this is accomplished on the Mac by ignoring dependencies or by dealing with them in a structured way. I have no knowledge of this but I'd be surprised if it's the former.
    It's a combination of relying on system provided Frameworks, and bundling the other dependencies with the App. The Framework dependencies are versioned, but also they're much more loosely bound than typical static libraries, because of how Obj-C works.
    You've never dealt with dependency conflicts within a war?
    Of course I have, thus the word "ideally". But, in general, I think the WAR model and it's composite standalone application approach has been more successful than not as a binary distribution mechanism. And bundling dependencies rather than placing the burden on the consumer to hunt them down is more a benefit than not.
    OSGi provides equivalent functionality and more. I've found it much easier to get a bundle working on an OSGi container than to get a war working in say, websphere or weblogic or JBoss.

    I don't know if you've tried OSGi for yourself (if you use Eclipse 3+ you are already using it) but if you haven't you should really give it a try.
    The initial comment was regarding duplication of jars, etc., and I was simply claiming that there are advantages to bundling jars over relying on a shared, installed based in terms of ease of administration and installation. The problem with the WARs is not necessarily the WAR format at all, rather its the way that the code is written and how they interact with the classloaders. Perhaps if written differently, the (reasonably) isolated classloader structure of the WAR wouldn't be a problem. The other issue is when you're dealing with the classloader environment of, say, and EJB container. For example, if you take two WARs and bundle them with some EJBs in an EAR, GF, by default, flattens the hierarchy, putting ALL of the libs and such from both WARS in to the same classloader. You can imagine what fun that can be. But, that's an implementation detail of GF (and can be configured away), and the issue there isn't so much that it does that (while it can be problem), the issue is the JEE spec doesn't specify this behavior, so GF is "in spec", but may behave differently than other containers in this regard. More formal specifications can clarify this issue (no doubt I'm guessing well clarified in the OSGi spec) without tossing out the entire JEE component model and feature set. My limited experience with OSGi didn't surface the concept of "meta assemblies" that let you bundle "bundles" together and treat that as a singular, normal OSGi bundle, that had several of it dependencies internally satisfied, in the same way that ostensibly a WAR could be self contained. But that concept may well exist. P.S. I think it is poignant that the CAPTCHA for this post (after a couple of refreshes) is "go struggling". What a fine motto for CAPTCHA.
  66. Re: New Article: Java EE 6 Overview[ Go to top ]

    You've never dealt with dependency conflicts within a war?


    Of course I have, thus the word "ideally". But, in general, I think the WAR model and it's composite standalone application approach has been more successful than not as a binary distribution mechanism.

    And bundling dependencies rather than placing the burden on the consumer to hunt them down is more a benefit than not.
    I think these are related but separate issues. What OSGi gives you is a clear specification of dependencies. It doesn't address how to resolve those dependencies. I agree that is something that needs to be addressed but knowing what the dependencies are is the first step.
    The initial comment was regarding duplication of jars, etc., and I was simply claiming that there are advantages to bundling jars over relying on a shared, installed based in terms of ease of administration and installation.

    The problem with the WARs is not necessarily the WAR format at all, rather its the way that the code is written and how they interact with the classloaders.
    It's seemed to me for a long time that the default classloader hierarchy of JEE app-servers is upside down. In most everything else we do in Java, things in a narrower scope things from wider scopes. But in an JEE app-server it's the other way around. But in any event the WAR model is too simplistic. Sure, it's less complex but simple is only better if it meets your needs and the war model has often not, especially when using third party wars. The problem is that while it's easier at first to just bundle in what you need with your app, if you don't keep track of your dependencies, it comes back to bite you. For example, we have some custom shared libraries that we use in our applications. In the past, these were just packed up into the application that used them. The problem is that later when a second application needs to add something or fix some code, it's difficult to know what version of the source the first application is running on. If we need to debug an issue, or do an emergency fix, we have to scramble to find the source file and hope that it's right one. A lot of this could be solved by using a better source control system but OSGi goes right at the heart of this issue. And by doing that it allows for things like automatic dependency resolution. OSGi doesn't really prevent you from delivering all of your dependencies with your application. It just allows you to specify what those dependencies are. The other thing that makes OSGi great, IMO, is the ability to specify which packages in your jars are public. This makes it so much easier to enforce modularity and makes it obvious when your chosen points of coupling are not sufficient.
  67. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik,

    OK, this post sheds a bit more light on what the underlying miscommunication is.

    The problems you are mentioning are far more prevalent/acute in Tomcat based applications that depend on large amounts of third-party libraries specific to an application.
    It must be me not clearly understanding the point. I never had any classloading problems with tomcat (with the exception of something related to commons-logging). Unless you are "smart" enough to clueless put jars in commons/shared dirs. I think everybody have experienced classloader problems with other popular app server, fixed with some strange not always working container settings or "simple" second instance installation. Yes, you pay this deploying the same jar in several wars, but it works. Always. Guido
  68. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik,

    Not to be facetous, the issue, as Bill Burke pointed out, is that OSGi on it's own does not really offer much in terms of bread-and-butter concerns, as much as Java EE does, in my opinion.
    exactly, JEE does not offer bread and butter concerns, since: I want to be able to swap between versions of an application while the running transactions are not interrupted a new version is activated for new transactions. A few application servers support it, but this is natural in OSGi, so this is case for deploy OSGi bundles with EJBs, JSPs or Servlets... Not high end IMO Classloading in JEE servers is not fully standardized. In JEE you often find unexpected types in your classloader, but you haven't asked for those. A lot of times you have conflicts of multiple versions of same types. You can have regressions in your application when you upgrade your app server, since new types on the app server classloader could somehow impact your application (even if the application respects 100% the standards). You must use app server extensions to isolate/set priority on the types embedded in your ear/war. This list could go on... Deployment in JEE is highly dependent on the app server. the deployment API never succeed.
    on it's own it's really not a useful Java EE "replacement". Perhaps a more helpful and relevant discussion is what you believe Java EE should adopt from the stack you suggest?
    The idea is not to replace, but to be complementary. The application server becomes an OSGi container with several services, such as datasources, ejb servers, servlet servers, jca servers, etc. User applications are deployed as OSGi bundles aside with the many other bundles from the applicaton server. In this mode, classloading would be highly controlled by OSGi, all JEE apis could become OSGi services, and backward compatibility could be easily supported for JEE 5. In summary my proposal is: turn the app server an OSGi container, bundle all APIs and implementations, deploy application bundles on the same level as the app server bundles.
  69. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik,
    In summary my proposal is: turn the app server an OSGi container, bundle all APIs and implementations, deploy application bundles on the same level as the app server bundles.
    I think we might be wasting our collective breaths here a little bit. I do not see the issues you mentioned as being all that critical, certainly not compared to the APIs in Java EE. That being said, many vendors are doing exactly what you are suggesting, but not by abandoning the current packaging structure that's been field-tested for quite a while. If that indeed is well-adopted, supported and deployed in the real world, I am sure it will be standardized. Frankly, I think that's a stretch at best and OSGi will either be hidden as an infrastructure concern or hit a dead-end because of being too complex/overkill by then. I certainly see this concern being out of place when the trend is towards things like Rails and Grails. Not to mention .NET has more or less abandoned chasing high-end concerns in favor of bread-and-butter usability. Cheers, Reza
  70. Re: New Article: Java EE 6 Overview[ Go to top ]

    ...I do not see the issues you mentioned as being all that critical, certainly not compared to the APIs in Java EE.

    That being said, many vendors are doing exactly what you are suggesting, but not by abandoning the current packaging structure that's been field-tested for quite a while.
    I guess you are mostly concerned about APIs, while my concerns are mostly operational. The field-tested packaging you mention causes many troubles, since the classloading model is incomplete. And yes, the these issues are critical since they happen very often, reducing productivity and increasing TTM, since even most the "senior" developers are unware of classloaders, libraries and all. Most of these issues can only be solved with a component model like OSGi. I have to repeat again that OSGi is not just about being pluggable, but it's a component infrastructure capable to solve low level bread-and-butter issues that developers should not worry about, but are facing daily, and these issues are solved by OSGi. If you don't think these issues are critical then you probably have to get more input from the field.
  71. Re: New Article: Java EE 6 Overview[ Go to top ]

    Erik,
    If you don't think these issues are critical then you probably have to get more input from the field.
    As I said, the problem is that I already have (as has the rest of the folks working in various groups), but there's nothing saying I can't try again :-). And FYI, managing operations for clients is something I have to tackle in many instances, although I'll admit I am undoubtedly a developer at heart :-). Cheers, Reza
  72. Re: New Article: Java EE 6 Overview[ Go to top ]

    While OSGi, mature for years, enables much finer control over the components enabled in the infrastruture and the applications running on it, so why not using it today?
    I think you've answered your own question. Why do you need J2EE?
  73. Re: New Article: Java EE 6 Overview[ Go to top ]

    While OSGi, mature for years, enables much finer control over the components enabled in the infrastruture and the applications running on it, so why not using it today?


    I think you've answered your own question. Why do you need J2EE?
    James, I don't, but everyday we face different companies using so many different infrastructures, I mean mostly application servers, and you have to deal with it. One day those that are capable to deliver software and services (IBM, Oracle, Sun JBoss, ...) to mass, will understand that OSGi is not only for high end systems (app servers, eclipse, ...) but can also suits end-users to solve their classpath hell issues, modularity, deployment, versioning, ... For this day to come, there should be an implementation model that enables JEE running on the top of OSGi as well as new applications or existing applications (backward compatibility) There are already public examples of JEE APIs running on OSGI, such as OpenEJB, DataNucleus (JPA), servlets, ... Years ago I implemented JCA and JTA in OSGi.. so OSGi+JEE is not impossible.
  74. JSR 299 should be mandatory![ Go to top ]

    I'm kinda surprised and also disappointed that JSR 299 isn't considered as absolutely mandatory and an integral part of JEE 6. IMHO it's one of the greatest things in that version (and shortly after sliced bread ;D). Seriously, take your time to iron out things but, by all means, include it. If that means the final spec gets delayed, then so be it. Additional benefit might be that some other useful stuff like JSR 303 gets included as well. Also since it is such an integral part touching all / almost all others there surely will show up some issues which need to be fixed but the earlier we start the earlier we're done. E.g. if it doesn't get included in JEE 6 then we have to wait for JEE 7 and then until the first compliant servers are released - which will be in like 4-5 years (considering how long it took to get JEE 5 compliant ones) which is definitely too long. Therefore _please_ don't release it without JSR 299. Take you time to iron out things but don't release without it! Also thanks a lot for all the work you invest in this (since I just want to use the opportunity).
  75. Re: JSR 299 should be mandatory![ Go to top ]

    Brandon, Thanks for the kind words and constructive feedback. Rest assured, everyone is trying hard to get JSR 299 into Java EE 6, including the JSR 299 EG itself. Cheers, Reza
  76. Why no mail in web profile?[ Go to top ]

    I was a bit surprised to see that JavaMail was not in the web profile. In my wiew a lot of applications on the web includes mail in one way ore another.
  77. Re: Why no mail in web profile?[ Go to top ]

    Mikael,
    I was a bit surprised to see that JavaMail was not in the web profile. In my wiew a lot of applications on the web includes mail in one way ore another.
    OK, I'll try to forward this onto the EG. This might not be that big of a deal really since JavaMail doesn't really involve much configuration or an integration effort. Cheers, Reza
  78. Just catching up.[ Go to top ]

    First, again, thanks to Reza for these articles that he's been making, and helping summarize the activity for those of us who don't follow the gritty details of the EGs. Always appreciated. Even being WebBeans agnostic, and a touch ignorant (having never played with them), it seems to be that this is the time that WebBeans should come in to JEE. It seems to me that while perhaps still with problems, with all of the Seam and other experience, they're mature enough to enter JEE now rather than in JEE 7, which won't be for several years. For example, JPA 1 had real problems, but was very usable out of the box, and the introduction of JPA to JEE pushed ORMs even more mainstream than they were before. Despite it's issues, I don't think anyone really laments the introduction of JPA to JEE, and we now look forward to JPA 2 because we have a couple years of JPA 1 experience under our belts. The Web Profile is what's going to push "JEE" in to further adoption. Folks talk "Oh we use JEE", when in fact they're just using Tomcat and bolting on extra services. The Web Profile will eliminate that concept. It offers the facilities that the vast majority of "single server" developers want. With the JEE Web Profile there will be further disincentive for folks to "roll their own" application services and servers. With that said, I think JAX-RS should be added to the Web Profile. It's easy to argue it's not necessary, since it could be added "after market". But there's valid points that JAX-RS offers a much better development model than pure Servlets, and it could even be argued that JAX-RS and Servlet 3.0 should have a lot of overlap. I also agree about JavaMail being in the Web Profile. Again, this helps round it out for the bulk of the single server application authors out there. They get a nice tidy package that will take them very far down the field. I have no comment on the OSGi debate. I know several servers are being built upon modular platforms (GFv3 for one). Folks want to extend their applications with OSGi will be free to do it using proprietary methods within the servers. But, despite the rise of OSGi, there is still the dark horse of JSR-277 (I think). And that's either going to clarify a lot or muddy the waters even worse, giving even more reason to not commit to a particular modularity API beyond the current component model within JEE. JEE 6 shows the web space architecture flattening even more. In the past you had your Web tier remotely talking to the business tier remotely talking to the DB tiers. Now, the web and business tiers are typically combined, segregated by transaction boundaries, and the deployment model of JEE. With EJB Lite, even that is going away with the Web Tier containing the whole kit, and with JAX-WS and JAX-RS, the Web Tier is taking the place of what used to be the RMI-IIOP tier, while fatter clients (Rich apps, AJAX) are speaking directly to server APIs via the HTTP tier. So, we come full circle. I still eagerly await EJB 3.1, EJB Lite, and the Web Profile. I think they're going to hit a very nice sweet spot in the development stack.
  79. Re: Just catching up.[ Go to top ]

    Will, First, thanks for the kind words and great to hear from you again. In the end, I'm just doing what I think is right and it's a better investment of time than playing video games, for example :-). You are right that WebBeans need not be pefect to be in Java EE 6. My gut feeling is that it will happen as soon as the public review is over. Point taken on JAX-RS and JavaMail too. I'll try to follow it up on the EG... And you right about JSR-277 and JSR-291 (more closely related to OSGi). The developement of these two JSRs could be a vehicle for vendors to figure out what they really think they should do and how to go about doing it. If OSGi is really as important as some folks are saying, there is nothing saying it could not be included in Java SE or Java EE in the very near future, besides being available at a vendor-specific level. Cheers, Reza
  80. Re: Just catching up.[ Go to top ]

    JEE 6 shows the web space architecture flattening even more. In the past you had your Web tier remotely talking to the business tier remotely talking to the DB tiers.
    Is there anyone who remembers how it was treated anyone saying that the above architecture was inappropriate at best ? (Well, the correct word was another, but is left to reader)


    Now, the web and business tiers are typically combined, segregated by transaction boundaries, and the deployment model of JEE.

    With EJB Lite, even that is going away with the Web Tier containing the whole kit, and with JAX-WS and JAX-RS, the Web Tier is taking the place of what used to be the RMI-IIOP tier, while fatter clients (Rich apps, AJAX) are speaking directly to server APIs via the HTTP tier.

    So, we come full circle.

    I still eagerly await EJB 3.1, EJB Lite, and the Web Profile. I think they're going to hit a very nice sweet spot in the development stack.
    Having closed the circle, does it still make sense the EJB concept ? Do we need session beans when these components are embedded in the web tier ? To solve which problem ? Isn't better a real lightweight old presentation layer+(POJO) business layer+orm ? Guido
  81. Re: Just catching up.[ Go to top ]

    Guido,
    does it still make sense the EJB concept? Do we need session beans when these components are embedded in the web tier? To solve which problem? Isn't better a real lightweight old presentation layer+(POJO) business layer+orm ?
    It's a good question and I am glad someone brought it up. Java EE 6/WebBeans relies on EJB 3.1 to provide enterprise services such as transactions (programmatic and declarative), security (programmatic and declarative) and the extended persistence context with stateful session beans, not to mention the more "high-end" services such as messaging, remoting, SOAP web services, asynchronous invocation, scheduling and the like. On the other hand, JavaBean components that are not EJBs do provide a sub-set of EJB-ish functionality such as a component life-cycle, dependency injection and interceptors - this subset is not really sufficient for the business component/service tier. As a side-note, EJB Lite does not include the more "high-end" EJB 3.1 features, although I am getting feedback to the effect that things like scheduling and asynchronous procesing is useful even for vanilla web applications, so they should probably be added to EJB Lite. For completeness, it feels like I should state that EJB 3.1 beans are nothing more than POJOs (since you seem to have stressed POJO/lightweight) with annotations that makes the container apply various services including entry into the JNDI registry, thread-safety, scope and a component life-cycle. Cheers, Reza ----------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  82. Re: Just catching up.[ Go to top ]

    Guido,

    does it still make sense the EJB concept? Do we need session beans when these components are embedded in the web tier? To solve which problem? Isn't better a real lightweight old presentation layer+(POJO) business layer+orm ?


    It's a good question and I am glad someone brought it up.

    Java EE 6/WebBeans relies on EJB 3.1 to provide enterprise services such as transactions (programmatic and declarative), security (programmatic and declarative) and the extended persistence context with stateful session beans, not to mention the more "high-end" services such as messaging, remoting, SOAP web services, asynchronous invocation, scheduling and the like. On the other hand, JavaBean components that are not EJBs do provide a sub-set of EJB-ish functionality such as a component life-cycle, dependency injection and interceptors - this subset is not really sufficient for the business component/service tier.

    As a side-note, EJB Lite does not include the more "high-end" EJB 3.1 features, although I am getting feedback to the effect that things like scheduling and asynchronous procesing is useful even for vanilla web applications, so they should probably be added to EJB Lite.

    For completeness, it feels like I should state that EJB 3.1 beans are nothing more than POJOs (since you seem to have stressed POJO/lightweight) with annotations that makes the container apply various services including entry into the JNDI registry, thread-safety, scope and a component life-cycle.

    Cheers,
    Reza
    -----------------
    Independent Consultant
    Author, EJB 3 in Action
    Expert Group Member, Java EE 6 and EJB 3.1
    I have to confess that long time ago I used EJB (1.0 era) and never done it again (you might guess why). In 99.9% of the application I design the approach is exactly that explained before. From a transactional point of view, each request is surrounded by one transaction; each request is executed using one JDO PersistenceManager or Hibernate Session. Business Logic POJOs are instantiated with the ORM context to use in the execution of the actions required by the request. In this scenario, what is the positioning of an EJB ? Persistent object instances are "new" in each request since they must be bound the ORM context (PM or Session), so the lifecycle is managed by the ORM implementation. Business Logic ? And what the applicable container services would be ? Thread-safety ? No, since each instance has request scope. Life-cycle ? A really trivial Servlet filter accomplishes the job quite well. And what kind of session bean ? Stateless ?.......Embedded in the web application ? To gain what ? Instance pooling ? And the http request dispatching pool ? Stateful ? Yyyyyyes, maybe.....But we already have a servlet session...... My concern is that questionable evangelists blindly map layers to technologies, leading to applications where, for example, all the business logic is in EJB (just like putting a whole transaction in onClick() handler in any GUI app). You may say: "bad designers!!" Sure. But... Can you really state that J2EE promotion has always been realized trying to "teach" the correct way to adopt it ? Rather the contrary, I would say. Some months ago I argued about annotations, stating that, IMHO, they were not for configurations. "Yes", "right" were the common answers. And what a table name is ? And what a webservice endpoint is ? There is a wonderful chapter in "Advanced CORBA programming with C++" that deals with the positioning of CORBA objects in a system architecture: CORBA objects are boundary objects that deal with the triggering, from remote, of local processing, in turn, totally unaware of CORBA presence. Similar words would be welcome for J2EE. Before "Bitter EJB 100th edition" goes for printing. Guido
  83. Re: Just catching up.[ Go to top ]

    Some months ago I argued about annotations, stating that, IMHO, they were not for configurations.
    "Yes", "right" were the common answers.
    And what a table name is ?
    And what a webservice endpoint is?
    I agree completely. I can only attribute this trend to the constant ebb and flow of development trends: Everyone tightly couples their code to the persistence layer. It's easy and quick. Everyone is happy. Then things start to move a little. Maintenance becomes difficult. So people realize that there's a cost to this. The move this out of the code. That's more work but the maintenance becomes easier. People forget about issues created by coupling. A new approach to coupling appears. Everyone uses it. And so on an so forth. I predict that in a few years annotations will be seen as a problem. They may have real value but the way they are commonly being used is increasing coupling in a very bad way.
  84. Re: Just catching up.[ Go to top ]

    James, Good to see we are gravitating somewhat back to the center (at least from my perspective)... Please see my response to Guido for my take on annotations. Just to repeat for reference, they are an *option* for folks who prefer them and I think it is more than a bit presumptious to tell them they are wrong. In this instance, I'll go so far as to say they know best what's useful for them, not you or I and the issue is firmly gray, not black and white, as you seem to be suggesting. Nothing can ever be perfect in life and almost everything is a trade-off (if that were the case, life would be pretty boring, right?) However, I and many others find annotations to be much more productive, type-safe, IDE-friendly, concise and readable compared to any other alternative that I know of... Peace, Reza ---------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1 P.S.: Kindly do note my comment about "shouting matches" and "Jihads"...I don't think there is a problem is agreeing to disagree...
  85. Re: Just catching up.[ Go to top ]

    Kindly do note my comment about "shouting matches" and "Jihads"...I don't think there is a problem is agreeing to disagree...
    It's hard for me to take this comment seriously. You've taken a dismissive tone but play victim when someone takes you to task for it. You should try being less defensive and try to not take constructive criticism so personally. The main person I see 'fighting' in this thread is you. You've even gone as far as to question the integrity of others.
  86. Re: Just catching up.[ Go to top ]

    It's hard for me to take this comment seriously
    No, its hard to take you seriously. Look at your posts: "I think you've answered your own question. Why do you need J2EE?" "Have you seen Eclipse deployed on any machines? It's a pretty popular IDE." Reza is at least really trying to have quality discussion and is at least writing quality posts worth reading (even if he made small mistakes on the way which he had balls to admit). Your sarcastic "Have you seen Eclipse deployed on any machines" are uncalled for. You are not here to have quality discussion, you are here to troll or nerd rage for whatever reasons you have.
  87. Re: Just catching up.[ Go to top ]

    Your sarcastic "Have you seen Eclipse deployed on any machines" are uncalled for. You are not here to have quality discussion, you are here to troll or nerd rage for whatever reasons you have.
    I have to admit that was what I was thinking as well...guess I don't have to verbalize it now... That being said, perhaps it is best to move on. We can probably all do a little better - I most certainly can. These are issues we all care about, so some emotions boiling over perhaps is not that surprising... Cheers, Reza ---------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  88. Re: Just catching up.[ Go to top ]

    It's hard for me to take this comment seriously


    No, its hard to take you seriously. Look at your posts:

    "I think you've answered your own question. Why do you need J2EE?"
    "Have you seen Eclipse deployed on any machines? It's a pretty popular IDE."
    So the people I was responding to can imply that OSGi is some toy that no one is using. That's OK, right? Slamming a technology you don't really know anything about. Is that a quality post? And I'm not allowed to someone on it. I just want to make sure I know the rules. Is it just things that you care about that I can't be sarcastic about or is all sarcasm forbidden?
    Reza is at least really trying to have quality discussion and is at least writing quality posts worth reading (even if he made small mistakes on the way which he had balls to admit).
    It's not clear to me what I did to Reza that got him so offended. He's the one casting dispersions on my character. Oh and you too now.
    Your sarcastic "Have you seen Eclipse deployed on any machines" are uncalled for. You are not here to have quality discussion, you are here to troll or nerd rage for whatever reasons you have.
    Calling me a nerd is OK. But sarcasm is really bad. And I don't have any 'quality' posts here. That seems pretty mean. I'm struggling to understand this system but perhaps one day I'll be as wonderful as you are.
  89. Re: Just catching up.[ Go to top ]

    James,
    You've taken a dismissive tone
    - Sorry if that's impression you get. I'll try to do better. More imporatntly, so what do you think I have not addressed sufficiently? From my perspetive, I've read and carefully thought through every sensentce posted so far. Perhaps I've been lax in communicating my thoughts? That's certainly possible...
    play victim when someone takes you to task for it
    - As I've said already, I have no problem with answering questions (in fact, I've made every ettempt to answer any and all questions posed at least once, sometimes more than once). However, I don't think I (or anyone else) deserves to be heckled and that's what I see quite a bit of. In fact, it's a bit disturbing you feel the compulsion to "take someone to task" because they might not agree with you...that's certainly not a sentiment I feel often...but maybe that's just me...
    contructive criticism so personally.
    - Not sure where you got this impression from. Thus far, I have not taken anything personally. However, I do get the distinct feeling I am wasting my time vis-a-vis what I worked very hard to try to accomplish, mostly towards aims I gain little or nothing from. I don't want to bother posting fairly well-know netiquette rules here, they are in easy reach and pretty easy to follow - most of those rules of conduct were developed to keep impersonal discussions on the web useful for everyone. That being said, I do want to hear what constructive criticism you felt was not taken well, let's revisit it, with the caveat that I would appreciate a reasonable reaction to "let's agree to disagree" instead of a *dogged pursuit to force one's opinion on others*. One issue I've already made clear I am not interested in discussing is the applicability of OSGi in enterprise Java applications. *I've stated what I think more than once and nothing has been said yet that I did not aleady know*. I might also point out other folks with similar positions to mine not even bothering to mention it more than once... That being said, there is nothing saying the discussions around those shouldn't go on -- just that I don't need any part of it. Hope that's reasonable enough for you?
    The main person I see 'fighting' in this thread is you.
    - Sorry if that's impression you get. I'll try to do better. So what fights should I have avoided as you see it? It would certainly help me understand where you are coming from?
    You've even gone as far as to question the integrity of others.
    - Don't think I've questioned anyone's intergrity. Merely pointing out that things could be done better based on pretty prevalent practices for this kind of discourse. That's nothing personal, it is simply being careful to keep the playing field level and keep things transparent in a medium where hiding one's identity and agenda is all too easy. In fact, I've gone well out of my way to be as transparent as possible myself. Peace, Reza ---------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  90. Re: Just catching up.[ Go to top ]

    However, I don't think I (or anyone else) deserves to be heckled and that's what I see quite a bit of.
    I've heckled someone? Where?
    In fact, it's a bit disturbing you feel the compulsion to "take someone to task" because they might not agree with you...that's certainly not a sentiment I feel often...but maybe that's just me...
    I find it disturbing you need to twist my words into something I didn't say. If someone makes slanderous and/or demonstrably false statements against a technology that I am strongly in favor of, why shouldn't I take issue with that?
    contructive criticism so personally.
    Not sure where you got this impression from.
    The part of your posts where you accuse people of partaking in 'Jihad'. It's a passive-aggressive attack where you insult people while simultaneously taking on the role of the victim. Your comments are all wonderfully helpful but people who don't agree with everything you say are violent monsters.
    I do want to hear what constructive criticism you felt was not taken well, let's revisit it, with the caveat that I would appreciate a reasonable reaction to "let's agree to disagree" instead of a *dogged pursuit to force one's opinion on others*.
    You really don't see how you are personally insulting people with these statements? When did I try to force my opinion on anyone? Just because I don't think much of JEE, I'm forcing my opinion on someone? What kind of crazy logic is that? I really don't know what any of this BS you are trying to accuse me is coming from. I didn't mean to hurt your feelings but I haven't got patience for this kind of fragile ego nonsense. Can we just stick to technical stuff and not get all touchy-feely?
  91. Re: Just catching up.[ Go to top ]

    James, I said let's move on from this, but you are insisting on dragging this on, leaving me very little choice...
    I've heckled someone?
    - If you really need that pointed out, the "Eclipse" comment is a fairly good example. And I wasn't just talking about you.
    If someone makes slanderous and/or demonstrably false statements against a technology that I am strongly in favor of, why shouldn't I take issue with that?
    - Both claims are questionable at best. I have not slandered you or anyone else and have already thoroughly explained why this is not the case. And as I've mentioned (repeating myself yet again :-(), I really don't agree that you've established anything. That being said, it is entirely possible that in your mind you have. The point is to learn to take note and respect the where further argument is unproductive. I apologize beforehand if you find this last bit of advice demeaning - frankly you've left me little choice...
    The part of your posts where you accuse people of partaking in 'Jihad'.
    - Would a term like "dogged campaigning" suit you better? I think this post is a good case in point. It seems to me you can't help but have the last word...unfortunately, no one get's that every time.
    comments are all wonderfully helpful but people who don't agree with everything you say are violent monsters.
    - Here I go repeating myself yet again: You can disagree with me all you want. The point is to leave me alone when I ask it. Again, this post is a good case in point.
    I really don't know what any of this BS you are trying to accuse me is coming from. I didn't mean to hurt your feelings but I haven't got patience for this kind of fragile ego nonsense.
    - Great. Foul language and name-calling all in one sentence. Please calm down, stop and take a good look at what you are doing...it's getting harder and harder to deal with you and I'm thinking it's best to leave you alone...
    So the people I was responding to can imply that OSGi is some toy that no one is using. That's OK, right? Slamming a technology you don't really know anything about.
    - Again, kindly stop here for a second and think about how you are coming across. You've said pretty much the same things about Java EE, see me getting worked up or "taking people to task"? See the problem with what you are doing? We'll let alone a second the implication that anyone that doesn't agree with you clearly doesn't know much...and you honestly think I'm being insulting. Talk about a double-standard!!
    Is it just things that you care about that I can't be sarcastic about or is all sarcasm forbidden?
    - Do you seriously need answer to this? Have you actually ever seen someone that takes you more seriously when you are sarcastic?
    He's the one casting dispersions on my character.
    - Here we go again. Please take a look towards the beginning of this post for the answer to this one.
    I'm struggling to understand this system but perhaps one day I'll be as wonderful as you are.
    - Take a look here: http://www.city-data.com/forum/music/237842-hijacking-off-topic-posts.html. That's a pretty well used piece of netiquette to stop unproductive exchanges (otherwise called "flames") - something I've known for a the good part of a decade. Does that help? If you really want to talk about OSGi, kindly write a blog or article on it and invite people to discuss it. While OSGi is somewhat relevant in Java EE, it simply has not yet been generally established as a center piece, so insisting on devoting large portions of a discussion to it is pretty questionable... Please try not to take this the wrong way, but kindly don't expect me to respond to you any further unless you can calm down. Like you, I have limits of time and patience as well... Peace, Reza --------------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  92. Re: Just catching up.[ Go to top ]

    James,

    I said let's move on from this, but you are insisting on dragging this on, leaving me very little choice...
    This is getting silly. I can't take the time to answer all of your post partly because the terrible formatting makes it hard to follow. But lets take this gem.
    The point is to leave me alone when I ask it. Look back at the posts. I was respond to Guido. I didn't say anything to you. My response to him had absolutely nothing to do with you. Then you took it upon yourself to respond to me. And then somehow, in your mind, 'I'm not leaving you alone.' Look, when you post on a public forum, you can't control where the conversation goes. If you want to control the discussion, get a blog and moderate the comments. Maybe it's cultural. You could try to me more tolerant of people who express things differently than what you are used to. I'm blunt and often coarse. I grew up on the playground with kids from public housing throwing around snaps and yo-mama jokes. I'm comfortable with who I am. Just don't respond to me if you don't like me. I'll try to remember your name and avoid your posts. I'm not trying to upset you.
  93. Re: Just catching up.[ Go to top ]

    James, OK, this is a lot better and more constructive. I wholeheartedly agree that carrying on with this is one of the silliest things I've experience for a good long while. Firstly, please take a careful look at what I said. I said I am not interested in a religious battle - I didn't necessarily say there was one going on. That being said, I've had ample indication one is about to brew. What I was trying to do was preemptive based on my observations and experience dealing with a variety of people in various settings over the years. Secondly, where on earth did you get the idea I think I can "control" you or anyone else? That doesn't mean I can't point out glaringly obvious problems when I see them or try to head off oncoming problems. For one, I left you alone with your continued pontification of OSGi. I only responded to you when I detected the definite potential for an oncoming flame. Frankly, I don't think that's too unreasonable of a observation. Thirdly, there is just no excuse for unprofessional, confrontational and inconsiderate attitudes. Thankfully, good manners and decent language are pretty universal and I can tell you that first hand spending time in quite a few cultures in my life-time... No one cares where you grew up. If you really need to know, I was in a state-run orphanage until age 12 and I spent a majority of my teen years close to drug/crime infested third world slums. If you really think people will put up with you because you had a hard life, I dare say you are in for a pretty big surprise... Lastly, I have nothing personal against you. You are more difficult to deal with than most people I work with, but I've seen far worse and it's hardly anything that I find surprising especially in the impersonal setting of the web. If you have something valid to say and are saying it fairly calmly/respectfully, of course I'll continue respond. In the same token, you are most welcome to ask me questions as well - but kindly try to respect what I am asking of you. That said, you are a grown man, so feel free to do as you see fit. Honestly, I'm too old for sulking or putting up with nonsense. Now, can we please, please leave this be? Peace, Reza --------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  94. Re: Just catching up.[ Go to top ]

    I said I am not interested in a religious battle - I didn't necessarily say there was one going on.

    That being said, I've had ample indication one is about to brew. What I was trying to do was preemptive based on my observations and experience dealing with a variety of people in various settings over the years.
    And that's where I think you went wrong. Your first response on OSGi was perfect (the one where you suggested it should be looked at later with respect to JEE.) You should have left it at that. It wasn't you that started bashing OSGi but for some reason you decided to get on that bandwagon. Like others, I only got involved in this thread to question the misrepresentations of OSGi that were being thrown about here. I threw in a couple gibes at JEE and that's was unnecessary but I don't really see how someone can give negative opinions about one technology and expect no one to make comments about their own sacred cow. The 'and forget about JEE' comment was a little glib but i was trying to get it across that by ignoring OSGi, you risk obsolescence because that's what I believe.
    Secondly, where on earth did you get the idea I think I can "control" you or anyone else?
    You complained about people taking the thread off-topic. It's not your thread. You don't get to decided where it goes. Complaining about it is pointless.
    That doesn't mean I can't point out glaringly obvious problems when I see them or try to head off oncoming problems. For one, I left you alone with your continued pontification of OSGi. I only responded to you when I detected the definite potential for an oncoming flame. Frankly, I don't think that's too unreasonable of a observation.
    It's hugely presumptuous and by doing it, you created a problem.
    Thirdly, there is just no excuse for unprofessional, confrontational and inconsiderate attitudes.
    What's ironic is that I find much of what you have written here confrontational, unprofessional and inconsiderate. Your 'universal' understanding of manners may not be as good as you think.
    No one cares where you grew up. If you really need to know, I was in a state-run orphanage until age 12 and I spent a majority of my teen years close to drug/crime infested third world slums. If you really think people will put up with you because you had a hard life, I dare say you are in for a pretty big surprise...
    I didn't say where I grew up. I also didn't say I had a hard time. All I was saying is that it may just be that the way I express myself could be perfectly normal in my culture but offensive to you just as the way you are talking to me is extremely aggravating to me even though you seem to think you are beyond reproach. For example, I just pointed out two conclusions you drew that I never said and in fact are not true. I find that very annoying but if your used a couple curse words, I wouldn't care at all because words are just words. There is no one word that offends me. In other words, I'm more concerned with what people say, not how they say it.
    Now, can we please, please leave this be?
    You keep continuing the conversation. I like how you accuse me of having to get in the last word yet you always have to respond. One thing that I've learned in life is that the most unreasonable people complain the most bitterly about the behavior of others.
  95. Re: Just catching up.[ Go to top ]

    James, I think John is right. I let you off the hook a little too easily. Let's pursue this a little more in the hopes that you don't think you are freely entitled to repeat this again on another poor soul...
    but i was trying to get it across that by ignoring OSGi, you risk obsolescence because that's what I believe.
    As I stated over and over again, what you believe is not an issue. The problem is the actions you believe are justified based on your beliefs. Nothing gives you the right to provoke other people, undermine my hard work and make the discussion effectively useless for people who do not share your beliefs but want to discuss the main contents of the article all for the goal of imposing your will on others. It's just sad that you don't see that and I wonder how many other people you will harm and have already harmed...
    It's not your thread. You don't get to decided where it goes. Complaining about it is pointless.
    Thanks for your kind counsel. Don't mind too much if I ignore it though, right? After all, I've spent quite a few years on web forums. I find this ironic coming from someone who is either ignorant of widely accepted practices on the web or believes he is well-above them somehow. Of course, that too bad for us who do believe in using a little more self-control...
    In other words, I'm more concerned with what people say, not how they say it.
    And here is where you miss the point again, perhaps even deliberately. The point is that no one needs to quietly put up with your "self-styled" culture. It would be much more productive instead if you perhaps were humble enough to strive to do better or are you really that "comfortable with yourself" to think you are perfect? And you are telling me I'm presumptuous? How much text do you think has been written on netiquette? Really think you know something they don't?
    One thing that I've learned in life is that the most unreasonable people complain the most bitterly about the behavior of others.
    Let me see, you trolled into here because you wanted to "take people to task" and proudly hijack a thread in the name of your religion and I'm being unreasonable? You'll forgive me if I ignore this bit of advice... Regards, Reza
  96. Re: Just catching up.[ Go to top ]

    Guido, First of all, no one is forcing you to use EJB 3.x/Java EE and I am not "evangelizing" anything - just informing, listening and answering questions - nothing in the article even suggests you need to be using Java EE... Don't like EJB/Java EE? Great - use what you think is really right for you. A lot of my own customers think EJB 3 is out to kill them somehow (partly because of now well outdated books like Bitter EJB, written by folks who have since abandoned Java wholesale and berate Java developers as being "stupid" and "unproductive") - yet we are still good friends and I respect them as individuals :-). I would say the best way find answers to your questions that respects everone's time is to pick up a good book on EJB 3.x/Java EE 5. In short, you can do all of what you are doing now with EJB 3.x without any penalties, much more productively, keeping your codebase 100% vendor neutral and much more robustly. Here is why: * Each request is surrounded by one transaction - which would be transparenly managed by an EJB 3 session bean with *zero* code or even metadata. * Each request is executed using one JDO PersistenceManager or Hibernate Session. - This would be a JPA EntityManager injected into a bean. * Business Logic POJOs are instantiated with the ORM context to use in the execution of the actions required by the request. - This would be JPA entities with embedded business logic ala DDD (domain-driven design). That being said, EJB 3 won't force DDD on you and neither do I. * And what the applicable container services would be? - In your particular case, the services that EJB 3 Lite provide. * Thread-safety? No, since each instance has request scope. - With respect, it's not really that simple. You'd have to make sure all of your instance variables are thread-safe - EJB means you don't worry about that at all. For example, the Hiberate session you mention and well as the JPA EntityManager (the rough equivalent of the Hibernate session) is *not* thread safe. Spring handles this by making large portions of it's API are serialized under the hood - pretty dangeroud and fragile IMO. Just like you are, folks get into pretty lax mindsets about concurrency. * Life-cycle? A really trivial Servlet filter accomplishes the job quite well. - Yes, but it's 10 times more verbose that a component life-cycle implemented as a simple POJO method. Stateless?.......Embedded in the web application? To gain what? - To gain the EJB services above, to start with. Instance pooling? And the http request dispatching pool? - Notice, I made no mention of pooling. The spec does not mandate pooling, vendors choose to do so at their discrecion. As an aside, the HTTP requst dispatch pool will not pool the entire object graph, EJB will. Stateful? Yyyyyyes, maybe.....But we already have a servlet session...... - Again, a stateful session bean with WebBeans or Seam will do that much more robustly and with 10 times less custom code. * Some months ago I argued about annotations, stating that, IMHO, they were not for configurations. - And no one is suggesting that they should be. In fact, I've written best practices myself about when to use XML vs. annotations. Annotations are just another option. If you don't think somethings should be in annotations, use an XML override. That being said, let's not pretend to know what's best for everyne (after all that's what the "questionable evangelists" you refer to tend to do) - some folks find annotations perfectly maintenable and the productivity/readability gains well-worth it. Hope this helps. If you have more quetions I'll be happy to answer them. That being said, I have one humblle request - if you've adopted "I hate EJB/Java EE" as your religion, kindly *don't waste any more of my time*. *I'm not interested in fighting a "Jihad"*. As I stated, the explicit purpose of the article is to inform you and listen to what you have to say, not "sell" or "convince" you anything... By the same token, I don't particulary enjoy the typical "I'm the smartest geek around" shouting matches either. So if that's what you are looking for - I concede and "you win" :-). Peace, Reza ---------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1
  97. Re: Just catching up.[ Go to top ]

    Reza, it is quite evident that you didn't catch my P.S., so I have been in doubt if answer (considering your exchange with James Watson, too), but, OK, let's take the risk.
    Guido,

    First of all, no one is forcing you to use EJB 3.x/Java EE and I am not "evangelizing" anything - just informing, listening and answering questions - nothing in the article even suggests you need to be using Java EE...

    Well, it is rather odd that you have understood my claim as directed to you. Let's assume to be a side-effect of communicating via forum.
    Don't like EJB/Java EE? Great - use what you think is really right for you.
    Please, forgive me, but I was not requiring you consent.
    A lot of my own customers think EJB 3 is out to kill them somehow (partly because of now well outdated books like Bitter EJB, written by folks who have since abandoned Java wholesale and berate Java developers as being "stupid" and "unproductive") - yet we are still good friends and I respect them as individuals :-).

    I would say the best way find answers to your questions that respects everone's time is to pick up a good book on EJB 3.x/Java EE 5.
    Do you think my post is a silly one ? Great!! You are not forced to answer,If you think it is a waste of time.
    That being said, I have one humblle request - if you've adopted "I hate EJB/Java EE" as your religion, kindly *don't waste any more of my time*. *I'm not interested in fighting a "Jihad"*. As I stated, the explicit purpose of the article is to inform you and listen to what you have to say, not "sell" or "convince" you anything...

    By the same token, I don't particulary enjoy the typical "I'm the smartest geek around" shouting matches either. So if that's what you are looking for - I concede and "you win" :-).

    Peace,
    Reza
    ----------------------
    Independent Consultant
    Author, EJB 3 in Action
    Expert Group Member, Java EE 6 and EJB 3.1
    I guess you need some vacations, or maybe, better, I think it is more appropriate Robin Williams claim in Good Morning Vietnam about human needs (at least in italian sounds great). With little less respect, Guido
  98. Re: Just catching up.[ Go to top ]

    Guido, OK, I'll meet you halfway and assume your post is sincere. For one, it could be the case that language (given your reference to Italian) could be an issue. If not, I guess I can serve as a personal entertainer some more...
    Let's assume to be a side-effect of communicating via forum.
    - There isn't a need to assume - I'll happily share why I deemed preemption to a flame war necessary. You started the post by stating that you haven't worked with EJB since 1.0. You then proceeded to berate how Java EE proponents (being folks like myself) have and might somehow force bad architecture decisions on you. You then presumed to know "for sure" that annotations are evil (all still with EJB 1.0 era experience mind you). You rounded out the post with a derogatory and overkill sentence on how EJB 3.x is bound to fail unless you are paid attention to. Really think there isn't room for improvement in how you came across? Stop for a second and take a look at it from my perspective...need I clarify more?
    Please, forgive me, but I was not requiring you consent.
    - Frankly, it looks to me like you are *deliberately being a little obtuse*. The point is that I'm not here to entertain an endless flame war and it definitely looked like that's what you were gearing up for. See above to understand why that might be the case, if your confusion is indeed sincere.
    Do you think my post is a silly one ? Great!! You are not forced to answer,If you think it is a waste of time.
    - Not really sure where you got that from. If I thought it was completely pointless, would I have replied at all, needless to say in good detail to all your points? I merely pointed out that my time is limited and the best way to find out more is to pick up a book. I don't think that's too much to ask for. That being said, if you have further questions, I'll try my best to answer them. And I *do* think is it my obligation to readers to respond to any questions that I can without killing my schedule...
    I guess you need some vacations, or maybe, better, I think it is more appropriate Robin Williams claim in Good Morning Vietnam about human needs (at least in italian sounds great).
    - So sarcasm, confrontational tones and disregard for other's time/effort passes for humor? Maybe I've had a pretty sheltered life after all. Might be true--I certainly can't discount it. I've never been much of a comedian myself...
    With little less respect
    - Frankly, at the moment, I could care less. As I see it, you didn't start with much of it to begin with, so no big loss... Regards, Reza
  99. Re: Just catching up.[ Go to top ]

    You started the post by stating that you haven't worked with EJB since 1.0. You then proceeded to berate how Java EE proponents (being folks like myself) have and might somehow force bad architecture decisions on you.
    No, it is not true. And the worst thing is that you know you are wrong, since I told you twice that people I was referring to as evangelists were not you. But maybe your obtuse visual angle prevent you from seeing the reality of things.
    You then presumed to know "for sure" that annotations are evil
    No, never said so. I simply said that a lot of people say that annotations are not for configurations and I asked myself if table names and webservices endpoints weren't configurations.
    You rounded out the post with a derogatory and overkill sentence on how EJB 3.x is bound to fail unless you are paid attention to.

    You have an incredible ability to read things never written.
    Really think there isn't room for improvement in how you came across? Stop for a second and take a look at it from my perspective...need I clarify more?

    Please, forgive me, but I was not requiring you consent.


    - Frankly, it looks to me like you are *deliberately being a little obtuse*.
    The rudeness degree you can reach goes far beyond any comprehension. Your attitude to the personal offence and insult has few equivalent.
    The point is that I'm not here to entertain an endless flame war and it definitely looked like that's what you were gearing up for. See above to understand why that might be the case, if your confusion is indeed sincere.

    Do you think my post is a silly one ? Great!! You are not forced to answer,If you think it is a waste of time.


    - Not really sure where you got that from. If I thought it was completely pointless, would I have replied at all, needless to say in good detail to all your points? I merely pointed out that my time is limited and the best way to find out more is to pick up a book. I don't think that's too much to ask for.

    Mr. Reza Rahman, your post didn't seem to be a press conference where the chairman kindly grant answers to journalists questions. Is TSS still a public forum ? You cannot post a reply start saying "please, don't waste my time". Or better, it is obvious you can, but you cannot complain about consequences without being al little ridicule.
    - Frankly, at the moment, I could care less. As I see it, you didn't start with much of it to begin with, so no big loss...
    Me ? Are you talking about me ? You must have had a really bad day; you lack of contact with the reality of things happening around you is quite evident. Guido
  100. Re: Just catching up.[ Go to top ]

    I think I've made it amply clear that this isn't "my forum" but it is not a free-for-all without all context either - it is specifically designed to be helpful for folks that want to discuss the content of a given article - in this case, the article that I put in my hard work to write. As I see it, some foks continue to have completely unapologetic disregard for that fact. I think that's regrettable and if it persists, is likely to create a repeat of what happened here. This is a good resource worth taking a quick look at: http://www.albion.com/netiquette/corerules.html. I read it many years ago and do find that it helps me avoid sad situations like this one - although clearly not every time. A "public forum" is not a license for anyone to do as they please no matter how self-entitled they might feel. "Tit for tat", "sarcasm" and the "law of the jungle" are definitely not good substitutes for well-estabished rules of conduct that work much better. Regardless of all that, it is *very true* that I did partake in the degeneration of this in the past few posts and really should have restrained myself a bit more, whatever anyone else did or did not do. I sincerely regret that indescretion and really do hope I have the moral strength to do better next time... Cheers, Reza
  101. Re: Just catching up.[ Go to top ]

    James/Guido You guys have to be the biggest couple of jerks I've seen in quite a while. I can't believe one of you thinks it's OK to flame with sarcasm/cussing cuz their "cow" got beat up. Where are you from? Ghetto? Trailer park? Get a life, man. And the other thinks it's OK to "ridicule" someone and have that be just fine? From where I'm looking, it looks like Reza's been a lot nicer than anyone else I know. All he did was to ask not to be flamed. You and your buddy boy took it to a whole new level of trash talking! Your nothing but a couple of trolls. You guys ought to be blacklisted or something. Guys like you are what gives TSS a bad name... Shape up or ship out, dudes!
  102. Re: Just catching up.[ Go to top ]

    John,
    Shape up or ship out, dudes!
    Amen. Informal standards of conduct for the web were designed specifically *for* responsible professionals on open forums to self-regulate and remain effective...I guess that's a point missed on these folks. I am *also* curious to know what culture is it exactly that is so permissive as to liberally initiate undue provocation at will as an effective way of conversation - I'll make sure to stay away from it :-). Cheers, Reza
  103. Re: Just catching up.[ Go to top ]

    James/Guido

    You guys have to be the biggest couple of jerks I've seen in quite a while. I can't believe one of you thinks it's OK to flame with sarcasm/cussing cuz their "cow" got beat up. Where are you from? Ghetto? Trailer park? Get a life, man.

    And the other thinks it's OK to "ridicule" someone and have that be just fine? From where I'm looking, it looks like Reza's been a lot nicer than anyone else I know. All he did was to ask not to be flamed.
    John, please note that, as I see it, everything started here http://www.theserverside.com/news/thread.tss?thread_id=53459#304132 where Reza have clearly missed the point in his preface
    ...First of all, no one is forcing you to use EJB 3.x/Java EE and I am not "evangelizing" anything - just informing, listening and answering questions - nothing in the article even suggests you need to be using Java EE... Don't like EJB/Java EE? Great - use what you think is really right for you.....
    Peace, it may happen. Then, nice Reza, ***before**** any specific answer says:
    ....I would say the best way find answers to your questions that respects everone's time....
    Please, since you claim the right to censor other's behaviour from the high of your moral strength, can you spend a minute to strictly comment the above nice behaviour?
    You and your buddy boy
    Please, clarify who is "you" and who is "your buddy boy".
    took it to a whole new level of trash talking!

    It seems to be somehow contagious
    Your nothing but a couple of trolls. You guys ought to be blacklisted or something. Guys like you are what gives TSS a bad name...

    Shape up or ship out, dudes!
    Yes sir. Guido
  104. Re: Just catching up.[ Go to top ]

    Guido, Firstly, I'm not sure who are addressing here. Since it seems to be mostly me, I'll try to respond the best I can yet once again...
    I would say the best way find answers to your questions that respects everone's time....
    I've already explained this comment. If you still don't get it, I respectfully ask you to give the netiquette guidelines I posted earlier and look under "respect for other people's time and bandwidth". The bottom line is that it is far more effective and time-efficient for you to take a look at a good Java EE 5/EJB 3 reference to answer the questions you posted. I simply can't do justice to it beyond what I have already tried my best to do. That being said, please *do* ask follow-up questions if you want, if I am indeed at fault, I will try to do better right now...
    Please, since you claim the right to censor
    You are totally misunderstanding this. *No one* is claiming the right to censor. Self-regulation is quite the opposite. Censorship is when someone has the *absolute power to silence you*. Group self-regulation is when you are at a professional meeting and you *choose* not to yell and scream when you disagree with someone or a number of other people in the group *request* that you calm down or kindly leave the the room. Let me give you another extreme example if it helps you: The freedom of speech act in the U.S. allows neo-Nazis and the Ku Klux Klan members to speak publicly about their violent ideology. But that doesn't mean that those of us who do not agree with them can't hold a peaceful counter-rally where they speak. See the distinction or need I explain more?
    from the high of your moral strength
    I sincerely hope this is rage talking. If you honestly believe a quest for moral strength is a worthy target for ridicule, for your own sake, I beg you to seek whatever spiritual advise you find comforting. I never said I am perfect, but I don't frivolously attack people, deliberately use offensive language or harass others unnecessarily.
    can you spend a minute to strictly comment the above nice behavior?
    I believe I already did. Please take a look above and my recent posts. If it is still unclear what motivated me to try to stop you on your tracks if your intentions were questionable, I'll summarize to the best of my abilities yet again. *That being said, perhaps it would have been best to give you further benefit of the doubt.*
    It seems to be somehow contagious
    *It usually is and that's the problem.* I've tried to restrain myself the best I could but have clearly failed as well. Perhaps I can redeem myself now... Regards, Reza
  105. Re: Just catching up.[ Go to top ]

    Guido,

    Firstly, I'm not sure who are addressing here. Since it seems to be mostly me, I'll try to respond the best I can yet once again...

    No Reza, it was not you. It was in reply to John's post.
    I would say the best way find answers to your questions that respects everone's time....


    I've already explained this comment. If you still don't get it, I respectfully ask you to give the netiquette guidelines I posted earlier and look under "respect for other people's time and bandwidth".
    IMHO, it is not "politically correct" nor polite start with the above. (IMHO, if someone doesn't want someone else might reply to something it is better to not to write it). You start saying "No forces you", "if you don't like J2EE don't use". What did you expect here from me to happen. Close my mouth or saying "Oh, thank you, I would never been able to realize it by myself" ?
    Please, since you claim the right to censor


    You are totally misunderstanding this. *No one* is claiming the right to censor.
    Hmm, John hopes for me to be blacklisted. And you totally agree with him. I, in turn, agree with you about speech freedom. John must have the right to express his opinions wherever he wants and, limited only by current laws on calumny, in the terms he prefers. I would have the possibility to preserve my right of saying that he seems to be on a pedestal, in force of "his moral strength".
    Let me give you another extreme example if it helps you:

    The freedom of speech act in the U.S. allows neo-Nazis and the Ku Klux Klan members to speak publicly about their violent ideology. But that doesn't mean that those of us who do not agree with them can't hold a peaceful counter-rally where they speak.

    See the distinction or need I explain more?
    No, it was neither necessary (no offence). I am a supporter of an italian party that is well-known for its battles for freedom tout-court. Beyond any bad tone from me or from you, there was no polemical intent in my posts. I warned about the possibility of misunderstanding due to this form of communication, but without success I have to admit. I can read ten times my posts but what I can honestly deduce is that I didn't deserve that kind of attention from you. But, you know, I read my posts with my eyes, knowing what I felt when I wrote it. Maybe you didn't pay too much attention to the context, as your last post suggests: in fact, it is quite clear that it was not directed to you but, nevertheless, it was not clear to you. I really hope your next reply, if any, would not start with some sort of granting sincerity to my words. Regards, Guido
  106. Re: Just catching up.[ Go to top ]

    Guido,
    I really hope your next reply, if any, would not start with some sort of granting sincerity to my words.
    Given what you are saying, I really think the real issue between you and me might be a language barrier. I mentioned this briefly earlier but it might have been too late already with tempers flaring... Please don't take this to be demeaning in any way - it is not intended to be. Frankly, I can't even say that I know what you are going through since I've never had to struggle with learning a second language (I am bi-lingual from childhood). Honestly, I was getting tired of the jabbing/negativity and that might have contributed to my misreading your post, not giving you the benefit of the doubt or just not trying hard enough to understand what you were probably trying hard to say without having a strong grasp on English. When I talk about the jabbing, I'm not talking about James alone. I'll admit the first few con-constructive comments despite all the hard work we put into Java EE 6 and what I perceive to be an overdone OSGi tangent put me on the defensive, perhaps more than was warranted. Putting up with what I perceived as regurgitated EJB 2.x/EJB 1.x bashing really was the straw that broke the Camel's back for me. Thinking about this carefully, if your post had been one of the first few, I probably would have reacted differently, but it is really difficult to tell now since I haven't fully calmed down yet :-). In any case, I am sorry for all this and there are no hard feelings :-). Next time, I'll try to pay extra attention to what you might be struggling hard to say and will try harder not to get on the defensive so easily. Best regards, Reza P.S.: Do feel free to send me an email with any questions you might have at any point. My email address is reza_rahman at lycos dot com.
  107. Re: Just catching up.[ Go to top ]

    I'll admit the first few con-constructive comments despite all the hard work we put into Java EE 6 and what I perceive to be an overdone OSGi tangent put me on the defensive, perhaps more than was warranted. Putting up with what I perceived as regurgitated EJB 2.x/EJB 1.x bashing really was the straw that broke the Camel's back for me.
    JEE is tough because it's got such a history, one that is extremely negative for a lot of people, including myself. I should be more open minded to it the changes. You can take that away as a least one positive result of all this negativity. But you've taken on something that a lot of people have strong opinions about (most negative, in my estimation) so you are going to need to have a stiff upper lip. I predict this will not be last time you get some negative feedback. And good work on the pruning, especially JAX-RPC. Long overdue IMO. We still have consultants trying to push RPC style services on us where I work.
  108. Re: Just catching up.[ Go to top ]

    James,
    I should be more open minded to the changes. You can take that away as a least one positive result of all this negativity.
    Believe it or not, that makes my day :-). Or perhaps even the week :-).
    you've taken on something that a lot of people have strong opinions about (most negative, in my estimation) so you are going to need to have a stiff upper lip.
    I know that and knew that when I embarked on this several years ago. And I agree that I do need a stiff upper lip, even if some of the negativity borders on being completely irrational... Honestly, a lot of problems really have been fixed. What remains is pretty trivial. To boot, I've been using Java EE for the better part of a decade and have been able to harness it successfully and avoid the pitfalls (albeit avoiding Entity Beans CMP, using XDoclet, Tomcat/JBoss for testing/development, etc). I've been using Spring for the last five/six years and honestly cannot say it does not have its weaknesses vis-a-vis Java EE 5 (but we'll leave that alone for now). I am very new to OSGi and perhaps a little skeptical just for that reason and the fact that it seems a bit over-hyped/complex at the moment. That being said, I do assure you the Java EE vendors are taking it *very seriously* and are eager to not repeat the mistakes of the past like not keeping a closer eye on JDO/TopLink/Hibernate as well as PicoContainer/Spring. Believe me those days are over and everyone is putting in 150%. I think you will see some evidence of that in Java EE 6 if not perhaps in Java EE 5 too. The danger is that if people are still very apathetic I fear vendors will start pulling back their investments and going the proprietary route. I think that will do all Java developers a big disfavor in the long run, although it might not seem like it right away. The underlying problem is that Java EE applications still have a lot of maturing to do and there is too much money to be made to trust anyone to do the right thing without pressure from a strong, full-platform, collaboration-based open standard.
    And good work on the pruning, especially JAX-RPC. Long overdue IMO. We still have consultants trying to push RPC style services on us where I work.
    Thanks for the feedback and I agree. You can tell the consultants about my article and the Java EE 6 draft spec :-). Thanks a bunch, Reza
  109. Re: Just catching up.[ Go to top ]

    I am very new to OSGi and perhaps a little skeptical just for that reason and the fact that it seems a bit over-hyped/complex at the moment. That being said, I do assure you the Java EE vendors are taking it *very seriously* and are eager to not repeat the mistakes of the past like not keeping a closer eye on JDO/TopLink/Hibernate as well as PicoContainer/Spring.
    I don't want to get into a long thing about OSGi but what appeals to me about it is that it's something that and reasonably skilled developer can use with standard Java classes and interfaces to solve their own problems. It's also able to support a lot of complex behavior without dealing with it directly. That means I can ignore it most of the time but when I need to be able to scratch my own itch, it's possible for me to do so. For example, if a vendor provides a work queue to me via a OSGi enabled service, it's should be possible for me to change it out with something homegrown or from a 3rd party if I need to. Conversely, this is exactly what I didn't like about J2EE. It was always, "don't do this, don't do that". Developers' hands were tied and if the spec didn't provide what you needed, you either had to violate these rules (possibly causing unexpected issues) or use a vendor-specific capability. IMO, this turned J2EE into a sort of bait-and-switch spec. Everybody who got into it thought they were getting portability in the deal. But to do anything non-trivial, you ended up having to give up portability and jumping through all of the hoops of the spec became pure overhead. A lot of people (especially vendors) will argue that I shouldn't need to do things for myself but that's something that my experience (and many others) tells me is wrong. To give an analogy: I don't particularly want to change a car tire but if I've got a flat, I will be glad to have the ability to do so. This isn't the right time for a debate about that but that's what I'm looking for with a spec: true portability and some level of transparency. I think OSGi could be a step forward in that direction and my experiences with it have been very positive. My concern is that a lot of vendors will see users ability to solve their own problems or pick and choose parts of an application server as a threat instead of seeing how much more appealing it will make their products. Of course a lot of managers don't think their employees should be solving their own problems so the vendors may just be catering to the people holding the purse strings.
  110. Re: Just catching up.[ Go to top ]

    James, I think it's OK to discuss this now that this thread has effectively died down and there are not that many people to coordinate across anyway (of course, that might change next week)... Have you actually had a production deployment or are you still researching? If so, on what platform? My customer used Equinox/Spring DM. I saw them struggle with the learning curve (they were already familiar with Java EE/Spring) quite a bit and they found that in the end, all they really achieved in terms of a tangible benefit was basically equivalent to app server hot-deploys. Other than that, modularity really wasn't a big issue and the versioning/dependency management was basically handled by Maven. Fortunately, I didn't initiate the project so it wasn't a problem for me personally. That's really what makes me question the practical usability of this (beyond my own research) in most environments. On hind sight, it would have been better, at least for them, until OSGi support was more matured and cost-benefits/best practices better understood. Do you know SpringSource recommends it only for very high-end environments? All this kid of reminds me of early hype around EJB 1.0...not the best of examples in terms of practical success :-(. Honestly, I'm not trying to be difficult. Just trying to understand where you are coming from. What am I missing? Perhaps less jar copying? Where would something like WebBeans fall short, specifically in terms of the pluggabilty you are mentioning? In case you are not familiar with it, it is a very generic (more generic than Spring) DI system. Robust third-party integration should be very possible via that? For example, you can plug in Spring beans transparently if you want to. Also, what specific J2EE restriction was an issue for you? Threading? Similarly, what was the portability issue? Did you know I could reuse the same EJB 3.0 code for our book code examples across four application servers with no changes? Again, not trying to be difficult, just trying to understand the real issues so I can make sure they are already solved? Don't worry about it if you don't have time. As I said, almost all major vendors are looking into it now anyway. Thanks, Reza P.S.: If it is easier for you, do feel free to continue the conversation off-forum via email (easier to get notification of a new message). My address is reza_rahman at lycos dot com. You have to promise you won't get mad if I don't agree with you, though (just kidding) :-).
  111. Re: Just catching up.[ Go to top ]

    I didn't start out meaning to write such a long diatribe so don't feel the need to respond to all of it (or any really).
    Have you actually had a production deployment or are you still researching? If so, on what platform?
    One place I was seeing potential is in a project I work on called Simbrain. You can look at project if you want more detail but it basically has a similar problem space as Eclipse where the project owner wants plugability (custom components) and modularity. For work I see it having the potential of addressing some dependency issues. We have a lot of concurrent work going on and the development is not centrally managed or well controlled. It's possible to address this on the development side but I think it would be easier in our situation to manage the dependencies at the deployment site.
    My customer used Equinox/Spring DM. I saw them struggle with the learning curve (they were already familiar with Java EE/Spring) quite a bit and they found that in the end, all they really achieved in terms of a tangible benefit was basically equivalent to app server hot-deploys. Other than that, modularity really wasn't a big issue and the versioning/dependency management was basically handled by Maven.
    I guess this where I feel we are not connecting. I would want to see every app deployment treated as a module. So when you say that you modularity is not an issue, it kind of sounds like you don't see the business app as having the same kind of importance as the vendor modules. I don't want to put words into your mouth. That's just my feeling. To me the business application is the whole point. I want all tools at my disposal to solve the business problem the best I can. I'm really not fond of going back to the customer and telling them the tools we are using don't support what they want us to do. I think that's really lame although I know people who think this is perfectly legitimate. I think it's sad that it's viewed as acceptable in IT.
    Fortunately, I didn't initiate the project so it wasn't a problem for me personally. That's really what makes me question the practical usability of this (beyond my own research) in most environments. On hind sight, it would have been better, at least for them, until OSGi support was more matured and cost-benefits/best practices better understood.
    I haven't found it to be complex in my exploration (the oscar tutorials helped a lot) and it addresses a lot of my needs but I haven't used it in a real world situation or even in a prototype so I could be underestimating the problems I would have. It's also quite possible that it wouldn't provide me with what I want anyway. Your point is taken.
    Do you know SpringSource recommends it only for very high-end environments?
    No I didn't but I'm not really into Spring or beans in general. I think of POJO as meaning anything that I can code in Java is OK. But that's a rogue viewpoint in most circles.
    What am I missing? Perhaps less jar copying? Where would something like WebBeans fall short, specifically in terms of the pluggabilty you are mentioning?
    Being able to bring services down and up and in an out of the container without restarting things would be a great help. Right now we have to stop and restart Websphere just to fix a jndi connection or at least that's what I'm told. Being able to have public packages that are only visible inside the jar is a nice touch. Maybe it's a minor thing but it makes things much more rigorous. The service paradigm, although unfortunately named, is very helpful. The ability to say that X depends on version 1 of package Y is a big deal to me. We have dozens of concurrent projects going on and we share code as much as we can. The problem is that you end up wanting to fix things or add to things but you can't because you'd have to retest everything that was already deployed. And I don't mean unit tests. I mean full blown QA. It's just not feasible so reuse goes out the window and you end up with a lot of cut and paste or ad hoc versioning. It's bad enough when you are talking about Java SE apps but when you try to run things in the same app server, it's maddening and risky.
    Also, what specific J2EE restriction was an issue for you? Threading? Similarly, what was the portability issue? Did you know I could reuse the same EJB 3.0 code for our book code examples across four application servers with no changes?
    [Understand that I am referring to J2EE and I realize you and others have made huge improvements.] Mainly threading. We had some serious performance issues (container related and design related) and we ended up having to build a threaded cache inside the container in full violation of the rules. It seemed OK but could have been a major issue in the long run. But in general, the inability to build our own internal services or tweak the vendors transactions and persistence were extremely frustrating. We ended up having to write more code to use the container the way it was that it would have taken to just do what the container provided for us. There were lots things where we ended up writing lots of code because we couldn't just put in our own app-server behaviors. I even wrote a code generator so that I could finish my work on time. Of course this was the bad old days of EJB 1.1 so most if not all of the issues I had have probably been solved. The thing is, I still want the ability to add levels of indirection at the app server level. It's not the problems of the past I'm worried about, it's the problems I haven't run into yet. When I use my own solutions and/or good customizable solutions, I can fix major problems in a day because the I can attack the problem at a high level. We often can't get our vendors to respond within a week. To me, the inability to provide stop-gap solutions in a pinch is an unacceptable risk. The business I work for cannot function without IT. Our inability to deliver could spell disaster for the company. In theory the vendor will always give you what you need but in practice it's often not the case. It's not that they are bad, it's just that if they do the math and its not worth it to them, they won't help you. I've seen vendors leave customers high and dry. I've seen contractors walk off after delivering nothing that even runs once they hit the stop loss limit on their contract. I used to work for a consulting firm that was sued for hundreds of millions of dollars for a 10 (or something like that) million dollar project that never got off the ground. At my last employer their outsourcing has gone so poorly and hurt their business so badly they started working on filing a lawsuit within a year. And you never know who will own the vendor down the road. At least two of our vendors are now owned by our direct competitors. I think we can agree that depending on a competitor is not a good thing for a business. In general, it's fine to use 3rd parties for getting stuff done but I think it's really non smart to depend on a 3rd party (or group thereof) 100%. You always need an contingency plan. As far as portability goes, we have both Websphere and WebLogic because other vendors won't certify their software on anything but the one platform they chose. Back in the dark ages, I worked on porting an app from platform to two others in a vendor selection process and it was a lot of work. And this was for J2EE compliant code. Again, I realize things have gotten better but I still want control over my tools. It's like a seat belt. I don't want to need it but I'm not driving anywhere without it. It's an unacceptable risk to put my ability to succeed fully into the hands of a third party. I'm sure that an app server vendor might be able to what ever me and my team does better than we can. They have the resources (hopefully). But they may not want to do it. It might be too niche or not provide enough margin. They might do it but charge exorbitant rates (this is usually the case for us.) Or they may just be to busy to get to it when we need it. In theory, my company shouldn't nee developers at all. But year after year the ranks swell.
  112. Re: Just catching up.[ Go to top ]

    Shape up or ship out, dudes!
    Given your long history of contributions on these forums and the extreme corniness of your post, I'll definitely totally take your advice seriously.
  113. Re: Just catching up.[ Go to top ]

    James,
    Given your long history of contributions on these forums and the extreme corniness of your post, I'll definitely totally take your advice seriously.
    So this is what entitles you to the poorest attitudes I've seen in a long time? That you are a "TSS God" and no one can question you here?. John is absolutely right, people like you probably drive away hundreds of good people from these forums. You are judging his post given your history on this post and many others? Talk about blatant hypocrisy...I do hope *someone* can open your eyes one day...it's just sad that it won't be this day... Regards, Reza
  114. Re: Just catching up.[ Go to top ]

    James,

    Given your long history of contributions on these forums and the extreme corniness of your post, I'll definitely totally take your advice seriously.


    So this is what entitles you to the poorest attitudes I've seen in a long time? That you are a "TSS God" and no one can question you here?. John is absolutely right, people like you probably drive away hundreds of good people from these forums. You are judging his post given your history on this post and many others? Talk about blatant hypocrisy...I do hope *someone* can open your eyes one day...it's just sad that it won't be this day...

    Regards,
    Reza
    I can't believe you can be such a hypocrite and be so oblivious to that fact. This entire crybaby fit you are throwing is about you not wanting people to question you. All I am saying is that I noticed that "John Connelly" appeared yesterday only to post a 'test' message and then attack me and Guido. I don't believe John is a real person and I don't worry too much about what imaginary people say about me. For the record, since you've decided to get personal, I think it's people like you that are driving creative developers away from Java.
  115. Re: Just catching up.[ Go to top ]

    I don't believe John is a real person and I don't worry too much about what imaginary people say about me.
    Dude, I couldn't care less about both OSGi and EJB, and by reading all posts and trying to be objective as much as possible, you first started acting like a jerk. Lets summarize your posts: "Have you seen Eclipse deployed on any machines? It's a pretty popular IDE." "I think you've answered your own question. Why do you need J2EE?" "... and forget about JEE." "Are you on drugs?" "That's the most ironic comment I've read in a while." "Bla bla bla"
  116. Re: Just catching up.[ Go to top ]

    Chief, Thanks for your time to post this, especially since none of this really pertains to you and you seem to post quite frequently at TSS as well. Please don't take this as an attempt at fawning (if I could get to your email, I would have preferred to have sent this message privately, not publicly). I would have said the same things if I saw this anywhere else in a similar situation, without my having to do anything with it... Regards, Reza
  117. Re: Just catching up.[ Go to top ]

    I don't believe John is a real person and I don't worry too much about what imaginary people say about me.


    Dude, I couldn't care less about both OSGi and EJB, and by reading all posts and trying to be objective as much as possible, you first started acting like a jerk.

    Lets summarize your posts:

    "Have you seen Eclipse deployed on any machines? It's a pretty popular IDE."
    I just can't believe that people think this is some kind of major insult. I could have phrased it differently I suppose. Which do you like best: * Liar! (that's a joke) * You must not be aware that OSGi is a core part of the Eclipse IDE. * Are you aware that OSGi is a core part of the Eclipse IDE? * OSGi is a core part of the Eclipse IDE. I'm sure you've seen it installed on at least a machine or two. Or maybe you have another option.
    "I think you've answered your own question. Why do you need J2EE?"
    How is this insulting? It' not personal. And how is it that saying OSGi is bloatware that no one uses is OK if this is unacceptable?
    "... and forget about JEE."
    Again, this is not a personal attack on anyone. Why anyone should find it insulting or offensive is not clear to me. And when you post something like this: "Geez this thread is pointless. We all know Spring is ok, and Spring AS is failure. Next please." http://www.theserverside.com/news/thread.tss?thread_id=50477#267550 Was that OK? I'm not suggesting it wasn't, I just want to understand what makes the 4 words above so bad. You are claiming an objectivity that I just don't see.
    "Are you on drugs?"
    OK, I'll admit I shouldn't have written that. It was unnecessary. I was just a little shocked by comments that OSGi is bloatware when any rational observer can see that it is definitely not. To say so is either purposeful misinformation or based in ignorance. Either way, I see such comments as being the worst kind of thing to post on a forum like this. No one cares about whether I am a jerk or not (well, they shouldn't) they are here to get technical information.
    "That's the most ironic comment I've read in a while.
    What's so offensive about that? My entire character is being defamed and you are faulting me for writing that a I thought a comment was ironic. Is there some offensive meaning of ironic that I don't know about? You don't see any sort of asymmetry?
    "Bla bla bla"
    I don't really see how this supports your argument. I'm making a concerted effort to not be sarcastic even though I definitely think this deserves it. And the last question I have is that "Bla bla bla" is obviously a slam. What makes it OK for you to slam me and call me a nerd? Because I did something that you think was wrong? Then if you are able to attack people when you decide a wrong was done, why can't I go after someone when I decide it's warranted?
  118. Re: Just catching up.[ Go to top ]

    Chief, At the high risk of stating the obvious, I beg you to kindly not respond to this. It's not going to end and it is probably best to simply isolate it at this point... Kind regards, Reza
  119. Re: Just catching up.[ Go to top ]

    James, The more I look into what you have been up to on TSS the more honestly disgusted I am getting... You definitely have some technical depth, but it doesn't even come close to matching the stuff you spew on a regular basis! And I would have never ever dreamed I could say that to *anyone*. It's hurts *me* to see that I can have such contempt for someone *I haven't even met in person*! If your personality offline matches anything of what I see here, I truly feel sorry for anyone and everyone that has to deal with you on a day-to-day basis. You are truly a great example of the proverbial Internet troll! Thank god there's no one like that in my workplace! Your posts here are just the tip of the iceberg. It would be a scary picture if someone actually made a list of all the offensive, nasty and confrontational comments you've made just on TSS alone! I think I have a pretty strong threshold but I can honestly say I don't think you are worth my time and not feel an *ounce* of guilt about it. I just hope you stop and look at yourself one say. Given what I can see from your habits, I doubt very much that'll happen any time soon. That's just unfortunate, probably mostly for you. At least four people pointing out what you are doing still doesn't make you look in the mirror. I thought I've seen worse than you, but now I really don't think I have. I guess it'll be an experience to remember for me! If I can get credit for driving people like you away from Java, I'll carry it around as a badge of honor! I said I would interact with you again if it's appropriate. I was totally wrong. You are just not worth my time and that's probably true of a pretty large group of people... With truly, surprisingly very little respect, Reza
  120. Re: Just catching up.[ Go to top ]

    It's hurts *me* to see that I can have such contempt for someone *I haven't even met in person*!
    I don't think I'm losing much if you never converse with me again. I would discuss things with you in the future but it's not a big deal to me either way.
  121. Re: Just catching up.[ Go to top ]

    James,
    I don't think I'm losing much if you never converse with me again.
    That's been pretty obvious to me all along, but thanks anyway for clarifying that.
    I would discuss things with you in the future but it's not a big deal to me either way.
    Thanks but no thanks. I've never fancied "hanging out" with the "Good ol' boys" online or offline. As I said, I fear any future interchange with you would hurt *me*, so I would actually appreciate if we didn't get in touch again as you suggested earlier... Good luck, Reza
  122. Re: Just catching up.[ Go to top ]

    I would discuss things with you in the future but it's not a big deal to me either way.


    Thanks but no thanks. I've never fancied "hanging out" with the "Good ol' boys" online or offline. As I said, I fear any future interchange with you would hurt *me*, so I would actually appreciate if we didn't get in touch again as you suggested earlier...
    Reza, I truly am sorry that I have made you so angry. I hope you will accept my apology. It wasn't intentional and I think you should realize that you made me angry too. At this point who first started problem isn't a big deal. Let's agree that it was me so we can move on. I definitely can be a jerk, I know. My wife tells me so all the time. But I'm really not the monster you seem to believe I am. I do want to say though, that I really think you are reading into things and seeing things that are not there. For example, I never suggested that we "get in touch." I don't mean this as an attack. I just think that perhaps some of what you are perceiving in my posts is not what I meant. Having said that, I will definitely try to consider my wording more carefully in the future and not post when I'm angry or irritable. Again, I apologize, I definitely don't want to harm anyone.
  123. Re: Just catching up.[ Go to top ]

    James,
    I truly am sorry that I have made you so angry. I hope you will accept my apology.
    Apology wholeheartedly accepted :-). I am sorry I missed this post last night. I agree let's move on from here, nothing good further can come from it. We all can make mistakes, clearly I've made some here. The important thing is to realize them and try our best to strive for self-improvement. Which you are and that's always admirable :-). We start with a clean slate next time - promise :-). Kind regards, Reza
  124. Re: Just catching up.[ Go to top ]

    I would actually appreciate if we didn't get in touch again as you suggested earlier
    Maybe you mean I suggested that we wouldn't get in touch. I don't think I suggested that either but in any event, another example of how easily misunderstandings can occur on these forums.
  125. Re: Just catching up.[ Go to top ]

    James,
    another example of how easily misunderstandings can occur on these forums.
    That is perhaps a distant possibility, however distant it may feel at the moment. After all, I forgot another important rule in life - never say never. You are right in one regard - I was perhaps trying to accomplish the impossible here and shouldn't be disappointed. I do wish you good luck and I mean it, whether we converse again or not. And I don't agree with some of the obvious/cruel sarcasm specifically directed at you. No matter what, no one deserves that. At worst, a man should be told these things in a direct and straightforward manner - no matter what. Best regards, Reza
  126. Re: Just catching up.[ Go to top ]

    James Your not just a troll. Your nuts. Go see a doctor, dude. I use Seam and I heard about Reza's article. Just to see this mess. Like I said, now I know why people stay away from TSS. Later. Maybe.
  127. Re: Just catching up.[ Go to top ]

    John, If you would like, please feel free to email me. My address is reza_rahman at lycos dot com. I will try to help the best I can. I am sorry I partook in this mess. Regards, Reza
  128. Re: Just catching up.[ Go to top ]

    I read it many years ago and do find that it helps me avoid sad situations like this one - although clearly not every time.
    It's just a forum, guy. It's really not that dramatic. You need to take yourself a little less seriously.
  129. Re: Just catching up.[ Go to top ]

    Guido,
    I told you twice that people I was referring to as evangelists were not you.
    And I did not claim it was an unprovocted personal attack. If that's what I thought, that's what I have told you straight up, without beating about the bush. The point is that you lumped together a number of intelligent and compassionate people together and labeled them with a very confrontational/derogatory tone. Again, stop for a second and take a look at it from my perspective. What was I *supposed* to think about your general attitude to Java EE - you tell me?
    You rounded out the post with a derogatory and overkill sentence on how EJB 3.x is bound to fail unless you are paid attention to.


    You have an incredible ability to read things never written.
    So what does this mean exactly - "Before Bitter EJB 100th edition goes for printing"? What are you trying to imply and why was this statement necessary? Think this could have been written to be less provocative? Again, you tell me what I am supposed to think about your general attitude towards Java EE? Was this supposed to make me think further conversation with you is a good investment of my time?
    Mr. Reza Rahman, your post didn't seem to be a press conference where the chairman kindly grant answers to journalists questions.
    Honestly, I have to wonder if this illusion is what was/is driving a lot of what you were doing. As I stated multiple times now, this is not "my forum" and not "your forum" or "James Watson's forum" either. It is our collective responsibility to make sure it is useful for the largest number of people possible, vis-a-vis discussion of my article. That being said, I do have the incredible privilege to make a real difference by listening and talking to as many people as I can. This forum could have been a vital means to make that happen. I do hope that's something that you can understand...
    Is TSS still a public forum?
    I think I've answered this already. If I haven't let me know. I'll try my best to answer it again.
    You cannot post a reply start saying "please, don't waste my time.
    You are exaggerating here. I didn't - it was a caveat at the end of the post and a well-guarded/conditional one at that.
    but you cannot complain about consequences without being al little ridicule
    It is not acceptable to ridicule anyone in an online setting. *Period.* *No exceptions.* *No excuses.* Again, kindly take at the netiquette guidelines as to why this is the case, even at the hand of the best comedians in the world - which I dare say *no one here is*. Regards, Reza
  130. Please explain[ Go to top ]

    With respect, it's not really that simple. You'd have to make sure all of your instance variables are thread-safe - EJB means you don't worry about that at all. For example, the Hiberate session you mention and well as the JPA EntityManager (the rough equivalent of the Hibernate session) is *not* thread safe. Spring handles this by making large portions of it's API are serialized under the hood - pretty dangeroud and fragile IMO. Just like you are, folks get into pretty lax mindsets about concurrency.
    Reza, Can you please explain this? Since you mention "under the hood", I assume you can provide an example that clarifies what exactly you are talking about here. Regards, Mark SpringSource
  131. Re: Please explain[ Go to top ]

    Mark, This is pretty simple to explain, I think. Are you aware all EJB instances are guaranteed to run in a single threaded context? This is actually one reason to implement EJB definitions as pools of instances assigned to client threads on demand. This means that EJB bean implementations need not worry about any instance variables being thread-safe *at all*. A good example is the EntityManager API that is not guaranteed to be thread-safe, similar to a Hibernate Session. Now, Spring Singletons often used to handle stateless/concurrent services (as per usage recommendations from you guys: http://static.springframework.org/spring/docs/2.5.5/reference/beans.html) have no built-in thread-safety guarantees. *This means that if an EntityManager is injected into such beans, they must be made thread safe somehow.* As far as I know, many of the Spring template APIs ensure this via internal serialization/thread-safety measures (if not, feel free to tell me otherwise). Your own Spring reference explains this well: http://static.springframework.org/spring/docs/2.5.5/reference/orm.html. Search for the word "thread-safe" on the linked page. Here is another article that talks about the same issues of Spring template API thread-safety via reentrance http://www.javalobby.org/articles/thread-safe/index.jsp?source=archives. Here is another article that generically talks about thread-safety in DI systems: http://weblogs.java.net/blog/tomwhite/archive/2006/09/are_your_beans_1.html. Perhaps that is what I should have done to rather than coming across as "picking on" Spring in particular. If this is not the case, I would shudder at anyone using Spring singletons for their service tier (including many of my own applications)! Is this clear enough or do we need to pursue this more? Honestly, it shocks me that I am even discussing this with you? That being said, its difficult to know everything all the time, especially when it comes to arcane issues like thread-safety. It is also entirely possible I am missing something...? If so, let's definitely chat more... It would definitely be helpful since I am planing to start work on a Spring based EJB 3.1 implementation as soon as I get some bandwidth (perhaps even working with SpringSource as per discussions with Rod)... Peace, Reza
  132. Re: Please explain[ Go to top ]

    This is actually one reason to implement EJB definitions as pools of instances assigned to client threads on demand. This means that EJB bean implementations need not worry about any instance variables being thread-safe *at all*.
    Writing thread-safe code in stateless services is more performant, scalable, and testable than relying on object pools. Besides, *not* worrying about thread-safety of instance variables is extremely dangerous. I honestly don't understand why that would ever be desirable.
    *This means that if an EntityManager is injected into such beans, they must be made thread safe somehow.* As far as I know, many of the Spring template APIs ensure this via internal serialization/thread-safety measures (if not, feel free to tell me otherwise).
    Spring manages a thread-bound, transactional EntityManager automatically. It behaves exactly like an injected EntityManager from an Application Server's JNDI registry, and it does not require the use of JpaTemplate. That is explained here: http://static.springframework.org/spring/docs/2.5.5/reference/orm.html#orm-jpa-straight Spring's HibernateTransactionManager likewise establishes a thread-bound, transactional Session. This can be obtained via the SessionFactory's getCurrentSession() method and therefore does not require the use of HibernateTemplate. That is explained here: http://static.springframework.org/spring/docs/2.5.5/reference/orm.html#orm-hibernate-straight Neither case has anything to do with "serialized APIs" that you implied in this statement: "Spring handles this by making large portions of it's API are serialized under the hood - pretty dangeroud and fragile IMO." I hope that provides some clarification. Regards, Mark
  133. Re: Please explain[ Go to top ]

    Mark, Unfortunately, I beg to disagree that the component model should not be inherently thread-safe or doing so has any significant performance implications (also, single-threaded execution != pooling, but we'll leave that alone for now). In my opinion, the component model should be such that the developer never needs to worry about thread-safety, whatever API he/she chooses to use. However, the truth is that one can make a valid argument (as you are) that thread safety *is* a developer concern and an API concern (the way it is for the Spring JPA template APIs and "shared proxy" entity manager model that you are referring to). I think you are missing the point on entity manager thread safety. An entity manager injected directly from JNDI without a Spring "shared proxy" is absolutely *not* thread-safe. Saying so is absolutely mis-leading. Take a look here: http://www.hibernate.org/hib_docs/entitymanager/reference/en/html_single/ (search for "Common concurrency control issues") and here: http://weblogs.java.net/blog/ss141213/archive/2005/12/dont_use_persis_1.html. That being said, it is true that the "transaction proxy" injected by Spring through non-standard enhancements for @PersistenceUnit *is* thread safe, but because of the Spring API, not because it is behaviour guarateed by any spec or any JPA vendor. That's fine as long as porting to an API/runtime other than Spring is not an issue (other than EJB, which guaratees thread-safety as I said) or the developer does not do a plain JNDI lookup/injection via @Resource or . Honesly though, I am fine to give this a rest, primarily because it is besides the point via-a-vis the purpose of the article and I doubt you will ever agree with me. Best regards, Reza
  134. Re: Please explain[ Go to top ]

    In my opinion, the component model should be such that the developer never needs to worry about thread-safety, whatever API he/she chooses to use.
    That is an unbelievably ignorant and dangerous assertion.
    I doubt you will ever agree with me.
    Not with statements like the one quoted above. Sorry. -Mark
  135. Re: Please explain[ Go to top ]

    Mark, The irony here is that I just said what you are saying is a valid point of view, but not neccessary the only point of view. And I am ignorant?? I'm not going to further comment on why you simply can't agree with me no matter what. You are not even bothering to acknowledge the obvious fact that Spring enhances the injected EntityManager functionality to provide thread-safety features that neither the spec nor any current JPA implementations provide... As I said, let's simply agree to disagree and "go our separate ways" like gentlemen without resorting to pointless and needless name-calling... Peace, Reza
  136. Re: Please explain[ Go to top ]

    Reza, My comment wasn't intended as "name-calling", so I apologize for that. I do feel rather strongly that thread-safety is something that developers need to fully consider at all times regardless of the component model. For example: never store state in an instance variable that should not be accessed concurrently. My attitude is mostly due to the surprising frequency with which I have encountered mis-understandings about thread-safety over many years of training and consulting. As far as the way Spring handles an EntityManager, its approach is an internal detail (essentially in the same sense that any EJB container's approach would be an internal detail). According to the JPA Spec, any use in a Java SE environment must take into account thread-safety for an EntityManager (or use the shareable EntityManagerFactory directly). Spring just happens to provide that support for EntityManager in a transparent way. And, as a result, this is portable (e.g. from Spring to SLSB): @PersistenceContext EntityManager em; The other benefit is of course that Spring does not require JTA-based transactions. It can transparently manage the EntityManager for local resource transaction management as well. Please understand that I am not automatically disagreeing with you. The reason I originally posted here was to clarify the statement about "serialized APIs" which sounds like something very different than what is actually happening. "Serialized" implies limiting concurrent access, whereas in truth, Spring is using thread local storage to enable highly scalable concurrent access. Regards, Mark
  137. Re: Please explain[ Go to top ]

    Mark, No problems. At least we've reached some kind of middle-ground. That's certainly better than the alternative. As you already know, I don't see Spring/EJB 3 as an either/or proposition. I think that's a false dichotomy at best. Cheers and no hard feelings. After all, I hope to work with you guys some day :-). Can't afford to have you really mad at me :-). Kind regards, Reza P.S.: We'll leave addressing the JTA comment/definition for portability/definition of serializing access to shared resources for another day. LOL :-)
  138. Nice article[ Go to top ]

    Nice summary of Java EE 6. I also believe that JAX-RS should be in the web profile. I guess it really depends what particular type of application that the "Web Profile" addresses. I would say that even the simplest web apps could benefit from JAX-RS as both something that can be used as an integration point or simply writing restfull web apps. Also, I think "Java Contexts and Dependency Injection" should be included in the web profile (AKA Webbeans). If your going to have JSF in there why not throw in the Webbeans since it really helps unify JSF with EJB.
  139. Re: Nice article[ Go to top ]

    Serge, Thanks for the kind words and the feedback. Cheers, Reza
  140. Sigh...[ Go to top ]

    I guess we can call this thread effectively over without any nazi-references...
  141. Re: Sigh...[ Go to top ]

    I guess we can call this thread effectively over without any nazi-references...
    So it's all my fault after all...so be it. I apologize for all my indiscretions. Thanks for the input and I'll try to do better next time... As to ending further posts, can't say it hasn't crossed my mind. However, as I said, I think I have an obligation to stick around for readers and fellow members of the expert group, so I will. Cheers, Reza P.S.: Before I potentially sign off from here, I think I should thank all of whom emailed me and the JSR comments alias with your support and feedback. Please do keep it up...it is vital for us to be effective.
  142. Ummm?[ Go to top ]

    I thought it was reasonably safe to refer to Godwin's Law when the last 50 posts or so had little relevance to the topic at hand. I commented on the main article to make clear that I didn't direct the blame to anybody, just stating that the thread was dead with regard to further content of interest.
  143. Re: Ummm?[ Go to top ]

    Nicklas, OK, I get it now, I was missing the point of reference. I agree. Regards, Reza
  144. The true disappointment[ Go to top ]

    Java EE Application Deployment (JSR-88) JSR 88 was an attempt at developing deployment tools that work across application servers. Unfortunately, this API has never gained much vendor support. Java EE Management (JSR-77) Similar to JSR 88, JSR 77 was an attempt at creating application server management tools that work in a cross-vendor manner. This API has not been well supported either.
    What is required is that licensing be denied vendors that do not support mechanisms such as JSR-77 and/or JSR-88. Why are the vendors given a pass when they elect to (effectively) sabotage the JEE platform's usability in order to insure the stickiness of their inferior product?
  145. Re: The true disappointment[ Go to top ]

    Joubin, Umm...it looks like there is a mis-understanding here? All current Java EE application servers support JSR-77 and JSR-88. The problem is that no one (like third-party vendors, IDEs, management tools, etc) actually took an interest in these, so they were effectively abandoned. A good example is the Eclipse application server plugins - they all use application server specific APIs. Does this address your comment or did you mean something else? Are you actually suggesting that these should not be pruned? Cheers, Reza
  146. Re: The true disappointment[ Go to top ]

    Joubin,

    Umm...it looks like there is a mis-understanding here?

    All current Java EE application servers support JSR-77 and JSR-88. The problem is that no one (like third-party vendors, IDEs, management tools, etc) actually took an interest in these, so they were effectively abandoned. A good example is the Eclipse application server plugins - they all use application server specific APIs.

    Does this address your comment or did you mean something else? Are you actually suggesting that these should not be pruned?

    Cheers,
    Reza
    Of course you are right, Reza. (It was just an attempt at humor.)
  147. Re: The true disappointment[ Go to top ]

    Joubin, OK. Let me know if you have any feedback. As you know, the public review date is closing fast and the spec will be finalized soon after that. Cheers, Reza
  148. Profiles and web profile[ Go to top ]

    Two comments on an interesting article. Personally I think profiles will only muddy the water, making it harder to sell JEE. Most people can keep track of a handful of versions. The current state of affairs with a mobile version (or rather several!), a client version and a server/enterprise version may be fine, but I don't think it is a good idea to fragment the picture more. Perhaps a web version corresponding to the new web profile may be warranted (after all there is clearly demand for it), but adding profiles means there may be additional ones and in my opinion that opens up Pandora's box. I bet there will be one or several SOA versions and other insert-your-favourite-buzzword-here versions in a not so distant time... As for the web version I agree with a previous poster that mail support should be included, it is very frequently used and it is provided by Tomcat and other potential candidates already.
  149. Re: Profiles and web profile[ Go to top ]

    Erik, Thanks for your kind words and comments. I agree Profiles are a dangerous territory to be getting into. That's why we've tried hard stop too many from being created. Comments such as yours will help ensure the same kind of discipline is carried forward. I will also follow-up on the JavaMail piece. What would help me out is for you to directly mail the EG, just to reduce a link in the chain of communication, but it is not a big deal. Thanks again, Reza
  150. Re: Profiles and web profile[ Go to top ]

    I'll send an e-mail right away.
  151. Re: Profiles and web profile[ Go to top ]

    Erik, Thanks, I just saw it come through. Reza
  152. For the record[ Go to top ]

    Contrary to claims in the article, neither I nor anyone else from the Guice team have been involved with Web Beans for quite some time. We believe Guice 2 is the right direction.
  153. Re: For the record[ Go to top ]

    Bob, Sorry if this did not correctly represent your current levels of involvement/support. The intent was to give credit where it was due. I'll make sure to correct any wrong impression going forward, so thanks for letting us know and good luck with Guice 2. Regards, Reza
  154. Re: For the record[ Go to top ]

    Sorry if this did not correctly represent your current levels of involvement/support. The intent was to give credit where it was due.
    No need to apologize! I just didn't want to take credit where it isn't due. :-) Bob
  155. Re: For the record[ Go to top ]

    Bob, I am glad to see you are still watching this thread! While I have some of your time, do you mind commenting on what, if any, course corrections Java EE 6 (or perhaps JSR 299 in particular or EJB 3.1) neeeds? I'll confess I haven't looked at Guice in great detail besides noting some of the obviuos overlap with JSR 299 (most of them features I think are very valuable and innovative). If you like, we can do this off-line. My email is reza_rahman at lycos dot com. I think your comments would be valuable and I can try my best to make sure they are heard (if that is even really the issue). Kind regards, Reza P.S.: As much as this is probably venturing into personal matters, I am a little dissapointed to hear that you are not working on JSR 299 anymore and Google would not have a JSR 299 impleentation. Personally, I saw that as something very positive from your apparent early involvement. Please do feel free to ignore this as irrelevant. I reality it's nothing more than personal curiuosity.