Technical Beef -

i use the way named JDBCStore.But i find nothing from the table tomcat_sessions.what's the reason ?

so jessionid cannot be used with https?

Hi Toni,

I hesitated somewhat to publish your comment, because it severely lacks arguments, and I think you're missing the big picture here. Anyway, it's not worth than some of the viagra-spam that sometimes pass the spam barrier, so I just let it.

First, the point you mention was already discussed there: http://blog.kornr.net/index.php/2008/12/18/osgi-logging-putting-it-all-together (read the comments please)

I'm not sure why you're aggressively defending Pax Logging, which is not a bad solution except it fragments _again_ the logging frameworks used by the java community, which by itself is enough to keep it at bay, but what really bothered me was all the FUD the PAX initiative seemed to use in order to justify their solution. From what I can see, bad habits are not lost.

Regarding your argument "it creates fat "self contained" bundles, sweeping out the entire service layer and replacing it with monotholic (I suppose you mean "monolithic", right?) uber bundles", it only shows you have not correctly understood what commons-logging is: it's not just a logging framework, it's also designed to be a _facade_ for a logging system that you can define at runtime. Let me put some emphasis on this: FACADE. I'm pretty sure you know how the facade pattern works, and why it makes sense to keep this facade because, well, it's widely used and can be considered a de facto standard.

It's straightforward to keep the commons-logging facade (that's 2 classes, Log and LogFactory), and just change the code behind to call the the OSGi Log Service instead of the normal commons-logging engine that is available by default. That's what the sample code I provide (2 classes, 6Kb in total, is that what you call fat?) do. Nothing more. The benefit of that is that only one logging API is used (read facade), and a common code base can be shared between OSGi and non-OSGi projects.

Now, please read the article I mentionned above, and if you have any suggestion for a better solution (and I'm sure there are), please do not hesitate to give a pointer. Pax Logging is not what _I_ call a better solution, but I'm not offended if it is for others. Just, please, stop the FUD, I'm sure you can make up better arguments than that to convince people to use your PAX stuff.

Hi,

just found your blogs and complaints about Pax Logging.
Looking at your solution, i don't know if this is an april fool's joke or ment to be serious? Are you really saying that embedding the commons logging libs into each bundle is a solution?
What you showed here is counter-productive as it creates fat "self contained" bundles, sweeping out the entire service layer and replacing it with monotholic uber bundles.
I am not sure, maybe this article is too old (2008?) and does not reflect your current mindset anymore. (i hope so).
No offence, just blown away from spreading those code smells.
cheers,
Toni

Heman,

No you can't use this solution with different domains. A JSESSIONID is just an HTTP cookie and HTTP cookies can't be shared with different domains (browser will not send cookies to different domains).

It was done on purpose to confuse the issue from what I've understood.

Äàííàÿ ïóáëèêàöèÿ èìååò íåôîðìàëüíûé, èíôîðìàòèâíûé ñòèëü, áîëüøîå ñïàñèáî Âàì!

Very cool stuff.

sorry, the link was lost during a server migration.
It's fixed now.

Looks like something I could use! But the download links don't work. Any chance to fix that?

Yeah, this is absolutly correct, shame on you Nga! :-)

Hi: I have a problem , if I want to ctreat a log file and log information using commonning-log.jar

how to ?

thank you !

A question.

Can the jSession id in a Tomcat be shared within 2 different domains (say www.example1.com and www.example2.com) the same way it can be shared between 2 sub-domains?

Any help will be much appreciated.

Heman..

So far..Mixing the loggers works for me and Now I am experimenting Leonid's idea.
My question is how does slf4j binds a logger..I am not sure..Can you publish your code Leonid.

This article was very helpful to me.
I actually found a solution without the need of embedding those jars in every bundle. It may not work for everybody, but for me it was actually what I was looking for.
I wanted to have the logging on the server to be configured in one place. My thinking was: even though there will be multiple bundles running, together they constitute an application, and it will make sense to define everything related to the logging in one place.
So here is how I did it. I created one bundle that embeds the slf4j-api,slf4j-log4j12, and log4j jar files, as described in the article. It exports the org.slf4j package. All other bundles import org.slf4j, and in the code they use pure slf4j stuff. Everything works fine, and I can control all log4j configuration in one file. I used rolling file appenders, and I configured different files for different packages, so each bundle has its own log file.

The Swit project is a result of me not making buttons fast enough.

Very Nice and Good Job for handling the highly "Confused Topic by mob..."..

Just couple of thoughts:
1. How about having a aspect using AspectJ to use the OSGI Services and attach the OSGI services to SLF4J or JCL facade...
This way you are not tightly coupled...

Thoughts?

Interesting article, Im looking to write one similar to yours in spanish. Thanks.

What happens to the pagemap with the second level cache is not altered by the session being stored by tomcat in memory or in a jdbc store. How Tomcat manages its servlet session happens on a totally different layer.

Consequently, when the second level cache and the jdbc store are both used, pagemaps are still stored on the filesystem, and the session still contains a simple reference to this pagemaps, used by the second level cache to load it back in memory when needed.

The only difference is that without the jdbc store, the session always reside in memory, while it can be persisted in the database after a while when the jdbc store is used. PageMaps are just a specific data of the sessions, that happens to be managed differently by Wicket's HttpSessionStore (pagemaps always stored in the session) and SecondLevelCacheSessionStore (pagemaps always stored on disk, only a reference is kept in the session)

But what happens to the PageMap that is serialized to disk while the session is persisted to mysql? Will the pages still exist when a user finally does something?

Or will the pagemap persist as long as the session is valid (until the session times-out)?