Hi Vicente,

I'm not sure integration by trying to compile the WIAB code in with your
application is the best approach, but perhaps you can tell us more about
what you're trying to do so we can judge.

The code under the org.waveprotocol.wave package is intended as re-usable
library code, and the build file can build it into jars for you to link
against. The code under org.waveprotocol.box is the WIAB application itself
and we never thought about it being compiled or linked into another
application. Guice is used for some pieces, but not universally because
Guice doesn't solve all problems. There's no commitment to keep interfaces
or bindings remotely stable within that code so I think integrating that
deep is likely to be painful.

However, you're hinting at something we would like to do, which is to be
able to delegate WIAB authentication to external authentication systems. I
had imagined this would involve a general auth interface in WIAB with
multiple implementations of that interface, something without too much
churn. So WIAB would still be a stand-alone binary but you could switch auth
systems by configuration. Ditto persistence.

Alex

On 18 January 2011 21:54, Vicente J. Ruiz Jurado <[email protected]>wrote:

> Hi again,
>
> Next question. We are trying to integrate the Wave server into our
> (modest) server code. We were also using Guice, so it should be
> relatively easy.
>
> The idea is to try to play with the Authentication services (initially)
> and integrate them with our equivalent services. And the same thing with
> the persistence stuff. One year ago, to integrate Fedone was easy, but
> of course WIAB is something else (a lot of servlets, more complex
> startup, etc).
>
> Our first small problems: Guice complains about some final classes or
> classes without a public constructor in:
>
> M src/org/waveprotocol/box/server/authentication/SessionManagerImpl.java
> M src/org/waveprotocol/box/server/robots/RobotRegistrationServlet.java
> M src/org/waveprotocol/box/server/robots/dataapi/DataApiTokenContainer.java
> M src/org/waveprotocol/box/server/rpc/AttachmentServlet.java
> M src/org/waveprotocol/box/server/rpc/FetchServlet.java
> M src/org/waveprotocol/box/server/rpc/UserRegistrationServlet.java
>
> because we are using interceptors. See limitations in:
> https://code.google.com/p/google-guice/wiki/AOP
>
> Anyway I'm not sure if I'm walking in the right direction in order to
> integrate WIAB in our project...
>
> The first attempt was to try to run our server code and the WIAB code in
> the same context and server port. However, I failed to convert
> ServerRpcProvider to something compatible with GuiceFilter (because
> ProxyServlet.Transparent and WaveSocketIOServlet are not HttpServlets,
> and Guice seems to only allow registering HttpServlets, or I don't know
> how to do it).
>
> Right now, I can start our code (in the 8080 port) with the WIAB server
> code (but running in the 9898 port) as dependencies. If using such
> approach, I think we need to proxy our client (running in 8080) wave
> petitions to the WIAB 9898 port, right?
>
> Well, as it's clear, I'm somehow confused with which is the best way to
> integrate WIAB in other projects. Could someone provide any
> recommendation/advise? Is there any documentation related to this issue?
> Any feedback or comment would be more than welcome.
>
> Thanks in advance,
> --
> Vicente J. Ruiz Jurado
>
> http://comunes.org
> http://ourproject.org
> http://homes.ourproject.org/~vjrj/blog
>
>  "For the more there are who say 'Ours,'-not 'Mine'- by that much is
>  each richer ." [Dante on the joys of sharing (Purgatorio, XV)]
>
>
>
>
>
>
>

Reply via email to