Re: Encoding problem

[Endre Stølsvik]

On Fri, 4 Jun 2004, Thomas Grundey wrote:

| Hi,
| I had the same problem.
|
| It happend when a user entered umlauts (äöü) into a HTML input field. The
| portlet stores the strings in a database.
| Each umlaut is encoded with 2 bytes.
| Setting the charset to ISO-8859-1 in media.xreg solved the problem
| Thanks

Try chinese.

Endre


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Encoding problem

[Endre Stølsvik]

On Thu, 3 Jun 2004, Floßmann Christoph wrote:

| Hi folks!
|
| The jetspeed default encoding is UTF-8 what causes some problems with my portlets 
(here in Germany we use some letters like üöä)

utf-8 does most definately support those letters - it is "much better"
than "latin-1" (iso8859-1).

Use a proper editor that has the capability to save files as utf-8 (as
saving in latin1 then reading with utf8 "decoding" will surely mess up
your data), and your problem will be solved..

-- 
Mvh,
Endre Stølsvik   M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Does anyone know how to send data from one portlet to another?

[Endre Stølsvik]

On Tue, 18 May 2004, alex wrote:

| This is what I want to do: have a list on a portlet, when the user clicks on
| an item (maybe an URL) I want to display the resultant output in another
| portlet. Any ideas???

Use session, scoped at the application level. When the action occurs, you
shove the new info into the session, then when the rendering occurs, that
info is available to all portlets.

.. or you can use a shared outside resource, like a database.

Ah.. btw, the first answer goes for JSR 168 Portlets. I have pretty much
no idea of how you do this with the Jetspeed 1 portlets.


-- 
Mvh,
Endre Stølsvik   M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: MS exchange OWA and jetspeed

[Endre Stølsvik]

On Wed, 25 Feb 2004, Sezmillenium wrote:

| Thanks,
| But, i want connect with java code and i want manage the information
| to separete everything in a differents portlets... I think that I need
| create some classes to work with this information. Somebody know another
| solution?

You're in for a treat!

If you come up with something, PLEASE let me know!

Here are a couple of hints along the way: Jacob, Jawin, JIntegra
(commercial). Those are (D)COM bridges.

Endre


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: MS exchange OWA and jetspeed

[Endre Stølsvik]

On Wed, 25 Feb 2004, Sez Sez wrote:

| Hi,
|
| I am working with a project and i must connect to ms
| exchange owa. Any ideas?

Use frames..

IE's NTLM "silent login"/"single sign-on" will do the trick if they're
already on their own domain, logged in on a NT/2000/XP box. Or else you
have a slight problem, as the browser will pop up a password box. We've
"solved" this using some smartness, where we assume that the user will
"silent login-in" automatically if he is on an internal network (typicall
10.x.x.x and some others), and that this won't work if he's outside of
this, thus the password have been included using the @: url-trick (which
isn't supported by IE anymore).

Hope this is of some interest..

Endre


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jetspeed2 planning

[Endre Stølsvik]

On Tue, 30 Sep 2003, Endre Stølsvik wrote:

| Apache is very wary of accepting any project - it should have a community
| and blah blah and whatnot. Why should it suddenly become so extremely
| thankful for -IBM- "donating" some piece of software?!  One -could-
| imagine that they were just "going for the feather", instead of sincerly
| aiming for a true open source development process and community.

And btw, you have "The Incubator" (read it with the low film-preview
voice like "Tha' Terminator")..

This is from a slightly heated discussion on "general incubator":

http://www.mail-archive.com/general%40incubator.apache.org/msg01701.html
  "new code coming in to the asf comes through the incubator.  period."

http://www.mail-archive.com/general%40incubator.apache.org/msg01693.html
  "and i believe the board will take a very, very dim view of any tlp
that tries to do an end-run around this by bringing in an outside
group of people and then subsequently importing their codebase."


Endre.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jetspeed2 planning

[Endre Stølsvik]

On Mon, 29 Sep 2003, Serge Huber wrote:

|
| I'll second that, thanks David and Scott for taking the time to answer our
| frustrations over and over :) I've been lurking a bit since I'm very busy
| at work with an upcoming product release, but I see the same question
| coming over and over about when will Pluto finally be delivered and I'm
| still surprised nobody has landed a replacement by now :) If somebody did
| maybe it would change the view of the people in the PMC that are reluctant
| to open source it ?

I don't believe it's the PMC that's having problems open sourcing it. If
PMC is the problem, then I would instead think that some people in PMC
would rather like to decline the offer..  Read on..:

|
| But before I go down that road again, I must say if the code for Pluto was
| also entirely developed by IBM that in a way we should be thankful that
| they are willing to contribute it for free ! After all this code didn't
| write itself, and just like we are thankful to all the contributors to the
| Apache Foundation I think we will have to thank IBM for their contributions
| as soon as they finally land it :)

There are several arguments against accepting stash from "here we
contribute it for free, you should be thankful"-organizations.

Apache (Jakarta) was apparently very sad that they ever accepted the
Tomcat code (RI for Servlets) from Sun. It wasn't of good quality.

Apache is very wary of accepting any project - it should have a community
and blah blah and whatnot. Why should it suddenly become so extremely
thankful for -IBM- "donating" some piece of software?!  One -could-
imagine that they were just "going for the feather", instead of sincerly
aiming for a true open source development process and community.

People at Apache apparently feel that open source code should be developed
in an open source fashion. The opposite was once called something like
"blackboxware", and is described in this post:

http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html

This link is actually found from the PlutoProposal wiki page:
  http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal
.. more specifically, the "Talk Page" :
http://nagoya.apache.org/wiki/apachewiki.cgi?TalkPlutoProposal

|
| As for the PMC members and the process, I understand a small group of
| volunteers must be able to decide for the masses  on some issues. But I'm
| sure that corporate issues can get in the way of the committee but hey
| that's just how the world is :)

But this s... is really dragging along. There are just too much corporate
legacy stuff here. That you can clearly observe from the spec (JSR 168)
too; it is clearly something like the least common denominator of all the
portal implementations that the vendors that developed this specification
had when they entered it, and is tailored so that everyone of them easily
can implement it - logically enough.
  Then, all the vendors inside that club have delayed and halted the
specification for a REALLY long time, so that -they- could be "compliant"
to the still-not-released specification -before- the spec is out (check
out e.g. Sun and IBM's "beta" portal products: HOW COME they already are
"JSR 168 compliant", one might start to wonder)..
  This -could- be the reason why Pluto is being halted too, you know. Then
the spec could be out and everything fine, and the commercial entities
would get a first stake at the market. If pluto gets out now (or earlier),
I and several others would try to make our portal products compliant as
fast as possible, using the OS Pluto code. This would be bad for business
for IBM and the others that have spent so much time (and hence money) on
this specification, and on their already developed implementations.

Just speculations.. ranting away..

Still looking forward to the RI!

Endre.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jetspeed2 planning

[Endre Stølsvik]

David and Scott: Thanks for the informative answers!

 .. And I didn't know that the PMC meeting minutes were available like
this - but the last one is from "2002 January 30"??

Anyways, looking forward to JS2 and pluto!

Thanks
Endre

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jetspeed2 planning

[Endre Stølsvik]

On Thu, 25 Sep 2003, Weaver, Scott wrote:

| From what I have heard, it's very close now.  I know, I know I have
| said that before, but I have seen correspondence in Apache lately that
| seem to point things actually being finalized.  What you might also find
| interesting is that Pluto and Jetspeed may have a new home at
| portals.apache.org, nothing is set in stone on that though.

-Where- are these things going on?

How much "behind the scenes" is to be expected from an -OPEN SOURCE-
organization like Apache?

Endre.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re[2]: JSR-168 Comments

[Endre Stølsvik]

On Wed, 23 Jul 2003, Serge Huber wrote:

| At 09:05 AM 7/23/2003 -0700, you wrote:
|
| >Tomcat and Resin have a cross-context invoker feature.
| >See http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html
|
| Yes I am aware of those, but it still doesn't solve the problem of
| dispatching to a Portlet API portlet. The entry point for one of those
| portlets is a class that complies to a certain interface. For a Servlet in
| a different web application we can dispatch by doing something like this :
|
|  ServletContext otherWebAppContext =
| ServletContext.getContext(otherWebAppContextPath);
|  RequestDispatcher otherWebAppDispatcher =
| otherWebAppContext.getRequestDispatcher(otherWebAppURI)
|  otherWebAppDispatcher.include(request, response);
|
| But there is no equivalent for portlets. How can I call the doView method
| of a certain portlet ? You'd need a way to access the classloader of the
| other context. From what I understand in the implementation that is being
| proposed to the ASF there will be a JAR that integrates with Tomcat
| (meaning it will not be deployed in a context class loader but in Tomcat's
| classloader, providing access down to all sub class loaders) to provide
| access to the portlets, but this is very container specific and will have
| to be modified to run on any other application server.

I so hugely "agree with your problems" here. The spec is -very- confusing
on how to bind together the actual portal application (the one that draws
the windows and handles the user comms) and the portlet container. It
states very hard that it "only defineds the contract between the portlet
and the container". But how interesting is that, if it is impossible to
actually -make a PORTAL- using these Portlets?

My problem is that is seems impossible to do both of:
  a) Have a Portal implemented on top of a standard Servlet Container
  b) Run multiple Portlet Applications, preferrably in a standard Portlet
Container, preferrably -the same- container as the Portal is running in.
.. and be able to, in a standard way, to communicate between the portal
and the portlets.

One way of solving it is apparently using WSRP as the "glue" between the
portlet and portal.

To me, this seems some a kind of vendor lock-in scheme: you buy the
Servlet Engine from us, and wow, it also have a Portal in there,
effeciently doing proprietary communications with the Portlets. You are
suddenly (as it is already) locked to both the Servlet Engine -and- the
Portal (application).
  I would have loved a spec where the Portal was the Container, and had to
be able to host Portlets within it. This way, one could buy the Servlet
Container from Oracle, use JetSpeed as the Portal, and buy Portlets from
CompanyA, B and C, plugging them in / installing like nice little
applications in a normal OS.


-- 
Mvh,
Endre Stølsvik   M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Jetspeed's "new API" and IBM's WebSphere 4.1 API...

[Endre Stølsvik]

Raphael Lute: thank you very much for your tremendously helpful and
informative answers!

So..

While reading the document for the IBM WebSphere Portal v.4.1, I run into
something that I do not understand, and thought that maybe you (or someone
else here) may be able to answer:

On page 7, a Porlet is shown like an extension of PortletAdapter, which is
an extension of Portlet. I guess the latter one is meant to shown
"implements". Nevertheless, these are both from package
org.apache.jetspeed.portlet. OK. But what I do not understand, is the logic
with the next step, where Porlet inherits from
_javax.servlet.http.HttpServlet_.

Has the Jetspeed API, old or new, _ever_ had any inheritance from the
servlet specification?

Is the Jetspeed API shown in this document actually available from the
Jetspeed CVS?

This inheritance scares me! This, to me, seems like a TOTAL trashing of the
concept of a "loadable module" or "portal application" that I've found it
called here at Jetspeed. You're supposed to package the portal application
in a .war file. How are you supposed to have multiple portal applications
installed, then? Install multiple _web_ applications? But how is the
communication between the different portal applications supposed to be made?
For example, a HttpSession should not be migrated between different web
applications, according to the Servlet specs.

Given that IBM somewhat ambiguously states "The Portlet API offered in
WebSphere Portal Version 4.1 is the first step toward the Portlet API
standardization." (pg 6), I wonder about this Servlet dependency.

Jason van Zyl and David Sean Taylor: hi! Do you folks have any inside info
you can share?! ;)

Thanks,
Endre.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: update jetspeed with PortletRequest.java ....

[Endre Stølsvik]

- Original Message -
From: "Sonia Jorge" <[EMAIL PROTECTED]>
To: "Jetspeed Users List" <[EMAIL PROTECTED]>
Sent: Monday, May 06, 2002 9:17 PM
Subject: Re: update jetspeed with PortletRequest.java 


| I have only found the same as you as a proposal for the portlet api.
| But i have found some websphere documentation using these jetspeed classes
| and i want to get the version with them, can anyone help me to get them?

Check out the sources from CVS, and use the branch portlet_api.

Alternatively, you can use the CVS browser @ jakarta. You will have to look
in the Attic, for some reason. Probably since they're removed from the main
trunk, and lives within that branch portlet_api.

Just did the cvs branch checkout, and there they were! They're not finished,
though, as I suppose they are in the WebSphere Portal 4.1 product. This
product isn't out yet, though. It will come in May/June, apparently.

Endre..


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Hi! What's the "concept" with Jetspeed's portlets?

[Endre Stølsvik]

Thanks a lot for the quick reply!

I do have some follow-up questions, though..!

| Endre Stølsvik wrote:
|
| >I am writing a review of different EIP implementations, and trying to
| >analyze which "functionality" each framework provide.
| >
| >The problem I'm facing with Jetspeed, is the documentation! I cannot seem
to
| >grasp the overview of Jetspeed, so if someone could clear up on a couple
of
| >problems I'm faced with, I would be very happy! If I obviously have
missed
| >some essential documentation, could someone please lead me to the light?
;)
| >
| >*) It seems like there are a couple of portlets present in the framework,
| >and it looks to me like in the documentation that these are supposed to
be
| >enough for you, except if you have really weird needs. Is this so?
Doesn't
| >one break MVC somewhat by using Velocity template language in addition to
| >the XML registiry stuff only to program new portlets?
| >
| >
| For the first part of the question, I'm not sure these portlets are
| really supposed to handle *all* your
| current needs (for example we're missing a standard POP3/IMAP inbox
| monitor portlet...) but they
| are supposed to give you a good start.

OK.. But they are so tiny. They seems to only be made for aggregation of
internet data, and not to do any complex processing.

| For the second part of the question, if you're talking about the
| VelocityPortlet read below about
| "hello-velocity".

Didn't quite get this one..

|
| >*) Is Jetspeed primarily designed to handle _viewing_ of enterprise data,
| >that is to extract data from the underlying source, and then present it
to
| >the user? It seems a bit like this because of the "we have made 5
portlets
| >for you that handle almost everything you'd want" approach. What about
the
| >Enterprise Application Integration concept, where portlets should expose
| >some of an enterprise application's functionality? Or application-like
| >functionality, e.g. implement a group calendar system or a simple CRM
system
| >like www.salesforce.com, directly in the portal system?
| >
| >
| You can develop enterprise application integration portlet, it's just
| that we have not developped any.
| In any case, these kinds of development would more probably be done by a
| Jetspeed integrator
| although we could certainly host within the project some very generic
| ones like messaging, calendar, etc

Thanks.. But I was more referring to the "programmability" of the framework.
If I want to make some _new_ portlets, not simply aggregating easy-to-fetch
internet concent, how do I do this? Am I supposed to be helped by the
VelocityPortlet thingy, or do I have to make my own portlets? If I must make
my own, how do I go about doing this? What if I'd like to make a hugly
complex application with TONS of Java code and ten different portlets
working in conjunction, each having ten different templates that they'd like
to juggle between? Where do I start, kind of??

|
| >*) The "instance" and "ref" types. What is this? Is it similar to the
| >"instance" stuff talked about in this document:
| >
|
>http://www-3.ibm.com/software/webservers/portal/doc/V41PortletDevelopmentGu
i
| >de.pdf

Has anyone read that document?! ;) I try to sneak it into my every email, as
it seems to be a blastin' good portlet API! But I wonder how they're going
to handle "loadable modules", that is, point your configuration to a URL,
and then you will have another cool application with images, portlets and
everything "installed". Well, whatever..

| >
| >*) The actions. Are these supposed to take care of all your business
logic
| >needs?
| >
| >
| No. Actions are typically "controllers". They may sometimes be used to
| also implement the
| business logic, but Turbine would typically expect you to encapsulate
| all business logic within other classes
| (like Turbine AppplicationTools) all use the Action to populate the
| context provided to the template with
| the appropriate business objects (or use implicit context loading in
| case of Tools).

My idea is that since VelocityPortlet is pretty stupid, then Actions would
have to be where I make my business logic, showing stuff into the context
from within the Action. But apparently not. So how do I configure that
loading, basically; which class do I extend, and where do I configure it to
run with my template?

|
| >*) The "addressing" of the portlets. The hello-velocity portlet has some
| >data that can be sent to it.
| >  1) Where is the action defined? How is this configured?
| >
| There's several way to invoke the action:
| - the Turbine way of specifying an "action" parameter in the portlet
|  tag.
| - the Jetspeed VelocityPortlet way 

Hi! What's the "concept" with Jetspeed's portlets?

[Endre Stølsvik]

I am writing a review of different EIP implementations, and trying to
analyze which "functionality" each framework provide.

The problem I'm facing with Jetspeed, is the documentation! I cannot seem to
grasp the overview of Jetspeed, so if someone could clear up on a couple of
problems I'm faced with, I would be very happy! If I obviously have missed
some essential documentation, could someone please lead me to the light? ;)

*) It seems like there are a couple of portlets present in the framework,
and it looks to me like in the documentation that these are supposed to be
enough for you, except if you have really weird needs. Is this so? Doesn't
one break MVC somewhat by using Velocity template language in addition to
the XML registiry stuff only to program new portlets?

*) Is Jetspeed primarily designed to handle _viewing_ of enterprise data,
that is to extract data from the underlying source, and then present it to
the user? It seems a bit like this because of the "we have made 5 portlets
for you that handle almost everything you'd want" approach. What about the
Enterprise Application Integration concept, where portlets should expose
some of an enterprise application's functionality? Or application-like
functionality, e.g. implement a group calendar system or a simple CRM system
like www.salesforce.com, directly in the portal system?

*) The "instance" and "ref" types. What is this? Is it similar to the
"instance" stuff talked about in this document:

http://www-3.ibm.com/software/webservers/portal/doc/V41PortletDevelopmentGui
de.pdf

*) The actions. Are these supposed to take care of all your business logic
needs?

*) The "addressing" of the portlets. The hello-velocity portlet has some
data that can be sent to it.
  1) Where is the action defined? How is this configured?
  2) How is it addressed? What if two portlets on the same screen had a
submit button?

*) "Porlet applications": are Jetspeed supposed to handle, at this stage, a
".par" file, where all the necessary stash is bundled into a file?

Any help would be valued! Jetspeed isn't _that_ easy, with all the stuff
coming from both turbine and jetspeed.. ;-)

Endre.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: