Re: Devel Digest, Vol 12, Issue 6
by Soumyadip Modak
Martin Kauss <bishoph(a)open-xchange.org> wrote
> Hi,
>
> the configure just checks the system dependencies to build the
> system. The needed libraries are not checked until the compile
> process, JFYI.
>
> The questions was asked some month ago for a Debian package as well.
> I tried to build Open-Xchange some time ago with GNU Classpath, but
> specially for mail, necessary methods and functions are just missing.
So what I understand is this: (Correct me if I'm wrong)
1. Problems with servlets are solvable with free Java tools, and these
are not major showstoppers
2. Base64 and Parserdelegator problems need some work
3. Main problem is that the free Javamail does not implement some
methods that are needed by OX.
Is it possible for the OX developers to work with the Classpath
developers to resolve these problems ? As far as I can understand there
is no major bottleneck other than some missing functionality, and I'm
sure that the Classpath people would love to have people collaborating
with them. :)
> We are just providing a collaboration framework and that is our
> focus. This means, if the functionality is covered by any other
> package than Sun's Javamail package one can build OX with this
> packages.
>
> Currently - AFAIK - this is not possible.
>
> The other question is what you mean with "extensive free Java tools"
> ... for some ppl. also packages offered by Sun/IBM/Bea are "free" ...
I generally refer to the Debian Free Software Guidelines for my
definition of Free software :)
http://www.debian.org/social_contract#guidelines
Thanks a lot
--
Soumyadip Modak
soumyadip.modak(a)gmail.com
soumyadip(a)randomink.org
http://www.randomink.org/soumyadip
17 years, 10 months
Is tomcat-connectors-4.0.6 buildable on FC4
by crisppy fernandes
Hi All
can anybody give me some pointer or info related to my problem..
I am facing many issues related to building tomcat-connectors-4.0.6 on FC4 .
After solving few problems i have reached a point where its searching
for one struct i.e.
JDK1_1InitArgs. and after searching more i have come to know that
definition of this struct is now removed from source i.e jni.h file
So do we have fix for this. or i am missing something.
some or any help welcome.
Crisppy f.
--
Crisppy Fernandes
17 years, 10 months
RE: [fedora-java] rssowl: libgcj bugs that need fixing for it torun
by Boehm, Hans
There is some code in earlier versions of the
GC to do thread registration, but it's very platform specific
and thus ugly. I think there wasn't a real facility for Linux.
The tricky part of doing this in general is that the GC needs
to know the stack bounds for the newly registered thread. It
can find the hot end, but the cold end is often hard. GC7
addresses this by providing two ways to get the cold stack
end:
1) A generic mechanism that just takes the address of a local.
The collector knows how to implement that everywhere. We just
provide a function that calls back one of your functions f with
a stack address that's guaranteed to be "below" f. Since this
is not the actual base of the stack, the GC ends up tracing
pointers only in "new" frames.
2) A separate routine that tries to discover the stack base
in a platform dependent way. It may fail. (And currently
usually does.) I think that for Linux, pthread_getattr_np
works for most threads, though perhaps not the main one.
(The thread pointer also probably works in many cases.)
I'm not sure the JNI primitives can be implemented in terms
of (1). Certainly if you use CNI that has different semantics,
in that the GC doesn't see pointers "below" you on the stack.
We may need (2) to work for gcj.
Hans
> -----Original Message-----
> From: Robin Green [mailto:greenrd@greenrd.org]
> Sent: Thursday, July 28, 2005 1:51 PM
> To: Anthony Green; Boehm, Hans
> Cc: tromey(a)redhat.com; Discussion list for java related
> Fedora development
> Subject: RE: [fedora-java] rssowl: libgcj bugs that need
> fixing for it torun
>
>
> > On Thu, 2005-07-28 at 11:34 -0700, Boehm, Hans wrote:
> > > [I missed the beginning of this thread initially.]
> > >
> > > I'm actually trying to work on some of these issues. Some status:
> >
> > Cool.
> >
> > Robin - is there a local hack/patch we can apply to swt
> and/or rssowl
> > to work around this problem until a real fix from Hans
> migrates into
> > GCC?
>
> I'm a bit out of my depth here.
>
> Hans wrote: "Gc7 (even the released, but very experimental
> alpha3 version) has a thread registration interface." This
> implies that the version in gcc _doesn't_ have a thread
> registration interface, or anything that could be hacked
> together into one. Is that surmise correct?
>
> If so, the only other thing I can think of is to spawn a new
> registered thread instead of calling AttachCurrentThread, and
> somehow translate all C->Java invocations on the unregistered
> thread into inter-thread calls onto the new registered
> thread. In other words, keep all Java code on a separate thread. Yuck.
>
> --
> Robin
>
17 years, 10 months
Standard version of JPEGImageDecoder
by Orion Poplawski
Is there a standard JPEG api that is available with gcj that provides
JPEGImageDecoder and the like that are in com.sun.image.codec.jpeg.*?
Or at least something comparable?
Thanks!
--
Orion Poplawski
System Administrator 303-415-9701 x222
Colorado Research Associates/NWRA FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com
17 years, 10 months
RE: [fedora-java] rssowl: libgcj bugs that need fixing for it torun
by Boehm, Hans
[I missed the beginning of this thread initially.]
I'm actually trying to work on some of these issues. Some status:
1) I'm currently hacking on the /proc/self/maps reading code
that's already in the GC. The
current code actually broke with a kernel change in August 2003
which changed the file format on 64-bit architectures.
Unfortunately it didn't break blatantly
enough for anyone to notice until now. I have a patch that should
probably be integrated into gcj, but it needs a bit more mileage on
it.
2) Reading /proc/self/maps reliably in a multithreaded environment
seems hard. I'm still trying to understand this better, but there
seems to be a design flaw here. Reads can return short, meaning
that you don't necessarily get a consistent picture. And AFAICT,
both nptl and linuxthreads unmap thread stacks after the thread
becomes invisible to the user, so there is no way you can deal
with this by user level synchronization. The mappings can
change even if all threads that haven't exited are stopped.
I currently believe that
/proc/self/maps can only shrink asynchronously, so it might be possible
to address this by reading it twice.
3) I have code in my gc7 tree to intercept pthread_create as suggested
here. My immediate goal is to make it possible to use the gc as a
preloadable malloc replacement, even in the multithreaded case.
(This seems to require /proc/self/maps, since the dynamic loader seems
to have its own malloc, and the objects it allocates point to objects
allocated with the later malloc.) I think this is getting close to
working, but I'm not quite there.
4) Gc7 (even the released, but very experimental alpha3 version)
has a thread registration interface. That's probably a better solution
for some of the problems here. (The implementation behind this
interface is currently severely lacking in places. But at least there's
an interface.)
5) My general plan is to get gc7 slightly more stable, and then set up
CVS
access to it.
Hans
> -----Original Message-----
> From: Anthony Green [mailto:green@redhat.com]
> Sent: Thursday, July 28, 2005 7:47 AM
> To: tromey(a)redhat.com
> Cc: Boehm, Hans; Discussion list for java related Fedora development
> Subject: Re: [fedora-java] rssowl: libgcj bugs that need
> fixing for it torun
>
>
> On Wed, 2005-07-27 at 12:16 -0600, Tom Tromey wrote:
> > This seems like a reasonable approach when libgcj is linked
> into the
> > resulting executable. But how can it work if we dlopen()
> libgcj and
> > then attach a previously-existing thread?
>
> It can't; this only solves the problem reported. We could
> force tricky programmers to do thread registrations
> themselves. The PyLucene people probably solved this in some way.
>
> > I was wondering if there was some /proc-reading approach
> (or something
> > like that) that we could use to find information about threads.
>
> Well, I'm guessing that the "[stack]" line
> /proc/<pid>/task/<pid>/maps describes the extent of each
> stack. Is this an interface we can depend on over all Linux
> implementations? (isn't /proc optional during kernel
> configuration?)
>
> AG
>
>
>
17 years, 10 months
RE: [fedora-java] rssowl: libgcj bugs that need fixing for it torun
by Robin Green
> On Thu, 2005-07-28 at 11:34 -0700, Boehm, Hans wrote:
> > [I missed the beginning of this thread initially.]
> >
> > I'm actually trying to work on some of these issues. Some status:
>
> Cool.
>
> Robin - is there a local hack/patch we can apply to swt and/or rssowl to
> work around this problem until a real fix from Hans migrates into GCC?
I'm a bit out of my depth here.
Hans wrote: "Gc7 (even the released, but very experimental alpha3 version)
has a thread registration interface." This implies that the version in gcc
_doesn't_ have a thread registration interface, or anything that could
be hacked together into one. Is that surmise correct?
If so, the only other thing I can think of is to spawn a new registered thread instead
of calling AttachCurrentThread, and somehow translate all C->Java invocations
on the unregistered thread into inter-thread calls onto the new registered thread.
In other words, keep all Java code on a separate thread. Yuck.
--
Robin
17 years, 10 months
rssowl: libgcj bugs that need fixing for it to run
by Robin Green
I have also been working in my spare time on packaging rssowl for FC5
[sic]. I can post my .spec file if wanted. Here's my list of unfixed
libgcj bugs that need to be fixed before rssowl will run natively
reliably. These are both threading bugs.
1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22211
"Thread.interrupt sometimes causes abort if thread is already dead"
This gets hits about 25%-50% of the time on quitting rssowl, and
occassionaly also when I press the little red stop button at the bottom of
the window. I can provide a backtrace if wanted.
Unfortunately rssowl only saves any changes upon quit, so this means
that any changes (including preferences and even the record of which feed
items have been read) will be lost 25-50% of the time - unacceptable,
obviously.
2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
"AttachCurrentThread() not working"
This is an old bug. It only triggered for me once I rebuilt gcc for
Athlon (32bit) with a private threading patch, but now it triggers 100% of
the time, every time I try to view the Dilbert comic in rssowl. Again,
backtrace available on request. I am convinced that it is a real bug in
the existing code, not a bug in my patch. After all, bad memory accesses
don't always trigger SIGSEGVs. Sometimes they just cause memory
corruptions. So probably, previously it was just causing memory
corruptions instead of SIGSEGVs for some subtle reason.
Feel free to add to this list.
--
Robin
17 years, 10 months
Re: Odd ClassNotFoundException with RSSOwl
by Andrew Overholt
Oops, I meant to CC the list.
Hi Ben,
* Benjamin Pasero <bpasero(a)rssowl.org> [2005-07-25 15:58]:
>
> the origin of this is most likely "jface.jar" requring parts of
> Eclipse's platform Jars.
Ah.
> I will ask a SWT comitter that told me he once managed to remove the
> dependency. He might be able to create a jar for me.
That won't really work unless we can patch FC's JFace build stuff to allow
the JFace jar in the system to have the same dependency removed. But it's
a good step forward.
Either way, I've made an SRPM and specfile available for the little hackjob
I did on this:
http://www.overholt.ca/rssowl/
Things work pretty well for me. The specfile lists things that we need to
do. If anyone wants to help, it'd be greatly appreciated.
Thanks,
Andrew
17 years, 10 months
gcj and java at LinuxWorld
by Anthony Green
Just FYI, I'll be giving an extremely short talk on java, gcj, etc as
they relate to the Fedora project during the San Francisco LinuxWorld
show. It will be in the Fedora booth on Wednesday the 10th at 11am.
I'll hang around a little before and after just in case anybody is
interested in a discussion.
AG
17 years, 10 months
