[jira] Created: (GERONIMO-5617) Timestamp precision (scale) openjpa - Oracle

2010-09-21 Thread Ralf Baumhof (JIRA) 
Timestamp precision (scale) openjpa - Oracle
-

 Key: GERONIMO-5617
 URL: https://issues.apache.org/jira/browse/GERONIMO-5617
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: databases, persistence
Affects Versions: 2.1.4
 Environment: Geronimo 2.14 with JDK 1.5 update 20, on Window / Linux, 
Database Oracle 10g or 11
Reporter: Ralf Baumhof


Timestamp precision should be up to 10 up -12 (nano second) with Datatype 
java.sql.Timestamp. On inserts to database only 10 up -3 is inserted. 
This is done with rounding at position 10 up -3.

Example - the log lines beginning with a # the value of 5551110 is rounded to 
12:16:06.006:
2010-09-21 12:16:06,646  INFO - $$vor update, timestamp.toString=2010-09-21 
12:16:06.646  $$ nanos vor update=64600
2010-09-21 12:16:06,646  INFO -  (addition Millisekunden): 1 * 1110222 = 1110222
2010-09-21 12:16:06,646  INFO - $$nach update, timestamp.toString=2010-09-21 
12:16:06.001110222  $$ nanos nach update=1110222
2010-09-21 12:16:06,662  INFO - $$vor update, timestamp.toString=2010-09-21 
12:16:06.662  $$ nanos vor update=66200
2010-09-21 12:16:06,662  INFO -  (addition Millisekunden): 2 * 1110222 = 2220444
2010-09-21 12:16:06,662  INFO - $$nach update, timestamp.toString=2010-09-21 
12:16:06.002220444  $$ nanos nach update=2220444
2010-09-21 12:16:06,662  INFO - $$vor update, timestamp.toString=2010-09-21 
12:16:06.662  $$ nanos vor update=66200
2010-09-21 12:16:06,662  INFO -  (addition Millisekunden): 3 * 1110222 = 3330666
2010-09-21 12:16:06,662  INFO - $$nach update, timestamp.toString=2010-09-21 
12:16:06.003330666  $$ nanos nach update=3330666
2010-09-21 12:16:06,677  INFO - $$vor update, timestamp.toString=2010-09-21 
12:16:06.677  $$ nanos vor update=67700
2010-09-21 12:16:06,677  INFO -  (addition Millisekunden): 4 * 1110222 = 4440888
2010-09-21 12:16:06,677  INFO - $$nach update, timestamp.toString=2010-09-21 
12:16:06.004440888  $$ nanos nach update=4440888
2010-09-21 12:16:06,693  INFO - $$vor update, timestamp.toString=2010-09-21 
12:16:06.693  $$ nanos vor update=69300
2010-09-21 12:16:06,693  INFO -  (addition Millisekunden): 5 * 1110222 = 5551110
###2010-09-21 12:16:06,693  INFO - $$nach update, timestamp.toString=2010-09-21 
12:16:06.00555111  $$ nanos nach update=5551110
###2010-09-21 12:16:36,583  INFO - $$ personAnschrift=4425 54852010-09-21 
12:16:06.006
2010-09-21 12:16:36,583  INFO - $$ personAnschrift=4425 54842010-09-21 
12:16:06.004
2010-09-21 12:16:36,583  INFO - $$ personAnschrift=4425 54832010-09-21 
12:16:06.003
2010-09-21 12:16:36,583  INFO - $$ personAnschrift=4425 54822010-09-21 
12:16:06.002
2010-09-21 12:16:36,583  INFO - $$ personAnschrift=4425 54812010-09-21 
12:16:06.001


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

[jira] Created: (GERONIMO-5416) After login to Geronimo/Tomcat with j_security_check action, the user is not authenticated to ejb container

2010-06-30 Thread Ralf Baumhof (JIRA) 
After login to Geronimo/Tomcat with j_security_check action, the user is not 
authenticated to ejb container
---

 Key: GERONIMO-5416
 URL: https://issues.apache.org/jira/browse/GERONIMO-5416
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: security
Affects Versions: 2.1.4
 Environment: Windows, Linux with jdk 1.5 update 20, Geronimo 2.1.4 
with Tomcat Web Container
Reporter: Ralf Baumhof
Priority: Minor


After logging in to geronimo with j_security_check action, the user is 
authenticated to jsf and his role is known to jsf. But the user is not 
authenticated to ejb container. See also 
http://apache-geronimo.328035.n3.nabble.com/j-security-check-jaas-container-managed-security-login-to-tomcat-is-not-forwarde-to-ejb-container-tc921719.html#a921719


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

[jira] Commented: (GERONIMO-4981) Admin console abnormal when using java security policy

2010-02-01 Thread Ralf Baumhof (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMO-4981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12828515#action_12828515
 ] 

Ralf Baumhof commented on GERONIMO-4981:


On Windows and Ubuntu Linux we have got the same problem with geronimo 2.2. 
With jdk 1.5 update 20, no error is displayed in log or console. Using jdk 1.6 
update 14 the following error msg is displayed:

java.lang.SecurityException: Es wird versucht, ein Objekt hinzuzufügen, das 
keine Instanz von java.security.Principal für eine Principal-Gruppe eines 
Betreffs ist.
at javax.security.auth.Subject$SecureSet.add(Subject.java:1074)
at 
java.util.Collections$SynchronizedCollection.add(Collections.java:1577)
at 
org.apache.catalina.connector.Request.setUserPrincipal(Request.java:1757)
at 
org.apache.geronimo.tomcat.security.SecurityValve.invoke(SecurityValve.java:77)
at 
org.apache.geronimo.tomcat.security.jacc.JACCSecurityValve.invoke(JACCSecurityValve.java:54)
at 
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:420)
at 
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:361)
at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
at 
org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

The policy file's content is as mentioned:
grant {
  permission java.security.AllPermission;
};
and was created with the policy toolkit.

The startup statement which forces the error is:
set JAVA_OPTS=-Xms96m -Xmx256m -XX:MaxPermSize=128M 
-DGERONIMO_CONF=/d:/home/geronimo2.2/var/config 
-Djava.security.manager=java.rmi.RMISecurityManager 
-Djava.security.policy=/geronimo2.2/bin/java.policy



 Admin console abnormal when using java security policy
 --

 Key: GERONIMO-4981
 URL: https://issues.apache.org/jira/browse/GERONIMO-4981
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 2.2
 Environment: OS: Linux x86
 Java: java version 1.6.0_10
 Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
 Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
Reporter: Forrest Xia

 If you add a file .java.policy in your user.home with content as this:
 grant{
   permission java.security.AllPermission;
 };
 then start geronimo 2.2, you will find the admin console app is abnormal, 
 there is no need to login, and no navigation bar shows up.
 But geronimo 2.1.4 has no such problem.

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

[jira] Commented: (GERONIMO-4671) Error on Oracle XA Datasource deployment or server startup thow the datasource works correctly

2009-09-04 Thread Ralf Baumhof (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMO-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12751548#action_12751548
 ] 

Ralf Baumhof commented on GERONIMO-4671:


Yes, the datasource is configured as type XA datasource

 Error on Oracle XA Datasource deployment or server startup thow the 
 datasource works correctly
 --

 Key: GERONIMO-4671
 URL: https://issues.apache.org/jira/browse/GERONIMO-4671
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: persistence
Affects Versions: 2.1.4
 Environment: java 1.6 update 14, windows
Reporter: Ralf Baumhof
Priority: Minor

 We have configured oracle xa datasource with the following settings 
 (see also 
 http://www.nabble.com/Configure-Oracle-XA-Datasource-with-Oracle-XE-(10g-Express)-in-console-dialog-to23707396s134.html#a23858245)
 User Name: oracleuser(schema name)
 Service Name: xe
 Password:XXX
 Confirm Password: XXX
 Port:1521
 Data Source Name: oracle.jdbc.xa.client.OracleXADataSource
 Network Protocol: TCP
 Database Name: xe
 TNS Entry Name: (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(Host = 
 localhost)(Port = 1521))(CONNECT_DATA = (SID = xe)))
 Driver Type: thin
 Server Name: localhost 
 The datasource works, and with geronimo 2.1.3 (java 1.5 update 16 on windows, 
 linux) no errors have been reported. Now we are switching to geronimo 2.1.4 
 and during deployment an exception is thrown. This exception is also thrown 
 on every server startup.
 Exception during deployment:
 Geronimo Application Server started
 2009-06-03 21:09:45,921 WARN  [XSRFHandler] Blocked due to invalid 
 HttpServletRe
 quest parameter.
 2009-06-03 21:09:45,921 ERROR [XSSXSRFFilter] XSSXSRFFilter blocked 
 HttpServletR
 equest due to invalid FORM content.
 2009-06-03 21:12:57,468 ERROR [RecoveryController] Recovery error
 javax.transaction.xa.XAException
 at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:705)
 at 
 org.apache.geronimo.transaction.manager.WrapperNamedXAResource.recove
 r(WrapperNamedXAResource.java:74)
 at 
 org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceM
 anager(RecoveryImpl.java:98)
 at 
 org.apache.geronimo.transaction.manager.TransactionManagerImpl.recove
 rResourceManager(TransactionManagerImpl.java:352)
 at 
 org.apache.geronimo.connector.outbound.AbstractConnectionManager.doRe
 covery(AbstractConnectionManager.java:70)
 at 
 org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrappe
 r.doStart(ManagedConnectionFactoryWrapper.java:166)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
 nstance.java:998)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
 (GBeanInstanceState.java:268)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta
 nceState.java:102)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j
 ava:541)
 at 
 org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB
 eanDependency.java:111)
 at 
 org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe
 ndency.java:146)
 at 
 org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe
 ndency.java:120)
 at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve
 nt(BasicLifecycleMonitor.java:176)
 at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas
 icLifecycleMonitor.java:44)
 at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr
 oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
 (GBeanInstanceState.java:294)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta
 nceState.java:102)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G
 BeanInstanceState.java:124)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI
 nstance.java:555)
 at 
 org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi
 cKernel.java:379)
 at 
 org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio
 nGBeans(ConfigurationUtil.java:456)
 at 
 org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke
 rnelConfigurationManager.java:188)
 at 
 org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
 figuration(SimpleConfigurationManager.java:563)
 at 
 org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon

[jira] Commented: (GERONIMO-4671) Error on Oracle XA Datasource deployment or server startup thow the datasource works correctly

2009-06-05 Thread Ralf Baumhof (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMO-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12716533#action_12716533
 ] 

Ralf Baumhof commented on GERONIMO-4671:


As in geronimo 2.1.3 the datasource was configured through console dialog. 
During deployment the first exception is thrown. 

 Error on Oracle XA Datasource deployment or server startup thow the 
 datasource works correctly
 --

 Key: GERONIMO-4671
 URL: https://issues.apache.org/jira/browse/GERONIMO-4671
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: persistence
Affects Versions: 2.1.4
 Environment: java 1.6 update 14, windows
Reporter: Ralf Baumhof
Priority: Minor

 We have configured oracle xa datasource with the following settings 
 (see also 
 http://www.nabble.com/Configure-Oracle-XA-Datasource-with-Oracle-XE-(10g-Express)-in-console-dialog-to23707396s134.html#a23858245)
 User Name: oracleuser(schema name)
 Service Name: xe
 Password:XXX
 Confirm Password: XXX
 Port:1521
 Data Source Name: oracle.jdbc.xa.client.OracleXADataSource
 Network Protocol: TCP
 Database Name: xe
 TNS Entry Name: (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(Host = 
 localhost)(Port = 1521))(CONNECT_DATA = (SID = xe)))
 Driver Type: thin
 Server Name: localhost 
 The datasource works, and with geronimo 2.1.3 (java 1.5 update 16 on windows, 
 linux) no errors have been reported. Now we are switching to geronimo 2.1.4 
 and during deployment an exception is thrown. This exception is also thrown 
 on every server startup.
 Exception during deployment:
 Geronimo Application Server started
 2009-06-03 21:09:45,921 WARN  [XSRFHandler] Blocked due to invalid 
 HttpServletRe
 quest parameter.
 2009-06-03 21:09:45,921 ERROR [XSSXSRFFilter] XSSXSRFFilter blocked 
 HttpServletR
 equest due to invalid FORM content.
 2009-06-03 21:12:57,468 ERROR [RecoveryController] Recovery error
 javax.transaction.xa.XAException
 at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:705)
 at 
 org.apache.geronimo.transaction.manager.WrapperNamedXAResource.recove
 r(WrapperNamedXAResource.java:74)
 at 
 org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceM
 anager(RecoveryImpl.java:98)
 at 
 org.apache.geronimo.transaction.manager.TransactionManagerImpl.recove
 rResourceManager(TransactionManagerImpl.java:352)
 at 
 org.apache.geronimo.connector.outbound.AbstractConnectionManager.doRe
 covery(AbstractConnectionManager.java:70)
 at 
 org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrappe
 r.doStart(ManagedConnectionFactoryWrapper.java:166)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
 nstance.java:998)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
 (GBeanInstanceState.java:268)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta
 nceState.java:102)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j
 ava:541)
 at 
 org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB
 eanDependency.java:111)
 at 
 org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe
 ndency.java:146)
 at 
 org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe
 ndency.java:120)
 at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve
 nt(BasicLifecycleMonitor.java:176)
 at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas
 icLifecycleMonitor.java:44)
 at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr
 oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
 (GBeanInstanceState.java:294)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta
 nceState.java:102)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G
 BeanInstanceState.java:124)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI
 nstance.java:555)
 at 
 org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi
 cKernel.java:379)
 at 
 org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio
 nGBeans(ConfigurationUtil.java:456)
 at 
 org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke
 rnelConfigurationManager.java:188)
 at 
 org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
 figuration(SimpleConfigurationManager.java:563)
 at

[jira] Updated: (GERONIMO-4671) Error on Oracle XA Datasource deployment or server startup thow the datasource works correctly

2009-06-04 Thread Ralf Baumhof (JIRA) 

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

Ralf Baumhof updated GERONIMO-4671:
---

Description: 
We have configured oracle xa datasource with the following settings 
(see also 
http://www.nabble.com/Configure-Oracle-XA-Datasource-with-Oracle-XE-(10g-Express)-in-console-dialog-to23707396s134.html#a23858245)

User Name: oracleuser(schema name)
Service Name: xe
Password:XXX
Confirm Password: XXX
Port:1521
Data Source Name: oracle.jdbc.xa.client.OracleXADataSource
Network Protocol: TCP
Database Name: xe
TNS Entry Name: (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(Host = 
localhost)(Port = 1521))(CONNECT_DATA = (SID = xe)))
Driver Type: thin
Server Name: localhost 

The datasource works, and with geronimo 2.1.3 (java 1.5 update 16 on windows, 
linux) no errors have been reported. Now we are switching to geronimo 2.1.4 and 
during deployment an exception is thrown. This exception is also thrown on 
every server startup.

Exception during deployment:
Geronimo Application Server started
2009-06-03 21:09:45,921 WARN  [XSRFHandler] Blocked due to invalid HttpServletRe
quest parameter.
2009-06-03 21:09:45,921 ERROR [XSSXSRFFilter] XSSXSRFFilter blocked HttpServletR
equest due to invalid FORM content.
2009-06-03 21:12:57,468 ERROR [RecoveryController] Recovery error
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:705)
at org.apache.geronimo.transaction.manager.WrapperNamedXAResource.recove
r(WrapperNamedXAResource.java:74)
at org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceM
anager(RecoveryImpl.java:98)
at org.apache.geronimo.transaction.manager.TransactionManagerImpl.recove
rResourceManager(TransactionManagerImpl.java:352)
at org.apache.geronimo.connector.outbound.AbstractConnectionManager.doRe
covery(AbstractConnectionManager.java:70)
at org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrappe
r.doStart(ManagedConnectionFactoryWrapper.java:166)
at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
nstance.java:998)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
(GBeanInstanceState.java:268)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta
nceState.java:102)
at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j
ava:541)
at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB
eanDependency.java:111)
at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe
ndency.java:146)
at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe
ndency.java:120)
at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve
nt(BasicLifecycleMonitor.java:176)
at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas
icLifecycleMonitor.java:44)
at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr
oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
(GBeanInstanceState.java:294)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta
nceState.java:102)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G
BeanInstanceState.java:124)
at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI
nstance.java:555)
at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi
cKernel.java:379)
at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio
nGBeans(ConfigurationUtil.java:456)
at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke
rnelConfigurationManager.java:188)
at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
figuration(SimpleConfigurationManager.java:563)
at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
figuration(SimpleConfigurationManager.java:544)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl
ectionMethodInvoker.java:34)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
n.java:124)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
java:832)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5
7)
at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat

[jira] Created: (GERONIMO-4671) Error on Oracle XA Datasource deployment or server startup thow the datasource works correctly

2009-06-03 Thread Ralf Baumhof (JIRA) 
Error on Oracle XA Datasource deployment or server startup thow the datasource 
works correctly
--

 Key: GERONIMO-4671
 URL: https://issues.apache.org/jira/browse/GERONIMO-4671
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: persistence
Affects Versions: 2.1.4
 Environment: java 1.6 update 14, windows
Reporter: Ralf Baumhof
Priority: Minor


We have configured oracle xa datasource with the following settings 
(see also 
http://www.nabble.com/Configure-Oracle-XA-Datasource-with-Oracle-XE-(10g-Express)-in-console-dialog-to23707396s134.html#a23858245)

User Name: oracleuser(schema name)
Service Name: xe
Password:XXX
Confirm Password: XXX
Port:1521
Data Source Name: oracle.jdbc.xa.client.OracleXADataSource
Network Protocol: TCP
Database Name: xe
TNS Entry Name: (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(Host = 
localhost)(Port = 1521))(CONNECT_DATA = (SID = xe)))
Driver Type: thin
Server Name: localhost 

The datasource works, and with geronimo 2.1.3 (java 1.5 update 16 on windows, 
linux) no errors have been reported. Now we are switching to geronimo 2.1.4 and 
during deployment an exception is thrown. This exception is also thrown on 
every server startup.

Exception:
Geronimo Application Server started
2009-06-03 21:09:45,921 WARN  [XSRFHandler] Blocked due to invalid HttpServletRe
quest parameter.
2009-06-03 21:09:45,921 ERROR [XSSXSRFFilter] XSSXSRFFilter blocked HttpServletR
equest due to invalid FORM content.
2009-06-03 21:12:57,468 ERROR [RecoveryController] Recovery error
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:705)
at org.apache.geronimo.transaction.manager.WrapperNamedXAResource.recove
r(WrapperNamedXAResource.java:74)
at org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceM
anager(RecoveryImpl.java:98)
at org.apache.geronimo.transaction.manager.TransactionManagerImpl.recove
rResourceManager(TransactionManagerImpl.java:352)
at org.apache.geronimo.connector.outbound.AbstractConnectionManager.doRe
covery(AbstractConnectionManager.java:70)
at org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrappe
r.doStart(ManagedConnectionFactoryWrapper.java:166)
at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
nstance.java:998)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
(GBeanInstanceState.java:268)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta
nceState.java:102)
at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j
ava:541)
at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB
eanDependency.java:111)
at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe
ndency.java:146)
at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe
ndency.java:120)
at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve
nt(BasicLifecycleMonitor.java:176)
at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas
icLifecycleMonitor.java:44)
at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr
oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
(GBeanInstanceState.java:294)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta
nceState.java:102)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G
BeanInstanceState.java:124)
at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI
nstance.java:555)
at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi
cKernel.java:379)
at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio
nGBeans(ConfigurationUtil.java:456)
at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke
rnelConfigurationManager.java:188)
at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
figuration(SimpleConfigurationManager.java:563)
at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
figuration(SimpleConfigurationManager.java:544)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl
ectionMethodInvoker.java:34)
at

[jira] Created: (GERONIMO-4672) Managed oracle datasource does not properly perform rollbacks

2009-06-03 Thread Ralf Baumhof (JIRA) 
Managed oracle datasource does not properly perform rollbacks
-

 Key: GERONIMO-4672
 URL: https://issues.apache.org/jira/browse/GERONIMO-4672
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: persistence
Affects Versions: 2.1.3
 Environment: Geronimo 2.1.3 with java 1.5 on linux and windows
Reporter: Ralf Baumhof


The oracle datasource is configured with the following parameters:

Type: thin
Transactions: none
jar file: ojdbc14.jar from oracle 10g Express
db server: oracle 10g express, 11g express and 11g production

The application uses OpenJpa for persistence layer. With PostgreSQL database 
Server all worked fine. When migrating to oracle we discovered that rollback is 
not properly performed.

Test:
In one table a column is dropped. The application tries to insert data. This 
result in an persistence exception. A rollback is performed (that's what the 
server tells in the log) but data inserted prior to the error point remains 
comitted. We solved the problem by configuring an XA datasource, but this 
version should also work.


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

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

2008-05-06 Thread Ralf Baumhof (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594577#action_12594577
 ] 

Ralf Baumhof commented on GERONIMO-3907:


Today if have tested the new Geronimo release 2.1.1 (published on 28.04.2008). 
The problem is now fixed. If the server gets an error on trying a commit, this 
error is now thrown to the web bean. 

Exception text: 
javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, 
presumably because setRollbackOnly was called during a synchronization: Unable 
to commit: transaction marked for rollback Root Cause: 
javax.transaction.TransactionRolledbackException : Transaction was rolled back, 
presumably because setRollbackOnly was called during a synchronization: Unable 
to commit: transaction marked for rollback

Unfortunately there is no proper root cause attached to the exception. So the 
cause can only be seen in the server console, but can not be reported to the 
user. It would be very nice if you could change this in a later release.

Thanks for your help.




 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: Blocker
   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
 openjpa-1.0.1-r420667:592145 fatal general error 
 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

[jira] Closed: (GERONIMO-3923) Login established without tomcat notification

2008-03-18 Thread Ralf Baumhof (JIRA) 

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

Ralf Baumhof closed GERONIMO-3923.
--

Resolution: Invalid

Works as designed

 Login established without tomcat notification
 -

 Key: GERONIMO-3923
 URL: https://issues.apache.org/jira/browse/GERONIMO-3923
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 2.0.2, 2.1
 Environment: Windows, Linux
Reporter: Ralf Baumhof
Assignee: David Jencks

 I have set up a security realm (sql realm). In web.xml tomcat is advised to 
 keep a watch an all pages lying in directory /pages. I use a form login. If 
 the  login form is designed to use j_security_check action, the servlet 
 authentication works. The first try to access a page in /pages/* area leads 
 to the login form and after successful login the page is diplayed. However, 
 the application has strong security impacts, so we would prefer to use a JSF 
 backing bean which performs a LoginContext method for login to geronimo. This 
 also works. The login succeeds and i get a principal. But the application is 
 not logged in at tomcat webcontainer. It's not possible to access the pages 
 in /pages/* area. Is this a bug or a feature What must be done if one 
 want's to use the LoginContext way??? According to the geronimo wiki i 
 suggest that it should work. 

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

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

2008-03-17 Thread Ralf Baumhof (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579354#action_12579354
 ] 

Ralf Baumhof commented on GERONIMO-3907:


Of course entityManager.flush() works. But this is not an appropriate solution. 
We have a big project and we can not rely on the programmers always to write 
flush after each persist call. What i mean is a configuration setting that 
always forces the EntityManager to write changes through to databse. I have 
tried to disable caching but this does not work. Now, i'am currently 
evaluating: property name=openjpa.DataCacheTimeout value=0 /. This seems 
to work. This means, data in the cache will expire at once.  But will there be 
any serious side effects if we enable this setting I consider this 
problem as very serious because container transaction managment must be 
reliable. It's the main point for using an application server. 

 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
Priority: Blocker
   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
 openjpa-1.0.1-r420667:592145 fatal general error 
 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

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

2008-03-17 Thread Ralf Baumhof (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579356#action_12579356
 ] 

Ralf Baumhof commented on GERONIMO-3907:


Sorry, i was wrong. The setting property name=openjpa.DataCacheTimeout 
value=0 / does not work. So, if there is no nearby solution for this 
problem, we must think about stopping the project and first port to an another 
application container.

 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
Priority: Blocker
   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
 openjpa-1.0.1-r420667:592145 fatal general error 
 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)
 at org.apache.el.parser.AstValue.invoke(AstValue.java:131)
 at 
 org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
 at 
 org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68)
 at 
 javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75)
 at 
 org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54)

[jira] Created: (GERONIMO-3923) Login established without tomcat notification

2008-03-17 Thread Ralf Baumhof (JIRA) 
Login established without tomcat notification
-

 Key: GERONIMO-3923
 URL: https://issues.apache.org/jira/browse/GERONIMO-3923
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: security
Affects Versions: 2.1, 2.0.2
 Environment: Windows, Linux
Reporter: Ralf Baumhof


I have set up a security realm (sql realm). In web.xml tomcat is advised to 
keep a watch an all pages lying in directory /pages. I use a form login. If the 
 login form is designed to use j_security_check action, the servlet 
authentication works. The first try to access a page in /pages/* area leads to 
the login form and after successful login the page is diplayed. However, the 
application has strong security impacts, so we would prefer to use a JSF 
backing bean which performs a LoginContext method for login to geronimo. This 
also works. The login succeeds and i get a principal. But the application is 
not logged in at tomcat webcontainer. It's not possible to access the pages in 
/pages/* area. Is this a bug or a feature What must be done if one want's 
to use the LoginContext way??? According to the geronimo wiki i suggest that it 
should work. 




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

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

2008-03-13 Thread Ralf Baumhof (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578208#action_12578208
 ] 

Ralf Baumhof commented on GERONIMO-3907:


I have just upgraded my geronimo 2.1 with a new openjpa (1.0.2) version. The 
error is the same. The situation always occurs if you have only one insert on 
the database. So, the physical insert on database is performed AFTER the 
stateless session bean is executed (by ejb container on performing the commit 
with the jta datasource). If i throw an exception by myself it is recognized. 
Did you try this situation in your environment?  The situation does not occur 
if i have several inserts on dependant objects. In this case OpenJPA writes to 
database earlier and the exception is thrown during one of the persist calls. 
The database is a postgresql 8.2 database. Is there a possibility to force 
OpenJPA always write through to the database on each persist call?? Much thanks 
in advance!!

 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
Priority: Blocker
   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
 openjpa-1.0.1-r420667:592145 fatal general error 
 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

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

2008-03-12 Thread Ralf Baumhof (JIRA) 
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.1, 2.0.2
 Environment: Linux, Windows
Reporter: Ralf Baumhof
Priority: Blocker


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
openjpa-1.0.1-r420667:592145 fatal general error 
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)
at org.apache.el.parser.AstValue.invoke(AstValue.java:131)
at 
org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at 
org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68)
at 
javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75)
at 
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54)
at javax.faces.component.UICommand.broadcast(UICommand.java:121)
at 
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292)
at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209)
at 
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:117)
at 
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32)
at 
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at 
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at

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

2008-03-12 Thread Ralf Baumhof (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577805#action_12577805
 ] 

Ralf Baumhof commented on GERONIMO-3907:


The same proble occurs, if i correct the annotations, but have an invalid 
foreign key in one column. The persist method is successfully, and later the 
commit fails. The call stack, the first line is from the DAO class which 
reports that the persist method was ok, the last line is from the JSF bean. 

[de.nrw.hagen.ggrz.bv.benutzer.db.BenutzerDAOImpl]  $$ BenutzerDAO::generated 
id = 32
12:36:12,337 WARN  [Transaction] Unexpected exception from beforeCompletion; 
transaction will roll back
openjpa-1.0.1-r420667:592145 fatal general error 
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 $Proxy78.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)
at org.apache.el.parser.AstValue.invoke(AstValue.java:131)
at 
org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at 
org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68)
at 
javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75)
at 
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54)
at javax.faces.component.UICommand.broadcast(UICommand.java:121)
at 
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292)
at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209)
at 
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:117)
at 
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32)
at 
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at 
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at 
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at

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

2008-03-12 Thread Ralf Baumhof (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577846#action_12577846
 ] 

Ralf Baumhof commented on GERONIMO-3907:


More over. Two nearly identical situations. In both cases the insert fails 
because of invalid foreign keys. In both cases the persist method first does 
not throw an exception. But in the first case (the working case) there are some 
additional inserts and updates which may force that the data is written to 
database a little bit earlier. In this case the exception is visible and 
catchable at the level of the service fassace. In the second case (the case 
described above) it is not visible - neither at the service fassade, nor at the 
JSF bean. 

This works (the exception can be caught at the service fassade):
javax.ejb.EJBTransactionRolledbackException: The transaction has been marked 
rollback only because the bean encountered a non-application exception 
:javax.ejb.EJBTransactionRolledbackException : The transaction has been marked 
rollback only because the bean encountered a non-application exception 
: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.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:348)
at 
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:323)
at 
org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
at $Proxy97.anlegenSchuldnerEintrag(Unknown Source)
at 
de.nrw.hagen.ggrz.vesuv.schuldner.services.SchuldnerServiceManagerImpl.AnlegenSchuldnerJuristischePersonZSV(SchuldnerServiceManagerImpl.java:49)
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)
at 
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:146)
at 
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:129)
at 
org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67)
at 
org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210)
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 $Proxy96.AnlegenSchuldnerJuristischePersonZSV(Unknown Source)
at 
de.nrw.hagen.ggrz.vesuv.schuldner.controler.SRegControlerBean.anlegenJPerson(SRegControlerBean.java:115)
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)
at org.apache.el.parser.AstValue.invoke(AstValue.java:131)
at 
org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at 
org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68)
at 
javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75)
at 
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54)
at javax.faces.component.UICommand.broadcast(UICommand.java:121)
at 
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292)
at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209)
at 
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:117)
at 
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32)
at 
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at 
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148)
at

[jira] Commented: (GERONIMO-3878) Unable to deploy Postgres Datasource from console dialog Database Pools because of missing jar files in jar selection listbox.

2008-03-03 Thread Ralf Baumhof (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMO-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574508#action_12574508
 ] 

Ralf Baumhof commented on GERONIMO-3878:


Yes, that's right. It works if you donwload the driver directly. The dialog 
first does not work, if you try a test, it fails. But after this first failure, 
the dialog is ok. It always comes up with the corret postgres specific 
settings, and more over, the datasource is ok. The application works. But i'am 
still confused because of the following:

- Why this strange behaviour - only for Postgres? With geronimo 2.0.2 you could 
download the driver separately, and then use the common libs dialog (now called 
repository) to deploy it. Then you will see it in the jars  listbox. This still 
works - if you use another database type (like DB2). 

- This workaround is not suitable for a production system. In production we 
NEVER have a internet connection. People in the production system are used to 
get a jar, and then they deploy it using the dialoge. So, i could use the 
dialog of an other system with internet connection to create a plan and advice 
production to deploy the plan. But this will probably result in editing and 
changing the plan to the preferences of production systems.  And this will 
result in errors. 

 Unable to deploy Postgres Datasource from console dialog Database Pools 
 because of missing jar files in jar selection listbox.
 

 Key: GERONIMO-3878
 URL: https://issues.apache.org/jira/browse/GERONIMO-3878
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 2.1
 Environment:  Windows XP Professional and Ubuntu
Reporter: Ralf Baumhof
   Original Estimate: 120h
  Remaining Estimate: 120h

 Trying to deploy a datasource with console dialog Database Pools. 
  - Select link Console Navigation/Services/Database Pools.
  - Select link Using the geronimo database pool wizard.
  - Enter some database name like for instance vesuv and select as Database 
 Type: PostgreSQL XA or PostgreSQL local.
  - Click the Next button.
  - Now, on the page where you specify the properties of the database pool, 
 the listbox where you can select the driver jar  is empty. If you choose 
 another database type (on the previous dialog page), the list is filled with 
 all entries from repository. The same steps have been made with Geronimo 
 2.02. There the database could be deployed. 

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

[jira] Created: (GERONIMO-3878) Unable to deploy Postgres Datasource from console dialog Database Pools because of missing jar files in jar selection listbox.

2008-02-27 Thread Ralf Baumhof (JIRA) 
Unable to deploy Postgres Datasource from console dialog Database Pools 
because of missing jar files in jar selection listbox.


 Key: GERONIMO-3878
 URL: https://issues.apache.org/jira/browse/GERONIMO-3878
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: console, databases, deployment
Affects Versions: 2.1
 Environment:  Windows XP Professional and Ubuntu
Reporter: Ralf Baumhof


Trying to deploy a datasource with console dialog Database Pools. 
 - Select link Console Navigation/Services/Database Pools.
 - Select link Using the geronimo database pool wizard.
 - Enter some database name like for instance vesuv and select as Database 
Type: PostgreSQL XA or PostgreSQL local.
 - Click the Next button.
 - Now, on the page where you specify the properties of the database pool, the 
listbox where you can select the driver jar  is empty. If you choose another 
database type (on the previous dialog page), the list is filled with all 
entries from repository. The same steps have been made with Geronimo 2.02. 
There the database could be deployed. 

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

[jira] Commented: (GERONIMO-3878) Unable to deploy Postgres Datasource from console dialog Database Pools because of missing jar files in jar selection listbox.

2008-02-27 Thread Ralf Baumhof (JIRA) 

[ 
https://issues.apache.org/jira/browse/GERONIMO-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573172#action_12573172
 ] 

Ralf Baumhof commented on GERONIMO-3878:


As i mentioned in my last sentence If you choose another database type (on the 
previous dialog page), the list is filled with all entries from repository. 
And because i have OF COURSE installed the jdbc driver in the repository, you 
can see it like all the other jars in repository. This means, if you choose DB2 
as database type, you get a lot of entries in the listbox. If you choose 
Postgres you see really NOTHING (the listbox where you can select the driver 
jar is empty) I'am sorry that i did not mention that i installed the 
Postgres jar driver, because this seemed to be a clear precondition for me. 

 Unable to deploy Postgres Datasource from console dialog Database Pools 
 because of missing jar files in jar selection listbox.
 

 Key: GERONIMO-3878
 URL: https://issues.apache.org/jira/browse/GERONIMO-3878
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 2.1
 Environment:  Windows XP Professional and Ubuntu
Reporter: Ralf Baumhof
   Original Estimate: 120h
  Remaining Estimate: 120h

 Trying to deploy a datasource with console dialog Database Pools. 
  - Select link Console Navigation/Services/Database Pools.
  - Select link Using the geronimo database pool wizard.
  - Enter some database name like for instance vesuv and select as Database 
 Type: PostgreSQL XA or PostgreSQL local.
  - Click the Next button.
  - Now, on the page where you specify the properties of the database pool, 
 the listbox where you can select the driver jar  is empty. If you choose 
 another database type (on the previous dialog page), the list is filled with 
 all entries from repository. The same steps have been made with Geronimo 
 2.02. There the database could be deployed. 

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