Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10955 > unrolled thread

Volunteer for Java Development

Back to article view | Back to comp.lang.java.programmer

Contents

  Volunteer for Java Development Sarkar <virtexamit@gmail.com> - 2011-12-22 09:25 -0800
    Re: Volunteer for Java Development Roedy Green <see_website@mindprod.com.invalid> - 2011-12-22 14:40 -0800
      Re: Volunteer for Java Development Lew <lewbloch@gmail.com> - 2011-12-22 21:59 -0800
        Re: Volunteer for Java Development Sarkar <virtexamit@gmail.com> - 2011-12-23 03:46 -0800
          Re: Volunteer for Java Development Lew <lewbloch@gmail.com> - 2011-12-23 09:15 -0800
            Re: Volunteer for Java Development "Qu0ll" <Qu0llSixFour@gmail.com> - 2011-12-24 10:47 +1100
              Re: Volunteer for Java Development Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-24 12:33 -0400
              Re: Volunteer for Java Development Lew <lewbloch@gmail.com> - 2011-12-24 10:06 -0800
                Re: Volunteer for Java Development Tom Anderson <twic@urchin.earth.li> - 2011-12-27 03:29 +0000
                  Re: Volunteer for Java Development Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-27 13:28 -0400
                Re: Volunteer for Java Development Arne Vajhøj <arne@vajhoej.dk> - 2011-12-27 18:13 -0500
                  Re: Volunteer for Java Development Lew <lewbloch@gmail.com> - 2011-12-28 01:07 -0800
                    Re: Volunteer for Java Development Sarkar <virtexamit@gmail.com> - 2012-01-01 22:37 -0800
              Re: Volunteer for Java Development Arne Vajhøj <arne@vajhoej.dk> - 2011-12-27 18:09 -0500
            Re: Volunteer for Java Development Roedy Green <see_website@mindprod.com.invalid> - 2011-12-23 20:54 -0800
              Re: Volunteer for Java Development Steve Sobol <sjsobol@JustThe.net> - 2011-12-24 00:18 -0800
              Re: Volunteer for Java Development Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-24 11:09 -0400
                Re: Volunteer for Java Development Sarkar <virtexamit@gmail.com> - 2011-12-24 07:26 -0800
                Re: Volunteer for Java Development Tom Anderson <twic@urchin.earth.li> - 2011-12-27 00:53 +0000
                  Re: Volunteer for Java Development Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-26 22:23 -0400
                  Re: Volunteer for Java Development Arne Vajhøj <arne@vajhoej.dk> - 2011-12-27 18:24 -0500
                    Re: Volunteer for Java Development Steve Sobol <sjsobol@JustThe.net> - 2011-12-27 16:13 -0800
              Re: Volunteer for Java Development Lew <lewbloch@gmail.com> - 2011-12-24 10:10 -0800
                Re: Volunteer for Java Development Sarkar <virtexamit@gmail.com> - 2011-12-25 06:45 -0800
              Re: Volunteer for Java Development Arne Vajhøj <arne@vajhoej.dk> - 2011-12-27 18:16 -0500

Page 1 of 2  [1] 2  Next page →

#10955 — Volunteer for Java Development

Hi,

I'm looking for a project to volunteer some time on doing some Java
development. If you know of something, please let me know.

Interested to work on Struts, Spring, Hibernate framework...

regards, Amit J.

[toc] | [next] | [standalone]

#10961

On Thu, 22 Dec 2011 09:25:12 -0800 (PST), Sarkar
<virtexamit@gmail.com> wrote, quoted or indirectly quoted someone who
said :

>Interested to work on Struts, Spring, Hibernate framework..

see http://mindprod.com/jgloss/sourceforge.html

fill in "Struts Spring Hibernate volunteer" in the search box.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
If you can't remember the name of some method, 
consider changing it to something you can remember.
 

[toc] | [prev] | [next] | [standalone]

#10965

Roedy Green wrote:
> Sarkar wrote, quoted or indirectly quoted someone who said :
>> I'm looking for a project to volunteer some time on doing some Java 
>> development. If you know of something, please let me know. 
>> 
>> Interested to work on Struts, Spring, Hibernate framework..
> 
> see http://mindprod.com/jgloss/sourceforge.html
> 
> fill in "Struts Spring Hibernate volunteer" in the search box.

In addition to that, just snooping around the web sites of Apache projects and other such exposes you to a whole lot of good code (and some to not-so-good code).  There are a gazillion open-source projects out there.  You have to decide for yourself the worthiness of each.  The best have ample documentation, both operational and Javadocs, wikis, good packaging and other signs of professionalism.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10970

Hi Roedy and Lew,

Thanks for reply...

Its not like I just want to work on struts/spring/hibernate community.
Re-correcting my sentence, I have shown interest to any _open-source_
project which is build on top of struts, spring and hibernate
framework.

If you know any of them please suggest...

regards, Amit J.

[toc] | [prev] | [next] | [standalone]

#10975

Sarkar wrote:
> Its not like I just want to work on struts/spring/hibernate community.
> Re-correcting my sentence, I have shown interest to any _open-source_
> project which is build on top of struts, spring and hibernate
> framework.
> 
> If you know any of them please suggest...

http://lmgtfy.com/?q=Open-source+project+with+struts+spring+hibernate

Why those particular frameworks?  There are others, and better, so why do you focus on those?

Hibernate is not the only JPA player in town, and if you use old-style (pre-
JPA) Hibernate you won't have as good an experience.  Use OpenJPA or 
EclipseLink.  

Struts is obsolete.  Use JSF.

Spring sucks.

Why not use good stuff instead?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10980

"Lew"  wrote in message 
news:31036852.221.1324660513125.JavaMail.geo-discussion-forums@prfi34...

> Spring sucks.
>
> Why not use good stuff instead?

Care to elaborate on that postulation?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me] 

[toc] | [prev] | [next] | [standalone]

#10987

On 11-12-23 07:47 PM, Qu0ll wrote:
> "Lew"  wrote in message
> news:31036852.221.1324660513125.JavaMail.geo-discussion-forums@prfi34...
> 
>> Spring sucks.
>>
>> Why not use good stuff instead?
> 
> Care to elaborate on that postulation?

I'll phrase this differently: Spring is now unnecessary.

It was never _necessary_ - God knows I did enough J2EE 1.2 and 1.3
projects without it. I'm still doing some J2EE 1.4 work but fortunately
those app servers are actually hybrids with EJB 3 support; but all that
is without Spring also.

I have done Spring projects, and I'll be the first one to concede that
back in the day a Spring app with selected good bits of J2EE was (1) a
good way to go, and (2) maybe _the_ way to go. This heyday of Spring
really corresponds to Spring 1.x (e.g 1.2.6 that won justified awards
came out in 2004).

But here's the thing, IMO. With Java EE 5 (2006), Spring (2.0 in Oct
2006, 2.5 in Nov 2007) already became substantially less "necessary",
and less useful. Now, if you were already committed to Spring I would
not have recommended a switch over to Java EE 5, necessarily. But new
adopters of anything would usually have been as happy with Java EE 5 as
with Spring.

And now with Java EE 6 (a year ago) and the best Java EE 6 app servers,
Spring (now up to 3.x) is completely unnecessary.

To be fair Spring people would probably say that Java EE 6 is
unnecessary - except for the component bits that they've liked to use
all along.

This has now become a comparison of two application frameworks that
solve the same problems roughly equally well. By "roughly" I do mean
"roughly" - I personally believe that a full-blown Spring app is
considerably more work to set up than a Java EE 6 application (which may
be part of the reason for Lew's comment). But certainly both can
competently solve the same problems.

The only valid comparison is that done by an individual. I have a
minimal application that I keep in my head that I use to proof Java EE
app servers: when I do the eval I create the app from scratch.
Configuring the app server from scratch is also part of it. Elements of
this proof app are:

1. Reasonably complex front-end, maybe 10-15 Facelets XHTML pages, a
good mix of JSF managed beans in different scopes;

2. A number of stateless and stateful session beans, maybe half a dozen
total;

3. JPA (EclipseLink) and perhaps half a dozen Oracle XE or PostgreSQL
tables;

4. log4j logging;

5. JMX;

6. JMS with one or two MDBs;

7. scheduling (e.g. Quartz or EJB 3.1 timers);

8. web services.

What I would consider to be a good comparison would be to create
essentially the same app with Spring. Since I haven't done this
experiment for a while I think I will go ahead and do it for giggles.
Off the top of my head I'd use Spring Framework 3.x, JPA 2 with
Hibernate (to introduce some extra difficulty, but also because most
people use it), Jetty or Tomcat as the web server (could go Spring MVC
also), probably Atomikos for transaction support (so it'll support JMS
and JPA provider transactions), maybe Wicket for the presentation but
maybe Freemarker with Spring MVC. Other bits like log4j and JMX (the
Spring way) being substantially the same.

I've used Spring Security (which used to be Acegi) before, and IMHO
compared to Java EE security or something like Apache Shiro the Spring
stuff is bloatware, but I'll use it because it's Spring. The Spring-WS
will make use of Spring Security. OTOH Apache Shiro does have good
Spring integration so I might look at that too.

I haven't done Spring this extensively in a few years, although I've
dabbled to keep up, so it'll take longer, and it won't be polished. But
I think I'll end up with something at the end of it that I can look at
and fairly compare to a comparable Java EE 6 job. Part of my paid job is
technical evals so I think I can be reasonably dispassionate about it.

One thing that pops out, and it's one reason I described my thinking, is
that with Java EE - let's assume you've selected a decent Java EE6 app
server - you *have* the stack. With Spring you basically build it, from
a wide variety of available pieces. Ask the question: for someone
relatively new to either technology stack, what's the safer bet?

I'll add one thing - if Spring was *ever* "lightweight", that was over
half a decade ago. But the Spring team still pushes that absurd message:
it is one reason I do have a bias against Spring. It's misleading and
it's wrong. And let's keep in mind, SpringSource is a substantial
company, owned by VMWare for over 2 years, which in turn was acquired by
EMC back in 2004. If there ever was any motivation to keep Spring and
its family clean and small and elegant (and I'd argue that back in the
1.x days it was close), that's down the toilet now: everything about
bloatware that Spring boosters ascribe to Java EE 6 offerings is also
inherent in Spring 3.x.

AHS

[toc] | [prev] | [next] | [standalone]

#10988

On Friday, December 23, 2011 3:47:40 PM UTC-8, Qu0ll wrote:
> "Lew"  wrote in message 
> news:31036852.221.1324660513125.JavaMail.geo-discussion-forums@prfi34...
> 
> > Spring sucks.
> >
> > Why not use good stuff instead?
> 
> Care to elaborate on that postulation?

Conclusion, not postulation.

I have used Spring on mnay projects.  It was always a tangled mess of obscure 
references to extrinsic resources to obfuscate logic.  This may not be Spring's 
fault, but it's a consistent result.

Java EE annotations do everything Spring hopes to, only better, more simply, 
with a more flowing mental model, in accordance with the standard.

Slam-dunk, BOOYAH!

Why add yet another framework that provides no additional benefit?  Burden of proof - you.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#11005

On Sat, 24 Dec 2011, Lew wrote:

> On Friday, December 23, 2011 3:47:40 PM UTC-8, Qu0ll wrote:
>> "Lew"  wrote in message
>> news:31036852.221.1324660513125.JavaMail.geo-discussion-forums@prfi34...
>>
>>> Spring sucks.
>>>
>>> Why not use good stuff instead?
>>
>> Care to elaborate on that postulation?
>
> Conclusion, not postulation.
>
> I have used Spring on mnay projects.  It was always a tangled mess of obscure
> references to extrinsic resources to obfuscate logic.  This may not be Spring's
> fault, but it's a consistent result.
>
> Java EE annotations do everything Spring hopes to, only better, more simply,
> with a more flowing mental model, in accordance with the standard.

That is not *quite* true.

CDI replaces some of the fundamental bits of Spring: the dependency 
injection, and AOP. Done and dusted.

You could argue that JSF replaces Spring MVC. I don't think it does, 
because Spring MVC is an action-style framework, and JSF is a 
component-style framework. Rather different beasts. There is no 
EE-standard action-style framework, so there is no genuine EE replacement 
for Spring MVC. There are other action-style frameworks that are smaller 
than spring MVC and more aligned with EE (Stripes with the injection 
enhancer, perhaps), so you could argue that modern EE lets them make 
Spring MVC obsolete.

But there are many other bits of Spring.

Security? Does JAAS and friends cover everything Acegi does? Don't think 
so.

Web Flow? It's a sort of wizard-based web framework. Does JSF address 
that? Don't know. Does it address it within an action-based framework? No.

JDBC templates? They're simple, but they apparently really simplify JDBC 
programming (for people who need to do raw JDBC).

Spring Integration? Web Services? Batch? I have no idea what they do. I 
would be very surprised if *everything* they did was now covered by EE.

So, whilst i agree that EE now does everything the Spring *core* hopes to, 
better and more simply, i think there are other bits of Spring which may 
still be useful. If the Spring guys have a clue, they will adapt them to 
work with EE's DI and AOP mechanisms. Spring has always been a layer on 
top of EE; as EE gains the ability to do certain things well, Spring can 
simply evolve to do other things.

Which is not to say that Spring is the only way of doing these things, or 
is, or will remain, the best way!

tom

-- 
Miscellaneous Terrorists: Ducks | Bird Flu | Avian flu | Jimbo Wales |
Backstreet Boys | The Al Queda Network | Tesco -- Uncyclopedia

[toc] | [prev] | [next] | [standalone]

#11010

On 11-12-26 11:29 PM, Tom Anderson wrote:
> On Sat, 24 Dec 2011, Lew wrote:
> 
>> On Friday, December 23, 2011 3:47:40 PM UTC-8, Qu0ll wrote:
>>> "Lew"  wrote in message
>>> news:31036852.221.1324660513125.JavaMail.geo-discussion-forums@prfi34...
>>>
>>>> Spring sucks.
>>>>
>>>> Why not use good stuff instead?
>>>
>>> Care to elaborate on that postulation?
>>
>> Conclusion, not postulation.
>>
>> I have used Spring on mnay projects.  It was always a tangled mess of
>> obscure
>> references to extrinsic resources to obfuscate logic.  This may not be
>> Spring's
>> fault, but it's a consistent result.
>>
>> Java EE annotations do everything Spring hopes to, only better, more
>> simply,
>> with a more flowing mental model, in accordance with the standard.
> 
> That is not *quite* true.
> 
> CDI replaces some of the fundamental bits of Spring: the dependency
> injection, and AOP. Done and dusted.
> 
> You could argue that JSF replaces Spring MVC. I don't think it does,
> because Spring MVC is an action-style framework, and JSF is a
> component-style framework. Rather different beasts. There is no
> EE-standard action-style framework, so there is no genuine EE
> replacement for Spring MVC. There are other action-style frameworks that
> are smaller than spring MVC and more aligned with EE (Stripes with the
> injection enhancer, perhaps), so you could argue that modern EE lets
> them make Spring MVC obsolete.

I just don't see the web framework as being something that is part of
Java EE, I really don't. Servlet API yes, web framework no. I'm content
that there's a wide choice list out there, and I'd prefer none of them
to be considered as "standard".

> But there are many other bits of Spring.
> 
> Security? Does JAAS and friends cover everything Acegi does? Don't think
> so.

It's sort of apples and oranges, that. "JAAS and friends" are a
foundation, and there isn't much at all that you can't do with them. But
much of the "final mile" stuff needs to be coded up. That's one reason
security frameworks like Spring Security (Acegi really, it was Acegi's
original motivation) and Apache Shiro have appeared.

This of course is something that we've seen before with "standard" Java
APIs, that they supply the API but a weak or non-existent
implementation. Logging has this problem, XML parsing had this problem,
JAAS is sort of in the same ballpark insofar as to customize and shape
the actual solution a fair bit of coding may be needed.

Another motivation behind Acegi and Shiro was ease of use - a lot of
developers struggle with JAAS. They could do what they need to do with
JAAS, they just struggle. My feeling, having used both, is that Shiro is
better than Acegi at ease of use.

I'll bet you though that 90 percent of developers using Spring Security
are solving application security problems that are actually readily done
with JAAS.

> Web Flow? It's a sort of wizard-based web framework. Does JSF address
> that? Don't know. Does it address it within an action-based framework? No.

I'm not familiar with Web Flow, but part of what it addresses - page
navigation and navigational/conversational state - is very much also a
JSF thing.

On the action-based thing, I think it's worth pointing out that JSF
components aren't involved in the 'C' in MVC. Sure, the components are
sources of action events, but the actual controller logic isn't all that
dissimilar to Struts: you've got an ActionServlet or a FacesServlet
that's (leaving aside filters) the first point of processing for an
incoming request, and further handling is handed off to "actions". We
actually call them actions in Struts, and you have a method in an action
class that is executed; in JSF it's precisely the same as you have a
method in a class that gets executed.

A lot of the things that happen in JSF phases (once the FacesServlet has
started to process the request) are peculiar to the component
processing, and are orthogonal to the "action" type processing that
happens in the JSF INVOKE_APPLICATION phase. Also, navigation concerns
*are* addressed during this "action" phase of JSF.

> JDBC templates? They're simple, but they apparently really simplify JDBC
> programming (for people who need to do raw JDBC).

No doubt. I've been in situations where I'd prefer iBatis/MyBatis to
JPA. JPA is nice stuff as far as I am concerned but it's not ideal for
100% of all circumstances.

> Spring Integration? Web Services? Batch? I have no idea what they do. I
> would be very surprised if *everything* they did was now covered by EE.

I'd hope the web services stuff *is* covered by Java EE. I can't think
of anything I've needed to do with web services that isn't covered by
Java EE.

I'm not familiar with Spring Integration or Batch, but a quick skim at
docs tells me that Spring Integration is about external systems, and it
sure looks like aspects of ESBs are being incorporated also. Java EE
does a lot of that, with things like resource adapters and JMS and what
have you. For the other aspects I'd expect to use (and do frequently
use) Java EE to SOA-enable an application and then use existing ESBs to
handle the enterprise messaging and routing and transformations and so
forth. Can't expect Java EE to do everything - big bits of SOA are not
covered by Java EE.

> So, whilst i agree that EE now does everything the Spring *core* hopes
> to, better and more simply, i think there are other bits of Spring which
> may still be useful. If the Spring guys have a clue, they will adapt
> them to work with EE's DI and AOP mechanisms. Spring has always been a
> layer on top of EE; as EE gains the ability to do certain things well,
> Spring can simply evolve to do other things.

The original fundamental motivation for Spring, and a good one it was,
was that EJBs sucked. How do you look them up with JNDI, how do you
configure them, how much boilerplate do you have to write for each
component, an intrusive and frequently unnecessary distributed object
model, etc etc - old-style EJBs sucked.

Spring basically was originally about being able to give POJOs
J2EE-style services, like transactions, in a much less complex fashion.
And it more or less succeeded in being a lot better than J2EE 1.2 and
1.3, probably even 1.4. It clearly made sense then to use those parts of
J2EE that worked, like servlets, and so all that was a happy combination.

I digress in this fashion to indicate that I don't think Spring was a
layer on top of EE, I think it is a distinct enterprise application
framework that right from the gitgo has used solid parts of EE. But now
that Java EE does pretty much all that you really need, the guts of
Spring are not necessary.

So now it's pure competition: Spring versus Java EE.

> Which is not to say that Spring is the only way of doing these things,
> or is, or will remain, the best way!
> 
> tom

Just my opinion, but the Spring team started losing its way back with
2.x. And with 3.x they are completely adrift. J2EE/Java EE has been
moving in the right direction from a rocky start; Spring started out
relatively simple and clean, and now that entire ecosystem is a rambling
mess.

AHS

[toc] | [prev] | [next] | [standalone]

#11014

On 12/24/2011 1:06 PM, Lew wrote:
> On Friday, December 23, 2011 3:47:40 PM UTC-8, Qu0ll wrote:
>> "Lew"  wrote in message
>> news:31036852.221.1324660513125.JavaMail.geo-discussion-forums@prfi34...
>>
>>> Spring sucks.
>>>
>>> Why not use good stuff instead?
>>
>> Care to elaborate on that postulation?
>
> Conclusion, not postulation.

Th difference between postulation and conclusion without the arguments
seem rather small to me.

> I have used Spring on mnay projects.  It was always a tangled mess of obscure
> references to extrinsic resources to obfuscate logic.  This may not be Spring's
> fault, but it's a consistent result.

I have seen that too.
>
> Java EE annotations do everything Spring hopes to, only better, more simply,
> with a more flowing mental model, in accordance with the standard.
>
> Slam-dunk, BOOYAH!
>
> Why add yet another framework that provides no additional benefit?  Burden of proof - you.

That argument is a little thin.

There are things in Spring that Java EE annotations does not.

And besides that there are also something weird called Java SE apps
that does not benefit much from stuff provided by Java EE containers.

Arne

[toc] | [prev] | [next] | [standalone]

#11021

On Tuesday, December 27, 2011 3:13:03 PM UTC-8, Arne Vajhøj wrote:
> On 12/24/2011 1:06 PM, Lew wrote:
> > On Friday, December 23, 2011 3:47:40 PM UTC-8, Qu0ll wrote:
> >> "Lew"  wrote in message
> >> news:31036852.221.1324660513125.JavaMail.geo-discussion-forums@prfi34...
> >>
> >>> Spring sucks.
> >>>
> >>> Why not use good stuff instead?
> >>
> >> Care to elaborate on that postulation?
> >
> > Conclusion, not postulation.
> 
> Th difference between postulation and conclusion without the arguments
> seem rather small to me.

And yet you then cite the arguments I provided, so how is that "without the arguemnts", hm?

My statement came *with* the arguemnts, some of which you even agreed with, so what the frack are you on?

... on about?

> > I have used Spring on mnay projects.  It was always a tangled mess of obscure
> > references to extrinsic resources to obfuscate logic.  This may not be Spring's
> > fault, but it's a consistent result.
> 
> I have seen that too.
> >
> > Java EE annotations do everything Spring hopes to, only better, more simply,
> > with a more flowing mental model, in accordance with the standard.
> >
> > Slam-dunk, BOOYAH!
> >
> > Why add yet another framework that provides no additional benefit?  Burden of proof - you.
> 
> That argument is a little thin.

The lack of argument from the other side was what was thin.  The burden of proof is on the proponents of Spring, and you haven't lightened that burden an iota.  "That argument is a little thin" without the arguments to show why seems rather small to me.

> There are things in Spring that Java EE annotations does not.

What, exactly, and is it worth it?  C'mon man, don't be so vague.

> And besides that there are also something weird called Java SE apps
> that does not benefit much from stuff provided by Java EE containers.

Not so much, really.  The EJB annotations obviously don't help SE much, and dependency injection and JPA are available for SE, which I find sufficient if it keeps out of the Spring morass.

WEhile it's not literally true that Spring brings nothing new to the table, it is true enough not to justify the cost of using it to me.

Perhaps instead of vaguely waving at what you think is insufficient about non-Spring alternatives, could you be specific about what is missing for Java SE that Spring provides and gives enough benefit to justify Spring over the alternatives?  It's pretty easy to gainsay whatever anyone else says, somewhat more challenging to contribute affirmatively.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#11057

Hi All,

Thanks for wonderful discussion and throwing light on different
frameworks...

Can anyone please suggest me name of project where I can do some
voluntary work...

regards, Amit J.

[toc] | [prev] | [next] | [standalone]

#11013

On 12/23/2011 6:47 PM, Qu0ll wrote:
> "Lew" wrote in message
> news:31036852.221.1324660513125.JavaMail.geo-discussion-forums@prfi34...
>> Spring sucks.
>>
>> Why not use good stuff instead?
>
> Care to elaborate on that postulation?

Spring today is a bundle of many different pieces of software.

Spring started as a simple DI/IoC framework. But then they started
adding stuff. They must somehow want to make it possible writing
a full app only using Java SE and Spring.

The added stuff are of varying quality.

It has certainly become very huge with the consequence of being
difficult to keep overview.

Certain things has been replaced by standard features in
Java EE 5 and 6.

Some Spring users go completely overboard in using Spring
resulting in very cluttered code.

I don't think Spring sucks.

But I do think that some of Spring sucks.

And I think that a large portion of actual Spring usage
sucks per the above reasons.

Arne

[toc] | [prev] | [next] | [standalone]

#10981

On Fri, 23 Dec 2011 09:15:13 -0800 (PST), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>Struts is obsolete.  Use JSF.
I was told JSF has hugely more overhead.  
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
If you can't remember the name of some method, 
consider changing it to something you can remember.
 

[toc] | [prev] | [next] | [standalone]

#10983

In article <1nmaf7h9eu97hhbbibrs6u2ti1mvu5e5ei@4ax.com>, Roedy Green 
says...
> 
> On Fri, 23 Dec 2011 09:15:13 -0800 (PST), Lew <lewbloch@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
> 
> >Struts is obsolete.  Use JSF.
> I was told JSF has hugely more overhead.  

In terms of... what?

I find JSF pretty elegant, myself. You need two jars in your classpath; 
one additional one if you want to use EL, and one more if you want to 
use Facelets (which I often do). So, for the type of work I do with JSF, 
four jars, total.


-- 
Steve Sobol - Programming/WebDev/IT Support
sjsobol@JustThe.net

[toc] | [prev] | [next] | [standalone]

#10985

On 11-12-24 12:54 AM, Roedy Green wrote:
> On Fri, 23 Dec 2011 09:15:13 -0800 (PST), Lew <lewbloch@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
> 
>> Struts is obsolete.  Use JSF.
> I was told JSF has hugely more overhead.  

What kind of overhead?

1) Size or number of JARs? The days of few and small JARs were over with
many years ago. Besides, assuming reasonable overall size, what does the
exact number of JARs matter anyway? These days a fair few application
servers bundle a suitable JSF implementation; failing that you can
install one server-side; failing that the worst case is that each one of
your web apps that needs JSF grew by a few percent because you had to
include JSF libraries in the WAR. Big deal.

Rather more of an overhead concern would be trying to figure out for any
web app framework *which* JARs to include. This question doesn't get
much simpler than it is for JSF.

2) Application configuration? It doesn't get much easier actually. A
decent IDE will fire out a useful minimal faces-config.xml that you
barely need to touch with JSF 2.0. There's very little configuration
that you need to do prior to starting actual coding of JSF stuff for
your application.

I can myself go a long ways with a nearly empty faces-config.xml.

3) Page complexity?

Let's say that you're using Facelets XHTML pages, which are now included
in JSF. That's absolutely not more complicated than JSPX. If you were
comparing to the use of Spring MVC for your web app framework, with
Velocity as your view technology, JSF Facelets would definitely not be
more complicated. If you were comparing to the use of Struts 2 with,
say, Freemarker as the view technology, JSF Facelets are definitely not
more complicated.

There's no free lunch with any of these view technologies. Provided that
they cleanly separate concerns, which pretty much all of them can do,
the amount of work that a body has to do to define elements in a page,
and their bindings, is comparable.

4) API complexity?

All of the web framework APIs are large, JSF is no exception. But how
much do you need to get a lot done? It seems to me, that once you've
made a decision about component scope, or about a navigation case - all
of which are necessary in *every* web app, including ones that don't use
a framework at all - the translation of those decisions into working
code in JSF is about as easy as it gets. A handful of simple
annotations, and use of JSF 2 implicit and conditional navigation [1],
and you're off to the races.

It seems to me that the same people who make statements about overhead
are the same ones that bandy about terms like "lightweight". In either
case they usually don't even know what they mean.

AHS

1. I fall into the camp of JSF developers that has absolutely no qualms
about hard-coding an implicit navigation rule into a Java action method
in a JSF managed bean. I've seen some commentators state that this
"ties" business objects into the navigation model. They're wrong.

[toc] | [prev] | [next] | [standalone]

#10986

Hi All,

Thanks for replies...

My initial question wasa : looking for any open source java project to
do some voluntary developement work (prefered project which are build
on top of ayny of framwork like struts/hibernate/spring reason feel
more comfortable on them because having small experience on them).

regards, Amit J.

[toc] | [prev] | [next] | [standalone]

#11003

On Sat, 24 Dec 2011, Arved Sandstrom wrote:

> On 11-12-24 12:54 AM, Roedy Green wrote:
>> On Fri, 23 Dec 2011 09:15:13 -0800 (PST), Lew <lewbloch@gmail.com>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> Struts is obsolete.  Use JSF.
>>
>> I was told JSF has hugely more overhead.
>
> What kind of overhead?
>
> 4) API complexity?
>
> All of the web framework APIs are large

No. Stripes is pretty small.

I've never used JSF, so i have no first-hand evidence. By way of 
second-hand evidence, i see a lot of questions on forums from people who 
are struggling with some aspect of JSF. I very rarely see questions like 
that for action-style frameworks like Struts or Stripes, despite the fact 
that such frameworks are very widely used.

Also, correct me if i'm wrong, but doesn't JSF (like other component-style 
frameworks) make it harder to precisely control the HTML than action-style 
frameworks? The last project i did used an action-style framework. Our web 
designers sat down and cranked out finely-tuned HTML for the site, taking 
care to make it lean, semantic, portable across browsers, SEO-friendly, 
etc. We programmers could pick up their static mockups and made minimal 
changes to make the appropriate bits dynamic - replacing a hardcoded value 
with a ${}, an <input> with a <webframework:input>, and so on. Can you do 
that with JSF?

tom

-- 
Miscellaneous Terrorists: Ducks | Bird Flu | Avian flu | Jimbo Wales |
Backstreet Boys | The Al Queda Network | Tesco -- Uncyclopedia

[toc] | [prev] | [next] | [standalone]

#11004

On 11-12-26 08:53 PM, Tom Anderson wrote:
> On Sat, 24 Dec 2011, Arved Sandstrom wrote:
> 
>> On 11-12-24 12:54 AM, Roedy Green wrote:
>>> On Fri, 23 Dec 2011 09:15:13 -0800 (PST), Lew <lewbloch@gmail.com>
>>> wrote, quoted or indirectly quoted someone who said :
>>>
>>>> Struts is obsolete.  Use JSF.
>>>
>>> I was told JSF has hugely more overhead.
>>
>> What kind of overhead?
>>
>> 4) API complexity?
>>
>> All of the web framework APIs are large
> 
> No. Stripes is pretty small.
> 
> I've never used JSF, so i have no first-hand evidence. By way of
> second-hand evidence, i see a lot of questions on forums from people who
> are struggling with some aspect of JSF. I very rarely see questions like
> that for action-style frameworks like Struts or Stripes, despite the
> fact that such frameworks are very widely used.

I've seen this also. I've encountered a number of people who were/are
top-notch users of frameworks like Struts, and when they had to do their
first JSF project they stumbled, sometimes badly.

I'm really not sure why, other than that these folks are getting
discombobulated by minutiae and don't see the forest for the trees. When
all is said and done the frameworks are mostly all MVC and people
shouldn't be getting all twisted over minor details, and basically the
differences - in the big scheme of things - are minor details.

I don't know how much weight you can put on who is struggling with what,
based on forums volume. It depends on a bunch of factors. All I know,
having used a variety of view technologies and a variety of web
frameworks, is that with the exception of JSPs (even JSPX) as a view
technology, I've found that any competent developer can readily make any
of them work to solve the front-end problem. My personal belief is that
anyone with significant experience who is still having problems with
framework X, or seriously hates view technology Y, that they're copping
an attitude rather than solving real problems.

Just my 2 cents. I have personal biases, sure - I would rather use
ASP.NET MVC than JSF (or any of the Java web frameworks), but if someone
told me that my next contract involved Struts 1 I'd go ahead and do it.
In fact I just finished a project where another team on the project
*did* use Struts 1; they weren't moaning about it. And everyone on that
team has also done extensive work with JSF and they don't moan about
that either.

Not venting at you, Tom, just venting in general. :-) I get so tired of
people who bitch about web frameworks and view technologies but can't be
bothered to learn how to do proper requirements analysis or design or
learn up on how to code properly down in the business logic and
persistence layers.

> Also, correct me if i'm wrong, but doesn't JSF (like other
> component-style frameworks) make it harder to precisely control the HTML
> than action-style frameworks? The last project i did used an
> action-style framework. Our web designers sat down and cranked out
> finely-tuned HTML for the site, taking care to make it lean, semantic,
> portable across browsers, SEO-friendly, etc. We programmers could pick
> up their static mockups and made minimal changes to make the appropriate
> bits dynamic - replacing a hardcoded value with a ${}, an <input> with a
> <webframework:input>, and so on. Can you do that with JSF?
> 
> tom
> 
I can change how a component is rendered, but in 4 odd years of using
JSF I've had the need to do that myself exactly zero times. The
available components, including a few fairly esoteric ones (not the
publicly available *Faces sets), have done the trick.

I honestly don't know why the usual JSF components need to be tailored.
They generate very simple HTML actually, and using best practices you
style with CSS. JSF people also tend to do a lot of their tuning with
carefully crafted Facelets components, themselves suitably styled. And
when all is said and done, if you absolutely need very precise control
over some UI element appearance you can "pair up" a visible standard
HTML element and a JSF component, the latter handling the JSF action via
JavaScript.

Again, I've not run across a situation where I couldn't make a page look
like I wanted. Without too much agony.

AHS

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web