Re: How can I use WSRP4J to expose a web application as WSRP?

[Ali Sakebi <al...@gmail.com>]

As far as I have figured out from the source there is only few
interface that I have to implement:
PortletPool
PortletInvoker
DescriptionHandler
ProviderFactory, Provider
PortletStateImpl and PortletStateManagerImpl in provider.pluto.driver
seems to be reusable.

I'm trying to implement them for the simplest case, a Hello World
producer offered wsrp portlet.
Next I will try to extend it to real word application and if possible
to a framework to map servlet based web apps to wsrp portlets.
Probably there will be many difficulties including two phase
interaction, URL rewriting, limiting the web apps to work in fragment
of the page instead of entire of the page and ....

The code for first step is attached and I would be grateful  if
someone else review them and give me more idea to extend them.

On 12/4/06, Diego Louzán <dl...@apache.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ali Sakebi escribió:
> > Do you mean that exposing a web app directly as wsrp (without using
> > jsr168 as an intermediate) is not a standard way of using wsrp (in
> > Java world)? First I should use some bridge to convert ordinary web
> > app to jsr168 and another one to convert jsr168 to wsrp. Doesn't it
> > (using jsr168) duplicate complexity of the solution and/or remove some
> > functionality of wsrp?
> >
> > BTW, thanks for useful info about how to develop non-jsr168 solution.
> >
> > On 12/3/06, Diego Louzán <dl...@apache.org> wrote:
> > Ali Sakebi escribió:
> >> What about non- jsr168 web apps? I there any sample?
> >
> >> On 12/3/06, Diego Louzán <dl...@apache.org> wrote:
> >> Ali Sakebi escribió:
> >>> Does anyone know what does "producer" do and how does it works? Or how
> >>> can I use WSRP4J to expose a web application as WSRP?
> >
> >> Using Producer you can expose any jsr-168 portlet app as a WSRP
> > service.
> >> The current svn doesn't work for Producer, so you can't use it. For a
> >> working version, you can download an old snapshot from here:
> >
> >> http://wiki.apache.org/portals/WSRP4J/WorkingSnapshots
> >
> >> Select "Attachments" on the menu to download the snapshot.
> >
> >> Regards.
> >> Diego.
> >
> >
> > If you're asking about a non-standard solution, I mean, if you have your
> > own service developed (non-jsr-168) and you want to expose it as a WSRP
> > service, then you'll need to implement your own wrappers around wsrp to
> > be able to expose it as wsrp. Using wsrp4j, you can use the classes
> > provided by org.apache.wsrp4j.producer to implement your solution. The
> > classes under org.apache.wsrp4j.producer are the standard interfaces for
> > the producer; the classes under org.apache.wsrp4j.producer.provider are
> > the wrappers around the actual backend service for the producer: that
> > is, if you provide your own implementation of the
> > org.apache.wsrp4j.producer.provider interfaces, you can have your
> > service exposed as wsrp.
> >
> > Regards.
> > Diego.
> >>
>
>     WSRP portlets and JSR-168 portlets share many ideas (in fact, the
> specifications were both developed simultaneously and with each other on
> mind). Since the JSR-168 release, it has become the standard for
> developing portlets in Java: it was its goal and it makes portlet
> portability easier. So, WSRP4J provides a way to plug your JSR-168
> portlet into the WSRP4J Producer, and producer will expose that portlet
> as a WSRP service, there isn't any duplication of work, you must somehow
> implement your wsrp services, and this is the "most standard" way in
> Java. Why develop a new backend for wsrp portlets when you can expose
> your own portable jsr-168 portlets using a bridge? You leverage your
> portal container, which can manage jsr-168 portlet natively, by exposing
> them as wsrp.
>     If your portlets aren't jsr-168 you have two options:
> * Port them to jsr-168 which is the standard in Java, and then expose
> them using wsrp4j. Take into account that jsr-168 specification doesn't
> address issues like inter-portlet communication (the new version 2.0,
> jsr-286, addresses this but it's still in development).
> * Develop your own wrapper around wsrp by implementing your own solution
> OR provide your own implementation of
> org.apache.wsrp4j.producer.provider classes which connect the Producer
> implementation to the actual backend portlets serving the requests. In
> case of WSRP4J, these provider classes implementation connect Producer
> with Pluto Portal as a proof of concept.
>
> Regards.
> Diego.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFc1MYgyzZYflJelERAqSoAJ47IapvpFzgoBeKj4rDiUmWZIbrEgCeLPXj
> LY6mRCX2w2h42V5icGFDwZI=
> =zpMA
> -----END PGP SIGNATURE-----
>

Re: How can I use WSRP4J to expose a web application as WSRP?

[Diego Louzán <dl...@apache.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ali Sakebi escribió:
> As far as I have figured out from the source there is only few
> interface that I have to implement:
> PortletPool
> PortletInvoker
> DescriptionHandler
> ProviderFactory, Provider
> PortletStateImpl and PortletStateManagerImpl in provider.pluto.driver
> seems to be reusable.
> 
> I'm trying to implement them for the simplest case, a Hello World
> producer offered wsrp portlet.
> Next I will try to extend it to real word application and if possible
> to a framework to map servlet based web apps to wsrp portlets.
> Probably there will be many difficulties including two phase
> interaction, URL rewriting, limiting the web apps to work in fragment
> of the page instead of entire of the page and ....
> 
> The code for first step is attached and I would be grateful  if
> someone else review them and give me more idea to extend them.
> 
> On 12/4/06, Diego Louzán <dl...@apache.org> wrote:
> Ali Sakebi escribió:
>> Do you mean that exposing a web app directly as wsrp (without using
>> jsr168 as an intermediate) is not a standard way of using wsrp (in
>> Java world)? First I should use some bridge to convert ordinary web
>> app to jsr168 and another one to convert jsr168 to wsrp. Doesn't it
>> (using jsr168) duplicate complexity of the solution and/or remove some
>> functionality of wsrp?
> 
>> BTW, thanks for useful info about how to develop non-jsr168 solution.
> 
>> On 12/3/06, Diego Louzán <dl...@apache.org> wrote:
>> Ali Sakebi escribió:
>>> What about non- jsr168 web apps? I there any sample?
> 
>>> On 12/3/06, Diego Louzán <dl...@apache.org> wrote:
>>> Ali Sakebi escribió:
>>>> Does anyone know what does "producer" do and how does it works? Or
> how
>>>> can I use WSRP4J to expose a web application as WSRP?
> 
>>> Using Producer you can expose any jsr-168 portlet app as a WSRP
>> service.
>>> The current svn doesn't work for Producer, so you can't use it. For a
>>> working version, you can download an old snapshot from here:
> 
>>> http://wiki.apache.org/portals/WSRP4J/WorkingSnapshots
> 
>>> Select "Attachments" on the menu to download the snapshot.
> 
>>> Regards.
>>> Diego.
> 
> 
>> If you're asking about a non-standard solution, I mean, if you have
> your
>> own service developed (non-jsr-168) and you want to expose it as a WSRP
>> service, then you'll need to implement your own wrappers around wsrp to
>> be able to expose it as wsrp. Using wsrp4j, you can use the classes
>> provided by org.apache.wsrp4j.producer to implement your solution. The
>> classes under org.apache.wsrp4j.producer are the standard interfaces
> for
>> the producer; the classes under org.apache.wsrp4j.producer.provider are
>> the wrappers around the actual backend service for the producer: that
>> is, if you provide your own implementation of the
>> org.apache.wsrp4j.producer.provider interfaces, you can have your
>> service exposed as wsrp.
> 
>> Regards.
>> Diego.
> 
> 
>     WSRP portlets and JSR-168 portlets share many ideas (in fact, the
> specifications were both developed simultaneously and with each other on
> mind). Since the JSR-168 release, it has become the standard for
> developing portlets in Java: it was its goal and it makes portlet
> portability easier. So, WSRP4J provides a way to plug your JSR-168
> portlet into the WSRP4J Producer, and producer will expose that portlet
> as a WSRP service, there isn't any duplication of work, you must somehow
> implement your wsrp services, and this is the "most standard" way in
> Java. Why develop a new backend for wsrp portlets when you can expose
> your own portable jsr-168 portlets using a bridge? You leverage your
> portal container, which can manage jsr-168 portlet natively, by exposing
> them as wsrp.
>     If your portlets aren't jsr-168 you have two options:
> * Port them to jsr-168 which is the standard in Java, and then expose
> them using wsrp4j. Take into account that jsr-168 specification doesn't
> address issues like inter-portlet communication (the new version 2.0,
> jsr-286, addresses this but it's still in development).
> * Develop your own wrapper around wsrp by implementing your own solution
> OR provide your own implementation of
> org.apache.wsrp4j.producer.provider classes which connect the Producer
> implementation to the actual backend portlets serving the requests. In
> case of WSRP4J, these provider classes implementation connect Producer
> with Pluto Portal as a proof of concept.
> 
> Regards.
> Diego.
>>

I'm sorry I can't review your code, I'm currently very busy trying to
get all wsrp4j features working before the end of the year. Maybe some
other committer will show off and can provide you more insight.

Regards.
Diego.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFfTfMgyzZYflJelERArHHAJ9FWioukRIzSVMcZnqMyk44yRNP7gCgo9ND
iLNSAHojTAhxtYacBXJH4Jk=
=SZZa
-----END PGP SIGNATURE-----