You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Torsten Curdt <tc...@dff.st> on 2000/07/18 09:52:09 UTC
RE: urgent: 1.7.5
> Please guys... I need 1.7.5 to get working!!
> There must be someone out there using 1.7.5
> and connection pooling! I'm runnin' out
> of time!!
> java.lang.RuntimeException: Error creating
> org.apache.cocoon.processor.xsp.XSPProcessor:
> make sure the needed classes can be found in the classpath
> (org/apache/java/util/ConfigurationsRepository)
> at org.apache.cocoon.framework.Manager.create(Manager.java:114)
> at org.apache.cocoon.framework.Router.init(Router.java:80)
>
> I tracked it down and it seems to be the configuration repository of the
> connection pool.
> The problem is: like cocoon... I don't find this a class either! Shouldn't
> it be inside the turbine-pool.jar ?!
Ok... some more information: 1.7.5 runs fine when NOT defining a connection
pool! So: commenting out all pools in the cocoon.properties made 1.7.5 run.
But I NEED the connection pool! Could someone help me setting up this
d*mn pool? This part of the cocoon.properties makes my cocoon stumbling:
--snip--
wrapper.classpath=D:\INSTALL\tomcat/lib/turbine-pool.jar
processor.xsp.pool.logfile=D:\INSTALL\dbPool.log
#processor.xsp.pool.services.TurbineResourceService.classname=org.apache.tur
bine.services.resources.TurbineResourceService
# tried it with and without the above line
processor.xsp.pool.database.adaptor.DBSybase=com.sybase.jdbc.SybDriver
processor.xsp.pool.database.desire.driver=com.sybase.jdbc.SybDriver
processor.xsp.pool.database.desire.url=jdbc:sybase:Tds:mogh.dff.local:2629/t
est
processor.xsp.pool.database.desire.username=test
processor.xsp.pool.database.desire.password=test
processor.xsp.pool.database.desire.maxConnections=3
processor.xsp.pool.database.desire.expiryTime=3600000
--snap--
> Please some... I'm really desperate!
meant someONE... ;-)
--
Torsten
Re: urgent: 1.7.5
Posted by Jeff Turner <je...@socialchange.net.au>.
Torsten Curdt wrote:
>
> > > > java.lang.RuntimeException: Error creating
> > > > org.apache.cocoon.processor.xsp.XSPProcessor:
> > > > make sure the needed classes can be found in the classpath
> > > > (org/apache/java/util/ConfigurationsRepository)
> > > > at org.apache.cocoon.framework.Manager.create(Manager.java:114)
> > > > at org.apache.cocoon.framework.Router.init(Router.java:80)
> > > >
> > > > I tracked it down and it seems to be the configuration
> > repository of the
> > > > connection pool.
> > > > The problem is: like cocoon... I don't find this a class
> > either! Shouldn't
> > > > it be inside the turbine-pool.jar ?!
> >
> > I'd just like to jump in here promote Kevin Burton's 'classman' tool
> > for managing CLASSPATHs. For example, to search all the jars in my
> > CLASSPATH for your missing class "ConfigurationsRepository":
> >
> > ~/java/classman$ classman --find ConfigurationsRepository
> > /home/jeff/java/lib/turbine.jar
> > ConfigurationsRepository ->
> > org.apache.java.util.ConfigurationsRepository
> >
> > In turbine.jar, not turbine-pool.jar. Cool, no? :)
> >
> > The URL is http://relativity.yi.org/classman/
>
> This thing is cool! I'll check if can get it workin' under NT later on...
> ;-)
>
> Ok, back to my class problem:
> There is no turbine.jar in 1.7.5 just a turbine-pool.jar!
> Do I need to get the turbine distribution? Thought the turbine-pool.jar
> would have all I need?
Looks like someone forgot to update turbine-pool.jar. Check turbine
out from CVS
(CVSROOT=:pserver:anon@cvs.working-dogs.com:/products/cvs/turbine,
password=anon).
CLASSPATH variables are horrible things; they embody unchallenged
assumptions about code dependencies and are too easy to abuse. Might I
humbly suggest that developers reset their CLASSPATHs to only include
the bare minimum? (rt.jar, tools.jar, jaxp.jar, parser.jar).
--Jeff
>
> You're giving me hope to solve this stuff... :-)
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: urgent: 1.7.5
Posted by Torsten Curdt <tc...@dff.st>.
> > > java.lang.RuntimeException: Error creating
> > > org.apache.cocoon.processor.xsp.XSPProcessor:
> > > make sure the needed classes can be found in the classpath
> > > (org/apache/java/util/ConfigurationsRepository)
> > > at org.apache.cocoon.framework.Manager.create(Manager.java:114)
> > > at org.apache.cocoon.framework.Router.init(Router.java:80)
> > >
> > > I tracked it down and it seems to be the configuration
> repository of the
> > > connection pool.
> > > The problem is: like cocoon... I don't find this a class
> either! Shouldn't
> > > it be inside the turbine-pool.jar ?!
>
> I'd just like to jump in here promote Kevin Burton's 'classman' tool
> for managing CLASSPATHs. For example, to search all the jars in my
> CLASSPATH for your missing class "ConfigurationsRepository":
>
> ~/java/classman$ classman --find ConfigurationsRepository
> /home/jeff/java/lib/turbine.jar
> ConfigurationsRepository ->
> org.apache.java.util.ConfigurationsRepository
>
> In turbine.jar, not turbine-pool.jar. Cool, no? :)
>
> The URL is http://relativity.yi.org/classman/
This thing is cool! I'll check if can get it workin' under NT later on...
;-)
Ok, back to my class problem:
There is no turbine.jar in 1.7.5 just a turbine-pool.jar!
Do I need to get the turbine distribution? Thought the turbine-pool.jar
would have all I need?
You're giving me hope to solve this stuff... :-)
--
Torsten
Re: Dynamic XML generation
Posted by Yann <yl...@ims.ltd.uk>.
You should use XSP instead.
You can embbed Java logic in XSP pages and use your own classes. Since you
have access to the HTTP request and session objects, you can easily redirect
to a login page if a user hasn't logged on yet.
It's pretty straightforward.
Yann.
Re: OFF-TOPIC? Including an XML file in another one
Posted by Berin Loritsch <bl...@infoplanning.com>.
Olivier Richaud wrote:
>
> I'm trying to define an xml page that is in fact an aggregation of several
> other XML pages. What I want to do, is to consider those XML pages as XML
> datasources that will be inserted in the top XML page. For example, my page
> should look like:
>
> <page>
> <data-source src="ds1.xml"/>
> <data-source src="ds2.xml"/>
> </page>
>
> The data-source tag points to another XML file that should be inserted. For
> example, ine the ds1.xml file, I could find paragraphs:
>
> <paragraph>
> Foo bar, Foo bar,....
> </paragraph>
>
> Is there anyone with a solution for this? Anything which is Cocoon compliant
> is welcome, that is using XSL, XSP, ....
>
> Thanks in advance.
In your XSL file, call the external XML file with a construct like this:
<xsl:template match="page">
<xsl:for-each select="data-source">
<xsl:apply-templates select="document(data-source/@src)"/>
</xsl:for-each>
</xsl:template>
That should do it for you. If it complains about not finding the "@src",
then remove the preceding "data-source/". It's not clear to me if the
scope of the XPath statement automatically goes into "data-source/" when
you use the <xsl:for-each/> tag or not.
I have used the <xsl:apply-templates select="document(foo.xml)"/> construct
to keep menus separate from the content.
Re: OFF-TOPIC? Including an XML file in another one
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 16:07 -0400 19/07/00, Donald Ball wrote:
>On Wed, 19 Jul 2000, Olivier Richaud wrote:
>
>> I'm trying to define an xml page that is in fact an aggregation of several
>> other XML pages. What I want to do, is to consider those XML pages as XML
>> datasources that will be inserted in the top XML page. For example, my page
>> should look like:
[snip]
>1. use xinclude processor
>2. use util:include-uri logicsheet
>3. use external entities
>4. use xslt document() function
5. use FP TagLib
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: OFF-TOPIC? Including an XML file in another one
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 19 Jul 2000, Olivier Richaud wrote:
> I'm trying to define an xml page that is in fact an aggregation of several
> other XML pages. What I want to do, is to consider those XML pages as XML
> datasources that will be inserted in the top XML page. For example, my page
> should look like:
>
> <page>
> <data-source src="ds1.xml"/>
> <data-source src="ds2.xml"/>
> </page>
>
> The data-source tag points to another XML file that should be inserted. For
> example, ine the ds1.xml file, I could find paragraphs:
>
> <paragraph>
> Foo bar, Foo bar,....
> </paragraph>
>
> Is there anyone with a solution for this? Anything which is Cocoon compliant
> is welcome, that is using XSL, XSP, ....
1. use xinclude processor
2. use util:include-uri logicsheet
3. use external entities
4. use xslt document() function
- donald
OFF-TOPIC? Including an XML file in another one
Posted by Olivier Richaud <ri...@cstb.fr>.
I'm trying to define an xml page that is in fact an aggregation of several
other XML pages. What I want to do, is to consider those XML pages as XML
datasources that will be inserted in the top XML page. For example, my page
should look like:
<page>
<data-source src="ds1.xml"/>
<data-source src="ds2.xml"/>
</page>
The data-source tag points to another XML file that should be inserted. For
example, ine the ds1.xml file, I could find paragraphs:
<paragraph>
Foo bar, Foo bar,....
</paragraph>
Is there anyone with a solution for this? Anything which is Cocoon compliant
is welcome, that is using XSL, XSP, ....
Thanks in advance.
Olivier Richaud
CSTB
office: +33 4 93 95 67 24
mobile: +33 6 87 52 53 17
www: http://cic.cstb.fr
Re: Dynamic XML generation
Posted by Ulrich Mayring <ul...@denic.de>.
Nicola Ken Barozzi wrote:
>
> If you have 20 files in a directory, to secure them you have to put
> XSP tags in all of them, and remember to do it.
Yes, the system gets messy, if you have too many files and no authoring
front-end to automate things. On the other hand if you have many files
with different users/rights, then my system is better to manage, I
think. You can put a few general directives in an external container
(sitemap, servlet, whatever), but if you were to specify every single
file's permission modes in an external container or its config file,
then things get messy, too. Imagine a website and cocoon2's sitemap
which specifies a different thing for every single file - messy :)
Not to speak about performance: a sitemap-like thing has to be scanned
for matches with every single request coming in. Even though in 99% of
the cases the sitemap may not even act, because location paths don't
match. With my system a file's access rights are only checked when that
file is actually requested, not every time a request comes in.
Finally, to change access rights you probably have to restart an
external container. Quite a problem with busy sites. I just have to
modify XML files.
> > 2) Who is ever going to want to take cocoon away? :-)
>
> Who is going to take the servlet container away?
Well, this was tongue-in-cheek. I assumed your servlet container is not
a generic program, that can be installed everywhere. It is specific to
your site and your security setup, so you can't give it to someone else.
But you can give cocoon and XML files plus an authentication taglib to
everyone, they just install it and it works. I think this
interoperability may turn out to be very important in B2B-workflows.
> Definately agree.
> But I think that it should build over servlet security, adding where things
> are missing.
Absolutely!
> Your scenario is missing, mine needs additions.
Yes, one can only start with a single scenario and hope to add more
later on :)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Dynamic XML generation
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Uli Mayring" <ul...@denic.de>
> On Tue, 18 Jul 2000, Nicola Ken Barozzi wrote:
>
> > I understand.
> > The point is that security is not necessarily managed at the level of
> > content writers. I find it cleaner to use container type validation,
> > but keep in mind that I am thinking of an intranet.
> > In your case, I agree that loose security is usually better.
>
> Well, content is not necessarily managed at the level of editing a text
> file either :-)
>
> So, content writers shouldn't have access to the XML file itself, only to
> a front-end, which presents them with the parts of the XML they are
> allowed to edit. Now, wouldn't it be handy if every XML file knew about
> its access policy? It could tell the front-end about it :)
Good point. In this scenario, yes.
I think that your and my views are complementary.
> I think this is the opposite of loose security :)
Not necessarily.
If you have 20 files in a directory, to secure them you have to put
XSP tags in all of them, and remember to do it.
Content creators alse <create> files, and the administrator may want
to block a whole dir to a group of users without hoping that the content
creator remembers to specify it in all his files.
Btw, they have to be XSPs.
> The problem with a container-approach is that it only works as long as the
> container works. Take the container away and nobody will know the access
> permissions of your XML files anymore. A good example are apache's
> .htaccess files. They are useless, unless you access the HTML files
> through an apache webserver. So, what do you do if management tells you,
> you should put an IIS on the same files? Or you should allow users to
> login to the filesystem? You have to take your security away from apache
> in these cases or you will start to manage many different security setups.
>
> Now, cocoon (and my taglib) is of course a container, too. Take cocoon (or
> my taglib) away and security is gone? Wrong, it's still there, in the XML
> - only it doesn't work anymore :)
>
> 1) This difference may sound academic, I'm afraid :-)
> 2) Who is ever going to want to take cocoon away? :-)
Who is going to take the servlet container away?
> Hey, I'm open to other suggestions. How can I do security better? Somehow
> I think that cocoon would benefit, if it shipped with authentication. Why
> should every cocoon-user re-invent the wheel?
Definately agree.
But I think that it should build over servlet security, adding where things
are missing.
Your scenario is missing, mine needs additions.
> > I mean that the servlet container checks only that the user authenticated,
> > not that its properties are present.
> > You have to put this check in by hand for every file, I want it to
> > be automatic for every page in secured resources.
>
> Well, why don't you rewrite your servlet container in such a way, then?
> Probably because if you do, you end up with something like cocoon :)
I was not clear. When I talk about container I mean Tomcat.
I ain't going to rewrite it ! ;-)
And cocoon doesn't do authentication yet.
> Anyway, now I see why you would want a taglib for managing properties. I
> have no moral doubts about stealing your taglib and using it for my own
> authentication system :-)
Good! :-))
> > > It appears to me that this is authentication external to cocoon, I am
> > > doing authentication within cocoon.
> >
> > Hmm... why is it so important?
>
> I think... well, no, I hope I explained it above :)
Yes, your scenario.
> Think of it as an additional feature - nothing stops you from using an
> external container as well or instead of it. I just think there is some
> value in integrating into cocoon what can be integrated. Less external
> things to manage.
Yes, same as above.
Ciao,
nicola_ken
Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Personal homepage at Java Guru:
http://www.jguru.com/jguru/guru/viewchannel.jsp?EID=39153
Personal FAQ at Java Guru:
http://www.jguru.com/jguru/guru/viewfaqs.jsp?EID=39153
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)
Re: Dynamic XML generation
Posted by Uli Mayring <ul...@denic.de>.
On Tue, 18 Jul 2000, Nicola Ken Barozzi wrote:
> I understand.
> The point is that security is not necessarily manadged at the level of
> content writers. I find it cleaner to use container type validation,
> but keep in mind that I am thinking of an intranet.
> In your case, I agree that loose security is usually better.
Well, content is not necessarily managed at the level of editing a text
file either :-)
So, content writers shouldn't have access to the XML file itself, only to
a front-end, which presents them with the parts of the XML they are
allowed to edit. Now, wouldn't it be handy if every XML file knew about
its access policy? It could tell the front-end about it :)
I think this is the opposite of loose security :)
The problem with a container-approach is that it only works as long as the
container works. Take the container away and nobody will know the access
permissions of your XML files anymore. A good example are apache's
.htaccess files. They are useless, unless you access the HTML files
through an apache webserver. So, what do you do if management tells you,
you should put an IIS on the same files? Or you should allow users to
login to the filesystem? You have to take your security away from apache
in these cases or you will start to manage many different security setups.
Now, cocoon (and my taglib) is of course a container, too. Take cocoon (or
my taglib) away and security is gone? Wrong, it's still there, in the XML
- only it doesn't work anymore :)
1) This difference may sound academic, I'm afraid :-)
2) Who is ever going to want to take cocoon away? :-)
Hey, I'm open to other suggestions. How can I do security better? Somehow
I think that cocoon would benefit, if it shipped with authentication. Why
should every cocoon-user re-invent the wheel?
> I mean that the servlet container checks only that the user authenticated,
> not that its properties are present.
> You have to put this check in by hand for every file, I want it to
> be automatic for every page in secured resources.
Well, why don't you rewrite your servlet container in such a way, then?
Probably because if you do, you end up with something like cocoon :)
Anyway, now I see why you would want a taglib for managing properties. I
have no moral doubts about stealing your taglib and using it for my own
authentication system :-)
> > It appears to me that this is authentication external to cocoon, I am
> > doing authentication within cocoon.
>
> Hmm... why is it so important?
I think... well, no, I hope I explained it above :)
Think of it as an additional feature - nothing stops you from using an
external container as well or instead of it. I just think there is some
value in integrating into cocoon what can be integrated. Less external
things to manage.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: Dynamic XML generation
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Uli Mayring" <ul...@denic.de>
> On Tue, 18 Jul 2000, Nicola Ken Barozzi wrote:
>
> > Well, servlet engines and web servers can do authentication by themselves,
> > and I found it quite easier to use.
> > I wouldn't want to make all my pages XSPs, nor want to put the taglib
> > in all my XSPs.
>
> In a scenario where you have many public pages and only a few protected
> ones, my taglib should work fine. You'll just have to have two things:
>
> A) one login file per authentication system (i.e. one file called
> login.xml, which specifies users, their rights and whatever else you
> need, for example database URLs and drivers for JDBC access to them)
> B) in each protected file you need to insert something (best done via
> XInclude) that points to the login file to use
>
> If a user tries to access any of the files in group B and has not
> previously been authenticated according to the system set forth in group
> A, he is automatically sent to the respective login file. Thus he can't
> see any protected pages, unless he has successfully authenticated.
>
> The advantages of this system are that you can centrally manage security
> by using a number of login files (or even just one). Plus you don't have
> passwords in your files anymore. I plan to make authentication schemes
> pluggable, but at first there will just be authentication against a
> database (because that is what I need ;-).
I understand.
The point is that security is not necessarily manadged at the level of
content writers. I find it cleaner to use container type validation,
but keep in mind that I am thinking of an intranet.
In your case, I agree that loose security is usually better.
> A drawback is that you don't have connection security as with SSL, but I
> think this should be considered a seperate task anyway.
>
> > I am writing a simple system that associates user properties to the user
> > login name, and will post it here when finished.
> > The problem is how to make the check automatic...
>
> Could you describe that problem? I'm not sure I understand what you mean
> here.
I mean that the servlet container checks only that the user authenticated,
not that its properties are present.
You have to put this check in by hand for every file, I want it to
be automatic for every page in secured resources.
> > Why not make a servlet that is in charge of all extensions and that
> > forwards
> > to Cocoon only valid users?
>
> It appears to me that this is authentication external to cocoon, I am
> doing authentication within cocoon.
Hmm... why is it so important?
Anyway, the servlet before cocoon is there only for C1, not
to have to change C1 inside.
With C2 you can use the sitemap i guess.
> > Can the sitemap in C2 do this easily?
>
> The sitemap can do everything and will make us all lose our jobs ;-)
:-))
> > How can we make things work between my user properties class
> > and your authentication system?
>
> Well, my system includes a very basic user property system, you specify
> the properties to use in the login files, as explained under A)
>
> However, I don't have an automatic way to set properties, the user has to
> type them into a form. And I don't save properties beyond a session.
> Static properties (ones that never change) can be kept in login files, of
> course.
Ok.
Thanx.
nicola_ken
Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Personal homepage at Java Guru:
http://www.jguru.com/jguru/guru/viewchannel.jsp?EID=39153
Personal FAQ at Java Guru:
http://www.jguru.com/jguru/guru/viewfaqs.jsp?EID=39153
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)
Re: Dynamic XML generation
Posted by Uli Mayring <ul...@denic.de>.
On Tue, 18 Jul 2000, Nicola Ken Barozzi wrote:
> Well, servlet engines and web servers can do authentication by themselves,
> and I found it quite easier to use.
> I wouldn't want to make all my pages XSPs, nor want to put the taglib
> in all my XSPs.
In a scenario where you have many public pages and only a few protected
ones, my taglib should work fine. You'll just have to have two things:
A) one login file per authentication system (i.e. one file called
login.xml, which specifies users, their rights and whatever else you
need, for example database URLs and drivers for JDBC access to them)
B) in each protected file you need to insert something (best done via
XInclude) that points to the login file to use
If a user tries to access any of the files in group B and has not
previously been authenticated according to the system set forth in group
A, he is automatically sent to the respective login file. Thus he can't
see any protected pages, unless he has successfully authenticated.
The advantages of this system are that you can centrally manage security
by using a number of login files (or even just one). Plus you don't have
passwords in your files anymore. I plan to make authentication schemes
pluggable, but at first there will just be authentication against a
database (because that is what I need ;-).
A drawback is that you don't have connection security as with SSL, but I
think this should be considered a seperate task anyway.
> I am writing a simple system that associates user properties to the user
> login name, and will post it here when finished.
> The problem is how to make the check automatic...
Could you describe that problem? I'm not sure I understand what you mean
here.
> Why not make a servlet that is in charge of all extensions and that
> forwards
> to Cocoon only valid users?
It appears to me that this is authentication external to cocoon, I am
doing authentication within cocoon.
> Can the sitemap in C2 do this easily?
The sitemap can do everything and will make us all lose our jobs ;-)
> How can we make things work between my user properties class
> and your authentication system?
Well, my system includes a very basic user property system, you specify
the properties to use in the login files, as explained under A)
However, I don't have an automatic way to set properties, the user has to
type them into a form. And I don't save properties beyond a session.
Static properties (ones that never change) can be kept in login files, of
course.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: Dynamic XML generation
Posted by Mark Washeim <es...@canuck.com>.
on 18/7/00 6:12 pm, Nicola Ken Barozzi at nicolaken@supereva.it wrote:
> ----- Original Message -----
> From: "Ulrich Mayring" <ul...@denic.de>
>
>> Patrick Roemer wrote:
>>>
>>> So I am looking for an approach that handles
>>> authentication separately and then has Cocoon do its work.
>>
>> I am currently putting together a taglib, that does authentication. This
>> is IMHO the only sensible way to implement something like this in
>> cocoon. Otherwise you could use another framework below cocoon that does
>> these things, I believe something called turbine or jetspeed could do
>> that.
>>
>
> Well, servlet engines and web servers can do authentication by themselves,
> and I found it quite easier to use.
> I wouldn't want to make all my pages XSPs, nor want to put the taglib
> in all my XSPs.
> I am writing a simple system that associates user properties to the user
> login name, and will post it here when finished.
> The problem is how to make the check automatic...
> Why not make a servlet that is in charge of all extensions and that forwards
> to Cocoon only valid users?
> Can the sitemap in C2 do this easily?
> How can we make things work between my user properties class
> and your authentication system?
>
We use a wrapper approach which might find it's parallel in a C2 transformer
. . . namely, create a custom transformer that you apply for pipelines you
want authentication to take place for and have it check, for instance, the
session for log-in status and redirect if needed.
I think this is, in principle wrong, from the site-map view. Hmmm. I'm going
to look at the matcher and selector mechanisms again, but, it should be
possible, since this is a pipe-line arch. to introduce a filter for
authorization and authentication . . .
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: Dynamic XML generation
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Ulrich Mayring" <ul...@denic.de>
> Patrick Roemer wrote:
> >
> > So I am looking for an approach that handles
> > authentication separately and then has Cocoon do its work.
>
> I am currently putting together a taglib, that does authentication. This
> is IMHO the only sensible way to implement something like this in
> cocoon. Otherwise you could use another framework below cocoon that does
> these things, I believe something called turbine or jetspeed could do
> that.
>
Well, servlet engines and web servers can do authentication by themselves,
and I found it quite easier to use.
I wouldn't want to make all my pages XSPs, nor want to put the taglib
in all my XSPs.
I am writing a simple system that associates user properties to the user
login name, and will post it here when finished.
The problem is how to make the check automatic...
Why not make a servlet that is in charge of all extensions and that forwards
to Cocoon only valid users?
Can the sitemap in C2 do this easily?
How can we make things work between my user properties class
and your authentication system?
nicola_ken
Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Personal homepage at Java Guru:
http://www.jguru.com/jguru/guru/viewchannel.jsp?EID=39153
Personal FAQ at Java Guru:
http://www.jguru.com/jguru/guru/viewfaqs.jsp?EID=39153
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)
Re: Dynamic XML generation
Posted by Ulrich Mayring <ul...@denic.de>.
Patrick Roemer wrote:
>
> So I am looking for an approach that handles
> authentication separately and then has Cocoon do its work.
I am currently putting together a taglib, that does authentication. This
is IMHO the only sensible way to implement something like this in
cocoon. Otherwise you could use another framework below cocoon that does
these things, I believe something called turbine or jetspeed could do
that.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Dynamic XML generation
Posted by Mike Engelhart <me...@earthtrip.com>.
on 7/18/00 3:42 PM, Jeremy Quinn at jeremy@media.demon.co.uk wrote:
> Does this work by placing the attributes in the request HTTP header?
> How are they encoded?
> Why not use sessions and save passing the data around the net?
> I was about to try this with the FP TagLib. I am hoping you should be able
> to mix FP and the Request TagLib with the Session TagLib to do this.
It's not passing it around the net. It's passing it from the server to the
server. It forwards an HttpServletRequest object to another servlet, not
the headers (although the headers are encapsulated in the object as well).
Mike
Re: Dynamic XML generation
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Ulrich Mayring" <ul...@denic.de>
> Jeremy Quinn wrote:
> >
> > I am assuming (I never used session before) that it would be possible for
> > both of our taglibs to only create a new session if one did not already
> > exist, and then to keep "personal" values in there, like FP puts things
> > like fp-action="blah" into parent tags, hoping that the user of the tagset,
> > or another tagset is not going to use the same name.
> >
> > FP would make session objects (eg. Hashtable) named "fp.vars" or something,
> > you use your naming scheme. We each prefix by the name of our own tagset
> > and Bob's yer uncle, no trampling.
>
> Well, suppose I create a session, because the user successfully
> authenticated. I put some values in it, then your fp taglib puts some
> more stuff in it. Then the user leaves the confidential area and I kill
> the session and your values are gone. The same thing happens if we do it
> the other way round: you create a session, because the user is beginning
> to use fp. Then he accesses confidential areas and needs to
> authenticate. So I grab your session and put my values in it. Later on
> the user stops using fp, so you kill the session and the user is also
> dis-authenticated automatically.
>
> I think cooperation can only work, if it is 100% clear who creates and
> kills sessions. This calls for a seperate taglib that does just that.
>
Maybe session management should be encapsulated like the output
stream is?
It's not possible that every taglib author has to agree with other authors...
Maybe not making it possible to close sessions?
Hmm...
nicola_ken
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Ulrich Mayring <ul...@denic.de>.
Jeremy Quinn wrote:
>
> I don't know what kind of overhead this produces, or if this is considered
> good practice. It is the only way I can think of handling it safely when
> several TagLibs or Servlets on the same machine could be sharing a session
> object to keep data in.
You are right, so I'll do it like that.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 21:49 +0200 20/07/00, Uli Mayring wrote:
>On Thu, 20 Jul 2000, Jeremy Quinn wrote:
>Yeah, the session times out after one hour in my case, so you
>theoretically can have the user surfing unprotected pages for one hour and
>the servlet engine keeps the session needlessly. Is this overhead
>negligible?
I don't know what kind of overhead this produces, or if this is considered
good practice. It is the only way I can think of handling it safely when
several TagLibs or Servlets on the same machine could be sharing a session
object to keep data in.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
child node
Posted by tc...@dff.st.
Lets say I have a template that is matched
against "text". Now I want to check if there
is a child node named "defaulttext". If there
is one I want to apply it's template.
I was thinking of something like the following but
I guess my XPath syntax for the test is not correct.
XML:
<text>
<sometag>bla</sometag>
<defaulttext>blub</defaulttext>
</text>
XSL:
<xsl:template match="text">
<xsl:choose>
<xsl:when test="@url">
...
</xsl:when>
<xsl:when test="child::defaulttext">
<xsl:apply-templates select="child::defaulttext"/>
</xsl:when>
</xsl:choose>
</xsl:template>
<xsl:template match="defaulttext">
<h1><xsl:apply-templates/></h1>
</xsl:template>
--
Torsten
Re: Cocoon UML Diagrams (in HTML)
Posted by Alex Ferrer <al...@home.com>.
Don't want to get off topic here, (if anyone wants you can email me directly)
but I can't believe that their use (UML) is not wide spread, to me it makes
the process of getting aquainted with a new piece of software much easier.
Anyway yes I built them with TogetherJ, a pretty cool UML tool (pure java) ..
it is pretty expensive (like $2000!) but I got this from their site
www.togethersoft.com, and a 1 month time key to try it.
The diagram builds itself (pretty easy), the printout is also neat, but the
tool itself is really awsome..
Any more info, contact me directly so we dont "contaminate" the list .. I'll
be glad to answer any questions.
alx.
Alex Ferrer
alex@ftconsult.com
Chris Todd wrote:
> OK, my bad, I should have done "View Source" prior to posting this
> question...
>
> So you use Together to produce these kinds of diagrams, huh? Did you have
> to create all the UML diagrams yourself? Did Together generate the Java
> docs and navigation frames automatically? I know this is off-topic, and
> asking for details about a commercial software package that has nothing to
> do with Cocoon, so perhaps you could email me directly. I'd love to know
> what you had to do to produce those web pages (that is, how easy or
> difficult it was).
>
> Sincerest regards,
> Chris Todd
> Software Engineer
> Alabanza Corporation
> ctodd@alabanza.com
>
RE: Cocoon UML Diagrams (in HTML)
Posted by Chris Todd <cl...@bellatlantic.net>.
OK, my bad, I should have done "View Source" prior to posting this
question...
So you use Together to produce these kinds of diagrams, huh? Did you have
to create all the UML diagrams yourself? Did Together generate the Java
docs and navigation frames automatically? I know this is off-topic, and
asking for details about a commercial software package that has nothing to
do with Cocoon, so perhaps you could email me directly. I'd love to know
what you had to do to produce those web pages (that is, how easy or
difficult it was).
Sincerest regards,
Chris Todd
Software Engineer
Alabanza Corporation
ctodd@alabanza.com
> -----Original Message-----
> From: Chris Todd [mailto:cltodd@bellatlantic.net]
> Sent: Saturday, July 22, 2000 1:48 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: Cocoon UML Diagrams (in HTML)
>
>
> OK, I know this is a little off-topic, but those pages are
> really too-cool!
> How did you make them? Is there a software package you used?
> Did you use
> Alexandria? I simply have to know, as my company could
> really make use of
> this kind of coordinated documentation.
>
> Sincerest regards,
> Chris Todd
> Software Engineer
> Alabanza Corporation
> ctodd@alabanza.com
>
>
> > -----Original Message-----
> > From: Alex Ferrer [mailto:alexferrer@home.com]
> > Sent: Thursday, July 22, 1999 12:39 PM
> > To: cocoon-users@xml.apache.org
> > Subject: Cocoon UML Diagrams (in HTML)
> >
> >
> > FYI,
> > This is not a big deal but I made a set of UML diagrams &
> > JavaDocs for cocoon
> > (In HTML) , it is pretty helpfull in understanding the
> > overall picture, if
> > anybody cares for them they are at:
> > http://www.ftconsult.com/cocoonUML/
> >
> > note: you can navigate the diagrams with a click of the mouse.
> >
> > enjoy
> > alx.
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
Re: Cocoon UML Diagrams (in HTML)
Posted by Mark Washeim <31...@t-online.de>.
on 22/7/00 7:47 pm, Chris Todd at cltodd@bellatlantic.net wrote:
> OK, I know this is a little off-topic, but those pages are really too-cool!
> How did you make them? Is there a software package you used? Did you use
> Alexandria? I simply have to know, as my company could really make use of
> this kind of coordinated documentation.
>
> Sincerest regards,
> Chris Todd
> Software Engineer
> Alabanza Corporation
> ctodd@alabanza.com
>
>
>> -----Original Message-----
>> From: Alex Ferrer [mailto:alexferrer@home.com]
>> Sent: Thursday, July 22, 1999 12:39 PM
>> To: cocoon-users@xml.apache.org
>> Subject: Cocoon UML Diagrams (in HTML)
>>
>>
>> FYI,
>> This is not a big deal but I made a set of UML diagrams &
>> JavaDocs for cocoon
>> (In HTML) , it is pretty helpfull in understanding the
>> overall picture, if
>> anybody cares for them they are at:
>> http://www.ftconsult.com/cocoonUML/
>>
>> note: you can navigate the diagrams with a click of the mouse.
>>
>> enjoy
>> alx.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
>> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
Those pages were made with togetherJ the java modeling tool
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
RE: Cocoon UML Diagrams (in HTML)
Posted by Chris Todd <cl...@bellatlantic.net>.
OK, I know this is a little off-topic, but those pages are really too-cool!
How did you make them? Is there a software package you used? Did you use
Alexandria? I simply have to know, as my company could really make use of
this kind of coordinated documentation.
Sincerest regards,
Chris Todd
Software Engineer
Alabanza Corporation
ctodd@alabanza.com
> -----Original Message-----
> From: Alex Ferrer [mailto:alexferrer@home.com]
> Sent: Thursday, July 22, 1999 12:39 PM
> To: cocoon-users@xml.apache.org
> Subject: Cocoon UML Diagrams (in HTML)
>
>
> FYI,
> This is not a big deal but I made a set of UML diagrams &
> JavaDocs for cocoon
> (In HTML) , it is pretty helpfull in understanding the
> overall picture, if
> anybody cares for them they are at:
> http://www.ftconsult.com/cocoonUML/
>
> note: you can navigate the diagrams with a click of the mouse.
>
> enjoy
> alx.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
Cocoon UML Diagrams (in HTML)
Posted by Alex Ferrer <al...@home.com>.
FYI,
This is not a big deal but I made a set of UML diagrams & JavaDocs for cocoon
(In HTML) , it is pretty helpfull in understanding the overall picture, if
anybody cares for them they are at: http://www.ftconsult.com/cocoonUML/
note: you can navigate the diagrams with a click of the mouse.
enjoy
alx.
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Uli Mayring <ul...@denic.de>.
On Sat, 22 Jul 2000, Jeremy Quinn wrote:
> I think there will be a mixture.
> I think Uli want's his TagLib to control the Session itself, while I want
> people to be able to use the Session TagLib mixed in with FP TagLib.
Well, I wanted to, but you guys convinced me to give it up :)
Presently I am putting auth:auth with value "true" into the session,
whenever I request it. That tells me that I have used this session before.
When the user is successfully authenticated I put auth:id with value
[auth-scheme-name] into the session. When the user logs out, I delete all
values from the session, whose names start with auth:
Uli
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 16:31 -0400 21/07/00, Donald Ball wrote:
>> - a method to check, if this session is my session (by passing it the
>> taglib prefix I use)
>> - a method to delete all values starting with the prefix passed to it
>
>ooh, that'd be clever. of course, are y'all using the session taglib from
>your taglibs or talking to the session object directly?
I think there will be a mixture.
I think Uli want's his TagLib to control the Session itself, while I want
people to be able to use the Session TagLib mixed in with FP TagLib.
Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Uli Mayring <ul...@denic.de>.
On Sat, 22 Jul 2000, Jeremy Quinn wrote:
> Identify common functionalities, encode them as TagLibs and all of a sudden
> the number of people who can use them grows outside of Java Programmers.
>
> This is extremely empowering!
Yeah, except that for learning this taglib stuff and finding out what
tags are available the users have to read the Java API and the source code
:-)
Still, you are right, of course, I was speaking from the very narrow point
of view of myself and forgot about the rest of the world. Not good :)
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 01:14 +0200 22/07/00, Uli Mayring wrote:
>On Fri, 21 Jul 2000, Donald Ball wrote:
>
>> ooh, that'd be clever. of course, are y'all using the session taglib from
>> your taglibs or talking to the session object directly?
>
>I'm talking directly, do you think I'm a whimp? :-)
>
>Seriously, I am wondering about the usefulness of the session (and some
>other) taglibs. I mean, if you make a taglib that just wraps the API
>methods, then you don't get anything new. Compare:
>
><response:send-redirect href="somewhere.xml"/>
>
>response.sendRedirect("somewhere.xml");
>
>I mean, what's the point besides aesthetic completeness?
A well designed TagLib lets a non-programmer (who is able to at least
understand the problem) effectively write a Servlet, just by using simple
XML Tags.
I think this is a very important benefit!
>A taglib should be like the util taglib, which incorporates a number of
>really useful functions, which are not available anywhere else.
I would rather deal with a few simple Tags than having Java Code exposed in
my XSP Pages (though this is nice too :).
Identify common functionalities, encode them as TagLibs and all of a sudden
the number of people who can use them grows outside of Java Programmers.
This is extremely empowering!
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sat, 22 Jul 2000, Uli Mayring wrote:
> On Fri, 21 Jul 2000, Donald Ball wrote:
>
> > ooh, that'd be clever. of course, are y'all using the session taglib from
> > your taglibs or talking to the session object directly?
>
> I'm talking directly, do you think I'm a whimp? :-)
>
> Seriously, I am wondering about the usefulness of the session (and some
> other) taglibs. I mean, if you make a taglib that just wraps the API
> methods, then you don't get anything new. Compare:
>
> <response:send-redirect href="somewhere.xml"/>
>
> response.sendRedirect("somewhere.xml");
>
> I mean, what's the point besides aesthetic completeness?
well, not much really, but you can allow authors to use these utility
taglibs while forbidding them from using xsp: elements to call java
directly. that can be handy.
- donald
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Uli Mayring <ul...@denic.de>.
On Fri, 21 Jul 2000, Donald Ball wrote:
> ooh, that'd be clever. of course, are y'all using the session taglib from
> your taglibs or talking to the session object directly?
I'm talking directly, do you think I'm a whimp? :-)
Seriously, I am wondering about the usefulness of the session (and some
other) taglibs. I mean, if you make a taglib that just wraps the API
methods, then you don't get anything new. Compare:
<response:send-redirect href="somewhere.xml"/>
response.sendRedirect("somewhere.xml");
I mean, what's the point besides aesthetic completeness?
A taglib should be like the util taglib, which incorporates a number of
really useful functions, which are not available anywhere else.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 21 Jul 2000, Ulrich Mayring wrote:
> Nicola Ken Barozzi wrote:
> >
> > +1 on the facade.
> > I posted a similar idea some days ago, and this is even better. :-)
> > Don't you guys think it's a good idea?
> > Taglibs have to cooperate without authors sharing implementation
> > details.
> >
> > > Just my thoughts....
> >
> > Hey, you're not alone! :-)
>
> Well, instead of the servlet class name (which will vary depending on
> what directory the XSP page is in) I would use the taglib prefix. And I
> think everyone should always do request.getSession(true) and never
> session.invalidate()
>
> Perhaps we could share some code (or put it in the session taglib):
>
> - a method to check, if this session is my session (by passing it the
> taglib prefix I use)
> - a method to delete all values starting with the prefix passed to it
ooh, that'd be clever. of course, are y'all using the session taglib from
your taglibs or talking to the session object directly?
- donald
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Mark Washeim <31...@t-online.de>.
on 21/7/00 10:20 am, Ulrich Mayring at ulim@denic.de wrote:
> Nicola Ken Barozzi wrote:
>>
>> +1 on the facade.
>> I posted a similar idea some days ago, and this is even better. :-)
>> Don't you guys think it's a good idea?
>> Taglibs have to cooperate without authors sharing implementation
>> details.
>>
>>> Just my thoughts....
>>
>> Hey, you're not alone! :-)
>
> Well, instead of the servlet class name (which will vary depending on
> what directory the XSP page is in) I would use the taglib prefix. And I
> think everyone should always do request.getSession(true) and never
> session.invalidate()
>
Yeah, I thought you and Jeremy were on the money with the tag-lib prefix. I
was simply giving an example from another domain.
> Perhaps we could share some code (or put it in the session taglib):
>
> - a method to check, if this session is my session (by passing it the
> taglib prefix I use)
> - a method to delete all values starting with the prefix passed to it
>
> Ulrich
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Ulrich Mayring <ul...@denic.de>.
Nicola Ken Barozzi wrote:
>
> +1 on the facade.
> I posted a similar idea some days ago, and this is even better. :-)
> Don't you guys think it's a good idea?
> Taglibs have to cooperate without authors sharing implementation
> details.
>
> > Just my thoughts....
>
> Hey, you're not alone! :-)
Well, instead of the servlet class name (which will vary depending on
what directory the XSP page is in) I would use the taglib prefix. And I
think everyone should always do request.getSession(true) and never
session.invalidate()
Perhaps we could share some code (or put it in the session taglib):
- a method to check, if this session is my session (by passing it the
taglib prefix I use)
- a method to delete all values starting with the prefix passed to it
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Mark Washeim" <31...@t-online.de>
To: <co...@xml.apache.org>
Sent: Thursday, July 20, 2000 10:19 PM
Subject: Re: cooperative session handling (was: Dynamic XML generation)
> on 20/7/00 9:49 pm, Uli Mayring at ulim@denic.de wrote:
>
> > On Thu, 20 Jul 2000, Jeremy Quinn wrote:
> >
> >> so your taglib could do something like this:
> >>
> >> if there a session?
> >> if it contains my auth.stuff?
> >> go for it
> >> else
> >> login
> >> else
> >> make one
> >
> > Yeah, that's what I'm doing with the only difference that I care about
> > invalidating sessions. More below.
> >
> >> When you want to log a user out, you remove your auth:stuff from the
> >> Session, and only invalidate the session if it contains nothing else. In
> >> fact due to the multithreaded nature of the Beast, it would probably be
> >> safer never to invalidate a session, in case something else was about to
> >> use it.
> >
> > What's the session.invalidate() method for, then? Sorry if I sound dumb,
> > but I believe Sun doesn't implement random methods for fun and profits. It
> > would be much, much easier for me to implement auth: if I didn't have to
> > worry about invalidating sessions. So I am really not reluctant to take
> > your advice, it just "feels bad" not to clean up :)
> >
> >> Reading the Servlet Spec ....
> >> Sessions should be automatically invalidated by the server or Servlet
> >> engine, there should be a setting for "session persistence" in your engine.
> >> Servers can offload active sessions to file if memory gets constrained.
> >
> > Yeah, the session times out after one hour in my case, so you
> > theoretically can have the user surfing unprotected pages for one hour and
> > the servlet engine keeps the session needlessly. Is this overhead
> > negligible?
> >
> > Ulrich
>
>
> Just my two bits.
>
> In most cases where any significant number of applications are running,
> namely, most public websites running servlets, there is rarely a need for
> any individual servlet to invalidate the session.
>
> In fact, there is more overhead in the creation of session objects than
> called for.
>
> Our application framework hides the session from individual servlets and
> 'pools' the session objects, as it were. We found that running dozens of
> servlets for any given client required the session practically persistantly
> and so, added a facade to it...
>
> The facade ensures unique identity for names of keys by prefixing the
> servlet class name.
+1 on the facade.
I posted a similar idea some days ago, and this is even better. :-)
Don't you guys think it's a good idea?
Taglibs have to cooperate without authors sharing implementation
details.
> Just my thoughts....
Hey, you're not alone! :-)
nicola_ken
Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Personal homepage at Java Guru:
http://www.jguru.com/jguru/guru/viewchannel.jsp?EID=39153
Personal FAQ at Java Guru:
http://www.jguru.com/jguru/guru/viewfaqs.jsp?EID=39153
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Mark Washeim <31...@t-online.de>.
on 20/7/00 9:49 pm, Uli Mayring at ulim@denic.de wrote:
> On Thu, 20 Jul 2000, Jeremy Quinn wrote:
>
>> so your taglib could do something like this:
>>
>> if there a session?
>> if it contains my auth.stuff?
>> go for it
>> else
>> login
>> else
>> make one
>
> Yeah, that's what I'm doing with the only difference that I care about
> invalidating sessions. More below.
>
>> When you want to log a user out, you remove your auth:stuff from the
>> Session, and only invalidate the session if it contains nothing else. In
>> fact due to the multithreaded nature of the Beast, it would probably be
>> safer never to invalidate a session, in case something else was about to
>> use it.
>
> What's the session.invalidate() method for, then? Sorry if I sound dumb,
> but I believe Sun doesn't implement random methods for fun and profits. It
> would be much, much easier for me to implement auth: if I didn't have to
> worry about invalidating sessions. So I am really not reluctant to take
> your advice, it just "feels bad" not to clean up :)
>
>> Reading the Servlet Spec ....
>> Sessions should be automatically invalidated by the server or Servlet
>> engine, there should be a setting for "session persistence" in your engine.
>> Servers can offload active sessions to file if memory gets constrained.
>
> Yeah, the session times out after one hour in my case, so you
> theoretically can have the user surfing unprotected pages for one hour and
> the servlet engine keeps the session needlessly. Is this overhead
> negligible?
>
> Ulrich
Just my two bits.
In most cases where any significant number of applications are running,
namely, most public websites running servlets, there is rarely a need for
any individual servlet to invalidate the session.
In fact, there is more overhead in the creation of session objects than
called for.
Our application framework hides the session from individual servlets and
'pools' the session objects, as it were. We found that running dozens of
servlets for any given client required the session practically persistantly
and so, added a facade to it...
The facade ensures unique identity for names of keys by prefixing the
servlet class name.
Just my thoughts....
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Uli Mayring <ul...@denic.de>.
On Thu, 20 Jul 2000, Donald Ball wrote:
> what you could do is when you get the session instance, if you created
> it, record the fact that you created it. when you're done, if the session
> is otherwise empty, invalidate it.
That's precisely what I'm doing. Or, better, what I'm trying to do,
because I don't get it to work :)
It's really much harder than it sounds, at least if you're trying to make
it as user-friendly as possible.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 20 Jul 2000, Uli Mayring wrote:
> > When you want to log a user out, you remove your auth:stuff from the
> > Session, and only invalidate the session if it contains nothing else. In
> > fact due to the multithreaded nature of the Beast, it would probably be
> > safer never to invalidate a session, in case something else was about to
> > use it.
>
> What's the session.invalidate() method for, then? Sorry if I sound dumb,
> but I believe Sun doesn't implement random methods for fun and profits. It
> would be much, much easier for me to implement auth: if I didn't have to
> worry about invalidating sessions. So I am really not reluctant to take
> your advice, it just "feels bad" not to clean up :)
what you could do is when you get the session instance, if you created
it, record the fact that you created it. when you're done, if the session
is otherwise empty, invalidate it.
like so much else in the servlet spec, i don't think sun thought through
all of the issues perfectly beforehand. well, hindsight is colorblind.
- donald
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Uli Mayring <ul...@denic.de>.
On Thu, 20 Jul 2000, Jeremy Quinn wrote:
> so your taglib could do something like this:
>
> if there a session?
> if it contains my auth.stuff?
> go for it
> else
> login
> else
> make one
Yeah, that's what I'm doing with the only difference that I care about
invalidating sessions. More below.
> When you want to log a user out, you remove your auth:stuff from the
> Session, and only invalidate the session if it contains nothing else. In
> fact due to the multithreaded nature of the Beast, it would probably be
> safer never to invalidate a session, in case something else was about to
> use it.
What's the session.invalidate() method for, then? Sorry if I sound dumb,
but I believe Sun doesn't implement random methods for fun and profits. It
would be much, much easier for me to implement auth: if I didn't have to
worry about invalidating sessions. So I am really not reluctant to take
your advice, it just "feels bad" not to clean up :)
> Reading the Servlet Spec ....
> Sessions should be automatically invalidated by the server or Servlet
> engine, there should be a setting for "session persistence" in your engine.
> Servers can offload active sessions to file if memory gets constrained.
Yeah, the session times out after one hour in my case, so you
theoretically can have the user surfing unprotected pages for one hour and
the servlet engine keeps the session needlessly. Is this overhead
negligible?
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 15:52 +0200 20/07/00, Ulrich Mayring wrote:
>> yea, let XSP make the session for you.
>> why bother invalidating the session?
>
>How does XSP know when I need a session and when not?
Users of your taglib would do this
<xsp:page create-session="true">
<your stuff/>
</xsp:page>
I'm guessing ....
Your TagLib would look to see it it's own things were set up in the session
or not, the existence or not of the session is not the key, obviously if
there is no session at all you can do something about it, but you cannot
assume there will not already be one, maybe created by another
TagLib/Servlet whatever with it's stuff in it.
so your taglib could do something like this:
if there a session?
if it contains my auth.stuff?
go for it
else
login
else
make one -- this would save users remembering to do create-session="true"
login
When you want to log a user out, you remove your auth:stuff from the
Session, and only invalidate the session if it contains nothing else. In
fact due to the multithreaded nature of the Beast, it would probably be
safer never to invalidate a session, in case something else was about to
use it.
> I don't want sessions to hang around forever, this is overhead and a security
> issue.
Reading the Servlet Spec ....
Sessions should be automatically invalidated by the server or Servlet
engine, there should be a setting for "session persistence" in your engine.
Servers can offload active sessions to file if memory gets constrained.
hope this helps
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 16:03 +0200 20/07/00, Mark Washeim wrote:
>
>:) My solution is to use cookies, when I need to persist something
>indefinately. It's a bit more hassle, but it's more reliable.
Cool, your users become your user info database :)
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Mark Washeim <31...@t-online.de>.
on 20/7/00 3:52 pm, Ulrich Mayring at ulim@denic.de wrote:
> Jeremy Quinn wrote:
>>
>> yea, let XSP make the session for you.
>> why bother invalidating the session?
>
> How does XSP know when I need a session and when not? I don't want
> sessions to hang around forever, this is overhead and a security issue.
>
> Ulrich
Not to mention load-balancers will often invalidate your sessions in any
case.
This is a fairly serious problem that pertains to a higher level problem.
Namely, behaviours outside of the cocoon context which you cann't even
predict the behaviour of.
In the case of eurofootball, I'm fighting a load balancer that times
sessions out after 10 minutes! And that's to keep the load balancer for ...
crashing because of load!
:) My solution is to use cookies, when I need to persist something
indefinately. It's a bit more hassle, but it's more reliable.
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Ulrich Mayring <ul...@denic.de>.
Jeremy Quinn wrote:
>
> yea, let XSP make the session for you.
> why bother invalidating the session?
How does XSP know when I need a session and when not? I don't want
sessions to hang around forever, this is overhead and a security issue.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 12:35 +0200 20/07/00, Ulrich Mayring wrote:
>Jeremy Quinn wrote:
>>
>> So instead of invalidating the whole session, just remove your stuff from
>> it
>> (just keep your hands of my values, right? :)
>
>I think what we need to do is this:
>
>to create a session or use an existing one:
> request.getSession(true);
> if (((String) session.getValue("myprefix:myprefix")).equals("true")) {
> // my session already exists
> }
> else {
> // this session is a new one for me (but may have existed before for
>another taglib)
> session.putValue("myprefix:myprefix","true");
> }
>
>to save values in a session:
> session.putValue("myprefix:myname",value);
>
>to get values from a session:
> session.getValue("myprefix:myname",value);
>
>to end my session:
> remove all myprefix:* values from session
> check if there are any other values left (are there any "standard"
>values, which we must ignore?)
> if yes: do nothing
> if no: session.invalidate();
>
>I am using session.getValue and session.putValue here, which are
>deprecated as of JSDK2.2, but I think we should use them for backwards
>compatibility to JSDK2.1 (which JServ needs).
>
>Any comments?
yea, let XSP make the session for you.
why bother invalidating the session?
Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
cooperative session handling (was: Dynamic XML generation)
Posted by Ulrich Mayring <ul...@denic.de>.
Jeremy Quinn wrote:
>
> So instead of invalidating the whole session, just remove your stuff from
> it
> (just keep your hands of my values, right? :)
I think what we need to do is this:
to create a session or use an existing one:
request.getSession(true);
if (((String) session.getValue("myprefix:myprefix")).equals("true")) {
// my session already exists
}
else {
// this session is a new one for me (but may have existed before for
another taglib)
session.putValue("myprefix:myprefix","true");
}
to save values in a session:
session.putValue("myprefix:myname",value);
to get values from a session:
session.getValue("myprefix:myname",value);
to end my session:
remove all myprefix:* values from session
check if there are any other values left (are there any "standard"
values, which we must ignore?)
if yes: do nothing
if no: session.invalidate();
I am using session.getValue and session.putValue here, which are
deprecated as of JSDK2.2, but I think we should use them for backwards
compatibility to JSDK2.1 (which JServ needs).
Any comments?
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Dynamic XML generation
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 17:05 +0200 19/07/00, Ulrich Mayring wrote:
>Jeremy Quinn wrote:
>>
>> I am assuming (I never used session before) that it would be possible for
>> both of our taglibs to only create a new session if one did not already
>> exist, and then to keep "personal" values in there, like FP puts things
>> like fp-action="blah" into parent tags, hoping that the user of the tagset,
>> or another tagset is not going to use the same name.
>>
>> FP would make session objects (eg. Hashtable) named "fp.vars" or something,
>> you use your naming scheme. We each prefix by the name of our own tagset
>> and Bob's yer uncle, no trampling.
>
>Well, suppose I create a session, because the user successfully
>authenticated. I put some values in it, then your fp taglib puts some
>more stuff in it. Then the user leaves the confidential area and I kill
>the session and your values are gone.
So instead of invalidating the whole session, just remove your stuff from it
(just keep your hands of my values, right? :)
[snip]
>I think cooperation can only work, if it is 100% clear who creates and
>kills sessions. This calls for a seperate taglib that does just that.
I think that if you put:
<xsp:page create-session="true">
<your_stuff/>
</xsp:page>
A session is only created if one did not exist already.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: Dynamic XML generation
Posted by Ulrich Mayring <ul...@denic.de>.
Jeremy Quinn wrote:
>
> I am assuming (I never used session before) that it would be possible for
> both of our taglibs to only create a new session if one did not already
> exist, and then to keep "personal" values in there, like FP puts things
> like fp-action="blah" into parent tags, hoping that the user of the tagset,
> or another tagset is not going to use the same name.
>
> FP would make session objects (eg. Hashtable) named "fp.vars" or something,
> you use your naming scheme. We each prefix by the name of our own tagset
> and Bob's yer uncle, no trampling.
Well, suppose I create a session, because the user successfully
authenticated. I put some values in it, then your fp taglib puts some
more stuff in it. Then the user leaves the confidential area and I kill
the session and your values are gone. The same thing happens if we do it
the other way round: you create a session, because the user is beginning
to use fp. Then he accesses confidential areas and needs to
authenticate. So I grab your session and put my values in it. Later on
the user stops using fp, so you kill the session and the user is also
dis-authenticated automatically.
I think cooperation can only work, if it is 100% clear who creates and
kills sessions. This calls for a seperate taglib that does just that.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Dynamic XML generation
Posted by Mark Washeim <31...@t-online.de>.
on 19/7/00 4:14 pm, Jeremy Quinn at jeremy@media.demon.co.uk wrote:
> At 09:49 +0200 19/07/00, Ulrich Mayring wrote:
>>>> Dang. If you use the session taglib to pass data around in fp and I use
>>>> it
>>>> to manage authentication, then your taglib and mine will not be
>>>> inter-operable, right?
>>>
>>> why would that be?
>>
>> Suppose I create a session, when the user has successfully
>> authenticated. With this session I send the user into the protected
>> pages, which could contain some fp stuff. fp now manipulates the session
>> object for its needs - writing things into it and possibly overwriting
>> my things. Perhaps fp even invalidates and re-creates sessions, I don't
>> know.
>
> I am assuming (I never used session before) that it would be possible for
> both of our taglibs to only create a new session if one did not already
> exist, and then to keep "personal" values in there, like FP puts things
> like fp-action="blah" into parent tags, hoping that the user of the tagset,
> or another tagset is not going to use the same name.
>
> FP would make session objects (eg. Hashtable) named "fp.vars" or something,
> you use your naming scheme. We each prefix by the name of our own tagset
> and Bob's yer uncle, no trampling.
>
> hope this helps
>
> regards Jeremy
One way you can keep session stored values from colliding is to be sparse.
I do the following, often.
Use the sessioID (Jserv or tomcat) or the servletName as the key and then
store a hash of my value pairs . . .
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: Dynamic XML generation
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 09:49 +0200 19/07/00, Ulrich Mayring wrote:
>> > Dang. If you use the session taglib to pass data around in fp and I use
>> > it
>> > to manage authentication, then your taglib and mine will not be
>> > inter-operable, right?
>>
>> why would that be?
>
>Suppose I create a session, when the user has successfully
>authenticated. With this session I send the user into the protected
>pages, which could contain some fp stuff. fp now manipulates the session
>object for its needs - writing things into it and possibly overwriting
>my things. Perhaps fp even invalidates and re-creates sessions, I don't
>know.
I am assuming (I never used session before) that it would be possible for
both of our taglibs to only create a new session if one did not already
exist, and then to keep "personal" values in there, like FP puts things
like fp-action="blah" into parent tags, hoping that the user of the tagset,
or another tagset is not going to use the same name.
FP would make session objects (eg. Hashtable) named "fp.vars" or something,
you use your naming scheme. We each prefix by the name of our own tagset
and Bob's yer uncle, no trampling.
hope this helps
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: Dynamic XML generation
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 19 Jul 2000, Ulrich Mayring wrote:
> Donald Ball wrote:
> >
> > On Wed, 19 Jul 2000, Uli Mayring wrote:
> >
> > > Dang. If you use the session taglib to pass data around in fp and I use
> > > it
> > > to manage authentication, then your taglib and mine will not be
> > > inter-operable, right?
> >
> > why would that be?
>
> Suppose I create a session, when the user has successfully
> authenticated. With this session I send the user into the protected
> pages, which could contain some fp stuff. fp now manipulates the session
> object for its needs - writing things into it and possibly overwriting
> my things. Perhaps fp even invalidates and re-creates sessions, I don't
> know.
that's a common problem with sessions. solution - use namespace-like names
when using sessions, and don't ever invalidate a session if it's not
empty. e.g. your authentication logicsheet could use objects named with
the 'auth:' prefix, while jeremy's stuff could use the 'fp:' prefix.
- donald
Re: Dynamic XML generation
Posted by Ulrich Mayring <ul...@denic.de>.
Donald Ball wrote:
>
> On Wed, 19 Jul 2000, Uli Mayring wrote:
>
> > Dang. If you use the session taglib to pass data around in fp and I use
> > it
> > to manage authentication, then your taglib and mine will not be
> > inter-operable, right?
>
> why would that be?
Suppose I create a session, when the user has successfully
authenticated. With this session I send the user into the protected
pages, which could contain some fp stuff. fp now manipulates the session
object for its needs - writing things into it and possibly overwriting
my things. Perhaps fp even invalidates and re-creates sessions, I don't
know.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Dynamic XML generation
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 19 Jul 2000, Uli Mayring wrote:
> On Tue, 18 Jul 2000, Jeremy Quinn wrote:
>
> > Why not use sessions and save passing the data around the net?
> > I was about to try this with the FP TagLib. I am hoping you should be able
> > to mix FP and the Request TagLib with the Session TagLib to do this.
>
> Dang. If you use the session taglib to pass data around in fp and I use it
> to manage authentication, then your taglib and mine will not be
> inter-operable, right?
why would that be?
- donald
Re: Dynamic XML generation
Posted by Uli Mayring <ul...@denic.de>.
On Tue, 18 Jul 2000, Jeremy Quinn wrote:
> Why not use sessions and save passing the data around the net?
> I was about to try this with the FP TagLib. I am hoping you should be able
> to mix FP and the Request TagLib with the Session TagLib to do this.
Dang. If you use the session taglib to pass data around in fp and I use it
to manage authentication, then your taglib and mine will not be
inter-operable, right?
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: Dynamic XML generation
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 18:11 +0200 18/07/00, Klaus Malorny wrote:
>> <xsp:page language="java" xmlns:xsp="http://www.apache.org/1999/XSP/Core">
>> <document>
>> <error><xsp:expr>(String) request.getAttribute("error")</xsp:expr></error>
>> </document>
>> </xsp:page>
>>
>> Mike
>>
>
>
>Thanks for this trick, since I am a Cocoon novice similar to Patrick and got
>the same questions like him. It nicely solves the problem I have for
>multi-page forms with 'next' and 'prev' buttons, since depending on the button
>and the contents of the current page I have to display the previous, current
>(evenutally with error messages) or next page. It also allows the seperation
>of the data processing and the presentation, although I'm not quite sure how
>to do this the best way.
>
>BTW, it seems that setAttribute is a method of Request instead of
>RequestDispatcher.
Does this work by placing the attributes in the request HTTP header?
How are they encoded?
Why not use sessions and save passing the data around the net?
I was about to try this with the FP TagLib. I am hoping you should be able
to mix FP and the Request TagLib with the Session TagLib to do this.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
http://www.eurofootball.com/
Posted by Mark Washeim <es...@canuck.com>.
Finally.
Ok, some weeks after I'd hoped to have this live: eurofootball is now
running on cocoon-power . . .
We're running 1.7.5-dev with minor modifications:
1. XSPProcessor modified to permit XSP page caching to work (I think this
one is working it's way into the repository, Stefano?)
2. Utils.java, browser type encoding disabled for page caching
Both, naturally, measures to reduce the number of requests to the cache and
the number of xsp processing cycles . . .
Any feedback about performance, errors, deficits are greatly appreciated . .
.
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: Dynamic XML generation
Posted by Mike Engelhart <me...@earthtrip.com>.
on 7/18/00 11:11 AM, Klaus Malorny at Klaus.Malorny@knipp.de wrote:
> Thanks for this trick, since I am a Cocoon novice similar to Patrick and got
> the same questions like him. It nicely solves the problem I have for
> multi-page forms with 'next' and 'prev' buttons, since depending on the button
> and the contents of the current page I have to display the previous, current
> (evenutally with error messages) or next page. It also allows the seperation
> of the data processing and the presentation, although I'm not quite sure how
> to do this the best way.
No problem. I do this because it makes it easier to maintain my code
because I don't have a ton of logic in my XSP's even though you can do that
as well.
> BTW, it seems that setAttribute is a method of Request instead of
> RequestDispatcher.
Ooops... that was a typo. it should be:
RequestDispatcher rd = request.getRequestDispatcher("/xml/login.xml");
request.setAtttribute("error", "The user name and password you selected were
invalid");
rd.forward(request, response);
thanks,
Mike
Re: Dynamic XML generation
Posted by Klaus Malorny <Kl...@knipp.de>.
Mike Engelhart wrote:
>
> on 7/18/00 9:36 AM, Patrick Roemer at roemer@cs.uni-bonn.de wrote:
>
> > Hi,
> >
> > I'm a Cocoon beginner and I'm sure you have read this question before,
> > but I haven't been able to find a consistent answer in all the mailing
> > list archives I've searched, so please help me out.
> >
> > I have a servlet that checks access authorization by username and
> > password, send a database request and outputs the result in HTML.
> > Authorization and database access are handled by separate classes, so
> > the servlet itself is quite lightweight.
> >
> Just use a RequestDispatcher in your servlet and send it to either an XSP
> (if you need the output to be dynamic) or to an .xml file.
>
> So in your servlet you'd have something like:
>
> RequestDispatcher rd = request.getRequestDispatcher("/xml/login.xml");
> // if you want you can put objects into the request
> // and pull them out again in an XSP or else just forward the request object
> // this example puts a simple error string into the request object via
> // setAttribute() and then the XSP adds it to the XML document on the fly
> rd.setAtttribute("error", "The user name and password you selected were
> invalid");
> rd.forward(request, response);
>
> then in say an XSP, you can do this:
>
> <?xml version="1.0"?>
>
> <?cocoon-process type="xsp"?>
> <?cocoon-process type="xslt"?>
>
> <?xml-stylesheet href="error.xsl" type="text/xsl"?>
>
> <xsp:page language="java" xmlns:xsp="http://www.apache.org/1999/XSP/Core">
> <document>
> <error><xsp:expr>(String) request.getAttribute("error")</xsp:expr></error>
> </document>
> </xsp:page>
>
> Mike
>
Thanks for this trick, since I am a Cocoon novice similar to Patrick and got
the same questions like him. It nicely solves the problem I have for
multi-page forms with 'next' and 'prev' buttons, since depending on the button
and the contents of the current page I have to display the previous, current
(evenutally with error messages) or next page. It also allows the seperation
of the data processing and the presentation, although I'm not quite sure how
to do this the best way.
BTW, it seems that setAttribute is a method of Request instead of
RequestDispatcher.
regards
Klaus
Re: Dynamic XML generation
Posted by Mike Engelhart <me...@earthtrip.com>.
on 7/18/00 9:36 AM, Patrick Roemer at roemer@cs.uni-bonn.de wrote:
> Hi,
>
> I'm a Cocoon beginner and I'm sure you have read this question before,
> but I haven't been able to find a consistent answer in all the mailing
> list archives I've searched, so please help me out.
>
> I have a servlet that checks access authorization by username and
> password, send a database request and outputs the result in HTML.
> Authorization and database access are handled by separate classes, so
> the servlet itself is quite lightweight.
>
Just use a RequestDispatcher in your servlet and send it to either an XSP
(if you need the output to be dynamic) or to an .xml file.
So in your servlet you'd have something like:
RequestDispatcher rd = request.getRequestDispatcher("/xml/login.xml");
// if you want you can put objects into the request
// and pull them out again in an XSP or else just forward the request object
// this example puts a simple error string into the request object via
// setAttribute() and then the XSP adds it to the XML document on the fly
rd.setAtttribute("error", "The user name and password you selected were
invalid");
rd.forward(request, response);
then in say an XSP, you can do this:
<?xml version="1.0"?>
<?cocoon-process type="xsp"?>
<?cocoon-process type="xslt"?>
<?xml-stylesheet href="error.xsl" type="text/xsl"?>
<xsp:page language="java" xmlns:xsp="http://www.apache.org/1999/XSP/Core">
<document>
<error><xsp:expr>(String) request.getAttribute("error")</xsp:expr></error>
</document>
</xsp:page>
Mike
Dynamic XML generation
Posted by Patrick Roemer <ro...@cs.uni-bonn.de>.
Hi,
I'm a Cocoon beginner and I'm sure you have read this question before,
but I haven't been able to find a consistent answer in all the mailing
list archives I've searched, so please help me out.
I have a servlet that checks access authorization by username and
password, send a database request and outputs the result in HTML.
Authorization and database access are handled by separate classes, so
the servlet itself is quite lightweight.
Now I would like to 'Cocoon-enable' this application. My first try was
to convert the servlet into a producer. This works fine, but there
remain a few problems. For example, the authorization should not be part
of the production process: In the original servlet I redirected the user
to the login page on authentication fail. Now the producer (resp.
authenticator) has to come up with some mockup XHTML code that
reproduces the login page. So I am looking for an approach that handles
authentication separately and then has Cocoon do its work.
My next consideration was having the servlet handle the authorization
and then explicitly call the Cocoon engine. But this use has been
strictly discouraged in all the postings I've seen, since Cocoon
shouldn't be used as an API (sounds sensible to me).
I think I'm still missing some insight into the overall Cocoon
architecture. Could someone point me to a more in-depth description of
its design, or (maybe even better) to some sample code handling dynamic
XML generation and tasks other than pure content generation that is a
bit less trivial than DummyProducer et al?
Thank you very much in advance,
Patrick
newbie
Posted by Ray Hilton <ra...@londonsocial.com>.
Hi peeps, im new to all this lark, and trying to learn all this stuff in not
very much time at all.
Anyway, i have cocoon running under tomcat, with apache and php. Now i know
you can dynamically generate it using some sort of jsp/xsp stylee thingy,
but is it possible to say, preprocess in php first and then execute the xml
through cocoon? or would this just be longwinded and inefficient?
and is a java/jdbc the only option available for database generated content?
cheers for your help,
ray
Re: urgent: 1.7.5
Posted by Jeff Turner <je...@socialchange.net.au>.
Torsten Curdt wrote:
[snip stuff I can't answer..sorry;]
> > java.lang.RuntimeException: Error creating
> > org.apache.cocoon.processor.xsp.XSPProcessor:
> > make sure the needed classes can be found in the classpath
> > (org/apache/java/util/ConfigurationsRepository)
> > at org.apache.cocoon.framework.Manager.create(Manager.java:114)
> > at org.apache.cocoon.framework.Router.init(Router.java:80)
> >
> > I tracked it down and it seems to be the configuration repository of the
> > connection pool.
> > The problem is: like cocoon... I don't find this a class either! Shouldn't
> > it be inside the turbine-pool.jar ?!
I'd just like to jump in here promote Kevin Burton's 'classman' tool
for managing CLASSPATHs. For example, to search all the jars in my
CLASSPATH for your missing class "ConfigurationsRepository":
~/java/classman$ classman --find ConfigurationsRepository
/home/jeff/java/lib/turbine.jar
ConfigurationsRepository ->
org.apache.java.util.ConfigurationsRepository
In turbine.jar, not turbine-pool.jar. Cool, no? :)
The URL is http://relativity.yi.org/classman/
--Jeff