RE: OC4J 9.0.3
Presumably this is based on 1.5.4? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of sana > Sent: Wednesday, 27 March 2002 2:05 PM > To: Orion-Interest > Subject: OC4J 9.0.3 > > > Hi, > > Oracle released OC4J 9.0.3 Developer Preview. > > http://otn.oracle.com/tech/java/oc4j/content_preview.html > > It supports most of J2EE 1.3 features. > http://otn.oracle.com/tech/java/oc4j/htdocs/oc4j-feature-list.html Regards, sana __ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/
Markus O. van Kempen/CA/MCS/PwC was out of the office.
I will be out of the office starting 03/26/2002 and will not return until 04/08/2002. I will respond to your message when I return.
OC4J 9.0.3
Hi, Oracle released OC4J 9.0.3 Developer Preview. http://otn.oracle.com/tech/java/oc4j/content_preview.html It supports most of J2EE 1.3 features. http://otn.oracle.com/tech/java/oc4j/htdocs/oc4j-feature-list.html Regards, sana __ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/
Content Advisor (IE 5.5,6.0) and default.jsp bug
I have discovered a strange bug with orion after enabling "Content Advisor"
in both IE 5.5 and 6.0. The problem is that the default.jsp is being
executed after every request, causing a "duplicate" erroneous request.
I have created a simple test to duplicate the problem. I tested 1.5.2 and
1.5.4 which both have the problem. I also tested oc4j 1.0.2.2.1 which works
fine. Below are the steps to reproduce the problem.
1. Create a default.jsp which contains the following lines:
<%
response.setHeader("Cache-Control","no-store"); //HTTP 1.1
response.setHeader("Pragma","no-cache"); //HTTP 1.0
response.setDateHeader ("Expires", 1); //prevents caching at the proxy
server
%>
<%!
static int x = 0;
%>
<% System.out.println("EXECUTING DEFAULT.JSP: x=" + x);%>
<%="This is default.jsp: x=" + x++%>
2. Create a test.jsp which contains the following lines (The first few lines
are to prevent caching):
<%
response.setHeader("Cache-Control","no-store"); //HTTP 1.1
response.setHeader("Pragma","no-cache"); //HTTP 1.0
response.setDateHeader ("Expires", 1); //prevents caching at the proxy
server
%>
<%!
static int y = 0;
%>
<% System.out.println("EXECUTING TEST.JSP: y=" + y);%>
<%="This is test.jsp: y=" + y++%>
3. Place both files in the default-web-app folder (be sure to rename the
index.html to index1.html so the default.jsp is used).
4. Start orion and issue a request for http://localhost/test.jsp. Below is
the output I receive:
C:\Prog\java\orion1_5_2>java -jar orion.jar
Orion/1.5.2 initialized
EXECUTING TEST.JSP: y=0
EXECUTING DEFAULT.JSP: x=0 <-- Duplicate request
5. Now issue a request for http://localhost/. Below is the output I
receive:
C:\Prog\java\orion1_5_2>java -jar orion.jar
Orion/1.5.2 initialized
EXECUTING TEST.JSP: y=0
EXECUTING DEFAULT.JSP: x=0
EXECUTING DEFAULT.JSP: x=1
EXECUTING DEFAULT.JSP: x=2 <-- duplicate request
This is causing some problems for my site and I have been unable to find a
solution to the problem. The problem also occurs when using the
welcome-file-list in web.xml also. Any help would be appreciated.
Thanks,
Robert Johnson
Re: Orion EJB 2.0 final
At 12:17 PM 3/25/2002, you wrote: >Hi, >does anyone know when Orion will be 100% EJB 2.0 compatible including >local/remote inerfaces EJB-QL ... > >Michael I would just be happy with the JMS working correctly, have the JMS message types don't work at all! This includes most of the really neat stuff in the MDB spec, which is missing!
RE: Orion EJB 2.0 final
sans ejb-ql, 1.5.4 is compatible. I understand from some Oracle types that ejb-ql will be out later this summer. many-many is broken in 1.5.4, but Magnus et al indicate its fixed in bugzilla for 1.5.5 regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Maurer Sent: Monday, March 25, 2002 9:18 AM To: Orion-Interest Subject: Orion EJB 2.0 final Hi, does anyone know when Orion will be 100% EJB 2.0 compatible including local/remote inerfaces EJB-QL ... Michael
Test
repost: FYI/PATCH: Log4j bug masks part of Orion's stack traces
Seems the original went missing, again.
> -Original Message-
> From: Geoff Soutter [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 26 March 2002 3:46 PM
> To: 'Orion Interest List'
> Cc: [EMAIL PROTECTED]
> Subject: FYI/PATCH: Log4j bug masks part of Orion's stack traces
>
>
> Hi there,
>
> I've been having a weird problem with parts of my stack
> traces disappearing.
>
> After a few hours mucking around I've tracked it down to a
> bug in log4j that I thought you may all wish to be aware of.
>
> This shows up when you attempt to log an OrionRemoteException
> in an application client which has been thrown from a session bean.
>
> If I call System.out.printStackTrace() I get:
>
> at com.evermind.server.ejb.EJBUtils.getUserException(.:207)
> at
> _StatelessSessionBeanWrapper3. hod>( ssionBean>_StatelessSessionBeanWrapper3.java:153)
> at java.lang.reflect.Method.invoke(Native Method)
> at com.evermind._dq._fs(.:79)
> at com.evermind._bt.run(.:62)
> at connection to localhost/127.0.0.1 as admin
> at
> com.evermind._dn.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(.:1447)
> at com.evermind._dn.invokeMethod(.:1370)
> at com.evermind._yp.invoke(.:53)
> at __Proxy2.(Unknown Source)
>
> But if I log the same exception through log4j I get only:
>
> at
> com.evermind._dn.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(.:1447)
> at com.evermind._dn.invokeMethod(.:1370)
> at com.evermind._yp.invoke(.:53)
> at __Proxy2.(Unknown Source)
>
> Turns out the reason for this is that there is a bug in the
> way log4j deals with stack traces. In log4j, stace track
> formatting is handled by a class called ThrowableInformation.
> It contains a subclass of PrintWriter called VectorWriter
> which only overrides the println() - all the other methods
> are effectively disabled. This class is passed into
> Throwable.printStackTrace(). Unfortunately, Orion's implementation of
> OrionRemoteException.printStackTrace() is calling print() rather than
> println() to pass part of the remote part of the stack trace
> across. Thus, this part of the stack trace is simply thrown
> away. Ouch.
>
> This is a bug which impacts Orion and potentially any other
> user of log4j which, in general, wishes to override the way that
> printStackTrace() works. It has been reported before on the
> log4j developers list
> (http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg0
> 0926.html)
> , but it appears Ceki is too busy to fix it :-).
>
> Note, I'm using log4j 1.x at the moment but I had a quick
> check of the CVS repository and it appears the bug is in
> latest stuff as well.
>
> I created a simplistic new version of
> ThrowableInformation.getThrowableStrRep(), which sucks the
> entire stack trace into a buffer and then parses it into
> individual lines. It's probably kinda slow compared to the
> old version, but at least it fixes the bug. I've included it
> if you are interested.
>
> public
> String[] getThrowableStrRep() {
> if(rep != null) {
> return (String[]) rep.clone();
> } else {
> // NOTE: This is not particularly fast. This probably
> needs to be
> // re-architected to use JDK1.4's new parsed stack
> trace stuff anyway,
> // so I consider this to be only a temporary solution.
>
> // First, obtain the _entire_ stack trace as a string
> CharArrayWriter caw = new CharArrayWriter();
> PrintWriter pw = new PrintWriter(caw);
> throwable.printStackTrace(pw);
> pw.flush();
> String trace = caw.toString();
> // Parse it into individual lines.
> // This should handle both Win32 and Unix EOL markers
> (hopefully).
> StringTokenizer tok = new StringTokenizer(trace, "\r\n");
> Vector v = new Vector();
> while (tok.hasMoreTokens()) {
> v.add(tok.nextToken());
> }
> // Convert the result into an array, without using an
> 1.2 functionality
> int len = v.size();
> rep = new String[len];
> for(int i = 0; i < len; i++) {
> rep[i] = (String) v.elementAt(i);
> }
> return rep;
> }
> }
>
> Cheers
>
> Geoff
>
>
> --
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail:
>
>
Re: Orion EJB 2.0 final
At this point, Orion does support local/remote interfaces, CMP/CMR, etc (The experimental Orion 1.5.4), with some bugs they are still working out (many-to-many CMR for instance). EJB-QL isn't in there yet - don't know when it will be. You may try contacting Ironflare directly for more concise information. I do know that j2ee1.3 compliance is a top priority and that they are working feverishly on it. Cheers Ray --- Michael Maurer <[EMAIL PROTECTED]> wrote: > > Hi, > does anyone know when Orion will be 100% EJB 2.0 compatible including > local/remote inerfaces EJB-QL ... > > Michael > > > __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/
