Vaadin Meetup in St. Petersburg on January 24, 2011

General
1

We’ll arrange the next Vaadin Meetup in St. Petersburg on January 24, 2011. The meetup will follow the agenda of the past meetups with presentations on roadmap, possibility to showcase what you have done with Vaadin, free discussion on any related topic and networking with great people. If you are in the area, please join and bring your friends too :slight_smile:

Event is free of charge - including beer and your copy of
Book of Vaadin
, but registration is required (to estimate how many people are attending):

More info on event at
http://vaadin.com/meetup

If you know a way to advertise this to people interested in Vaadin, please do!

PS. Many thanks to
Dmitri
 and
Alee Software
 for making this event possible!

Also added a LinkedIn page for the event: http://events.linkedin.com/Vaadin-Meetup-St-Petersburg/pub/497053
(but still register to
http://vaadin.com/meetup
 even if you mark yourself as attendee on LinkedIn)

2

I’m sorry. I was very ill (season influenza).
I like Vaadin very much and also want to present my add-on in Lightning Talks.

But http://vaadin.com/meetup shows:

Registration ends on Monday, January 10.

Can You help me with registration.

If you don’t have free chairs - I can stand at attention :wink:

3

That’s St-Petersburg, Russia, not the one next to Tampa (judging from blue sky and hat on your picture)

4

Yes, meeting in St-Petersburg (aka SPb), Russia.

Actually photo from Istanbul, Turkey :wink:

Friendly people, cheap goods, very interesting city, but no normal food (edible meal only in McDonald’s and Burgerking).

I live in
Vidnoe
 city, Moscow region
And I will pay for trip to Spb from my pocket, so my love to Vaadin is true :wink:
PUT me IN :wink:

PS:
Sorry! I understand your joke only now

Spb, but not in US:
US SPb

Ok, I live not here
US Moscow 1

not here
US Moscow 2

and not here
US Moscow etc

too :wink:

But I was several times in
Venice

and
Paris
 ;-)))

and (why you should invite me to this meeting) I really was here:
MARS!

PPS: ups, wrong planet, I was here
True MARS 1
 or here
True MARS 2

5

Hi, Andrew !

Registration form i still open, feel free to fill it up and welcome to Meetup ! :slight_smile:


http://vaadin.com/meetup

In your e-mail you mentioned, you have something to present - this is a double great !

Waiting you 24.01 in St.Petersburg !

6

Thank You for interesting event!
It was pleasant to see you both.

I will remind my three questions from conference:

  1. Logging in V6.5 is a Good Thing (much better than System.out in prev ;-), but nobody (i mean adequate people) likes j.u.l, nobody can configure it. Please! Use http://slf4j.org/ from java logging father. Yes, It is extra dependency jar. But it standard de facto for many projects and organizations. It’s small, it’s high-quality, it allows end user to change logger implementation (to http://logback.qos.ch for example, logback vs j.u.l is like Java6 vs 1.4)

  2. Add “refresher” to core vaadin distribution

  3. put all vaadin distribution .class files (~600 small files in WEB-INF/classes) to WEB-INF/lib/somename.jar
    All will be the same, but Vaadin distribution will look more solid and compact :wink:

7

Slf4j can bridge legacy calls to jul, jcl and log4j, so its not a problem: http://slf4j.org/legacy.html

8

Spring guys can’t switch to slf4j for backward compatibility.

You write new code, so you make it right.

slf4j site has bigger page rank than vaadin, so vaadin.jar will be dependency for slf4j :wink:

Legacy interceptor for log4j and jcl are excellent, but jul is different ;-(

http://slf4j.org/legacy.html#jul-to-slf4j

jul-to-slf4j bridge

The jul-to-slf4j module includes a java.util.logging (jul) handler, namely SLF4JBridgeHandler, which routes all incoming jul records to the SLF4j API. Please see SLF4JBridgeHandler javadocs for usage instructions.

Contrary to other bridging modules, namely jcl-over-slf4j and log4j-over-slf4j, which reimplement JCL and respectively log4j, the jul-to-slf4j module does not reimplement the java.util.logging because packages under the java.* namespace cannot be replaced. Instead, jul-to-slf4j translates LogRecord objects into their SLF4J equivalent. Please note this traslation process incurs the cost of constructing a LogRecord instance regardless of whether the SLF4J logger is disabled for the given level or nor. Consequently, j.u.l. to SLF4J translation can seriously impact on the cost of disabled logging statements (60 fold increase) and a measurable impact on enabled log statements (20% overall increase). Please note that as of logback-version 0.9.25, it is possible to completely eliminate the 60 fold translation overhead for disabled log statements with the help of LevelChangePropagator.

If you are concerned about application performance, then use of SLF4JBridgeHandler is appropriate only if one the following two conditions is true:

  1. few j.u.l. logging statements are in play
  2. LevelChangePropagator has been installed