|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 41
Messages: 41
Messages: 41
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Editorial: Where Java EE goes horribly wrong
Sure, Java EE covers everything but the corner cases... but why, oh why are there so many corner cases?!
Java EE rocks, it really does. I'm usually quite happy working with it. But it strikes me -- while it handles nearly everything but the corner cases, it leaves so many corner cases as to make itself less useful than it could or should be. It's the Achilles' heel of Java.
For example, look at my recent travails with getting a JMS destination populated for an EIS component. This shouldn't be that big of a deal, really, considering that I've an inbound EIS component that communicates with a resource in JNDI.
Here's the backstory: I'm writing an EIS component to receive mail. It needs to falsify email addresses (i.e., all addresses are dynamic) and my intent was, as email came in, to forward each email to a JMS queue. The JMS queue would be listened to by a message-driven bean, which would ignore the email or ... well... not ignore it.
I wanted this in an EIS component because that way I don't have to remember to start up all of my application components: I'd start my database and my application server, and be done with it.
Thus, my EIS component wants to have JMS ready to go when it starts, because otherwise it'll bind to a port and have nowhere to go with it. That's where my "problem" comes in.
It turns out that in Glassfish, JNDI isn't populated until after server startup finishes. Thus, my EIS component initializes, and it will never have JNDI available to it when it starts. That's by design, apparently, and is the source of a bug I filed with Glassfish already, if I'm not mistaken. (Bug #1950, which happens to be the year I wasn't born.)
I need a Glassfish Lifecycle module, to watch for when the server is ready, and then I can get the JNDI context from the lifecycle process. I can start threads there (as long as I shut them down) and do whatever I need. This is in some ways a cleaner solution than what I'd done, because instead of balkanizing SubEthaSMTP, I can just start SubEthaSMTP in a lifecycle module and have done.
But... what happens if I want to move to, say, JBoss? Or OC4J? Or WebLogic? Or WebSphere? Geronimo? JONAS? RESIN? I'm using Glassfish for the moment, for development - primarily because it's the reference implementation of the specification, not for any magical qualities it has as an application server. Writing a lifecycle event is fine if I'm staying on Glassfish, but I have no desire to be tied to a specific server if I can help it. These lifecycles are specific to Glassfish - other servers aren't likely to follow its lead.
Java EE has, in this case, failed me. This isn't that big of a deal, except for this is the kind of corner case that you run into over and over and over and over again with Java EE.
You want to know why people look at Spring as if it's the Messiah? You want to know why TheServerSide.com keeps yakking about OSGi and grids and Ruby and AJAX and other stuff? THIS IS WHY. They provide ways around the corner cases. Not always - I'm waiting for an OSGi or Spring template for an application server (i.e., "inject an app server into this bean and start it...") but that allows us to treat the corner cases like what they are - corner cases instead of barriers to constantly be confronted.
Java EE doesn't suck - not really - but let's be real, it DOES suck in ways it shouldn't. The spec has to have ways to address these corner cases, provide things that developers like me can rely on. I know I have options here, I'm just dissatisfied with every cotton-pickin' one of them.
Some people are going to argue that providing injection points for these problems will increase complexity - witness people complaining about all the phaselistener things in JSF 2.0. Hey, I get that. But let's be realistic: you don't have to use the capabilities if you don't need them. It's just that if you do need them, right now, you're left adrift, screwed over by spec authors who feel that it's more important to address common capabilities instead of common NEEDS.
This has got to change, or else Bruce Tate's proclamation that Java is "dead like COBOL" - meaning quite alive, but not extremely vibrant - will come true after all.
|
|
|
Message #230657
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Editorial: Where Java EE goes horribly wrong
Welcome to the world of standard before implementation. Personally I think that Java EE is made unnecessarily complex and hard to customize in the interest of tool and server vendors. After all it's much harder to sell tools and servers for lightweight component-based frameworks like Spring...
It is interesting that some people are so afraid of vendor lock-in they don't even consider that sticking to standards may be the most efficient way of ensuring vendor revenue. Not that I have anything against making money on middleware, but I wish it would be services, not frameworks.
Jevgeni Kabanov
www.araneaframework.org
|
|
|
Message #230658
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Generally agreed..
But... what happens if I want to move to, say, JBoss? Or OC4J? Or WebLogic? Or WebSphere? Geronimo? JONAS? RESIN?
This is apparently a common problem with J2EE - illusory vendor independence. Moving to another vendor, you HAVE to face some of your modules are not working anymore. Even moving, for instance, from Weblogic 8.x to Weblogic 9 is sometimes an extremely painful process - so one can imagine what issues may wait for you when switching vendors.
Anyway, I think such monsters as J2EE are kinda able to heal itself as it now happens with hibernate-based EJB 3.0. When really bad disadvantages appear, J2EE eventually goes to its competitors to take all the advantages from them. So popularity of, let's say, Ruby and AJAX (AJAX also gives its regards to obvious obsolescent HTTP protocol) is in the end profitable for everyone, including J2EE developers imho.
|
|
|
Message #230663
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Editorial: Where Java EE goes horribly wrong
You're absolutely right.
There are all of these corner cases that folks rarely bump in to, but when they do, those corners are sharp and knee high.
On the one hand, as I said, those cases ARE indeed rare, but on the other LOTS of folks use the system, so lots of rare events appear to happen more often. Add the equalizing power of the internet, and those rare cases can have the perception of being common.
This post is a perfect example.
That said, and I do agree with you as I have bruised knees myself, I don't blame the JEE spec for it.
Rather I look at experiences like this as data that needs to be considered when the JEE spec gets revisited yet again.
I know it's not happening anytime "soon", but I think a lot of folks will admit that JEE 5 really got a lot more of the basics right. Its much much more solid and usable today than it ever was before, and now they'll be able to work on more of those corner cases that folks run in to, like you just did.
But to be fair, what you ran in to is actually a hidden "feature" of the system. I know, you'll all call me insane, but it's true.
The feature of the system is precisely in these corner cases, as this is where the container developers can distinguish their systems from others.
You ran in to an implementation detail. You filed a bug, but they did what they did by design. And they get around the issue with their Lifecycle Listener, a non-portable artifact.
But appreciate that JEE is a specification, and not an implementation. Perhaps this exact case came up in the committee discussions but it was realized that all of the major vendors simply handled this particular aspect of container startup in ways that differed enough to make "standardizing" this aspect less important than other aspects of the JEE specification in terms of bang/buck of limited container implementation dollars and time. Like you, they may have realized that this is indeed a corner case and a rare event, particularly compared to the other major factors of the specification.
In a sense, be grateful that Glassfish exposes ANY mechanism to do what you want to do. A simpler container, perhaps, may not have even exposed such functionality, as it is "out of scope" of the specification.
So, while I agree it's frustrating, I, personally, accept this reality for the simple reason that I LIKE having a dozen different EJB containers to pick from.
I don't have that flexibility with Spring. That's a love it or leave it proposition. I can't get a better documented Spring, an easier to use Spring, a Spring that takes less memory, a "lighter weight" Spring, or whatever. Spring is a single implementation. And the question isn't "why would someone want a 'different' Spring', the point is simply that you can't get one.
But if I'm unhappy with my BEA/IBM/Sun/JBoss/Apache App server, I can look elsewhere for a faster/cheaper/smaller/embeddable/modular etc. EJB App Server. I can look to the vendors to make the JEE standard that much better because they'll come up with non-portable artifacts to work around its warts.
As EJB matures, more folks will port applications across App servers, and as more folks port, more pain points of porting will come up. And those pain points will be logged with the vendors and JEE standard committees to get us all a more portable JEE spec in the future. Those non-portable artifacts will become deprecated and replaced with a portable mechanism newly specified in the latest specification. We've seen that happen every time the new spec comes out.
So, while I feel your pain, just appreciate, as you grit your teeth, hold your nose or whatever your coping mechanism is (perhaps writing internet posts :-)), that this is in fact a feature, and not a bug.
|
|
|
Message #230664
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Editorial: Where Java EE goes horribly wrong
Let me first preface by saying I have not worked with EIS, and I have not used JCA.
I have however written a lot of EJB(Both Session. Entity and MD)/Servlet/JMS applications and put those into production.
Is the EIS running inside the Glassfish container? Or is it in a separate process space?
I don't think this is an issue with J2EE. I think your assumption that the JNDI Tree and all of the JMS objects be up and running on start up is not really realistic.
Even if your EIS is in the Glashfish container, things can happen to JMS that could cause your application to lose connectivity. (Something might happen to your message store, some admin might un-deploy your queues.)
If your EIS is outside of the Glassfish container, it makes it even more important to not count on JNDI being there. Even if it was up on startup, what if some sort of adverse event occurs and your J2EE server goes down? Your adapter will not be able to connect to the JMS Queue again.
You should have sort of lazy connecting to the JMS Queue. So that if even if it is up when you start up, and if it goes down, you'll be able to reconnect.
To assume that your application will have the entire infrastructure available to it at start up, and will never lose it is a recipe for a production disaster.
Joe
|
|
|
Message #230666
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Editorial: Where Java EE goes horribly wrong
source of a bug I filed with Glassfish already
The bug report complains that "Webapps are initialized before Connection Pools/JNDI are". Is it correct ? One of my WEB apps uses JNDI (it starts EJB timer) from ServletContextListener and it runs on SJAS 9.
I have had problems with security realms in Glassfish, because they are initialized before connection pools and JNDI, indeed. So I had to use old and awkward way to get db connection.
But have you tried to use another application server? I remember that in WL you can access connection pools from security realms.
Or maybe you can initialize you'r EIS from ServletContextListener of a dummy WEB application ? You should have JNDI context then. It might not be very elegant solutions, but it would work in all JavaEE servers.
Also in Glassfish there is an option which turns off "lazy initialization" of it's components. Perhaps that might help?
|
|
|
Message #230668
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Editorial: Where Java EE goes horribly wrong
As I said you don't need any LifecycleListener to initialize something after server startup. Besides ServletContextListener there is another solution - a simple servlet with load-on-startup > 0 in web.xml. It would work in older J2EE versions that doesn't have ServletContextListener. Is there any reason you can't do that?
|
|
|
Message #230671
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Decent point, rubbish example
While there may be significant corner cases where Java EE causes headaches, I think this example is awful. Would you expect your JDBC driver to have direct access to a JMS queue? How about your mainframe resource adapter?
Java EE espouses a complete architecture, which includes functional layers. At the "top" (closest to the client) are the usual suspects (JSF, Servlets, JSP, etc.). Not until you reach the "bottom" do you find JDBC and Resource Adapters. It just doesn't make sense for anyone to build an application as a resource adapter. EIS stands for "Enterprise Information Source", which makes perfect sense if you're trying to write an SMTP, IMAP, or POP3 protocol implementation. What doesn't make sense is for you to write an application into the Java EE equivalent of a device driver. I don't expect my keyboard driver to do spell checking, do I? User-level code belongs in the "application" space, which can be activated from the "top" or the "bottom".
Instead of connecting your EIS (email) directly to JMS, can I suggest you connect the J2CA 1.5 compliant resource adapter directly to your MDB? There is a lifecycle mechanism built in there that you might find useful (and portable). Then, you might actually have a chance of building a different application to process email messages in potentially different ways, too!
To be fair, I can understand how you came to your conclusions. J2CA is one of the most difficult specs to understand, and it isn't particularly well-placed in most of the documentation I've seen (which is perhaps a meta-point to your post). The weight of the specs makes it difficult even to know in which corner to start looking...
|
|
|
Message #230672
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reality check
> As EJB matures ...
Will, are you serious? How many more years do you want to wait for uncle X to make you happy? Bile-style comments go next...
The point is 'non-spec' alternatives exist today and ARE usable. And, being pragmatic, I'll use those whenever I can to get the job done, and not deal with 'vapourware'.
|
|
|
Message #230676
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Decent point, rubbish example
Instead of connecting your EIS (email) directly to JMS, can I suggest you connect the J2CA 1.5 compliant resource adapter directly to your MDB? There is a lifecycle mechanism built in there that you might find useful (and portable). Then, you might actually have a chance of building a different application to process email messages in potentially different ways, too!
To be fair, I can understand how you came to your conclusions. J2CA is one of the most difficult specs to understand, and it isn't particularly well-placed in most of the documentation I've seen (which is perhaps a meta-point to your post). The weight of the specs makes it difficult even to know in which corner to start looking... That's an entirely valid point. To be honest, I don't know enough about connecting the outbound data to feed into an MDB - the only examples I have use polling to check an external POP3 system, instead of serving as an SMTP endpoint. I'd LURRRRRRRRRVE to have someone shine some light here....
|
|
|
Message #230678
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Editorial: Where Java EE goes horribly wrong
There will always be corner cases. You can push cases further into the corner but they will always be there and nothing -- not Spring, Ruby, OSGI, nor anything else you can think of will EVER change that. You can argue that the problem you ran into shouldn't have been a corner case but I'm guessing that everyone feels that their headaches shouldn't be corner cases either. To put it simply: there are infinite possibilities.
If the world of programming were so simple, we wouldn't need programmers. Programmers are required for all the little gothchas that you run into when developing and deploying an application.
|
|
|
Message #230679
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
bingo
You nailed it.
Look at JSF standard. How many vendors implement it? Only one that I know of -- Oracle. There is an open source project myfaces and RI.
The only time we need standards is when we want closed source vendors to compete. However, if some area is dominated by open source, like say, frameworks and other middleware, then standards only serve as sand in the gears of what should be a well oiled machine.
Standards are fine if you expect to have at least 5 closed source vendors competing. But if most competition is from open source and then you have 2 closed source vendors that both kind of suck compared to the open source solutions, then what is the point of standards?
Open source trumps standards any day because it allows implementation to be the focus of effort, instead of specification being the focus of effort as it happens in standards.
Closed source non-standard development sucks the hardest for reasons that I hope are obvious to everyone here.
Closed source written to an open standard is better.
Open source is by far the best, since without any friction of a standard you get all the benefits of openness and competition.
If you use a closed source solution written to a standard, then you can never enjoy rich or enhanced or elegant API, because such APIs only appear when people make implementation their number one goal. Since the point of using a standard implementation is to specifically NOT to step out of the bounds of standard, and to specifically NOT to use vendor extensions, then you end up with competition based only on efficiency and stability and not based on elegance of APIs.
|
|
|
Message #230684
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
umm?? looks suspicious
Did you look at that list? Many of those are not JSF implementations at all. Many myfaces projects are listed in separate columns. There is at least one framework listed that has nothing to do with JSF. Etc.
That list looks suspicious to me, because it's a list of apples and oranges and pears and who knows what else.
I accept there may be more JSF implementations than I know of. Maybe there are 4 or 5.
Also a commercial implementation that is based on myfaces or RI does not count as an independent implementation in my book, since it will inherit all the flaws (and benefits) of the parent implementation.
|
|
|
Message #230687
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: bingo
You nailed it.
Look at JSF standard. How many vendors implement it? Only one that I know of -- Oracle. There is an open source project myfaces and RI.
The only time we need standards is when we want closed source vendors to compete. However, if some area is dominated by open source, like say, frameworks and other middleware, then standards only serve as sand in the gears of what should be a well oiled machine.
Standards are fine if you expect to have at least 5 closed source vendors competing. But if most competition is from open source and then you have 2 closed source vendors that both kind of suck compared to the open source solutions, then what is the point of standards?
Open source trumps standards any day because it allows implementation to be the focus of effort, instead of specification being the focus of effort as it happens in standards.
Closed source non-standard development sucks the hardest for reasons that I hope are obvious to everyone here.
Closed source written to an open standard is better.
Open source is by far the best, since without any friction of a standard you get all the benefits of openness and competition.
If you use a closed source solution written to a standard, then you can never enjoy rich or enhanced or elegant API, because such APIs only appear when people make implementation their number one goal. Since the point of using a standard implementation is to specifically NOT to step out of the bounds of standard, and to specifically NOT to use vendor extensions, then you end up with competition based only on efficiency and stability and not based on elegance of APIs.
Services API standardization is really important (JDBC, JTA,.. ) but IMO frameworks or component models (JSF, EJB, ...) should never be standardized (and for the record I like JSF) because :
1) Your application has always a lot more dependency on a framework than on a service API. A service API can always be wrapped behind a gateway or an adapter but a framework by nature can't be hidden from your application (for the record I don't consider an IoC container as a framework).
2) There are always corner cases that you will have to deal with and to do so you'll have to use some proprietary extensions but according to #1 it's hard to wrap a component model/framework) and make your application portable on every server.
So I think any portable component model is kind of a myth unless it's built directly in the JVM.
Plus, frameworks tend to evolve a lot more faster than service APIs which are by nature more stable so I believe the open source non standard model is a lot more suited to the task since specification are too long to come out.
The only thing that should be standardized about components if you ask me is a way to expose them to a remote protocol (http, rmi, jmx, ...) using some annotations for instance. Other than that I believe more in open source frameworks.
|
|
|
Message #230689
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Reality check
Will, are you serious?
You bet!
How many more years do you want to wait for uncle X to make you happy?
Why would I have to wait at all?
The specific problem this guy is having is a PORTABILITY problem, not a functional problem. He was fully capable of being able to solve the particular issue that he was having. But then he expressed a concern that his solution wouldn't port to other containers.
The point is 'non-spec' alternatives exist today and ARE usable.
Of course there are.
And, being pragmatic, I'll use those whenever I can to get the job done, and not deal with 'vapourware'.
Who said anything about 'vapourware'?
The guy is having an issue of POTENTIALLY porting his application to another EJB container. Saying "Look, here's a rough edge that the JEE spec doesn't cover that affects porting my application".
In the long term, since he's talking about a specification here, if enough people encounter and file issues about this portability issue, then the specification will address it and ideally make it possible for him to do what he wants in a portable way in the future. Is it likely? I dunno. But is it possible? Yes, it's certainly possible.
But none of that is keeping him from doing it now.
He could simply say "I don't care about portability" and code straight to the Glassfish APIs. Just like many code to Spring. They don't worry about portability either. It's simply not a concern on their radar. He'll probably do the right thing in isolating his code so that he can make porting to other containers (using their specific APIs) easier. Then, he may not. Burn that bridge if and when we come to it.
Just like some folks embrace Oracle for all of its Oracle-ness, while others treat it as simply a SQL database no different from MySQL or SQL Server. I mean, seriously, how many folks REALLY port their database once they're in production? Ask any DB vendor. When they get entrenched in an organization, changing the DB is like pulling wisdom teeth -- you need sedatives and high explosives to get the job done.
But as with any widely adopted specification, different vendors will handle the "corner cases" in their own way. As the corner cases become more prevalent and important, then these corner cases get codified and incorporated in to the specification, transforming from corner cases to portable constructs.
I LIKE that we have a popular specification, and that multiple vendors are out there beating on each other through features and such. Over time, that trend improves all of the containers.
If some super paradigm comes out, then, thanks to the flexibility of Java in general, we don't have to stick to the spec at all. How many EJB 2 apps are using Hibernate today replacing their Entity beans, or working along side them? Or using Spring for injecting some resources in to their application?
But, now, with things like JPA, there's no longer a reason to work solely with Hibernate. Rather, developers can work with JPA using Hibernate as a back end (I think there's at least 4 JPA backends out there). But now, because of the JPA, you don't have to necessarily pick Hibernate or, say, Toplink. You can pick JPA and then later choose Hibernate over Toplink. Because more of the interaction between your code and the ORM layer is mandated by an independent specification, which mean there's less to port from one implementation to another.
This cuts both ways. It makes it easier for someone to port away from Hibernate while at the same time allowing them the ability to port TO Hibernate. That makes it easy for Hibernate to come in and talk you out of using Toplink. Maybe they have a better feature, or are faster, or whatever.
Portability is simply a single aspect of the entire application development equation. You can look at coding to a published specification in a similar light to late binding. The longer the specification meets your needs, the longer you do not have to commit to any particular implementation of that specification.
And that just helps everyone involved.
It helps developers by being able to "develop against Tomcat and deploy to Weblogic" or not being trapped by a particular implementation (a zillion years ago we had major problems with Netscapes server and because of the 1.x Servlet spec, we were able to drop it like a hot rock when we ran in to insurmountable problems).
It also helps vendors because they're able to compete in the same space as their competitors. Do you think JBoss would be as big and as popular if it weren't JEE compliant? And with the JEE specification, it gave industry the warm fuzzy of portability of their application as well as portability of their developers. Today, enterprise application developers are either JEE or .NET. "Wanted J2EE developer, Weblogic preferrred." Note, that's not "Weblogic Developer, J2EE preferred."
Look at how the great OODBMS vs RDBMS wars worked out. Do you think MySQL would be as popular as it is if it didn't use SQL? It evens uses it BADLY, but it's Close Enough for most purposes.
So public standards are not a crutch, nor are they an albatross around your neck. You use them as far as they'll take you. As standards gain momentum, they get better, and ideally you'll be able to do more of your work within the standard in order to get the larger macro benefits of having one in the first place.
But if you can't find a standard you like, then move on, absolutely. The standard should never hold you back. The implementation can, as any implementation. But the standard won't.
Personally, I try to work within the standards I use as much as I can. I will make the effort if something seems that it doesn't quite fit the standard to see if there is a way, or perhaps a compromise that well suits both the standard and the application. Maybe if I save the corners of my square peg it'll fit a little bit better. But I only take that so far. I'm not going to let it get in the way of the application.
|
|
|
Message #230690
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Reality check
The specific problem this guy is having is a PORTABILITY problem, not a functional problem. He was fully capable of being able to solve the particular issue that he was having. But then he expressed a concern that his solution wouldn't port to other containers.
If we don't care about portability, we burden ourselves with the complexity of these standards? Isn't that really the crux of the issue?
If I don't misunderstand the problem, he just wants to send an email to a message queue. If you get rid of all the alphabet soup this is a really very simple thing to do. I've spent many an hour trying to get J2EE tools to do the most trivial things. I guess that's why I haven't been real excited to dive into J6EE or whatever version Sun's marketing is calling it now.
|
|
|
Message #230693
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Reality check
But, now, with things like JPA, there's no longer a reason to work solely with Hibernate. Rather, developers can work with JPA using Hibernate as a back end (I think there's at least 4 JPA backends out there). But now, because of the JPA, you don't have to necessarily pick Hibernate or, say, Toplink. You can pick JPA and then later choose Hibernate over Toplink. Because more of the interaction between your code and the ORM layer is mandated by an independent specification, which mean there's less to port from one implementation to another.
The point is correct that coding to a spec is "the way".
Your example however is just the same as the Editorial situation with the "J2EE spec". You have a "specification" but it doesnt go far enough. OK, in this situation its ver 1 of JPA and we all hope that it goes further in a future release, but there is too much that isnt covered ... and in that particular case we arent just talking "corner" cases. Some basic relationship types arent even mentioned. Some basic types aren't included for persistence. So you end up relying on an implementations own way. This is not a comment that Hibernate (or Toplink, or BEA Kodo) dont provide all the tools for the job, they do ... but in their own way that are outside the spec in question.
|
|
|
Message #230694
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It is not a corner case
Joseph, it is not a corner case. I used to ran into things like this on a daily basis.
As others point out it is simply the problem of an API specification that has been designed on paper without asking a hand full of developers to design their application with it first.
Application server vendors recognize this and implement extensions. Glassfish has lifecycle modules, JBoss EJB3 has a @Service annotation, etc. etc. This leads to lock-in, tying your code heavily to a specific app server.
For me it is one of the reasons why Spring has been so succesful for my projects. It gives you all the power and (optional) features that you need to solve problems like you describe. And with a little effort even the most complex Spring apps can run without modifications on any app server.
S.
|
|
|
Message #230708
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Following specifications
Salaam,
Respectfully, Joseph, the issue here appears to be a misuse of the JEE architecture, as the specification addresses EIS life-cycle management.
If you look at the specification for JEE Connectors, which is the *only* specified mechanism for connecting a JEE server to external information systems (EIS), you'll note the whole spec is fundamentally a connectivity protocol, naturally including the semantics of starting an EIS connection (Ch. 5 Life Cycle Management) by the server. 5.3 defines the life cycle management api of Connector Architecture.
You would be expected to write a ResourceAdapater bean, which during either the server startup, or, your resource startup, would be called with start(). 13.2 has a diagram pretty much addressing precisely what you are describing here, btw.
Now here is perhaps a shortcoming of JEE conception or a given deployment of a JEE application (such as yours), but when your application server owns both the JNDI and JMS provider then clearly these resources are scoped within the application life-cycle.
Your server is 'the world' and your inbound EIS is part of this world, but somehow has a leg up in startup, which is a conceptual issue on your part. If 'the world' of your application extends beyond your server, in terms of life-cycle, then you either have to place critical resources outside of your server, or, have dependent external components wait to be notified regarding the creation of the world.
So we run into problems for two reasons:
1 - Life-cycle dependencies, due to connectivity management between your system elements. Your EIS expects a JNDI resource and a JMS resource, when you know that these are child sub-systems of your server. Your external component needs to block until notified of the server availability. (How?)
2 - Life-cycle management of EIS *adapters*:
Referencing Connector Architecture 1.5, we note the need to create a resource adapter component for use by the server to notify our eis adapter of 'startup' event for the eis. This is where you notify your inbound component that 'the world is up'.
Should you follow the connector spec., it is to be expected that you should be able to port to any other JEE compliant app server. (Any issues there are related to the vendor and compliance management by Sun.)
/& Salaam
|
|
|
Message #230709
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I hate having flies in my soup, let me just eat flies then.
I am not sure I get your point.
You are criticizing EE because it doesn't cover all of your corner cases and that you have to rely on non-standard API to fulfill these gaps, right?
And then you explain us that it is the reason why some people are moving away from EE and are leveraging non-standard/proprietary APIs/frameworks, right?
I fail to understand your point because if you do not care about using standards API in the first place (as you seem willing to use non-standard ones), why do you care about having to use a few of them as part of a EE environment, to fulfill your specific requirements/corner cases? It sounds a bit like "I hate having to use a few non-API as part of my EE deployment, so let me not use any standard API at all".
As for your original point (EE not fulfilling all corner cases), I think that is pretty normal for a standard. If your use cases become more mainstream, feel free to raise them to the EE spec body: EE6 JSR just started.
It seems easier to go proprietary (or complain) then spend energy in a standardization effort these days. It might be useful to remember that standardization efforts (as well as the EE standard) are one of the key reasons why the Java ecosystem has been so successful and diverse.
Onward,
Sacha
|
|
|
Message #230713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I hate having flies in my soup, let me just eat flies then.
+1
Ruby, ASP.net are NON standard. They are created by one manufacturer and NOT portable.
So Why author of this thread complains of not portable solutions in Java World?? Standarlize everything? Is it good direction?
One of the post above remarks that Service API should be standarlized and frameworks API not, because it must quick change for demand of market. Ruby and ASP are not not restrains by standards, they do right job.
|
|
|
Message #230715
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
And it doesn't get any better with clustering
Good points Joseph, couldn't agree more.
And JEE limitations are even a lot worse when you get into clustering. Oh wait, the word "cluster" isn't even mentioned in the JEE spec ? Isn't there obviously something wrong there ;) (if you don't believe me, download JSR 244 and search for "cluster")
Ever tried to send JMX notifications to all nodes in a cluster (e.g. to trigger cache reloading) ? I did, and it's not fun, not at all, proprietary mechanisms for each application server (JBoss was easiest to deploy though)
It is somewhat bewildering to find out that several mechanisms are completely lacking in JEE, and I'm not sure those are "corner cases" in any way. And don't even get me started on JAAS.
More hooks, more customization, clustering capable services -- IMO that's the sort of things that are needed in the JEE specification (and are much easier to address with Spring as of now).
|
|
|
Message #230717
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I hate having flies in my soup, let me just eat flies then.
But Joe has a good point. EE needs a real kernel behind it so that we as vendors can extend and innovate and yet be portable to other application servers. From the beginning, if EE had started out as a kernel specification and then built on top of it specifications like JCA, JMS, EJB, etc. we'd be a lot better off.
Bill
|
|
|
Message #230718
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Implementation vs. Spec
Do we really want Java EE to be a spec, or wouldn't we all really rather forgo the pain and have Java EE be an implementation?
In my thinking, Java EE has become part of the Operating System, and just as a multitude of Unix implementations left the door open for Windows and Linux to dominate the OS landscape, a multitude of Java EE implementations (with all the unavoidable porting querks that entails) is leaving the door open for implementation, such as Ruby, to perhaps take the lion's share of the market.
John
|
|
|
Message #230719
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Implementation vs. Spec
Do we really want Java EE to be a spec, or wouldn't we all really rather forgo the pain and have Java EE be an implementation?
Sorry, you've lost me. An "implementation" by definition implements something. Consequently we have a specification to define what is implemented and an implementation to implement it. An implementation written by whom ?
J2EE will not become part of my operating system anytime soon.
|
|
|
Message #230729
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Editorial: Where Java EE goes horribly wrong
Adding event mechanisms to j2ee servers as a standart may help. ServerListener for standart server activities, AdminListener for administator activites, JndiListener for JNDI changes, ConnectionPoolListener for connection pool events etc...
Basically we may try to get a resource at first if it is not available we may add an appropriate listener to wait for it to be available.
And also we may listen to those resources to tear down our application when some resources are gone. This may make our applications safer.
|
|
|
Message #230733
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I hate having flies in my soup, let me just eat flies then.
I am not sure I get your point.
You are criticizing EE because it doesn't cover all of your corner cases and that you have to rely on non-standard API to fulfill these gaps, right?
And then you explain us that it is the reason why some people are moving away from EE and are leveraging non-standard/proprietary APIs/frameworks, right?
I fail to understand your point because if you do not care about using standards API in the first place (as you seem willing to use non-standard ones), why do you care about having to use a few of them as part of a EE environment, to fulfill your specific requirements/corner cases? It sounds a bit like "I hate having to use a few non-API as part of my EE deployment, so let me not use any standard API at all". Sacha, you misunderstood me. I do prefer to avoid using nonstandard APIs, because portability is incredibly important to me. I use Glassfish at the moment for development... but that doesn't mean I intend to use Glassfish everywhere. Like I said, I might move to JBoss, WAS, WL, Geronimo, etc. I cannot and do not endorse a given application server, and I take that very seriously. If I write something that doesn't port well, then I'm creating extra work for myself, and since I'm kinda lazy, that repels me.
What bothers me is not that corner cases exist. What bothers me is that they exist in places they shouldn't. You'd be surprised at how many people pragmatically abandon Java for various purposes, simply because doing things is "too hard" or simply so much easier in another language. I'm obviously a "homer" in that if I can use Java, I want to use Java... and my goals specifically include furthering Java as a whole.
I want the standards to be complete enough that I can do things as easily as I think they should be done. I don't care if Java EE doesn't specify a mail server; I do care if Java EE makes writing that mail server a pain in the rear.
(It turns out that it doesn't - due to some excellent responses on this thread, I finally got it through my thick skull what I should have been doing, and got it done. I'll be posting the project on java.net soon.)As for your original point (EE not fulfilling all corner cases), I think that is pretty normal for a standard. If your use cases become more mainstream, feel free to raise them to the EE spec body: EE6 JSR just started.
It seems easier to go proprietary (or complain) then spend energy in a standardization effort these days. It might be useful to remember that standardization efforts (as well as the EE standard) are one of the key reasons why the Java ecosystem has been so successful and diverse. Sacha, I have no problem participating in standards bodies - I'm a member of the JCP and have been for some years. I have my own views as to what the standards bodies do, and also what to do to fix 'em. :)
|
|
|
Message #230735
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: And it doesn't get any better with clustering
is JMX in JEE spec? I wonder...
and for ur case, should it be handled very well by using Topic and MDB? all are JEE standard...
let's discuss. I think we can learn more :)
|
|
|
Message #230736
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Decent point, rubbish example
should it be the problem of POP3 protocol itself instead of the spec from JEE? let's thinking of a "outlook express" client connecting to a POP3 server, it is using "polling" too. I think we share blame on POP3 protocol instead of JEE. what do u think?
|
|
|
Message #230770
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Editorial: Where Java EE goes horribly wrong
Here's the backstory: I'm writing an EIS component to receive mail. It needs to falsify email addresses (i.e., all addresses are dynamic) and my intent was, as email came in, to forward each email to a JMS queue. The JMS queue would be listened to by a message-driven bean, which would ignore the email or ... well... not ignore it.
I wanted this in an EIS component because that way I don't have to remember to start up all of my application components: I'd start my database and my application server, and be done with it.
I work for Sun so I could be a bit biased here, but you can build and manage that very easily with Sun's Java CAPS (formerly known as SeeBeeyond's ICAN) without being bothered by writing JCA resource adapters yourself as there is an inbound / outbound email adapter and working with MDBs is a child's play. Unfortunately the product is still not available as opensource while most of Sun software is, but hopefully it will be soon.
Regards,
MT
|
|
|
Message #230787
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Editorial: Where Java EE goes horribly wrong
I work for Sun so I could be a bit biased here, but you can build and manage that very easily with Sun's Java CAPS (formerly known as SeeBeeyond's ICAN) without being bothered by writing JCA resource adapters yourself as there is an inbound / outbound email adapter and working with MDBs is a child's play. Unfortunately the product is still not available as opensource while most of Sun software is, but hopefully it will be soon.
Regards,
MT Thank you! However, I've already gotten the SMTP RA working - it's waiting for approval on Java.net, and it'll be released under the ASL.
|
|
|
Message #230828
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
You gotta look at the big picture
Something we've been using for years, which was once thought to be the end-all of software, starts looking bad. Some people try to patch it up, while others go on to develop radical new solutions. Eventually one of the newcomers takes over and becomes the new standard, and the cycle continues.
I've seen this happen enough times that I don't complain about it anymore. I've come to accept it as the way we do business.
You can't have long-term success in software if you aren't willing to throw out everything you know every few years and start over. The first language I learned was BASIC. In college we used Pascal. My first job used C, then later C++. Today I use J2EE. Tomorrow, it could be Ruby on Rails, or something else.
My advice is, don't get so married to Java that you feel like it's the end of the world when it doesn't do what you want. There will be a time when moving to the next thing makes sense. Until then, there will be workarounds. The best programmers know when it's time to make a switch. The worst programmers are the ones who plant a stake in the ground, say "I'll never switch", and spend the rest of their careers trying to breathe life into a dead platform.
Frank
|
|
|
Message #230833
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: You gotta look at the big picture
Agree.
The right tool depends on the job style you must do, not on your knowledge of one or more tools.
With a chainsaw you can ease tree chopping. Try to use the same tool to get your haircut.
Obviously a chainsaw is far more complicated than a scissor.
But thats the price (the real price) you must pay.
C for a distributed and clustered application? sure you can do. hopefully you'll end in the next 32 years.
Java to create a DVD-ROM driver? HAHAHA.
|
|
|
Message #230847
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: You gotta look at the big picture
I actually wrote web applications in C++ for a few years in the 90's. This was back at a time when the only other way to add programming to a web site was through a "cgi-bin" executable. We had our own HTTP server, and our own way of extending it via DLLs. We even had our own scripting language, which I wrote myself, and considered the centerpiece of the whole affair.
It was great for a while - we were the only guys in town who could could build business logic into a web site without the overhead of cgi-bin.
It broke down eventually of course. Once people were doing Java servlets and ActiveX, other shops were vastly more productive because they could leverage so much of the work of others for free.
Sometimes it's hard to change, when you've invested so much time in something. I used to know the HTTP protocol and the Windows sockets APIs like the back of my hand. I could parse and interpret a script in C code, complete with loops, variables, and function calls. Before that I was a BBS guy. I knew serial ports and modem AT command sets. I indexed my own data files.
Sometimes I wish the day will come when I need these skills again, but I realize it won't. Today I write servlets and taglibs and EJBs like everyone else. It's what the job is in 2007.
Frank
|
|
|
Message #230994
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
javax.management.j2ee Listeners
Did you try the javax.management.j2ee Listeners?
These are part of the Java EE spec.
You could e.g. try to register a NotificationListener with the J2EEManagedObject "JNDIResource".
|
|
|
Message #236551
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
which one is ur OS?
J2EE will not become part of my operating system anytime soon.
Ohh You have your own Operation system also, Gr8 'Raul'.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
