[rules-dev] Guvnor build problems? -> Tomcat

Geoffrey De Smet ge0ffrey.spam at gmail.com
Thu Jan 20 08:20:59 EST 2011


Michael,

I've done a "mvn clean install" locally and that test class  
(MockRoleBasedPermissionStore) is not packaged in the war.
This directory
   
droolsjbpm/drools-guvnor/*target*/drools-guvnor/WEB-INF/classes/org/drools/guvnor/server/security
does not contain MockRoleBasedPermissionStore (which is normal, as it's 
comes from src/test/java, not src/main/java).

So I don't understand how it ended up in your war you created and 
deployed to tomcat.
Can you check if you do a "mvn clean install -DskipTests" that you have 
it again?


I do have problems to deploy the Guvnor SNAPSHOT on tomcat 6:

ERROR 20-01 14:05:09,218 (RepositoryImpl.java:getWorkspaceInfo:785)     
  Unable to initialize workspace 'security'
javax.jcr.RepositoryException: Cannot instantiate persistence manager 
org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager
     at 
org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1433)
...
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot create 
PoolableConnectionFactory (Failed to create database 
'repository/workspaces/security/db', see the next exception for details.)
     at 
org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1225)
...
Caused by: java.sql.SQLException: Failed to create database 
'repository/workspaces/security/db', see the next exception for details.
     at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown 
Source)
...
Caused by: java.sql.SQLException: Directory 
/home/gdesmet/opt/appserver/*apache-tomcat-6.0.30/bin/repository/workspaces/security/db 
already exists*.
     at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown 
Source)
...
Caused by: ERROR XBM0J: Directory 
/home/gdesmet/opt/appserver/apache-tomcat-6.0.30/bin/repository/workspaces/security/db 
already exists.
     at 
org.apache.derby.iapi.error.StandardException.newException(Unknown Source)


Op 20-01-11 10:15, Geoffrey De Smet schreef:
> I don't know who broke it, but I 'll see if I can get it fixed
>
> Op 20-01-11 09:20, Michael Anstis schreef:
>> Hi Ge0ffrey,
>>
>>> Does it occur in hosted mode in Eclipse/IntelliJ?
>>> Looks like the test classes are also copied into the war?!?
>>> Tihomir might know more about the whole role based stuff.
>> - It occurs when deploying to Tomcat (any Servlet Container?).
>> - The WAR *does* contain all "test" classes\resources.
>> - It does not occur in hosted mode (as I can remove "test"
>> classes\resources from the classpath).
>> - Seam is correct in reporting the error (as two classes are declared
>> as being the same component, because of the inclusion of "test" classes).
>>
>> So I'd surmise a compile problem with maven (but it could be old news)?
>>
>> With kind regards,
>>
>> Mike
>>
>> On 20 January 2011 07:56, Geoffrey De Smet<ge0ffrey.spam at gmail.com
>> <mailto:ge0ffrey.spam at gmail.com>>  wrote:
>>
>>
>>
>>      Op 19-01-11 22:33, Michael Anstis schreef:
>>      >  Hi,
>>      >
>>      >  I tried building a WAR for Guvnor and found a couple of hick-ups
>>      >  (although it was with my local copy of master taken a few months
>>      ago).
>>      >
>>      >  I mention them here in case they are unknown issues (feel free
>>      to beat
>>      >  me up if I simply need to resync with master; which will happen as
>>      >  part of my dtable commit...)
>>      >
>>      >  1) In \drools-guvnor
>>      >
>>      >  mvn package -DskipTests=true -PfullProfile
>>      >
>>      >  Didn't build dependant drools-ide-common, as I'd expect and I had to
>>      >  "mvn install" this first.
>>      This is partially normal...
>>      mvn install = mvn package (=make the jar) + copy the jar in the local
>>      repository
>>      mvn package = mvn compile + ... + make the jar
>>
>>      But for normal java apps, mvn compile is enough even in a
>>      multi-module,
>>      because it doesn't need to create a jar (or copy that in the local
>>      repo)
>>      as it justs reuses drools-ide-common/target/classes in the
>>      classpath of
>>      drools-guvnor.
>>      Just like your Eclipse/IntelliJ does (because if were to build a jar
>>      each time it would take as long as the maven build).
>>      However, that might not work for GWT compilation,
>>      so the safest bet it to do mvn install...
>>      >
>>      >  2) In \drools-guvnor
>>      >
>>      >  mvn package -DskipTests=true -PfullProfile
>>      >
>>      >  Built the WAR however the test classes are also included,
>>      leading to a
>>      >  Seam error when deploying:-
>>      >
>>      >  SEVERE: Exception sending context initialized event to listener
>>      >  instance of class org.jboss.seam.servlet.SeamListener
>>      >  java.lang.IllegalStateException: Two components with the same
>>      name and
>>      >  precedence - component name:
>>      >  org.drools.guvnor.server.security.RoleBasedPermissionStore,
>>      component
>>      >  classes:
>>      >  org.drools.guvnor.server.security.MockRoleBasedPermissionStore,
>>      >  org.drools.guvnor.server.security.RoleBasedPermissionStore
>>      >      at
>>      >
>>      org.jboss.seam.init.Initialization.addComponentDescriptor(Initialization.java:586)
>>      >      at
>>      >
>>      org.jboss.seam.init.Initialization.installScannedComponentAndRoles(Initialization.java:927)
>>      >      at
>>      >
>>      org.jboss.seam.init.Initialization.scanForComponents(Initialization.java:874)
>>      >      at
>>      org.jboss.seam.init.Initialization.init(Initialization.java:687)
>>      >
>>      >  This traced back to "MockRoleBasedPermissionStore" in the test
>>      classes
>>      >  and "RoleBasedPermissionStore" in the non-test classes.
>>      >
>>      >  Tomcat 6.x.
>>
>>      Does it occur in hosted mode in Eclipse/IntelliJ?
>>      Looks like the test classes are also copied into the war?!?
>>      Tihomir might know more about the whole role based stuff.
>>      >
>>      >  3) Alot of Guvnor tests failed, however I assume Toni Rikkola could
>>      >  have fixed recently with his work in this area.
>>
>>      If they talk about a repository lock failing, it's cool and Toni's
>>      working on it.
>>      If it's something else, it's not cool.
>>      >
>>      >  Cheers,
>>      >
>>      >  Mike
>>      >
>>      >
>>      >  _______________________________________________
>>      >  rules-dev mailing list
>>      >  rules-dev at lists.jboss.org<mailto:rules-dev at lists.jboss.org>
>>      >  https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>      --
>>      With kind regards,
>>      Geoffrey De Smet
>>
>>
>>      _______________________________________________
>>      rules-dev mailing list
>>      rules-dev at lists.jboss.org<mailto:rules-dev at lists.jboss.org>
>>      https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev

-- 
With kind regards,
Geoffrey De Smet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110120/fc8862e0/attachment.html 


More information about the rules-dev mailing list