cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom HTML-based browser for CXF logs"
Date Thu, 22 Apr 2010 16:51:51 GMT
Hi Tomasz

On Thu, Apr 22, 2010 at 4:31 PM, Tomasz Oponowicz <> wrote:

> Hi Sergey,
> On Thu, Apr 22, 2010 at 3:10 PM, Sergey Beryozkin <>
> wrote:
> > Indeed, at the moment I'm thinking of us starting from something similar
> to
> > "Centralized structure without logs server", it is quite close but not
> > exactly what I've had in mind.
> Sorry to bother you. I think it is worth to ask few more question to
> avoid troubles at the end.

there's no need to apologize at all :-)

> It's great that we have one vision now.
> > The browser application/endpoint will get available say at
> > http://localhost:8080/services/logs and when a users targets this URI
> he/she
> > will be presented with an initial page and then a user will be able to
> > subscribe to individual feeds whose addresses a user will find about from
> > the http://localhost:8080/services page or through some other channels.
> This sample is clear. However I would like to consider something.
> It's worth to notice that all endpoints (which will interact with log
> browser) have to be on the same host, where initial page (log browser
> page) exist - because of same origin policy [1].
I do not think it should be a problem. Users would probably have a separate
tab per each host if needed...Lets assume for a start we have a single
host/single container hosting all the endpoints (cxf ones, one/many
AtomPullServer ones plus a browser one). For a case where we have a single
host but multiple containers we can consider utilizing AtomPushBeans
forwarding events to a centralized AtomPullServer or may we will just
recommend opening a tab per each container, we'll see.

thanks, Sergey

> It will be the only limitation of log browser.
> [1]
> --
> Best regards,
> Tomasz Oponowicz

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message