Aha, well, can you define the diffence between the two? Inquiring minds want to know!
And inquiring minds want to know what technology can combat the paragraph of random english words or just pseudo-words that seem to throw-off the 'spam-ness' score using either tech.
I would hope that it would use IPs also. Our site is currently receiving mortgage spam that slips past our current amavisd-new + spamassasin setup, as well as client-side Apple Mail.app baysean filtering. But one thing is consistent between all of em -- the hostnames in the single link within each of the mails resolve to the same IP address.
So, would either SA 3.0 take care of this naturally, or allow me to easily write a plugin to resolve the addresses in links and apply my own IP address based blacklist?
Seems they now default to using the java compiler shipped with Eclipse instead of the com.sun.* compiler which 'javac' uses. So, no tools.jar dependency -- can run on straight sun JRE, not SDK.
This only effects JSP (re)compilation.
This could have been made more clear by the submitter. But that wouldn't do, would it?
Both Novell and Hummingbird (aka NFS Maestro for Windows) are players in the NFSv4 working group, as is Network Appliance. NFSv4 ACLs are pretty much NTFS ACLS, not POSIX. The preamble of the NFSv4 spec announce that one of the reasons it exists is to better incorporate Windows clients and servers.
Stop spreading FUD. NFSv4 is our best hope for non-sucky network file systems, since AFS suffers from sole-vendor-ism, as well as having to bite off too much in one chunk (as in EJB coders having to 'swallow the whole elephant').
I used to be a die-hard AFS user, but now have gone laptop and CVS replaces my need for network filesystems. Disconnected activity done right!
But this whole thread is immaterial relative to the topic at hand. Network protocols != on-the-disk filesystem implementations.
Recent SQL specs include recursive queries. Oracle implements recursive queries, but no with the standard syntax. There's a patch for postgres to implement the oracle syntax, but it won't be considered for inclusion into the core because it is rumored to be unclean (doesn't handle large rows, etc.) as well as because the postgres hackers feel that if there's a way to do it in the standard, then don't commit new implementations that differ from said standard.
Since JVM spawning overhead is astronomic, your box can only run one at a time. So our application runs as a monolithic single process, most likely bigger than your EJB container.
Duh. Likewise, it cannot be sold for high dollars. It is a considerable corporate asset for Sun, goven that their proprietary UNIX server hardware just isn't bringing in the top dollar it used to.
You're right, OC. I didn't intend to slander all of J2EE -- just offering the bitter taste in my mouth from years of CMP 2.0. The core specs for components like JavaMail, Servlets, JNDI, JDBC, etc. seem to better hit that sweet-spot of offering a complete-enough API to do vast wonderful things in that domain, while at the same time not being overtly complicated nor crufty. Well, for sure, theres cruft in there, but little need for casting down to vendor subclasses and/or vendor-specific deployment descriptors.
Perhaps the issue is that the problem CMP is trying to solve, cache-consistent O-R mapping while hiding all SQL from the app developer, is just a holy grail, or, rather, a really hard one to solve in the aforementioned sweet spot.
Gotta look into hibernate or JDO for the next application.
The only thing we're tied to is ORACLE b/c of the BMP SQL code although we wrote it in such a generic way that porting to other DB's is pretty easy and can be done without having multiple code bases. We get good performance to boot!
That's just it though. CMP + EQL offered the hope for database-vendor independence, but fell short IMO. Just like SQL offered the hope for database-vendor independence.
Have you indeed ported to other RDBMS?
Congrats on app-server neutrality, tho. Which do you prefer?
But is is just like SQL. Each EJB container vendor has their own suite of extensions to the specs, 'cause the specs just don't let you do all that you need to do in the real world.
Differences in SQL is one of the reasons for this. EQL is a horribly constricting query language. Sure, it hides the SQL-vendor's flavoring from you, but since it gives you such a limited view of even 'standard' SQL, it has to be avoided for non-trivial queries -- either through EJB-container specifc deployment files, or even down to handcoded SQL in prepared statements at the session bean layer.
Show me a non-trivial enterprise application that sticks straight to the spec. I wish it could be done. Really. But my gut feel is that it is incomplete in parts, and way too wordy in other parts.
Geronimo is an attempt to produce an apache-licensed J2EE middleware stack. Another player in the JBoss realm, apache licensed as opposed to GPL backed by the JBoss commercial company.
Will end up being another postgres vs. mysql 'battle':
One with more features than the other
Different licenses
One propped up by a company
[ We're a JBoss (GPL, not LLC) / Postgres shop ourselves ]
The only reason Java has been around for so long is because Microsoft was slow to really set its target on it in the past.
COBOL is still around in big installations, although Y2K probably reduced that number to some extent, but certainly did not kill it off.
Java, believe it or not, via J2EE / EJB is the COBOL of our time. Business logic gets done today in Java -> EJB -> relational database, instead of COBOL -> VSAM.
Which will be more readable? COBOL today or EJB code 30 years from now? At least COBOL was inherently single-threaded!
Java won't be 'dead' until all of this generation's buisness logic gets reimplemented. But at least the data is (should be) housed in something more language-neutral than VSAM.
Reflection breaks the typesafety of the generics model, which is enforced only at compile time. Therefore, any reflection-driven manipulation of generic collections, such as via Jython, will completely bypass the typesafety of the system, probably yeilding ClassCastExceptions at retreival time (I've not played with the beta yet, so I'm talking out of my ass a little bit here).
It would be nice when / if the EJB CMP relation interfaces switch from vanilla Collection and Set to these typed collections. Would ever so pretty up EJB code!
Maintaining installations of K5-ticket-passing OpenSSH at a university level (i.e. multiple client / server platforms) is just that much harder when having to match the exact openssh codebase to the exact K5 patchsuite. Being able to ultimately say to all university subunits that want to play ball (and esp. students / faculty and their home boxen) "just cook ossh v3.2x with '--withk5'" would be ever so nice.
Slashdot Mirror
I didn't mean URI vs. IP -- I mean the difference between Baysean and latent semantic filtering.
Aha, well, can you define the diffence between the two? Inquiring minds want to know!
And inquiring minds want to know what technology can combat the paragraph of random english words or just pseudo-words that seem to throw-off the 'spam-ness' score using either tech.
I would hope that it would use IPs also. Our site is currently receiving mortgage spam that slips past our current amavisd-new + spamassasin setup, as well as client-side Apple Mail.app baysean filtering. But one thing is consistent between all of em -- the hostnames in the single link within each of the mails resolve to the same IP address.
So, would either SA 3.0 take care of this naturally, or allow me to easily write a plugin to resolve the addresses in links and apply my own IP address based blacklist?
Ugh. Someone should send 'em a cease and desist!
Seems they now default to using the java compiler shipped with Eclipse instead of the com.sun.* compiler which 'javac' uses. So, no tools.jar dependency -- can run on straight sun JRE, not SDK.
This only effects JSP (re)compilation.
This could have been made more clear by the submitter. But that wouldn't do, would it?
Here's a link to the Liberty Dollar, a value-based (backed by gold / silver) currency that you can possibly even spend at some stores.
I first read about 'em in a weekly newspaper article in Maine.
Both Novell and Hummingbird (aka NFS Maestro for Windows) are players in the NFSv4 working group, as is Network Appliance. NFSv4 ACLs are pretty much NTFS ACLS, not POSIX. The preamble of the NFSv4 spec announce that one of the reasons it exists is to better incorporate Windows clients and servers.
Stop spreading FUD. NFSv4 is our best hope for non-sucky network file systems, since AFS suffers from sole-vendor-ism, as well as having to bite off too much in one chunk (as in EJB coders having to 'swallow the whole elephant').
I used to be a die-hard AFS user, but now have gone laptop and CVS replaces my need for network filesystems. Disconnected activity done right!
But this whole thread is immaterial relative to the topic at hand. Network protocols != on-the-disk filesystem implementations.
Recent SQL specs include recursive queries. Oracle implements recursive queries, but no with the standard syntax. There's a patch for postgres to implement the oracle syntax, but it won't be considered for inclusion into the core because it is rumored to be unclean (doesn't handle large rows, etc.) as well as because the postgres hackers feel that if there's a way to do it in the standard, then don't commit new implementations that differ from said standard.
See this thread for more.
Allow me to translate:
Since JVM spawning overhead is astronomic, your box can only run one at a time. So our application runs as a monolithic single process, most likely bigger than your EJB container.
Thank you very much.
From the good book
We will fight wars over oil in the future.
The future is already here, my friend.
Duh. Likewise, it cannot be sold for high dollars. It is a considerable corporate asset for Sun, goven that their proprietary UNIX server hardware just isn't bringing in the top dollar it used to.
It is a highly valuable component if SUNW.
You're right, OC. I didn't intend to slander all of J2EE -- just offering the bitter taste in my mouth from years of CMP 2.0. The core specs for components like JavaMail, Servlets, JNDI, JDBC, etc. seem to better hit that sweet-spot of offering a complete-enough API to do vast wonderful things in that domain, while at the same time not being overtly complicated nor crufty. Well, for sure, theres cruft in there, but little need for casting down to vendor subclasses and/or vendor-specific deployment descriptors.
Perhaps the issue is that the problem CMP is trying to solve, cache-consistent O-R mapping while hiding all SQL from the app developer, is just a holy grail, or, rather, a really hard one to solve in the aforementioned sweet spot.
Gotta look into hibernate or JDO for the next application.
The only thing we're tied to is ORACLE b/c of the BMP SQL code although we wrote it in such a generic way that porting to other DB's is pretty easy and can be done without having multiple code bases. We get good performance to boot!
That's just it though. CMP + EQL offered the hope for database-vendor independence, but fell short IMO. Just like SQL offered the hope for database-vendor independence.
Have you indeed ported to other RDBMS?
Congrats on app-server neutrality, tho. Which do you prefer?
But is is just like SQL. Each EJB container vendor has their own
suite of extensions to the specs, 'cause the specs just don't let you do all that you need to do in the real world.
Differences in SQL is one of the reasons for this. EQL is a horribly constricting query language. Sure, it hides the SQL-vendor's flavoring from you, but since it gives you such a limited view of even 'standard' SQL, it has to be avoided for non-trivial queries -- either through EJB-container specifc deployment files, or even down to handcoded SQL in prepared statements at the session bean layer.
Show me a non-trivial enterprise application that sticks straight to the spec. I wish it could be done. Really. But my gut feel is that it is incomplete in parts, and way too wordy in other parts.
At least there's xdoclet.
Yeah, I knew that -- duly corrected.
;-)
Still won't correct the irreconsilable licensing differences between the groups
For those who don't read the article....
Geronimo is an attempt to produce an apache-licensed J2EE middleware stack. Another player in the JBoss realm, apache licensed as opposed to GPL backed by the JBoss commercial company.
Will end up being another postgres vs. mysql 'battle':
One with more features than the other
Different licenses
One propped up by a company
[ We're a JBoss (GPL, not LLC) / Postgres shop ourselves ]
I wonder if it will ever be able to contain / integrate hibernate, or will that be verboten by JBoss LLC?
Word around the campfire says it requires far fewer contortions than CMP beans.
Congrats to both JBoss and Geronimo. May they both provide middleware containers that don't suck.
COBOL is still around in big installations, although Y2K probably reduced that number to some extent, but certainly did not kill it off.
Java, believe it or not, via J2EE / EJB is the COBOL of our time. Business logic gets done today in Java -> EJB -> relational database, instead of COBOL -> VSAM.
Which will be more readable? COBOL today or EJB code 30 years from now? At least COBOL was inherently single-threaded!
Java won't be 'dead' until all of this generation's buisness logic gets reimplemented. But at least the data is (should be) housed in something more language-neutral than VSAM.
Reflection breaks the typesafety of the generics model, which is enforced only at compile time. Therefore, any reflection-driven manipulation of generic collections, such as via Jython, will completely bypass the typesafety of the system, probably yeilding ClassCastExceptions at retreival time (I've not played with the beta yet, so I'm talking out of my ass a little bit here).
It would be nice when / if the EJB CMP relation interfaces switch from vanilla Collection and Set to these typed collections. Would ever so pretty up EJB code!
I worked for UNCC's CSCI / COIT in a former life. Not MIS, though. Never changed my /. nic.
I'll bet that it will not require a plugin for IE, making web animation display on windows+IE avoid the plugin patent.
Not good at all for Flash.
Anyone else seeing hot redeploys of EARs in JBoss causing abort traps after the update?
Philadelphia seems to use OSX boxes all synched to a VNC server. Saw a pair of 'em get rebooted lateley during a long layover last week.
Maintaining installations of K5-ticket-passing OpenSSH at a university level (i.e. multiple client / server platforms) is just that much harder when having to match the exact openssh codebase to the exact K5 patchsuite. Being able to ultimately say to all university subunits that want to play ball (and esp. students / faculty and their home boxen) "just cook ossh v3.2x with '--withk5'" would be ever so nice.