Nabble - Turbine - User

Re: ACL serialization.

2009-12-19T02:25:21Z

Sheldon Ross wrote:
> Alright, success, multiple tomcats running, and sessions are persistent and clustered.
[...]

Glad to hear that it finally worked out for you. Thanks for your
analysis. It may be useful for others as well.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

RE: ACL serialization.

2009-12-18T13:47:30Z

Alright, success, multiple tomcats running, and sessions are persistent and clustered.

I did have to add

if(!TurbineSession.getActiveSessions().contains(req.getSession()))
TurbineSession.addSession(req.getSession());

to Turbine.java. Right now, Sessions are only added in SessionListener.java when they are created.
When the server restarts, it reloads the sessions - so they are not new.
So TurbineSession.getActiveSessions does not contain the existing sessions.

Also due to this bug
http://www.mail-archive.com/dev@.../msg18838.html

That exists in the version of Tomcat my distro uses, I had to set change these lines

// if (data.getSession().isNew())
// {
int timeout = configuration.getInt(SESSION_TIMEOUT_KEY,
SESSION_TIMEOUT_DEFAULT);

if (timeout != SESSION_TIMEOUT_DEFAULT && data.getSession().getMaxInactiveInterval() != timeout)
{
data.getSession().setMaxInactiveInterval(timeout);
}
// }

Just in case anyone else has issues replicating sessions.

Oh, and I had downloaded the Turbine 2.3.2 source in which the TorqueObject is not serializable.
2.3.3 has this fixed.

> From: ross_sheldon@...
> To: user@...
> Subject: RE: ACL serialization.
> Date: Fri, 18 Dec 2009 20:33:59 +0000
>
>
> Alright, I solved the problem.
>
> The TorqueObject.java I had apparently was old. (I swear I just downloaded the source about a month ago)
>
> It didn't implement Serializable, therefore the
>
> obj in TorqueUser was not saving. Which was odd because I figured it should crash, but everything else about
> TorqueUser was serializing fine. How does half an object serialize, and the other parts not?
>
> Oh well, now I just have to figure out how to get the activesessions to save.
>
> My sessions restore, and I can perform actions/access pages correctly. But my admin list of who's logged on
> is empty.
>
> > Date: Fri, 18 Dec 2009 18:17:43 +0100
> > From: tv@...
> > To: user@...
> > Subject: Re: ACL serialization.
> >
> > Sheldon Ross wrote:
> > > At the start it makes a distinction between permanent storage,
> > > and temporary. These appear to refer to (database) and (session)
> > > respectively. The problem lies with the fact that there is no link between
> > > the two.
> >
> > I cannot confirm this. data.getUser() provides the user object from the
> > session, where it is stored as User.SESSION_KEY.
> >
> > Likewise, the ACL for the user that you get with data.getACL() is stored
> > in the session as AccessControlList.SESSION_KEY.
> >
> > > The underlying user account object is stored in permanent storage
> > > and as such, if you update it's name, email, etc, it updates the permanent
> > > storage object in memory. However, the session has no record of this.
> >
> > It would have, if you manipulate the user object in the session. The
> > user object has a save()-method.
> >
> > > This appears to be a serious limitation for sharing sessions across server nodes.
> >
> > I guess the problem is just that the user/acl implementation is not
> > serializable for some reason.
> >
> > >> So I set the user and acl when someone logs in via
> > >>
> > >> user = TurbineSecurity.getAuthenticatedUser( username, password );
> > >> data.setUser(user);
> > >>
> > >> and the aforementioned ACL code.
> >
> > This is actually part of the session validator code.
> >
> > >>> data.save();
> >
> > This only saves the user object to the session, not the ACL. The ACL is
> > built and saved to the session by the AccessController.
> >
> > >>> Any thoughts as to what I'm doing wrong, and how I can get the ACL to persist with the
> > >>> session?
> >
> > If objects stored in the session are not serializable, Tomcat will log
> > that during shutdown or during startup. See your Tomcat logs for what
> > really happens.
> >
> > This problem looks strange to me. What session validators,
> > ACL-implementations or other security-related settings do you have in place?
> >
> > Bye, Thomas.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@...
> > For additional commands, e-mail: user-help@...
> >
>
> _________________________________________________________________
> Hotmail: Powerful Free email with security by Microsoft.
> http://clk.atdmt.com/GBL/go/171222986/direct/01/

_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141665/direct/01/

RE: ACL serialization.

2009-12-18T12:33:59Z

Alright, I solved the problem.

The TorqueObject.java I had apparently was old. (I swear I just downloaded the source about a month ago)

It didn't implement Serializable, therefore the

obj in TorqueUser was not saving. Which was odd because I figured it should crash, but everything else about
TorqueUser was serializing fine. How does half an object serialize, and the other parts not?

Oh well, now I just have to figure out how to get the activesessions to save.

My sessions restore, and I can perform actions/access pages correctly. But my admin list of who's logged on
is empty.

> Date: Fri, 18 Dec 2009 18:17:43 +0100
> From: tv@...
> To: user@...
> Subject: Re: ACL serialization.
>
> Sheldon Ross wrote:
> > At the start it makes a distinction between permanent storage,
> > and temporary. These appear to refer to (database) and (session)
> > respectively. The problem lies with the fact that there is no link between
> > the two.
>
> I cannot confirm this. data.getUser() provides the user object from the
> session, where it is stored as User.SESSION_KEY.
>
> Likewise, the ACL for the user that you get with data.getACL() is stored
> in the session as AccessControlList.SESSION_KEY.
>
> > The underlying user account object is stored in permanent storage
> > and as such, if you update it's name, email, etc, it updates the permanent
> > storage object in memory. However, the session has no record of this.
>
> It would have, if you manipulate the user object in the session. The
> user object has a save()-method.
>
> > This appears to be a serious limitation for sharing sessions across server nodes.
>
> I guess the problem is just that the user/acl implementation is not
> serializable for some reason.
>
> >> So I set the user and acl when someone logs in via
> >>
> >> user = TurbineSecurity.getAuthenticatedUser( username, password );
> >> data.setUser(user);
> >>
> >> and the aforementioned ACL code.
>
> This is actually part of the session validator code.
>
> >>> data.save();
>
> This only saves the user object to the session, not the ACL. The ACL is
> built and saved to the session by the AccessController.
>
> >>> Any thoughts as to what I'm doing wrong, and how I can get the ACL to persist with the
> >>> session?
>
> If objects stored in the session are not serializable, Tomcat will log
> that during shutdown or during startup. See your Tomcat logs for what
> really happens.
>
> This problem looks strange to me. What session validators,
> ACL-implementations or other security-related settings do you have in place?
>
> Bye, Thomas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>

_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/

RE: ACL serialization.

2009-12-18T12:14:26Z

The User is stored in the session.

At the top of TorqueUser.java
http://turbine.apache.org/turbine/turbine-2.3.3/xref/org/apache/turbine/services/security/torque/TorqueUser.html

/*** This is data that will survive a servlet engine restart. */
62 private Hashtable permStorage = null;
63
64 /*** This is data that will not survive a servlet engine restart. */
65 private Hashtable tempStorage = null;

When I restart Tomcat, The tempStorage (ironically) is serialized and saved.
The permStorage does not get saved for some reason.

Nothing is crashing, catalina.out is clean, and everything else serializes fine.

Ross

_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/

Re: ACL serialization.

2009-12-18T09:17:43Z

Sheldon Ross wrote:
> At the start it makes a distinction between permanent storage,
> and temporary. These appear to refer to (database) and (session)
> respectively. The problem lies with the fact that there is no link between
> the two.

I cannot confirm this. data.getUser() provides the user object from the
session, where it is stored as User.SESSION_KEY.

Likewise, the ACL for the user that you get with data.getACL() is stored
in the session as AccessControlList.SESSION_KEY.

> The underlying user account object is stored in permanent storage
> and as such, if you update it's name, email, etc, it updates the permanent
> storage object in memory. However, the session has no record of this.

It would have, if you manipulate the user object in the session. The
user object has a save()-method.

> This appears to be a serious limitation for sharing sessions across server nodes.

I guess the problem is just that the user/acl implementation is not
serializable for some reason.

>> So I set the user and acl when someone logs in via
>>
>> user = TurbineSecurity.getAuthenticatedUser( username, password );
>> data.setUser(user);
>>
>> and the aforementioned ACL code.

This is actually part of the session validator code.

>>> data.save();

This only saves the user object to the session, not the ACL. The ACL is
built and saved to the session by the AccessController.

>>> Any thoughts as to what I'm doing wrong, and how I can get the ACL to persist with the
>>> session?

If objects stored in the session are not serializable, Tomcat will log
that during shutdown or during startup. See your Tomcat logs for what
really happens.

This problem looks strange to me. What session validators,
ACL-implementations or other security-related settings do you have in place?

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

RE: ACL serialization.

2009-12-17T15:41:36Z

Alright, I've done some serious digging now, and I think I've found the heart of the issue.

I'm using the TorqueUser implementation of the User interface.

At the start it makes a distinction between permanent storage,
and temporary. These appear to refer to (database) and (session)
respectively. The problem lies with the fact that there is no link between
the two.
The underlying user account object is stored in permanent storage
and as such, if you update it's name, email, etc, it updates the permanent
storage object in memory. However, the session has no record of this.

This appears to be a serious limitation for sharing sessions across server nodes.

I suppose I'll write/rewrite my own implementation of the User interface, such
that the underlying user object is stored in the session too.

And If its not too hackish, maybe I'll even submit it to the project lol..

> From: ross_sheldon@...
> To: user@...
> Subject: RE: ACL serialization.
> Date: Tue, 15 Dec 2009 23:41:03 +0000
>
>
> So actually neither the User, nor the ACL is getting saved when the server restarts.
> It appeared like the user was because I have it linked to address tables, etc. And
> they were getting reloaded.
>
> So I set the user and acl when someone logs in via
>
> user = TurbineSecurity.getAuthenticatedUser( username, password );
> data.setUser(user);
>
> and the aforementioned ACL code.
>
> So why aren't these being stored in the session? And how do I go about getting
> them stored in the session?
>
> I could of course create a hashmap or custom object, store them in that,
> and put it in the session manually or something clunky like that.
>
> It seems to me like there has to be a better way?
>
> > From: ross_sheldon@...
> > To: turbine-user@...
> > Subject: ACL serialization.
> > Date: Tue, 15 Dec 2009 23:17:36 +0000
> >
> >
> > Hello,
> > I'm trying to make sessions persistent, and set-up a cluster.
> > I'm able to serialize and recall/reload all my defined session tools and subobjects
> > defined via example:
> >
> > tool.session.queryData=org.simmental.util.QueryData
> >
> > However, the my Access control list doesn't seem to be serializing for some reason.
> >
> > AccessControlList acl = data.getACL();
> > if ( acl == null )
> > {
> > acl = TurbineSecurity.getACL( data.getUser() );
> > data.getSession().setAttribute( AccessControlList.SESSION_KEY,(Object)acl );
> > }
> > data.setACL(acl);
> > data.save();
> >
> > This code is in my login action. Now I thought that would save the ACL to the session,
> > but whenever I restart Tomcat, the ACL is null on requests.
> >
> > Any thoughts as to what I'm doing wrong, and how I can get the ACL to persist with the
> > session?
> >
> > Thanks
> > Ross
> >
> >
> > _________________________________________________________________
> > Hotmail: Free, trusted and rich email service.
> > http://clk.atdmt.com/GBL/go/171222984/direct/01/
>
> _________________________________________________________________
> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
> http://clk.atdmt.com/GBL/go/171222985/direct/01/

_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/171222984/direct/01/

RE: ACL serialization.

2009-12-15T15:41:03Z

So actually neither the User, nor the ACL is getting saved when the server restarts.
It appeared like the user was because I have it linked to address tables, etc. And
they were getting reloaded.

So I set the user and acl when someone logs in via

user = TurbineSecurity.getAuthenticatedUser( username, password );
data.setUser(user);

and the aforementioned ACL code.

So why aren't these being stored in the session? And how do I go about getting
them stored in the session?

I could of course create a hashmap or custom object, store them in that,
and put it in the session manually or something clunky like that.

It seems to me like there has to be a better way?

> From: ross_sheldon@...
> To: turbine-user@...
> Subject: ACL serialization.
> Date: Tue, 15 Dec 2009 23:17:36 +0000
>
>
> Hello,
> I'm trying to make sessions persistent, and set-up a cluster.
> I'm able to serialize and recall/reload all my defined session tools and subobjects
> defined via example:
>
> tool.session.queryData=org.simmental.util.QueryData
>
> However, the my Access control list doesn't seem to be serializing for some reason.
>
> AccessControlList acl = data.getACL();
> if ( acl == null )
> {
> acl = TurbineSecurity.getACL( data.getUser() );
> data.getSession().setAttribute( AccessControlList.SESSION_KEY,(Object)acl );
> }
> data.setACL(acl);
> data.save();
>
> This code is in my login action. Now I thought that would save the ACL to the session,
> but whenever I restart Tomcat, the ACL is null on requests.
>
> Any thoughts as to what I'm doing wrong, and how I can get the ACL to persist with the
> session?
>
> Thanks
> Ross
>
>
> _________________________________________________________________
> Hotmail: Free, trusted and rich email service.
> http://clk.atdmt.com/GBL/go/171222984/direct/01/

_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/171222985/direct/01/

ACL serialization.

2009-12-15T15:17:36Z

Hello,
I'm trying to make sessions persistent, and set-up a cluster.
I'm able to serialize and recall/reload all my defined session tools and subobjects
defined via example:

tool.session.queryData=org.simmental.util.QueryData

However, the my Access control list doesn't seem to be serializing for some reason.

AccessControlList acl = data.getACL();
if ( acl == null )
{
acl = TurbineSecurity.getACL( data.getUser() );
data.getSession().setAttribute( AccessControlList.SESSION_KEY,(Object)acl );
}
data.setACL(acl);
data.save();

This code is in my login action. Now I thought that would save the ACL to the session,
but whenever I restart Tomcat, the ACL is null on requests.

Any thoughts as to what I'm doing wrong, and how I can get the ACL to persist with the
session?

Thanks
Ross

_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/171222984/direct/01/

Turbine 2.3.3 and Jboss 5.01 GA

2009-12-08T15:33:08Z

Has anyone had any luck getting the turbine hello world example to run
on JBoss 5.0.1.GA / JDK 1.6.0_17
I've been able to get it running on both Tomcat and Glassfish but I get
the following stack in JBOSS

(I created the war and deployed it to JBOSS without error.
However the moment you access http://localhost:8080/helloworld/ JBoss
throws a stacktrace.
Will turbine run on JAVA 6? )

17:32:50,684 INFO [ServerImpl] JBoss (Microcontainer) [5.0.1.GA (build:
SVNTag=JBoss_5_0_1_GA date=200902231221)] Started in 40s:969ms
17:34:30,154 ERROR [STDERR] log4j:ERROR A
"org.jboss.logging.appender.FileAppender" object is not assignable to a
"org.apache.log4j.Appender" variable.
17:34:30,154 ERROR [STDERR] log4j:ERROR The class
"org.apache.log4j.Appender" was loaded by
17:34:30,154 ERROR [STDERR] log4j:ERROR
[BaseClassLoader@136b039{vfszip:/D:/spi/jboss-5.0.1.GA_ag/server/ag/depl
oy/helloworld.war/}] whereas object of type
17:34:30,154 ERROR [STDERR] log4j:ERROR
"org.jboss.logging.appender.FileAppender" was loaded by
[org.jboss.system.NoAnnotationURLClassLoader@1dd7056].
17:34:30,154 ERROR [STDERR] log4j:ERROR Could not instantiate appender
named "FILE".
17:34:30,372 ERROR [[/helloworld]] StandardWrapper.Throwable
java.lang.LinkageError: loader constraint violation: when resolving
overridden method
"org.apache.avalon.framework.configuration.SAXConfigurationHandler.fatal
Error(Lorg/xml/sa
x/SAXParseException;)V" the class loader (instance of
org/jboss/classloader/spi/base/BaseClassLoader) of the current class,
org/apache/avalon/framework/configuration/SAXConfig
urationHandler, and its superclass loader (instance of <bootloader>),
have different Class objects for the type org/xml/sax/SAXParseException
used in the signature
at
org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.ge
tHandler(DefaultConfigurationBuilder.java:155)
at
org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.se
tParser(DefaultConfigurationBuilder.java:131)
at
org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.<i
nit>(DefaultConfigurationBuilder.java:107)
at
org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.<i
nit>(DefaultConfigurationBuilder.java:82)
at
org.apache.turbine.services.avaloncomponent.TurbineAvalonComponentServic
e.initialize(TurbineAvalonComponentService.java:147)
at
org.apache.turbine.services.avaloncomponent.TurbineAvalonComponentServic
e.init(TurbineAvalonComponentService.java:101)
at
org.apache.turbine.services.BaseServiceBroker.initService(BaseServiceBro
ker.java:286)
at
org.apache.turbine.services.BaseServiceBroker.doInitService(BaseServiceB
roker.java:366)
at
org.apache.turbine.services.BaseServiceBroker.initServices(BaseServiceBr
oker.java:338)
at
org.apache.turbine.services.BaseServiceBroker.init(BaseServiceBroker.jav
a:155)
at org.apache.turbine.Turbine.configure(Turbine.java:377)
at org.apache.turbine.Turbine.init(Turbine.java:194)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav
a:1048)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:7
77)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:129)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:191)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAs
sociationValve.java:190)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticator
Base.java:433)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.j
ava:92)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(
SecurityContextEstablishmentValve.java:126)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(S
ecurityContextEstablishmentValve.java:70)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:102)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConn
ectionValve.java:158)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:3
30)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:82
9)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
Http11Protocol.java:601)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
17:34:30,372 ERROR [[helloworld]] Allocate exception for servlet
helloworld
java.lang.LinkageError: loader constraint violation: when resolving
overridden method
"org.apache.avalon.framework.configuration.SAXConfigurationHandler.fatal
Error(Lorg/xml/sa
x/SAXParseException;)V" the class loader (instance of
org/jboss/classloader/spi/base/BaseClassLoader) of the current class,
org/apache/avalon/framework/configuration/SAXConfig
urationHandler, and its superclass loader (instance of <bootloader>),
have different Class objects for the type org/xml/sax/SAXParseException
used in the signature

Re: ajax and rundata disposal

2009-12-08T07:30:35Z

> Yes, performance is the key here. The difference is that this switch
> makes *all* tools refresh themselves on every request, while the scope
> change affects your single tool only.
>

Ok, thanks.

> Again, I can only emphasize that RunData objects should not be used in
> any other scope than request.

I use the RunData only in a tool to help rendering a response from a
template.
So this is only for one request.

Setting the scope to request does actually work.

The solution provided in
http://turbine.markmail.org/message/xchloohdlo7enj2l should work too,
but haven't used it so far.

bye
christian

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-07T01:55:19Z

>
> It sounds as if one of the tools you are are accessing is not
> re-entrant, meaning that internally it is storing a temporary reference
> to RunData

Yes, I think this is re-entrant.
So this might be the source of my problems.

class ATool

public void init(Object data) {
if (data instanceof RunData)
this.data = (RunData) data;
}
public void refresh(RunData data) {
this.data = data;
}
public Model get(String modelName) {
ModelService modelService = TurbineModel.getService();
return modelService.getModel(modelName,data);
}
---------------------------------------------------------------------------------------

I guess I am supposed to use the tool that way.

public Model get(String modelName, presentData) {
ModelService modelService = TurbineModel.getService();
return modelService.getModel(modelName,presentData);
}

Can you confirm that?

christian

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-03T12:11:35Z

Christian Kaiser wrote:
> I would really like to know why you don't recommend this. Is it for
> performance reasons? Isn't the same thing when I change the tools scope
> to 'request'?

Yes, performance is the key here. The difference is that this switch
makes *all* tools refresh themselves on every request, while the scope
change affects your single tool only.

Again, I can only emphasize that RunData objects should not be used in
any other scope than request. Because they are pooled, recycled and
reused, your tool might end up in using the data of another request -
which is the case if the RunData object you just used is assigned to a
different thread or session.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-03T09:23:41Z

I have never had a problem accessing pull tools from Velocity, whether
the page contains Javascript that causes the form submittal (because of
a mouse click, the browser closing, etc) or whether the user is
hammering away at the keyboard.

What is puzzling is how the tool is accessing a null reference to
RunData since you are passing in the $data parameter from within the
template.

I have literally beaten/stress tested my forms to intentionally generate
overlapping requests, and I make heavy use of pull tools (that I have
written myself), and I have never had this type of null $data reference
within a tool. From my experience the pull tool concept is sound.

It sounds as if one of the tools you are are accessing is not
re-entrant, meaning that internally it is storing a temporary reference
to RunData (rather than internally passing RunData as a parameter to
every internal method call). Then at some insignificant time later
within the same sequence of steps it is trying to reference this
temporarily stored reference. In a hard hitting, asynchronous model
this could obviously fail. (Or instead of a reference to RunData, a
tool could also be trying to access the same long running resource, data
retrieval, storing data, etc, in which case it would need to control
access to the resource, or maintain state using an external resource).

From what I understand, no matter how quickly you submit overlapping
requests (even for the same session), each will have its own unique
instance of RunData, so the RunData model itself is probably not the
issue. What happens within the application when these different
requests are asynchronously accessing the same resources can be solved
through the implementation of the tool.

Christian Kaiser wrote:

>> (1) You create an object and while initializing it you store a reference
>> to RunData. A reference to this object is stored in the session.
>> ...
>>
>
>
>
> My code doesn't store objects to RunData. Turbines does.
>
>
> Hm, the pull tools i am talking about are using TurbineServices.
>
> These services are fetched from Turbine with the RunData as parameter.
> The services uses a key from the session to get specific data.
> Just to repeat it: If rundata.isDisposed --> session is null --> NPE.
>
> This approach was designed by Henning Schmiedehausen a while ago, so I
> assume thats ok. This was with turbine version 2.3.1 resp 2.3.2-rc1
>
> Maybe we shouldn't have upgraded to 2.3.3. ??
>
>
> My conclusion of turbine behaviour for now:
>
> If you use simple http requests (non-ajax), you won't have too much
> trouble besides some ERROR logs resulting from a disposed rundata.
> This may happen if a user doesn't wait for a long request to return, and
> sends another request which overtakes the first one.
> The user would not note anything, because his second request will be
> performed correctly.
> So, we have only errors in the log files as result. Ok, in bad designed
> software it may lead to data inconsistency, but that might be too far
> fetched for now.
>
> Things get worse, if you have asynchronous ajax requests AND you use
> pull tools from velocity templates to generate the response.
>
> In this case, I suggest to refresh the rundata in all used tools per
> request.
>
> christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

Re: ajax and rundata disposal

2009-12-03T01:56:06Z

> (1) You create an object and while initializing it you store a reference
> to RunData. A reference to this object is stored in the session.
> ...

My code doesn't store objects to RunData. Turbines does.

Hm, the pull tools i am talking about are using TurbineServices.

These services are fetched from Turbine with the RunData as parameter.
The services uses a key from the session to get specific data.
Just to repeat it: If rundata.isDisposed --> session is null --> NPE.

This approach was designed by Henning Schmiedehausen a while ago, so I
assume thats ok. This was with turbine version 2.3.1 resp 2.3.2-rc1

Maybe we shouldn't have upgraded to 2.3.3. ??

My conclusion of turbine behaviour for now:

If you use simple http requests (non-ajax), you won't have too much
trouble besides some ERROR logs resulting from a disposed rundata.
This may happen if a user doesn't wait for a long request to return, and
sends another request which overtakes the first one.
The user would not note anything, because his second request will be
performed correctly.
So, we have only errors in the log files as result. Ok, in bad designed
software it may lead to data inconsistency, but that might be too far
fetched for now.

Things get worse, if you have asynchronous ajax requests AND you use
pull tools from velocity templates to generate the response.

In this case, I suggest to refresh the rundata in all used tools per
request.

christian

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-03T00:51:22Z

> services.PullService.tools.per.request.refresh=true

Nice, thanks for the hint.

> I do not recommend this for production use, however.

I would really like to know why you don't recommend this. Is it for
performance reasons? Isn't the same thing when I change the tools scope
to 'request'?

christian

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-02T09:49:26Z

Christian Kaiser wrote:
> It seems I get same sessions for different RunData instances.

... and vice versa. This is because RunData objects are pooled.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-02T09:48:25Z

Christian Kaiser wrote:
> I can prevent from this, when I set the tool in a request scope.

Yes, this is the way to do it.

> That means the refresh method of the RunDataApplicationTool is not
> called, but the Rundata is passed to the Tool with the init method.

The refresh()-method call can be forced by setting

services.PullService.tools.per.request.refresh=true

The comment in the original TurbineResources.properties file is like
this (which explains it all)

---8<---
# This determines whether the non-request tools are refreshed
# on each request (request tools aren't ever, because they're
# instantiated for the request only anyway).
services.PullService.tools.per.request.refresh=true
---8<---

I do not recommend this for production use, however.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-02T08:33:12Z

Let me see if I have this straight...

(1) You create an object and while initializing it you store a reference
to RunData. A reference to this object is stored in the session.
...

(2) Another event takes place causing you to reference the session
object, where you in turn attempt to use the original reference to your
original RunData object
...

Instead of (1) and (2) simply include a reference of RunData as a
parameter to the methods on your object... Do not store any references
to any instance of RunData. Also, you should not care if you are
working with different instances of RunData as each instance is single
use (per event).

FYI... I would use a parameter approach rather than an init approach...
Depending upon implementations, I have seen cases where the form object
gets called, then the event, and then the form gets called
redundantly... Even if you are referencing an event (where you might
always expect the event to be first in the sequence).

...

If you are worried about maintaining state just use the methods on the
current RunData instance to access whatever you have stored in the
session. Your state is maintained in the session, and not in any
particular instance of RunData.

Christian Kaiser wrote:

> I think I got it now.
> Please correct me if I misconceive.
> log:
>
> 14:51:27,027 [TP-Processor8] DEBUG ...BmsRunData
> recycle ...BmsRunData@1f3bb61
> 14:51:27,033 [TP-Processor8] DEBUG ...ModelTool -
> refresh ...BmsRunData@1f3bb61
>
> 14:51:27,168 [TP-Processor2] DEBUG ...BmsRunData -
> recycle ...BmsRunData@3e65be
> 14:51:27,183 [TP-Processor2] DEBUG ...ModelTool -
> refresh ...BmsRunData@3e65be
> 14:51:27,245 [TP-Processor2] DEBUG ...BmsRunData -
> dispose ...BmsRunData@3e65be
>
> 14:51:27,249 [TP-Processor8] ERROR ...ModelTool - NPE
> for ...BmsRunData@3e65be
> 14:51:27,256 [TP-Processor8] DEBUG ...BmsRunData -
> dispose ...BmsRunData@1f3bb61
>
>
> Processor2 overtakes Processor8.
>
> The modeltool runs in session scope, so only one instance of it exists.
> After P8 refreshes the rundata in the tool,
> P2 overwrites it with its rundata.
> P2 finished and disposed the rundata.
> The model tool in P8 has a disposed rundata.
>
>
> I can prevent from this, when I set the tool in a request scope.
> That means the refresh method of the RunDataApplicationTool is not
> called, but the Rundata is passed to the Tool with the init method.
> The tool gets initialized on every request.
>
> Thats about it for now.
> Feel free to add your thoughts.
> Thanks for your hints, so far.
>
> Christian
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-02T07:29:46Z

I think I got it now.
Please correct me if I misconceive.
log:

14:51:27,027 [TP-Processor8] DEBUG ...BmsRunData
recycle ...BmsRunData@1f3bb61
14:51:27,033 [TP-Processor8] DEBUG ...ModelTool -
refresh ...BmsRunData@1f3bb61

14:51:27,168 [TP-Processor2] DEBUG ...BmsRunData -
recycle ...BmsRunData@3e65be
14:51:27,183 [TP-Processor2] DEBUG ...ModelTool -
refresh ...BmsRunData@3e65be
14:51:27,245 [TP-Processor2] DEBUG ...BmsRunData -
dispose ...BmsRunData@3e65be

14:51:27,249 [TP-Processor8] ERROR ...ModelTool - NPE
for ...BmsRunData@3e65be
14:51:27,256 [TP-Processor8] DEBUG ...BmsRunData -
dispose ...BmsRunData@1f3bb61

Processor2 overtakes Processor8.

The modeltool runs in session scope, so only one instance of it exists.
After P8 refreshes the rundata in the tool,
P2 overwrites it with its rundata.
P2 finished and disposed the rundata.
The model tool in P8 has a disposed rundata.

I can prevent from this, when I set the tool in a request scope.
That means the refresh method of the RunDataApplicationTool is not
called, but the Rundata is passed to the Tool with the init method.
The tool gets initialized on every request.

Thats about it for now.
Feel free to add your thoughts.
Thanks for your hints, so far.

Christian

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-02T02:19:03Z

It seems I get same sessions for different RunData instances.

2009-12-02 10:48:37,132 [TP-Processor1] DEBUG ...BmsRunData -
recycle ...BmsRunData@edd8bc SessionID No Session
2009-12-02 10:48:37,139 [TP-Processor1] DEBUG ...ModelTool -
refresh ...BmsRunData@edd8bc SessionID
13E9EEE6182B2F7E8D9053C08676FFE1
2009-12-02 10:48:37,141 [TP-Processor1] DEBUG ...BmsRunData -
dispose ...BmsRunData@edd8bc SessionID
13E9EEE6182B2F7E8D9053C08676FFE1
2009-12-02 10:48:37,315 [TP-Processor3] DEBUG ...BmsRunData -
recycle ...BmsRunData@402c41 SessionID No Session
2009-12-02 10:48:37,323 [TP-Processor3] DEBUG ...ModelTool -
refresh ...BmsRunData@402c41 SessionID
13E9EEE6182B2F7E8D9053C08676FFE1
2009-12-02 10:48:37,488 [TP-Processor3] DEBUG ...BmsRunData -
dispose ...BmsRunData@402c41 SessionID
13E9EEE6182B2F7E8D9053C08676FFE1
2009-12-02 10:48:37,776 [TP-Processor8] DEBUG ...BmsRunData -
recycle ...BmsRunData@edd8bc SessionID No Session
2009-12-02 10:48:37,784 [TP-Processor8] DEBUG ...ModelTool -
refresh ...BmsRunData@edd8bc SessionID
13E9EEE6182B2F7E8D9053C08676FFE1
2009-12-02 10:48:37,793 [TP-Processor8] DEBUG ...BmsRunData -
dispose ...BmsRunData@edd8bc SessionID
13E9EEE6182B2F7E8D9053C08676FFE1
2009-12-02 10:48:37,979 [TP-Processor5] DEBUG ...BmsRunData -
recycle ...BmsRunData@402c41 SessionID No Session
2009-12-02 10:48:37,987 [TP-Processor5] DEBUG ...ModelTool -
refresh ...BmsRunData@402c41 SessionID
13E9EEE6182B2F7E8D9053C08676FFE1
2009-12-02 10:48:37,990 [TP-Processor5] DEBUG ...BmsRunData -
dispose ...BmsRunData@402c41 SessionID
13E9EEE6182B2F7E8D9053C08676FFE1

greetings
christian

Am Dienstag, den 01.12.2009, 18:59 -0600 schrieb Tony Oslund:

> Are you getting new sessions?
>
> You stated that you have different instances of rundata.
>
> Are you getting unique session id's?
>
> Tony
>
> On Dec 1, 2009, at 3:05 AM, Christian Kaiser <christian.kaiser@...
> > wrote:
>
> > Am Montag, den 30.11.2009, 19:12 +0000 schrieb Sheldon Ross:
> >>
> >> Are you sure your action is not generating a form submittal at the
> >> same time as an ajax request?
> >
> > Yes I am sure.
> > I can provoke this by entering two URLs in the browser, one after the
> > other.
> >
> > christian
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@...
> > For additional commands, e-mail: user-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>

Christian Kaiser | Softwareentwicklung

blue cell networks GmbH

Hainstraße 14 | 96047 Bamberg, Germany | phone:+49 (0) 951-30 20 67
121 | fax: +49 (0) 951-30 20 67 201

email: christian.kaiser@... | skype:
bcn_christian.kaiser | web: www.bluecellnetworks.com

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-01T16:59:25Z

Are you getting new sessions?

You stated that you have different instances of rundata.

Are you getting unique session id's?

Tony

On Dec 1, 2009, at 3:05 AM, Christian Kaiser <christian.kaiser@...
> wrote:

> Am Montag, den 30.11.2009, 19:12 +0000 schrieb Sheldon Ross:
>>
>> Are you sure your action is not generating a form submittal at the
>> same time as an ajax request?
>
> Yes I am sure.
> I can provoke this by entering two URLs in the browser, one after the
> other.
>
> christian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-01T07:19:57Z

maybe it has to do with scope of the pull tools I am using.

I use the ModelService, done by Henning, maybe you know it.

The model tool runs in authorized scope and uses the contents of the
rundata to get a model.

As far as I understand it, a rundata object will be passed to the tool
when the session gets initialized.

This tool will be used by all requests. It may happen that the rundata
object, stored in the tool, is disposed when some request wants to fetch
a model with it.

I tried to put the tool in request scope. But it seems that the tool
doesn't get a refresh call with the rundata object in that scope.

I am not sure if I am on the right path, but hopefully this helps you to
understand my set up.

christian

Am Dienstag, den 01.12.2009, 11:08 +0100 schrieb Christian Kaiser:

> logs proof that there are multiple RunData Objects:
>
> 2009-12-01 11:03:08,673 [TP-Processor6] DEBUG de.beamzone.sm.service.rundata.BmsRunData - recycle de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:08,752 [TP-Processor6] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:08,981 [TP-Processor8] DEBUG de.beamzone.sm.service.rundata.BmsRunData - recycle de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:09,109 [TP-Processor8] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:09,357 [TP-Processor8] DEBUG de.beamzone.sm.service.rundata.BmsRunData - recycle de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:09,557 [TP-Processor2] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@296a42
> 2009-12-01 11:03:09,795 [TP-Processor8] ERROR de.beamzone.sm.tools.ModelTool - Cannot get model Campaign for RunData de.beamzone.sm.service.rundata.BmsRunData@296a42. Error: java.lang.NullPointerException
> 2009-12-01 11:03:09,984 [TP-Processor8] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:10,385 [TP-Processor7] DEBUG de.beamzone.sm.service.rundata.BmsRunData - recycle de.beamzone.sm.service.rundata.BmsRunData@296a42
> 2009-12-01 11:03:10,392 [TP-Processor7] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@296a42
> 2009-12-01 11:03:10,573 [TP-Processor3] DEBUG de.beamzone.sm.service.rundata.BmsRunData - recycle de.beamzone.sm.service.rundata.BmsRunData@1afc148
> 2009-12-01 11:03:10,603 [TP-Processor3] DEBUG de.beamzone.sm.service.rundata.BmsRunData - dispose de.beamzone.sm.service.rundata.BmsRunData@1afc148
>
>
>
> Am Dienstag, den 01.12.2009, 10:00 +0100 schrieb Christian Kaiser:
> > First of all, thanks for your answers. :-)
> >
> > Am Montag, den 30.11.2009, 18:34 +0100 schrieb Thomas Vandahl:
> > > Christian Kaiser wrote:
> > > > If the ajax request is the first request to finish, it disposes the
> > > > RunData.
> > > > This leads to bad behavour of my http request, because this request has
> > > > to deal with a disposed RunData.
> > >
> > > RunData is a per-request object that is borrowed from a pool at request
> > > creation and returned (and recycled) at request completion. A RunData
> > > object is not meant to be shared between different requests. If you
> > > believe you must do this, you have a serious design problem in your
> > > software.
> >
> > Ok, I don't believe I must do this.
> > I thought it is meant to be that way.
> >
> >
> >
> >
> >
> > >
> > > Then again, your main screen request and your Ajax request are totally
> > > unrelated from Turbine's point of view. They should use two different
> > > RunData objects anyway.
> >
> > Concerning your previous mentioned point, I don't think that this issue
> > is Ajax related any more. I face the same problem with ordinary
> > requests, sent fast in row.
> > If one request overtakes the other while processing, it ends up in a
> > disposed Rundata of the first request, too.
> >
> >
> > >
> > > > Is this a common problem?
> > > > Can I prevent from it?
> > >
> > > No, this should not happen at any time.
> > >
> > That sounds promising.
> > >
> > > > Please let me now if I can provide you with additional information.
> > >
> > > Well, yes. Let's have a look at some code. This problem sounds very
> > > strange to me.
> > >
> > >
> > >
> >
> > I overwrote The DefaultTurbineRunData. ( I think this was to identify disposed rundata ??).
> >
> > /**
> > *
> > * Gets the servlet session information. Return null if data expired.
> > *
> > * @return the session.
> > */
> > public HttpSession getSession() {
> > HttpServletRequest request = getRequest();
> >
> > if (request == null) {
> >
> > return null;
> >
> > }
> >
> > return request.getSession();
> > }
> >
> > Let me know which other code is of interest.
> >
> > Thanks,
> > christian
> >
> >
> >
> > > Bye, Thomas.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@...
> > > For additional commands, e-mail: user-help@...
> > >
> >
> >
> > Christian Kaiser | Softwareentwicklung
> >
> > blue cell networks GmbH
> >
> >
> >
> > Hainstraße 14 | 96047 Bamberg, Germany | phone:+49 (0) 951-30 20 67
> > 121 | fax: +49 (0) 951-30 20 67 201
> >
> > email: christian.kaiser@... | skype:
> > bcn_christian.kaiser | web: www.bluecellnetworks.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@...
> > For additional commands, e-mail: user-help@...
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>

Re: ajax and rundata disposal

2009-12-01T02:08:37Z

logs proof that there are multiple RunData Objects:

2009-12-01 11:03:08,673 [TP-Processor6] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - recycle
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:08,752 [TP-Processor6] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:08,981 [TP-Processor8] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - recycle
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:09,109 [TP-Processor8] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:09,357 [TP-Processor8] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - recycle
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:09,557 [TP-Processor2] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@296a42
2009-12-01 11:03:09,795 [TP-Processor8] ERROR
de.beamzone.sm.tools.ModelTool - Cannot get model Campaign for RunData
de.beamzone.sm.service.rundata.BmsRunData@296a42. Error:
java.lang.NullPointerException
2009-12-01 11:03:09,984 [TP-Processor8] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:10,385 [TP-Processor7] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - recycle
de.beamzone.sm.service.rundata.BmsRunData@296a42
2009-12-01 11:03:10,392 [TP-Processor7] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@296a42
2009-12-01 11:03:10,573 [TP-Processor3] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - recycle
de.beamzone.sm.service.rundata.BmsRunData@1afc148
2009-12-01 11:03:10,603 [TP-Processor3] DEBUG
de.beamzone.sm.service.rundata.BmsRunData - dispose
de.beamzone.sm.service.rundata.BmsRunData@1afc148

Am Dienstag, den 01.12.2009, 10:00 +0100 schrieb Christian Kaiser:

> First of all, thanks for your answers. :-)
>
> Am Montag, den 30.11.2009, 18:34 +0100 schrieb Thomas Vandahl:
> > Christian Kaiser wrote:
> > > If the ajax request is the first request to finish, it disposes the
> > > RunData.
> > > This leads to bad behavour of my http request, because this request has
> > > to deal with a disposed RunData.
> >
> > RunData is a per-request object that is borrowed from a pool at request
> > creation and returned (and recycled) at request completion. A RunData
> > object is not meant to be shared between different requests. If you
> > believe you must do this, you have a serious design problem in your
> > software.
>
> Ok, I don't believe I must do this.
> I thought it is meant to be that way.
>
>
>
>
>
> >
> > Then again, your main screen request and your Ajax request are totally
> > unrelated from Turbine's point of view. They should use two different
> > RunData objects anyway.
>
> Concerning your previous mentioned point, I don't think that this issue
> is Ajax related any more. I face the same problem with ordinary
> requests, sent fast in row.
> If one request overtakes the other while processing, it ends up in a
> disposed Rundata of the first request, too.
>
>
> >
> > > Is this a common problem?
> > > Can I prevent from it?
> >
> > No, this should not happen at any time.
> >
> That sounds promising.
> >
> > > Please let me now if I can provide you with additional information.
> >
> > Well, yes. Let's have a look at some code. This problem sounds very
> > strange to me.
> >
> >
> >
>
> I overwrote The DefaultTurbineRunData. ( I think this was to identify disposed rundata ??).
>
> /**
> *
> * Gets the servlet session information. Return null if data expired.
> *
> * @return the session.
> */
> public HttpSession getSession() {
> HttpServletRequest request = getRequest();
>
> if (request == null) {
>
> return null;
>
> }
>
> return request.getSession();
> }
>
> Let me know which other code is of interest.
>
> Thanks,
> christian
>
>
>
> > Bye, Thomas.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@...
> > For additional commands, e-mail: user-help@...
> >
>
>
> Christian Kaiser | Softwareentwicklung
>
> blue cell networks GmbH
>
>
>
> Hainstraße 14 | 96047 Bamberg, Germany | phone:+49 (0) 951-30 20 67
> 121 | fax: +49 (0) 951-30 20 67 201
>
> email: christian.kaiser@... | skype:
> bcn_christian.kaiser | web: www.bluecellnetworks.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

RE: ajax and rundata disposal

2009-12-01T01:05:26Z

Am Montag, den 30.11.2009, 19:12 +0000 schrieb Sheldon Ross:
>
> Are you sure your action is not generating a form submittal at the
> same time as an ajax request?

Yes I am sure.
I can provoke this by entering two URLs in the browser, one after the
other.

christian

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: ajax and rundata disposal

2009-12-01T01:00:02Z

First of all, thanks for your answers. :-)

Am Montag, den 30.11.2009, 18:34 +0100 schrieb Thomas Vandahl:

> Christian Kaiser wrote:
> > If the ajax request is the first request to finish, it disposes the
> > RunData.
> > This leads to bad behavour of my http request, because this request has
> > to deal with a disposed RunData.
>
> RunData is a per-request object that is borrowed from a pool at request
> creation and returned (and recycled) at request completion. A RunData
> object is not meant to be shared between different requests. If you
> believe you must do this, you have a serious design problem in your
> software.

Ok, I don't believe I must do this.
I thought it is meant to be that way.

>
> Then again, your main screen request and your Ajax request are totally
> unrelated from Turbine's point of view. They should use two different
> RunData objects anyway.

Concerning your previous mentioned point, I don't think that this issue
is Ajax related any more. I face the same problem with ordinary
requests, sent fast in row.
If one request overtakes the other while processing, it ends up in a
disposed Rundata of the first request, too.

>
> > Is this a common problem?
> > Can I prevent from it?
>
> No, this should not happen at any time.
>
That sounds promising.
>
> > Please let me now if I can provide you with additional information.
>
> Well, yes. Let's have a look at some code. This problem sounds very
> strange to me.
>
>
>

I overwrote The DefaultTurbineRunData. ( I think this was to identify disposed rundata ??).

/**
*
* Gets the servlet session information. Return null if data expired.
*
* @return the session.
*/
public HttpSession getSession() {
HttpServletRequest request = getRequest();

if (request == null) {

return null;

}

return request.getSession();
}

Let me know which other code is of interest.

Thanks,
christian

> Bye, Thomas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>

Christian Kaiser | Softwareentwicklung

blue cell networks GmbH

Hainstraße 14 | 96047 Bamberg, Germany | phone:+49 (0) 951-30 20 67
121 | fax: +49 (0) 951-30 20 67 201

email: christian.kaiser@... | skype:
bcn_christian.kaiser | web: www.bluecellnetworks.com

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

RE: ajax and rundata disposal

2009-11-30T11:12:33Z

Are you sure your action is not generating a form submittal at the same time as an ajax request?

For instance, if you have a <button> object on a page with in a form, in most browsers that will submit the form
even if you only wanted the button onclick listener to launch an ajax event.

Sheldon Ross

> Subject: ajax and rundata disposal
> From: christian.kaiser@...
> To: user@...
> Date: Mon, 30 Nov 2009 16:42:59 +0100
>
> Dear Turbine Users,
>
> I have hard times with the disposal of the rundata.
>
> I integrated the json-rpc service in my turbine 2.3.3 application.
>
> Now when worst comes to worst, a common http request (user click) is
> sent at the same time as an automated ajax request that tries to build
> up the last site.
>
> If the ajax request is the first request to finish, it disposes the
> RunData.
> This leads to bad behavour of my http request, because this request has
> to deal with a disposed RunData.
>
>
> Is this a common problem?
> Can I prevent from it?
>
> Thanks in advance for your help.
>
> Please let me now if I can provide you with additional information.
>
> christian
>
>
>
>
>
>
>
>
>
> Christian Kaiser | Softwareentwicklung
>
> blue cell networks GmbH
>
>
>
> Hainstraße 14 | 96047 Bamberg, Germany | phone:+49 (0) 951-30 20 67
> 121 | fax: +49 (0) 951-30 20 67 201
>
> email: christian.kaiser@... | skype:
> bcn_christian.kaiser | web: www.bluecellnetworks.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>

_________________________________________________________________
Hotmail: Trusted email with Microsoft's powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/
http://clk.atdmt.com/GBL/go/177141664/direct/01/

Re: ajax and rundata disposal

2009-11-30T09:34:20Z

Christian Kaiser wrote:
> If the ajax request is the first request to finish, it disposes the
> RunData.
> This leads to bad behavour of my http request, because this request has
> to deal with a disposed RunData.

RunData is a per-request object that is borrowed from a pool at request
creation and returned (and recycled) at request completion. A RunData
object is not meant to be shared between different requests. If you
believe you must do this, you have a serious design problem in your
software.

Then again, your main screen request and your Ajax request are totally
unrelated from Turbine's point of view. They should use two different
RunData objects anyway.

> Is this a common problem?
> Can I prevent from it?

No, this should not happen at any time.

> Please let me now if I can provide you with additional information.

Well, yes. Let's have a look at some code. This problem sounds very
strange to me.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

ajax and rundata disposal

2009-11-30T07:42:59Z

Dear Turbine Users,

I have hard times with the disposal of the rundata.

I integrated the json-rpc service in my turbine 2.3.3 application.

Now when worst comes to worst, a common http request (user click) is
sent at the same time as an automated ajax request that tries to build
up the last site.

If the ajax request is the first request to finish, it disposes the
RunData.
This leads to bad behavour of my http request, because this request has
to deal with a disposed RunData.

Is this a common problem?
Can I prevent from it?

Thanks in advance for your help.

Please let me now if I can provide you with additional information.

christian

Christian Kaiser | Softwareentwicklung

blue cell networks GmbH

Hainstraße 14 | 96047 Bamberg, Germany | phone:+49 (0) 951-30 20 67
121 | fax: +49 (0) 951-30 20 67 201

email: christian.kaiser@... | skype:
bcn_christian.kaiser | web: www.bluecellnetworks.com

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Fulcrum Intake 1.0.6 released

2009-11-22T11:19:25Z

The Fulcrum Intake team is pleased to announce the fulcrum-intake-1.0.6
release!

Fulcrum Intake Service

Changes in this version include:

New features:
o Added locale handling to Intake, added user-defined field types.

Fixed Bugs:
o Catch only Exceptions that are actually thrown.
o Intake won't use interfaces for the mapTo() method. Issue: TRB-11.
Thanks to Evan Koffler.
o The number validators did not set an invalid number message when
initialized with the default constructor Issue: TRB-74. Thanks to
Susi Berrington.
o Intake did not correctly parse the message of a rule or
required-message from intake.xml Issue: TRB-68. Thanks to Ronny
Voelker.
o Intake was not handling empty values correctly. Issue: TRB-9. Thanks
to Jürgen Hoffmann.
o Intake was not loading the correct Default Validators when the rules
for a field are empty. Issue: TRB-14. Thanks to Jürgen Hoffmann.

Changes:
o Moved the initialization code of the service implementation to
initialize()
o Removed the dependency on ORO by replacing the regular expression
handling with java.util.regexp. This might have slight implications on
the regexp syntax.
o Use the localize features of the parser to simplify the value
assignment in Intake fields. Made handling of empty values consistent
over all number field types.
o Updated locale handling to use the new localized parameter parser.
This removes the dependency from LocalizationService
o Intake now handles the case where the mapToObject does not map to all
fields in the group. Issue: TRB-9. Thanks to Jürgen Hoffmann.
o Update to Apache License 2.0
o Use inherited getLogger() instead of Log in classes extending
AbstractLogEnabled.

Removed:
o Removed the Intake class. It was duplicating the IntakeServiceFacade.

Have fun!
-Fulcrum Intake team

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

RE: Does links need to be case sensitive?

2009-11-22T09:08:29Z

Yes.

- Madhu

-----Original Message-----
From: Thomas Vandahl [mailto:tv@...]
Sent: Sunday, November 22, 2009 10:27 PM
To: Turbine Users List
Subject: Re: Does links need to be case sensitive?

On 19.11.09 15:38, Ludwig Magnusson wrote:
> Hello!
>
> We had a problem with our screen classes. In some cases they weren't
loaded.
> I noticed that the loading was screen-sensitive so that if I typed in
the
> url www.mydomain.com/mypage.vm and the site had a screen class called
> MyPage.java, it was never executed.
>
>
>
> Is there any way around this?

Yes. The mapping of templates to classes is done by the
JavaScreenFactory IIRC. This factory is pluggable so you can roll your
own.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

"Legal Disclaimer: This electronic message and all contents contain information from Cybage Software Private Limited which may be privileged, confidential, or otherwise protected from disclosure. The information is intended to be for the addressee(s) only. If you are not an addressee, any disclosure, copy, distribution, or use of the contents of this message is strictly prohibited. If you have received this electronic message in error please notify the sender by reply e-mail to and destroy the original message and all copies. Cybage has taken every reasonable precaution to minimize the risk of malicious content in the mail, but is not liable for any damage you may sustain as a result of any malicious content in this e-mail. You should carry out your own malicious content checks before opening the e-mail or attachment."
www.cybage.com

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: Does links need to be case sensitive?

2009-11-22T08:57:01Z

On 19.11.09 15:38, Ludwig Magnusson wrote:

> Hello!
>
> We had a problem with our screen classes. In some cases they weren't loaded.
> I noticed that the loading was screen-sensitive so that if I typed in the
> url www.mydomain.com/mypage.vm and the site had a screen class called
> MyPage.java, it was never executed.
>
>
>
> Is there any way around this?

Yes. The mapping of templates to classes is done by the
JavaScreenFactory IIRC. This factory is pluggable so you can roll your own.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Re: Weird Tomcat issue.

2009-11-21T09:26:16Z

Hi,
I do. We had a strange deaths of our turbine web apps last year. The problem was at 64b Java at Linux in version 1.6.0 between updates 5 and 8 (approximately). We always received the trace, that the java proces died, and always at the same place. We discovered, that it was in the village library, but the problem couldn't be repeatable at developer's boxes. Afterwards we discovered, that the problem was in the java hot spot and it occured only, when the village library wasn't processed via the hot spot in approximately 10 minutes after the start. If it happened later, the proces died. Everything runs well after the big Java 6 update nr. 10. There are no more problems from that time.

But still, our crash looked different, no nice informations about the shutdown in the log file, just the core dump ;-)

Best regards
Tom

Thomas Vandahl wrote:

Sheldon Ross wrote:

Tomcat is shutting down. There are no java processes on the server after this happens. The machine itself is still up and running fine.


Look into catalina.out if it exists. Sometimes the JVM just decides to
die. BTW: Anyone having experience with JAI crashing/hanging the JVM?


Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Ing. Tomas Metz jr.
HSF spol. s r. o.

tel   : +420 352 638 111
mob   : +420 724 005 323
email : tomm@...
jabber: tom.metz@...
www   : www.hsf.cz

Tato zpráva obsahuje důvěrné a/nebo právně chráněné informace. Pokud nejste správným adresátem, popřípadě jste obdržel(a) tuto zprávu omylem, informujte, prosím, obratem odesílatele a smažte tuto zprávu. Nedovolené kopírování a přeposílání této zprávy není dovoleno.

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[ANNOUNCEMENT] Fulcrum XSLT 1.1.0 released

2009-11-19T14:23:49Z

The fulcrum-xslt-team is pleased to announce the fulcrum-xslt-1.1.0.jar
release!

Fulcrum XSLT Service

Changes in this version include:

New features:
o Added an additional transform() method which takes no XML input
document.
o Added a regression test which really does a XSL transformation.
o Moved to M2 build

Changes:
o Synced with 2_3 branch (excluding the replacement of the cache Map()
with a LRUMap()). Thanks to Thomas Vandahl for the patches. Issue:
TRB-19. Thanks to Thomas Vandahl.

Have fun!
-fulcrum-xslt-team

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

Does links need to be case sensitive?

2009-11-19T06:38:51Z

Hello!

We had a problem with our screen classes. In some cases they weren't loaded.
I noticed that the loading was screen-sensitive so that if I typed in the
url www.mydomain.com/mypage.vm and the site had a screen class called
MyPage.java, it was never executed.

Is there any way around this?

/Ludwig

Re: Weird Tomcat issue.

2009-11-17T11:00:43Z

Sheldon Ross wrote:
> Tomcat is shutting down. There are no java processes on the server after this happens. The machine itself is still up and running fine.

Look into catalina.out if it exists. Sometimes the JVM just decides to
die. BTW: Anyone having experience with JAI crashing/hanging the JVM?

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...