Announcement Announcement Module
Collapse
No announcement yet.
The value for the useBean class attribute ... is invalid Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • The value for the useBean class attribute ... is invalid

    Howdy! I'm a Spring newbie, been reading the official reference documentations as well as learning from the web tutorials for half year but I haven't come to a success point. Now that a project from work is in the need to implement Spring under the following circumstances:
    • projects will be deployed in Apache Tomcat (version 7 to be specific), no future plan to migrate to application servers such as GlassFish;
    • views will be DOM-based (utilizing org.w3c.dom.*) in plain JSP which produce either XML or transformed XSLT (HTML), hence we don't quite need to incorporate full Spring Web MVC;
    • what we need from Spring Framework is the Spring Data JPA support due to all of the above: No application server (just servelt container) but still in the need for JPA.
    Questions arised:
    1. Can we eliminate writing @Controller class(es) totally!? Actually, we've tried to achieve this after doing a few researches; we're just not sure if we're on the rite path (see below for current configuration).
    2. Are we using/configuring everything correctly!? Have we over-configured things we actually don't need and/or have we miss-configured things, please advise!
    3. The result is either:
      Code:
      org.apache.jasper.JasperException: /index.jsp (line: 1, column: 95) The value for the useBean class attribute tw.com.nani.tsj.entity.EmployeeDAO is invalid.
      	org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)
      	org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:443)
      	org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:149)
      	org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1237)
      	org.apache.jasper.compiler.Node$UseBean.accept(Node.java:1182)
      	org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
      	org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2428)
      	org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2434)
      	org.apache.jasper.compiler.Node$Root.accept(Node.java:475)
      	org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
      	org.apache.jasper.compiler.Generator.generate(Generator.java:3503)
      	org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:250)
      	org.apache.jasper.compiler.Compiler.compile(Compiler.java:373)
      	org.apache.jasper.compiler.Compiler.compile(Compiler.java:353)
      	org.apache.jasper.compiler.Compiler.compile(Compiler.java:340)
      	org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:646)
      	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
      	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
      	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
      	javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
      or the entityManagerFactory throws NullPointerException.
    The Mavenized project is attached: Attachment

    Development setup:
    • JDK: 1.7.0_21 (1.7.0_9 on deployment server)
    • Tomcat: 7.0.40 (7.0.33 on deployment server)
    • NetBeans IDE: 7.3
    • MySQL: MariaDB 5.5.28 (I don't think this is relevant to the questions or issues but, what the heck)
    • JPA provider: We first tried EclipseLink due to its community supports on the web, but we didn't have any success so recently switched to OpenJPA 2.2.2!
    Steps w/ details:
    1. pom.xml (New Project... and Add Dependencies...):
      Note that there's a few customizations (such as version number of plugins) compared to IDE generated default values.
    2. /WEB-INF/web.xml (New Standard Deployment Descriptor...):
      As explained earlier, we want the views to be handled in plain JSPs, hence the <welcome-file>index.jsp</welcome-file>.
    3. /WEB-INF/dispatcher-servlet.xml (New Spring XML Configuration File...):
      Since we're aware that some schemas are not required by now, we've decided to check them all just to be safe and manually rule out the unused ones when deploying. Another thing to be noted is we prefer annotation-based container configuration.
    4. /META-INF/context.xml:
      We favor High Concurrency JDBC Pool as suggested from Improving the performance of the Spring-Petclinic sample application and hope the following PU can benefit from this (we were told that a few JPA providers such as EclipseLink features built-in DBCP but we prefer keeping it container-managed to avoid vendor-specific configuration, if possible).
      The account to access database was created:
      Code:
      GRANT ALL ON *.* TO 'username'@'%' IDENTIFIED BY'password';
      FLUSH PRIVILEGES;
      in case someone questions about it.
    5. Schema:
      Attachment
    6. /WEB-INF/web.xml (again):
      Added <resource-ref/> for JNDI DataSource resource.
      Up until this point, a /jdbc.jsp was created to verified the above steps are configured correctly.
    7. classpath:/META-INF/persistence.xml (New Persistence Unit...):
    8. New Entity Classes from Database...
      Attachment
      Attachment
    9. Frankly, we're lazy to write boilerplate code, so we use this great feature (New JPA Controller Classes from Entity Classes...) of the IDE to generate the DAOs for us:
      Attachment
      a few modifications required on tw.com.nani.tsj.entity.*JpaController of course:
      • Rename tw.com.nani.tsj.entity.*JpaController to tw.com.nani.tsj.entity.*DAO (Refactor > Rename).
      • Remove interface Serializable implementation.
      • Rename private field emf to entityManagerFactory, following the convention.
      • Add @Repository annotation to the DAO classes.
      • Add @PersistenceUnit annotation to private field entityManagerFactory.
      • Generate Getter and Setter methods (attached source did not have this generated but we actually did this in the real project).
    Further questions:
    1. <resource-ref/> is required when we used to acquired JNDI in plain JDBC before, do we still need it now in order to implement JPA and/or Spring w/ JPA?
    2. If the PU acquires DataSource from context resource like we did while JTA is in place, do we still have to set defaultAutoCommit="false" in /META-INF/context.xml?
    3. Is there any dependency we don't need? Suspicious candidates are:
      • derby-*.jar
      • junit-*.jar Suppose we don't need testing support.
    Attached Files
    Last edited by 高科技黑手; Aug 26th, 2013, 06:58 AM.

  • #2
    I strongly suggest you read some documentation and books again.

    It seems to me that you basically work against the framework instead of WITH the framework. If you don't want to use spring then don't, but if you do use it correct and wisely.

    views will be DOM-based (utilizing org.w3c.dom.*) in plain JSP which produce either XML or transformed XSLT (HTML), hence we don't quite need to incorporate full Spring Web MVC;
    Spring has excellent XML and XSLT support out-of-the-box so instead of writing your own use the spring provided VIew classes.

    what we need from Spring Framework is the Spring Data JPA support due to all of the above: No application server (just servelt container) but still in the need for JPA.
    Spring (Data) JPA has nothing to do with the fact if you are using a full-blown application server or not, heck it can be used without a servlet container. It makes it just a whole lot easier to create dao's adn work with JPA.

    So I strongly urge you to re-read the documentationa nd books and use spring as intended and not work around spring (as you are attempting to do).

    Comment


    • #3
      First of all, I appreciate your insights.

      Originally posted by Marten Deinum View Post
      I strongly suggest you read some documentation and books again

      It seems to me that you basically work against the framework instead of WITH the framework. If you don't want to use spring then don't, but if you do use it correct and wisely.
      I described how we manage the project as much detail as possible while trying to keep the content w/in the 10K-character limit, perhaps I just haven't put up w/ enough effort before posting for help here. But according to Part I. Overview of Spring Framework and I quote:
      Spring is modular, allowing you to use only those parts that you need, without having to bring in the rest...you can also use only the Hibernate integration code or the JDBC abstraction layer.
      (Anyone can) correct me if I'm wrong, I think everybody is free to choose the Spring module(s) he or she needs and that's the spirit of the said above.

      Originally posted by Marten Deinum View Post
      Spring has excellent XML and XSLT support out-of-the-box so instead of writing your own use the spring provided VIew classes.
      I have read these related chapters/sections as well as have tried coding them by either the correct and wise way, or by refering to samples from books and internet communities.
      Frankly, some of the official implementation techniques could not totally meet our expectations; not to mention lack of plain-English explainations (I may, upon your request, share a few links on this forum whose posters have similar thoughts), outdated samples (AbstractXsltView is deprecated, where's the official XsltView example when we need it), etc. Shall I name more!?
      We as the employees, are getting paid to do the jobs (hey, we ain't at the management level, we don't make calls...XD) and the jobs require us to go by the against (parts of) the framework approach in order to shorten or to lower the learning curve; for that I apologize!

      Originally posted by Marten Deinum View Post
      Spring (Data) JPA has nothing to do with the fact if you are using a full-blown application server or not, heck it can be used without a servlet container. It makes it just a whole lot easier to create dao's adn work with JPA.
      This was to let others who'd love to provide more helpful assistance a better understanding on the background of the questions/issues. Cut me some slack, will you!? >"<

      Originally posted by Marten Deinum View Post
      So I strongly urge you to re-read the documentationa nd books and use spring as intended and not work around spring (as you are attempting to do).
      Reading, researching, studying more, will do, that's for sure, thanx again for your words!

      Oh, BTW, w/ your strong background in Java and enthusiasm in Spring Framework, do you think you could help us to get back on the right tracks!?

      Comment


      • #4
        Oh, BTW, w/ your strong background in Java and enthusiasm in Spring Framework, do you think you could help us to get back on the right tracks!?
        I could but not in a single forum post as there are a couple of loose ends in your code and approach and as I mentioned you are working against the framework instead of with the framework.

        (Anyone can) correct me if I'm wrong, I think everybody is free to choose the Spring module(s) he or she needs and that's the spirit of the said above.
        Correct but the modules/parts you choose to use you should use well and that is something you aren't doing. Not to mention you are basically creating more work for yourselves by not working with the framework but trying to find creative ways around the framework.

        We as the employees, are getting paid to do the jobs (hey, we ain't at the management level, we don't make calls...XD) and the jobs require us to go by the against (parts of) the framework approach in order to shorten or to lower the learning curve; for that I apologize!
        So am I but I also want to do a good job and use frameworks as they are intended to be used. It might lower the learning curve but you pay a fee in finding a way to work around the framework. Next when things go haywire in production you are left with creative workarounds and cannot rely on support or anything from the guys here on the forums or maybe official support.

        But to get you on the right track, in your JSPs you cannot use the use beans tag, you have to use the beans from the ApplicationContext, so in all the JSPs you need to use the RequestContextUtils to retrieve the ApplicationContext and manually retrieve beans from it.

        However instead of a JSP I would simply write a controller which does the same thing as a JSP. It is a whole lot easier to test and to write. Not to mention the fact that you can simply use dependency injection to get all the needed beans (instead of doing the lookups yourself).

        Code:
        @Controller
        public class EmployeesController  {
        
            @Autowired
            private EmployeeDAO employeeDAO;
        
            public void listEmployees(HttpServletResponse response) throws ParserConfigurationException, TransformerException, IOException {
                Document document = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
                Element documentElement = document.createElement("employees");
        
                for (Employee employee : employeeDAO.findEmployeeEntities()) {
                    Element element = document.createElement("department");
                    element.setAttribute("id", employee.getId().toString());
                    element.setAttribute("name", employee.getName());
                    element.setAttribute("department", employee.getDepartment().getName());
        
                    documentElement.appendChild(element);
                }
        
                document.appendChild(documentElement);
        
                TransformerFactory.newInstance().newTransformer().transform(new DOMSource(document), new StreamResult(response.getOutputStream()));
            }
        }
        Something like this. This is easy testable with a unit test (unlike the jsp) and yields the same result without having to write a JSP (one should never use a JSP for these constructs, JSP should be as simple as possible and only be used for views IMHO).

        And I would probably use JAXB2 together with springs marshalling view to output the xml instead of writing the xml handling myself (or whichever marshaller you want to use). This saves you writing a lot of this code.

        Comment


        • #5
          You also hinted on wanting to eliminate XML, then do it. Instead of using an web.xml write a subclass of AbstractAnnotationConfigDispatcherServletInitializ er to bootstrap the DispatcherServlet and ContextLoaderListener. For the remainder of your application use java based and annotation based configuration.

          Next your JPA is basically writting in a JDBC way instead of utilizing JPA, it basically defeats the purpose of having JPA. The way the relations are managed is really a bad way, you are resetting collections with new fersh instances (basically destroying the old relations). In general this is a sign of not using or having configured your relations in your entities correctly, no cascading for instances. When storing a Department (for instance) you should only need to store the department, all the other relations should be updated by the JPA framework of your choice, not by hand.

          You don't have a service layer but only a dao layer, in general you want to have a service layer and the repository should only be burdend with loading, saving an entity.

          TransactionManagement is something you want to do declarative (using @Transactional for instance) and not manually (that way is how we did it 10 years ago). All the stuff mentioned above really makes your repositories/daos a whole lot easier to maintain and understand (but you have to start by properly managing your relations inside your entities).

          When your repositories/daos are such a thin layer you could, for instance, use Spring Data JPA and not have to write any repository implementatin any more (only the interface). As the best maintainable code is code not written, that should give a nice feel, not to mention should be a lot faster.

          Comment

          Working...
          X