asterisk-java-users

Re: [Asterisk-java-users] pre-packaged jars

[Alex M. <al...@go...>]

On Thu, 2005-03-17 at 17:37 -0600, Alex Malinovich wrote:
> What are the odds of getting some nice, pre-packaged jars of
> asterisk-java anytime in the near future? I'm ready to do a limited
> rollout of my application here internally, but I need to distribute
> asterisk-java with it. And since it's all being done with Java Web Start
> I need a clean jar I can include.
>=20
> I've tried making some of my own, but I keep having problems with the
> logging libraries being missing. If I include them in, the application
> just hangs. And javaws doesn't give me any errors that I can see, which
> makes it difficult to diagnose.

Ok, I've managed to make my own jar and have it work. Unfortunately, it
also requires me to distribute both commons-logging and commons-lang
with the application. All together, this adds almost an entire megabyte
to the size of the distributed application. And since this is a Java Web
Start program, that's going to end up being rather slow in the future.

So with that said, is there any simple way to completely remove the NEED
for logging in asterisk-java? Something other than going through the
entire source and removing every call to the logging facilities by hand
of course.

--=20
Alex Malinovich
Golden Technologies, Inc.
(219) 462-7200 x 216
http://www.golden-tech.com

Re: [Asterisk-java-users] pre-packaged jars

[Alex M. <al...@go...>]

On Tue, 2005-03-22 at 22:59 +0000, Stefan Reuter wrote:
--snip--
> The dependency on commons-lang should be removed in latest CVS. I am not
> aware on a dependency of commons-logging on commons-lang.

At the time that I was building the packages, there was a commons-lang
function (something similiar to toString, but I forget the exact name)
that was being called inside commons-logging.

> I will look at the code again when i am back home next week and decide if
> its possible to borrow the stuff for switching the logging api between jd=
k
> and log4j and remove that dependency as well.

I don't know if there's any simple way to do this. For test, the logging
functionality is definitely useful. However, when it comes time to
distribute the program, having to add two extra dependencies that will
NEVER actually be used is kind of frustrating.

> Please help me with some testing of the library and post your results
> (positive and negative experiences to the list).
> If you wish we can start with a release candidate within the next two or
> three weeks.

So far, I've had very positive experiences with the library. The
application that I'm using it in has made it up to v0.97d and has been
stable for over a week. (We use it all day every day during the week
here at the office.)

I have also received approval from my company to release the program
publicly under the GPL. As soon as I have some time to clean up the code
and put in appropriate GPL blurbs in all the source I'm going to look at
getting the project put up on sourceforge for continued development. At
that point, I would be VERY interested in having release candidates
available for asterisk-java so that I can easily say something like,
v0.97d depends on asterisk-java rc1, v1.0 depends on asterisk-java rc3
(or 0.2 rc1, etc.).

--=20
Alex Malinovich
Golden Technologies, Inc.
(219) 462-7200 x 216
http://www.golden-tech.com

Re: [Asterisk-java-users] pre-packaged jars

[Stefan R. <sr...@re...>]

On Wed, 2005-03-30 at 13:13 -0600, Alex Malinovich wrote:
> On Tue, 2005-03-22 at 22:59 +0000, Stefan Reuter wrote:
> --snip--
> > The dependency on commons-lang should be removed in latest CVS. I am no=
t
> > aware on a dependency of commons-logging on commons-lang.
>=20
> At the time that I was building the packages, there was a commons-lang
> function (something similiar to toString, but I forget the exact name)
> that was being called inside commons-logging.

I grepped the source code of commons-logging 1.0.4 for the string
"commons.lang" and found no match. Therefore I suppose recent versions
of commons-logging do no longer depend on commons-lang.

> > I will look at the code again when i am back home next week and decide =
if
> > its possible to borrow the stuff for switching the logging api between =
jdk
> > and log4j and remove that dependency as well.
>=20
> I don't know if there's any simple way to do this. For test, the logging
> functionality is definitely useful. However, when it comes time to
> distribute the program, having to add two extra dependencies that will
> NEVER actually be used is kind of frustrating.

Sure I understand your concerns. After further investigation I think the
easiest way to go is to use a very thin wrapper around commons-logging's
LogFactory that determines via reflection if the commons-logging classes
are available. If they are available on the classpath a commons-logging
Log object (in fact a proxy for it) will be returned otherwise a NullLog
will be returned that does nothing.
So we will still have a compile time dependency on commons-logging but
at runtime logging is just switched off if commons-logging is not
available.
Will this change help you?

> So far, I've had very positive experiences with the library. The
> application that I'm using it in has made it up to v0.97d and has been
> stable for over a week. (We use it all day every day during the week
> here at the office.)

Thats nice to hear and makes me more confident of providing a non-crappy
release candidat :)
r
> I have also received approval from my company to release the
> publicly under the GPL. As soon as I have some time to clean up the code
> and put in appropriate GPL blurbs in all the source I'm going to look at
> getting the project put up on sourceforge for continued development.

When you have more information available on that let us now - it will be
the first open source software using Asterisk-java i know of.

> At that point, I would be VERY interested in having release candidates
> available for asterisk-java so that I can easily say something like,
> v0.97d depends on asterisk-java rc1, v1.0 depends on asterisk-java rc3
> (or 0.2 rc1, etc.).

Sure. I will try my best to provide it asap. I will change the logging
dependency as described above and start packaging.
Did you have a look at the maven built snapshot releases on
http://maven.reucon.com/maven/asterisk-java/distributions/ ?

=3DStefan

[Asterisk-java-users] hard runtime dependency on commons-logging removed

[Stefan R. <sr...@re...>]

Hi Alex,

> After further investigation I think the
> easiest way to go is to use a very thin wrapper around commons-logging's
> LogFactory that determines via reflection if the commons-logging classes
> are available. If they are available on the classpath a commons-logging
> Log object (in fact a proxy for it) will be returned otherwise a NullLog
> will be returned that does nothing.
> So we will still have a compile time dependency on commons-logging but
> at runtime logging is just switched off if commons-logging is not
> available.

I just implemented this as described before.
If commons-logging is available it will be used, if not no logging is
done. So now you only need to include the asterisk-java jar file if you
dont need any logging.


Please check the latest snapshot available from
http://maven.reucon.com/maven/asterisk-java/distributions/ 
that includes this change.

=Stefan

Re: [Asterisk-java-users] pre-packaged jars

[Chris H. <ch...@as...>]

On Mar 17, 2005, at 7:12 PM, Alex Malinovich wrote:

>>
>
> Ok, I've managed to make my own jar and have it work. Unfortunately, it
> also requires me to distribute both commons-logging and commons-lang
> with the application. All together, this adds almost an entire megabyte
> to the size of the distributed application. And since this is a Java 
> Web
> Start program, that's going to end up being rather slow in the future.
>
> So with that said, is there any simple way to completely remove the 
> NEED
> for logging in asterisk-java? Something other than going through the
> entire source and removing every call to the logging facilities by hand
> of course.
>
Alex,
   I had the same problem and it seem to be that the Jars for the  
logging was missing some of the classes required.

Chris