Re: Sanity check. Can't inject DAO
Yup I think timo hit the spot here. When working with enough interfaces
your naming becomes Protocol for the interface and ProtocolImpl etc for
the implementations (just a side remark).
Timo Rantalaiho wrote:
On Thu, 29 May 2008, David Nedrow wrote:
public class ProtocolDAO extends JpaDaoSupport implements IProtocolDAO
...
public class ShowProtocolsPanel extends Panel {
@SpringBean(name=ProtocolDAO)
private ProtocolDAO dao;
Clearly this should be IProtocolDao, so that the component
depends on interface and not on implementation.
I'm not sure if this affects your issue though, we use both
forms all the time with Spring 2.5.
Best wishes,
Timo
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sanity check. Can't inject DAO
Hi David,
Have you tried with naming the dao to be injected explicitly? i.e.
@SpringBean (name=ProtocolDAO)
private ProtocolDAO dao;
Regards,
Mike
Could someone take a look at the following to see if they see any
issues? I'm going to ask on the Spring forums as well, but they have a
new requirement that you now must have created fifteen new threads in
order to post anything with URLs or the @ sign. Urgh.
So, using the panel below, the following is thrown...
WicketMessage: Method onLinkClicked of interface
org.apache.wicket.markup.html.link.ILinkListener targeted at component
[MarkupContainer [Component id = link, page =
com.foo.FilterRequest.pages.HomePage, path =
2:tabs:tabs:panel:tabs:tabs-container:tabs:1:link.TabbedPanel$5,
isVisible = true, isVersioned = true]] threw an exception
Root cause:
java.lang.IllegalStateException: bean of type [com.foo.ProtocolDAO]
not found
I believe I have everything in place, config-wise.
/* begin ShowProtocolsPanel.java */
public class ShowProtocolsPanel extends Panel {
@SpringBean
private ProtocolDAO dao;
public ShowProtocolsPanel(String id) {
super(id);
IModel protocolModel = new LoadableDetachableModel() {
protected Object load() {
return dao.findAll();
}
};
add(new ListView(eachItem, protocolModel) {
@Override protected void populateItem(ListItem item) {
final Protocol protocol = (Protocol)
item.getModelObject();
item.add(new Label(keyword, protocol.getKeyword()));
item.add(new Label(description,
protocol.getDescription()));
}
});
}
}
/* end ShowProtocolsPanel.java */
!-- begin web.xml --
?xml version=1.0 encoding=UTF-8?
web-app version=2.5 xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
descriptionThis application provides a web frontend to the ACL
tool./description
display-nameFilter Request Tool/display-name
!-- Additional Spring config --
context-param
descriptionLoad the application context file for bean
definitions, etc./description
param-namecontextConfigLocation/param-name
param-value/WEB-INF/applicationContext.xml/param-value
/context-param
filter
descriptionServlet 2.3 Filter that binds a JPA EntityManager
to the thread for the entire
processing of the request. Intended for the Open
EntityManager in View pattern, i.e.
to allow for lazy loading in web views despite the
original transactions already being
completed. /description
filter-namelazyLoadingFilter/filter-name
filter-classorg.springframework.orm.jpa.support.OpenEntityManagerInViewFilter/filter-class
/filter
!-- acegi filter--
filter
descriptionDelegates Filter requests to a Spring-managed
bean./description
filter-nameAcegi HTTP Request Security Filter/filter-name
filter-classorg.acegisecurity.util.FilterToBeanProxy/filter-class
init-param
descriptionDelegates Filter requests to a list of
Spring-managed beans./description
param-nametargetClass/param-name
param-valueorg.acegisecurity.util.FilterChainProxy/param-value
/init-param
/filter
!-- Spring Wicket app--
filter
descriptionFilter for initiating handling of Wicket
requests./description
filter-namewicket-spring/filter-name
filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class
init-param
descriptionImplementation of IWebApplicationFactory that
pulls the WebApplication
object out of spring application context/description
param-nameapplicationFactoryClassName/param-name
param-valueorg.apache.wicket.spring.SpringWebApplicationFactory/param-value
/init-param
/filter
!-- Acegi filter first, only for /acegi urls --
filter-mapping
filter-nameAcegi HTTP Request Security Filter/filter-name
url-pattern/frtool/*/url-pattern
/filter-mapping
!-- regular mapping for spring wicket app --
filter-mapping
filter-namewicket-spring/filter-name
url-pattern/frtool/*/url-pattern
/filter-mapping
filter-mapping
filter-namelazyLoadingFilter/filter-name
url-pattern/frtool/*/url-pattern
/filter-mapping
!-- Listener for Spring --
listener
descriptionBootstrap listener to start up Spring's root
WebApplicationContext. Simply
delegates to ContextLoader. /description
listener-classorg.springframework.web.context.ContextLoaderListener/listener-class
/listener
session-config
session-timeout 30 /session-timeout
/session-config
Re: Sanity check. Can't inject DAO
On May 29, 2008, at 5:18 PM, Michael O'Cleirigh wrote: Hi David, Have you tried with naming the dao to be injected explicitly? i.e. @SpringBean (name=ProtocolDAO) private ProtocolDAO dao; Interesting. That seems to get me closer... org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'ProtocolDAO' must be of type [com.vzbi.ncs.argfrp.jpa.netconf.ProtocolDAO], but was actually of type [$Proxy30] Checking google... -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sanity check. Can't inject DAO
I don't think the proxy stuff is your problem. Is your DAO class interface-based (it should be). Meaning, do you have a DAO interface that your implementation class implements (this part is key)? I have had situations where I forgot to add in the implements FooDao to my implementation class even though it had all the required methods. On Thu, May 29, 2008 at 7:58 PM, David Nedrow [EMAIL PROTECTED] wrote: On May 29, 2008, at 7:50 PM, David Nedrow wrote: On May 29, 2008, at 5:18 PM, Michael O'Cleirigh wrote: Hi David, Have you tried with naming the dao to be injected explicitly? i.e. @SpringBean (name=ProtocolDAO) private ProtocolDAO dao; Interesting. That seems to get me closer... org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'ProtocolDAO' must be of type [com.vzbi.ncs.argfrp.jpa.netconf.ProtocolDAO], but was actually of type [$Proxy30] Checking google... Looks like I may need to add 'proxy-target-class=true' to my tx:annotation-driven/ element. That gets me all the way to the actual data object, though there is a failure there I'll have to look at. Thanks for getting me pointed in the right direction. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sanity check. Can't inject DAO
Pardon my possible ignorance but didn't the need to use DAOs evaporate once transparent persistence (eg., Hibernate, JDO) hit the streets a few years back? I always thought the DAO architecture was what we used in the old days in the absence of mature transparent persistence solutions when we had a DAO per persistent class to help with the persistence of that class. Now that persistence is effectively transparent (using Hibernate, JPOX etc.,) aren't they now redundant? Have you tried with naming the dao to be injected explicitly? i.e. @SpringBean (name=ProtocolDAO) private ProtocolDAO dao; Interesting. That seems to get me closer... org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'ProtocolDAO' must be of type [com.vzbi.ncs.argfrp.jpa.netconf.ProtocolDAO], but was actually of type [$Proxy30] Checking google... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sanity check. Can't inject DAO
You should still abstract your data access behind some interface. On Thu, May 29, 2008 at 9:19 PM, Chris Colman [EMAIL PROTECTED] wrote: Pardon my possible ignorance but didn't the need to use DAOs evaporate once transparent persistence (eg., Hibernate, JDO) hit the streets a few years back? I always thought the DAO architecture was what we used in the old days in the absence of mature transparent persistence solutions when we had a DAO per persistent class to help with the persistence of that class. Now that persistence is effectively transparent (using Hibernate, JPOX etc.,) aren't they now redundant? Have you tried with naming the dao to be injected explicitly? i.e. @SpringBean (name=ProtocolDAO) private ProtocolDAO dao; Interesting. That seems to get me closer... org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'ProtocolDAO' must be of type [com.vzbi.ncs.argfrp.jpa.netconf.ProtocolDAO], but was actually of type [$Proxy30] Checking google... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sanity check. Can't inject DAO
the need for dao per entity class has gone away with transparent persistence, however there is still a dao that is a hibenate session, jpa entitymanager, cayenne context, or whatever. also, some people still use dao to store finder/batch update methods. -igor On Thu, May 29, 2008 at 6:19 PM, Chris Colman [EMAIL PROTECTED] wrote: Pardon my possible ignorance but didn't the need to use DAOs evaporate once transparent persistence (eg., Hibernate, JDO) hit the streets a few years back? I always thought the DAO architecture was what we used in the old days in the absence of mature transparent persistence solutions when we had a DAO per persistent class to help with the persistence of that class. Now that persistence is effectively transparent (using Hibernate, JPOX etc.,) aren't they now redundant? Have you tried with naming the dao to be injected explicitly? i.e. @SpringBean (name=ProtocolDAO) private ProtocolDAO dao; Interesting. That seems to get me closer... org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'ProtocolDAO' must be of type [com.vzbi.ncs.argfrp.jpa.netconf.ProtocolDAO], but was actually of type [$Proxy30] Checking google... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sanity check. Can't inject DAO
Oh ok, it's probably just a terminology issue then. We use JDO and hence the PersistenceManager is our equivalent to the others you speak of. In the past DAOs were always a beast that had to be dealt with explicitly to store and retrieve objects. The Hibernate Session, JDO PersistenceManager etc., are a lot less 'manual' with automatic 'load on demand' and update of dirty objects and so I never associated them with the old fashioned DAOs we used to create. We also use the Exposed POJO Domain Model pattern with its 'repositories' (for locating objects) and 'services' (for making significant model changes according to embedded business rules) which allows us to write code that can be easily ported to any transparent persistence provider and it manages all the dependency injection in a very light weight manner in simple Java rather than a 'sea of XML' which really turned me off Spring. the need for dao per entity class has gone away with transparent persistence, however there is still a dao that is a hibenate session, jpa entitymanager, cayenne context, or whatever. also, some people still use dao to store finder/batch update methods. -igor On Thu, May 29, 2008 at 6:19 PM, Chris Colman [EMAIL PROTECTED] wrote: Pardon my possible ignorance but didn't the need to use DAOs evaporate once transparent persistence (eg., Hibernate, JDO) hit the streets a few years back? I always thought the DAO architecture was what we used in the old days in the absence of mature transparent persistence solutions when we had a DAO per persistent class to help with the persistence of that class. Now that persistence is effectively transparent (using Hibernate, JPOX etc.,) aren't they now redundant? Have you tried with naming the dao to be injected explicitly? i.e. @SpringBean (name=ProtocolDAO) private ProtocolDAO dao; Interesting. That seems to get me closer... org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'ProtocolDAO' must be of type [com.vzbi.ncs.argfrp.jpa.netconf.ProtocolDAO], but was actually of type [$Proxy30] Checking google... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sanity check. Can't inject DAO
On Thu, May 29, 2008 at 10:47 PM, Chris Colman [EMAIL PROTECTED] wrote: Oh ok, it's probably just a terminology issue then. We use JDO and hence the PersistenceManager is our equivalent to the others you speak of. The PersistenceManager shouldn't be part of your domain model. In the past DAOs were always a beast that had to be dealt with explicitly to store and retrieve objects. The Hibernate Session, JDO PersistenceManager etc., are a lot less 'manual' with automatic 'load on demand' and update of dirty objects and so I never associated them with the old fashioned DAOs we used to create. Hibernate vs. JDO vs. iBATIS vs. JPA is still an implementation detail. Your true domain shouldn't care what persistence technology you're using. We also use the Exposed POJO Domain Model pattern with its 'repositories' (for locating objects) and 'services' (for making significant model changes according to embedded business rules) which allows us to write code that can be easily ported to any transparent persistence provider and it manages all the dependency injection in a very light weight manner in simple Java rather than a 'sea of XML' which really turned me off Spring. The Exposed POJO Domain Model would prescribe that you use an interface for your repositories. The implementation of those repositories would be based on the persistence technology, but it could be switched out without changing any of your other domain classes (the interface would stay that same). So, you still need the repository/dao abstraction (most folks still use the term DAO rather than repository in my experience). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sanity check. Can't inject DAO
On May 29, 2008, at 8:51 PM, James Carman wrote:
I don't think the proxy stuff is your problem. Is your DAO class
interface-based (it should be). Meaning, do you have a DAO interface
that your implementation class implements (this part is key)?
Yes, the classes are interface-based. Eg.,
public class ProtocolDAO extends JpaDaoSupport implements IProtocolDAO
I think it's down to fiuring out what I've done wrong in my Panel. I
get a classcastexception at the (Protocol) item.getModelObject();
line. Listed below is both my Panel and the appropriate signature from
ProtocolDAO.findAll().
public class ShowProtocolsPanel extends Panel {
@SpringBean(name=ProtocolDAO)
private ProtocolDAO dao;
public ShowProtocolsPanel(String id) {
super(id);
IModel protocolModel = new LoadableDetachableModel() {
protected Object load() {
return dao.findAll();
}
};
add(new ListView(eachItem, protocolModel) {
@Override protected void populateItem(ListItem item) {
final Protocol protocol = (Protocol)
item.getModelObject();
item.add(new Label(keyword, protocol.getKeyword()));
item.add(new Label(description,
protocol.getDescription()));
}
});
}
}
public class ProtocolDAO extends JpaDaoSupport implements IProtocolDAO {
...
@Transactional(readOnly = true)
@SuppressWarnings(unchecked)
@Override
public ListProtocol findAll(final int... rowStartIdxAndCount) {
...
}
...
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sanity check. Can't inject DAO
On Thu, 29 May 2008, David Nedrow wrote:
public class ProtocolDAO extends JpaDaoSupport implements IProtocolDAO
...
public class ShowProtocolsPanel extends Panel {
@SpringBean(name=ProtocolDAO)
private ProtocolDAO dao;
Clearly this should be IProtocolDao, so that the component
depends on interface and not on implementation.
I'm not sure if this affects your issue though, we use both
forms all the time with Spring 2.5.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
