java sniffer
hellow linux and java fan can I get another good java sniffer package rather then the www.besiex.org/ByProxy/Developers/Sniffers/programming_guide.html
Re: suggestion for list (was: Re: STOP asking about Java 1.2 / 2)
On Sat, 9 Jan 1999, Chris Abbey wrote: > The recent on-list exchange between John Summerfield and Kontorotsui has > brought a background thought of mine to the foreground, so I'd like to share > it with the list and see what the general opinion is. > > I suggest that the current copy of the FAQ be included with the succesful > subscription message. I know this is possible with majordomo because other > lists do it. I believe this will reduce the volume of these questions because > it appears that most of the people posting this question have just joined > the list. (probably in order to ask that question.) Along with the suggestion that, to be kept informed, they add an entry like this to their crontab: 15 00 * * 5 lynx -dump http://www.blackdown.org/java-linux/ports.html | mail summer or 15 00 * * 5 echo get java news | mail summer -s "get java news" with appropriate changes. The second entry should be directed to users' external email address in order to get the page when online. Use a procmail filter to recognise the email and get the page, much like I use this to get a web page when I get email that it's changed :0c: * ^To:.*[EMAIL PROTECTED] | $HOME/bin/jobsatexecom The script is no more than: lynx -dump http://www.peoplexp.com.au/new_positions.html\ | mail -s "jobs at peoplexp" summer@`hostname` > > I also suggest that all messages from the list have a standard footer > appended; something like what Redhat does on their lists. I'd suggest: > > > > (Java && Linux) - [EMAIL PROTECTED] - !(Java || Linux) > To unsubscribe: issue the following command from a shell prompt > mail -s unsubscribe [EMAIL PROTECTED] < /dev/null Another idea with which I agree. -- Cheers John Summerfield http://os2.ami.com.au/os2/ for OS/2 support. Configuration, networking, combined IBM ftpsites index.
Re: Java-VisiBroker CORBA on Linux with Blackdown Java 1.16/1.17 Howto
Armen Yampolsky wrote: > > Marcel, > > Thanks for your great summary! BTW, I just wanted to let you know, we've switched to >omniORB2/Sun IDL (JDK1.2) instead of Visibroker. I felt that visi was just way too > expensive, and being a believer in the benefits of Open Source software (and reading >all the great posts re omniORB), I decided to give it a try. The Sun java libs are > just enough for the client, definitely not good enough for a server, IMO, but we're >running a C++ appserver and so this fits beautifully. The two work together quite > well, and I only have good things to say about omniORB, so if you have similar >requirements, you may want to look into it. I guess this is sounding a bit like a >pitch ;) > > Naturally, all work splendidly on linux (with the exception of the absence of >idltojava compiler, which the Blackdown team should have up Real Soon Now, right?). > > Cheers, > -A. a. My thanks to Marcel as well - that was very helpful & timely Marcel, as I'm just now porting a Visibroker based CORBA training class from NT to Linux. Thanks! b. Armen, as I understand things, - omniORB2 is a C++ ORB (no Java lang. mappings at present). Presumably this is your "C++ appserver" correct? (And presumably you have this running on Linux?) - JavaIDL, as you note, requires JDK1.2, which as of now (this week/day, anyway :) still isn't avail. on Linux, so this is probably running for you on NT/Solaris/other, right? Hence, you have an environment using muliple lang (C++/Java), multiple platform (Linux server/ non-Linux client), multiple ORB (omniORB/JavaIDL). That's actually pretty impressive - if you have more operational stats (eg types of applications you are using this for, scaling you're getting, etc.) I'd be quite interested. However, just to be clear, the config. above at no point has the combination of "+Java +CORBA +Linux", right? I.e, the Java ORB is not on Linux, only the C++ ORB. I ask only because for those of us looking for an open source Java ORB on Linux, your config. above still doesn't quite fit. Or have I misunderstood you? Thanks, Ron -- Ron Resnick Senior Consulting Engineer DiaLogos Incorporated http://www.dialogosweb.com
Re: Java2
Jim Waldo - SMI Software Development wrote: > > Hi folks -- > > Any words on when the Java 2 (aka 1.2) port is available? I would love to get > a port of Jini out on Linux early (and often), but we are completely 1.2 > based. > > Any words you could give would be a help. > > Thanks, > > Jim Waldo Hi Jim, Your question (when is Blackdown JDK1.2 coming out) gets asked about 3 times a day on the Blackdown list :). For most folks who ask this, the standard answer is some combination of: (i) read the faq (ii) wait and bear it in silence (iii) #$@!!#$ In your case though, perhaps we could synergistically act to expedite things? I think it's great that senior folks within Sun, such as yourself, are interested in moving Java/Linux along. Recently, a member of the Blackdown team (Steve Byrne) informed us all that: > We're not legally allowed to put out pre-release versions if they haven't > passed through JCK. We're in the process of trying to chase down some issues > with running the JCK. > > > The page also says, "Before we can release, we have to make sure that it > > passes the tests in the Java Compatibility Kit." Is this a requirement > > of Sun's source code licensing, or is it just something that was decided > > on by the Blackdown team? > > It's the dreaded sections 2.4 and 2.5 as amending 2.3 of our license that say > we HAVE to pass JCK before we can release or even pre-release. > > Steve Certainly there are good reasons for ensuring that Java ports are "sanitized" by passing JCK. However, maybe there's a way that Sun can expedite this process for the Blackdown folks, or at least allow a controlled prerelease that lightens the impact of these "dreaded sections"? Do you think you could lend a hand here Jim? Or is this (probably) in the hands of some "dreaded lawyers" 8-). On another note, what do you mean by: "get a port of Jini out on Linux early (and often)"? I thought Jini was pure Java, i.e., as soon as there is a compliant JDK2 running on platform of choice, Jini is just a drop in, like JFC, JSDK, or any other pure Java package. Or is there native code in Jini that needs to be ported platform by platform? Thanks, Ron --- Ron Resnick Senior Consulting Engineer DiaLogos Incorporated http://www.dialogosweb.com
Re: [dist-obj-tech] Java-VisiBroker CORBA on Linux with BlackdownJava 1.16/1.17 Howto
On Sun, 10 Jan 1999, Ron Resnick wrote: > - JavaIDL, as you note, requires JDK1.2, which as of now (this > week/day, anyway :) still isn't avail. on Linux, so this is > probably running for you on NT/Solaris/other, right? I have successfully extracted the JavaIDL ORB from JDK1.2b3 and use it under JDK1.1.7. As I had to patch the ORB to fix some bugs, a work I wouldn't want to repeat, I haven't tried with the latest releases. Actually, with some layer code, we successfully use JavaIDL for an, admittedly relatively small server. Successfully deployed on Solaris, Linux and Windows NT ! The additional functionality of Visibroker, for example, does IMHO not pay off the much higher price. The POA (portable object adapter) could be a reason to switch to another ORB. Ad performance, using a JDBC connected DB as backend, you don't *really* need to care about the ORB. > However, just to be clear, the config. above at no point > has the combination of "+Java +CORBA +Linux", right? I didn't follow it ... has Sun released JavaIDL as open source ? If yes, this combination is indeed possible today. Cheers -- Matthias
[ATTENTION]: Mailing List Changes
I'd like to do one of two things with this mailing list, as it's really become a significant amount of traffic. Either move it to a newsgroup, or move it to a place willing to host the java-linux and java-linux-digest lists. The world unfortunately isn't a place of free bandwidth forever and I have to make some decisions. Now my main request is for someone to hold my hand through getting a newsgroup proposed and possibly approved. Alternatively, I would really appreciate a -stable- (and by stable I mean someplace that isn't going to die within a week) to host the mailing lists. If you can help with either of these, please let me know. As a side note, this isn't the start of a massive move of the site or anything else. The only issue is the mailing list, which is just a constant bandwidth and i/o load on the machine. Thanks, Karl Asha [EMAIL PROTECTED]
Re: Java-VisiBroker CORBA on Linux with Blackdown Java 1.16/1.17 Howto
Marcel - > Armen Yampolsky wrote: > >> Marcel, >> >> Thanks for your great summary! BTW, I just wanted to let you know, >> we've switched to omniORB2/Sun IDL (JDK1.2) instead of Visibroker. > > We had at that time a lot of problems with omniORB, threads, > exceptions, the gcc/egcs couldn't handle > it very well. Are these problems gone? So far we did a few highly simplified tests of mutex and exceptions, with g++ on Linux and Sun's CC on Solaris, all worked as expected. They have a threading model, it is probably newer than when you last used it, but I have not had the opportunity to look into it deeply. > Where are you running JDK 1.2 and SUN IDL, on Linux ? Does this work? Oh yes, just fine! I add rt.jar to the *end* of my classpath, so that only the CORBA files are used from it, and swing and everything else come from the jdk1.1.7 version. I use IBM's jikes to compile, and Blackdown's JDK1.1.7 java. > Did you have to port your Java code much to run with Sun IDL? Not too much. Some things are different, like ORB instantiation arguments, the singleton argument-less ORB.init() does not return the full-fledged ORB (don't use it to get the ORB), and there were also a few things Visigenic does that do not comply to the standard, so that I had to change. Not too much of an issue. The biggest issue was omniORB's (well-done) connection management scheme, which Sun just does not deal well with. One must turn the connection idle timeout *off* on the omniORB side, until Sun fixes this bug. The trick is too turn it off for the Naming Service daemon too, and that involved getting into the source code. They have accepted my suggestion and will add a command line arg to the Naming Service so that one can shut the idle timeout off easily. Check out http://www.orl.co.uk/omniORB/javaORBs.html For an interesting breakdown. It is a little dated, Sun has fixed several of the items mentioned. Cheers, -Armen -- Armen Yampolsky Axiom Software Labs New York
Re: Java-VisiBroker CORBA on Linux with Blackdown Java 1.16/1.17 Howto
Ron, > b. Armen, as I understand things, > > - omniORB2 is a C++ ORB (no Java lang. mappings at present). > Presumably this is your "C++ appserver" correct? (And presumably > you have this running on Linux?) Yes, that's right. > - JavaIDL, as you note, requires JDK1.2, which as of now (this > week/day, anyway :) still isn't avail. on Linux, so this is > probably running for you on NT/Solaris/other, right? No. It's easy to use the libraries of JDK1.2 on Linux. One must make sure to add rt.jar to the *end* of the classpath, so that only the org.omg libraries are used from there, and swing etc. are not. Of course, none of the binaries work, but I use jikes and the JDK1.1.7 vm, so I only need the idltojava compiler (which is not all that good, BTW) from 1.2. This I run on a Solaris box. I point my java compiler to proxies there. It's nice to keep generated files in a separate directory anyway. So, I run everything on Linux, with the exception of that compiler. > at no point > has the combination of "+Java +CORBA +Linux", right? > I.e, the Java ORB is not on Linux, only the C++ ORB. > I ask only because for those of us looking for an > open source Java ORB on Linux, your config. above still doesn't > quite fit. Or have I misunderstood you? You've misunderstood. I replied to another email from Marcel and forgot to cc the list, so I'm forwarding it now. It has some of my observations regarding our experiences with JDK1.2 and omniORB. Cheers, -Armen -- Armen Yampolsky Axiom Software Labs New York
volunteer
Is it possible to participate in the JDK linux port project as an volunteer? Thanks. Sam
native synchronized methods
This is not really java-linux specific, but this is the only java related group
that I am subscribed to. I am wondering if a native method is specified as
synchronized if the jvm will perform the proper MontiorEnter & MonitorExit
calls or if I should call them in the native method.
So for example... does:
native public synchronized byte[] getBytes ();
imply:
JNIEXPORT jbyteArray JNICALL Java___getBytes
(JNIEnv *env, jobject jthis)
{
(*env)->MonitorEnter(env, jthis);
/* do something */
(*env)->MonitorExit(env, jthis);
return /* some jbyteArray */;
}
--jason
Re: native synchronized methods
> Jason Dillon writes:
Jason> This is not really java-linux specific, but this is the
Jason> only java related group that I am subscribed to. I am
Jason> wondering if a native method is specified as synchronized
Jason> if the jvm will perform the proper MontiorEnter &
Jason> MonitorExit calls or if I should call them in the native
Jason> method.
Jason> So for example... does:
Jason> native public synchronized byte[] getBytes ();
Jason> imply:
Jason> JNIEXPORT jbyteArray JNICALL Java___getBytes
Jason> (JNIEnv *env, jobject jthis)
Jason> {
Jason> (*env)->MonitorEnter(env, jthis);
Jason> /* do something */
Jason> (*env)->MonitorExit(env, jthis);
Jason> return /* some jbyteArray */;
Jason> }
Not exactly, the method indeed is synchronized but the synchronization
is part of the method invocation and return. Section 7.14 of the
virtual machine specification has more details about that:
http://java.sun.com/docs/books/vmspec/html/Compiling.doc.html#6530
Juergen
--
Juergen Kreileder, Universitaet Dortmund, Lehrstuhl Informatik V
Baroper Strasse 301, D-44221 Dortmund, Germany
Phone: ++49 231/755-5806, Fax: ++49 231/755-5802
Num-Lock, Swing, JDK 117v1a problems
I was just wondering if anyone else has had trouble using the number pad with num-lock on? I searched the jitterbug database, and there was one bug reported a while back in 116 which was supposedly fixed. My setup is blackdown jdk117v1a, RedHat 5.2 i386, KDE window manager, (I tried several others also), Swing 1.1. Kelly -- Kelly A. Campbell Applications Programmer/Analyst <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Kansas State University http://www.telecom.ksu.edu/~camk/ Department of Telecommunications 109 East Stadium, Manhattan KS 66506http://www.telecom.ksu.edu/ Voice: (785) 532-7067 Fax: (785) 532-7114
Re: native synchronized methods
Does this apply to native methods as well? The docs do not really mention
anything about native methods (not in that section anyways). I am wondering if
it is safe to assume that marking a native method as synchronized will
automagicly protect the object from access by other threads or if I have to
explicitly protect the method in the native code.
--jason
On 11-Jan-99 Juergen Kreileder wrote:
>> Jason Dillon writes:
>
> Jason> This is not really java-linux specific, but this is the
> Jason> only java related group that I am subscribed to. I am
> Jason> wondering if a native method is specified as synchronized
> Jason> if the jvm will perform the proper MontiorEnter &
> Jason> MonitorExit calls or if I should call them in the native
> Jason> method.
>
> Jason> So for example... does:
>
> Jason> native public synchronized byte[] getBytes ();
>
> Jason> imply:
>
> Jason> JNIEXPORT jbyteArray JNICALL Java___getBytes
> Jason> (JNIEnv *env, jobject jthis)
> Jason> {
> Jason> (*env)->MonitorEnter(env, jthis);
> Jason> /* do something */
> Jason> (*env)->MonitorExit(env, jthis);
>
> Jason> return /* some jbyteArray */;
> Jason> }
>
> Not exactly, the method indeed is synchronized but the synchronization
> is part of the method invocation and return. Section 7.14 of the
> virtual machine specification has more details about that:
> http://java.sun.com/docs/books/vmspec/html/Compiling.doc.html#6530
>
>
> Juergen
>
> --
> Juergen Kreileder, Universitaet Dortmund, Lehrstuhl Informatik V
> Baroper Strasse 301, D-44221 Dortmund, Germany
> Phone: ++49 231/755-5806, Fax: ++49 231/755-5802
Re: native synchronized methods
> Jason Dillon writes:
Jason> Does this apply to native methods as well? The docs do not
Jason> really mention anything about native methods (not in that
Jason> section anyways). I am wondering if it is safe to assume
Jason> that marking a native method as synchronized will
Jason> automagicly protect the object from access by other threads
Jason> or if I have to explicitly protect the method in the native
Jason> code.
Yes, this applies to native methods as well and at least the JDK
implements it correctly.
Here's a little test program:
C.java:
class C
{
static {
System.loadLibrary("synctest");
}
native synchronized void ok();
native void bad();
public static void main(String[] args)
{
C c = new C();
c.ok();
System.out.println("--");
c.bad();
}
}
synctest.c:
#include
#include "C.h"
JNIEXPORT void JNICALL
Java_C_ok(JNIEnv* env, jobject this)
{
jclass cls = (*env)->FindClass(env, "C");
jmethodID mid = (*env)->GetMethodID(env, cls, "notify", "()V");
(*env)->CallObjectMethod(env, this, mid);
if ((*env)->ExceptionOccurred(env)) {
(*env)->ExceptionDescribe(env);
}
}
JNIEXPORT void JNICALL
Java_C_bad (JNIEnv* env, jobject this)
{
jclass cls = (*env)->FindClass(env, "C");
jmethodID mid = (*env)->GetMethodID(env, cls, "notify", "()V");
(*env)->CallObjectMethod(env, this, mid);
if ((*env)->ExceptionOccurred(env)) {
(*env)->ExceptionDescribe(env);
}
}
The call to c.ok() should be ok but c.bad() should fail, i.e. the correct
output is:
$ LD_LIBRARY_PATH=. java C
--
java.lang.IllegalMonitorStateException: current thread not owner
at C.main(C.java:16)
Juergen
Jason> On 11-Jan-99 Juergen Kreileder wrote:
>>> Jason Dillon writes:
>>
Jason> This is not really java-linux specific, but this is the
Jason> only java related group that I am subscribed to. I am
Jason> wondering if a native method is specified as synchronized
Jason> if the jvm will perform the proper MontiorEnter &
Jason> MonitorExit calls or if I should call them in the native
Jason> method.
>>
Jason> So for example... does:
>>
Jason> native public synchronized byte[] getBytes ();
>>
Jason> imply:
>>
Jason> JNIEXPORT jbyteArray JNICALL Java___getBytes
Jason> (JNIEnv *env, jobject jthis)
Jason> {
Jason> (*env)->MonitorEnter(env, jthis);
Jason> /* do something */
Jason> (*env)->MonitorExit(env, jthis);
>>
Jason> return /* some jbyteArray */;
Jason> }
>>
>> Not exactly, the method indeed is synchronized but the synchronization
>> is part of the method invocation and return. Section 7.14 of the
>> virtual machine specification has more details about that:
>> http://java.sun.com/docs/books/vmspec/html/Compiling.doc.html#6530
>>
>>
>> Juergen
>>
>> --
>> Juergen Kreileder, Universitaet Dortmund, Lehrstuhl Informatik V
>> Baroper Strasse 301, D-44221 Dortmund, Germany
>> Phone: ++49 231/755-5806, Fax: ++49 231/755-5802
Re: native synchronized methods
Cool... thank you for your help.
--jason
On 11-Jan-99 Juergen Kreileder wrote:
>> Jason Dillon writes:
>
> Jason> Does this apply to native methods as well? The docs do not
> Jason> really mention anything about native methods (not in that
> Jason> section anyways). I am wondering if it is safe to assume
> Jason> that marking a native method as synchronized will
> Jason> automagicly protect the object from access by other threads
> Jason> or if I have to explicitly protect the method in the native
> Jason> code.
>
> Yes, this applies to native methods as well and at least the JDK
> implements it correctly.
>
> Here's a little test program:
>
> C.java:
> class C
> {
> static {
> System.loadLibrary("synctest");
> }
>
> native synchronized void ok();
> native void bad();
>
> public static void main(String[] args)
> {
> C c = new C();
> c.ok();
> System.out.println("--");
> c.bad();
> }
> }
>
> synctest.c:
>#include
>#include "C.h"
>
> JNIEXPORT void JNICALL
> Java_C_ok(JNIEnv* env, jobject this)
> {
> jclass cls = (*env)->FindClass(env, "C");
> jmethodID mid = (*env)->GetMethodID(env, cls, "notify", "()V");
> (*env)->CallObjectMethod(env, this, mid);
> if ((*env)->ExceptionOccurred(env)) {
> (*env)->ExceptionDescribe(env);
> }
> }
>
> JNIEXPORT void JNICALL
> Java_C_bad (JNIEnv* env, jobject this)
> {
> jclass cls = (*env)->FindClass(env, "C");
> jmethodID mid = (*env)->GetMethodID(env, cls, "notify", "()V");
> (*env)->CallObjectMethod(env, this, mid);
> if ((*env)->ExceptionOccurred(env)) {
> (*env)->ExceptionDescribe(env);
> }
> }
>
> The call to c.ok() should be ok but c.bad() should fail, i.e. the correct
> output is:
> $ LD_LIBRARY_PATH=. java C
> --
> java.lang.IllegalMonitorStateException: current thread not owner
> at C.main(C.java:16)
>
>
> Juergen
>
> Jason> On 11-Jan-99 Juergen Kreileder wrote:
> >>> Jason Dillon writes:
> >>
> Jason> This is not really java-linux specific, but this is the
> Jason> only java related group that I am subscribed to. I am
> Jason> wondering if a native method is specified as synchronized
> Jason> if the jvm will perform the proper MontiorEnter &
> Jason> MonitorExit calls or if I should call them in the native
> Jason> method.
> >>
> Jason> So for example... does:
> >>
> Jason> native public synchronized byte[] getBytes ();
> >>
> Jason> imply:
> >>
> Jason> JNIEXPORT jbyteArray JNICALL Java___getBytes
> Jason> (JNIEnv *env, jobject jthis)
> Jason> {
> Jason> (*env)->MonitorEnter(env, jthis);
> Jason> /* do something */
> Jason> (*env)->MonitorExit(env, jthis);
> >>
> Jason> return /* some jbyteArray */;
> Jason> }
> >>
> >> Not exactly, the method indeed is synchronized but the synchronization
> >> is part of the method invocation and return. Section 7.14 of the
> >> virtual machine specification has more details about that:
> >> http://java.sun.com/docs/books/vmspec/html/Compiling.doc.html#6530
> >>
> >>
> >> Juergen
> >>
> >> --
> >> Juergen Kreileder, Universitaet Dortmund, Lehrstuhl Informatik V
> >> Baroper Strasse 301, D-44221 Dortmund, Germany
> >> Phone: ++49 231/755-5806, Fax: ++49 231/755-5802
Re: Num-Lock, Swing, JDK 117v1a problems
I have a followup to my earlier mail. The NumLock key does work with jdk116v5, however, the Enter key doesn't work as expected. It would be nice to have these bugs fixed in 117. The application I am testing was primarily developed on Solaris, so these problems are most likely only in the linux port. On Sun, Jan 10, 1999 at 10:03:16PM -0600, Kelly Campbell wrote: > I was just wondering if anyone else has had trouble using the number pad > with num-lock on? I searched the jitterbug database, and there was one bug > reported a while back in 116 which was supposedly fixed. > > My setup is blackdown jdk117v1a, RedHat 5.2 i386, KDE window manager, (I > tried several others also), Swing 1.1. > > Kelly -- Kelly A. Campbell Applications Programmer/Analyst <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Kansas State University http://www.telecom.ksu.edu/~camk/ Department of Telecommunications 109 East Stadium, Manhattan KS 66506http://www.telecom.ksu.edu/ Voice: (785) 532-7067 Fax: (785) 532-7114
