Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 367754 - [nano] Enable per-app trace logging in Nano
Summary: [nano] Enable per-app trace logging in Nano
Status: NEW
Alias: None
Product: Virgo
Classification: RT
Component: runtime (show other bugs)
Version: 3.1.0.M01   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: 3.6.0.RELEASE   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-03 07:46 EST by Borislav Kapukaranov CLA
Modified: 2012-07-03 06:41 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Borislav Kapukaranov CLA 2012-01-03 07:46:40 EST 
Per-app(WAR) deployment should be straight-forward to enable in Nano as the required Tracing Service is included as part of it.

If it isn't possible to enable that, then we can remove the sifting log appender from the Nano's serviceability.xml
Comment 1 Borislav Kapukaranov CLA 2012-01-06 04:51:59 EST 
To clarify we are referring to web applications here.
Possible deployment sources options are the apps deployed via the hot-deployer and via p2. Both should not have any knowledge about the TracingService though, because it is not their concern.

In VTS and VJS the per-app trace logging is enabled in a separate "extension" for GW (o.e.v.web.tomcat.support bundle?). 
Should we have something similar here? I'm saying similar because it probably would be a simplified version of the web.tomcat.support bundle that would only configures the per-app trace logging and discover apps similarly to GW's extender bundle.
Comment 2 Glyn Normington CLA 2012-01-06 05:04:01 EST 
Yes, it seems reasonable to have per-app tracing in nano via a similar extension, although it may also be consistent with the performance requirements of nano to comment out the sifting appender configuration in serviceability.xml so that startup speed is optimal by default, but can easily be enabled by users that want it.
Comment 3 Borislav Kapukaranov CLA 2012-01-06 05:15:11 EST 
Ok, so I propose to comment out the sifting appender by default and additionally create a bundle to configure the tracing service. This bundle along with a serviceability.xml that has properly configured sifting appender will be wrapped in a p2 feature, so users could install this optionally.
wdyt?
Comment 4 Glyn Normington CLA 2012-01-06 05:26:48 EST 
(In reply to comment #3)
> Ok, so I propose to comment out the sifting appender by default and
> additionally create a bundle to configure the tracing service. This bundle
> along with a serviceability.xml that has properly configured sifting appender
> will be wrapped in a p2 feature, so users could install this optionally.
> wdyt?

Sounds good, but we'll need an integration test so that this feature does not stop functioning in the future without us noticing.
Comment 5 Glyn Normington CLA 2012-03-30 10:51:31 EDT 
This is an enhancement rather than a bug.