EW,
The message to which you replied has a slightly different title and is from
my alternate email address ([EMAIL PROTECTED], not [EMAIL PROTECTED]). It
went through just fine.
After my criticism, subsequent messages from others on the original thread
(RE: Oracle deal) also went through
From: Jay Armstrong [EMAIL PROTECTED]
EW,
[snip]
After my criticism, subsequent messages from others on the original thread
(RE: Oracle deal) also went through fine, but none of them were critical
of Ironflare. In fact, all of them either told me to shut up (Greg
Stickley and Hani Suleiman,
Hi.
you need a switch which has multicast
enabled; (most ethernet switchs have this capability, some just don't
have it enabled)
That is not true.
Multicast is a network service. It
is of type send-on-receive-anyone. That means, that one packet is send and it is
received by anyone,
Have you tried using sun's jdk 1.3?
That's the jdk that has been tested.
Jay,
Might I say in advance that I've read your posts in the past and they are
good, however this one is severly off the mark and badly wrong in judgement.
After my criticism, subsequent messages from others on the original thread
(RE: Oracle deal) also went through fine, but none of them
Now you need to come up with an even more convoluted conspiracy theory as
to why THIS email you sent was 'allowed to make it through'.
On Sun, 10 Jun 2001, Jay Armstrong wrote:
EW,
The message to which you replied has a slightly different title and is from
my alternate email address
Okay, EW. I'll agree that some things are apparently not getting through.
They can write a great J2EE product, but can't get their list server to
work. My dog at my homework.
Now that I've tried for the third time to post my response to Karl, and
asked for Mike Cannon-Brookes to post it, we'll
Depending on the country, enforcing a license can be a problem. In the US,
all the licensor need do is contact the isp which is hosting the site, and
notify them of a copywrite violation. The law is pretty clear about that
one. The isp has to take them down.
In other countries, they may have no
From: Jay Armstrong [mailto:[EMAIL PROTECTED]]
[...paranoia...]
Have you ever considered that maybe your communications are being
intercepted and preprocessed by a CIA computer? Do you hear clicking
noises every time you pick up the phone?
You have accidentally sumbled across The Swedish
...CLIP...
If it's a list problem, okay, but how can we possibly know? Time will
tell,...
...CLIP...
Since you are even able to say Time will tell why don't you just wait and
see if Ironflare's personality changes over time instead of assuming the
worst.
jason,
thankyou for yor responses.
in the interests of keeping it simple, i've decided to try to lobby
the rest of the team to go back to using db generated keys (i.e. identity
columns in the case of ms sql server ) and throw out key our
key generation code.
we'll then have a single .ear that
Greg,
I didn't really understand your problem. If you are using counter.jar to
generate your keys, then the key is actually generated based upon the last
key in the database, not the appserver, so clustering shouldn't be a
problem. If there is an issue with transaction concurrency, you can
Even paranoid people have enemies.
I've never suggested a conspiracy. The response I got from Karl was an
immediate reaction to my comment that their testing was done for free. Now
testing/bug reporting by the open community will directly help Oracle.
Try dealing with facts. Six months ago,
If I understand Greg's decision correctly, he made it to prevent a single
point of failure on the Orion server instance serving the key generation
with the counter.jar. That Orion server indeed is a single point of failure
instance as only one server should serve the key generation locally.
Of
We have several orion's running in clustering, each of them serving up keys
from counter.jar, with no conflicts. Let me be clear, each orion instance
uses its own local counter.jar ejb to generate a key, but the underlying
data for the key generation comes from the database. The counter.jar is
Well, you're kinda asking for it, but your credentials clearly show why
you're so paranoid and are on very, umm, thin ground when it comes to
mental well being.
We've all tried presenting the facts to you regarding the Oracle deal, but
all we seem to be getting in respose is a descent into your
Mahesh,
there were issues with auto-deployment and earlier versions. I would upgrade
to 1.5.2 the latest stable version, 1.4.0 is a little behind the times now.
Check the permissions on your deploy directory and the application
directory, does orion have write access? (write permissions are not
--- Harley Rana [EMAIL PROTECTED] wrote:
Have you tried using sun's jdk 1.3?
That's the jdk that has been tested.
Yes, I downloaded Sun's jdk and it now works. I just
wanted to stick with IBM's since that works with the
same combination on a Mandrake Linux (the error occurs
on a Windows
i think elephantwalker's solution is probably better from a
database independence point of view and understand
now that counter works off the db.
i think using identity's is probably ok also, but we'll have
to do some OO stuff server side to abstract away the
get the last identity used (MS SQL
No, I just unZIPPED the archive to it's folder.
Javier Soques
--- Tim Endres [EMAIL PROTECTED] wrote:
Between release 1.4.7 and 1.4.8, Orion switched over
to Xalan 2.
It appears from the stack trace that you have
somehow confused the
JAR files related to Xalan. Did you by chance copy
your
20 matches
Mail list logo
