You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2003/04/22 15:46:17 UTC
Re: cvs commit: jakarta-turbine-2/src/java/org/apache/turbine/om/
EPugh@upstate.com writes:
>------_=_NextPart_001_01C308C9.B0FCEBC0
>Content-Type: text/plain;
> charset="iso-8859-1"
>The reason I added the:
> if(this.permStorage==null){
> this.permStoreage = new Hashtable(10);
>}
>was because with the PassiveUserManager and DBSecurityService, every time I
>created a TurbineUser, it would try and to a setPerm and fail becuase the
>hashtable was null...
>I wrote a Cactus test, TurbineUserTest to validate this problem.. For the
>life of me, I could not figure out what the ctor for TurbineUser wasn't
>called, I eventually decided that it was because the super class
>SecurityObject's ctor was being used, although I could very easily be
>wrong.. Could you please try and run the TurbineUserTest without my code
>changes, and validate that TurbineUser can be created?
Hi,
that can't be. C'tors are not inherited and we have a Default C'tor in
TurbineUser. So I see no way around the creation of the hash table
objects.
>Also, the big with the multiple exits. I actually agree with you. however,
>one of the methods worked with one exit, the other worked with two. So I
>wanted to have both have the same pattern. But I can change both to have a
>single exit.
>I will change the void setX(String x) { this.x = x } pattern.
>If you can test the TurbineUser, let me know how it goes, and then I'll make
>the changes.
Will do.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-turbine-2/src/java/org/apache/turbine/om/
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
>EPugh@upstate.com writes:
Ok, I found it. It goes like this:
TurbineUser()
super() --> SecurityObject()
--> setName("")
--> TurbineUser::setPerm("")
BOOM!
permStorage = new Hashtable();
The problem is, that you can't put the new Hashtable() statements into
the instance variable declarations, because
(http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html#58549)
--- cut ---
Just before a reference to the newly created object is returned as
the result, the indicated constructor is processed to initialize the
new object using the following procedure:
1. Assign the arguments for the constructor to newly created
parameter variables for this constructor invocation.
2. If this constructor begins with an explicit constructor
invocation of another constructor in the same class (using
this), then evaluate the arguments and process that constructor
invocation recursively using these same five steps. If that
constructor invocation completes abruptly, then this procedure
completes abruptly for the same reason; otherwise, continue with
step 5.
3. This constructor does not begin with an explicit constructor
invocation of another constructor in the same class (using
this). If this constructor is for a class other than Object,
then this constructor will begin with an explicit or implicit
invocation of a superclass constructor (using super). Evaluate
the arguments and process that superclass constructor invocation
recursively using these same five steps. If that constructor
invocation completes abruptly, then this procedure completes
abruptly for the same reason. Otherwise, continue with step 4.
4. Execute the instance initializers and instance variable
initializers for this class, assigning the values of instance
variable initializers to the corresponding instance variables,
in the left-to-right order in which they appear textually in the
source code for the class. If execution of any of these
initializers results in an exception, then no further
initializers are processed and this procedure completes abruptly
with that same exception. Otherwise, continue with step 5. (In
some early implementations, the compiler incorrectly omitted the
code to initialize a field if the field initializer expression
was a constant expression whose value was equal to the default
initialization value for its type.)
5. Execute the rest of the body of this constructor. If that
execution completes abruptly, then this procedure completes
abruptly for the same reason. Otherwise, this procedure
completes normally. In the example:
--- cut ---
We need the hash tables at 3) but will get them initialized in 4) or
5).
So your code is correct, we must check for null at getTemp/PermStorage
because these methods run potentially earlier than the c'tor methods
or the instance variable assignments in the class ( =:-O Wow, learned
something new about Java that I'd never expected... )
I have a cleaned up version of TurbineUser checked in. As I'm not able
to get the cactus stuff to run, please try out. This should work now
in all cases.
Regards
Henning
>>------_=_NextPart_001_01C308C9.B0FCEBC0
>>Content-Type: text/plain;
>> charset="iso-8859-1"
>>The reason I added the:
>> if(this.permStorage==null){
>> this.permStoreage = new Hashtable(10);
>>}
>>was because with the PassiveUserManager and DBSecurityService, every time I
>>created a TurbineUser, it would try and to a setPerm and fail becuase the
>>hashtable was null...
>>I wrote a Cactus test, TurbineUserTest to validate this problem.. For the
>>life of me, I could not figure out what the ctor for TurbineUser wasn't
>>called, I eventually decided that it was because the super class
>>SecurityObject's ctor was being used, although I could very easily be
>>wrong.. Could you please try and run the TurbineUserTest without my code
>>changes, and validate that TurbineUser can be created?
>Hi,
>that can't be. C'tors are not inherited and we have a Default C'tor in
>TurbineUser. So I see no way around the creation of the hash table
>objects.
>>Also, the big with the multiple exits. I actually agree with you. however,
>>one of the methods worked with one exit, the other worked with two. So I
>>wanted to have both have the same pattern. But I can change both to have a
>>single exit.
>>I will change the void setX(String x) { this.x = x } pattern.
>>If you can test the TurbineUser, let me know how it goes, and then I'll make
>>the changes.
>Will do.
> Regards
> Henning
>--
>Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
>hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>Java, perl, Solaris, Linux, xSP Consulting, Web Services
>freelance consultant -- Jakarta Turbine Development -- hero for hire
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org