Stan Sokolov

Tnx! It worked and I agree this is a junk design pattern to embed such a code in a jsp. Was just playing.

Jesper de Jong wrote:That's not true, I'm using Tomcat 8 on Java 8 without problems. Why do you think Tomcat 8 does not work on Java 8?

From the Tomcat 8.0.15 Release Notes:

Tomcat 8.0.15 Release Notes wrote:
Tomcat 8.0 is designed to run on Java SE 7 and later.

It does not when it comes to JSP pages. Try to use closures in a JSP page

Collections.sort(selectedLines, (String o1, String o2)->f.parse(o1.split(",")[0]).compareTo(f.parse(o2.split(",")[0])));

The exception will follow as bellow.

type Exception report

message Unable to compile class for JSP:

description The server encountered an internal error that prevented it from fulfilling this request.

exception

org.apache.jasper.JasperException: Unable to compile class for JSP:

An error occurred at line: 131 in the jsp file: /inventory.jsp
Lambda expressions are allowed only at source level 1.8 or above
128: }
129:
130:
131: Collections.sort(selectedLines, (String o1, String o2)->f.parse(o1.split(",")[0]).compareTo(f.parse(o2.split(",")[0])));
132:
133: //Collections.sort(selectedLines, new StringDateComparator());
134: DateFormat formatterCsv1 = new SimpleDateFormat("MM/dd/yyyy HH:mm:ss SSS");


Stacktrace:
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:103)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:199)
org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:450)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:361)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:336)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:323)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:396)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:340)
javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

note The full stack trace of the root cause is available in the Apache Tomcat/8.0.15 logs.

Tomcat 8 apparently does not work with Java 8. So is any alternative available already ?

Ankita Jha wrote:Hello ranchers,

I m trying to implement spring validator for MultiActionController,
Can any one provide me a sample code for doing the same.
For SimpleFormController it works well..
Neeed to try out the same for MultiActionController

Thanks in Advance,
Ankita

After reading millions of forums... ok well dozens to be correct. I am inclining to assumption that it is not possible. Everywhere is published some nonsense that hiding the fact that individual methods could not be bound to a validator. It makes MultiActionController effectively useless. I wish Spring Developers tell about that thing upfront to not waste time on it.

Rick Goff wrote:I'm not sure it's due diligence for you to glance at a language Martin Odersky and others took years to produce, and declare it unreadable. What else is unreadable to you? Russian? Mandarin?

Sorry if that's snarky. More constructively, I suggest you post a sample of "unreadable" Scala and see if we can work out what it means.

Any Scala code premier looks like an ugly PERL script. It might be shorter than Java in some way, but I would give +1 for this and -10 for readability.
/** Print prime numbers less than 100, very inefficiently */ object primes extends Application { def isPrime(n: Int) = (2 until n) forall (n % _ != 0) for (i <- 1 to 100 if isPrime(i)) println(i) }

Palak Mathur wrote:

Stas Sokolov wrote:

Mohamed Sanaulla wrote:

Stas Sokolov wrote:Is there any Java framework / JVM extension that already in one way or another mimics this syntax ?

You can have a look at the JVM based language called Scala.

It looks not so good. Syntax is unreadable. Somebody who decided to use a class body to define lines of constructor between different methods was just insane. This one Kotlin is a little bit easier and structural but I still like to stick with all good Java just using the same nice things that were defined in Project Coin and then Oracle took them off.

Stas,

You are making up your mind just after a glance. Just give sometime to understand the philosophy behind the language, try to build few things with it and then you would be in a better position to judge a language.

I did my research comparing Java and Scala a while ago and I even wrote some performance tests comparing Java and Scala. Java wins because it support primitive arrays when in Scala every primitive type is an object.

Mohamed Sanaulla wrote:

Stas Sokolov wrote:Is there any Java framework / JVM extension that already in one way or another mimics this syntax ?

You can have a look at the JVM based language called Scala.

It looks not so good. Syntax is unreadable. Somebody who decided to use a class body to define lines of constructor between different methods was just insane. This one Kotlin is a little bit easier and structural but I still like to stick with all good Java just using the same nice things that were defined in Project Coin and then Oracle took them off.

Is there any Java framework / JVM extension that already in one way or another mimics this syntax ?

First let make clear.
There are two concepts
OLD WAY: Bound hibernate session to thread. One thread - one session.
NEW WAY. Bound hibernate session to transaction. One transaction - one hibernate session.

If you chose the old way - you are on your own, not gonna advice anything but most common approach create a transaction the same place thread get connected first time to your code (Servlet, StrutsAction, SpringController, WebService Endpoint - plenty of choices but all driven by a controller framework)

If you chose a new way then you are going to use AOP. You will tell to which classes and methods transactions have to be created. Here I give you few advices

1. Start from defining interfaces. AOP only works with interfaces so if you have a class/method reference that a new transaction should start - not gonna work. Use only interface references.

2. Every DAO method should be able to start transaction by using transaction demarcation (REQUIRED/SUPPORT). You need it for unit testing. Never (Never !) in production transaction shell be started by
direct call to DAO but for running unit tests you have to keep a gate open. So ideally you will have two configurations one for prod, another one for unit testing

3. For every transaction as people above say you have to define an orchestrator. For me it is just a dummy Spring bean that has million of definitions - each invokes a program that implements the same interface.


Pointcut saying my orchestrators need a transaction
<aop:pointcut id="orchestrationOperation" expression="execution(* com.xxx.view.orchestrator.*.*(..))"/>

And I have a million of beans based on the same orchestrator class
<bean id="selectStocksOrchestrator" class="com.trade4stas.view.orchestrator.GenericDomainTransactionOrchestrator" parent="genericDomainTransactionOrchestrator"> <property name="mapper" ref="stocksMapper"/> <property name="validator" ref="selectStocksValidator"/> <property name="program" ref="selectStocksProgram"/> </bean> <bean id="pageStorageOrchestrator" class="com.trade4stas.view.orchestrator.GenericDomainTransactionOrchestrator" parent="genericDomainTransactionOrchestrator"> <property name="mapper" ref="simpleMapper"/> <property name="validator" ref="pageStorageValidator"/> <property name="program" ref="pageStorageProgram"/> </bean> <bean id="searchPageByTagOrchestrator" class="com.trade4stas.view.orchestrator.GenericDomainTransactionOrchestrator" parent="genericDomainTransactionOrchestrator"> <property name="mapper" ref="simpleMapper"/> <property name="validator" ref="searchPageByTagValidator"/> <property name="program" ref="pageStorageProgram"/> </bean>

Orchestrator here is just a class that invokes a program that might need a transaction. It validates a form, convert form parameters into domain object and passes them to program that has to handle a request. Spring AOP makes sure that transaction is created and commited/rolled back once orchestration is completed

Nam Ha wrote:Thanks guys for sharing your experience on Maven.

I prefer using Ant for my small to medium projects. I wanted to move to Maven, however I stopped at first place when reading Maven tutorials, as I did not understand what the document says. It seems that learning Maven is harder then Ant.

Will Maven replace Ant or both are still living together?

Maven is doing the same what ANT is doing but in a different way. Unlike ANT that has no dependencies on external resources, Maven depends on repository where all build files are stored. This repository stores not only your builds but also builds done by other developers. So you connect Maven to repository to let it download and upload jar files that are required as dependencies for your prokects. Ant does not have anything like this. It loads dependencies from local folders as configured.

Second difference is that ANT does not care how you structure your projects, but Maven does. You need to read a lot of manuals to learn how to comply with Maven standards. The good things other developers do the same. Once all comply it becomes easy to learn (theoretically not practically) how other projects are designed. In reality it is very far from being true.

Third difference Maven has prearranged build scripts where there are around 20 phases (clean, generate-sources, compile etc). You could not change order of these phases. You only allowed to say which tasks you can execute on every phase. So build script is always the same from perspective of how phases are going after each other. Compile always go to after generate-source etc. You free to define which tasks have to be performed for every phase. You do it by connecting plugins. Plugin is basically a task that I mentioned before that is something to bind to a phase. .

Trust me it is hard to read maven scripts and understand what and how is going to happen in which order because there are so many things that are configured not by you but by plugin developers. Every plugin is bind to a phase automatically as plugin developer decided. For example JI wrote a plugin that generate hibernate mapping for DB tables and it is bind to generate-source phase. You have no way to know about it because it is not written anywhere. Unless you know somehow, you have no clue what and how my plugin is doing. I mean in case if you just a developer who has to make sense on somebody's else maven script.

In practice in my opinion Maven is over-engineered product that can be used but requires huge initial investment of time to go trough the manuals. Hopefully it will be replaced soon but something else, but unlikely it takes less than 5 years considering a current hype around this technolgy.

Peter Johnson wrote:

You cannot see the build flow in Maven.

But Maven is scary when you first encounter it. My recommendation is to read the two Maven docs available online:
http://monkproject.org/MONK.wiki/attachments/17620/1332
http://www.sonatype.com/books/mvnref-book/reference/
And when you are done, write a plugin. When I wrote my first plugin, a lot of Maven's idiosyncrasies suddenly made sense and the world was a beautiful place.

Almost finished reading the first book (only last chapter left). I migrated two of my projects to maven and created one pretty useful maven plugin of my own. It was easy because I had already got an experience with creating custom ANT tasks. So far, so good. Thanks a lot for the book links. It really helped me big time. I am still very confused about doing things that are not in the book. For example finding reference information of properties that are available for Maven plugin is a struggle. My plugin generates sources and some resources. It works - code compiles, jar file generated , but generated files are not removed once jar artifact is created. Big question why. Nobody really needs them. So it is is big mystery how to let Maven know to remove generated code after compilation is over.

And the most scary part that stays in front of me is web.application deployment. My next step is to migrate one complex Web. application (Struts,Spring,Hibernate, AJAX libraries) to maven and see how Cargo/Jetty deployment procedure can handle hot updates. Something tells me that it is not going to be too easy to make it works.

Another right thing for me to do was to migrate to IntelliJ 10.5. Working with Maven projects in Eclipse was a torture. IntelliJ 9.5 seems to be unable deal with Maven at all. But IntelliJ 10.5 has a very very good support for Maven projects. I was impressed how easy it become to deal with Maven projects in IntelliJ 10.5. Sure it is not free IDE as Eclipse and community edition sucks but commercial version is very nice.

Peter Johnson wrote:

You cannot see the build flow in Maven.

Actually, if you are using Maven 3.0.x, then if you run with the -X option, one of the things printed out is the build plan - look for "PROJECT BUILD PLAN" in the output. Of course, it gets lost in all the other stuff output, and the build still runs. I submitted an enhancement request to provide an abbreviated build plan report (along with some code we use in my shop to generate that report) to the Maven team.

Personally, I like the integration of m2eclipse with Eclipse, and it gets better with each release. But then I NEVER build within Eclipse - I always use the command line. (Official builds are done via Jenkins which doesn't build via Eclipse, so why should I?) Search this forum and you will find countless posts where Eclipse (or Netbeans) was being "helpful" and thus screwed up an Ant or Maven build.

But Maven is scary when you first encounter it. My recommendation is to read the two Maven docs available online:
http://monkproject.org/MONK.wiki/attachments/17620/1332
http://www.sonatype.com/books/mvnref-book/reference/
And when you are done, write a plugin. When I wrote my first plugin, a lot of Maven's idiosyncrasies suddenly made sense and the world was a beautiful place.

Maven is a great example of over-engineering. Simplicity of ANT is gone. Benefits ?
1. Downloading dependencies. Why ? Why dependencies have to be downloaded ? Dependencies are part of every project runtime, developers add/remove check them in SCM as need arises. Why every time build is made a time (a lot of time) should be wasted to download dependencies ? It should be done once when a new feature is added that requires dependencies and upgraded as problem detected.

2. Standardization of project structure ? Project structure for J2EE application has been standardized 10 years ago. Worked as charm in every IDE ... well until Maven was invented. Now structure of Maven project has nothing to do with the structure of WAR archive. Please look at Maven build script to figure out how files are going do be deployed. Now we need bunch of plugins to let our IDE deploy maven projects. And you know what ? forget about it. No more deployment trough IDE - straight deployment of applications to the server after waiting 30 minutes for maven build to complete. It is too hard to configure eclipse to understand structure of the large maven projects and perform a deployment. So no more testing on a local server trough the eclipse. You think that it is probably a joke? No, it is how 5000 people IT organization where I am currently employed ended up after having adopted Maven. Too bad but the architect is happy - he has a line in his resume.

3. Magic ? Maven does some magic! ... The only "magic" Maven does is transforms project structure from its own standard into J2EE standard. But why do we need Maven standard on top of J2EE standard ?

4. Separate folder for tests sources. Ohh it was so hard to exclude com.company.project.test folder from the build by using ANT. Just because somebody did not know how to configure WAR task for exclusion the whole ANT process had to be replaced.

There are 3 things I hate the most from new technologies: Maven, RESTful WS and Agile. I can talk and talk about how stupid these things are....

P.S. I started reading the book about Maven that you guys recommended. Thank you for this. The fact that book exists it is already funny. You have to learn 290 pages of text to figure out how other people manage do things that can be explained in 3 lines of text
generate code based on metadata if have any
compile the code
create war file

290 pages of text. People just have a lot of time ...

As much as I look at Maven the more it stinks to me
1. All definitions are extremely bulky. To bulky to be able to understand a flow of events. This is not the worst problem

2. Worst problem is that there is no clear flow of events. Declarations are convoluted. One type of declaration overwritten by another type (pluginManagement overwrites plugin). There is no way to determine in 5-10 minutes an entire flow of steps that will be performed for the project build. Again see item 1

3. Eclipse plugin sucks. Even worse, newer versions suck more than old ones. Idiots in charge of development and there is no competition - one plugin m2e. Take it or leave it. If you don't like idiotic "features" like
maven-dependency-plugin (goals "copy-dependencies", "unpack") is not supported by m2e.
then you better kill yourself. Why plugin developers even dare to decide which maven plugins they are supporting or not. There is nothing like this for ANT builds.

4. Too much stupid XML. I hate programming using XML. XML is not for programming. Less XML = Easy to read. Maven is all about creating monstrous XML files that is hard to read and hard to understand.

This technology will be dead in trash in 2-3 years. I remember as idiots were praising EJB. It took industry 5 years to realize how crappy EJB was until than idiots were claiming it the way to go. Maven is an EJB number 2. Than will be Agile.

P.S. I would not complain but I have to use this crap for my new project. Sitting and crying.

Nikhil Nagrani wrote:Hi Guys,

I have to write a script to fetch data from PVCS repository and that too from a web-client.

What i did i first installed a desktop client and tried to fetch data from it and i was succesfull in doing that.

Also for that i had to set the path in environment variable: C:\Program Files\Serena\vm\win32\bin

Here goes the script:-

<project name="test" default="getLatestCodeFromSerena" basedir="."> <target name="getLatestCodeFromSerena"> <pvcs repository="D:\Documents and Settings\All Users\Application Data\Serena\VM\newdb" pvcsproject="/HelloApp"/> </target> </project>

But for webclient what changes i need to make for the same?(i can provide the userid and password by setting properties).

But how will i set the path(in environ variable) in case of web-client?

Please help me in resolving the same.Thanks.

What I was doing:
- wrote DOS .bat file to check-out files using SERENA command line utility
- call .bat file from ANT task