You already know what ThreadLocal is (and used that extensively)
You see transaction management in the application code (an annotation, however is not perfect, but o.k.)
You have to deal with EntityManagerFactory and EntityTransaction in your code
Your XML-configuration doesn't fit on a single page any more
Your solution cannot be handled without extensive tooling
You spend some time for convincing other developers, that your solution is actually lightweight :-)
You are in the process of replacing existing frameworks with your "lightweight" POJOs and hope the result will be easier, lighter and better maintainable
You forgot the name and purpose of the layers
The number of interfaces is equal or greater, than the number of classes, and you need naming conventions to deal with that
The deployment size of your application archive (WAR) is greater, than the installation size of your "lightweight" server (like tomcat)
Comments:
11. To document your homemade interceptor API, you need a threedimensional UML dialect, two laser pointers, and one new LaTeX package.
Posted by
Gerald Struck
on October 01, 2010 at 07:15 PM CEST
#
agreed... on everything but 10. - Is an application not lightweight if it's heavy? ;) how could I handle big applications in a lightweight matter or do I have to accept, that I didn't make a lightweight application if 10. turns true?
Posted by
björn
on October 01, 2010 at 07:37 PM CEST
#
@Björn,
to satisfy the point 10, you could also put more JARs into tomcat, so that your WAR will be still smaller :-)
thanks!,
adam
Posted by
adam-bien.com
on October 01, 2010 at 08:13 PM CEST
#
@Gerald,
in your case its impossible to document the interceptors - because the interception points are computed dynamically :-),
thanks,
adam
Posted by
adam-bien.com
on October 01, 2010 at 08:14 PM CEST
#
#1 is nonsense. Using threadlocals makes an api a lot easier to use, especially in lightweight architectures. They can be used for all kinds of stuff like transactions or security related settings.
But since you are so much in using everything the JEE specs coughs out, I guess you don't know what lightweight really is.
Peter Veentjer
Multiverse: Software Transactional Memory for Java
http://multiverse.codehaus.org
Posted by
Peter Veentjer
on October 02, 2010 at 06:13 AM CEST
#
@Peter,
#1 is nonsense in general, because most of the application server are using ThreadLocal behind the scenes. If you are using ThreadLocal to replicate already existing functionality, you end up with unnecessary code - and bloat.
"But since you are so much in using everything the JEE specs"
I look at the existing functionality first. If it is good enough, I just use it. Otherwise I widen the search.
"I guess you don't know what lightweight really is."
I would define lightweight as: "Minimal amount of infrastructural code, and highest possible emphasis on business logic". Agreed?
Btw. your solution looks interesting and promising. Will have to play with it.
thanks!,
adam
Posted by
adam-bien.com
on October 02, 2010 at 01:31 PM CEST
#
Your application is not lightweight if you have to wait 5 minuts before being able to discover that, no... your web page still sucks
Your application is not lightweight if you have to rename your JAR so that 01_orm.jar is loaded before 02_orm_by_summer.jar and it finally works with Websphere.
Your application is not lightweight if you can't copy your EAR on an USB key or if your customer Firewall blocks the file when you try to upload-it
Your application is not lightweight if you need OSGi to partially make it work
Your application is not lightweight if maven takes more than 10 minutes to download all dependencies from Internet
I think majority of these points are correct for small applications but when we are dealing with bpel engines, extensive JMS, databases, transactional caches in the business layer several of them will be ruled out but generally I cannot agree with 10 and 4 and a bit laughed at 8 and 9 :D
just imagine yourself when you are bundling few libraries like JasperReport into the application bundle, you will exceed the size. But as Adam said, we can add more JARs into the apps and we will be complying with the rule. :D
The configuration can grow larger than multiple pages even for small applications unless you move everything into the source code as annotations, thanks to Java EE 6. But I am old-school way and prefer to use the XML descriptors for most parts.
Posted by
Masoud Kalali
on October 02, 2010 at 10:49 PM CEST
#
@Nicolas, It depends on the Internet connection though.
Posted by
Masoud Kalali
on October 02, 2010 at 10:50 PM CEST
#
@Nicolas,
I assume you had lots of fun with WebSphere already :-). The newer WebSphere releases are surprisingly "lightweight" (comparing to the older versions),
thanks!,
adam
Posted by
adam-bien.com
on October 03, 2010 at 12:48 AM CEST
#
@Masoud,
"But I am old-school way and prefer to use the XML descriptors for most parts."
At the very beginning (~JDK 1.1) I built some frameworks, where everything was replaceable with lots of reflection and property-files. It was cool, but we rarely configured anything...
In my current Java EE 6 projects I don't have any XML configuration and it works surprisingly well. Just try once to follow the "Convention Over Configuration" route. The good news are - if you get the demand, you can easily override the conventions as well as the annotations with XML deployment descriptors.
thanks for your comment!
adam
Posted by
adam-bien.com
on October 03, 2010 at 12:52 AM CEST
#
It would be nice if, you learned how, a comma, works.
Posted by
John Haugeland
on October 06, 2010 at 12:39 AM CEST
#
@John,
in Java comma is needed to separate all parameters in a method call. This is not true for scala and ruby :-)
Any concrete hints / suggestions? It is hard to learn from your comment...
adam
Posted by
adam-bien.com
on October 06, 2010 at 12:45 AM CEST
#
Hi, I came from netbeans page to your blog, I was surprised you are not angered by any of the comments above, which directly takes you down, including the comma correction, how are you doing it!?
- San
Posted by
Santhosh
on October 12, 2010 at 07:07 PM CEST
#
@Santosh,
I'm not a professional blogger - just a "Starbucks" blogger. The posts are not perfect - but I hope the point is clear. 99% of the feedback is constructive - so it is still worth it. The guy with the comma was absolutely right - I re-read the post and the punctuation is actually wrong. But: who cares about commas in the twitter-age of 140 characters :-)
Thanks for your nice comment (I assume your intentions are positive :-)),
adam
Posted by
adam-bien.com
on October 12, 2010 at 07:20 PM CEST
#
Hi Adam,
I would add my $.02:
# 11. You can not execute unit but also integration tests from your favorite IDE.
# 12. The project is not portable between app server vendors (i.e: security).
Posted by
Marcin
on October 14, 2010 at 02:09 PM CEST
#
@Marcin,
#11 - is a good point. In projects I see the opposite -> local built breaks to often the CI
#12 - portability is important and since Java EE 5 mostly given. We should remain pragmatic: at some point you will have to decide whether to re-implement existing proprietary API (e.g. Hibernate, Eclipse-Links) or be dependent on it.
Although #12 is important - I wouldn't count it as a "lightweight-ness" indicator,
thanks for sharing your thoughts,
adam
Posted by
adam-bien.com
on October 14, 2010 at 11:23 PM CEST
#
#1 is not valid.
A lot of frameworks, and application servers have been using ThreadLocals for a very long time, and very effectively.
A few that come to mind are AspectJ, Apache Shiro, Tagger Cat. Also, does JSF not use a ThreadLocal for its context object?
ThreadLocals are very, very useful, and of course are a valid component of the JDK.
I think you should provide some backup as to why they are a bad thing, otherwise, please consider removing this from your list.
Like most things, with power, comes responsibility.
One, issue I have encountered using ThreadLocals is that they need to be cleaned up in a server environment, so that they don’t pollute pooled threads. But, cleaning up TheadLocals is usually easily handled in filter.
Thanks
Posted by
Grant
on March 20, 2011 at 09:56 PM CET
#
@Grant,
I agree with you: the infrastructure (Java EE server, EJB container, CDI container, JSF implementation etc) need ThreadLocal. BUT: because it is already implemented by the infrastructure, it is rarely needed in the application code.
If you are starting with ThreadLocal the chances are hight, that you try to replicate already existing application server functionality OR you are building your own server on bare WebContainer,
are you o.k with that? :-)
thank you for your comment,
adam
Posted by
adam-bien.com
on March 22, 2011 at 11:12 PM CET
#
I am going to agree with Santhosh on this one.
A couple of the comments were not nice and I was surprised that you were able to provide polite responses.
Thank you for your time.
Posted by
jonnie savell
on November 21, 2012 at 10:20 PM CET
#
Post a Comment:
Number of posts: 2419
Number of comments: 6163
Yesterday's hits: 14161
Today's hits: 17891
Post reads / hour: 649
Top posts:
11. To document your homemade interceptor API, you need a threedimensional UML dialect, two laser pointers, and one new LaTeX package.
Posted by Gerald Struck on October 01, 2010 at 07:15 PM CEST #
agreed... on everything but 10. - Is an application not lightweight if it's heavy? ;) how could I handle big applications in a lightweight matter or do I have to accept, that I didn't make a lightweight application if 10. turns true?
Posted by björn on October 01, 2010 at 07:37 PM CEST #
@Björn,
to satisfy the point 10, you could also put more JARs into tomcat, so that your WAR will be still smaller :-)
thanks!,
adam
Posted by adam-bien.com on October 01, 2010 at 08:13 PM CEST #
@Gerald,
in your case its impossible to document the interceptors - because the interception points are computed dynamically :-),
thanks,
adam
Posted by adam-bien.com on October 01, 2010 at 08:14 PM CEST #
#1 is nonsense. Using threadlocals makes an api a lot easier to use, especially in lightweight architectures. They can be used for all kinds of stuff like transactions or security related settings.
But since you are so much in using everything the JEE specs coughs out, I guess you don't know what lightweight really is.
Peter Veentjer
Multiverse: Software Transactional Memory for Java
http://multiverse.codehaus.org
Posted by Peter Veentjer on October 02, 2010 at 06:13 AM CEST #
@Peter,
#1 is nonsense in general, because most of the application server are using ThreadLocal behind the scenes. If you are using ThreadLocal to replicate already existing functionality, you end up with unnecessary code - and bloat.
"But since you are so much in using everything the JEE specs"
I look at the existing functionality first. If it is good enough, I just use it. Otherwise I widen the search.
"I guess you don't know what lightweight really is."
I would define lightweight as: "Minimal amount of infrastructural code, and highest possible emphasis on business logic". Agreed?
Btw. your solution looks interesting and promising. Will have to play with it.
thanks!,
adam
Posted by adam-bien.com on October 02, 2010 at 01:31 PM CEST #
Your application is not lightweight if you have to wait 5 minuts before being able to discover that, no... your web page still sucks
Your application is not lightweight if you have to rename your JAR so that 01_orm.jar is loaded before 02_orm_by_summer.jar and it finally works with Websphere.
Your application is not lightweight if you can't copy your EAR on an USB key or if your customer Firewall blocks the file when you try to upload-it
Your application is not lightweight if you need OSGi to partially make it work
Your application is not lightweight if maven takes more than 10 minutes to download all dependencies from Internet
Posted by Nicolas Martignole on October 02, 2010 at 10:37 PM CEST #
I think majority of these points are correct for small applications but when we are dealing with bpel engines, extensive JMS, databases, transactional caches in the business layer several of them will be ruled out but generally I cannot agree with 10 and 4 and a bit laughed at 8 and 9 :D
just imagine yourself when you are bundling few libraries like JasperReport into the application bundle, you will exceed the size. But as Adam said, we can add more JARs into the apps and we will be complying with the rule. :D
The configuration can grow larger than multiple pages even for small applications unless you move everything into the source code as annotations, thanks to Java EE 6. But I am old-school way and prefer to use the XML descriptors for most parts.
Posted by Masoud Kalali on October 02, 2010 at 10:49 PM CEST #
@Nicolas, It depends on the Internet connection though.
Posted by Masoud Kalali on October 02, 2010 at 10:50 PM CEST #
@Nicolas,
I assume you had lots of fun with WebSphere already :-). The newer WebSphere releases are surprisingly "lightweight" (comparing to the older versions),
thanks!,
adam
Posted by adam-bien.com on October 03, 2010 at 12:48 AM CEST #
@Masoud,
"But I am old-school way and prefer to use the XML descriptors for most parts."
At the very beginning (~JDK 1.1) I built some frameworks, where everything was replaceable with lots of reflection and property-files. It was cool, but we rarely configured anything...
In my current Java EE 6 projects I don't have any XML configuration and it works surprisingly well. Just try once to follow the "Convention Over Configuration" route. The good news are - if you get the demand, you can easily override the conventions as well as the annotations with XML deployment descriptors.
thanks for your comment!
adam
Posted by adam-bien.com on October 03, 2010 at 12:52 AM CEST #
It would be nice if, you learned how, a comma, works.
Posted by John Haugeland on October 06, 2010 at 12:39 AM CEST #
@John,
in Java comma is needed to separate all parameters in a method call. This is not true for scala and ruby :-)
Any concrete hints / suggestions? It is hard to learn from your comment...
adam
Posted by adam-bien.com on October 06, 2010 at 12:45 AM CEST #
Hi, I came from netbeans page to your blog, I was surprised you are not angered by any of the comments above, which directly takes you down, including the comma correction, how are you doing it!?
- San
Posted by Santhosh on October 12, 2010 at 07:07 PM CEST #
@Santosh,
I'm not a professional blogger - just a "Starbucks" blogger. The posts are not perfect - but I hope the point is clear. 99% of the feedback is constructive - so it is still worth it. The guy with the comma was absolutely right - I re-read the post and the punctuation is actually wrong. But: who cares about commas in the twitter-age of 140 characters :-)
Thanks for your nice comment (I assume your intentions are positive :-)),
adam
Posted by adam-bien.com on October 12, 2010 at 07:20 PM CEST #
Hi Adam,
I would add my $.02:
# 11. You can not execute unit but also integration tests from your favorite IDE.
# 12. The project is not portable between app server vendors (i.e: security).
Posted by Marcin on October 14, 2010 at 02:09 PM CEST #
@Marcin,
#11 - is a good point. In projects I see the opposite -> local built breaks to often the CI
#12 - portability is important and since Java EE 5 mostly given. We should remain pragmatic: at some point you will have to decide whether to re-implement existing proprietary API (e.g. Hibernate, Eclipse-Links) or be dependent on it.
Although #12 is important - I wouldn't count it as a "lightweight-ness" indicator,
thanks for sharing your thoughts,
adam
Posted by adam-bien.com on October 14, 2010 at 11:23 PM CEST #
#1 is not valid.
A lot of frameworks, and application servers have been using ThreadLocals for a very long time, and very effectively.
A few that come to mind are AspectJ, Apache Shiro, Tagger Cat. Also, does JSF not use a ThreadLocal for its context object?
ThreadLocals are very, very useful, and of course are a valid component of the JDK.
I think you should provide some backup as to why they are a bad thing, otherwise, please consider removing this from your list.
Like most things, with power, comes responsibility.
One, issue I have encountered using ThreadLocals is that they need to be cleaned up in a server environment, so that they don’t pollute pooled threads. But, cleaning up TheadLocals is usually easily handled in filter.
Thanks
Posted by Grant on March 20, 2011 at 09:56 PM CET #
@Grant,
I agree with you: the infrastructure (Java EE server, EJB container, CDI container, JSF implementation etc) need ThreadLocal. BUT: because it is already implemented by the infrastructure, it is rarely needed in the application code.
If you are starting with ThreadLocal the chances are hight, that you try to replicate already existing application server functionality OR you are building your own server on bare WebContainer,
are you o.k with that? :-)
thank you for your comment,
adam
Posted by adam-bien.com on March 22, 2011 at 11:12 PM CET #
I am going to agree with Santhosh on this one.
A couple of the comments were not nice and I was surprised that you were able to provide polite responses.
Thank you for your time.
Posted by jonnie savell on November 21, 2012 at 10:20 PM CET #