JBossDeveloper

Mike,

Can you be a bit more specific and describe: what jars did you put in those locations and what problems did you encounter?

Thanks,
Marius

"marius.bogoevici" wrote:

Can you be a bit more specific and describe: what jars did you put in those locations and what problems did you encounter?
Marius

Well I'm having all sorts of problems :-)

My main problem at the moment (which I should open a seperate thread either here or on the spring forums) is dependency injection has stopped working for me.

What I had working in a single war was a data access object defined like so

@Repository
public class HibernateDomainObjectDao extends HibernateDaoSupport implements DomainObjectDao {

@Service
public class DomainObjectServiceImpl implements DomainObjectService {

 private DomainObjectDao domainObjectDao;

 private static Logger log = Logger.getLogger(DomainObjectServiceImpl.class);

 public DomainObjectServiceImpl()
 {
 log.error("CONSTRUCTED DomainObjectServiceImpl");
 }

 @Resource
 public void setDomainObjectDao(DomainObjectDao domainObjectDao)
 {
 log.error("setDomainObjectDao");
 this.domainObjectDao = domainObjectDao;
 }

If I don't include int-vfs and int-deployers in the war/lib directory (but I do have them in the spring.deployers directory) I get the following exception

It looks like you're also including spring.jar in your .war?

Thanks for the update.

The problem seems to be that spring-web.jar is included in both the web app and the deployer, where it does not really belong. Try removing the spring-web.jar from the deployer and give it another try.

I'll fix the build not to it.

Generally speaking, try to make sure that you have the spring jars included only in one place (shared libs, deployer, war) and they're visible enough to the component that you want to use them (e.g. if you don't use the deployer, you can put them in the war, if you use the deployer put them in the deployer or shared, etc). The reason why we include a minimal set of jars in the distribution is that this is what you would need to get things running out of the box, if the only thing you need to do is provide an xml to do the bean wiring, but you can use different other setups, as per above, to match your needs.

Marius

Thanks alot guys ... duplicate jars was the answer to ALL my problems.

I was porting a sample app that was working on tomcat so I suppose its my own fault. But my dependency injection problem was cleaned up (by removing the hibernate jar) as well.

Thanks again. That was driving me CRAZZZZYYYY !!!! :-)

Ok still have a (small) problem with these spring jars, when I access the jsp, the war isn't picking up the spring tag libraries from the spring.jar (spring-2.5.6.jar) thats contained in the deployer directory, if I remove the tag definition everything is fine, I don't particularly need spring tags but its disconcerting that the war isn't picking it up. Could this be another clashing jar issue ?

I think you can somehow link these tlds/tags by declaring them in web.xml.
But I might be wrong since it's been ages when I last did www ui. :-)

Mike,

You need spring-mvc.jar on the classpath (contents of which are not included in spring.jar) if you want to reference the spring taglibs.

Are you sure that you added that particular jar to the deployer?

Marius

This is the contents of my deployers directory

$ ls
META-INF spring-context-support-2.5.6.jar
jboss-spring-int-deployers.jar spring-core-2.5.6.jar
jboss-spring-int-vfs.jar spring-orm-2.5.6.jar
jboss-spring.jar spring-tx-2.5.6.jar
spring-2.5.6.jar spring-web-2.5.6.jar
spring-beans-2.5.6.jar spring-webmvc-2.5.6.jar
spring-context-2.5.6.jar


my ear contents (I'm still trying to pear this down)
$ ls
META-INF jta-1.1.jar
aopalliance-1.0.jar junit-3.8.1.jar
asm-3.1.jar log4j-1.2.14.jar
asm-commons-3.1.jar maven-archiver-2.2.jar
asm-tree-3.1.jar maven-artifact-2.0.4.jar
asm-util-3.1.jar maven-artifact-manager-2.0.4.jar
aspectjrt-1.6.1.jar maven-ear-plugin-2.3.1.jar
aspectjweaver-1.6.1.jar maven-model-2.0.4.jar
cglib-nodep-2.1_3.jar maven-plugin-api-2.0.4.jar
classworlds-1.1-alpha-2.jar maven-profile-2.0.4.jar
common-mgt-fw.jar maven-project-2.0.4.jar
common-mgt-fw.war maven-repository-metadata-2.0.4.jar
commons-collections-3.2.1.jar maven-settings-2.0.4.jar
commons-dbcp-1.2.2.jar mysql-connector-java-5.1.6.jar
commons-logging-1.1.1.jar plexus-archiver-1.0-alpha-7.jar
commons-pool-1.4.jar plexus-container-default-1.0-alpha-9.jar
hessian-3.1.5.jar plexus-utils-1.2.jar
jdom-1.1.jar quartz-1.6.1.jar
jsr250-api-1.0.jar standard-1.1.2.jar
jstl-1.1.2.jar wagon-provider-api-1.0-alpha-6.jar

thats hard to read ... better

For anyone following the discussion on this forum, I've made a few changes to the project structure, moving the context classes in the vfs module and leaving the deployers to deal with deployment only.

A few hints:

1. context class is org.jboss.spring.vfs.context.VFSXmlWebApplicationContext
2. you only need to include jboss-spring-int-vfs.jar in your application
3. the stable branch for the project is to be found at http://anonsvn.jboss.org/repos/jbossas/projects/spring-int/branches/1_0/

Ales,

Is the code for spring-int (specifically org.jboss.spring.vfs) still maintained at https://anonsvn.jboss.org/repos/jbossas/projects/spring-int? Is the jar now available in JBoss AS 5.1.0 or part of some maven repository?

Thanks.
Naresh

Naresh,

The project is now hosted under https://www.jboss.org/snowdrop. Here you will find the downloads and the documentation for it. I need to update the stickies of the forum.

the svn location is: https://anonsvn.jboss.org/repos/jbossas/projects/snowdrop/

(1.0.0 is based on the 1_0 branch, current trunk is the future 1.1)

It is available in maven in the JBoss Maven repository as:

org.jboss.snowdrop
snowdrop-vfs
1.0.0.GA

(the other modules are snowdrop-cluster, snowdrop-deployers, snowdrop-facade and snowdrop-weaving)

Hope that helps,
Marius

PS: Good reminder for me to update the stickies on the top of the forum ;)