Nabble - DWR

Annotations using through-Spring configuration?

2008-07-05T12:47:23Z

Hello,

Is it possible to configure DWR to use annotations (like @RemoteProxy) if I use Spring-based configuration <dwr:configuration/>? I do not have any DwrServlet servlets configured in web.xml to use <init-param> "classes".

-----
Best regards,
Dzmitry Lazerka
Skype: dzmitry.lazerka
Phone: +375 (29) 502-9579

From forum: DWR - Users

Re: Handling individual Exceptions

2008-07-05T06:03:19Z

So this debate is nothing to do with security exceptions - I've done that.
This is about the ability to register different handers for different exceptions - so one of the parameters to the setExceptionHander call would be the type of exception to be handled by this handler.
My argument is that a simple switch would work.

Joe.

On Sat, Jul 5, 2008 at 12:36 PM, Jose Noheda <jose.noheda@...> wrote:

IMO this is useful enough to make it. Handling security exceptions easily for example to popup a login or things like that. In addition, if you're not registering custom exceptions it just works as always has been.

On Sat, Jul 5, 2008 at 11:44 AM, Joe Walker <joe@...> wrote:

On Fri, Jul 4, 2008 at 7:55 PM, Kevin Conaway <kevin.conaway@...> wrote:

The problem is that for each extra feature like this, the error handling documentation gets harder to understand

I'd argue that anyone who has familiarity with todays web frameworks (Struts, Beehive and Stripes come to mind) has experience with registering "global" exception handlers.

I'm not convinced that it buys us a lot, does it?

"A lot" is relative :) I think it allows for a concise and maintainable approach to error handling. Registering callbacks for specific exceptions seems cleaner to me than having a switch statement.

Or are you talking about having this at a call/batch level?

No, the global level

My problem is that DWR keeps on getting bigger:
$ find . -name \*.java -exec cat {} \; | wc -l
133270

That's a lot of lines of code, to do something fairly simple.
Now I try very hard to keep things modular, but if you ask what those lines of code are all for, it's 2 things: fixing browser bugs (nothing we can do about that - it's our sole purpose) and many many small features like this.
Back when I was doing 0.4 someone blogged something along the lines "Joe is a code machine churning out new features at an amazing rate". I don't think anyone would say that now. And it's not that I've got stupid - just that the weight of 100k lines of code prevents you from being a nimble as you would like.

So the cost of these features is that Gears support isn't going to be in 3.0, which is still going to be late.

Don't get me wrong - I'm not against new features, just wanting to pick the ones that really make a difference.

Joe.

From forum: DWR - Users

Re: Handling individual Exceptions

2008-07-05T04:36:08Z

IMO this is useful enough to make it. Handling security exceptions easily for example to popup a login or things like that. In addition, if you're not registering custom exceptions it just works as always has been.

On Sat, Jul 5, 2008 at 11:44 AM, Joe Walker <joe@...> wrote:

On Fri, Jul 4, 2008 at 7:55 PM, Kevin Conaway <kevin.conaway@...> wrote:

The problem is that for each extra feature like this, the error handling documentation gets harder to understand

I'd argue that anyone who has familiarity with todays web frameworks (Struts, Beehive and Stripes come to mind) has experience with registering "global" exception handlers.

I'm not convinced that it buys us a lot, does it?

"A lot" is relative :) I think it allows for a concise and maintainable approach to error handling. Registering callbacks for specific exceptions seems cleaner to me than having a switch statement.

Or are you talking about having this at a call/batch level?

No, the global level

My problem is that DWR keeps on getting bigger:
$ find . -name \*.java -exec cat {} \; | wc -l
133270

That's a lot of lines of code, to do something fairly simple.
Now I try very hard to keep things modular, but if you ask what those lines of code are all for, it's 2 things: fixing browser bugs (nothing we can do about that - it's our sole purpose) and many many small features like this.
Back when I was doing 0.4 someone blogged something along the lines "Joe is a code machine churning out new features at an amazing rate". I don't think anyone would say that now. And it's not that I've got stupid - just that the weight of 100k lines of code prevents you from being a nimble as you would like.

So the cost of these features is that Gears support isn't going to be in 3.0, which is still going to be late.

Don't get me wrong - I'm not against new features, just wanting to pick the ones that really make a difference.

Joe.

From forum: DWR - Users

Re: Global filter configuration using spring

2008-07-05T04:31:20Z

Hi Lance,

There was a Jira issue abot this issue and it was solved some time ago. You need the a 3.0 post M1 IIRC

Regards

On Fri, Jul 4, 2008 at 5:08 PM, Lance Java <lance.java@...> wrote:

I'm trying to configure a filter in my spring xml but I get the feeling that it's not possible.

I've tried the following locations in my application context file:
<dwr:configuration>
    <dwr:init>
      <dwr:filter class="foo.bar.MyFilter" /> 
        <dwr:converter id="..." class=".." />
    </dwr:init>
    <dwr:filter class="foo.bar.MyFilter" /> 
    <dwr:convert type="..." class="..." />
</dwr:configuration>

From forum: DWR - Users

Re: Handling individual Exceptions

2008-07-05T02:44:41Z

On Fri, Jul 4, 2008 at 7:55 PM, Kevin Conaway <kevin.conaway@...> wrote:

The problem is that for each extra feature like this, the error handling documentation gets harder to understand

I'd argue that anyone who has familiarity with todays web frameworks (Struts, Beehive and Stripes come to mind) has experience with registering "global" exception handlers.

I'm not convinced that it buys us a lot, does it?

"A lot" is relative :) I think it allows for a concise and maintainable approach to error handling. Registering callbacks for specific exceptions seems cleaner to me than having a switch statement.

Or are you talking about having this at a call/batch level?

No, the global level

My problem is that DWR keeps on getting bigger:
$ find . -name \*.java -exec cat {} \; | wc -l
133270

That's a lot of lines of code, to do something fairly simple.
Now I try very hard to keep things modular, but if you ask what those lines of code are all for, it's 2 things: fixing browser bugs (nothing we can do about that - it's our sole purpose) and many many small features like this.
Back when I was doing 0.4 someone blogged something along the lines "Joe is a code machine churning out new features at an amazing rate". I don't think anyone would say that now. And it's not that I've got stupid - just that the weight of 100k lines of code prevents you from being a nimble as you would like.

So the cost of these features is that Gears support isn't going to be in 3.0, which is still going to be late.

Don't get me wrong - I'm not against new features, just wanting to pick the ones that really make a difference.

Joe.

From forum: DWR - Users

Re: Handling individual Exceptions

2008-07-04T11:55:05Z

The problem is that for each extra feature like this, the error handling documentation gets harder to understand

I'd argue that anyone who has familiarity with todays web frameworks (Struts, Beehive and Stripes come to mind) has experience with registering "global" exception handlers.

I'm not convinced that it buys us a lot, does it?

"A lot" is relative :) I think it allows for a concise and maintainable approach to error handling. Registering callbacks for specific exceptions seems cleaner to me than having a switch statement.

Or are you talking about having this at a call/batch level?

No, the global level

Thanks,

Kevin

On Fri, Jul 4, 2008 at 11:57 AM, Joe Walker <joe@...> wrote:

The problem is that for each extra feature like this, the error handling documentation gets harder to understand, and I'm not convinced that it buys us a lot, does it?
Since this is for global error handlers, you only need one switch statement.
Or are you talking about having this at a call/batch level?

Joe.

On Fri, Jul 4, 2008 at 4:01 PM, Kevin Conaway <kevin.conaway@...> wrote:

Thanks. I'd like to see the the individual handlers called before the global handler but after the handler registered with the call. I suppose the precedence would be:

1.) If there was a handler registered with the call, use that
2.) If there is global handler registered for the exception type, use that
3.) Use the global error handler

If I'm able to register handlers for a certain type, it saves me from ugly conditional logic in my error handlers:

if (ex instanceof SomeException) {
// do something
} else if (ex instanceof ...) {
// something else
} else {
// punt to default handler
}

I've got a patch ready if you're interested.

On Fri, Jul 4, 2008 at 10:50 AM, Joe Walker <joe@...> wrote:

I ought to add something that wasn't clear from my original reply - the global error handler is called errorHandler and not exceptionHandler.

Joe.

On Fri, Jul 4, 2008 at 3:49 PM, Joe Walker <joe@...> wrote:

For once I'm ahead of you ...
http://directwebremoting.org/dwr/other/errors

On Fri, Jul 4, 2008 at 3:14 PM, Kevin Conaway <kevin.conaway@...> wrote:

Joe, can you explain how that works in 3.0m1?

Thanks

On Fri, Jul 4, 2008 at 9:57 AM, Joe Walker <joe@...> wrote:

You can do exactly that already in 3.0m1, with the exception that the Exception Handler gets passed all exceptions. But you're only a switch away from having just what you need.

Joe.

On Fri, Jul 4, 2008 at 2:52 PM, Kevin Conaway <kevin.conaway@...> wrote:
In addition to the global error handler, I'd like to see a way to register handlers for invidiual Exception instances. For example:

<convert converter="exception" javascript="MyException .../>

dwr.engine.setExceptionHandler(MyException, function() {
// Handler code
});

This allows for much more flexible error handling on the client side with minimal effort.

Cheers,

Kevin Conaway

From forum: DWR - Users

Re: Add "role" attribute to

2008-07-04T10:38:17Z

Ahh - Thanks.
Joe.

On Fri, Jul 4, 2008 at 6:24 PM, Kevin Conaway <kevin.conaway@...> wrote:

The address that was on the document, cla@...

I received a confirmation from Alyssa Maire

On Fri, Jul 4, 2008 at 12:01 PM, Joe Walker <joe@...> wrote:

On Thu, Jul 3, 2008 at 2:36 PM, Kevin Conaway <kevin.conaway@...> wrote:

...

The CLA is on its way via email

What address are you sending to?

Joe.

From forum: DWR - Users

Re: Long time processing in the DwrServlet.service()

2008-07-04T10:28:28Z

On Wed, Jun 11, 2008 at 8:43 PM, Mike Wilson <mikewse@...> wrote:

Great! I think this will help us a lot. I'm guessing that this
exception is thrown from ParseUtil.java:110 while it is reading
the POST body from the request InputStream.
As these requests are delayed by 60 secs my next guess is that it
is waiting for data and times out. Is the SimpleFramework socket
possibly configured with a timeout of 60 secs? Could you configure
the Simple socket to another timeout value and try again?

Maybe you could also configure your SimpleReq->ServletReq adapter
to spy on the input stream and log what data is actually fetched
by DWR for the different requests, so we can see how much DWR is
actually fetching before giving up on the slow requests.

I'm also noting that the
throw new ServerException
on line 110 isn't being logged, so we can't see the nested exception.

Joe: could we add logging of this exception?

Yes, but I'm not keen on doing this to 2.0.

I'm just checking something for this into HEAD, can you try it out there?

Joe.

From forum: DWR - Users

Re: Add "role" attribute to

2008-07-04T10:24:27Z

The address that was on the document, cla@...

I received a confirmation from Alyssa Maire

On Fri, Jul 4, 2008 at 12:01 PM, Joe Walker <joe@...> wrote:

On Thu, Jul 3, 2008 at 2:36 PM, Kevin Conaway <kevin.conaway@...> wrote:

...

The CLA is on its way via email

What address are you sending to?

Joe.

From forum: DWR - Users

Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.

2008-07-04T10:04:44Z

Well, it does not add much compared to a full integration. It is more of an optional library support (like spring or webwork). People do still need to know how to use jawr as well.

Anyway, I was trying to offer a compromise between getting everything done for 3.0 or doing nothing until 3.1. But if we are going to integrate things this might actually be a waste of time. All things considered, I guess it's best to get started on integration so we at least make it for 3.1.

I need to release a minor version with a couple of fixes and then I'll dive into the 3.0 code, to see if I can figure out a proposal for how to get things going.

Cheers, Jordi

Joe Walker-3 wrote:

I'd be happy to do that, but I'm not sure that it adds much does it?
In order to use DWR with JAWR people are still going to need to get a jawr
jar and understand how to use jawr. On the other hand it does make the DWR
build etc more complex.

Joe.

From forum: DWR - Users

Re: Handling Batch Exceptions

2008-07-04T09:20:31Z

So I'm prepared to give this a go. I've just removed the check from BaseCallHandler (in SVN HEAD). I think it will now be handled by DefaultRemoter alone, which should push it out at the call level rather than the batch level.
Please report back on how it works.

Joe.

On Thu, Jul 3, 2008 at 1:20 PM, Kevin Conaway <kevin.conaway@...> wrote:

Unfortunately, doing nothing isn't an option for me. In my case, I'm using Spring Security in AccessControl to validate the current users role. If the current user isn't there (which probably means their session timed out), Spring Security will throw some kind of exception about the credentials not being available any more. I'd like to handle those exceptions in a more robust manner.

The other thing I noticed is that DWR calls AccessControl.assertExecutionIsPossible in BaseCallHandler.marshallInbound() and again in DefaultRemoter.execute().

Is it necessary to call that method twice? I would prefer it if the method was called only in DefaultRemoter.execute() because any exceptions that are thrown are treated as "user" exceptions, not a "server" exception and are marshalled appropriately

Kvin

On Thu, Jul 3, 2008 at 5:20 AM, Joe Walker <joe@...> wrote:

From memory, the theory was that if you send in a batch, and if one of the calls in the batch violates a security constraint then we have a potential hacking incident, and the whole batch should be rejected.
The general principle is - if you suspect hacking, just stop processing and say nothing.

It sounds as though your setup defines a security problem to be part of the auth mechanism?
What do people think: Are we being too restrictive?

Joe.

On Wed, Jul 2, 2008 at 6:21 PM, Kevin Conaway <kevin.conaway@...> wrote:

I'm attempting to override AccessControl.assertIsRestrictedByRole to do some custom role checking. I'd like to throw an Exception back to the caller if the user doesn't have the correct permission.

The problem seems to be that the Exception is being caught by BaseCallHandler.handle() which calls BaseCallHandler.marshallException()

BaseCallHandler.marshallException() marshalls the exception using the EnginePrivate.getRemoteHandleBatchExceptionScript() call which loses destroys all type information and associated instance variables in the thrown Exception.

Why isn't the Exception marshalled in the same manner of Exceptions thrown when executing a method call?

Since its marshalled differently without type information, I can't do "instanceof" checks or get at the Exception state.

Thanks,

Kevin

From forum: DWR - Users

Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.

2008-07-04T09:04:57Z

I'd be happy to do that, but I'm not sure that it adds much does it?
In order to use DWR with JAWR people are still going to need to get a jawr jar and understand how to use jawr. On the other hand it does make the DWR build etc more complex.

Joe.

On Thu, Jul 3, 2008 at 2:34 PM, Jordi Hernandez <jordihs@...> wrote:

I'm flattered to see such interest! :-)

Maybe a compromise solution would be to add the current 3.0 plugin (just a
matter of throwing it in the source tree, although the jawr and log4j jars
would still be required separately) and tighten integration later for 3.1.

That said I don't mind waiting or getting right into it, whatever you guys
decide...

Jordi.

Joe Walker-3 wrote:
>

> The argument for holding off a release is always the same though isn't it?
> Gears support would be very nice too ...
>
> Joe.
>
>
>

--
View this message in context: http://www.nabble.com/Jawr-now-supports-DWR-3.-Plugin-offer-for-DWR-codebase.-tp17750178p18259333.html

Sent from the DWR - Users mailing list archive at Nabble.com.

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

From forum: DWR - Users

Re: Add "role" attribute to

2008-07-04T09:01:16Z

On Thu, Jul 3, 2008 at 2:36 PM, Kevin Conaway <kevin.conaway@...> wrote:

...
The CLA is on its way via email

What address are you sending to?

Joe.

From forum: DWR - Users

Re: Handling individual Exceptions

2008-07-04T08:57:48Z

The problem is that for each extra feature like this, the error handling documentation gets harder to understand, and I'm not convinced that it buys us a lot, does it?
Since this is for global error handlers, you only need one switch statement.
Or are you talking about having this at a call/batch level?

Joe.

On Fri, Jul 4, 2008 at 4:01 PM, Kevin Conaway <kevin.conaway@...> wrote:

Thanks. I'd like to see the the individual handlers called before the global handler but after the handler registered with the call. I suppose the precedence would be:

1.) If there was a handler registered with the call, use that
2.) If there is global handler registered for the exception type, use that
3.) Use the global error handler

If I'm able to register handlers for a certain type, it saves me from ugly conditional logic in my error handlers:

if (ex instanceof SomeException) {
// do something
} else if (ex instanceof ...) {
// something else
} else {
// punt to default handler
}

I've got a patch ready if you're interested.

On Fri, Jul 4, 2008 at 10:50 AM, Joe Walker <joe@...> wrote:

I ought to add something that wasn't clear from my original reply - the global error handler is called errorHandler and not exceptionHandler.

Joe.

On Fri, Jul 4, 2008 at 3:49 PM, Joe Walker <joe@...> wrote:

For once I'm ahead of you ...
http://directwebremoting.org/dwr/other/errors

On Fri, Jul 4, 2008 at 3:14 PM, Kevin Conaway <kevin.conaway@...> wrote:

Joe, can you explain how that works in 3.0m1?

Thanks

On Fri, Jul 4, 2008 at 9:57 AM, Joe Walker <joe@...> wrote:

You can do exactly that already in 3.0m1, with the exception that the Exception Handler gets passed all exceptions. But you're only a switch away from having just what you need.

Joe.

On Fri, Jul 4, 2008 at 2:52 PM, Kevin Conaway <kevin.conaway@...> wrote:
In addition to the global error handler, I'd like to see a way to register handlers for invidiual Exception instances. For example:

<convert converter="exception" javascript="MyException .../>

dwr.engine.setExceptionHandler(MyException, function() {
// Handler code
});

This allows for much more flexible error handling on the client side with minimal effort.

Cheers,

Kevin Conaway

From forum: DWR - Users

Global filter configuration using spring

2008-07-04T08:08:42Z

I'm trying to configure a filter in my spring xml but I get the feeling that it's not possible.

I've tried the following locations in my application context file:
<dwr:configuration>
    <dwr:init>
      <dwr:filter class="foo.bar.MyFilter" /> 
        <dwr:converter id="..." class=".." />
    </dwr:init>
    <dwr:filter class="foo.bar.MyFilter" /> 
    <dwr:convert type="..." class="..." />
</dwr:configuration>

From forum: DWR - Users

Re: Handling individual Exceptions

2008-07-04T08:01:01Z

Thanks. I'd like to see the the individual handlers called before the global handler but after the handler registered with the call. I suppose the precedence would be:

1.) If there was a handler registered with the call, use that
2.) If there is global handler registered for the exception type, use that
3.) Use the global error handler

If I'm able to register handlers for a certain type, it saves me from ugly conditional logic in my error handlers:

if (ex instanceof SomeException) {
// do something
} else if (ex instanceof ...) {
// something else
} else {
// punt to default handler
}

I've got a patch ready if you're interested.

On Fri, Jul 4, 2008 at 10:50 AM, Joe Walker <joe@...> wrote:

I ought to add something that wasn't clear from my original reply - the global error handler is called errorHandler and not exceptionHandler.

Joe.

On Fri, Jul 4, 2008 at 3:49 PM, Joe Walker <joe@...> wrote:

For once I'm ahead of you ...
http://directwebremoting.org/dwr/other/errors

On Fri, Jul 4, 2008 at 3:14 PM, Kevin Conaway <kevin.conaway@...> wrote:

Joe, can you explain how that works in 3.0m1?

Thanks

On Fri, Jul 4, 2008 at 9:57 AM, Joe Walker <joe@...> wrote:

You can do exactly that already in 3.0m1, with the exception that the Exception Handler gets passed all exceptions. But you're only a switch away from having just what you need.

Joe.

On Fri, Jul 4, 2008 at 2:52 PM, Kevin Conaway <kevin.conaway@...> wrote:
In addition to the global error handler, I'd like to see a way to register handlers for invidiual Exception instances. For example:

<convert converter="exception" javascript="MyException .../>

dwr.engine.setExceptionHandler(MyException, function() {
// Handler code
});

This allows for much more flexible error handling on the client side with minimal effort.

Cheers,

Kevin Conaway

From forum: DWR - Users

Re: Handling individual Exceptions

2008-07-04T07:50:05Z

I ought to add something that wasn't clear from my original reply - the global error handler is called errorHandler and not exceptionHandler.

Joe.

On Fri, Jul 4, 2008 at 3:49 PM, Joe Walker <joe@...> wrote:

For once I'm ahead of you ...
http://directwebremoting.org/dwr/other/errors

On Fri, Jul 4, 2008 at 3:14 PM, Kevin Conaway <kevin.conaway@...> wrote:

Joe, can you explain how that works in 3.0m1?

Thanks

On Fri, Jul 4, 2008 at 9:57 AM, Joe Walker <joe@...> wrote:

You can do exactly that already in 3.0m1, with the exception that the Exception Handler gets passed all exceptions. But you're only a switch away from having just what you need.

Joe.

On Fri, Jul 4, 2008 at 2:52 PM, Kevin Conaway <kevin.conaway@...> wrote:
In addition to the global error handler, I'd like to see a way to register handlers for invidiual Exception instances. For example:

<convert converter="exception" javascript="MyException .../>

dwr.engine.setExceptionHandler(MyException, function() {
// Handler code
});

This allows for much more flexible error handling on the client side with minimal effort.

Cheers,

Kevin Conaway

From forum: DWR - Users

Re: Handling individual Exceptions

2008-07-04T07:49:10Z

For once I'm ahead of you ...
http://directwebremoting.org/dwr/other/errors

On Fri, Jul 4, 2008 at 3:14 PM, Kevin Conaway <kevin.conaway@...> wrote:

Joe, can you explain how that works in 3.0m1?

Thanks

On Fri, Jul 4, 2008 at 9:57 AM, Joe Walker <joe@...> wrote:

You can do exactly that already in 3.0m1, with the exception that the Exception Handler gets passed all exceptions. But you're only a switch away from having just what you need.

Joe.

On Fri, Jul 4, 2008 at 2:52 PM, Kevin Conaway <kevin.conaway@...> wrote:
In addition to the global error handler, I'd like to see a way to register handlers for invidiual Exception instances. For example:

<convert converter="exception" javascript="MyException .../>

dwr.engine.setExceptionHandler(MyException, function() {
// Handler code
});

This allows for much more flexible error handling on the client side with minimal effort.

Cheers,

Kevin Conaway

From forum: DWR - Users

Re: Handling individual Exceptions

2008-07-04T07:14:54Z

Joe, can you explain how that works in 3.0m1?

Thanks

On Fri, Jul 4, 2008 at 9:57 AM, Joe Walker <joe@...> wrote:

You can do exactly that already in 3.0m1, with the exception that the Exception Handler gets passed all exceptions. But you're only a switch away from having just what you need.

Joe.

On Fri, Jul 4, 2008 at 2:52 PM, Kevin Conaway <kevin.conaway@...> wrote:
In addition to the global error handler, I'd like to see a way to register handlers for invidiual Exception instances. For example:

<convert converter="exception" javascript="MyException .../>

dwr.engine.setExceptionHandler(MyException, function() {
// Handler code
});

This allows for much more flexible error handling on the client side with minimal effort.

Cheers,

Kevin Conaway

From forum: DWR - Users

Re: Handling individual Exceptions

2008-07-04T06:57:35Z

You can do exactly that already in 3.0m1, with the exception that the Exception Handler gets passed all exceptions. But you're only a switch away from having just what you need.

Joe.

On Fri, Jul 4, 2008 at 2:52 PM, Kevin Conaway <kevin.conaway@...> wrote:

In addition to the global error handler, I'd like to see a way to register handlers for invidiual Exception instances. For example:

<convert converter="exception" javascript="MyException .../>

dwr.engine.setExceptionHandler(MyException, function() {
// Handler code
});

This allows for much more flexible error handling on the client side with minimal effort.

Cheers,

Kevin Conaway

From forum: DWR - Users

Re: Handling individual Exceptions

2008-07-04T06:57:22Z

Looks like a nice feature to add ....

In the meantime you can kind of implement it on your own by setting the
global error handler and checking the exception type within it .

Kevin Conaway wrote:

> In addition to the global error handler, I'd like to see a way to
> register handlers for invidiual Exception instances. For example:
>
> <convert converter="exception" javascript="MyException .../>
>
> dwr.engine.setExceptionHandler(MyException, function() {
> // Handler code
> });
>
> This allows for much more flexible error handling on the client side
> with minimal effort.
>
> Cheers,
>
> Kevin Conaway

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

From forum: DWR - Users

Handling individual Exceptions

2008-07-04T06:52:38Z

In addition to the global error handler, I'd like to see a way to register handlers for invidiual Exception instances. For example:

<convert converter="exception" javascript="MyException .../>

dwr.engine.setExceptionHandler(MyException, function() {
// Handler code
});

This allows for much more flexible error handling on the client side with minimal effort.

Cheers,

Kevin Conaway

From forum: DWR - Users

RE: class mapping enhancements

2008-07-03T06:58:29Z

So couldn't we just tweak getObjectClassName to inspect $dwrclassname and return that, if set?

I’m not actually sure, but sounds reasonable.

That makes sense to me, there are times when I would have used that.

Glad I came up with something useful. J

Randy

From: joseph.walker@... [mailto:joseph.walker@...] On Behalf Of Joe Walker
Sent: Thursday, July 03, 2008 8:51 AM
To: users@...
Subject: Re: [dwr-user] class mapping enhancements

On Thu, Jul 3, 2008 at 1:38 PM, Randy Jones <randy_jones@...> wrote:

Add a simplified class-mapping scheme that doesn't use JavaScript classes [F5: lighter class-mapping]

And of course I'm going to argue for this one, as it's my use case. To remind everyone of my use case, as it has been awhile, I have an api that is built on top of dojo and is fairly extensive. I'd like to be able to just set the $dwrclassname on those objects instead of having to create a new object based on my javascript attribute set in dwr.xml and copy over the attributes every time I send an object. Do I need to give a more detailed example here?

So couldn't we just tweak getObjectClassName to inspect $dwrclassname and return that, if set?

Addition:

I'm still working through this in my head, but one other suggestion might be and if the javascript attribute is set on a convert element, in the interface js we put enough information so that engine.js knows what attributes it need to serialized. This could drastically increase performance for instances like mine where my api's objects have a lot of "private" attributes that don't need to be sent to the server (and would just be dropped on the floor when they got there).

That makes sense to me, there are times when I would have used that.

Joe.

From forum: DWR - Users

Re: Add "role" attribute to

2008-07-03T06:36:12Z

Patch attached.

The integration I have with Spring Security is still in its infancy. I'll follow up with you once I have a more complete solution.

The CLA is on its way via email

Kevin

On Thu, Jul 3, 2008 at 5:00 AM, Joe Walker <joe@...> wrote:

I am interested in the patch Kevin - could you send it to the mailing list rather than JIRA?
Is the integration with Spring Security something that is generic enough that other users could benefit from it too?
And could I get you to sign a CLA? It's not ominous - it just allows us to say to our users "Our code is clean, we know where it came from"
http://directwebremoting.org/dwr/development/icla

Thanks,

Joe.

On Thu, Jul 3, 2008 at 2:11 AM, Kevin Conaway <kevin.conaway@...> wrote:

Hi Frank,

Its interesting that you mention Acegi because I'm using it with DWR instead of J2EE roles.

I've overriden AccessControl so that instead of looking up the "role" in J2EE, AccessControl validates that the current Acegi Authentication object has the given role

I'm not suggesting that the auth tag be dropped, I just think that including the "role" attribute on <include/> would be a great simplification for <auth/>'s most common use case.

Cheers,

Kevin

On Wed, Jul 2, 2008 at 8:40 PM, Frank W. Zammetti <fzlists@...> wrote:

I for one would love to see this... we use J2EE security extensively at work and this has been one of the (relatively minor) hassles with using DWR. I'd be willing to bet it was done the way it was so that definition of included methods is separate from specifying security, which I think makes sense conceptually... but in practice I agree with Kevin, this is more concise and probably less error-prone.

But, thinking against my own opinion for a moment... Kevin, is there maybe an argument to made that having a separate <auth> tag especially for security somehow makes it easier and/or cleaner to implement a different form of security? For instance, what if I wanted to use Acegi instead of container-managed security, and what if (I don't know if this is the case or not, just making up an example) Acegi calls it userGroup? I could *maybe* see an argument that extending a single <auth> tag to accept a userGroup attribute to account for that is better/cleaner than modifying the <include> tag since then there's maybe too much mixing of two different concepts (essentially authorization and authentication, in a sense) whereas with two tags they are separated conceptually... just a thought, not even sure what I think of it myself :)

Frank

--
Frank W. Zammetti
Author of "Practical DWR 2 Projects"
and "Practical JavaScript, DOM Scripting and Ajax Projects"
and "Practical Ajax Projects With Java Technology"
for info: apress.com/book/search?searchterm=zammetti&act=search
Java Web Parts - javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
My "look ma, I have a blog too!" blog: zammetti.com/blog

Kevin Conaway wrote:

I think it would be very helpful to have a "role" attribute added to <include/>.

This would vastly simplify the configuration of a creator because it is currently necessary to specify two different tags for a single method:

<create ...>
<include method="getFoo"/>
<auth method="getFoo" role="ROLE_NAME"/>
</create>

Writing:

<create ...>
<include method="getFoo" role="ROLE_NAME"/>
</create>

is much more concise and less prone to error.

I have a patch ready but the Jira link is still 404

Cheers,

Kevin

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

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

dwr-include-role.patch (2K) Download Attachment

From forum: DWR - Users

Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.

2008-07-03T06:34:13Z

I'm flattered to see such interest! :-)

Maybe a compromise solution would be to add the current 3.0 plugin (just a matter of throwing it in the source tree, although the jawr and log4j jars would still be required separately) and tighten integration later for 3.1.

That said I don't mind waiting or getting right into it, whatever you guys decide...

Jordi.

Joe Walker-3 wrote:

The argument for holding off a release is always the same though isn't it?
Gears support would be very nice too ...

Joe.

From forum: DWR - Users

Re: class mapping enhancements

2008-07-03T05:50:32Z

On Thu, Jul 3, 2008 at 1:38 PM, Randy Jones <randy_jones@...> wrote:

Add a simplified class-mapping scheme that doesn't use JavaScript classes [F5: lighter class-mapping]

And of course I'm going to argue for this one, as it's my use case. To remind everyone of my use case, as it has been awhile, I have an api that is built on top of dojo and is fairly extensive. I'd like to be able to just set the $dwrclassname on those objects instead of having to create a new object based on my javascript attribute set in dwr.xml and copy over the attributes every time I send an object. Do I need to give a more detailed example here?

So couldn't we just tweak getObjectClassName to inspect $dwrclassname and return that, if set?

Addition:

I'm still working through this in my head, but one other suggestion might be and if the javascript attribute is set on a convert element, in the interface js we put enough information so that engine.js knows what attributes it need to serialized. This could drastically increase performance for instances like mine where my api's objects have a lot of "private" attributes that don't need to be sent to the server (and would just be dropped on the floor when they got there).

That makes sense to me, there are times when I would have used that.

Joe.

From forum: DWR - Users

Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.

2008-07-03T05:45:08Z

The argument for holding off a release is always the same though isn't it?
Gears support would be very nice too ...

Joe.

On Thu, Jul 3, 2008 at 1:34 PM, Jose Noheda <jose.noheda@...> wrote:

I wouldn't put it on hold till 3.0! I'm confident that the building blocks of 3.0 (involving the topic) won't change that much so some work can be done in advance. I have to say this because 3.0 is already taking longer than expected and has no release date as of now. Starting the work today (and of course I'm not urging you by any stretch) could even bring us a late surprise ;-)

On Thu, Jul 3, 2008 at 1:26 PM, Jordi Hernandez <jordihs@...> wrote:

OK then, so let's just put this on hold until the 3.0 release. I'll get back
to you then.

Jordi

Joe Walker-3 wrote:
>

> On Thu, Jul 3, 2008 at 11:08 AM, Jordi Hernandez <jordihs@...>
> wrote:
>
>> If you want I can write a quick overview of the main components of Jawr
>> and
>> how they work together so you get the big picture.
>
>
> That would be good, thanks, although clearly, don't rush, In fact the best
> time would probably be just as 3.0 is done so I'm thinking about it at the
> right time!.\
>
> Joe.
>
>

--
View this message in context: http://www.nabble.com/Jawr-now-supports-DWR-3.-Plugin-offer-for-DWR-codebase.-tp17750178p18257184.html

Sent from the DWR - Users mailing list archive at Nabble.com.

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

From forum: DWR - Users