Robert Simmons wrote:

In my opinion this is the largest fault with cocoon at present. It is rather
strange since the Tomcat servlet engine does not suffer from this limitation.
Since they have already got this working, why cant we borrow their code to
accomplish it?

Robert,

You can answer this one easily by yourself: Suppose we've borrowed the Tomcat's code... Then we have to "borrow" WebLogic's code (read EULA first)... WebSphere's code... Resin's code... Shall we continue?


We will never get enterprise programmers to transfer over from using JSP to
using XSP without such a facility. Having to put all the jars in a classpath is
just NOT a viable solution. Not even a viable workaround.

It's perfectly common (and described in some J2EE docs, and implemented in J2EE reference implementation) for EJB client application to package it with EJB client jar. So, me thinks, it's a (endorsed by Sun) way... Not the best one, but sure it's a way.


In fact, I think the goal of cocoon should now be to reel in those enterprise
programmers and bring them into the fold. The days of doing things with direct
SQL and database calls are fast waning into the abyss of impossible large scale
project management. There must be other options. XSP as a competitor to JSP and
ASP technologies is simply not viable without integration with EJBs.

BTW... If you are trying to put all the EJB code into XSP I think you missed the concept of Actions which are the place to do such things. Like in so-called "JSP model 2" it's not advisable to put all your logic into JSPs, you can do same in Cocoon - put the logic into the Actions (pure java code, that's where the code belongs), and leave XSPs to (as much as possible) pure content.


Integration
with EJBs means getting our compiler to work with a class loader instead of a
classpath.

Exactly, classloading javac is the missing piece.


I think the milestone for this and related bugs should be firmly 2.1. Once
Cocoon has this, I'm convinced they could hit the big time.

No, this is the minor patch, which does not affect Cocoon internals, just adds (modifies - in case of Pizza) one component - it will happily go to both branches.

Vadim



-- Robert

"Michael Homeijer" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...

Anyone care to comment on the threads I mentioned?

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103769226701593&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103990910724056&w=2

When using xsp pages or actions in an ear (combined with using value objects
returned from ejb's) this is a rather big issue.

Michael

-----Original Message-----
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 13-2-2003 9:08
Subject: DO NOT REPLY [Bug 16580] - Java compiler requires JARs in the FS;
can not use classloader

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580

Java compiler requires JARs in the FS; can not use classloader



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to