| Some comments on the code [message #7776] |
Thu, 10 February 2005 23:03  |
Eclipse User |
|
|
|
Originally posted by: csetera.spss.com
Let me start by saying how impressed we are with what we are seeing for
the BIRT code that is starting to roll out into source control. Keep up
the great work!
Although we are aware that the work is still ongoing, there were a
couple of concerns that we had when looking at the current code that we
wanted to get noted while there is still a chance that they can possibly
be considered during the first release timeframe.
We were a bit confused with the logging story in the code. There seems
to be quite a mix of logging involved and the question is whether that
will be merged into a single logging implementation? There is
widespread use of commons logging throughout the BIRT code. This caused
us a large number of headaches even getting parts of the viewer code to
run due to classloader issues.
http://www.qos.ch/logging/classloader.jsp and
http://www.qos.ch/logging/thinkAgain.jsp document the numerous problems
when dealing with commons logging. Would it be possible to eliminate
commons logging from the mix and just pick an appropriate logging
framework? Despite the addition of logging in the JDK, it seems that
log4j is still the best choice due to its ability to be hosted on
multiple JDK levels and its functionality. In addition, it seems odd
that the org.eclipse.birt.data.oda.util.logging package and its contents
exist. It is unclear why this is necessary in addition to the other
logging facilities available.
Eventually, we would like to look at packaging the designer views into a
standalone designer tool for non-Eclipse users. The Eclipse RCP
refactoring makes that very possible, as long as plugin prerequisites
are kept to a minimum. At this time, the designer UI holds a dependency
on the org.eclipse.compare plugin which in turn drags in many non-RCP
plugins (such as the resources plugin). The dependency appears to be so
the UI can use the org.eclipse.compare.Splitter class. If this
dependency can be broken (by reimplementing the Splitter class or
similar), it appears that the designer should be able to be built as an
Eclipse RCP application.
Once again, we'd like to say how cool this stuff is looking. Hopefully
you won't take these comments to mean that we aren't impressed and
thrilled to see what is coming. Our hope is to help make BIRT as good
as it can possibly be.
Thanks,
Craig
|
|
|
| Re: Some comments on the code [message #8875 is a reply to message #7776] |
Thu, 17 February 2005 03:06  |
 Stanley Wang
Messages: 81
Registered: July 2009 |
Member |
|
|
Craig,
Thanks for your comments on the source code. I will focus on the logging
part for this response.
We have chosen common logging framework because many other projects use
the framework (including Tomcat). We however, do have concerns about the
classloader issues you reported. We will reevaluate the logging technology
and likely pick either Java 1.4 logging or log4j.
All BIRT projects will use a uniform logging framework even though some
projects have not done so.
Stanley Wang
BIRT Engine Lead
Craig Setera wrote:
> Let me start by saying how impressed we are with what we are seeing for
> the BIRT code that is starting to roll out into source control. Keep up
> the great work!
> Although we are aware that the work is still ongoing, there were a
> couple of concerns that we had when looking at the current code that we
> wanted to get noted while there is still a chance that they can possibly
> be considered during the first release timeframe.
> We were a bit confused with the logging story in the code. There seems
> to be quite a mix of logging involved and the question is whether that
> will be merged into a single logging implementation? There is
> widespread use of commons logging throughout the BIRT code. This caused
> us a large number of headaches even getting parts of the viewer code to
> run due to classloader issues.
> http://www.qos.ch/logging/classloader.jsp and
> http://www.qos.ch/logging/thinkAgain.jsp document the numerous problems
> when dealing with commons logging. Would it be possible to eliminate
> commons logging from the mix and just pick an appropriate logging
> framework? Despite the addition of logging in the JDK, it seems that
> log4j is still the best choice due to its ability to be hosted on
> multiple JDK levels and its functionality. In addition, it seems odd
> that the org.eclipse.birt.data.oda.util.logging package and its contents
> exist. It is unclear why this is necessary in addition to the other
> logging facilities available.
> Eventually, we would like to look at packaging the designer views into a
> standalone designer tool for non-Eclipse users. The Eclipse RCP
> refactoring makes that very possible, as long as plugin prerequisites
> are kept to a minimum. At this time, the designer UI holds a dependency
> on the org.eclipse.compare plugin which in turn drags in many non-RCP
> plugins (such as the resources plugin). The dependency appears to be so
> the UI can use the org.eclipse.compare.Splitter class. If this
> dependency can be broken (by reimplementing the Splitter class or
> similar), it appears that the designer should be able to be built as an
> Eclipse RCP application.
> Once again, we'd like to say how cool this stuff is looking. Hopefully
> you won't take these comments to mean that we aren't impressed and
> thrilled to see what is coming. Our hope is to help make BIRT as good
> as it can possibly be.
> Thanks,
> Craig
|
|
|
Powered by
FUDForum. Page generated in 0.03604 seconds
] 
Search
Help
Register
Login
Home
