Re: Whence the geronimo kernel?

[Jack Cai]

This is defintely a good move! How will that affect the programming model
around Geronimo? Obviously some users are not happy with the complexity of
the deployment plan [1].

-Jack

[1]
http://www.nabble.com/your-current-Geronimo-evaluation-td22329850s134.html

2009/3/5 Ivan 

> It is a good idea.
> I encounter some similar issues about the multiparent classloader. From the
> pom.xml, currently, it is hard to know which jar is in the classpath. The
> dependies between the configurations are also too complex, I notice that the
> restart/reload codes in the configurationManager is very very ...
> Maybe we could replace all the codes in the configurationManager, and just
> delegate it to the OSGI module/lifecycle layer.
> Thanks !
>
>
> 2009/3/5 David Jencks 
>
> Geronimo has been around for a while and despite the many good features
>> gbeans and the geronimo kernel are not catching on big time.  I think we
>> want to consider taking action now to avoid ending up being dragged down by
>> supporting a dead container.  Here are a few thoughts.
>>
>> Actual problems with geronimo:
>> - gbeans are too restrictive.  It's too hard to instantiate other peoples
>> components as gbeans.  GBeans don't support common patterns like factory
>> methods, factory beans, etc etc, and require the component to be
>> instantiated directly by the gbean framework.
>> - it's too hard to get the classloaders to work.  The most common problem
>> is a class cast exception due to loading the same jar in two plugins.
>>  NoClassDefFound errors from an optional jar in a child classloader are also
>> really annoying.
>>
>> Really good things about geronimo I haven't seen elsewhere (at least in
>> one place):
>> - gbean dependencies work across plugins.  Dependencies are a unified
>> system, not per-plugin.
>> - gbean dependencies are resolved in the ancestors of a plugin, not server
>> wide.  This means that you can't make a partially specified dependency
>> ambiguous by deploying additional plugins.  I consider this an extremely
>> important feature for predictability.
>> - plugin dependencies allow assembly of a server from the explicit
>> dependencies which are normally the same as the maven dependencies.
>>
>> Other projects and specs that have stuff we should look into:
>> maven.  Maven has a lot better infrastructure for dealing with dependency
>> resolution from partial transitive dependency specification than we do.  We
>> should look into using more of their infrastructure.
>> osgi. osgi has a lot of similarities to geronimo. The osgi classloading
>> model is getting a lot of people excited.  The import-bundle idea is pretty
>> much the same as our classloader model where every jar is a plugin.  I don't
>> know if people are really using the allegedly recommended method of
>> specifying imports and exports and letting the osgi runtime figure out where
>> they come from; this seems worth investigating to me. Also, we get periodic
>> inquiries about when we are going to support osgi and the was ce folks get
>> even more.
>> osgi blueprint service (rfc 124) This appears to be a simple wiring
>> framework for a single plugin.  IIUC it uses the osgi service registry for
>> component dependencies between bundles.
>> xbean-spring.  I'd be reluctant to try to implement a blueprint service
>> that didn't provide the xbean-spring capabilities really well
>> ee6 dependency injection.  EE6 is going to have a pretty sophisticated
>> dependency injection service which we'll need to support anyway.  We should
>> try to figure out how much of the core we can assemble using it.
>>
>> Other great stuff we have:
>> xbean-reflect, xbean-finder, xbean-spring
>>
>>
>> These ideas have been floating around in my head for a long time and I've
>> chatted with various people about them occasionally.   While more discussion
>> is certainly needed on everything here I need to do some implementation to
>> understand much more.  So, what I'm planning to do:
>>
>> Dave's crazy work plan...
>> - Try to use the osgi classloader.  I think this involves putting the
>> classloader creation in Configuration into a service.  Configurations will
>> turn into osgi bundles.  I'll put the Kernel in the osgi ServiceRegistry so
>> the Configuration bundle activator should be able to use it to resolve
>> cross-plugin dependencies.
>> - try to figure out how maven dependency resolution fits into osgi.
>> - see if eclipse p2 is relevant for provisioning geronimo repositories
>>
>> at this point I think geronimo would be running on osgi, still using
>> gbeans.
>>
>> - look into relaxing the gbean framework so it is more plugin-at-a-time
>> rather than gbean-at-a-time
>> - see how that differs from the blueprint service, ee DI, and
>> xbean-spring.  Try to support all of these at once.
>>
>> Thoughts? Counter proposals?  Anyone interested?
>>
>> many thanks
>> david jencks
>>
>>
>
>
> --
> Ivan
>

[jira] Commented: (GERONIMO-4544) Error occured when repeatedly create DB or records

[Ivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679107#action_12679107
 ] 

Ivan commented on GERONIMO-4544:


Thanks for your help,  Jarek and David !

> Error occured when repeatedly create DB or records
> --
>
> Key: GERONIMO-4544
> URL: https://issues.apache.org/jira/browse/GERONIMO-4544
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1.4
> Environment: JAVA5 + RHEL 5.3 (X86) + Firefox 3.0.5
>Reporter: lily seattle
>Assignee: Jarek Gawor
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4544-for2.1.patch, Geronimo-4544-forTrunk.patch
>
>
> steps:
> 1. login console
> 2. Click Embedded DB -> DB Manager. 
> 3. Filling the Create DB blank with TestDB, click Create.
> 4.Create a table using:
> CREATE TABLE CUSTOMER (
>   ID  INTEGER NOT NULL PRIMARY KEY,
>   NAMEVARCHAR(45),
>   BIRTHDATE   DATE,
>   SSS_NO  VARCHAR(25),
>   ADDRESS VARCHAR(60),
>   ANNUAL_SALARY   DOUBLE,
>   LOAN_AMOUNT DOUBLE
>   );
> 5. Insert a record:
> INSERT INTO CUSTOMER VALUES
> (001，'hi','02/19/2009','111','somewhere',100,150);
> Now, if create the same table again, or Insert the same record, errors will 
> occur. Also the Table can't be accessed
> any more.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Whence the geronimo kernel?

[Ivan]

It is a good idea.
I encounter some similar issues about the multiparent classloader. From the
pom.xml, currently, it is hard to know which jar is in the classpath. The
dependies between the configurations are also too complex, I notice that the
restart/reload codes in the configurationManager is very very ...
Maybe we could replace all the codes in the configurationManager, and just
delegate it to the OSGI module/lifecycle layer.
Thanks !


2009/3/5 David Jencks 

> Geronimo has been around for a while and despite the many good features
> gbeans and the geronimo kernel are not catching on big time.  I think we
> want to consider taking action now to avoid ending up being dragged down by
> supporting a dead container.  Here are a few thoughts.
>
> Actual problems with geronimo:
> - gbeans are too restrictive.  It's too hard to instantiate other peoples
> components as gbeans.  GBeans don't support common patterns like factory
> methods, factory beans, etc etc, and require the component to be
> instantiated directly by the gbean framework.
> - it's too hard to get the classloaders to work.  The most common problem
> is a class cast exception due to loading the same jar in two plugins.
>  NoClassDefFound errors from an optional jar in a child classloader are also
> really annoying.
>
> Really good things about geronimo I haven't seen elsewhere (at least in one
> place):
> - gbean dependencies work across plugins.  Dependencies are a unified
> system, not per-plugin.
> - gbean dependencies are resolved in the ancestors of a plugin, not server
> wide.  This means that you can't make a partially specified dependency
> ambiguous by deploying additional plugins.  I consider this an extremely
> important feature for predictability.
> - plugin dependencies allow assembly of a server from the explicit
> dependencies which are normally the same as the maven dependencies.
>
> Other projects and specs that have stuff we should look into:
> maven.  Maven has a lot better infrastructure for dealing with dependency
> resolution from partial transitive dependency specification than we do.  We
> should look into using more of their infrastructure.
> osgi. osgi has a lot of similarities to geronimo. The osgi classloading
> model is getting a lot of people excited.  The import-bundle idea is pretty
> much the same as our classloader model where every jar is a plugin.  I don't
> know if people are really using the allegedly recommended method of
> specifying imports and exports and letting the osgi runtime figure out where
> they come from; this seems worth investigating to me. Also, we get periodic
> inquiries about when we are going to support osgi and the was ce folks get
> even more.
> osgi blueprint service (rfc 124) This appears to be a simple wiring
> framework for a single plugin.  IIUC it uses the osgi service registry for
> component dependencies between bundles.
> xbean-spring.  I'd be reluctant to try to implement a blueprint service
> that didn't provide the xbean-spring capabilities really well
> ee6 dependency injection.  EE6 is going to have a pretty sophisticated
> dependency injection service which we'll need to support anyway.  We should
> try to figure out how much of the core we can assemble using it.
>
> Other great stuff we have:
> xbean-reflect, xbean-finder, xbean-spring
>
>
> These ideas have been floating around in my head for a long time and I've
> chatted with various people about them occasionally.   While more discussion
> is certainly needed on everything here I need to do some implementation to
> understand much more.  So, what I'm planning to do:
>
> Dave's crazy work plan...
> - Try to use the osgi classloader.  I think this involves putting the
> classloader creation in Configuration into a service.  Configurations will
> turn into osgi bundles.  I'll put the Kernel in the osgi ServiceRegistry so
> the Configuration bundle activator should be able to use it to resolve
> cross-plugin dependencies.
> - try to figure out how maven dependency resolution fits into osgi.
> - see if eclipse p2 is relevant for provisioning geronimo repositories
>
> at this point I think geronimo would be running on osgi, still using
> gbeans.
>
> - look into relaxing the gbean framework so it is more plugin-at-a-time
> rather than gbean-at-a-time
> - see how that differs from the blueprint service, ee DI, and xbean-spring.
>  Try to support all of these at once.
>
> Thoughts? Counter proposals?  Anyone interested?
>
> many thanks
> david jencks
>
>


-- 
Ivan

[jira] Commented: (GERONIMO-4555) Can't start App Client after stop it from console

[Ivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679098#action_12679098
 ] 

Ivan commented on GERONIMO-4555:


In the current app client  portlet, when it detects that if the type of the 
configuration is CAR, then it thought that it is a client application, so do 
not list any action (such as start/restart). The clause is correct if the 
module is of client side, for server side, it seems that we still allow to 
start/stop/restart it. So I add an extra clause to check it.
Thanks !

> Can't start  App Client after stop it from console
> --
>
> Key: GERONIMO-4555
> URL: https://issues.apache.org/jira/browse/GERONIMO-4555
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1.4
> Environment: OS:Windows 2003  JDK:1.5
>Reporter: viola.lu
>Priority: Minor
> Attachments: Geronimo-4555.patch
>
>
> 1.Deploy an application client, and stop its server module, but after that 
> there is just an "uninstall"button left, can't re-start it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4571) App client still can run after stop app client server env module

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679083#action_12679083
 ] 

David Jencks commented on GERONIMO-4571:


This is not really a problem.  The server side app client module is only there 
to fulfil some silly jsr77 requirements.  It doesn't actually do anything 
useful.

> App client still can run after stop app client server env module
> 
>
> Key: GERONIMO-4571
> URL: https://issues.apache.org/jira/browse/GERONIMO-4571
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: application client
>Affects Versions: 2.1.4
> Environment: OS:win2003, JDK 1.5
>Reporter: viola.lu
>Priority: Minor
> Attachments: test1.jar
>
>
> Steps:
> 1.Deploy the attached app client to g server, client env module is 
> sample/appclient/1.0/car, server env module is sample/appserver/1.0/car.
> and sample/appserver/1.0/car status is running
> 2.I stopped sample/appserver/1.0/car, run command :client.bat/client.sh 
> sample/appclient/1.0/car, it still can work, and print out string.
> So any one familiar with standalone app client running behavior give some 
> hints?Whether app client server module status is stopped or running, app 
> client still can run?Thanks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4555) Can't start App Client after stop it from console

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679082#action_12679082
 ] 

David Jencks commented on GERONIMO-4555:


I'm not sure I understand the proposed fix for the problem.  However the 
server side client module is a very silly thing that does nothing useful but is 
pretty much required for jsr77 compliance.  Basically it says the ear has an 
app client distributed inside... but has no influence on anything's behavior.

> Can't start  App Client after stop it from console
> --
>
> Key: GERONIMO-4555
> URL: https://issues.apache.org/jira/browse/GERONIMO-4555
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1.4
> Environment: OS:Windows 2003  JDK:1.5
>Reporter: viola.lu
>Priority: Minor
> Attachments: Geronimo-4555.patch
>
>
> 1.Deploy an application client, and stop its server module, but after that 
> there is just an "uninstall"button left, can't re-start it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4549) JMS resource jndi entries are not removed after uninstalling the JMS connect adapter

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679081#action_12679081
 ] 

David Jencks commented on GERONIMO-4549:


Jack,

I don't completely understand the xbean jndi code however I think the reason 
for some of the things like removeNotEmptyContext are to support federated jndi 
contexts.  So I recommend you try to understand federated jndi contexts better 
than I do before changing the code... or come up with more unit tests.


> JMS resource jndi entries are not removed after uninstalling the JMS connect 
> adapter
> 
>
> Key: GERONIMO-4549
> URL: https://issues.apache.org/jira/browse/GERONIMO-4549
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: ActiveMQ
>Affects Versions: 2.1.4
>Reporter: Forrest Xia
>Priority: Blocker
> Fix For: 2.1.4, 2.2
>
>
> Steps to reproduce this problem:
> 1. login admin console
> 2. Create a ActiveMQ resource connector with the wizard
> 3. Deploy it and check it is in running state
> 4. Click J2EE connector to uninstall it
> 5. Check JNDI viewer, you will see the JNDI entry still there, even you've 
> uninstalled it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4571) App client still can run after stop app client server env module

[viola.lu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

viola.lu updated GERONIMO-4571:
---

Attachment: test1.jar

> App client still can run after stop app client server env module
> 
>
> Key: GERONIMO-4571
> URL: https://issues.apache.org/jira/browse/GERONIMO-4571
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: application client
>Affects Versions: 2.1.4
> Environment: OS:win2003, JDK 1.5
>Reporter: viola.lu
>Priority: Minor
> Attachments: test1.jar
>
>
> Steps:
> 1.Deploy the attached app client to g server, client env module is 
> sample/appclient/1.0/car, server env module is sample/appserver/1.0/car.
> and sample/appserver/1.0/car status is running
> 2.I stopped sample/appserver/1.0/car, run command :client.bat/client.sh 
> sample/appclient/1.0/car, it still can work, and print out string.
> So any one familiar with standalone app client running behavior give some 
> hints?Whether app client server module status is stopped or running, app 
> client still can run?Thanks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-4571) App client still can run after stop app client server env module

[viola.lu (JIRA)]

App client still can run after stop app client server env module


 Key: GERONIMO-4571
 URL: https://issues.apache.org/jira/browse/GERONIMO-4571
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: application client
Affects Versions: 2.1.4
 Environment: OS:win2003, JDK 1.5
Reporter: viola.lu
Priority: Minor


Steps:
1.Deploy the attached app client to g server, client env module is 
sample/appclient/1.0/car, server env module is sample/appserver/1.0/car.
and sample/appserver/1.0/car status is running
2.I stopped sample/appserver/1.0/car, run command :client.bat/client.sh 
sample/appclient/1.0/car, it still can work, and print out string.

So any one familiar with standalone app client running behavior give some 
hints?Whether app client server module status is stopped or running, app client 
still can run?Thanks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4544) Error occured when repeatedly create DB or records

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679079#action_12679079
 ] 

David Jencks commented on GERONIMO-4544:


While resetting autocommit won't hurt anything its not necessary either.  When 
the connection gets put back in the pool a cleanup method is called to make 
sure its in a known state and in particular it resets autocommit.  If you 
aren't using the tranql wrappers but some other jdbc-jca wrapper this might not 
have been implemented correctly but with tranql I'm pretty sure it's working 
well.

> Error occured when repeatedly create DB or records
> --
>
> Key: GERONIMO-4544
> URL: https://issues.apache.org/jira/browse/GERONIMO-4544
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1.4
> Environment: JAVA5 + RHEL 5.3 (X86) + Firefox 3.0.5
>Reporter: lily seattle
>Assignee: Jarek Gawor
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4544-for2.1.patch, Geronimo-4544-forTrunk.patch
>
>
> steps:
> 1. login console
> 2. Click Embedded DB -> DB Manager. 
> 3. Filling the Create DB blank with TestDB, click Create.
> 4.Create a table using:
> CREATE TABLE CUSTOMER (
>   ID  INTEGER NOT NULL PRIMARY KEY,
>   NAMEVARCHAR(45),
>   BIRTHDATE   DATE,
>   SSS_NO  VARCHAR(25),
>   ADDRESS VARCHAR(60),
>   ANNUAL_SALARY   DOUBLE,
>   LOAN_AMOUNT DOUBLE
>   );
> 5. Insert a record:
> INSERT INTO CUSTOMER VALUES
> (001，'hi','02/19/2009','111','somewhere',100,150);
> Now, if create the same table again, or Insert the same record, errors will 
> occur. Also the Table can't be accessed
> any more.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-4570) deploy error after using login to save the name and password

[Jarek Gawor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor reassigned GERONIMO-4570:
-

Assignee: Jarek Gawor

> deploy error after using login to save the name and password
> 
>
> Key: GERONIMO-4570
> URL: https://issues.apache.org/jira/browse/GERONIMO-4570
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.1.4
> Environment: AIX(32 bit)+JAVA5
>Reporter: running Wang
>Assignee: Jarek Gawor
>
> 1. start geronimo server
> 2. remove file $HOME/.geronimo-deployer
> 3. run gsh to enter gshell mode
> 4. run deploy/login -u username -w password to save the username and password
> 5. run deploy/connect
> 6. run deploy/list-modules
> output: ERROR IllegalStateException:Disconnected
> if run deploy/list-plugins, output will be ERROR NullPointException:null

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4555) Can't start App Client after stop it from console

[Ivan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan updated GERONIMO-4555:
---

Attachment: Geronimo-4555.patch

Only checking whether the type is CAR is not enough to know it is a clientside 
or serverside application client. Add an extra clause, whether the 
configuration holds any owned configuration. It seems that the server side 
client should always have the client side as the owned configuration.
By the way, I wonder what is the server side client's role? From the codes, I 
found when the application client is standalone, a server client is always 
created. But I did not see any interaction between them in the codes.
Could anyone shed  light on it ?
Thanks!

> Can't start  App Client after stop it from console
> --
>
> Key: GERONIMO-4555
> URL: https://issues.apache.org/jira/browse/GERONIMO-4555
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1.4
> Environment: OS:Windows 2003  JDK:1.5
>Reporter: viola.lu
>Priority: Minor
> Attachments: Geronimo-4555.patch
>
>
> 1.Deploy an application client, and stop its server module, but after that 
> there is just an "uninstall"button left, can't re-start it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[BUILD] trunk: Failed for Revision: 750267

[gawor]

Geronimo Revision: 750267 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/build-2100.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 36 minutes 
[INFO] Finished at: Wed Mar 04 21:39:51 EST 2009
[INFO] Final Memory: 668M/996M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/logs-2100-tomcat/test.log
 
 
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from codehaus-snapshots
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:40.875
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO] 
[INFO] 
---
[INFO] 
[INFO] commands-testsuite/deploy  RUNNING
[INFO] commands-testsuite/deploy  SUCCESS (0:00:59.541) 
[INFO] commands-testsuite/gshell  RUNNING
[INFO] commands-testsuite/gshell  SUCCESS (0:00:27.709) 
[INFO] commands-testsuite/jaxws   RUNNING
[INFO] commands-testsuite/jaxws   SUCCESS (0:00:33.477) 
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:15.915) 
[INFO] concurrent-testsuite/concurrent-basic  RUNNING
[INFO] concurrent-testsuite/concurrent-basic  SUCCESS (0:06:24.025) 
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:19.848) 
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:43.340) 
[INFO] corba-testsuite/corba-helloworld   RUNNING
[INFO] corba-testsuite/corba-helloworld   SUCCESS (0:00:49.256) 
[INFO] corba-testsuite/corba-marshal  RUNNING
[INFO] corba-testsuite/corba-marshal  SUCCESS (0:01:18.856) 
[INFO] corba-testsuite/corba-mytime   RUNNING
[INFO] corba-testsuite/corba-mytime   SUCCESS (0:00:41.707) 
[INFO] deployment-testsuite/deployment-tests  RUNNING
[INFO] deployment-testsuite/deployment-tests  SUCCESS (0:00:30.186) 
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:32.861) 
[INFO] deployment-testsuite/manifestcp-tests  RUNNING
[INFO] deployment-testsuite/manifestcp-tests  SUCCESS (0:00:33.616) 
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:56.499) 
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:54.619) 
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:01:03.852) 
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.970) 
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.445) 
[INFO] security-testsuite/test-security   RUNNING
[INFO] security-testsuite/test-security   FAILURE (0:00:38.136) Java 
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:30.025) 
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5-servlets

[jira] Updated: (GERONIMO-4567) Gshell deploy/assemble command on a remote server cannot work

[caiwenjing (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

caiwenjing updated GERONIMO-4567:
-

  Component/s: commands
Fix Version/s: 2.1.4

> Gshell deploy/assemble command on a remote server cannot work
> -
>
> Key: GERONIMO-4567
> URL: https://issues.apache.org/jira/browse/GERONIMO-4567
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 2.1.4
> Environment: remote : JAVA5 + SOLARIS 10 SPARC (32BIT) 
> local : Windows xp professional sp3
>Reporter: caiwenjing
> Fix For: 2.1.4
>
>
> 1.Change the RemoteDeployHostname to the remote machine's IP in file 
> var/config/config-substitutions.properties in the remote machine.
> 2.Add the remote machine's IP to /etc/hosts in the remote machine.
> 2.Start the server on the remote machine.  
> 3.Cd into /bin directory on the local machine, launch gsh and run: 
> deploy/connect -s REMOTE_IP -p PORT
> 4.run: deploy/assemble, input a server artifact name
> Then console shows:
> ERROR UnmarshalException: error unmarshalling return; nested exception is:  
> java.lang.ClassNotFoundException: 
> com.sun.org.apache.xerces.internal.dom.ElementNSImpl

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-4570) deploy error after using login to save the name and password

[running Wang (JIRA)]

deploy error after using login to save the name and password


 Key: GERONIMO-4570
 URL: https://issues.apache.org/jira/browse/GERONIMO-4570
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Affects Versions: 2.1.4
 Environment: AIX(32 bit)+JAVA5
Reporter: running Wang


1. start geronimo server
2. remove file $HOME/.geronimo-deployer
3. run gsh to enter gshell mode
4. run deploy/login -u username -w password to save the username and password
5. run deploy/connect
6. run deploy/list-modules

output: ERROR IllegalStateException:Disconnected

if run deploy/list-plugins, output will be ERROR NullPointException:null



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4569) Built sample plugin by using new tomcat6-deployer cannot be installed on server

[Forrest Xia (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679035#action_12679035
 ] 

Forrest Xia commented on GERONIMO-4569:
---

ok, got it.

> Built sample plugin by using new tomcat6-deployer cannot be installed on 
> server
> ---
>
> Key: GERONIMO-4569
> URL: https://issues.apache.org/jira/browse/GERONIMO-4569
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Plugins
>Affects Versions: 2.1.4
>Reporter: Forrest Xia
>Assignee: David Jencks
>Priority: Critical
>
> Recently, when I am building some 2.1 branch samples plugins, I found that 
> built sample plugins are all not installable.
> A message on admin console like this:
> "A problem has occured:
> org.apache.geronimo.kernel.config.LifecycleException: start of 
> org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed"
> An exception in stdout/stderr like this:
> "Caused by:
> org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve 
> reference "Container" in gbean
> org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT
>  to a gbean matching the pattern [?name=WebContainer#]
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)"
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Whence the geronimo kernel?

[David Jencks]

Geronimo has been around for a while and despite the many good  
features gbeans and the geronimo kernel are not catching on big time.   
I think we want to consider taking action now to avoid ending up being  
dragged down by supporting a dead container.  Here are a few thoughts.


Actual problems with geronimo:
- gbeans are too restrictive.  It's too hard to instantiate other  
peoples components as gbeans.  GBeans don't support common patterns  
like factory methods, factory beans, etc etc, and require the  
component to be instantiated directly by the gbean framework.
- it's too hard to get the classloaders to work.  The most common  
problem is a class cast exception due to loading the same jar in two  
plugins.  NoClassDefFound errors from an optional jar in a child  
classloader are also really annoying.


Really good things about geronimo I haven't seen elsewhere (at least  
in one place):
- gbean dependencies work across plugins.  Dependencies are a unified  
system, not per-plugin.
- gbean dependencies are resolved in the ancestors of a plugin, not  
server wide.  This means that you can't make a partially specified  
dependency ambiguous by deploying additional plugins.  I consider this  
an extremely important feature for predictability.
- plugin dependencies allow assembly of a server from the explicit  
dependencies which are normally the same as the maven dependencies.


Other projects and specs that have stuff we should look into:
maven.  Maven has a lot better infrastructure for dealing with  
dependency resolution from partial transitive dependency specification  
than we do.  We should look into using more of their infrastructure.
osgi. osgi has a lot of similarities to geronimo. The osgi  
classloading model is getting a lot of people excited.  The import- 
bundle idea is pretty much the same as our classloader model where  
every jar is a plugin.  I don't know if people are really using the  
allegedly recommended method of specifying imports and exports and  
letting the osgi runtime figure out where they come from; this seems  
worth investigating to me. Also, we get periodic inquiries about when  
we are going to support osgi and the was ce folks get even more.
osgi blueprint service (rfc 124) This appears to be a simple wiring  
framework for a single plugin.  IIUC it uses the osgi service registry  
for component dependencies between bundles.
xbean-spring.  I'd be reluctant to try to implement a blueprint  
service that didn't provide the xbean-spring capabilities really well
ee6 dependency injection.  EE6 is going to have a pretty sophisticated  
dependency injection service which we'll need to support anyway.  We  
should try to figure out how much of the core we can assemble using it.


Other great stuff we have:
xbean-reflect, xbean-finder, xbean-spring


These ideas have been floating around in my head for a long time and  
I've chatted with various people about them occasionally.   While more  
discussion is certainly needed on everything here I need to do some  
implementation to understand much more.  So, what I'm planning to do:


Dave's crazy work plan...
- Try to use the osgi classloader.  I think this involves putting the  
classloader creation in Configuration into a service.  Configurations  
will turn into osgi bundles.  I'll put the Kernel in the osgi  
ServiceRegistry so the Configuration bundle activator should be able  
to use it to resolve cross-plugin dependencies.

- try to figure out how maven dependency resolution fits into osgi.
- see if eclipse p2 is relevant for provisioning geronimo repositories

at this point I think geronimo would be running on osgi, still using  
gbeans.


- look into relaxing the gbean framework so it is more plugin-at-a- 
time rather than gbean-at-a-time
- see how that differs from the blueprint service, ee DI, and xbean- 
spring.  Try to support all of these at once.


Thoughts? Counter proposals?  Anyone interested?

many thanks
david jencks

[jira] Commented: (GERONIMO-4297) Include TranQL connector for Oracle RAC

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679003#action_12679003
 ] 

David Jencks commented on GERONIMO-4297:


tranql oracle wraper v 1.4 released.

> Include TranQL connector for Oracle RAC
> ---
>
> Key: GERONIMO-4297
> URL: https://issues.apache.org/jira/browse/GERONIMO-4297
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: connector
>Affects Versions: 2.0.2, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2
>Reporter: Donald Woods
>Assignee: David Jencks
>Priority: Minor
> Fix For: 2.1.4, 2.2
>
>
> Can be accomplished once patch is provided in TRANQL-10 and a new connector 
> released by TranQL team.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-4523) Security Realm based Group-Role Mapping

[David Jencks (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks closed GERONIMO-4523.
--

   Resolution: Fixed
Fix Version/s: 2.2

I don't think anything more on this will get done.

> Security Realm based Group-Role Mapping
> ---
>
> Key: GERONIMO-4523
> URL: https://issues.apache.org/jira/browse/GERONIMO-4523
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: security
>Reporter: Jürgen Weber
>Assignee: David Jencks
> Fix For: 2.2
>
>
> For secured applications you currently need a Geronimo-specific deployment 
> plan which defines among others a mapping of realm groups onto JEE roles. 
> This goes against the spirit of EJB3 which replaces deployment descriptors 
> with annotations.
> It would be desirable to be able to run a standard-conforming JEE application 
> under container security without the need for Geronimo-specific deployment 
> plans.
> But this raises the need of another mean to specify Group-Role Mapping. I 
> suggest that this can be specified at the security-realm level. A realm 
> should be linked to a mapping (n:1 mapping, several realms should potentially 
> use the same mapping). There should be a default identity mapping, if you 
> have several thousands of users in LDAP.
> Mappings should be definable via console.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (GERONIMO-4554) Cant deploy an ejb web service as a plugin using car-maven-plugin

[Jarek Gawor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor resolved GERONIMO-4554.
---

Resolution: Fixed

Committed a set of changes that do not rely on config substitution properties 
to discover the web container to trunk (revision 750189) and branches/2.1 
(revision 750233).


> Cant deploy an ejb web service as a plugin using car-maven-plugin
> -
>
> Key: GERONIMO-4554
> URL: https://issues.apache.org/jira/browse/GERONIMO-4554
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: car-maven-plugin
>Affects Versions: 2.1.3
>Reporter: David Jencks
>Assignee: Jarek Gawor
> Fix For: 2.1.4, 2.2
>
>
> I tried to deploy an ejb web service using the car-maven-plugin.  The cxf and 
> axis2 ejb deployers set up the wslink gbean with a reference to the web 
> container.  This is set in the plan for the deployers as "WebContainer" but 
> the geronimo-plugin.xml overrides this to "${webContainer}".  The jetty and 
> tomcat plugins use a config-substitutions entry to e.g. set 
> webContainer=JettyWebContainer
> So, this all works on a server where all the plugins are installed.  However 
> it doesn't work when using the car-maven-plugin since the config.xml 
> overrides and config-substitutions are not applied.
> We need to either make the config modifications work for the car-maven-plugin 
> or make sure none of the deployers the car-maven-plugin might use depend on 
> these customizations to work.  For instance, we could change all the names to 
> WebContainer. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

private repo files and apache headers

[Joe Bohn]

Should we include apache license headers in the poms and README that we 
provide for the private builds in our repository?


Joe

Re: svn commit: r700193 - in /geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main: java/org/apache/geronimo/console/internaldb/ resources/ webapp/WEB-INF/view/internaldb/

[David Jencks]

On Mar 4, 2009, at 12:52 PM, Joe Bohn wrote:



I know this is going way back in time ... but any idea why this  
change deleted the content of dbViewerMaximized.jsp but kept the  
empty file around?


That's easy to do when you run patch -p0 which can empty files but not  
run svn rm on them.



I discovered this when checking for source headers.  This file is  
flagged because it doesn't contain a header - but more than that it  
doesn't contain anything at all.


I presume we can delete the entire file.  Does anybody know of any  
reason why we should not do this?


There are a few other instances of similar files that we need to  
deal with as well.


I expect the *Maximized.jsp were never referenced and the patch author  
deleted them but did not succeed in conveying the need to run svn rm  
to the patch applier.


thanks
david jencks




Joe

dwo...@apache.org wrote:

Author: dwoods
Date: Mon Sep 29 11:09:17 2008
New Revision: 700193
URL: http://svn.apache.org/viewvc?rev=700193&view=rev
Log:
GERONIMO-4225 Allow Run SQL portlet run sql against any configured  
data source.  Thanks to Michal Borowiecki for the patch.

Added:
   geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/webapp/WEB-INF/view/internaldb/ 
listDatabasesMaximized.jsp   (with props)
   geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/webapp/WEB-INF/view/internaldb/ 
listTablesMaximized.jsp   (with props)
   geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/webapp/WEB-INF/view/internaldb/ 
viewTableContentsMaximized.jsp   (with props)

Modified:
   geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/java/org/apache/geronimo/console/internaldb/ 
DBViewerHelper.java
   geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/java/org/apache/geronimo/console/internaldb/ 
DBViewerPortlet.java
   geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/java/org/apache/geronimo/console/internaldb/ 
DerbyConnectionUtil.java
   geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/java/org/apache/geronimo/console/internaldb/ 
RunSQLHelper.java
   geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/java/org/apache/geronimo/console/internaldb/ 
RunSQLPortlet.java
   geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/resources/systemdatabase.properties
   geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/webapp/WEB-INF/view/internaldb/ 
dbViewerMaximized.jsp
   geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/webapp/WEB-INF/view/internaldb/runSQLNormal.jsp
Modified: geronimo/server/branches/2.1/plugins/system-database/ 
sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/ 
DBViewerHelper.java

URL: 
http://svn.apache.org/viewvc/geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java?rev=700193&r1=700192&r2=700193&view=diff
= 
= 
= 
= 
= 
= 
= 
= 
= 
=
--- geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/java/org/apache/geronimo/console/internaldb/ 
DBViewerHelper.java (original)
+++ geronimo/server/branches/2.1/plugins/system-database/sysdb- 
portlets/src/main/java/org/apache/geronimo/console/internaldb/ 
DBViewerHelper.java Mon Sep 29 11:09:17 2008

@@ -18,9 +18,20 @@
package org.apache.geronimo.console.internaldb;
 import java.io.File;
+import java.util.ArrayList;
import java.util.Collection;
+import java.util.List;
import java.util.Vector;
+import org.apache.geronimo.console.util.KernelManagementHelper;
+import org.apache.geronimo.console.util.ManagementHelper;
+import org.apache.geronimo.console.util.PortletManager;
+import org.apache.geronimo.gbean.AbstractName;
+import org.apache.geronimo.j2ee.j2eeobjectnames.NameFactory;
+import org.apache.geronimo.kernel.Kernel;
+import org.apache.geronimo.kernel.KernelRegistry;
+import  
org.apache.geronimo.management.geronimo.ResourceAdapterModule;

+
public class DBViewerHelper {
 private static final String SYS_TBL_PREFIX = "SYS.";
@@ -28,6 +39,34 @@
private static final int COUNT_COL = 1;
 /**
+ * List the databases having datasources deployed.
+ *
+ * @param derbySysHome
+ * @return
+ */
+public Collection getDataSourceNames() {
+   
+   List databaseNames = new ArrayList();
+
+Kernel kernel = KernelRegistry.getSingleKernel();
+ManagementHelper helper = new  
KernelManagementHelper(kernel);
+ResourceAdapterModule[] modules =  
helper.getOutboundRAModules(helper.getDomains() 
[0].getServerInstances()[0], "javax.sql.DataSource");

+for (ResourceAdapterModule module : modules) {
+ 
org 
.apache.geronimo.management.geronimo.JCA

[BUILD] trunk: Failed for Revision: 750107

[gawor]

Geronimo Revision: 750107 built with tests included
 
See the full build-1500.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/build-1500.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 37 minutes 16 seconds
[INFO] Finished at: Wed Mar 04 15:44:36 EST 2009
[INFO] Final Memory: 397M/1002M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/logs-1500-tomcat/test.log
 
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/logs-1500-jetty/test.log
 
 
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-jetty6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty6-javaee5/2.2-SNAPSHOT/geronimo-jetty6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:46.158
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO] 
[INFO] 
---
[INFO] 
[INFO] commands-testsuite/deploy  RUNNING
[INFO] commands-testsuite/deploy  SUCCESS (0:01:11.038) 
[INFO] commands-testsuite/gshell  RUNNING
[INFO] commands-testsuite/gshell  SUCCESS (0:00:30.497) 
[INFO] commands-testsuite/jaxws   RUNNING
[INFO] commands-testsuite/jaxws   SUCCESS (0:00:34.506) 
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.092) 
[INFO] concurrent-testsuite/concurrent-basic  RUNNING
[INFO] concurrent-testsuite/concurrent-basic  SUCCESS (0:06:06.510) 
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:00:16.875) Java 
returned: 1
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicFAILURE (0:00:18.150) Java 
returned: 1
[INFO] corba-testsuite/corba-helloworld   RUNNING
[INFO] corba-testsuite/corba-helloworld   SUCCESS (0:00:46.796) 
[INFO] corba-testsuite/corba-marshal  RUNNING
[INFO] corba-testsuite/corba-marshal  SUCCESS (0:01:02.903) 
[INFO] corba-testsuite/corba-mytime   RUNNING
[INFO] corba-testsuite/corba-mytime   SUCCESS (0:00:39.364) 
[INFO] deployment-testsuite/deployment-tests  RUNNING
[INFO] deployment-testsuite/deployment-tests  SUCCESS (0:00:30.710) 
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:30.649) 
[INFO] deployment-testsuite/manifestcp-tests  RUNNING
[INFO] deployment-testsuite/manifestcp-tests  SUCCESS (0:00:32.739) 
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:36.588) 
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:51.113) 
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:41.207) 
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:28.274) 
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.310) 
[INFO] security-testsuite/test-security   RUNNING
[INFO] security-testsuite/test-security   FAILURE (0:00:34.391) Java 
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:30.060) 
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00

Re: svn commit: r700193 - in /geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main: java/org/apache/geronimo/console/internaldb/ resources/ webapp/WEB-INF/view/internaldb/

[Joe Bohn]

I know this is going way back in time ... but any idea why this change 
deleted the content of dbViewerMaximized.jsp but kept the empty file 
around?


I discovered this when checking for source headers.  This file is 
flagged because it doesn't contain a header - but more than that it 
doesn't contain anything at all.


I presume we can delete the entire file.  Does anybody know of any 
reason why we should not do this?


There are a few other instances of similar files that we need to deal 
with as well.


Joe

dwo...@apache.org wrote:

Author: dwoods
Date: Mon Sep 29 11:09:17 2008
New Revision: 700193

URL: http://svn.apache.org/viewvc?rev=700193&view=rev
Log:
GERONIMO-4225 Allow Run SQL portlet run sql against any configured data source. 
 Thanks to Michal Borowiecki for the patch.

Added:

geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/webapp/WEB-INF/view/internaldb/listDatabasesMaximized.jsp
   (with props)

geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/webapp/WEB-INF/view/internaldb/listTablesMaximized.jsp
   (with props)

geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/webapp/WEB-INF/view/internaldb/viewTableContentsMaximized.jsp
   (with props)
Modified:

geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java

geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerPortlet.java

geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DerbyConnectionUtil.java

geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/RunSQLHelper.java

geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/RunSQLPortlet.java

geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/resources/systemdatabase.properties

geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/webapp/WEB-INF/view/internaldb/dbViewerMaximized.jsp

geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/webapp/WEB-INF/view/internaldb/runSQLNormal.jsp

Modified: 
geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java
URL: 
http://svn.apache.org/viewvc/geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java?rev=700193&r1=700192&r2=700193&view=diff
==
--- 
geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java
 (original)
+++ 
geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java
 Mon Sep 29 11:09:17 2008
@@ -18,9 +18,20 @@
 package org.apache.geronimo.console.internaldb;
 
 import java.io.File;

+import java.util.ArrayList;
 import java.util.Collection;
+import java.util.List;
 import java.util.Vector;
 
+import org.apache.geronimo.console.util.KernelManagementHelper;

+import org.apache.geronimo.console.util.ManagementHelper;
+import org.apache.geronimo.console.util.PortletManager;
+import org.apache.geronimo.gbean.AbstractName;
+import org.apache.geronimo.j2ee.j2eeobjectnames.NameFactory;
+import org.apache.geronimo.kernel.Kernel;
+import org.apache.geronimo.kernel.KernelRegistry;
+import org.apache.geronimo.management.geronimo.ResourceAdapterModule;
+
 public class DBViewerHelper {
 
 private static final String SYS_TBL_PREFIX = "SYS.";

@@ -28,6 +39,34 @@
 private static final int COUNT_COL = 1;
 
 /**

+ * List the databases having datasources deployed.
+ *
+ * @param derbySysHome
+ * @return
+ */
+public Collection getDataSourceNames() {
+   
+   List databaseNames = new ArrayList();
+
+Kernel kernel = KernelRegistry.getSingleKernel();
+ManagementHelper helper = new KernelManagementHelper(kernel);
+ResourceAdapterModule[] modules = 
helper.getOutboundRAModules(helper.getDomains()[0].getServerInstances()[0], 
"javax.sql.DataSource");
+for (ResourceAdapterModule module : modules) {
+org.apache.geronimo.management.geronimo.JCAManagedConnectionFactory[] 
databases = helper.getOutboundFactories(module, "javax.sql.DataSource");
+for 
(org.apache.geronimo.management.geronimo.JCAManagedConnectionFactory db : 
databases) {
+try {
+AbstractName dbName = kernel.getAbstractNameFor(db);
+String datasourceName = 
(String)dbName.getName().get(

[jira] Closed: (GERONIMO-4538) Make framework self contained to build the framework server

[David Jencks (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks closed GERONIMO-4538.
--

Resolution: Fixed

Doesn't seem to break anything.

> Make framework self contained to build the framework server
> ---
>
> Key: GERONIMO-4538
> URL: https://issues.apache.org/jira/browse/GERONIMO-4538
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Affects Versions: 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2
>
>
> Make everything needed to build the framework server be in framework.  This 
> should make it a lot easier to experiment with the framework server because 
> you have a lot less to build.
> It should have its own testsuite, although that may be added later.
> I don't plan to change any groupIds or artifactIds immediately although some 
> should probably be modified slightly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-4569) Built sample plugin by using new tomcat6-deployer cannot be installed on server

[David Jencks (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks closed GERONIMO-4569.
--

Resolution: Fixed

I reverted my changes from the other bug.  In the future please do not 
proliferate bugs reports for the same issue but just attach comments to the 
original issue.

> Built sample plugin by using new tomcat6-deployer cannot be installed on 
> server
> ---
>
> Key: GERONIMO-4569
> URL: https://issues.apache.org/jira/browse/GERONIMO-4569
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Plugins
>Affects Versions: 2.1.4
>Reporter: Forrest Xia
>Assignee: David Jencks
>Priority: Critical
>
> Recently, when I am building some 2.1 branch samples plugins, I found that 
> built sample plugins are all not installable.
> A message on admin console like this:
> "A problem has occured:
> org.apache.geronimo.kernel.config.LifecycleException: start of 
> org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed"
> An exception in stdout/stderr like this:
> "Caused by:
> org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve 
> reference "Container" in gbean
> org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT
>  to a gbean matching the pattern [?name=WebContainer#]
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)"
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4566) Need extra servlet mappings for jetty for welcome jsps compiled into servlets

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678870#action_12678870
 ] 

David Jencks commented on GERONIMO-4566:


re-included the jsps since jetty may not fix this soon and the servlet mapping 
doesn't seem to actually work reliably.  rev 750118.

> Need extra servlet mappings for jetty for welcome jsps compiled into servlets
> -
>
> Key: GERONIMO-4566
> URL: https://issues.apache.org/jira/browse/GERONIMO-4566
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: David Jencks
>Assignee: David Jencks
>
> See http://jira.codehaus.org/browse/JETTY-936.  We need to include at least a 
> servlet mapping something like:
> 
> jsp.index_jsp
> /
> 
> until jetty fixes the default servlet.
> This showed up because I deleted the uncompiled jsps.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4549) JMS resource jndi entries are not removed after uninstalling the JMS connect adapter

[Joe Bohn (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678864#action_12678864
 ] 

Joe Bohn commented on GERONIMO-4549:


Perhaps I don't fully understand the problem ... but I attempted to recreate it 
and in my case the jndi entry was removed.  

I did the following:
- selected Services->JMS Resources from the navigation
- created a new resource group for ActiveMQ as follows:
- specified a group of myRG and kept the defaults for all else
- created a new connection factory under the Resource Group called 
myFactory and kept the defaults for all else
- deployed the plan
- validated that the resource group was running and visible in the JMS 
Resources view, the J2EE Connectors view (and running) and the JNDI viewer 
under ResourceAdapterModule
- from the J2EE Connectors view I uninstalled my resource group rar
- It was removed from the J2EE Connectors view, the JMS Resources view, and the 
JNDI Viewer 

Am I completely missing the issue?

> JMS resource jndi entries are not removed after uninstalling the JMS connect 
> adapter
> 
>
> Key: GERONIMO-4549
> URL: https://issues.apache.org/jira/browse/GERONIMO-4549
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: ActiveMQ
>Affects Versions: 2.1.4
>Reporter: Forrest Xia
>Priority: Blocker
> Fix For: 2.1.4, 2.2
>
>
> Steps to reproduce this problem:
> 1. login admin console
> 2. Create a ActiveMQ resource connector with the wizard
> 3. Deploy it and check it is in running state
> 4. Click J2EE connector to uninstall it
> 5. Check JNDI viewer, you will see the JNDI entry still there, even you've 
> uninstalled it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Cron /home/jdillon/ws/site/bin/sync

[Lin Sun]

Joe, I am very sure that I did that step, as I still have the terminal
window from yesterday pm -

Play nice.  -- ASF Infrastructure (infrastruct...@apache.org)
[lin...@minotaur ~]$ chgrp -R geronimo public_html/staging-site/txmanager
[lin...@minotaur ~]$ pwd
/home/linsun
[lin...@minotaur ~]$ chmod -R g+w public_html/staging-site/txmanager
[lin...@minotaur ~]$ ls public_html/staging-site/txmanager
2.1.2
[lin...@minotaur ~]$ cp -r public_html/staging-site/txmanager
/www/geronimo.apache.org/maven

I also found out that the two directories have different permission
after the cp command:
drwxrwxr-x  public_html/staging-site/txmanager
drwxr-xr-x   /www/geronimo.apache.org/maven/txmanager

Maybe it worked on your machine but I had to have the last step.

Lin

On Wed, Mar 4, 2009 at 1:46 PM, Joe Bohn  wrote:
>
> Lin,
>
> The new step you added (after the copy) should not be necessary if you had
> performed the step immediately prior to the copy (chmod -R g+w
> public_html/staging-site/[siteId]).  Are you sure you didn't just skip that
> step by mistake?
>
> Regards,
> Joe
> - Show quoted text -
>
>
>
> Lin Sun wrote:
>>
>> I hope I resolved this..   I also updated the component release wiki
>> page for the step I missed.
>>
>> Thanks.
>>
>> Lin
>>
>> On Wed, Mar 4, 2009 at 9:15 AM, Jason Dillon  wrote:
>>>
>>> Some permission problems...
>>> --jason
>>>
>>> Begin forwarded message:
>>>
>>> From: jdil...@apache.org (Cron Daemon)
>>> Date: March 4, 2009 9:08:11 PM GMT+07:00
>>> To: jdil...@apache.org
>>> Subject: Cron  /home/jdillon/ws/site/bin/sync
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/logos/maven-feather.png:
>>> Operation not permitted
>>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/logos:
>>> Operation not permitted
>>> chmod:
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/external.png:
>>> Operation not permitted
>>> chmod:
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_error_sml.gif:
>>> Operation not permitted
>>> chmod:
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_info_sml.gif:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_success_sml.gif:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_warning_sml.gif:
>>> Operation not permitted
>>> chmod:
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/newwindow.png:
>>> Operation not permitted
>>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/spacer.gif:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/top_bgstretch_1x64.gif:
>>> Operation not permitted
>>> chmod:
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/border_bottom.gif:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/topleft_logo_437x64.gif:
>>> Operation not permitted
>>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images: Operation
>>> not
>>> permitted
>>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/css/maven-base.css:
>>> Operation not permitted
>>> chmod:
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/css/maven-theme.css:
>>> Operation not permitted
>>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/css/print.css:
>>> Operation not permitted
>>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/css: Operation not
>>> permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/logos/maven-feather.png:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/logos:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/external.png:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_error_sml.gif:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_info_sml.gif:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_success_sml.gif:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_warning_sml.gif:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/newwindow.png:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/spacer.gif:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/top_bgstretch_1x64.gif:
>>> Operation not permitted
>>> chmod:
>>>
>>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/border_bottom.gif:
>>> Operatio

[jira] Assigned: (GERONIMO-4554) Cant deploy an ejb web service as a plugin using car-maven-plugin

[Jarek Gawor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor reassigned GERONIMO-4554:
-

Assignee: Jarek Gawor  (was: David Jencks)

> Cant deploy an ejb web service as a plugin using car-maven-plugin
> -
>
> Key: GERONIMO-4554
> URL: https://issues.apache.org/jira/browse/GERONIMO-4554
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: car-maven-plugin
>Affects Versions: 2.1.3
>Reporter: David Jencks
>Assignee: Jarek Gawor
> Fix For: 2.1.4, 2.2
>
>
> I tried to deploy an ejb web service using the car-maven-plugin.  The cxf and 
> axis2 ejb deployers set up the wslink gbean with a reference to the web 
> container.  This is set in the plan for the deployers as "WebContainer" but 
> the geronimo-plugin.xml overrides this to "${webContainer}".  The jetty and 
> tomcat plugins use a config-substitutions entry to e.g. set 
> webContainer=JettyWebContainer
> So, this all works on a server where all the plugins are installed.  However 
> it doesn't work when using the car-maven-plugin since the config.xml 
> overrides and config-substitutions are not applied.
> We need to either make the config modifications work for the car-maven-plugin 
> or make sure none of the deployers the car-maven-plugin might use depend on 
> these customizations to work.  For instance, we could change all the names to 
> WebContainer. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3907) Persistence Exception is not visible/lost for client.

[Joe Bohn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joe Bohn updated GERONIMO-3907:
---

Priority: Minor  (was: Blocker)

I have updated the status of this problem to "minor" from "blocker" because it 
appears that the original issue (no error returned) has been resolved.  The 
remaining issue seems to be the detail of the error reported.   Are there any 
additional enhancements planned for this JIRA in this area?  If not, we should 
close this issue.  Actually, since the core problem has been resolved we should 
perhaps close the issue and open a new issue requesting the enhancement.  If 
there are no additional enhancements planned for Geronimo 2.1.4 we should 
remove it from the fix versions.  It appears that the original problem was 
fixed in 2.1.1.

> Persistence Exception is not visible/lost for client. 
> --
>
> Key: GERONIMO-3907
> URL: https://issues.apache.org/jira/browse/GERONIMO-3907
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: persistence
>Affects Versions: 2.0.2, 2.1
> Environment: Linux, Windows
>Reporter: Ralf Baumhof
>Assignee: David Jencks
>Priority: Minor
> Fix For: 2.1.4, 2.2
>
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> I am trying an insert on a table. The Entity class is wrong annotated, one 
> column was renamed in the table. Then the following situation occurs.  
> The call to persist(entity) is successfully, no exception is thrown. On 
> leaving the ejb container and returning to tomact a commit is performed (it's 
> a managed datasource, so container performs commit). This leads to the insert 
> on database. This insert fails, a rollback is performed. On return to the JSF 
> bean no exception can be seen by the bean. In the same class i have got a 
> query method. If i replace the call to persist with the call to the query 
> method everything works ok. The exception is thrown and is visible at the 
> client site. 
> This is the geronimo console output. The last line comes from the JSB bean 
> which reports a successful insert.
> 11:58:04,390 WARN  [Transaction] Unexpected exception from beforeCompletion; 
> transaction will roll back
>  
> org.apache.openjpa.persistence.PersistenceException: The transaction has been 
> rolled back.  See the nested exceptions for details on the errors that 
> occurred.
> at 
> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107)
> at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954)
> at 
> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852)
> at 
> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770)
> at 
> org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514)
> at 
> org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499)
> at 
> org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400)
> at 
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257)
> at 
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245)
> at 
> org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141)
> at 
> org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75)
> at 
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233)
> at 
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
> at 
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
> at 
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217)
> at 
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
> at 
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321)
> at 
> org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
> at $Proxy75.anlegenBenutzer(Unknown Source)
> at 
> de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
>

[jira] Commented: (GERONIMO-4554) Cant deploy an ejb web service as a plugin using car-maven-plugin

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678799#action_12678799
 ] 

David Jencks commented on GERONIMO-4554:


Reverted changes from rev 748420 and 748924 in rev 750081

My next idea to fix this is to give the ejb web service deployers sets of 
abstract name queries so they can find either the jetty or tomcat web 
container.  You won't be able to run both jetty and tomcat on the same server 
if you have ejb web services, but I dont think that is a major limitation.

> Cant deploy an ejb web service as a plugin using car-maven-plugin
> -
>
> Key: GERONIMO-4554
> URL: https://issues.apache.org/jira/browse/GERONIMO-4554
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: car-maven-plugin
>Affects Versions: 2.1.3
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.1.4, 2.2
>
>
> I tried to deploy an ejb web service using the car-maven-plugin.  The cxf and 
> axis2 ejb deployers set up the wslink gbean with a reference to the web 
> container.  This is set in the plan for the deployers as "WebContainer" but 
> the geronimo-plugin.xml overrides this to "${webContainer}".  The jetty and 
> tomcat plugins use a config-substitutions entry to e.g. set 
> webContainer=JettyWebContainer
> So, this all works on a server where all the plugins are installed.  However 
> it doesn't work when using the car-maven-plugin since the config.xml 
> overrides and config-substitutions are not applied.
> We need to either make the config modifications work for the car-maven-plugin 
> or make sure none of the deployers the car-maven-plugin might use depend on 
> these customizations to work.  For instance, we could change all the names to 
> WebContainer. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?

[Joe Bohn]

+1.  I agree that would be an acceptable limitation.

Joe

David Jencks wrote:


On Mar 4, 2009, at 8:39 AM, Joe Bohn wrote:



Forrest,  Thanks for finding this problem and raising the issue.

IMO this is a critical issue that breaks backward compatibility.

I had validated that our 2.1.2 samples installed and worked in our 
2.1.4 server image prior to this change.  Since this change has been 
made this is no longer true.  I suspect this will also break other 
component installations (such as directory) and perhaps user created 
components.


We need another solution that support backward compatibility.


I guess we need to revert my attempt to fix the original problem.  Maybe 
we can change the ejb-webservice deployers to use two abstract name 
queries that will pick up either the jetty or tomcat web container.  
That would only prevent people from running both jetty and tomcat at 
once if they have ejb web services maybe not a serious limitation.


david jencks




Joe


Jarek Gawor wrote:

Please see https://issues.apache.org/jira/browse/GERONIMO-4554.
Jarek
On Wed, Mar 4, 2009 at 11:14 AM, Forrest_Xia  
wrote:
Recently, when I am building some 2.1 branch samples plugins, I 
found that

built sample plugins are all not installable.
A message on admin console like this:
"A problem has occured:
org.apache.geronimo.kernel.config.LifecycleException: start of
org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car 
failed"


An exception in stdout/stderr like this:
"Caused by:
org.apache.geronimo.kernel.config.InvalidConfigException: Unable to 
resolve

reference "Container" in gbean
org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT 


to a gbean matching the pattern [?name=WebContainer#]
  at
org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380) 


  at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438) 


  at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) 


  at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)" 



After some research, I found someone changed tomcat6-deployer plugin
deployment plan, changed "TomcatWebBuilder" GBean's attribute
"tomcatContainerName" value from "?name=TomcatWebContainer" to
"?name=WebContainer", why did that?

However, I think that's the reason causing the built plugins 
uninstallable.


Please help review and see if it is a bug before 2.1.4 release. Thanks!

Forrest

--
View this message in context: 
http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333212.html 


Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.

Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?

[Kevan Miller]

On Mar 4, 2009, at 11:50 AM, David Jencks wrote:



On Mar 4, 2009, at 8:39 AM, Joe Bohn wrote:



Forrest,  Thanks for finding this problem and raising the issue.

IMO this is a critical issue that breaks backward compatibility.

I had validated that our 2.1.2 samples installed and worked in our  
2.1.4 server image prior to this change.  Since this change has  
been made this is no longer true.  I suspect this will also break  
other component installations (such as directory) and perhaps user  
created components.


We need another solution that support backward compatibility.


I guess we need to revert my attempt to fix the original problem.   
Maybe we can change the ejb-webservice deployers to use two abstract  
name queries that will pick up either the jetty or tomcat web  
container.  That would only prevent people from running both jetty  
and tomcat at once if they have ejb web services maybe not a  
serious limitation.


I'd agree that would not be a serious limitation.

--kevan

Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?

[David Jencks]

On Mar 4, 2009, at 8:39 AM, Joe Bohn wrote:



Forrest,  Thanks for finding this problem and raising the issue.

IMO this is a critical issue that breaks backward compatibility.

I had validated that our 2.1.2 samples installed and worked in our  
2.1.4 server image prior to this change.  Since this change has been  
made this is no longer true.  I suspect this will also break other  
component installations (such as directory) and perhaps user created  
components.


We need another solution that support backward compatibility.


I guess we need to revert my attempt to fix the original problem.   
Maybe we can change the ejb-webservice deployers to use two abstract  
name queries that will pick up either the jetty or tomcat web  
container.  That would only prevent people from running both jetty and  
tomcat at once if they have ejb web services maybe not a serious  
limitation.


david jencks




Joe


Jarek Gawor wrote:

Please see https://issues.apache.org/jira/browse/GERONIMO-4554.
Jarek
On Wed, Mar 4, 2009 at 11:14 AM, Forrest_Xia   
wrote:
Recently, when I am building some 2.1 branch samples plugins, I  
found that

built sample plugins are all not installable.
A message on admin console like this:
"A problem has occured:
org.apache.geronimo.kernel.config.LifecycleException: start of
org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car  
failed"


An exception in stdout/stderr like this:
"Caused by:
org.apache.geronimo.kernel.config.InvalidConfigException: Unable  
to resolve

reference "Container" in gbean
org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car? 
J2EEApplication 
=null,j2eeType=WebModule,name=org.apache.geronimo.samples/ 
calculator-tomcat/2.1.3-SNAPSHOT

to a gbean matching the pattern [?name=WebContainer#]
  at
org 
.apache 
.geronimo 
.kernel 
.config 
.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380)

  at
org 
.apache 
.geronimo 
.kernel 
.config 
.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java: 
438)

  at
org 
.apache 
.geronimo 
.kernel 
.config 
.KernelConfigurationManager.start(KernelConfigurationManager.java: 
188)

  at
org 
.apache 
.geronimo 
.kernel 
.config 
.SimpleConfigurationManager 
.startConfiguration(SimpleConfigurationManager.java:562)"


After some research, I found someone changed tomcat6-deployer plugin
deployment plan, changed "TomcatWebBuilder" GBean's attribute
"tomcatContainerName" value from "?name=TomcatWebContainer" to
"?name=WebContainer", why did that?

However, I think that's the reason causing the built plugins  
uninstallable.


Please help review and see if it is a bug before 2.1.4 release.  
Thanks!


Forrest

--
View this message in context: 
http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333212.html
Sent from the Apache Geronimo - Dev mailing list archive at  
Nabble.com.

Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?

[Forrest_Xia]

Opened a defect https://issues.apache.org/jira/browse/GERONIMO-4569

Forrest

Forrest_Xia wrote:
> 
> I think this change bring another defect, that is built sample plugin
> which uses tomcat6-deployer won't be able to install on the server.
> 
> Please check. thanks!
> 
> Forrest
> 

-- 
View this message in context: 
http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22334092.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.

[jira] Created: (GERONIMO-4569) Built sample plugin by using new tomcat6-deployer cannot be installed on server

[Forrest Xia (JIRA)]

Built sample plugin by using new tomcat6-deployer cannot be installed on server
---

 Key: GERONIMO-4569
 URL: https://issues.apache.org/jira/browse/GERONIMO-4569
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Plugins
Affects Versions: 2.1.4
Reporter: Forrest Xia
Assignee: David Jencks
Priority: Critical


Recently, when I am building some 2.1 branch samples plugins, I found that 
built sample plugins are all not installable.
A message on admin console like this:
"A problem has occured:
org.apache.geronimo.kernel.config.LifecycleException: start of 
org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed"

An exception in stdout/stderr like this:
"Caused by:
org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve 
reference "Container" in gbean
org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT
 to a gbean matching the pattern [?name=WebContainer#]
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380)
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)"
 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4554) Cant deploy an ejb web service as a plugin using car-maven-plugin

[Joe Bohn (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678780#action_12678780
 ] 

Joe Bohn commented on GERONIMO-4554:


I agree with Forrest.  This breaks backward compatibility and as such is not an 
acceptable change.


> Cant deploy an ejb web service as a plugin using car-maven-plugin
> -
>
> Key: GERONIMO-4554
> URL: https://issues.apache.org/jira/browse/GERONIMO-4554
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: car-maven-plugin
>Affects Versions: 2.1.3
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.1.4, 2.2
>
>
> I tried to deploy an ejb web service using the car-maven-plugin.  The cxf and 
> axis2 ejb deployers set up the wslink gbean with a reference to the web 
> container.  This is set in the plan for the deployers as "WebContainer" but 
> the geronimo-plugin.xml overrides this to "${webContainer}".  The jetty and 
> tomcat plugins use a config-substitutions entry to e.g. set 
> webContainer=JettyWebContainer
> So, this all works on a server where all the plugins are installed.  However 
> it doesn't work when using the car-maven-plugin since the config.xml 
> overrides and config-substitutions are not applied.
> We need to either make the config modifications work for the car-maven-plugin 
> or make sure none of the deployers the car-maven-plugin might use depend on 
> these customizations to work.  For instance, we could change all the names to 
> WebContainer. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?

[Forrest_Xia]

I think this change bring another defect, that is built sample plugin which
uses tomcat6-deployer won't be able to install on the server.

Please check. thanks!

Forrest
-- 
View this message in context: 
http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333917.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.

Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?

[Joe Bohn]

Forrest,  Thanks for finding this problem and raising the issue.

IMO this is a critical issue that breaks backward compatibility.

I had validated that our 2.1.2 samples installed and worked in our 2.1.4 
server image prior to this change.  Since this change has been made this 
is no longer true.  I suspect this will also break other component 
installations (such as directory) and perhaps user created components.


We need another solution that support backward compatibility.

Joe


Jarek Gawor wrote:

Please see https://issues.apache.org/jira/browse/GERONIMO-4554.

Jarek

On Wed, Mar 4, 2009 at 11:14 AM, Forrest_Xia  wrote:

Recently, when I am building some 2.1 branch samples plugins, I found that
built sample plugins are all not installable.
A message on admin console like this:
"A problem has occured:
org.apache.geronimo.kernel.config.LifecycleException: start of
org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed"

An exception in stdout/stderr like this:
"Caused by:
org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve
reference "Container" in gbean
org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT
to a gbean matching the pattern [?name=WebContainer#]
   at
org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380)
   at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438)
   at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
   at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)"

After some research, I found someone changed tomcat6-deployer plugin
deployment plan, changed "TomcatWebBuilder" GBean's attribute
"tomcatContainerName" value from "?name=TomcatWebContainer" to
"?name=WebContainer", why did that?

However, I think that's the reason causing the built plugins uninstallable.

Please help review and see if it is a bug before 2.1.4 release. Thanks!

Forrest

--
View this message in context: 
http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333212.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.

[jira] Commented: (GERONIMO-4554) Cant deploy an ejb web service as a plugin using car-maven-plugin

[Forrest Xia (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678776#action_12678776
 ] 

Forrest Xia commented on GERONIMO-4554:
---

I think these changes will make built server plugins which uses 
tomcat6-deployer failed to install on server. 

For details, please see 
http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--td22333212s134.html.

Forrest

> Cant deploy an ejb web service as a plugin using car-maven-plugin
> -
>
> Key: GERONIMO-4554
> URL: https://issues.apache.org/jira/browse/GERONIMO-4554
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: car-maven-plugin
>Affects Versions: 2.1.3
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.1.4, 2.2
>
>
> I tried to deploy an ejb web service using the car-maven-plugin.  The cxf and 
> axis2 ejb deployers set up the wslink gbean with a reference to the web 
> container.  This is set in the plan for the deployers as "WebContainer" but 
> the geronimo-plugin.xml overrides this to "${webContainer}".  The jetty and 
> tomcat plugins use a config-substitutions entry to e.g. set 
> webContainer=JettyWebContainer
> So, this all works on a server where all the plugins are installed.  However 
> it doesn't work when using the car-maven-plugin since the config.xml 
> overrides and config-substitutions are not applied.
> We need to either make the config modifications work for the car-maven-plugin 
> or make sure none of the deployers the car-maven-plugin might use depend on 
> these customizations to work.  For instance, we could change all the names to 
> WebContainer. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?

[Jarek Gawor]

Please see https://issues.apache.org/jira/browse/GERONIMO-4554.

Jarek

On Wed, Mar 4, 2009 at 11:14 AM, Forrest_Xia  wrote:
>
> Recently, when I am building some 2.1 branch samples plugins, I found that
> built sample plugins are all not installable.
> A message on admin console like this:
> "A problem has occured:
> org.apache.geronimo.kernel.config.LifecycleException: start of
> org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed"
>
> An exception in stdout/stderr like this:
> "Caused by:
> org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve
> reference "Container" in gbean
> org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT
> to a gbean matching the pattern [?name=WebContainer#]
>        at
> org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380)
>        at
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438)
>        at
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
>        at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)"
>
> After some research, I found someone changed tomcat6-deployer plugin
> deployment plan, changed "TomcatWebBuilder" GBean's attribute
> "tomcatContainerName" value from "?name=TomcatWebContainer" to
> "?name=WebContainer", why did that?
>
> However, I think that's the reason causing the built plugins uninstallable.
>
> Please help review and see if it is a bug before 2.1.4 release. Thanks!
>
> Forrest
>
> --
> View this message in context: 
> http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333212.html
> Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
>
>

Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?

[Forrest_Xia]

Recently, when I am building some 2.1 branch samples plugins, I found that
built sample plugins are all not installable. 
A message on admin console like this:
"A problem has occured:
org.apache.geronimo.kernel.config.LifecycleException: start of
org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed"

An exception in stdout/stderr like this:
"Caused by: 
org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve
reference "Container" in gbean
org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT
to a gbean matching the pattern [?name=WebContainer#]
at
org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)"

After some research, I found someone changed tomcat6-deployer plugin
deployment plan, changed "TomcatWebBuilder" GBean's attribute
"tomcatContainerName" value from "?name=TomcatWebContainer" to
"?name=WebContainer", why did that?

However, I think that's the reason causing the built plugins uninstallable. 

Please help review and see if it is a bug before 2.1.4 release. Thanks!

Forrest

-- 
View this message in context: 
http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333212.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.

[jira] Issue Comment Edited: (GERONIMO-4549) JMS resource jndi entries are not removed after uninstalling the JMS connect adapter

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678767#action_12678767
 ] 

caijunj edited comment on GERONIMO-4549 at 3/4/09 8:10 AM:


So I spend more time to understand the code. Guess I now know the reason why 
Context A is chosen that way (to quickly remove a chain of subcontext which 
only contains the object to be removed). But I still don't get why 
removeNotEmptyContext is set to false in 
org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding().

I propose 2 fixes as - 

1. Update 
org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding(),
 new code below (change false to removeNotEmptyContext)
{code}
protected boolean removeBinding(String name, boolean 
removeNotEmptyContext) throws NamingException {
if (WritableContext.this.removeBinding(bindingsRef, name, 
removeNotEmptyContext)) {
return true;
}
return super.removeBinding(name, removeNotEmptyContext);
}
{code}

2. Update the 
org.apache.xbean.naming.context.AbstractContext.removeDeepBinding() to remove 
the chain of subcontexts one by one starting from the leaf subcontexts, so that 
each subcontext IS empty when being removed and can thus be removed 
successfully even if removeNotEmptyContext is set to false.

Any comments? I'll submit the patch tomorrow. But I'd like to get some advice 
beforehands.


  was (Author: caijunj):
So I spend more time to understand the code. Guess I now know the reason 
why Context A is chosen that way (to quickly remove a chain of subcontext which 
only contains the object to be removed). But I still don't get why 
removeNotEmptyContext is set to false in 
org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding().

I propose 2 fixes as - 

1. Update 
org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding(),
 new code below (change false to removeNotEmptyContext)
{code}
protected boolean removeBinding(String name, boolean 
removeNotEmptyContext) throws NamingException {
if (WritableContext.this.removeBinding(bindingsRef, name, 
removeNotEmptyContext)) {
return true;
}
return super.removeBinding(name, removeNotEmptyContext);
}
{/code}

2. Update the 
org.apache.xbean.naming.context.AbstractContext.removeDeepBinding() to remove 
the chain of subcontexts one by one starting from the leaf subcontexts, so that 
each subcontext IS empty when being removed and can thus be removed 
successfully even if removeNotEmptyContext is set to false.

Any comments? I'll submit the patch tomorrow. But I'd like to get some advice 
beforehands.

  
> JMS resource jndi entries are not removed after uninstalling the JMS connect 
> adapter
> 
>
> Key: GERONIMO-4549
> URL: https://issues.apache.org/jira/browse/GERONIMO-4549
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: ActiveMQ
>Affects Versions: 2.1.4
>Reporter: Forrest Xia
>Priority: Blocker
> Fix For: 2.1.4, 2.2
>
>
> Steps to reproduce this problem:
> 1. login admin console
> 2. Create a ActiveMQ resource connector with the wizard
> 3. Deploy it and check it is in running state
> 4. Click J2EE connector to uninstall it
> 5. Check JNDI viewer, you will see the JNDI entry still there, even you've 
> uninstalled it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [NOTICE] Creating server/branches/2.1.4

[Jack Cai]

Since Donald has marked this JIRA [1] as a blocker, I'm keen to get it fixed
in 2.1.4. I have two ideas which I described in the JIRA comments. Can
anyone who are familiar with the xbean-naming code take a look? Thanks!

-Jack

[1] https://issues.apache.org/jira/browse/GERONIMO-4549

2009/3/4 Jarek Gawor 

> We discovered a problem in Axis2 1.3 that prevents web services with
> overloaded methods to be deployed correctly. I would like to include a
> fix for this problem in 2.1.4 and in order to do that I will need to
> create patched versions of some of the Axis2 artifacts. I hope that's
> ok with everybody. I should be able to get this done today if there
> are no objections.
>
> Btw, this problem was already fixed in the latest Axis2 code so it
> does not affect trunk.
>
> Thanks,
> Jarek
>
> On Tue, Feb 24, 2009 at 2:30 PM, Joe Bohn  wrote:
> > We're getting very close to a Geronimo 2.1.4 release.  I think it's
> nearly
> > time to create a branch to prepare for the release.
> >
> > So, I'm planning to create a branch on Thursday afternoon (2/26).
> >
> > Please carefully consider any changes in the branches/2.1 that might
> > destabilize things and consider holding off until after the branch.  I do
> > anticipate that there will continue to be bug fixes and other minor
> changes.
> >  Hopefully, we will be in a position to create a release candidate
> sometime
> > next week.
> >
> > Thanks,
> > Joe
> >
>

[jira] Commented: (GERONIMO-4549) JMS resource jndi entries are not removed after uninstalling the JMS connect adapter

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678767#action_12678767
 ] 

Jack Cai commented on GERONIMO-4549:


So I spend more time to understand the code. Guess I now know the reason why 
Context A is chosen that way (to quickly remove a chain of subcontext which 
only contains the object to be removed). But I still don't get why 
removeNotEmptyContext is set to false in 
org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding().

I propose 2 fixes as - 

1. Update 
org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding(),
 new code below (change false to removeNotEmptyContext)
{code}
protected boolean removeBinding(String name, boolean 
removeNotEmptyContext) throws NamingException {
if (WritableContext.this.removeBinding(bindingsRef, name, 
removeNotEmptyContext)) {
return true;
}
return super.removeBinding(name, removeNotEmptyContext);
}
{/code}

2. Update the 
org.apache.xbean.naming.context.AbstractContext.removeDeepBinding() to remove 
the chain of subcontexts one by one starting from the leaf subcontexts, so that 
each subcontext IS empty when being removed and can thus be removed 
successfully even if removeNotEmptyContext is set to false.

Any comments? I'll submit the patch tomorrow. But I'd like to get some advice 
beforehands.


> JMS resource jndi entries are not removed after uninstalling the JMS connect 
> adapter
> 
>
> Key: GERONIMO-4549
> URL: https://issues.apache.org/jira/browse/GERONIMO-4549
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: ActiveMQ
>Affects Versions: 2.1.4
>Reporter: Forrest Xia
>Priority: Blocker
> Fix For: 2.1.4, 2.2
>
>
> Steps to reproduce this problem:
> 1. login admin console
> 2. Create a ActiveMQ resource connector with the wizard
> 3. Deploy it and check it is in running state
> 4. Click J2EE connector to uninstall it
> 5. Check JNDI viewer, you will see the JNDI entry still there, even you've 
> uninstalled it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4544) Error occured when repeatedly create DB or records

[Jarek Gawor (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678762#action_12678762
 ] 

Jarek Gawor commented on GERONIMO-4544:
---

Yes, that makes sense. Sorry about missing that change. Added the 
conn.setAutoCommit(true) call to trunk (revision 750053) and branches/2.1 
(revision 750054).


> Error occured when repeatedly create DB or records
> --
>
> Key: GERONIMO-4544
> URL: https://issues.apache.org/jira/browse/GERONIMO-4544
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1.4
> Environment: JAVA5 + RHEL 5.3 (X86) + Firefox 3.0.5
>Reporter: lily seattle
>Assignee: Jarek Gawor
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4544-for2.1.patch, Geronimo-4544-forTrunk.patch
>
>
> steps:
> 1. login console
> 2. Click Embedded DB -> DB Manager. 
> 3. Filling the Create DB blank with TestDB, click Create.
> 4.Create a table using:
> CREATE TABLE CUSTOMER (
>   ID  INTEGER NOT NULL PRIMARY KEY,
>   NAMEVARCHAR(45),
>   BIRTHDATE   DATE,
>   SSS_NO  VARCHAR(25),
>   ADDRESS VARCHAR(60),
>   ANNUAL_SALARY   DOUBLE,
>   LOAN_AMOUNT DOUBLE
>   );
> 5. Insert a record:
> INSERT INTO CUSTOMER VALUES
> (001，'hi','02/19/2009','111','somewhere',100,150);
> Now, if create the same table again, or Insert the same record, errors will 
> occur. Also the Table can't be accessed
> any more.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[BUILD] trunk: Failed for Revision: 749996

[gawor]

Geronimo Revision: 749996 built with tests included
 
See the full build-0900.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/build-0900.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 41 minutes 23 seconds
[INFO] Finished at: Wed Mar 04 09:48:57 EST 2009
[INFO] Final Memory: 392M/955M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/logs-0900-tomcat/test.log
 
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/logs-0900-jetty/test.log
 
 
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty6-javaee5/2.2-SNAPSHOT/geronimo-jetty6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:44.871
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO] 
[INFO] 
---
[INFO] 
[INFO] commands-testsuite/deploy  RUNNING
[INFO] commands-testsuite/deploy  SUCCESS (0:01:09.680) 
[INFO] commands-testsuite/gshell  RUNNING
[INFO] commands-testsuite/gshell  SUCCESS (0:00:30.383) 
[INFO] commands-testsuite/jaxws   RUNNING
[INFO] commands-testsuite/jaxws   SUCCESS (0:00:35.195) 
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.009) 
[INFO] concurrent-testsuite/concurrent-basic  RUNNING
[INFO] concurrent-testsuite/concurrent-basic  SUCCESS (0:06:05.214) 
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:00:16.558) Java 
returned: 1
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicFAILURE (0:00:17.460) Java 
returned: 1
[INFO] corba-testsuite/corba-helloworld   RUNNING
[INFO] corba-testsuite/corba-helloworld   SUCCESS (0:00:48.711) 
[INFO] corba-testsuite/corba-marshal  RUNNING
[INFO] corba-testsuite/corba-marshal  SUCCESS (0:00:49.113) 
[INFO] corba-testsuite/corba-mytime   RUNNING
[INFO] corba-testsuite/corba-mytime   SUCCESS (0:00:39.815) 
[INFO] deployment-testsuite/deployment-tests  RUNNING
[INFO] deployment-testsuite/deployment-tests  SUCCESS (0:00:30.369) 
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:29.521) 
[INFO] deployment-testsuite/manifestcp-tests  RUNNING
[INFO] deployment-testsuite/manifestcp-tests  SUCCESS (0:00:32.146) 
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:35.711) 
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:51.497) 
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:40.495) 
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.202) 
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:47.145) 
[INFO] security-testsuite/test-security   RUNNING
[INFO] security-testsuite/test-security   FAILURE (0:00:34.679) Java 
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:29.497) 
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00:28.352) 
[INFO] web-testsuite/test-jetty   RUNNING
[INFO] web-testsuite/test-jetty

[jira] Updated: (GERONIMO-4507) Admin console should honor the priority of user agent's language setting

[Gang Yin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gang Yin updated GERONIMO-4507:
---

Attachment: locale-priority_fix2.patch

> Admin console should honor the priority of user agent's language setting
> 
>
> Key: GERONIMO-4507
> URL: https://issues.apache.org/jira/browse/GERONIMO-4507
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1.3, 2.2
> Environment: All
>Reporter: Jack Cai
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.1.4, 2.2
>
> Attachments: locale-priority.patch, locale-priority_fix.patch, 
> locale-priority_fix2.patch, locale-priority_V21.patch
>
>
> See discussion: 
> http://www.nabble.com/Geronimo-Console-tp21369352s134p21383628.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4507) Admin console should honor the priority of user agent's language setting

[Gang Yin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gang Yin updated GERONIMO-4507:
---

Attachment: (was: locale-priority_fix2.patch)

> Admin console should honor the priority of user agent's language setting
> 
>
> Key: GERONIMO-4507
> URL: https://issues.apache.org/jira/browse/GERONIMO-4507
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1.3, 2.2
> Environment: All
>Reporter: Jack Cai
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.1.4, 2.2
>
> Attachments: locale-priority.patch, locale-priority_fix.patch, 
> locale-priority_fix2.patch, locale-priority_V21.patch
>
>
> See discussion: 
> http://www.nabble.com/Geronimo-Console-tp21369352s134p21383628.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4550) No error message displays in console when fail to create jms resource

[Gang Yin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gang Yin updated GERONIMO-4550:
---

Attachment: fix-g4550-v22-jeffyin.patch

Patch for geronimo v2.2

> No error message displays in console when fail to create jms resource
> -
>
> Key: GERONIMO-4550
> URL: https://issues.apache.org/jira/browse/GERONIMO-4550
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1.4
> Environment: OS:redhat 5.2 JDK 1.5
>Reporter: viola.lu
>Assignee: Gang Yin
>Priority: Minor
> Attachments: fix-g4550-jeffyin.patch, fix-g4550-v22-jeffyin.patch, 
> screenshot-1.jpg, screenshot-2.jpg
>
>
> 1.Create a console.jms/org.ibm.samples/1.0/rar resouce from admin console 
> 2.Receate a console.jms/org.ibm.samples/1.0/rar  resource , but no error in 
> conosle but error message in geronimo.out :Deployer operation failed: Module 
> console.jms/org.ibm.samples/1.0/rar already exists in the server.  Try to 
> undeploy it first or use the redeploy command.
> 3.So no error message when fail to create a jms resource.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[BUILD] trunk: Failed for Revision: 749927

[gawor]

Geronimo Revision: 749927 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/build-0300.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 41 minutes 8 seconds
[INFO] Finished at: Wed Mar 04 03:46:24 EST 2009
[INFO] Final Memory: 428M/972M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/logs-0300-tomcat/test.log
 
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/logs-0300-jetty/test.log
 
 
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-jetty6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty6-javaee5/2.2-SNAPSHOT/geronimo-jetty6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:47.442
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO] 
[INFO] 
---
[INFO] 
[INFO] commands-testsuite/deploy  RUNNING
[INFO] commands-testsuite/deploy  SUCCESS (0:01:09.434) 
[INFO] commands-testsuite/gshell  RUNNING
[INFO] commands-testsuite/gshell  SUCCESS (0:00:30.901) 
[INFO] commands-testsuite/jaxws   RUNNING
[INFO] commands-testsuite/jaxws   SUCCESS (0:00:35.042) 
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.734) 
[INFO] concurrent-testsuite/concurrent-basic  RUNNING
[INFO] concurrent-testsuite/concurrent-basic  SUCCESS (0:06:08.076) 
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:00:17.556) Java 
returned: 1
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicFAILURE (0:00:17.874) Java 
returned: 1
[INFO] corba-testsuite/corba-helloworld   RUNNING
[INFO] corba-testsuite/corba-helloworld   SUCCESS (0:00:49.636) 
[INFO] corba-testsuite/corba-marshal  RUNNING
[INFO] corba-testsuite/corba-marshal  SUCCESS (0:01:00.042) 
[INFO] corba-testsuite/corba-mytime   RUNNING
[INFO] corba-testsuite/corba-mytime   SUCCESS (0:00:40.479) 
[INFO] deployment-testsuite/deployment-tests  RUNNING
[INFO] deployment-testsuite/deployment-tests  SUCCESS (0:00:29.735) 
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:28.967) 
[INFO] deployment-testsuite/manifestcp-tests  RUNNING
[INFO] deployment-testsuite/manifestcp-tests  SUCCESS (0:00:31.306) 
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:36.000) 
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:53.594) 
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:41.013) 
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:28.376) 
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.441) 
[INFO] security-testsuite/test-security   RUNNING
[INFO] security-testsuite/test-security   FAILURE (0:00:34.091) Java 
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:28.857) 
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00

[jira] Created: (GERONIMO-4568) could not stop the application EAR that has the wrong JMS deployment plan

[running Wang (JIRA)]

could not stop the application EAR that has the wrong JMS deployment plan
-

 Key: GERONIMO-4568
 URL: https://issues.apache.org/jira/browse/GERONIMO-4568
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 2.1.4
 Environment: operating system: AIX


Reporter: running Wang


deploy the ear  with the wrong JMS deployment plan
could not stop the application via the console

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (GERONIMODEVTOOLS-555) Generated geronimo-plugin.xml file is empy after converting application to plugin

[viola.lu (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678640#action_12678640
 ] 

viola.lu edited comment on GERONIMODEVTOOLS-555 at 3/4/09 12:50 AM:


in jdk .16 , it doesn't work, but work on 1.5

  was (Author: viola.lu):
in jdk .16 , it doesn't work, but work on .15
  
> Generated  geronimo-plugin.xml file is empy after converting application to 
> plugin
> --
>
> Key: GERONIMODEVTOOLS-555
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.2.0, 2.1.4
> Environment: SunJDk 1.6
>Reporter: viola.lu
>Assignee: Tim McConnell
>
> 1.Install GEP 2.2 snapshot on eclispe, start G2.2snapshot in it.
> 2.Open defined server, and launch convert apps to plugins 
> 3.Choose deployed app cviewer and conver it to plugin, successfully saved 
> ,but check geronimo-plugin.xml, it's empty.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMODEVTOOLS-555) Generated geronimo-plugin.xml file is empy after converting application to plugin

[viola.lu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

viola.lu updated GERONIMODEVTOOLS-555:
--

Environment: SunJDk 1.6  (was: SunJDk 1.5, 1.6)

> Generated  geronimo-plugin.xml file is empy after converting application to 
> plugin
> --
>
> Key: GERONIMODEVTOOLS-555
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.2.0, 2.1.4
> Environment: SunJDk 1.6
>Reporter: viola.lu
>Assignee: Tim McConnell
>
> 1.Install GEP 2.2 snapshot on eclispe, start G2.2snapshot in it.
> 2.Open defined server, and launch convert apps to plugins 
> 3.Choose deployed app cviewer and conver it to plugin, successfully saved 
> ,but check geronimo-plugin.xml, it's empty.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMODEVTOOLS-555) Generated geronimo-plugin.xml file is empy after converting application to plugin

[viola.lu (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678640#action_12678640
 ] 

viola.lu commented on GERONIMODEVTOOLS-555:
---

in jdk .16 , it doesn't work, but work on .15

> Generated  geronimo-plugin.xml file is empy after converting application to 
> plugin
> --
>
> Key: GERONIMODEVTOOLS-555
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.2.0, 2.1.4
> Environment: SunJDk 1.6
>Reporter: viola.lu
>Assignee: Tim McConnell
>
> 1.Install GEP 2.2 snapshot on eclispe, start G2.2snapshot in it.
> 2.Open defined server, and launch convert apps to plugins 
> 3.Choose deployed app cviewer and conver it to plugin, successfully saved 
> ,but check geronimo-plugin.xml, it's empty.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-4567) Gshell deploy/assemble command on a remote server cannot work

[caiwenjing (JIRA)]

Gshell deploy/assemble command on a remote server cannot work
-

 Key: GERONIMO-4567
 URL: https://issues.apache.org/jira/browse/GERONIMO-4567
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Affects Versions: 2.1.4
 Environment: remote : JAVA5 + SOLARIS 10 SPARC (32BIT) 
local : Windows xp professional sp3
Reporter: caiwenjing


1.Change the RemoteDeployHostname to the remote machine's IP in file 
var/config/config-substitutions.properties in the remote machine.
2.Add the remote machine's IP to /etc/hosts in the remote machine.
2.Start the server on the remote machine.  
3.Cd into /bin directory on the local machine, launch gsh and run: 
deploy/connect -s REMOTE_IP -p PORT
4.run: deploy/assemble, input a server artifact name

Then console shows:

ERROR UnmarshalException: error unmarshalling return; nested exception is:  
java.lang.ClassNotFoundException: 
com.sun.org.apache.xerces.internal.dom.ElementNSImpl

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-4566) Need extra servlet mappings for jetty for welcome jsps compiled into servlets

[David Jencks (JIRA)]

Need extra servlet mappings for jetty for welcome jsps compiled into servlets
-

 Key: GERONIMO-4566
 URL: https://issues.apache.org/jira/browse/GERONIMO-4566
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Reporter: David Jencks
Assignee: David Jencks


See http://jira.codehaus.org/browse/JETTY-936.  We need to include at least a 
servlet mapping something like:


jsp.index_jsp
/


until jetty fixes the default servlet.

This showed up because I deleted the uncompiled jsps.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.