Sorry, I did not mean to make it private. It is good to keep it part of
mailing list as it may be useful for others in the future.
Regarding my problem, I am building a OSGi based Enterprise application
server which uses various OSGi core and enterprise OSGi services. I am
using using pax-web to provide the http service and web container
service (RFC 66) implementation.
Within this server, I have also embedded Apache OFBiz (ERP and
E-commerce server). Apache OFBiz uses Log4J as logging library with its
own wrapper around it. To satisfy the OFBiz dependencies, I need the
original log4j bundles.
As far as I know pax-web depends on the pax-logging. Loading of
org.apache.log4j.Layout class by OFBiz bundle fails because OFBiz tries
to load this class from the pax-logging version of log4j exported
package (org.apache.log4j) and this class is not available in the
pax-web bundle and OFBiz bundle fails to resolve. At the same time
exported packages form the log4j bundle are ignored as pax-loggin log4j
and my original log4j exported packages version are same.
I know it is not huge task for me to find a alternative. The reason I
brought this to the notice of pag-logging community is I think there may
be many more legacy libraries/application which are using the log4j for
logging and doing some nasty things for configuration. It may not be
possible to change the code of these application and I was thinking if
it is possible to find a work around within the pax-logging.
Regards,
Raj
On 22/04/10 19:52, Niclas Hedhman wrote:
Do you realize that this thread is now private?
If you are not happy with Pax Logging, feel free to substitute with
your own version of Log4j bundling. My guess is that you will have a
different set of issues, trading a known problem for one or more
unknown ones. Not tantalizing proposal, I know.
The issue about having the same versions revolves around what Log4j
clients expect. Bumping to Log4j 2.0 or 1.5 (or anything else) would
cause more confusion. Currently there is only a small set of client
code that doesn't work, typically those that tries to be 'clever' and
use Log4j in unintended ways, OR try to establish a configuration
programmatically.
I think to have ease of mind for most is more important than technical
accuracy for all.
Also, you still have not pointed out the actual problem you are
facing, and instead speaking in general terms, which doesn't give me
much to go on, in terms of either suggestions on improvements or
work-arounds.
On Thu, Apr 22, 2010 at 8:03 PM, Raj Saini<rajsa...@gmail.com> wrote:
Hi Niclas,
Sorry about the mixing web with logging. What I mean was pax logging and not
web.
If it is really needed to keep the log4j API in the pax-logging, and since
these API classes are not the original one, why not to give them a new
version number instead of using the log4j versions. OSGi does not have
problem having different version of the same jar. Problem is packages
exported by pax-logging have same version as the log4j.
Thanks,
Raj
On 22/04/10 17:22, Niclas Hedhman wrote:
If you are saying that Pax Web has Log4j classes in it, then that is a
bug.
If you are saying; Why isn't all Log4j exported in Pax Logging? The
answer is fairly long and complicated, but basically to be able to do
what Pax Logging does, it is essential to extract the Log4j API, which
isn't defined by the project, the implementation details and apis are
all mangled up, so I had to draw a line in the sand somewhere. And
what has been chosen is compatible with most(!) but NOT ALL
application usages. Also, the classes in Pax Logging API are not
'original', they have been modified to allow the log message routing
that occurs.
If you have more specific feedback, please feel free to express it...
Cheers
Niclas
On Thu, Apr 22, 2010 at 1:39 PM, Raj Saini<rajsa...@gmail.com> wrote:
Hi,
I am having a issue with pax-logging and Log4J. I have a legacy
application
using log4j library for logging. I have bundled this as a OSGi bundle and
embedding it in another application.
Pax logging has included the log4j classes in its own bundle and export
the
partial list of the packages. Now, when my legacy application tries to
load
the Log4J class, it is not found in the Log4J exported packages as the
given
class is not included in the pax-logging. Due to this I can't use the pax
logging (which is required by pax-web) and log4j in my runtime.
Is there a reason pax-web bundles the log4j classes with it? If pax-web
really needs to copy the log4j classes in it's bundle why are not all the
packages and classes are included and exported?
Regards,
Raj
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
