Re: NoClassDefFoundError

2016-02-24 Thread Steve Peery
I would guess a permissions issue. Can everything write to the log directory? 

Steve

> On Feb 24, 2016, at 10:08 PM, Jeff Schmitz  wrote:
> 
> Embedding the frameworks did work in that it allowed me to start my app from 
> the command line (Thanks!)
> 
> However now I’m at the javamonitor/wotaskd “hades” that always seems to get 
> me.  I’ve set all my WOHost vars to localhost, and am using localhost across 
> the board (Site and Host).  I’ve successfully added the application and 
> configured out, but when I start it nothing happens.  No log file, and 
> eventual a death.  Since I can start from the command line fine I don’t think 
> it’s the app itself, but with no log file to go by I’m not sure what the next 
> step would be.  Any ideas would be GREATLY appreciated.
> 
> 
> Jeff
> 
> 
> 
>> On Feb 18, 2016, at 6:17 PM, Paul Hoadley > > wrote:
>> 
>> Hi Jeff,
>> 
>> On 19 Feb 2016, at 10:39 am, Jeff Schmitz > > wrote:
>> 
>>> I’m trying to deploy to a new machine and am getting the below classpath 
>>> error when I start my app from the command line. I can build and run in my 
>>> dev environment as well as deploy to a different machine.  I checked 
>>> JAVA_HOME and it looks good so I’m not sure what to check next.  I’m 
>>> guessing my main project is looking in the wrong place for the frameworks 
>>> and added libs on the deployment machine, but I’m not sure what property 
>>> tells it where to look when deployed.  I’m hoping this is a simple one.
>> 
>> If that’s the problem, most people embed all the required frameworks in the 
>> application bundle to solve it. Set these in build.properties:
>> 
>> embed.Local=true
>> embed.Network=true
>> embed.Project=true
>> embed.System=true
>> embed.User=true
>> 
>> (If there’s some reason you can’t do this, we’ll have to explore the issue 
>> further.)
>> 
>> 
>> -- 
>> Paul Hoadley
>> http://logicsquad.net/ 
>> 
>> 
>> 
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com
> 
> This email sent to spe...@me.com

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NoClassDefFoundError

2016-02-24 Thread Jeff Schmitz
Embedding the frameworks did work in that it allowed me to start my app from 
the command line (Thanks!)

However now I’m at the javamonitor/wotaskd “hades” that always seems to get me. 
 I’ve set all my WOHost vars to localhost, and am using localhost across the 
board (Site and Host).  I’ve successfully added the application and configured 
out, but when I start it nothing happens.  No log file, and eventual a death.  
Since I can start from the command line fine I don’t think it’s the app itself, 
but with no log file to go by I’m not sure what the next step would be.  Any 
ideas would be GREATLY appreciated.


Jeff



> On Feb 18, 2016, at 6:17 PM, Paul Hoadley  wrote:
> 
> Hi Jeff,
> 
> On 19 Feb 2016, at 10:39 am, Jeff Schmitz  > wrote:
> 
>> I’m trying to deploy to a new machine and am getting the below classpath 
>> error when I start my app from the command line. I can build and run in my 
>> dev environment as well as deploy to a different machine.  I checked 
>> JAVA_HOME and it looks good so I’m not sure what to check next.  I’m 
>> guessing my main project is looking in the wrong place for the frameworks 
>> and added libs on the deployment machine, but I’m not sure what property 
>> tells it where to look when deployed.  I’m hoping this is a simple one.
> 
> If that’s the problem, most people embed all the required frameworks in the 
> application bundle to solve it. Set these in build.properties:
> 
> embed.Local=true
> embed.Network=true
> embed.Project=true
> embed.System=true
> embed.User=true
> 
> (If there’s some reason you can’t do this, we’ll have to explore the issue 
> further.)
> 
> 
> -- 
> Paul Hoadley
> http://logicsquad.net/ 
> 
> 
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Use case for a "case insensitive equals" qualifier

2016-02-24 Thread Chuck Hill
If you always want the comparison to be case insensitive, then you should be 
able to specify a database collation  for the column that is insensitive.   
Then just just a regular equals qualifier.  If you want it case sensitive 
sometimes and insensitive others, that is a different problem.

Chuck

From: 
mailto:webobjects-dev-bounces+chill=gevityinc@lists.apple.com>>
 on behalf of Lon Varscsak 
mailto:lon.varsc...@gmail.com>>
Date: Wednesday, February 24, 2016 at 5:08 PM
To: Paul Hoadley mailto:pa...@logicsquad.net>>
Cc: WebObjects Development 
mailto:webobjects-dev@lists.apple.com>>
Subject: Re: Use case for a "case insensitive equals" qualifier

Hmm, it would be interesting if there was an alternative, but really the 
problem lies in the database.  Any wildcard type searches (at least that start 
with a wildcard) are not likely to use indexes and cause a table scan.  If your 
database supported the concept of having case-insensitive indexes, then I would 
think it would be pretty trivial to implement in your own qualifier.  In Sybase 
(the database I use mostly) you can create a functional index (an index based 
on a function), but it’s the equivalent creating a second column that’s always 
lower and maintaining an index on it.  The difference being that the database 
maintains it for you (which is usually annoying for EOF).

I’ve always wanted a better way to do this too.

-Lon

On Wed, Feb 24, 2016 at 5:13 PM, Paul Hoadley 
mailto:pa...@logicsquad.net>> wrote:
Hello,

Say you have a web application where the login identifier is the user’s email 
address. This works in the conventional way: the user supplies that address at 
sign-up, and it serves two in-app functions: login identifier, and actual email 
address to which notifications can be sent. This is a fairly common pattern 
among some large, modern web apps.

It turns out that not everyone understands case sensitivity. We are seeing 
login failures in the wild because a user that signed up as 
“pa...@logicsquad.net” is now trying to log in 
with “pa...@logicsquad.net”, or vice versa. Here 
are some facts:

1. It would seem to be at least reasonably common for modern web apps that use 
email addresses as login identifiers to ignore case at login time. (For 
example, I tested a couple I had open in browser tabs: Strava and Bitbucket 
ignore case.)

2. Although the domain part of an email address is case-insensitive, my 
understanding is that the relevant RFCs suggest that you shouldn’t make 
assumptions about the local part. While everything I’ve read claims that in 
practice it will make no difference, let’s assume that we need to preserve the 
address as entered at sign-up. (It’s fail-safe to do so, whether we strictly 
need to or not.)

So, 1 is our aim: ignore case on the login identifier at login time. But 
because of 2, we don’t want to, say, normalise the email address given at 
sign-up to lower case and just store that, on the off chance that it makes a 
difference for mail delivery for that particular user. (Again, it probably 
won’t, but let’s assume that it could for the exercise.)

What are our options for finding the right User entity at login time?

1. We can jump in and naively use a CaseInsensitiveLike qualifier, but then a 
user can stick ‘?’ and ‘*’ wildcards in the input. We could strip those out, 
but they’re actually both valid characters in the local part. I stopped short 
of trying to escape them, as this route is starting to seem a little dangerous.

2. We could track both the supplied and a lower-cased version of the identifier 
in separate attributes. This has the advantage of presumably working, but it’s 
awkward, requiring special attention to changing the normalised attribute when 
the user-supplied one changes.

Can anyone suggest a better way? What I really need is a CaseInsensitiveEquals 
qualifier, like Java’s equalsIgnoreCase(). Is there such a thing? Would it be 
easily implemented?


--
Paul Hoadley
http://logicsquad.net/




 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  
(Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/lon.varscsak%40gmail.com

This email sent to lon.varsc...@gmail.com

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Use case for a "case insensitive equals" qualifier

2016-02-24 Thread Lon Varscsak
Hmm, it would be interesting if there was an alternative, but really the
problem lies in the database.  Any wildcard type searches (at least that
start with a wildcard) are not likely to use indexes and cause a table
scan.  If your database supported the concept of having case-insensitive
indexes, then I would think it would be pretty trivial to implement in your
own qualifier.  In Sybase (the database I use mostly) you can create a
functional index (an index based on a function), but it’s the equivalent
creating a second column that’s always lower and maintaining an index on
it.  The difference being that the database maintains it for you (which is
usually annoying for EOF).

I’ve always wanted a better way to do this too.

-Lon

On Wed, Feb 24, 2016 at 5:13 PM, Paul Hoadley  wrote:

> Hello,
>
> Say you have a web application where the login identifier is the user’s
> email address. This works in the conventional way: the user supplies that
> address at sign-up, and it serves two in-app functions: login identifier,
> and actual email address to which notifications can be sent. This is a
> fairly common pattern among some large, modern web apps.
>
> It turns out that not everyone understands case sensitivity. We are seeing
> login failures in the wild because a user that signed up as “
> pa...@logicsquad.net” is now trying to log in with “pa...@logicsquad.net”,
> or vice versa. Here are some facts:
>
> 1. It would seem to be at least reasonably common for modern web apps that
> use email addresses as login identifiers to ignore case at login time. (For
> example, I tested a couple I had open in browser tabs: Strava and Bitbucket
> ignore case.)
>
> 2. Although the domain part of an email address is case-insensitive, my
> understanding is that the relevant RFCs suggest that you shouldn’t make
> assumptions about the local part. While everything I’ve read claims that in
> practice it will make no difference, let’s assume that we need to preserve
> the address as entered at sign-up. (It’s fail-safe to do so, whether we
> strictly need to or not.)
>
> So, 1 is our aim: ignore case on the login identifier at login time. But
> because of 2, we don’t want to, say, normalise the email address given at
> sign-up to lower case and just store that, on the off chance that it makes
> a difference for mail delivery for that particular user. (Again, it
> probably won’t, but let’s assume that it could for the exercise.)
>
> What are our options for finding the right User entity at login time?
>
> 1. We can jump in and naively use a CaseInsensitiveLike qualifier, but
> then a user can stick ‘?’ and ‘*’ wildcards in the input. We could strip
> those out, but they’re actually both valid characters in the local part. I
> stopped short of trying to escape them, as this route is starting to seem a
> little dangerous.
>
> 2. We could track both the supplied and a lower-cased version of the
> identifier in separate attributes. This has the advantage of presumably
> working, but it’s awkward, requiring special attention to changing the
> normalised attribute when the user-supplied one changes.
>
> Can anyone suggest a better way? What I really need is a
> CaseInsensitiveEquals qualifier, like Java’s equalsIgnoreCase(). Is there
> such a thing? Would it be easily implemented?
>
>
> --
> Paul Hoadley
> http://logicsquad.net/
>
>
>
>
>  ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
>
> https://lists.apple.com/mailman/options/webobjects-dev/lon.varscsak%40gmail.com
>
> This email sent to lon.varsc...@gmail.com
>
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Use case for a "case insensitive equals" qualifier

2016-02-24 Thread Paul Hoadley
Hello,

Say you have a web application where the login identifier is the user’s email 
address. This works in the conventional way: the user supplies that address at 
sign-up, and it serves two in-app functions: login identifier, and actual email 
address to which notifications can be sent. This is a fairly common pattern 
among some large, modern web apps.

It turns out that not everyone understands case sensitivity. We are seeing 
login failures in the wild because a user that signed up as 
“pa...@logicsquad.net ” is now trying to log in 
with “pa...@logicsquad.net ”, or vice versa. Here 
are some facts:

1. It would seem to be at least reasonably common for modern web apps that use 
email addresses as login identifiers to ignore case at login time. (For 
example, I tested a couple I had open in browser tabs: Strava and Bitbucket 
ignore case.)

2. Although the domain part of an email address is case-insensitive, my 
understanding is that the relevant RFCs suggest that you shouldn’t make 
assumptions about the local part. While everything I’ve read claims that in 
practice it will make no difference, let’s assume that we need to preserve the 
address as entered at sign-up. (It’s fail-safe to do so, whether we strictly 
need to or not.)

So, 1 is our aim: ignore case on the login identifier at login time. But 
because of 2, we don’t want to, say, normalise the email address given at 
sign-up to lower case and just store that, on the off chance that it makes a 
difference for mail delivery for that particular user. (Again, it probably 
won’t, but let’s assume that it could for the exercise.)

What are our options for finding the right User entity at login time?

1. We can jump in and naively use a CaseInsensitiveLike qualifier, but then a 
user can stick ‘?’ and ‘*’ wildcards in the input. We could strip those out, 
but they’re actually both valid characters in the local part. I stopped short 
of trying to escape them, as this route is starting to seem a little dangerous.

2. We could track both the supplied and a lower-cased version of the identifier 
in separate attributes. This has the advantage of presumably working, but it’s 
awkward, requiring special attention to changing the normalised attribute when 
the user-supplied one changes.

Can anyone suggest a better way? What I really need is a CaseInsensitiveEquals 
qualifier, like Java’s equalsIgnoreCase(). Is there such a thing? Would it be 
easily implemented?


-- 
Paul Hoadley
http://logicsquad.net/



 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ERDDelayedBooleanAssignment question

2016-02-24 Thread Fabian Peters
Hi Sébastien,

If you look at ERMDDeleteButton, you'll find that canDelete() does not check 
the "isEntityDeletable" key. Instead:

return object() != null && object() instanceof 
ERXGuardedObjectInterface ? ((ERXGuardedObjectInterface)object()).canDelete() : 
true;

If you're not using the ERXGuardedObjectInterface you could use your own delete 
button via:

20 : (look = 'ERModernLook' and propertyKey = 'deleteAction') => componentName 
= "ERMDDeleteButton" [com.webobjects.directtoweb.Assignment]:Default modern 
button component names

IMHO, ERXGuardedObjectInterface can help you keep business logic out of the 
rules. I use a delegate on a common EO superclass with it to handle logic that 
is the same for all EOs.

Fabian

> Am 23.02.2016 um 09:05 schrieb Sébastien Rottiers :
> 
> Forget my previous post, in fact, it doesn’t work for me (I had forgotten to 
> remove the clear d2w cache by the code, thing that doesn’t work in 
> deployment).
> 
>> Le 23 févr. 2016 à 09:42, Sébastien Rottiers  a écrit :
>> 
>> Thanks for the replies !
>> 
>> I just test your first solution Mark and it works like a charm !
>> 
>> Sébastien
>> 
>>> Le 22 févr. 2016 à 22:47, Mark Wardle  a écrit :
>>> 
>>> I wonder whether your rules are being cached. 
>>> 
>>> I do this instead:
>>> 
>>> 100 : entity.name like 'Result*' => isEntityDeletable = 
>>> "session.authenticatedUser.role.isSystem" 
>>> [er.directtoweb.ERDDelayedKeyValueAssignment]
>>> 
>>> or
>>> 
>>> 100 : entity.name = 'Seizure' => isEntityEditable = 
>>> "object.summaryEpilepsy.patient.security.PATIENT_EDIT" 
>>> [er.directtoweb.ERDDelayedKeyValueAssignment]
>>> 
>>> where a security property on the patient entity supports arbitrary key 
>>> paths that correspond with a specific permission.
>>> 
>>> Mark
>>> 
 On 22 Feb 2016, at 13:56, Sébastien Rottiers  wrote:
 
 Hello,
 
 I have two rules to control the access write of my users (isEntityEditable 
 and isEntityDeletable). Here is these rules :
 
 100 : *true* => isEntityEditable = {"conditionKey" = 
 "session.userConnected.isAdmin"; "falseValue" = "0"; "trueValue" = "1"; } 
 [er.directtoweb.assignments.delayed.ERDDelayedBooleanAssignment],
 100 : *true* => isEntityDeletable = {"conditionKey" = 
 "session.userConnected.isAdmin"; "falseValue" = "0"; "trueValue" = "1"; } 
 [er.directtoweb.assignments.delayed.ERDDelayedBooleanAssignment],
 
 It works properly for isEntityEditable (if I login with an admin account I 
 can edit the EOs, and if I logout and login with a non admin user I can’t 
 edit EOs). But for isEntityDeletable the issue is : on the List pages 
 (ERModernLook) I already visited, when I logout/login from admin to non 
 admin, the delete button is still displayed. And in dev mode if I clear 
 the D2W cache, the delete button disappear as expected.
 
 Am I missing something ?
 
 Thanks,
 Sébastien 
  
 
 
 ___
 Do not post admin requests to the list. They will be ignored.
 Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org
 
 This email sent to m...@wardle.org
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/sebro%40mac.com
>> 
>> This email sent to se...@mac.com
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/lists.fabian%40e-lumo.com
> 
> This email sent to lists.fab...@e-lumo.com


 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com