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]
