Home » Archived » BIRT » Recommendations for integrating Birt Viewer w/ several webapps
| Recommendations for integrating Birt Viewer w/ several webapps [message #256690] |
Mon, 01 October 2007 17:50  |
Eclipse User |
|
|
|
Originally posted by: dserodio.gmail.com
I'm beginning to use Birt to generate reports for some of my webapps.
Should I use one Birt Viewer instance for all webapps? One Birt Viewer
instance per webapp?
For instance, some reports should be available only for some J2EE roles,
while others should be available for any authenticated user.
Does anyone have any recommendations for integrating Birt Viewer w/
several webapps?
Thanks in advance,
Daniel Serodio
|
|
|
| Re: Recommendations for integrating Birt Viewer w/ several webapps [message #256994 is a reply to message #256690] |
Thu, 04 October 2007 01:55  |
| Eclipse User |
|
|
|
Daniel Serodio wrote:
> I'm beginning to use Birt to generate reports for some of my webapps.
>
> Should I use one Birt Viewer instance for all webapps? One Birt Viewer
> instance per webapp?
>
> For instance, some reports should be available only for some J2EE roles,
> while others should be available for any authenticated user.
>
> Does anyone have any recommendations for integrating Birt Viewer w/
> several webapps?
>
> Thanks in advance,
> Daniel Serodio
I think the "official" solution is on Birt Viewer per webapp, because
all examples and doc are describing this way.
But in my opinion it has several drawbacks:
(*) The war file explodes (40MB for Birt only), because Birt has a huge
footprint.
(*) Each webapp starts its own OSGi engine, which costs lots of
resources and a looong startup time.
(*) The builtin viewer does not support running webapps that are not
unpacked during runtime, which is specified in servlet specification.
(*) The builtin viewer has a security hole, because it allows and
prefers(!) to store the rptdesign files in web-root. If you do so, you
can view the rptdesign source in the browser, and so you can view the
database password, which isn't really protected.
So I wrote my own viewer, put the OSGi engine with Birt to (in tomcat)
the common classloader. So OSGi is started only once.
But the major problem of Birt is, that ther are many, many bugs!!!
We tried 1.x and 2.0.x, but there was no thougt to really work, of
course some examples worked but no real world reports. 2.1.x was the
first usable versions. So we decided to use Birt in our company, hoping
the remainig bugs are fixed in 2.2.x. But since 2.2.x there are so many
new bugs (even in 2.2.1), that we are consider to remove Birt from our
apps. 2.2.0 and 2.2.1 are NO stable releases, they maybe beta releases.
|
|
|
| Re: Recommendations for integrating Birt Viewer w/ several webapps [message #257082 is a reply to message #256994] |
Thu, 04 October 2007 11:23 |
| Eclipse User |
|
|
|
Originally posted by: dserodio.gmail.com
John, thanks for your information, I'm very new to Birt so I haven't ran
into too many bugs yet.
If you put the OSGi engine on the common Tomcat classloader, are you
positive that the runtime will be shared between webapps? I thought the
classes themselves would, but the runtime (ie, object) would not; but I
know next to nothing about OSGi.
I don't suppose you could share your custom web viewer, can you?
Otherwise, can you elaborate on your solution to "share" the OSGi engine?
Thanks,
Daniel Serodio
John wrote:
> Daniel Serodio wrote:
>> I'm beginning to use Birt to generate reports for some of my webapps.
>>
>> Should I use one Birt Viewer instance for all webapps? One Birt Viewer
>> instance per webapp?
>>
>> For instance, some reports should be available only for some J2EE roles,
>> while others should be available for any authenticated user.
>>
>> Does anyone have any recommendations for integrating Birt Viewer w/
>> several webapps?
>>
>> Thanks in advance,
>> Daniel Serodio
>
> I think the "official" solution is on Birt Viewer per webapp, because
> all examples and doc are describing this way.
> But in my opinion it has several drawbacks:
> (*) The war file explodes (40MB for Birt only), because Birt has a huge
> footprint.
> (*) Each webapp starts its own OSGi engine, which costs lots of
> resources and a looong startup time.
> (*) The builtin viewer does not support running webapps that are not
> unpacked during runtime, which is specified in servlet specification.
> (*) The builtin viewer has a security hole, because it allows and
> prefers(!) to store the rptdesign files in web-root. If you do so, you
> can view the rptdesign source in the browser, and so you can view the
> database password, which isn't really protected.
>
> So I wrote my own viewer, put the OSGi engine with Birt to (in tomcat)
> the common classloader. So OSGi is started only once.
>
> But the major problem of Birt is, that ther are many, many bugs!!!
> We tried 1.x and 2.0.x, but there was no thougt to really work, of
> course some examples worked but no real world reports. 2.1.x was the
> first usable versions. So we decided to use Birt in our company, hoping
> the remainig bugs are fixed in 2.2.x. But since 2.2.x there are so many
> new bugs (even in 2.2.1), that we are consider to remove Birt from our
> apps. 2.2.0 and 2.2.1 are NO stable releases, they maybe beta releases.
|
|
|
| Re: Recommendations for integrating Birt Viewer w/ several webapps [message #257270 is a reply to message #257082] |
Fri, 05 October 2007 03:22 |
| Eclipse User |
|
|
|
My structure
catalina.base
+ common
+ birt
+ ReportEngine
+ configuration
+ lib
+ plugins
...
+ classes
+ lib
Place ${catalina.base}/common/birt/ReportEngine/lib/*.jar
in conf/catalina.properties in section common.loader
and start the engine e.g. with a (Tomcat) LifecycleListener at tomcat
startup.
If doing so you can access the birt runtime from every webapp in this
tomcat.
My "viewer" isn't really a viewer, it encapsulates the Birt API calls
and sets some HTTP headers (e.g. contenttype), opens acrobat reader, but
no drill down in html. I put my "viewer" to common/lib because viewer
depends on the correct BIRT version, which is also in common/birt. So
changing to an other BIRT version can be done in common - hoping
rptdesigns work correct...
John
Daniel Serodio schrieb:
> John, thanks for your information, I'm very new to Birt so I haven't ran
> into too many bugs yet.
>
> If you put the OSGi engine on the common Tomcat classloader, are you
> positive that the runtime will be shared between webapps? I thought the
> classes themselves would, but the runtime (ie, object) would not; but I
> know next to nothing about OSGi.
>
> I don't suppose you could share your custom web viewer, can you?
> Otherwise, can you elaborate on your solution to "share" the OSGi engine?
>
> Thanks,
> Daniel Serodio
>
> John wrote:
>> Daniel Serodio wrote:
>>> I'm beginning to use Birt to generate reports for some of my webapps.
>>>
>>> Should I use one Birt Viewer instance for all webapps? One Birt Viewer
>>> instance per webapp?
>>>
>>> For instance, some reports should be available only for some J2EE roles,
>>> while others should be available for any authenticated user.
>>>
>>> Does anyone have any recommendations for integrating Birt Viewer w/
>>> several webapps?
>>>
>>> Thanks in advance,
>>> Daniel Serodio
>> I think the "official" solution is on Birt Viewer per webapp, because
>> all examples and doc are describing this way.
>> But in my opinion it has several drawbacks:
>> (*) The war file explodes (40MB for Birt only), because Birt has a huge
>> footprint.
>> (*) Each webapp starts its own OSGi engine, which costs lots of
>> resources and a looong startup time.
>> (*) The builtin viewer does not support running webapps that are not
>> unpacked during runtime, which is specified in servlet specification.
>> (*) The builtin viewer has a security hole, because it allows and
>> prefers(!) to store the rptdesign files in web-root. If you do so, you
>> can view the rptdesign source in the browser, and so you can view the
>> database password, which isn't really protected.
>>
>> So I wrote my own viewer, put the OSGi engine with Birt to (in tomcat)
>> the common classloader. So OSGi is started only once.
>>
>> But the major problem of Birt is, that ther are many, many bugs!!!
>> We tried 1.x and 2.0.x, but there was no thougt to really work, of
>> course some examples worked but no real world reports. 2.1.x was the
>> first usable versions. So we decided to use Birt in our company, hoping
>> the remainig bugs are fixed in 2.2.x. But since 2.2.x there are so many
>> new bugs (even in 2.2.1), that we are consider to remove Birt from our
>> apps. 2.2.0 and 2.2.1 are NO stable releases, they maybe beta releases.
|
|
|
Goto Forum:
Current Time: Fri Oct 31 10:59:18 EDT 2025
Powered by FUDForum. Page generated in 0.03748 seconds |
Home