tobias.schaefer | 1 Mar 17:36
Picon
Favicon

attributes of req.getServletRequest

hi there

i tried to do the following:

   var request = req.getServletRequest();
   var attr = request.getAttributeNames();
   var hasMore = attr.hasMoreElements();

but unfortunately the variable "hasMore" is false...

what's the reason for this?

my goal is to retrieve some information from a client certificate sent through a secure http connection. as
stated in [1] this can be done using

   req.getAttribute("javax.servlet.request.X509Certificate");

but as there are no attributes at all i don't get any value here either.

is there a different way to get this information?

ciao,
tobi

--
[1] http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/ServletRequest.html#getAttribute(java.lang.String)
Joshua Levy | 2 Mar 02:18
Favicon

Re: Doc contributions

Following up on the doc suggestions for the website: I put a
couple comments on specific topics on the site earlier, but
here are a few more general, organizational comments.

Of course, thanks for high-quality docs to begin with!  I
do hope no one minds my presumption in tossing out a laundry
list of suggestions...

First:

- The outline on the left column does not actually match the
  contents of http://helma.org/docs/  This is confusing.  The
  left-hand side looks like a navigation tree, so it should list
  all the contents (in the same order), or just have one
  "Documents" link.

Generally, it can be a little hard to know what doc holds what
information, and so you end up just clicking on many and
reading them.  This is OK, but some more descriptive names might
help.  Some ideas: Within http://helma.org/docs/,

- Put "Tools" within the "Guide" folder, rather than at the top.
  (Other "tools" like HelmaDoc are already in the Guide.)

- Rename "Reference" more descriptively as "API Reference", and
  also put it in the "Guide" folder.  (There are other
  references, such as the property files reference, already
  in the Guide.)

- Rename "Conceptual Overview" something like "Helma Objects",
(Continue reading)

Dan Pozmanter | 2 Mar 05:18

HelmaControl

Dear Helma Community,

  I have been working on a small gui tool similiar to the apache monitor
that runs in the taskbar on windows, using java + jdic.
I was wondering if people thought this would be
a useful tool to have, and if so, what features people
would like to see.

Best,
Dan

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user
Chris Zumbrunn | 2 Mar 07:46
Gravatar

Re: Doc contributions

On Mar 2, 2006, at 2:18 AM, Joshua Levy wrote:

> - The outline on the left column does not actually match the
>   contents of http://helma.org/docs/  This is confusing.  The
>   left-hand side looks like a navigation tree, so it should list
>   all the contents (in the same order), or just have one
>   "Documents" link.

Right now I am limited in what I can do on the "old" website that is 
currently online. I can't easily change the order and the hierarchical 
structure of the content. The outline currently displayed is a 
compromise of staying within those limitations, preventing 
links/urls/bookmarks from breaking, being useful to newbies and being 
efficient for regular users.

I'll make a draft version of my proposal of the "new" site available 
shortly, which will address these issues.

> Generally, it can be a little hard to know what doc holds what
> information, and so you end up just clicking on many and
> reading them.  This is OK, but some more descriptive names might
> help.  Some ideas: Within http://helma.org/docs/,
>
> - Put "Tools" within the "Guide" folder, rather than at the top.
>   (Other "tools" like HelmaDoc are already in the Guide.)

The entire documentation really should be the "Guide", with individual 
sections serving as a "guide within a guide" on particular topics.

> - Rename "Reference" more descriptively as "API Reference", and
>   also put it in the "Guide" folder.  (There are other
>   references, such as the property files reference, already
>   in the Guide.)

The "Reference" I see as the exception to what I just wrote above. It 
can go inside the guide, but I do not want to hide it inside the guide, 
since regular/veteran users will need to use the reference regularly, 
while rarely caring about the "guide" sections. At least if it is a 
"good" reference - I'm thinking of making this work more like an 
app/tool rather than a collection of web pages.

> - Rename "Conceptual Overview" something like "Helma Objects",
>   since that is what it focuses on.

This will be rewritten and ready for the dust bin.

> - Actually, "Web Framework Guide" is closer to being a
>   conceptual overview.  In fact, it may be the most helpful
>   thing to read first, so perhaps should be highlighted somehow.

Yes, but it needs to be broken up a bit. It currently is to hard to 
digest as an "introduction".

> - The "Introductions" folder might be more accurately called
>   "Helma Building Blocks" and put after the latter one.

Hmm, I see what you are saying. I'll try to come up with a more ideal 
mix and structure.

> With more things within the Guide, you would know you should
> look there for general information beyond the tutorial.
> How-Tos and Examples, etc. would still be separate.

I was thinking to make HowTos/Examples a special section of the guide, 
containing a collection of "quick guides" on particular problems / use 
cases, separating development, deployment and maintenance related 
issues.

> A couple more notes:
>
> - I see the DocBook version of the documentation, but it would
>   be very helpful if there were a downloadable version of the
>   web-based Guide.  No doubt this involves some work to package
>   it up though...
>
> - Is the Gong wiki still used much?  If not, maybe remove the
>   link at http://helma.org/development/doczone/ and suggest
>   people use comments on the site.

Thanks, fixed.

> Well, hope some of those are of use.

Very much so, thank you. Please keep the feedback coming!

Chris
tobias.schaefer | 2 Mar 13:48
Picon
Favicon

Re: attributes of req.getServletRequest

hi tobi
:)

since i know you are using helma with apache2, you need to make sure to add the following directive in
apache.conf add

   SSLOptions +ExportCertData

then you should be able to retrieve the client certificates as java.security.cert.X509Certificate as
described before.

   var request = req.getServlet.Request();
   var certs = req.getAttribute("javax.servlet.request.X509Certificate");

hth,
tobi

tobias.schaefer <at> orf.at wrote:
> hi there
> 
> i tried to do the following:
> 
>    var request = req.getServletRequest();
>    var attr = request.getAttributeNames();
>    var hasMore = attr.hasMoreElements();
> 
> but unfortunately the variable "hasMore" is false...
> 
> what's the reason for this?
> 
> my goal is to retrieve some information from a client certificate
> sent through a secure http connection. as stated in [1] this can be
> done using  
> 
>    req.getAttribute("javax.servlet.request.X509Certificate");
> 
> but as there are no attributes at all i don't get any value here
> either. 
> 
> is there a different way to get this information?
> 
> ciao,
> tobi
Michael Platzer | 7 Mar 15:49
Picon

mod_jk & utf8

sorry, to pick up an old old topic again 
[http://helma.org/pipermail/helma-dev/2005-February/001683.html, 
http://helma.org/pipermail/helma-dev/2004-September/thread.html#1418], 
but i must admit, that i still haven't been able to solve this issue.
we've got "charset = utf-8" set in "app.properties", as well as render 
all the pages with a correct html-header indicating that the content is 
actually utf-8.

lets assume i've got an object named "möller" in my path, then the 
generated URL will be sthg like
  http://localhost:8080/helma/app01/users/m%C3%B6ller
(i.e. utf-8 encoded urls) and helma finds the according object, when i 
point my browser to that URL. wikipedia produces similar urls 
(http://de.wikipedia.org/wiki/M%C3%B6ller). now, first problem is, that 
if i write
  http://localhost:8080/helma/app01/users/möller
directly in my browser address bar, than a 404 is returned. but 
accessing http://de.wikipedia.org/wiki/Möller returns the correct page, 
which is also the behaviour i would like to have.

now, in a production environment we always use mod_jk. in my current 
setup i've got the latest stable mod_jk-release (1.2.15) together with 
apache2.0. The URLs generated by helma are now still utf8-encoded.
  http://localhost/helma/app01/users/m%C3%B6ller
These URLs produce 404s. Entering
  http://localhost/helma/app01/users/möller
in my IE also produces a 404, whereas FireFox redirects to
  http://localhost/helma/twoday_media/michi/stories/tags/m%F6ller
(i.e. to the iso-8859-1 encoded URL) which then returns the correct 
object. Entering the same URL in IE also produces a correct result.

so, my questions are:
* how can i tell mod_jk to accept utf8-encoded urls?
* how can i acchieve that entering the umlauts directly into my address 
bar leads to valid requests (with and without mod_jk)?

hope someone can help me out with this issue.
thanks in advance,
  michi
Joshua Levy | 8 Mar 20:26
Favicon

Java-based persistence

Hi folks,
I'm trying to use Helma as a front-end (that is, view and
controller) for an existing Java back-end with its own model
and persistence layer.  This is skipping out on the Helma
ORM and persistence model, but could still provide benefits
of the actions, skins, and deployment environment.  

Before possibly reinventing the wheel, I was curious if
anyone else has been using Helma this way or had thoughts on
the issue.  More specifically, I'm interested in how to get
the advantages of HopObjects when the data passing to and
from the back end is plain Java objects.  A simple approach
is manually to wrap objects that are web-renderable in
transient HopObjects, so that skinning works easily -- e.g.,
I can make a HopObject constructor wrapper and helper
methods so you can do something like
  var javaThing = javaBackend.lookupThing(...);
  var thing = new Thing(javaThing);  // HopObject constructor
  var str = thing.renderSkinAsString("myview");

But it would be nicer if there was an automatic wrapping of
Java classes with HopObjects, so that appropriate methods of
both were available on the same object:
  var thing = javaBackend.lookupThing(...);
  var str = thing.renderSkinAsString("...");
Behind the scenes, there would be some sort of declared
mapping between back-end Java objects and HopObjects.

Ideally, there could even be a third type of persistence
mechanism, with support also for persisting new and modified
objects, but I suppose this is rather ambitious.  Read-only
support as above would still be useful; storing modified
objects could be done manually.

Another simple approach might be to exploit prototype
chains...  Can a HopObject be assigned as a prototype of a
Java object?  I tried assigning to javaThing.__proto__, but
I'm not sure you can get away with this in Rhino; I'm
getting a TypeError.  Perhaps some Rhino trick using a
JavaAdapter?

In any case, it seems that with more support for Java-based
back-ends would lower the barrier to dropping existing Java
systems into a Helma UI, and provide the benefits of more
agile JavaScript web development even when one isn't
implementing the whole Web application stack in Helma.

Any comments or suggestions?  Many thanks,

Joshua
Stefan Rinner | 9 Mar 08:55
Picon

Re: Java-based persistence

> But it would be nicer if there was an automatic wrapping of
> Java classes with HopObjects, so that appropriate methods of
> both were available on the same object:
>   var thing = javaBackend.lookupThing(...);
>   var str = thing.renderSkinAsString("...");
> Behind the scenes, there would be some sort of declared
> mapping between back-end Java objects and HopObjects.

there's already a mechanism like this in helma
just put a file called "class.properties" in your application folder

and put something like this in it:
com.myCompany.mySpecialWhatever = SpecialWhatever
.....

it works very well

I'm currently building an application with the same approach -  
persistence and businesslogic in javaclasses and all presentation- 
stuff in helma.

- stefan
Hannes Wallnoefer | 9 Mar 09:43
Picon
Gravatar

Re: Java-based persistence

The (hopefully) complete documentation is here:

http://helma.org/docs/guide/properties/class.properties/

hannes

2006/3/9, Stefan Rinner <rist <at> mac.com>:
> > But it would be nicer if there was an automatic wrapping of
> > Java classes with HopObjects, so that appropriate methods of
> > both were available on the same object:
> >   var thing = javaBackend.lookupThing(...);
> >   var str = thing.renderSkinAsString("...");
> > Behind the scenes, there would be some sort of declared
> > mapping between back-end Java objects and HopObjects.
>
> there's already a mechanism like this in helma
> just put a file called "class.properties" in your application folder
>
> and put something like this in it:
> com.myCompany.mySpecialWhatever = SpecialWhatever
> .....
>
> it works very well
>
> I'm currently building an application with the same approach -
> persistence and businesslogic in javaclasses and all presentation-
> stuff in helma.
>
> - stefan
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
>
nighthawk | 9 Mar 10:54
Picon

listener on ipv6

hello,

i have encountered an interesting problem yesterday. i tried to set up
helma on freebsd 6. everything appears to be working fine, but helma
creates the listener on ipv6 interfaces only.
is there any way to tell helma to use ipv4? is there a way (in
general) to tell helma to not listen on 0.0.0.0 but a specific ip
instead?

lsof shows the following:
java      11973    root    7u  IPv6 0xc4d1dac8        0t0     TCP
*:8081 (LISTEN)
java      11973    root   18u  IPv6 0xc3298398        0t0     TCP
*:8009 (LISTEN)

and netstat shows this:
tcp6       0      0  *.8009                 *.*                    LISTEN
tcp6       0      0  *.8081                 *.*                    LISTEN

the problem - i think - is (i dont know how to describe that properly)
that on my interfaces "inet6" comes before "inet":

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet 127.0.0.1 netmask 0xff000000

unfortunately i have no clue how to change that. i could, i guess,
disable ipv6 on the machine, but that cant be the final solution since
there is afterall ppl out there (unlike me) who need ipv6 on their
machines :-)

nh

Gmane