Ate,
Thank you so much for clearing that out !!!. You are indeed a
lifesaver:) Well, your reply would amount to a newbie FAQ towards
logging as far as I am concerned.
With logging enabled, I could compare my application's action
processing in Jetspeed 2 and 1.6 to see why it is failing in JS1.6.
I find that withing Jetspeed2, the beans populate is called with all
the bean properties values, but with Jetspeed 1.6, I do not find the
bean properties. This results in validation failure, which ofcourse,
results in the failure. Well, that's a good start, now if only, I
could figure out why the bean populate/validation is failing in
Jetspeed1.6
The Jetspeed 1.6 logging clearly shows that the bean utils populate as
not having any properties, hence validation failure.
3-27 18:57:21,460 [http-8080-Processor25] DEBUG
CommonsMultipartRequestHandler - File upload temp dir:
D:\jakarta-tomcat-5.0.28\work\Catalina\localhost\welcomegreetings
2005-03-27 18:57:21,476 [http-8080-Processor25] DEBUG BeanUtils -
BeanUtils.populate(BaseForm:
|
, {_spage=[Ljava.lang.String;@1ed56e2})
2005-03-27 18:57:21,476 [http-8080-Processor25] DEBUG BeanUtils -
setProperty(BaseForm:
|
, _spage, [/saveWelcomeChanges.do])
2005-03-27 18:57:21,476 [http-8080-Processor25] DEBUG RequestProcessor
- Validating input form properties
2005-03-27 18:57:21,476 [http-8080-Processor25] DEBUG RequestProcessor
- Rolling back multipart request
2005-03-27 18:57:21,476 [http-8080-Processor25] DEBUG RequestProcessor
- Validation failed, returning to '/reshowWelcome.do'
Jetspeed2 logging clearly shows the target bean values being set and
is successful. The set property will contain all the values of the
bean property.I am not sure why the bean properties are not available
within Jetspeed 1.6. Any Pointers?
Thanks,
Hema
On Sun, 27 Mar 2005 23:22:51 +0200, Ate Douma <[EMAIL PROTECTED]> wrote:
> Hema,
>
> The log4j logging configuration *within* jetspeed can/is only be used
> for *within* the jetspeed context.
> While the current configuration file still contains definitions for
> struts, myfaces etc., this is obsolete since we removed the global
> commons-logging and log4j jars (in $Tomcat/shared/lib for example).
>
> For your own portlet applications you must provide your own logging
> setup like putting log4j (and commons-logging if you want) in WEB-INF/lib
> and also provide your own log4j.properties/xml in WEB-INF/classes.
>
> I'm going over the jetspeed log4j.properties right now and will clean out
> several of these obsolete definitions as they definitely give the wrong
> signal.
> Thanks for bringing this up ;-) It'll be another small improvement of the M2
> release.
>
> Remark: I do think it would be nice if we *could* provide a generic logging
> service
> for the portlet applications, but without getting into classloader problems on
> different platforms, right now I don't have a solid solution ready
> (although I have an idea which might work but it'll have to wait for now).
>
> Regards, Ate
>
> Hema Menon wrote:
> > I wanted to enable the logging for struts portal bridges. I added a
> > new log4j category for org.apache.portals with DEBUG level and also
> > added a logfile definition . I find the log file is created but is
> > empty. Forgive my ignorance, but is there some other configurations
> > that I am missing? Any help very much appreciated.
> >
> > Thanks,
> > Hema
> >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Hema Menon
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hema Menon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
