Home » Eclipse Projects » Technology Project and PMC » RSP-UI Proposal Discussion Thread
|
| Re: RSP-UI Proposal Discussion Thread [message #71628 is a reply to message #71609] |
Mon, 08 May 2006 16:08   |
Eclipse User |
|
|
|
I am very excited to see that this project is now official. This is an
ambitious project that will require a tremendous amount of hard work to
get it right.
I'll be closely watching this project and if there is anything OSGi
related that I can help with, I will. Do not hesitate to contact me with
an OSGi related questions.
Kind regards,
Peter Kriens
|
|
| |
| Re: RSP-UI Proposal Discussion Thread [message #71665 is a reply to message #71609] |
Tue, 09 May 2006 12:48 |
| Eclipse User |
|
|
|
Nice to see that it has made its way to Eclipse. I first saw these ideas in
javalobby. I've tried the example, and it worked well.
I had tried some similar ideas (like having extendable on actions) one year
ago, but failed with class loading issues within web containers. So it's
very nice to see a working example.
My interests are on tapestry integration and some basic UI frameworks(like
the menu, view, editor parts eclipse workbench provides)
Anyway, good ideas. looking forward to seeing a usable version ASAP.
Regards.
John Wilson
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #71684 is a reply to message #71647] |
Tue, 09 May 2006 18:19 |
| Eclipse User |
|
|
|
Hi all,
small update - now JSPs are compiling with the OSXA bundles from within
Eclipse. Main thing to sort out is the URL differences between running
the current scenarion under the servlet bridge in Tomcat (everything has
localhost/bridge/..... as root) as opposed to running directly on Jetty
(localhost/...), since many redirects, resource paths etc are
"hardcoded" into the servlets/jsps/views.
After sorting that out, we should be able to update the quickstart doc
with a "run directly from within PDE" section.
/peter
--
|
|
|
| RSP-UI and RCP integration [message #71701 is a reply to message #71609] |
Wed, 10 May 2006 23:09 |
| Eclipse User |
|
|
|
Hi!
I'm wondering what the community thinks if RSP should also provide code
to automatde the communcation between RCP and server side components?
For example, the JFace Databinding Framework is supposed to work to bind
data from a server to components on a client. I wonder if RSP should
also elaborate into this?
What does the community think about this?
Cu, Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #71722 is a reply to message #71628] |
Thu, 11 May 2006 14:16 |
| Eclipse User |
|
|
|
Originally posted by: sa.foroak.gmail.com
I have spent a lot of time "googling", looking for a way to develop
webapps following the MVC philosophy (if possible with different bundles
for view, model and logic) within an OSGI platform. And I hope this
project will lead me towards the solution!
As I have read in FAQ section (http://www.eclipse.org/proposals/rsp/),
"RSP-UI does not depend on particular OSGi container features beyond those
specified by applicable OSGi release levels"... So I guess it should be
strictly OSGI-conform (R4), and could be also used in other OSGI platforms
as Felix (http://incubator.apache.org/felix/) or Knopflerfish
(http://www.knopflerfish.org/). As Peter Kriens said in
http://www.quicktopic.com/35/H/7MDmdSANAr8e, "I would highly appreciate it
if it was an OSGi targeted project and not an Eclipse targeted project".
Anyway, I think this project is a great contribution.
Best regards,
Saioa
|
|
|
| Re: RSP-UI and RCP integration [message #71798 is a reply to message #71701] |
Fri, 12 May 2006 09:24 |
| Eclipse User |
|
|
|
Gunnar Wagenknecht wrote:
> Hi!
>
> I'm wondering what the community thinks if RSP should also provide code
> to automatde the communcation between RCP and server side components?
>
> For example, the JFace Databinding Framework is supposed to work to bind
> data from a server to components on a client. I wonder if RSP should
> also elaborate into this?
>
> What does the community think about this?
Personally, I think this will happen eventually, but the time frame is
unknown at the moment.
Cheers
Niclas
|
|
|
| Webapps based on MVC bundles in OSGI [message #71816 is a reply to message #71609] |
Fri, 12 May 2006 11:25 |
| Eclipse User |
|
|
|
Originally posted by: sa.foroak.gmail.com
Hi,
I am just reposting a thread that started in general mailing list in
OSP4J, as it is RSP-UI related.
On Thu, 2006-05-11 at 17:18 +0800, Niclas Hedhman wrote:
> On Thursday 11 May 2006 16:39, Saioa Arrizabalaga wrote:
> > Hi!
> > I am looking for a way to develop webapps in OSGI platform following
> > the MVC philosophy, if possible separating bundles for model, view and
> > logic.
> > I have only found two approaches:
> > The first one, an article writen by Wolfang Gehner where Eclipse +
> > Struts are used (http://www.infonoia.com/en/content.jsp?d=inf.05.09),
> > but I am afraid it will be too heavy for our requisites.
> > The second one, the wicket-dynamic project in ops4j, but the project
> > main page ( http://wiki.ops4j.org/dokuwiki/doku.php?id=pax:wicket-dynami c)
> > is uncomplete. Does anyone know what the status of this project is or
> > if there is any plan to keep on its development?
>
> First of all, Welcome to OPS4J...
>
> The Pax Wicket stuff will be folded into the RSP-UI project which Wolgang has
> been driving hard to get started.
> http://www.eclipse.org/proposals/rsp
>
> And if you think this is a good proposal, please express that on the Eclipse
> Technology newsgroup. You have a web access to that over
> http://www.eclipse.org/newsportal/thread.php?group=eclipse.t echnology
>
>
> What we have done so far with Wicket in an OSGi environment, is that
> additional bundles can add and remove "tabs" to a main page, which defines
> the general setup of that page. This is done in a commercial environment, and
> we have not been quick enough to update the Wiki with the findings. I hope
> I'll get to that eventually.
>
>
> Cheers
> Niclas
>
> _______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general
On Friday 12 May 2006 09:12, David Leangen wrote:
Although very interesting, this approach does not strike me as being
very light-weight. Maybe something like EJB3?
Or am I missing something? What do you see as the advantage of this over
the current type of Wicket plug-in, other than the larger community, of
course?
|
|
|
| Re: Webapps based on MVC bundles in OSGI [message #71835 is a reply to message #71816] |
Fri, 12 May 2006 11:27 |
| Eclipse User |
|
|
|
Originally posted by: sa.foroak.gmail.com
On Friday 12 May 2006 09:12, David Leangen wrote:
> Although very interesting, this approach does not strike me as being
> very light-weight. Maybe something like EJB3?
No it is not light-weight, and IMHO light-weight in itself is nothing
inherently good. In fact, I would even go as far as saying the "light" vs
"heavy" is a total misnomer of where the problems lies.
The traditional definition seems to suggest that just because something is
big, then it is of no use. In some cases, less functionality is seen as
better. But why is that perception prevailing??
I think it has nothing to do with the size of anything. I don't even think
it
is related to how tightly bound you get to a particular system.
What it thrives upon is the classic coupling between "monolithic" and
"large".
Monolithic applications are indeed inherently bad. And the opposite is the
"plug in architecture" which is what we come to love, in many forms;
Spring,
Eclipse, Pico and so forth.
And RSP-UI is all about pluggability. A fairly thin layer of framework to
gerase the wheels and exposure of the so called Extension Points. RSP-UI
draws upon the experience from the Eclipse Rich Client Platform, to get a
head start in what will be needed, but adopt that for a server environment,
which can not assume the single user envirnoment of Eclipse itself.
Now, once that framework is in place, you can grow that in any way
imaginable,
the same way as RCP is used both for Java IDE as well as cash machine
terminal, and hundreds of other totally different application types.
RSP-UI will allow you to make small plug-ins which is part of a larger
system.
Component-based server development (at last!) with the potential of a true
plug-n-play component market, much like the Eclipse platform is.
The initial effort is to allow the web application community at large to
re-use existing solutions, and wrap them into components for a rapid
growth.
But I predict the components will slowly become smaller, more dedicated and
more suitable for re-use.
> Or am I missing something? What do you see as the advantage of this over
> the current type of Wicket plug-in, other than the larger community, of
> course?
Probably just missing the bigger picture of collaboration and re-use. If I
have to do A-Z myself, then nothing is gained. but if A-W is available on a
common market, and I only need to do X, Y & Z myself, we are suddenly in a
totally new position.
Guess if I am excited.... ;o)
Cheers
Niclas
|
|
|
| Re: Webapps based on MVC bundles in OSGI [message #71854 is a reply to message #71835] |
Fri, 12 May 2006 11:30 |
| Eclipse User |
|
|
|
Originally posted by: sa.foroak.gmail.com
Very interesting...
A few questions just to make sure I understand your excitement.
> No it is not light-weight, and IMHO light-weight in itself is nothing
> inherently good. In fact, I would even go as far as saying the "light" vs
> "heavy" is a total misnomer of where the problems lies.
...
> And RSP-UI is all about pluggability. A fairly thin layer of framework to
> gerase the wheels and exposure of the so called Extension Points.
Aren't you contradicting yourself. You say above that it is not
light-weight, but now you say it's a "fairly thin layer of framework".
Which is it?
> Now, once that framework is in place, you can grow that in any way
imaginable,
Which is indeed exciting...
> > Or am I missing something? What do you see as the advantage of this over
> > the current type of Wicket plug-in, other than the larger community, of
> > course?
>
> Probably just missing the bigger picture of collaboration and re-use. If I
> have to do A-Z myself, then nothing is gained. but if A-W is available on a
> common market, and I only need to do X, Y & Z myself, we are suddenly in a
> totally new position.
But (without actually trying it out) it seems that this is a really
complex way of accomplishing this. If it is complex, barrier to entry
will be very high, so not many developers will end up using this. Not
very developers defeats the whole purpose of a system allowing for
re-use, since there won't be much to re-use in the first place!
Don't you think?
> Guess if I am excited.... ;o)
:-)
|
|
|
| Re: Webapps based on MVC bundles in OSGI [message #71864 is a reply to message #71854] |
Fri, 12 May 2006 11:32 |
| Eclipse User |
|
|
|
Originally posted by: sa.foroak.gmail.com
On Friday 12 May 2006 15:08, David Leangen wrote:
> > No it is not light-weight, and IMHO light-weight in itself is nothing
> > inherently good. In fact, I would even go as far as saying the "light" vs
> > "heavy" is a total misnomer of where the problems lies.
>
> ...
>
> > And RSP-UI is all about pluggability. A fairly thin layer of framework to
> > gerase the wheels and exposure of the so called Extension Points.
>
> Aren't you contradicting yourself. You say above that it is not
> light-weight, but now you say it's a "fairly thin layer of framework".
>
> Which is it?
"thin" is very relative. I would say that a OSGi container is fairly thin,
compared to for instance Geronimo. Eclipse RCP is thin compared to Eclipse
IDE, and RSP-UI framework will be relatively thin compared to a
full-fledged
application.
> > > Or am I missing something? What do you see as the advantage of this
> > > over the current type of Wicket plug-in, other than the larger
> > > community, of course?
> >
> > Probably just missing the bigger picture of collaboration and re-use. If
> > I have to do A-Z myself, then nothing is gained. but if A-W is available
> > on a common market, and I only need to do X, Y & Z myself, we are
> > suddenly in a totally new position.
>
> But (without actually trying it out) it seems that this is a really
> complex way of accomplishing this. If it is complex, barrier to entry
> will be very high, so not many developers will end up using this. Not
> very developers defeats the whole purpose of a system allowing for
> re-use, since there won't be much to re-use in the first place!
Just like not many developers will write Eclipse plugins either, yet a
large
number of users is using it. Maven plugins are not written to a large
degree,
because you can normally find what you need, just use it. And RSP-UI will
be
similar. Few people will write the plugins, many will use them.
Cheers
Niclas
|
|
|
| Contributing Tapestry POC to RSP-UI [message #71901 is a reply to message #71609] |
Fri, 12 May 2006 15:16 |
| Eclipse User |
|
|
|
Originally posted by: texas_mustang.yahoo.com
I spent some time developing a proof of concept for Tapestry and RSP-UI for
others to review. I've forwarded the POC directly to Wolfgang Gehner for
possible integration into the sample application.
The POC can be downloaded from here.
http://www.babbleknot.com/stuff/tapestry-rsp-workspaces.zip
The zip file contains two workspaces that can be saved to your
c:\rsp\workspace folder & imported into eclipse. The org.apache.tapestry
plug-in contains the latest tapestry jars & dependencies. The
org.rsp.sample.usage.tapestry plug-in implements the Tapestry "DirectLink"
quick start application. You'll have to add a "link" file to the rsp web app
that references the plug-ins.
A couple of points:
- The tapestry servlet path in app.application is set to account for the
"platform" node.
<meta key="org.apache.tapestry.servlet-path" value="/platform/app"/>
- A servlet that extends org.apache.tapestry.ApplicationServlet is used but
only overrides one method. This helps hivemind & tapestry find everything.
@Override
protected ClassResolver createClassResolver() {
return new DefaultClassResolver(this.getClass().getClassLoader());
}
- We are interested in using RSP-UI in our application framework if it makes
it as a full eclipse project.
I will try to answer questions on the integration, but I am not really a
tapestry expert yet. Enjoy.
Wayne Young
wyoung@metasolv.com
"Wolfgang Gehner" <wgehner@infonoia.com> wrote in message
news:0e1d83e1809a3e3493cb2feca71f915f$1@www.eclipse.org...
> This thread is to discuss the proposal "Rich Server Platform
|
|
|
| Re: Webapps based on MVC bundles in OSGI [message #71922 is a reply to message #71854] |
Fri, 12 May 2006 18:05 |
| Eclipse User |
|
|
|
Originally posted by: giacomin.vettatech.com
----- Original Message -----
From: "Repost: on behalf of David Leangen" <sa.foroak@gmail.com>
Newsgroups: eclipse.technology
Sent: Friday, May 12, 2006 8:30 AM
Subject: Re: Webapps based on MVC bundles in OSGI
> But (without actually trying it out) it seems that this is a really
> complex way of accomplishing this. If it is complex, barrier to entry
> will be very high, so not many developers will end up using this. Not
> very developers defeats the whole purpose of a system allowing for
> re-use, since there won't be much to re-use in the first place!
I second Niclas elaboration when he says there'll be those who will write
plug-ins and those who will use them. The RSP community will certainly
behave just as Eclipse IDE's community. You'll have good free options and
good commercial options (and possibly bad ones as well :-) ).
What really excites me about RSP (besides plug-and-play ability) is the
freedom of choice. RSP is designed to be open in the sense that different
technologies (MVC implementations, presentation engines, backend beans
integration mechanisms) might be wrapped up and put on top of its framework.
You can imagine yourself choosing a Wicket, or Struts, or JSF
implementation, or any other available. Specific technology experts will
certainly contribute to make the range of options broader.
So, I don't think there will be a barrier to entry. Developers will not
necessarly need to learn anything new. They might be able to use their
current expertise in order to write application components.
Regards,
Ricardo Giacomin.
|
|
|
| Re: Contributing Tapestry POC to RSP-UI [message #71961 is a reply to message #71901] |
Sat, 13 May 2006 13:33 |
| Eclipse User |
|
|
|
Hi Wayne,
"Wayne Young" <texas_mustang@yahoo.com> wrote:
>I spent some time developing a proof of concept for Tapestry and RSP-UI for
>others to review. I've forwarded the POC directly to Wolfgang Gehner for
>possible integration into the sample application.
Cool, that should give me some hints regarding some Wicket problems I
have with keeping the redirects in the current views. Will take a look
ASAP!
/peter
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #71982 is a reply to message #71609] |
Tue, 16 May 2006 16:28 |
| Eclipse User |
|
|
|
Originally posted by: weiten.ontoprise.de
We are extremely happy to see this initiative. We build on eclipse RC and
often had the requirement to "port" parts of the functionality to a
server-based solution. Since end of last year we have the requirement for
a systematic approach for a dual strategy sharing important parts of the
infrastucture. RSP-UI seems to be the perfect base. It also solves some
problems that we would have not only from a technical perspective but also
with respect to how we organize the share of work between different teams
(or external partners).
One question we initially have is: In how far would it be possible to
create "unique extension points" on the UI-Level? Let's say I have some
sort of control where an extension point for a certain type of action is
declared. Extensions should be able for both, a RC and a (server-based)
TC. In some cases there is no 1:1 equivalent (due to technical or
usability constraints). Would it still be imaginable to rely on a unique
mechanism to describe UI-related extension points on a more abstract
level? (If for example the RC uses a tree control with a context menue and
the server-based UI has no such control but means to provide the same
functionality).
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #71999 is a reply to message #71609] |
Wed, 17 May 2006 06:06 |
| Eclipse User |
|
|
|
I'm very excited about this project and I believe RSP-UI could deliver
tremendous value to java developers.
The article "Developing Eclipse/OSGi component webapps" that Wolfgang
wrote is a very useful resource to demonstrate integration between OSGI
and Struts. I was wondering have anyone created (or have plans to
create) an example of using OSGI with JSF/Facelets instead of Struts?
Regards,
Petko
|
|
|
| Re: unified extension points on the UI-Level [message #72018 is a reply to message #71982] |
Wed, 17 May 2006 11:34 |
| Eclipse User |
|
|
|
Moritz,
I am glad you like the RSP-UI proposal.
Before I answer your question, I must say that the approach we are using
is to reuse (in any forms) as much existing Eclipse code as possible.
Therefore, before we add a new feature, we first check how it is
implemented in Eclipse in order to see how feasible reuse is. Good news is
that for most of the features we implemented so far (in the code that we
are working on), we have been able to reuse a lot (70-80%).
We used this approach for all RSP-UI action support. In Eclipse, this is
under refactoring right now. A new commands extension point is available
in 3.2. The proposed design is somehow based on MVC, where the M is the
definition of commands, V is how this commands are related to UI parts and
C are key-bindings. This is an interesting approach since you definetely
can use commands (no dependency on UI widgets) in both your thin or rich
client.
Generally speaking, the architecture RSP-UI follows exactly the same as
Eclipse's. So we also have a hierarchy of WorkbenchWindow, WorkbenchPage,
Perspective, Parts (View and Editor parts), and so forth. This contributes
for reuse among RC and TC as well. The only major difference is how views
createPartControl() method will be implemented. If the contents of the
view are produced via PHP script interpretation you'll probably not be
able to define extension points in there. If the part controls are built
using a widget based library, that might be possible.
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #72036 is a reply to message #71609] |
Wed, 17 May 2006 14:02 |
| Eclipse User |
|
|
|
Hi there,
seems Google released a nice toolkit to actually generate the Ajax part of
the UI from Java, too: http://code.google.com/webtoolkit/
Thinking loud, this would be perfect to build RSP on since we then don't
have Javascript laying around but can generate targeted Ajax for what we
need. Check out the samples, seems it could do at least part of what we
need on the client side.
/peter
|
|
|
| GWT Ajax toolkit [message #72055 is a reply to message #72036] |
Wed, 17 May 2006 14:14 |
| Eclipse User |
|
|
|
Hi,
seems a docking framework is not there so this would be a perfect match to
what is already existent in the current demo.
/peter
|
|
|
| Re: GWT Ajax toolkit [message #72072 is a reply to message #72055] |
Wed, 17 May 2006 16:04 |
| Eclipse User |
|
|
|
Hi,
It's pretty interesting, and make part of the hard and dirty work for
client side. There problem I found is that it does not support drag and
drop :(
Wilson
Peter Neubauer wrote:
> Hi,
> seems a docking framework is not there so this would be a perfect match
> to what is already existent in the current demo.
>
> /peter
>
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #72087 is a reply to message #71609] |
Thu, 18 May 2006 13:41 |
| Eclipse User |
|
|
|
Originally posted by: mhoram.clandlan.net
Is a great idea, the presentation layer in webapps is allways a headhache,
sometimes you need Velocity, others html, ajax, jsp... andf change between
one and another is dificult even with MVC.
With this framework and OSGi we will be closer to a truly really plugable
WebApp, first was MVC, then OSGi now this, this may become future ;)
Thanks for the project, it will be a great sucess i hope
|
|
|
| Re: RSP-UI and JSF/Facelets [message #72104 is a reply to message #71999] |
Fri, 19 May 2006 13:02 |
| Eclipse User |
|
|
|
Petko,<p>
Exadel has done JSF work in relation to Eclipse/OSGi. It is part of their
proposal to the Eclipse foundation named "Enterprise Component
Framework/Platform (ECP)".<p>
RSP-UI aims to integrate with ECP at UI level, allowing to combine JSF-
and non-JSF rendering technologies in unified interfaces (much like Tiles
and Facelets, but not limited to Struts/JSP and JSF).<p>
We hope that the valuable work by Exadel will be accepted as an Eclipse
project, as JSF is a natural choice for fine-grained UI widgets on the
server (so is Wicket, of course).<p>
As a fallback, RSP-UI *may* create a JSF implementation of SWT components
for the server-side. John R. Fallows, co-author of "Pro JSF and AJAX", is
RSP-UI committer.<p>
If you are looking for other non-JSF implementations for fine-grained
server-side widgets, you may also look at W4T, which is subject of the
Rich Ajax Platform proposal (and we have scheduled to investigate merging
with in about 9 months).<p>
We believe that for RSP-UI and server-side Eclipse in general to be
successful, it needs to integrate with existing server-side approaches,
page-based (such as JSP), script-based (such as PHP and OpenLaszlo) and
UI-component-based (such as JSF and Wicket).<p>
For certain applications, some people may prefer page- or script-based
approaches over fine-grained components because they may feel that these
create less object overhead and thus may respond better under load (as in
thousands of simultaneous users). We integrate classic web approaches
partly because they have stood the proof of scalability.<p>
What RSP-UI does have in scope today is an implementation of the Workbench
API for constructing perspectives, views, editors etc.
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #72282 is a reply to message #71609] |
Sat, 27 May 2006 07:23 |
| Eclipse User |
|
|
|
Originally posted by: alfred.seiler.freesurf.ch
For SOA to become more widespread and useful, it will not just be about
normalizing inter-service messaging: the emerging mulitude of
(proprietory and open) stacks will be a major obstacle and any 'neutral'
abstraction layer with the potential of becoming a de-facto standard would
be a blessing. If it happend on the client side, ....
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #72300 is a reply to message #71609] |
Sun, 28 May 2006 15:31 |
| Eclipse User |
|
|
|
Originally posted by: alfred.seiler.freesurf.ch
For SOA to really take off it's not just a matter of standardized
messaging. Moreover, in view of the flurry of (commercial and open) stacks
in pipelines, any neutral, widely accepted abstraction layer facilitating
the re-use also of code should be a blessing for those who struggle to
survive all this diversity. If it was possible on the client ... it would
certainly seem worthwhile a try on the server.
|
|
|
| Wicket support for RSP-UI [message #72440 is a reply to message #71609] |
Mon, 05 June 2006 17:56 |
| Eclipse User |
|
|
|
Originally posted by: eelco12.SPAM.users.sf.net
Hello all,
We (core developers of Wicket) are exited to see that Wicket will be one
of the supported technologies for RSP-UI. We are committed to ensuring
that Wicket plays well with OSGi - in fact some of the earliest webapps
build with Wicket that I know of were utilizing OSGi - and I hereby like
to express that we are ready to actively support integrating Wicket
with RSP-UI. Typically, that will happen through supporting the people that
working on this in the scope of this initiative: Niclas Hedhman, Makas
Lau and Peter Neubauer.
Thanks and I'm looking forward to play around with RSP-UI!
Eelco Hillenius
|
|
|
| Pde for equinox.http, rsp based on web tools. [message #73056 is a reply to message #71609] |
Thu, 20 July 2006 00:28 |
| Eclipse User |
|
|
|
Originally posted by: weizhang.zdsoft.com.cn
Hi,
Since I found no pde plugin for equinox.http, I tried to make one.
It's based on equinox pde and web tools plugins.
It's sort of like equinox launch configuration + web server launch
configuration.
To use it, you should
1. install the plugin in it, restart eclipse with -clean.
2. set the web tools up (get server runtime and server ready), add a new web
project, import the equinox war in it.
3. import other equinox http plugins (org.eclipse.equinox.http.registry,
org.eclipse.equinox.servlet.api,org.eclipse.equinox.servlet. bridge.http,org.eclipse.equinox.servlet.bridge.launcher),
and make your own plugins (sample.http, sample.http.registry). You can use
the workspace in the archive.
4. make a new launch configuration under equinox http. set the arguments
(maybe you should clear the -console parameter, or it won't stop when you
stop your server. but with -console, you can use equinox console.).
5. launch it (debug or run).
It will make a tomcat server launch configuration (like you start a server),
it seems that you should add
(-Dorg.eclipse.equinox.servlet.bridge.enabled=true) in the vm arguments
section for org.eclipse.equinox.servlet.bridge.http plugin to action.
You can use it as normal pde, like debugging, selecting what plugins to
launch, etc..
It works like following:
It contains 2 parts. One part is a plugin which adds a new equinox http
launch configuration. The configuration is an equinox launch configuration
with an additional wtp server selection tab. It uses the equinox launch
configuration to gather launch parameters (vm parameters and application
parameters), save it to a temp file, use web tools to launch a server.
The other part is a dynamic web project named equinox. It uses the equinox
launch configuration parameters in the temp file to launch the framework.
Play with it, if you have problem or questions, just follow this thread.
(Sorry for my English.:().
John Wilson.
|
|
| |
| Re: RSP-UI Proposal Discussion Thread [message #73184 is a reply to message #71609] |
Wed, 02 August 2006 23:56 |
| Eclipse User |
|
|
|
Originally posted by: ltran.serena.com
Hi all,
I read the Timing section of the RSP proposal and found out that a demo
application integrating JSP/JSTL, Struts and Wicket should be available
last July. Does anyone know as to where we can download the demo? Thanks
a lot.
Luan
|
|
| | |
| Re: RSP-UI Proposal Discussion Thread [message #74320 is a reply to message #71609] |
Fri, 23 February 2007 05:35 |
| Eclipse User |
|
|
|
Originally posted by: reiern.isencia.com
Hi,
Very interesting proposal indeed! I also read the article at Infonoia
and played with the sample application.
Just a couple of questions:
- Are there any tools in development? I downloaded the source code of
the plug-in contributed by John Wilson and I see there is also a version
of the plug-in at the sample application. Are they the same? I can't
compare them myself because the one distributed with sample application
doesn't contain the source code.
- Will those tools be freely available?
- Can one contribute code?
Best regards,
Ernesto
Wolfgang Gehner wrote:
> This thread is to discuss the proposal "Rich Server Platform ? User
> Interface Framework (RSP-UI)" and any technical questions it raises at
> http://www.eclipse.org/proposals/rsp/
>
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #600244 is a reply to message #71609] |
Mon, 08 May 2006 16:08 |
| Eclipse User |
|
|
|
I am very excited to see that this project is now official. This is an
ambitious project that will require a tremendous amount of hard work to
get it right.
I'll be closely watching this project and if there is anything OSGi
related that I can help with, I will. Do not hesitate to contact me with
an OSGi related questions.
Kind regards,
Peter Kriens
|
|
| |
| Re: RSP-UI Proposal Discussion Thread [message #600258 is a reply to message #71609] |
Tue, 09 May 2006 12:48 |
| Eclipse User |
|
|
|
Nice to see that it has made its way to Eclipse. I first saw these ideas in
javalobby. I've tried the example, and it worked well.
I had tried some similar ideas (like having extendable on actions) one year
ago, but failed with class loading issues within web containers. So it's
very nice to see a working example.
My interests are on tapestry integration and some basic UI frameworks(like
the menu, view, editor parts eclipse workbench provides)
Anyway, good ideas. looking forward to seeing a usable version ASAP.
Regards.
John Wilson
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #600265 is a reply to message #71647] |
Tue, 09 May 2006 18:19 |
| Eclipse User |
|
|
|
Hi all,
small update - now JSPs are compiling with the OSXA bundles from within
Eclipse. Main thing to sort out is the URL differences between running
the current scenarion under the servlet bridge in Tomcat (everything has
localhost/bridge/..... as root) as opposed to running directly on Jetty
(localhost/...), since many redirects, resource paths etc are
"hardcoded" into the servlets/jsps/views.
After sorting that out, we should be able to update the quickstart doc
with a "run directly from within PDE" section.
/peter
--
|
|
|
| RSP-UI and RCP integration [message #600270 is a reply to message #71609] |
Wed, 10 May 2006 23:09 |
| Eclipse User |
|
|
|
Hi!
I'm wondering what the community thinks if RSP should also provide code
to automatde the communcation between RCP and server side components?
For example, the JFace Databinding Framework is supposed to work to bind
data from a server to components on a client. I wonder if RSP should
also elaborate into this?
What does the community think about this?
Cu, Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #600289 is a reply to message #71628] |
Thu, 11 May 2006 14:16 |
| Eclipse User |
|
|
|
Originally posted by: sa.foroak.gmail.com
I have spent a lot of time "googling", looking for a way to develop
webapps following the MVC philosophy (if possible with different bundles
for view, model and logic) within an OSGI platform. And I hope this
project will lead me towards the solution!
As I have read in FAQ section (http://www.eclipse.org/proposals/rsp/),
"RSP-UI does not depend on particular OSGi container features beyond those
specified by applicable OSGi release levels"... So I guess it should be
strictly OSGI-conform (R4), and could be also used in other OSGI platforms
as Felix (http://incubator.apache.org/felix/) or Knopflerfish
(http://www.knopflerfish.org/). As Peter Kriens said in
http://www.quicktopic.com/35/H/7MDmdSANAr8e, "I would highly appreciate it
if it was an OSGi targeted project and not an Eclipse targeted project".
Anyway, I think this project is a great contribution.
Best regards,
Saioa
|
|
|
| Re: RSP-UI and RCP integration [message #600325 is a reply to message #71701] |
Fri, 12 May 2006 09:24 |
| Eclipse User |
|
|
|
Gunnar Wagenknecht wrote:
> Hi!
>
> I'm wondering what the community thinks if RSP should also provide code
> to automatde the communcation between RCP and server side components?
>
> For example, the JFace Databinding Framework is supposed to work to bind
> data from a server to components on a client. I wonder if RSP should
> also elaborate into this?
>
> What does the community think about this?
Personally, I think this will happen eventually, but the time frame is
unknown at the moment.
Cheers
Niclas
|
|
|
| Webapps based on MVC bundles in OSGI [message #600338 is a reply to message #71609] |
Fri, 12 May 2006 11:25 |
| Eclipse User |
|
|
|
Originally posted by: sa.foroak.gmail.com
Hi,
I am just reposting a thread that started in general mailing list in
OSP4J, as it is RSP-UI related.
On Thu, 2006-05-11 at 17:18 +0800, Niclas Hedhman wrote:
> On Thursday 11 May 2006 16:39, Saioa Arrizabalaga wrote:
> > Hi!
> > I am looking for a way to develop webapps in OSGI platform following
> > the MVC philosophy, if possible separating bundles for model, view and
> > logic.
> > I have only found two approaches:
> > The first one, an article writen by Wolfang Gehner where Eclipse +
> > Struts are used (http://www.infonoia.com/en/content.jsp?d=inf.05.09),
> > but I am afraid it will be too heavy for our requisites.
> > The second one, the wicket-dynamic project in ops4j, but the project
> > main page ( http://wiki.ops4j.org/dokuwiki/doku.php?id=pax:wicket-dynami c)
> > is uncomplete. Does anyone know what the status of this project is or
> > if there is any plan to keep on its development?
>
> First of all, Welcome to OPS4J...
>
> The Pax Wicket stuff will be folded into the RSP-UI project which Wolgang has
> been driving hard to get started.
> http://www.eclipse.org/proposals/rsp
>
> And if you think this is a good proposal, please express that on the Eclipse
> Technology newsgroup. You have a web access to that over
> http://www.eclipse.org/newsportal/thread.php?group=eclipse.t echnology
>
>
> What we have done so far with Wicket in an OSGi environment, is that
> additional bundles can add and remove "tabs" to a main page, which defines
> the general setup of that page. This is done in a commercial environment, and
> we have not been quick enough to update the Wiki with the findings. I hope
> I'll get to that eventually.
>
>
> Cheers
> Niclas
>
> _______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general
On Friday 12 May 2006 09:12, David Leangen wrote:
Although very interesting, this approach does not strike me as being
very light-weight. Maybe something like EJB3?
Or am I missing something? What do you see as the advantage of this over
the current type of Wicket plug-in, other than the larger community, of
course?
|
|
|
| Re: Webapps based on MVC bundles in OSGI [message #600350 is a reply to message #71816] |
Fri, 12 May 2006 11:27 |
| Eclipse User |
|
|
|
Originally posted by: sa.foroak.gmail.com
On Friday 12 May 2006 09:12, David Leangen wrote:
> Although very interesting, this approach does not strike me as being
> very light-weight. Maybe something like EJB3?
No it is not light-weight, and IMHO light-weight in itself is nothing
inherently good. In fact, I would even go as far as saying the "light" vs
"heavy" is a total misnomer of where the problems lies.
The traditional definition seems to suggest that just because something is
big, then it is of no use. In some cases, less functionality is seen as
better. But why is that perception prevailing??
I think it has nothing to do with the size of anything. I don't even think
it
is related to how tightly bound you get to a particular system.
What it thrives upon is the classic coupling between "monolithic" and
"large".
Monolithic applications are indeed inherently bad. And the opposite is the
"plug in architecture" which is what we come to love, in many forms;
Spring,
Eclipse, Pico and so forth.
And RSP-UI is all about pluggability. A fairly thin layer of framework to
gerase the wheels and exposure of the so called Extension Points. RSP-UI
draws upon the experience from the Eclipse Rich Client Platform, to get a
head start in what will be needed, but adopt that for a server environment,
which can not assume the single user envirnoment of Eclipse itself.
Now, once that framework is in place, you can grow that in any way
imaginable,
the same way as RCP is used both for Java IDE as well as cash machine
terminal, and hundreds of other totally different application types.
RSP-UI will allow you to make small plug-ins which is part of a larger
system.
Component-based server development (at last!) with the potential of a true
plug-n-play component market, much like the Eclipse platform is.
The initial effort is to allow the web application community at large to
re-use existing solutions, and wrap them into components for a rapid
growth.
But I predict the components will slowly become smaller, more dedicated and
more suitable for re-use.
> Or am I missing something? What do you see as the advantage of this over
> the current type of Wicket plug-in, other than the larger community, of
> course?
Probably just missing the bigger picture of collaboration and re-use. If I
have to do A-Z myself, then nothing is gained. but if A-W is available on a
common market, and I only need to do X, Y & Z myself, we are suddenly in a
totally new position.
Guess if I am excited.... ;o)
Cheers
Niclas
|
|
|
| Re: Webapps based on MVC bundles in OSGI [message #600365 is a reply to message #71835] |
Fri, 12 May 2006 11:30 |
| Eclipse User |
|
|
|
Originally posted by: sa.foroak.gmail.com
Very interesting...
A few questions just to make sure I understand your excitement.
> No it is not light-weight, and IMHO light-weight in itself is nothing
> inherently good. In fact, I would even go as far as saying the "light" vs
> "heavy" is a total misnomer of where the problems lies.
...
> And RSP-UI is all about pluggability. A fairly thin layer of framework to
> gerase the wheels and exposure of the so called Extension Points.
Aren't you contradicting yourself. You say above that it is not
light-weight, but now you say it's a "fairly thin layer of framework".
Which is it?
> Now, once that framework is in place, you can grow that in any way
imaginable,
Which is indeed exciting...
> > Or am I missing something? What do you see as the advantage of this over
> > the current type of Wicket plug-in, other than the larger community, of
> > course?
>
> Probably just missing the bigger picture of collaboration and re-use. If I
> have to do A-Z myself, then nothing is gained. but if A-W is available on a
> common market, and I only need to do X, Y & Z myself, we are suddenly in a
> totally new position.
But (without actually trying it out) it seems that this is a really
complex way of accomplishing this. If it is complex, barrier to entry
will be very high, so not many developers will end up using this. Not
very developers defeats the whole purpose of a system allowing for
re-use, since there won't be much to re-use in the first place!
Don't you think?
> Guess if I am excited.... ;o)
:-)
|
|
|
| Re: Webapps based on MVC bundles in OSGI [message #600375 is a reply to message #71854] |
Fri, 12 May 2006 11:32 |
| Eclipse User |
|
|
|
Originally posted by: sa.foroak.gmail.com
On Friday 12 May 2006 15:08, David Leangen wrote:
> > No it is not light-weight, and IMHO light-weight in itself is nothing
> > inherently good. In fact, I would even go as far as saying the "light" vs
> > "heavy" is a total misnomer of where the problems lies.
>
> ...
>
> > And RSP-UI is all about pluggability. A fairly thin layer of framework to
> > gerase the wheels and exposure of the so called Extension Points.
>
> Aren't you contradicting yourself. You say above that it is not
> light-weight, but now you say it's a "fairly thin layer of framework".
>
> Which is it?
"thin" is very relative. I would say that a OSGi container is fairly thin,
compared to for instance Geronimo. Eclipse RCP is thin compared to Eclipse
IDE, and RSP-UI framework will be relatively thin compared to a
full-fledged
application.
> > > Or am I missing something? What do you see as the advantage of this
> > > over the current type of Wicket plug-in, other than the larger
> > > community, of course?
> >
> > Probably just missing the bigger picture of collaboration and re-use. If
> > I have to do A-Z myself, then nothing is gained. but if A-W is available
> > on a common market, and I only need to do X, Y & Z myself, we are
> > suddenly in a totally new position.
>
> But (without actually trying it out) it seems that this is a really
> complex way of accomplishing this. If it is complex, barrier to entry
> will be very high, so not many developers will end up using this. Not
> very developers defeats the whole purpose of a system allowing for
> re-use, since there won't be much to re-use in the first place!
Just like not many developers will write Eclipse plugins either, yet a
large
number of users is using it. Maven plugins are not written to a large
degree,
because you can normally find what you need, just use it. And RSP-UI will
be
similar. Few people will write the plugins, many will use them.
Cheers
Niclas
|
|
|
| Contributing Tapestry POC to RSP-UI [message #600403 is a reply to message #71609] |
Fri, 12 May 2006 15:16 |
| Eclipse User |
|
|
|
I spent some time developing a proof of concept for Tapestry and RSP-UI for
others to review. I've forwarded the POC directly to Wolfgang Gehner for
possible integration into the sample application.
The POC can be downloaded from here.
http://www.babbleknot.com/stuff/tapestry-rsp-workspaces.zip
The zip file contains two workspaces that can be saved to your
c:\rsp\workspace folder & imported into eclipse. The org.apache.tapestry
plug-in contains the latest tapestry jars & dependencies. The
org.rsp.sample.usage.tapestry plug-in implements the Tapestry "DirectLink"
quick start application. You'll have to add a "link" file to the rsp web app
that references the plug-ins.
A couple of points:
- The tapestry servlet path in app.application is set to account for the
"platform" node.
<meta key="org.apache.tapestry.servlet-path" value="/platform/app"/>
- A servlet that extends org.apache.tapestry.ApplicationServlet is used but
only overrides one method. This helps hivemind & tapestry find everything.
@Override
protected ClassResolver createClassResolver() {
return new DefaultClassResolver(this.getClass().getClassLoader());
}
- We are interested in using RSP-UI in our application framework if it makes
it as a full eclipse project.
I will try to answer questions on the integration, but I am not really a
tapestry expert yet. Enjoy.
Wayne Young
wyoung@metasolv.com
"Wolfgang Gehner" <wgehner@infonoia.com> wrote in message
news:0e1d83e1809a3e3493cb2feca71f915f$1@www.eclipse.org...
> This thread is to discuss the proposal "Rich Server Platform
|
|
|
| Re: Webapps based on MVC bundles in OSGI [message #600412 is a reply to message #71854] |
Fri, 12 May 2006 18:05 |
| Eclipse User |
|
|
|
Originally posted by: giacomin.vettatech.com
----- Original Message -----
From: "Repost: on behalf of David Leangen" <sa.foroak@gmail.com>
Newsgroups: eclipse.technology
Sent: Friday, May 12, 2006 8:30 AM
Subject: Re: Webapps based on MVC bundles in OSGI
> But (without actually trying it out) it seems that this is a really
> complex way of accomplishing this. If it is complex, barrier to entry
> will be very high, so not many developers will end up using this. Not
> very developers defeats the whole purpose of a system allowing for
> re-use, since there won't be much to re-use in the first place!
I second Niclas elaboration when he says there'll be those who will write
plug-ins and those who will use them. The RSP community will certainly
behave just as Eclipse IDE's community. You'll have good free options and
good commercial options (and possibly bad ones as well :-) ).
What really excites me about RSP (besides plug-and-play ability) is the
freedom of choice. RSP is designed to be open in the sense that different
technologies (MVC implementations, presentation engines, backend beans
integration mechanisms) might be wrapped up and put on top of its framework.
You can imagine yourself choosing a Wicket, or Struts, or JSF
implementation, or any other available. Specific technology experts will
certainly contribute to make the range of options broader.
So, I don't think there will be a barrier to entry. Developers will not
necessarly need to learn anything new. They might be able to use their
current expertise in order to write application components.
Regards,
Ricardo Giacomin.
|
|
|
| Re: Contributing Tapestry POC to RSP-UI [message #600426 is a reply to message #71901] |
Sat, 13 May 2006 13:33 |
| Eclipse User |
|
|
|
Hi Wayne,
"Wayne Young" <texas_mustang@yahoo.com> wrote:
>I spent some time developing a proof of concept for Tapestry and RSP-UI for
>others to review. I've forwarded the POC directly to Wolfgang Gehner for
>possible integration into the sample application.
Cool, that should give me some hints regarding some Wicket problems I
have with keeping the redirects in the current views. Will take a look
ASAP!
/peter
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #600435 is a reply to message #71609] |
Tue, 16 May 2006 16:28 |
| Eclipse User |
|
|
|
Originally posted by: weiten.ontoprise.de
We are extremely happy to see this initiative. We build on eclipse RC and
often had the requirement to "port" parts of the functionality to a
server-based solution. Since end of last year we have the requirement for
a systematic approach for a dual strategy sharing important parts of the
infrastucture. RSP-UI seems to be the perfect base. It also solves some
problems that we would have not only from a technical perspective but also
with respect to how we organize the share of work between different teams
(or external partners).
One question we initially have is: In how far would it be possible to
create "unique extension points" on the UI-Level? Let's say I have some
sort of control where an extension point for a certain type of action is
declared. Extensions should be able for both, a RC and a (server-based)
TC. In some cases there is no 1:1 equivalent (due to technical or
usability constraints). Would it still be imaginable to rely on a unique
mechanism to describe UI-related extension points on a more abstract
level? (If for example the RC uses a tree control with a context menue and
the server-based UI has no such control but means to provide the same
functionality).
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #600442 is a reply to message #71609] |
Wed, 17 May 2006 06:06 |
| Eclipse User |
|
|
|
I'm very excited about this project and I believe RSP-UI could deliver
tremendous value to java developers.
The article "Developing Eclipse/OSGi component webapps" that Wolfgang
wrote is a very useful resource to demonstrate integration between OSGI
and Struts. I was wondering have anyone created (or have plans to
create) an example of using OSGI with JSF/Facelets instead of Struts?
Regards,
Petko
|
|
|
| Re: unified extension points on the UI-Level [message #600445 is a reply to message #71982] |
Wed, 17 May 2006 11:34 |
| Eclipse User |
|
|
|
Moritz,
I am glad you like the RSP-UI proposal.
Before I answer your question, I must say that the approach we are using
is to reuse (in any forms) as much existing Eclipse code as possible.
Therefore, before we add a new feature, we first check how it is
implemented in Eclipse in order to see how feasible reuse is. Good news is
that for most of the features we implemented so far (in the code that we
are working on), we have been able to reuse a lot (70-80%).
We used this approach for all RSP-UI action support. In Eclipse, this is
under refactoring right now. A new commands extension point is available
in 3.2. The proposed design is somehow based on MVC, where the M is the
definition of commands, V is how this commands are related to UI parts and
C are key-bindings. This is an interesting approach since you definetely
can use commands (no dependency on UI widgets) in both your thin or rich
client.
Generally speaking, the architecture RSP-UI follows exactly the same as
Eclipse's. So we also have a hierarchy of WorkbenchWindow, WorkbenchPage,
Perspective, Parts (View and Editor parts), and so forth. This contributes
for reuse among RC and TC as well. The only major difference is how views
createPartControl() method will be implemented. If the contents of the
view are produced via PHP script interpretation you'll probably not be
able to define extension points in there. If the part controls are built
using a widget based library, that might be possible.
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #600453 is a reply to message #71609] |
Wed, 17 May 2006 14:02 |
| Eclipse User |
|
|
|
Hi there,
seems Google released a nice toolkit to actually generate the Ajax part of
the UI from Java, too: http://code.google.com/webtoolkit/
Thinking loud, this would be perfect to build RSP on since we then don't
have Javascript laying around but can generate targeted Ajax for what we
need. Check out the samples, seems it could do at least part of what we
need on the client side.
/peter
|
|
|
| GWT Ajax toolkit [message #600459 is a reply to message #72036] |
Wed, 17 May 2006 14:14 |
| Eclipse User |
|
|
|
Hi,
seems a docking framework is not there so this would be a perfect match to
what is already existent in the current demo.
/peter
|
|
|
| Re: GWT Ajax toolkit [message #600472 is a reply to message #72055] |
Wed, 17 May 2006 16:04 |
| Eclipse User |
|
|
|
Hi,
It's pretty interesting, and make part of the hard and dirty work for
client side. There problem I found is that it does not support drag and
drop :(
Wilson
Peter Neubauer wrote:
> Hi,
> seems a docking framework is not there so this would be a perfect match
> to what is already existent in the current demo.
>
> /peter
>
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #600480 is a reply to message #71609] |
Thu, 18 May 2006 13:41 |
| Eclipse User |
|
|
|
Originally posted by: mhoram.clandlan.net
Is a great idea, the presentation layer in webapps is allways a headhache,
sometimes you need Velocity, others html, ajax, jsp... andf change between
one and another is dificult even with MVC.
With this framework and OSGi we will be closer to a truly really plugable
WebApp, first was MVC, then OSGi now this, this may become future ;)
Thanks for the project, it will be a great sucess i hope
|
|
|
| Re: RSP-UI and JSF/Facelets [message #600486 is a reply to message #71999] |
Fri, 19 May 2006 13:02 |
| Eclipse User |
|
|
|
Petko,<p>
Exadel has done JSF work in relation to Eclipse/OSGi. It is part of their
proposal to the Eclipse foundation named "Enterprise Component
Framework/Platform (ECP)".<p>
RSP-UI aims to integrate with ECP at UI level, allowing to combine JSF-
and non-JSF rendering technologies in unified interfaces (much like Tiles
and Facelets, but not limited to Struts/JSP and JSF).<p>
We hope that the valuable work by Exadel will be accepted as an Eclipse
project, as JSF is a natural choice for fine-grained UI widgets on the
server (so is Wicket, of course).<p>
As a fallback, RSP-UI *may* create a JSF implementation of SWT components
for the server-side. John R. Fallows, co-author of "Pro JSF and AJAX", is
RSP-UI committer.<p>
If you are looking for other non-JSF implementations for fine-grained
server-side widgets, you may also look at W4T, which is subject of the
Rich Ajax Platform proposal (and we have scheduled to investigate merging
with in about 9 months).<p>
We believe that for RSP-UI and server-side Eclipse in general to be
successful, it needs to integrate with existing server-side approaches,
page-based (such as JSP), script-based (such as PHP and OpenLaszlo) and
UI-component-based (such as JSF and Wicket).<p>
For certain applications, some people may prefer page- or script-based
approaches over fine-grained components because they may feel that these
create less object overhead and thus may respond better under load (as in
thousands of simultaneous users). We integrate classic web approaches
partly because they have stood the proof of scalability.<p>
What RSP-UI does have in scope today is an implementation of the Workbench
API for constructing perspectives, views, editors etc.
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #600585 is a reply to message #71609] |
Sat, 27 May 2006 07:23 |
| Eclipse User |
|
|
|
Originally posted by: alfred.seiler.freesurf.ch
For SOA to become more widespread and useful, it will not just be about
normalizing inter-service messaging: the emerging mulitude of
(proprietory and open) stacks will be a major obstacle and any 'neutral'
abstraction layer with the potential of becoming a de-facto standard would
be a blessing. If it happend on the client side, ....
|
|
|
| Re: RSP-UI Proposal Discussion Thread [message #600596 is a reply to message #71609] |
Sun, 28 May 2006 15:31 |
| Eclipse User |
|
|
|
Originally posted by: alfred.seiler.freesurf.ch
For SOA to really take off it's not just a matter of standardized
messaging. Moreover, in view of the flurry of (commercial and open) stacks
in pipelines, any neutral, widely accepted abstraction layer facilitating
the re-use also of code should be a blessing for those who struggle to
survive all this diversity. If it was possible on the client ... it would
certainly seem worthwhile a try on the server.
|
|
|
| Wicket support for RSP-UI [message #600666 is a reply to message #71609] |
Mon, 05 June 2006 17:56 |
| Eclipse User |
|
|
|
Hello all,
We (core developers of Wicket) are exited to see that Wicket will be one
of the supported technologies for RSP-UI. We are committed to ensuring
that Wicket plays well with OSGi - in fact some of the earliest webapps
build with Wicket that I know of were utilizing OSGi - and I hereby like
to express that we are ready to actively support integrating Wicket
with RSP-UI. Typically, that will happen through supporting the people that
working on this in the scope of this initiative: Niclas Hedhman, Makas
Lau and Peter Neubauer.
Thanks and I'm looking forward to play around with RSP-UI!
Eelco Hillenius
|
|
|
| Pde for equinox.http, rsp based on web tools. [message #600911 is a reply to message #71609] |
Thu, 20 July 2006 00:28 |
| Eclipse User |
|
|
|
Hi,
Since I found no pde plugin for equinox.http, I tried to make one.
It's based on equinox pde and web tools plugins.
It's sort of like equinox launch configuration + web server launch
configuration.
To use it, you should
1. install the plugin in it, restart eclipse with -clean.
2. set the web tools up (get server runtime and server ready), add a new web
project, import the equinox war in it.
3. import other equinox http plugins (org.eclipse.equinox.http.registry,
org.eclipse.equinox.servlet.api,org.eclipse.equinox.servlet. bridge.http,org.eclipse.equinox.servlet.bridge.launcher),
and make your own plugins (sample.http, sample.http.registry). You can use
the workspace in the archive.
4. make a new launch configuration under equinox http. set the arguments
(maybe you should clear the -console parameter, or it won't stop when you
stop your server. but with -console, you can use equinox console.).
5. launch it (debug or run).
It will make a tomcat server launch configuration (like you start a server),
it seems that you should add
(-Dorg.eclipse.equinox.servlet.bridge.enabled=true) in the vm arguments
section for org.eclipse.equinox.servlet.bridge.http plugin to action.
You can use it as normal pde, like debugging, selecting what plugins to
launch, etc..
It works like following:
It contains 2 parts. One part is a plugin which adds a new equinox http
launch configuration. The configuration is an equinox launch configuration
with an additional wtp server selection tab. It uses the equinox launch
configuration to gather launch parameters (vm parameters and application
parameters), save it to a temp file, use web tools to launch a server.
The other part is a dynamic web project named equinox. It uses the equinox
launch configuration parameters in the temp file to launch the framework.
Play with it, if you have problem or questions, just follow this thread.
(Sorry for my English.:().
John Wilson.
|
|
| |
| Re: RSP-UI Proposal Discussion Thread [message #600956 is a reply to message #71609] |
Wed, 02 August 2006 23:56 |
| Eclipse User |
|
|
|
Originally posted by: ltran.serena.com
Hi all,
I read the Timing section of the RSP proposal and found out that a demo
application integrating JSP/JSTL, Struts and Wicket should be available
last July. Does anyone know as to where we can download the demo? Thanks
a lot.
Luan
|
|
| | |
| Re: RSP-UI Proposal Discussion Thread [message #601371 is a reply to message #71609] |
Fri, 23 February 2007 05:35 |
| Eclipse User |
|
|
|
Hi,
Very interesting proposal indeed! I also read the article at Infonoia
and played with the sample application.
Just a couple of questions:
- Are there any tools in development? I downloaded the source code of
the plug-in contributed by John Wilson and I see there is also a version
of the plug-in at the sample application. Are they the same? I can't
compare them myself because the one distributed with sample application
doesn't contain the source code.
- Will those tools be freely available?
- Can one contribute code?
Best regards,
Ernesto
Wolfgang Gehner wrote:
> This thread is to discuss the proposal "Rich Server Platform ? User
> Interface Framework (RSP-UI)" and any technical questions it raises at
> http://www.eclipse.org/proposals/rsp/
>
|
|
|
Goto Forum:
Current Time: Sun Feb 09 15:25:00 GMT 2025
Powered by FUDForum. Page generated in 0.08916 seconds |
] 
Search
Help
Register
Login
Home
