Global JNDI
Hi, How can I access ejbs over CORBA in Geronimo 2.0? On specifying the TSS configs as in 1.1, I was getting an error saying there is no builder configured for namespace http://openejb.apache.org/xml/ns/corba-tss-config-2.1 during deployment. Does anyone know why this is happening. I gave dependency only to the geronimo-corba-yoko configuration in the plan. Thanks Manu
Re: Global JNDI
Got it resolved. Needed to start the openejb-corba-deployer. Thanks Manu On 8/1/07, Manu George [EMAIL PROTECTED] wrote: Hi, How can I access ejbs over CORBA in Geronimo 2.0? On specifying the TSS configs as in 1.1, I was getting an error saying there is no builder configured for namespace http://openejb.apache.org/xml/ns/corba-tss-config-2.1 during deployment. Does anyone know why this is happening. I gave dependency only to the geronimo-corba-yoko configuration in the plan. Thanks Manu
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
On Jul 25, 2007, at 7:57 PM, Christopher Blythe wrote: I was working on DayTrader 2.0 when I found that the resetTrade method for all of the runtime modes (with the exception of Direct mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0 and noticed the same behavior. I then went back and deploy DT 1.2 on GMO 1.1.1 and resetTrade worked for EJB mode like a champ. If you look in the ejb-jar.xml and check out the container transactions, you see the following... container-transaction method ejb-nameTradeEJB/ejb-name method-intfRemote/method-intf method-nameresetTrade/method-name method-params method-paramboolean/method-param /method-params /method ... trans-attributeNotSupported/trans-attribute /container-transaction container-transaction ... method ejb-nameTradeEJB/ejb-name method-name*/method-name /method ... trans-attributeRequired/trans-attribute /container-transaction Took me a couple hours to dig through this but basically what is happening is that the second transaction attribute declaration for TradeEJB (method *) is essentially overwriting the first (method resetTrade(boolean)). These are processed in the order they are declared so fixing it should be as easy as moving the resetTrade (boolean) declaration to be after the * declaration. If you know of a part of the EJB spec that is relevant I'm definitely all ears -- as far as I know it's valid to process them in the order they are declared. For the future (not 2.0) and provided it isn't explicitly prohibited by the spec, we could possibly order the container-transaction declarations for an ejb from least specific to most specific and process them that way -- like we do for interceptor-bindings. If you had some time to do some leg work on digging through the spec that'd be great. -David The impl for resetTrade in the TradeEJB session bean calls to the TradeDirect code in order to perform the reset. The TradeDirect code manages the transaction commits on its own. That is why the resetTrade method in TradeEJB was marked as NotSupported. As I mentioned earlier, this was recognized by the Geronimo 1.1.1 container; however, it looks like the Geronimo 2.0 container is not picking this up. A look at some of the OpenEJB trace information seems to confirm this... 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/ TradeEJB with identity null 22:11:51,437 INFO [Transaction] TX Required: Started transaction [EMAIL PROTECTED] 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying pooled connection MCI: [EMAIL PROTECTED] MC: [EMAIL PROTECTED] from pool: org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor @56525652 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying connection from pool null for managed connection [EMAIL PROTECTED] to tx caching interceptor [EMAIL PROTECTED] c005c00 22:11:51,546 ERROR [Log] Error: Failed to reset Trade Just for reference, here is the exception that is being thrown 22:51:04,031 ERROR [Log] Error: Failed to reset Trade com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid during global transaction com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid during global transaction at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152) at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151) at org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit (ManagedXAConnection.java :104) at org.tranql.connector.AbstractManagedConnection $LocalTransactionImpl.commit(AbstractManagedConnection.java:192) at org.tranql.connector.jdbc.ConnectionHandle.commit (ConnectionHandle.java:115) at org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit (TradeDirect.java:2044) at org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade (TradeDirect.java:1964) at org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade (TradeBean.java:931) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java :64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.openejb.core.interceptor.ReflectionInvocationContext $Invocation.invoke (ReflectionInvocationContext.java:146) at org.apache.openejb.core.interceptor.ReflectionInvocationContext.procee d(ReflectionInvocationContext.java:129) at org.apache.openejb.core.interceptor.InterceptorStack.invoke
Problems trying to release tx + cx component jars
I tried to get a release candidate together for the tx and cx component jars but have failed. maven-release-plugin tags the jars into genesis and there seems to be way to override this, despite the documentation. http:// jira.codehaus.org/browse/MRELEASE-272 The release procedure at http://cwiki.apache.org/GMOxPMGT/release- branching-process.html works up to the point where I try to execute http://cwiki.apache.org/GMOxPMGT/release-branching-process.html which however fails because the legal files aren't getting into the source jar. If anyone else wants to try, the possibly ready to try to release stuff is at https://svn.apache.org/repos/asf/geronimo/components/ txmanager/branches/2.0 thanks david jencks
Re: [VOTE] Release specs for JACC, JSP, Servlet
+1 Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 The corresponding tar files are here: http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz The current svn locations are here: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-servlet_2.5_spec-1.1 The future svn locations will be here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1 The vote will conclude at 10:00 PM EST on Thursday, August 2nd.
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
David... Any idea how this will be handled in EJB 3 beans when the transaction attributes are defined in the annotations? If I were to define a transaction annotation for the whole bean and another for an individual method, would the method level attribute be ignored? Chris On 8/1/07, David Blevins [EMAIL PROTECTED] wrote: On Jul 25, 2007, at 7:57 PM, Christopher Blythe wrote: I was working on DayTrader 2.0 when I found that the resetTrade method for all of the runtime modes (with the exception of Direct mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0 and noticed the same behavior. I then went back and deploy DT 1.2 on GMO 1.1.1 and resetTrade worked for EJB mode like a champ. If you look in the ejb-jar.xml and check out the container transactions, you see the following... container-transaction method ejb-nameTradeEJB/ejb-name method-intfRemote/method-intf method-nameresetTrade/method-name method-params method-paramboolean/method-param /method-params /method ... trans-attributeNotSupported/trans-attribute /container-transaction container-transaction ... method ejb-nameTradeEJB/ejb-name method-name*/method-name /method ... trans-attributeRequired/trans-attribute /container-transaction Took me a couple hours to dig through this but basically what is happening is that the second transaction attribute declaration for TradeEJB (method *) is essentially overwriting the first (method resetTrade(boolean)). These are processed in the order they are declared so fixing it should be as easy as moving the resetTrade (boolean) declaration to be after the * declaration. If you know of a part of the EJB spec that is relevant I'm definitely all ears -- as far as I know it's valid to process them in the order they are declared. For the future (not 2.0) and provided it isn't explicitly prohibited by the spec, we could possibly order the container-transaction declarations for an ejb from least specific to most specific and process them that way -- like we do for interceptor-bindings. If you had some time to do some leg work on digging through the spec that'd be great. -David The impl for resetTrade in the TradeEJB session bean calls to the TradeDirect code in order to perform the reset. The TradeDirect code manages the transaction commits on its own. That is why the resetTrade method in TradeEJB was marked as NotSupported. As I mentioned earlier, this was recognized by the Geronimo 1.1.1 container; however, it looks like the Geronimo 2.0 container is not picking this up. A look at some of the OpenEJB trace information seems to confirm this... 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/ TradeEJB with identity null 22:11:51,437 INFO [Transaction] TX Required: Started transaction [EMAIL PROTECTED] 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying pooled connection MCI: [EMAIL PROTECTED] MC: [EMAIL PROTECTED] from pool: org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor @56525652 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying connection from pool null for managed connection [EMAIL PROTECTED] to tx caching interceptor [EMAIL PROTECTED] c005c00 22:11:51,546 ERROR [Log] Error: Failed to reset Trade Just for reference, here is the exception that is being thrown 22:51:04,031 ERROR [Log] Error: Failed to reset Trade com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid during global transaction com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid during global transaction at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152) at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151) at org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit (ManagedXAConnection.java :104) at org.tranql.connector.AbstractManagedConnection $LocalTransactionImpl.commit(AbstractManagedConnection.java:192) at org.tranql.connector.jdbc.ConnectionHandle.commit (ConnectionHandle.java:115) at org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit (TradeDirect.java:2044) at org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade (TradeDirect.java:1964) at org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade (TradeBean.java:931) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java :64) at sun.reflect.DelegatingMethodAccessorImpl.invoke
[VOTE : DISCUSS] Release Genesis 1.2
I would like to know why we do not use a single jdk version for all default configurations. The maven-compiler and maven-idea plugins use 1.4 whereas maven-javadoc plugin uses 1.5. Thanks Anita Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz
Re: [VOTE] Release specs for JACC, JSP, Servlet
+1 On Jul 30, 2007, at 10:04 PM, Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 The corresponding tar files are here: http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz The current svn locations are here: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- servlet_2.5_spec-1.1 The future svn locations will be here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- servlet_2.5_spec-1.1 The vote will conclude at 10:00 PM EST on Thursday, August 2nd. -- Thanks, Tim McConnell
[jira] Resolved: (SM-994) Add target .classpath and .project to svn:ignore list
[ https://issues.apache.org/activemq/browse/SM-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-994. Resolution: Fixed Fix Version/s: 3.2 Assignee: Guillaume Nodet URL: http://svn.apache.org/viewvc?view=revrev=561814 Add target .classpath and .project to svn:ignore list - Key: SM-994 URL: https://issues.apache.org/activemq/browse/SM-994 Project: ServiceMix Issue Type: Task Affects Versions: 3.2 Reporter: Piotr Bzdyl Assignee: Guillaume Nodet Fix For: 3.2 Attachments: ignored-resources.diff.txt Could you, please, add target directories and .classpath and .project files to svn:ignores? I am attaching a patch for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3357) run-as role is ignored in web.xml
[
https://issues.apache.org/jira/browse/GERONIMO-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516991
]
Aman Nanner commented on GERONIMO-3357:
---
You're right! The absence of the servlet-mapping was the cause of the issue.
I made this change in my main application, and everything is working fine now.
run-as role is ignored in web.xml
---
Key: GERONIMO-3357
URL: https://issues.apache.org/jira/browse/GERONIMO-3357
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0-M7
Environment: Windows XP SP2
Reporter: Aman Nanner
Assignee: David Jencks
Priority: Critical
Fix For: 2.0
Attachments: testing.ear.zip, testing2.ear
It seems that any run-as roles defined in a web.xml of a web application
are ignored. For example, consider the following web.xml fragment:
{code:xml}
servlet
servlet-nameExceptionPage/servlet-name
jsp-file/error/Exception.jsp/jsp-file
run-as
role-nameTESTSYSTEM/role-name
/run-as
/servlet
{code}
The JSP is never run as the TESTSYSTEM role in this case, and thus access to
method-restricted EJBs fails from the JSP. I cannot see in the
TomcatGeronimoRealm where this run-as role is being set, or if it is
accessing the credential store to get the run-as subject.
Below is the fragment of my geronimo-application.xml where I define the
security policy:
{code:xml}
security:security
security:credential-store
security:pattern
sys:name
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;MyCredentialStore/sys:name
/security:pattern
/security:credential-store
security:role-mappings
security:role role-name=TESTSYSTEM
security:run-as-subject
security:realmTestingRealm/security:realm
security:idtest-system/security:id
/security:run-as-subject
security:realm realm-name=TestingRealm
security:principal
class=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal
name=TESTSYSTEM /
/security:realm
/security:role
/security:role-mappings
/security:security
sys:gbean name=TestingRealm
class=org.apache.geronimo.security.realm.GenericSecurityRealm
sys:attribute name=realmNameTestingRealm/sys:attribute
sys:reference name=ServerInfo
sys:nameServerInfo/sys:name
/sys:reference
sys:xml-reference name=LoginModuleConfiguration
log:login-config
xmlns:log=http://geronimo.apache.org/xml/ns/loginconfig-2.0;
log:login-module control-flag=REQUIRED
wrap-principals=false
log:login-domain-nameTestingRealm/log:login-domain-name
log:login-module-classcom.testing.security.TestingLoginModule/log:login-module-class
log:option name=userSelectSELECT username, password FROM
utl_user WHERE username=?/log:option
log:option
name=dataSourceApplicationMxi/Testing/1/ear/log:option
log:option name=groupSelectSELECT name, 'TESTSYSTEM' as
role_name FROM dual/log:option
log:option
name=dataSourceNamecom/testing/jdbc/TestDS/log:option
/log:login-module
/log:login-config
/sys:xml-reference
/sys:gbean
sys:gbean name=MyCredentialStore
class=org.apache.geronimo.security.credentialstore.SimpleCredentialStoreImpl
xml-attribute name=credentialStore
credential-store
xmlns=http://geronimo.apache.org/xml/ns/credentialstore-1.0;
!-- uncomment this and the default subject in the jettty
console plan gives you admin console permissions --
realm name=TestingRealm
subject
idtest-system/id
credential
typeorg.apache.geronimo.security.credentialstore.NameCallbackHandler/type
valueananner/value
/credential
credential
typeorg.apache.geronimo.security.credentialstore.PasswordCallbackHandler/type
valuepassword/value
/credential
/subject
/realm
/credential-store
/xml-attribute
/sys:gbean
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3342) Provide a way to launch J2G components from within Eclipse IDE environment
[ https://issues.apache.org/jira/browse/GERONIMO-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan reassigned GERONIMO-3342: -- Assignee: Paul McMahan (was: Erik B. Craig) Provide a way to launch J2G components from within Eclipse IDE environment -- Key: GERONIMO-3342 URL: https://issues.apache.org/jira/browse/GERONIMO-3342 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Environment: All Reporter: Erik B. Craig Assignee: Paul McMahan Attachments: geronimo-3342.patch, geronimo-3342update.patch, geronimo-3342update2.patch In order to be more user friendly, j2g should provide a method to launch the components from within the Eclipse IDE environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3342) Provide a way to launch J2G components from within Eclipse IDE environment
[ https://issues.apache.org/jira/browse/GERONIMO-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3342: Attachment: geronimo-3342update2.patch Fixed missing Jres2glauncher.java and Jsrc2glauncher.java from the ui plugin. Provide a way to launch J2G components from within Eclipse IDE environment -- Key: GERONIMO-3342 URL: https://issues.apache.org/jira/browse/GERONIMO-3342 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Environment: All Reporter: Erik B. Craig Assignee: Erik B. Craig Attachments: geronimo-3342.patch, geronimo-3342update.patch, geronimo-3342update2.patch In order to be more user friendly, j2g should provide a method to launch the components from within the Eclipse IDE environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3342) Provide a way to launch J2G components from within Eclipse IDE environment
[ https://issues.apache.org/jira/browse/GERONIMO-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved GERONIMO-3342. Resolution: Fixed committed the additional files from geronimo-3342update2.patch in rev 561818. Thanks for the patch. Provide a way to launch J2G components from within Eclipse IDE environment -- Key: GERONIMO-3342 URL: https://issues.apache.org/jira/browse/GERONIMO-3342 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Environment: All Reporter: Erik B. Craig Assignee: Paul McMahan Attachments: geronimo-3342.patch, geronimo-3342update.patch, geronimo-3342update2.patch In order to be more user friendly, j2g should provide a method to launch the components from within the Eclipse IDE environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3332) POJO Web-services under Geronimo fail with arrays as method call arguments
[
https://issues.apache.org/jira/browse/GERONIMO-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor resolved GERONIMO-3332.
---
Resolution: Cannot Reproduce
Fix Version/s: 2.0
I'm pretty sure this problem was caused by specifying a JAX-WS web service in
the webservices.xml descriptor with the old J2EE namespace (the webservices.xml
should have JAVAEE namespace if it contains JAX-WS web services). Anyway, I
also updated Geronimo to check if a JAX-WS service is specified in a J2EE
webservices.xml descriptor and if so an deployment error will be raised.
POJO Web-services under Geronimo fail with arrays as method call arguments
--
Key: GERONIMO-3332
URL: https://issues.apache.org/jira/browse/GERONIMO-3332
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.0-M6
Environment: Windows XP Pro SP2, Sun JSDK 1.5._07,
geronimo-tomcat6-jee5-2.0-M6-rc1
Reporter: Alexei Kozich
Assignee: Jarek Gawor
Fix For: 2.0
We created POJO web sevice like following:
@WebService
@SOAPBinding(style = Style.RPC, use = Use.LITERAL)
public interface PartInventoryWs {
@WebMethod
public Integer completeReplenishOrders(
@WebParam(name = orderIds)
ListString orderIds);
}
in web.xml we defined servlet mapping in order to call this web-service like
following:
servlet-mapping
servlet-namePartInventoryWs/servlet-name
url-pattern/partinventory/url-pattern
/servlet-mapping
servlet
servlet-namePartInventoryWs/servlet-name
servlet-classdemocrm.webservice.shop.PartInventoryWsImpl/servlet-class
/servlet
So everything is deployed fine and we can access wsdl document by opening
URL: http://localhost:8080/.../partinventory?wsdl.
But this webservice fails when I try to invoke method and pass to it array of
Strings (I generated client classes by
the Apache Axis 1.3 Oct 05, 2005 (05:23:37 EDT) WSDL2Java emitter) :
(see string HTTP/1.1 500 Internal Server Error in the below debug log).
2007-07-18 14:53:16,812 DEBUG
org.apache.axis.i18n.ProjectResourceBundle
org.apache.axis.i18n.resource::handleGetObject(engineFactory)
2007-07-18 14:53:16,812 DEBUG
org.apache.axis.configuration.EngineConfigurationFactoryFinder Got
EngineFactory: org.apache.axis.configuration.EngineConfigurationFactoryDefault
2007-07-18 14:53:16,812 DEBUG org.apache.axis.AxisEngine Enter:
AxisEngine::init
2007-07-18 14:53:17,031 DEBUG org.apache.axis.AxisEngine Exit:
AxisEngine::init
2007-07-18 14:53:17,031 DEBUG
org.apache.axis.i18n.ProjectResourceBundle
org.apache.axis.i18n.resource::handleGetObject(transport00)
2007-07-18 14:53:17,031 DEBUG org.apache.axis.client.Call Transport is
[EMAIL PROTECTED]
2007-07-18 14:53:17,031 DEBUG org.apache.axis.client.Call Enter:
Call::invoke(ns, meth, args)
2007-07-18 14:53:17,031 DEBUG org.apache.axis.client.Call
operation=name:completeReplenishOrders
returnQName: null
returnType: {http://xml.apache.org/axis/}Void
returnClass: null
elementQName:null
soapAction: null
style: rpc
use: literal
numInParams: 1
method:null
ParameterDesc[0]:
name: orderIds
typeEntry: null
mode: IN
position: 0
isReturn: false
typeQName: {http://jaxb.dev.java.net/array}stringArray
javaType: class [Ljava.lang.String;
inHeader: false
outHeader: false
2007-07-18 14:53:17,031 DEBUG org.apache.axis.client.Call
operation.getNumParams()=1
2007-07-18 14:53:17,031 DEBUG org.apache.axis.client.Call getParamList
number of params: 1
2007-07-18 14:53:17,031 DEBUG org.apache.axis.client.Call Enter:
Call::invoke(RPCElement)
2007-07-18 14:53:17,031 DEBUG org.apache.axis.SOAPPart Enter: SOAPPart
ctor(FORM_SOAPENVELOPE)
2007-07-18 14:53:17,031 DEBUG
org.apache.axis.i18n.ProjectResourceBundle
org.apache.axis.i18n.resource::handleGetObject(setMsgForm)
2007-07-18 14:53:17,031 DEBUG org.apache.axis.SOAPPart Setting current
message form to: FORM_SOAPENVELOPE (currentMessage is now
org.apache.axis.message.SOAPEnvelope)
2007-07-18 14:53:17,031 DEBUG org.apache.axis.SOAPPart Exit: SOAPPart
ctor()
2007-07-18 14:53:17,031 DEBUG
org.apache.axis.i18n.ProjectResourceBundle
org.apache.axis.i18n.resource::handleGetObject(addBody00)
2007-07-18 14:53:17,031 DEBUG org.apache.axis.message.SOAPBody Adding
body element to message...
2007-07-18 14:53:17,031 DEBUG org.apache.axis.client.Call Enter:
Call::invoke()
2007-07-18 14:53:17,031 DEBUG org.apache.axis.MessageContext
MessageContext: setTargetService(PartInventoryWsImplPort)
2007-07-18 14:53:17,031 DEBUG
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
The spec is clear about this case anyway, on p 336 it says Atransactionattributemaybespecifiedonamethodof thebeanclass tooverridethetransaction attribute value explicitly or implicitly specified on the bean class. thanks david jencks On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote: David... Any idea how this will be handled in EJB 3 beans when the transaction attributes are defined in the annotations? If I were to define a transaction annotation for the whole bean and another for an individual method, would the method level attribute be ignored? Chris On 8/1/07, David Blevins [EMAIL PROTECTED] wrote: On Jul 25, 2007, at 7:57 PM, Christopher Blythe wrote: I was working on DayTrader 2.0 when I found that the resetTrade method for all of the runtime modes (with the exception of Direct mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0 and noticed the same behavior. I then went back and deploy DT 1.2 on GMO 1.1.1 and resetTrade worked for EJB mode like a champ. If you look in the ejb-jar.xml and check out the container transactions, you see the following... container-transaction method ejb-nameTradeEJB/ejb-name method-intfRemote/method-intf method-nameresetTrade/method-name method-params method-paramboolean/method-param /method-params /method ... trans-attributeNotSupported/trans-attribute /container-transaction container-transaction ... method ejb-nameTradeEJB/ejb-name method-name*/method-name /method ... trans-attributeRequired/trans-attribute /container-transaction Took me a couple hours to dig through this but basically what is happening is that the second transaction attribute declaration for TradeEJB (method *) is essentially overwriting the first (method resetTrade(boolean)). These are processed in the order they are declared so fixing it should be as easy as moving the resetTrade (boolean) declaration to be after the * declaration. If you know of a part of the EJB spec that is relevant I'm definitely all ears -- as far as I know it's valid to process them in the order they are declared. For the future (not 2.0) and provided it isn't explicitly prohibited by the spec, we could possibly order the container-transaction declarations for an ejb from least specific to most specific and process them that way -- like we do for interceptor-bindings. If you had some time to do some leg work on digging through the spec that'd be great. -David The impl for resetTrade in the TradeEJB session bean calls to the TradeDirect code in order to perform the reset. The TradeDirect code manages the transaction commits on its own. That is why the resetTrade method in TradeEJB was marked as NotSupported. As I mentioned earlier, this was recognized by the Geronimo 1.1.1 container; however, it looks like the Geronimo 2.0 container is not picking this up. A look at some of the OpenEJB trace information seems to confirm this... 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/ TradeEJB with identity null 22:11:51,437 INFO [Transaction] TX Required: Started transaction [EMAIL PROTECTED] 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying pooled connection MCI: [EMAIL PROTECTED] MC: [EMAIL PROTECTED] from pool: org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor @56525652 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying connection from pool null for managed connection [EMAIL PROTECTED] to tx caching interceptor [EMAIL PROTECTED] c005c00 22:11:51,546 ERROR [Log] Error: Failed to reset Trade Just for reference, here is the exception that is being thrown 22:51:04,031 ERROR [Log] Error: Failed to reset Trade com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid during global transaction com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid during global transaction at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152) at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151) at org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit (ManagedXAConnection.java :104) at org.tranql.connector.AbstractManagedConnection $LocalTransactionImpl.commit(AbstractManagedConnection.java :192) at org.tranql.connector.jdbc.ConnectionHandle.commit (ConnectionHandle.java:115) at org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit (TradeDirect.java :2044) at org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade (TradeDirect.java:1964) at org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade (TradeBean.java:931) at
[jira] Updated: (GERONIMO-3362) Enable Tomcat context level cluster
[ https://issues.apache.org/jira/browse/GERONIMO-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3362: --- Affects Version/s: (was: 2.0.x) 2.0 Fix Version/s: (was: 2.0.x) 2.1 2.0 Assignee: Donald Woods Enable Tomcat context level cluster --- Key: GERONIMO-3362 URL: https://issues.apache.org/jira/browse/GERONIMO-3362 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.0, 2.1 Reporter: YunFeng Ma Assignee: Donald Woods Fix For: 2.0, 2.1 Attachments: GERONIMO-3362.patch Geronimo v1.x supports tomcat context level cluster, but Geronimo v2.0.x only support tomcat host level cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r561827 [3/3] - in /geronimo/server/branches/2.0: applications/console/geronimo-console-core/ applications/console/geronimo-console-ear/ applications/console/geronimo-console-ear/src/m
On Aug 1, 2007, at 11:10 AM, [EMAIL PROTECTED] wrote: Modified: geronimo/server/branches/2.0/modules/geronimo-yoko/ NOTICE.txt URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.0/ modules/geronimo-yoko/NOTICE.txt? view=diffrev=561827r1=561826r2=561827 == --- geronimo/server/branches/2.0/modules/geronimo-yoko/NOTICE.txt (original) +++ geronimo/server/branches/2.0/modules/geronimo-yoko/NOTICE.txt Wed Aug 1 08:10:13 2007 @@ -1,11 +1,14 @@ - == === - == NOTICE file corresponding to the section 4 d of== - == the Apache License, Version 2.0, == - == in this case for the Apache OpenEJB distribution. == - == === - - Apache OpenEJB Project - Copyright 1999-2006 The Apache Software Foundation - - This product includes software developed by - The Apache Software Foundation (http://www.apache.org/). + == === + == NOTICE file corresponding to the section 4 d of== + == the Apache License, Version 2.0, == + == in this case for the Apache OpenEJB distribution. == + == === + + Apache Geronimo + Copyright 2003-2007 The Apache Software Foundation + + Apache OpenEJB Project + Copyright 1999-2007 The Apache Software Foundation + + This product includes software developed by + The Apache Software Foundation (http://www.apache.org/). Anybody know why this notice has OpenEJB in it? I'm guessing it was a copy/paste kind of error. Regardless, the prologue should say in this case for the Apache *Geronimo* distribution. Thanks for all these updates Prasad! --kevan
Re: svn commit: r561827 [3/3] - in /geronimo/server/branches/2.0: applications/console/geronimo-console-core/ applications/console/geronimo-console-ear/ applications/console/geronimo-console-ear/src/m
All of the corba code originally lived in the openejb2 tree, and was migrated into Geronimo for 2.0. Probably just never got changed when it was moved. Rick Kevan Miller wrote: On Aug 1, 2007, at 11:10 AM, [EMAIL PROTECTED] wrote: Modified: geronimo/server/branches/2.0/modules/geronimo-yoko/NOTICE.txt URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.0/modules/geronimo-yoko/NOTICE.txt?view=diffrev=561827r1=561826r2=561827 == --- geronimo/server/branches/2.0/modules/geronimo-yoko/NOTICE.txt (original) +++ geronimo/server/branches/2.0/modules/geronimo-yoko/NOTICE.txt Wed Aug 1 08:10:13 2007 @@ -1,11 +1,14 @@ - = - == NOTICE file corresponding to the section 4 d of== - == the Apache License, Version 2.0, == - == in this case for the Apache OpenEJB distribution. == - = - - Apache OpenEJB Project - Copyright 1999-2006 The Apache Software Foundation - - This product includes software developed by - The Apache Software Foundation (http://www.apache.org/). + = + == NOTICE file corresponding to the section 4 d of== + == the Apache License, Version 2.0, == + == in this case for the Apache OpenEJB distribution. == + = + + Apache Geronimo + Copyright 2003-2007 The Apache Software Foundation + + Apache OpenEJB Project + Copyright 1999-2007 The Apache Software Foundation + + This product includes software developed by + The Apache Software Foundation (http://www.apache.org/). Anybody know why this notice has OpenEJB in it? I'm guessing it was a copy/paste kind of error. Regardless, the prologue should say in this case for the Apache *Geronimo* distribution. Thanks for all these updates Prasad! --kevan
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
And section 13.3.7.2.1 very clearly states in great detail that more specific xml overrides less specific xml. So IMO there's a bug in openejb's current behavior. thanks david jencks On Aug 1, 2007, at 9:00 AM, David Jencks wrote: The spec is clear about this case anyway, on p 336 it says Atransactionattributemaybespecifiedonamethodof thebeanclass tooverridethetransaction attribute value explicitly or implicitly specified on the bean class. thanks david jencks On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote: David... Any idea how this will be handled in EJB 3 beans when the transaction attributes are defined in the annotations? If I were to define a transaction annotation for the whole bean and another for an individual method, would the method level attribute be ignored? Chris On 8/1/07, David Blevins [EMAIL PROTECTED] wrote: On Jul 25, 2007, at 7:57 PM, Christopher Blythe wrote: I was working on DayTrader 2.0 when I found that the resetTrade method for all of the runtime modes (with the exception of Direct mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0 and noticed the same behavior. I then went back and deploy DT 1.2 on GMO 1.1.1 and resetTrade worked for EJB mode like a champ. If you look in the ejb-jar.xml and check out the container transactions, you see the following... container-transaction method ejb-nameTradeEJB/ejb-name method-intfRemote/method-intf method-nameresetTrade/method-name method-params method-paramboolean/method-param /method-params /method ... trans-attributeNotSupported/trans-attribute /container-transaction container-transaction ... method ejb-nameTradeEJB/ejb-name method-name*/method-name /method ... trans-attributeRequired/trans-attribute /container-transaction Took me a couple hours to dig through this but basically what is happening is that the second transaction attribute declaration for TradeEJB (method *) is essentially overwriting the first (method resetTrade(boolean)). These are processed in the order they are declared so fixing it should be as easy as moving the resetTrade (boolean) declaration to be after the * declaration. If you know of a part of the EJB spec that is relevant I'm definitely all ears -- as far as I know it's valid to process them in the order they are declared. For the future (not 2.0) and provided it isn't explicitly prohibited by the spec, we could possibly order the container-transaction declarations for an ejb from least specific to most specific and process them that way -- like we do for interceptor-bindings. If you had some time to do some leg work on digging through the spec that'd be great. -David The impl for resetTrade in the TradeEJB session bean calls to the TradeDirect code in order to perform the reset. The TradeDirect code manages the transaction commits on its own. That is why the resetTrade method in TradeEJB was marked as NotSupported. As I mentioned earlier, this was recognized by the Geronimo 1.1.1 container; however, it looks like the Geronimo 2.0 container is not picking this up. A look at some of the OpenEJB trace information seems to confirm this... 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/ TradeEJB with identity null 22:11:51,437 INFO [Transaction] TX Required: Started transaction [EMAIL PROTECTED] 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying pooled connection MCI: [EMAIL PROTECTED] MC: [EMAIL PROTECTED] from pool: org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercepto r @56525652 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying connection from pool null for managed connection [EMAIL PROTECTED] to tx caching interceptor org.apache.geronimo.connector.outbound.TransactionCachingInterceptor@ 5 c005c00 22:11:51,546 ERROR [Log] Error: Failed to reset Trade Just for reference, here is the exception that is being thrown 22:51:04,031 ERROR [Log] Error: Failed to reset Trade com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid during global transaction com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid during global transaction at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152) at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151) at org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit (ManagedXAConnection.java :104) at org.tranql.connector.AbstractManagedConnection $LocalTransactionImpl.commit(AbstractManagedConnection.java :192) at org.tranql.connector.jdbc.ConnectionHandle.commit (ConnectionHandle.java:115) at
[jira] Commented: (GERONIMO-3362) Enable Tomcat context level cluster
[ https://issues.apache.org/jira/browse/GERONIMO-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517002 ] Paul McMahan commented on GERONIMO-3362: There was some discussion on dev about if and how context level clustering is supported in TC6. http://www.nabble.com/Context-level-clustering-not-supported-in-Tomcat-it-seems-tf3237711s134.html#a8998924 From rereading that thread it's not clear to me whether or not it's OK to apply this patch. On the surface it seems harmless to just pass the cluster reference from the deployment plan on through to the tomcat objects But without a deeper understanding of whether or not tomcat6 does in fact respond correctly to that setting I am hesitant to do so. It would be a big help if you could please take a moment to explain your clustering configuration and how you tested your patch. Another concern in my mind is whether or not Geronimo's existing support for Engine/Host level clustering might be adversely affected by making this change (I don't think so, but am not convinced yet). Thanks for your help and cooperation. Enable Tomcat context level cluster --- Key: GERONIMO-3362 URL: https://issues.apache.org/jira/browse/GERONIMO-3362 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.0.x, 2.1 Reporter: YunFeng Ma Fix For: 2.0.x Attachments: GERONIMO-3362.patch Geronimo v1.x supports tomcat context level cluster, but Geronimo v2.0.x only support tomcat host level cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
More sun schema choices
It seems that Craig Russell has succeeded in breaking the licensing logjam over the sun schemas and they are now available licensed under GPL+CDDL on the sun website at http://java.sun.com/xml/ns/javaee and http://java.sun.com/xml/ns/j2ee I'm inclined to switch to these copies for our release and include them in the schema jars. I can update the schemas in tck svn and modify the build to include the schemas themselves but I'm not sure how to appropriately modify the license files. Is anyone willing to do that? thanks david jencks
Re: Problems trying to release tx + cx component jars
Jvanzyl has offered to try to get the release plugin to stage these. thanks david jencks On Aug 1, 2007, at 2:03 AM, David Jencks wrote: I tried to get a release candidate together for the tx and cx component jars but have failed. maven-release-plugin tags the jars into genesis and there seems to be way to override this, despite the documentation. http:// jira.codehaus.org/browse/MRELEASE-272 The release procedure at http://cwiki.apache.org/GMOxPMGT/release- branching-process.html works up to the point where I try to execute http://cwiki.apache.org/GMOxPMGT/release-branching-process.html which however fails because the legal files aren't getting into the source jar. If anyone else wants to try, the possibly ready to try to release stuff is at https://svn.apache.org/repos/asf/geronimo/components/ txmanager/branches/2.0 thanks david jencks
Re: More sun schema choices
On Aug 1, 2007, at 12:26 PM, David Jencks wrote: It seems that Craig Russell has succeeded in breaking the licensing logjam over the sun schemas and they are now available licensed under GPL+CDDL on the sun website at http://java.sun.com/xml/ns/javaee and http://java.sun.com/xml/ns/j2ee I'm inclined to switch to these copies for our release and include them in the schema jars. I can update the schemas in tck svn and modify the build to include the schemas themselves but I'm not sure how to appropriately modify the license files. Is anyone willing to do that? Ya. I'll be updating the other license files, anyway. Ping me on irc when you start... --kevan
Re: [VOTE] Release specs for JACC, JSP, Servlet
+1 Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 The corresponding tar files are here: http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz The current svn locations are here: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-servlet_2.5_spec-1.1 The future svn locations will be here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1 The vote will conclude at 10:00 PM EST on Thursday, August 2nd. -- Thanks, Tim McConnell
[jira] Commented: (GERONIMO-3196) ConcurrentModificationException in ?wsdl processing
[ https://issues.apache.org/jira/browse/GERONIMO-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517036 ] Jarek Gawor commented on GERONIMO-3196: --- The problem only occurred with user supplied wsdl that contained multiple ports or services. The code was essentially removing unnecessary ports/services from a map while iterating over the same map. Committed fixes to trunk for Axis2 and CXF: Committed revision 561894. ConcurrentModificationException in ?wsdl processing --- Key: GERONIMO-3196 URL: https://issues.apache.org/jira/browse/GERONIMO-3196 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0 Reporter: Jarek Gawor Assignee: Jarek Gawor java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841) at java.util.HashMap$EntryIterator.next(HashMap.java:883) at java.util.HashMap$EntryIterator.next(HashMap.java:881) at org.apache.geronimo.cxf.GeronimoQueryHandler.updatePorts(GeronimoQueryHandler.java:93) at org.apache.geronimo.cxf.GeronimoQueryHandler.updateServices(GeronimoQueryHandler.java:73) at org.apache.geronimo.cxf.GeronimoQueryHandler.updateDefinition(GeronimoQueryHandler.java:55) at org.apache.cxf.transport.http.WSDLQueryHandler.writeResponse(WSDLQueryHandler.java:130) at org.apache.geronimo.cxf.CXFWebServiceContainer.getWsdl(CXFWebServiceContainer.java:118) at org.apache.geronimo.webservices.WebServiceContainerInvoker.service(WebServiceContainerInvoker.java:74) at org.apache.geronimo.webservices.POJOWebServiceServlet.service(POJOWebServiceServlet.java:79) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1098) at com.sun.ts.tests.jaxws.wsi.w2j.document.literal.swatest.CheckHttpMimeHeadersFilter.doFilter(CheckHttpMimeHeadersFilter.java:68) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:58) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:510) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3196) ConcurrentModificationException in ?wsdl processing
[ https://issues.apache.org/jira/browse/GERONIMO-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3196. --- Resolution: Fixed Fix Version/s: 2.0 Fixes committed to 2.0 branch: Committed revision 561903. ConcurrentModificationException in ?wsdl processing --- Key: GERONIMO-3196 URL: https://issues.apache.org/jira/browse/GERONIMO-3196 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0 Reporter: Jarek Gawor Assignee: Jarek Gawor Fix For: 2.0 java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841) at java.util.HashMap$EntryIterator.next(HashMap.java:883) at java.util.HashMap$EntryIterator.next(HashMap.java:881) at org.apache.geronimo.cxf.GeronimoQueryHandler.updatePorts(GeronimoQueryHandler.java:93) at org.apache.geronimo.cxf.GeronimoQueryHandler.updateServices(GeronimoQueryHandler.java:73) at org.apache.geronimo.cxf.GeronimoQueryHandler.updateDefinition(GeronimoQueryHandler.java:55) at org.apache.cxf.transport.http.WSDLQueryHandler.writeResponse(WSDLQueryHandler.java:130) at org.apache.geronimo.cxf.CXFWebServiceContainer.getWsdl(CXFWebServiceContainer.java:118) at org.apache.geronimo.webservices.WebServiceContainerInvoker.service(WebServiceContainerInvoker.java:74) at org.apache.geronimo.webservices.POJOWebServiceServlet.service(POJOWebServiceServlet.java:79) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1098) at com.sun.ts.tests.jaxws.wsi.w2j.document.literal.swatest.CheckHttpMimeHeadersFilter.doFilter(CheckHttpMimeHeadersFilter.java:68) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:58) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:510) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3124) Reminder: Switch Axis2 stack back to axis2-saaj from Sun SAAJ Impl
[ https://issues.apache.org/jira/browse/GERONIMO-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-3124: -- Regression: (was: [Regression]) Patch Info: (was: [Patch Available]) Affects Version/s: (was: Wish List) 2.0 Fix Version/s: (was: 2.0) 2.1 Defer this issue as the original prob is already resolved - and we are using axis2's saaj for axis2 in most cases. In certain cases, like some jaxr test cases, we are still using sun's saaj-impl for axis2 but it is too risky to make config/classloader changes related to this late in the release to not break anything. unmark patch avail and regression here as patch cannot be committed as it is and this is not a regression prob. Reminder: Switch Axis2 stack back to axis2-saaj from Sun SAAJ Impl --- Key: GERONIMO-3124 URL: https://issues.apache.org/jira/browse/GERONIMO-3124 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0 Reporter: Donald Woods Assignee: Lin Sun Fix For: 2.1 Attachments: G3124.patch, patch.patch This is a placeholder, so we don't forget to rollback the temporary changes made to use the Sun SAAJ Impl instead of the axis2-saaj jar. Most of the following changes will have to be rolled back - Revisions 530234, 531260 Author: dims Date: Wed Apr 18 19:18:50 2007 New Revision: 530234 URL: http://svn.apache.org/viewvc?view=revrev=530234 Log: Switch Axis2 over to sun's saaj jars as well. Once we stabilize, we can switch back to see what breaks with Axis2's saaj impl jars Modified: geronimo/server/trunk/configs/axis2-deployer/src/plan/plan.xml geronimo/server/trunk/configs/axis2/pom.xml geronimo/server/trunk/modules/geronimo-webservices/src/main/java/org/apache/geronimo/webservices/saaj/SAAJFactoryFinder.java Modified: geronimo/server/trunk/configs/axis2-deployer/src/plan/plan.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/axis2-deployer/src/plan/plan.xml?view=diffrev=530234r1=530233r2=530234 == --- geronimo/server/trunk/configs/axis2-deployer/src/plan/plan.xml (original) +++ geronimo/server/trunk/configs/axis2-deployer/src/plan/plan.xml Wed Apr 18 19:18:50 2007 @@ -83,19 +83,11 @@ /dependency dependency groupIdorg.apache.axis2/groupId -artifactIdaxis2-saaj/artifactId Modified: geronimo/server/trunk/configs/axis2/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/axis2/pom.xml?view=diffrev=530234r1=530233r2=530234 == --- geronimo/server/trunk/configs/axis2/pom.xml (original) +++ geronimo/server/trunk/configs/axis2/pom.xml Wed Apr 18 19:18:50 2007 @@ -110,19 +110,11 @@ /dependency dependency groupIdorg.apache.axis2/groupId -artifactIdaxis2-saaj/artifactId -/dependency Modified: geronimo/server/trunk/modules/geronimo-webservices/src/main/java/org/apache/geronimo/webservices/saaj/SAAJFactoryFinder.java URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-webservices/src/main/java/org/apache/geronimo/webservices/saaj/SAAJFactoryFinder.java?view=diffrev=530234r1=530233r2=530234 == --- geronimo/server/trunk/modules/geronimo-webservices/src/main/java/org/apache/geronimo/webservices/saaj/SAAJFactoryFinder.java (original) +++ geronimo/server/trunk/modules/geronimo-webservices/src/main/java/org/apache/geronimo/webservices/saaj/SAAJFactoryFinder.java Wed Apr 18 19:18:50 2007 @@ -32,12 +32,12 @@ org.apache.axis.soap.SOAPFactoryImpl, org.apache.axis.soap.SOAPConnectionFactoryImpl, org.apache.axis.soap.SAAJMetaFactoryImpl)); -SAAJ_FACTORIES.put(SAAJUniverse.Type.AXIS2.toString(), - createSAAJInfo(org.apache.axis2.saaj.MessageFactoryImpl, - org.apache.axis2.saaj.SOAPFactoryImpl, - org.apache.axis2.saaj.SOAPConnectionFactoryImpl, - org.apache.axis2.saaj.SAAJMetaFactoryImpl)); -SAAJ_FACTORIES.put(SAAJUniverse.Type.SUN.toString(), +SAAJ_FACTORIES.put(SAAJUniverse.Type.AXIS2.toString(), +
Re: [VOTE] Release XBean 3.1
+1 On 8/1/07, David Blevins [EMAIL PROTECTED] wrote: I have tagged an XBean 3.1 version at http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.1/ Binaries: http://people.apache.org/~dblevins/stage/org/apache/xbean/ Please review the tag/binaries and vote for this release. Once the vote passes, I will upload the release to the repository. [ ] +1 Release XBean 3.1 [ ] +/- 0 [ ] -1 Do not release Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
That's the info I was looking for. I'll fix this. -David On Aug 1, 2007, at 9:03 AM, David Jencks wrote: And section 13.3.7.2.1 very clearly states in great detail that more specific xml overrides less specific xml. So IMO there's a bug in openejb's current behavior. thanks david jencks On Aug 1, 2007, at 9:00 AM, David Jencks wrote: The spec is clear about this case anyway, on p 336 it says Atransactionattributemaybespecifiedonamethodof thebeanclass tooverridethetransaction attribute value explicitly or implicitly specified on the bean class. thanks david jencks On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote: David... Any idea how this will be handled in EJB 3 beans when the transaction attributes are defined in the annotations? If I were to define a transaction annotation for the whole bean and another for an individual method, would the method level attribute be ignored? Chris On 8/1/07, David Blevins [EMAIL PROTECTED] wrote: On Jul 25, 2007, at 7:57 PM, Christopher Blythe wrote: I was working on DayTrader 2.0 when I found that the resetTrade method for all of the runtime modes (with the exception of Direct mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0 and noticed the same behavior. I then went back and deploy DT 1.2 on GMO 1.1.1 and resetTrade worked for EJB mode like a champ. If you look in the ejb-jar.xml and check out the container transactions, you see the following... container-transaction method ejb-nameTradeEJB/ejb-name method-intfRemote/method-intf method-nameresetTrade/method-name method-params method-paramboolean/method-param /method-params /method ... trans-attributeNotSupported/trans-attribute /container-transaction container-transaction ... method ejb-nameTradeEJB/ejb-name method-name*/method-name /method ... trans-attributeRequired/trans-attribute /container-transaction Took me a couple hours to dig through this but basically what is happening is that the second transaction attribute declaration for TradeEJB (method *) is essentially overwriting the first (method resetTrade(boolean)). These are processed in the order they are declared so fixing it should be as easy as moving the resetTrade (boolean) declaration to be after the * declaration. If you know of a part of the EJB spec that is relevant I'm definitely all ears -- as far as I know it's valid to process them in the order they are declared. For the future (not 2.0) and provided it isn't explicitly prohibited by the spec, we could possibly order the container-transaction declarations for an ejb from least specific to most specific and process them that way -- like we do for interceptor-bindings. If you had some time to do some leg work on digging through the spec that'd be great. -David The impl for resetTrade in the TradeEJB session bean calls to the TradeDirect code in order to perform the reset. The TradeDirect code manages the transaction commits on its own. That is why the resetTrade method in TradeEJB was marked as NotSupported. As I mentioned earlier, this was recognized by the Geronimo 1.1.1 container; however, it looks like the Geronimo 2.0 container is not picking this up. A look at some of the OpenEJB trace information seems to confirm this... 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/ TradeEJB with identity null 22:11:51,437 INFO [Transaction] TX Required: Started transaction [EMAIL PROTECTED] 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying pooled connection MCI: [EMAIL PROTECTED] e MC: [EMAIL PROTECTED] from pool: org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercept or @56525652 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying connection from pool null for managed connection [EMAIL PROTECTED] to tx caching interceptor org.apache.geronimo.connector.outbound.TransactionCachingInterceptor @5 c005c00 22:11:51,546 ERROR [Log] Error: Failed to reset Trade Just for reference, here is the exception that is being thrown 22:51:04,031 ERROR [Log] Error: Failed to reset Trade com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid during global transaction com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid during global transaction at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152) at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151) at org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit (ManagedXAConnection.java :104) at org.tranql.connector.AbstractManagedConnection $LocalTransactionImpl.commit(AbstractManagedConnection.java :192) at
InstallationContext.getInstallationDescriptionExtensions not returning all extensions.
Hi, I posted this on the user list and meant to get it on the dev list. I have a new Service Engine and i have defined some extensions in my jbi.xml like below: component . Component info . !-- Installation Description Extensions -- observer:Observertrue/observer:Observer config:Configuration config:Locationlocalhost/config:Location config:Port/config:Port /config:Configuration /component The problem I am having is that when I call getInstallationDescriptorExtension during my Bootstrap init(), I only get back to following extensions: observer:Observertrue/observer:Observer The rest of the extensions are being left off. I checked out the source code and verified that what I thought I was seeing was correct. I modified the ComponentTest (under /core/servicemix-core) to compare the expected output to the actual output, also modified the component.xml used in the test to include a extension like the one above. Once I did this the unit test failed, and as expected it failed, only returning me the first extension listed. Is this expected behavior, or is this a bug? I have tested this same component with OpenESB, and it parses my Extensions fine. I looked at the spec and it doesn't really define wheter or not you can have multiple extensions, with different namespaces, or not. Let me know if I need to file a bug, or I can reach out the the OpenESB community as well and see what the expected behavior should be. Thanks -Chad -- View this message in context: http://www.nabble.com/InstallationContext.getInstallationDescriptionExtensions-not-returning-all-extensions.-tf4202093s12049.html#a11952026 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release XBean 3.1
+1 On 8/1/07, David Blevins [EMAIL PROTECTED] wrote: I have tagged an XBean 3.1 version at http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.1/ Binaries: http://people.apache.org/~dblevins/stage/org/apache/xbean/ Please review the tag/binaries and vote for this release. Once the vote passes, I will upload the release to the repository. [ ] +1 Release XBean 3.1 [ ] +/- 0 [ ] -1 Do not release Here's my +1 -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
RELEASE NOTES 2.0
Hi all, This is what we have so far for the Geronimo v2.0 Release Notes http://cwiki.apache.org/GMOxDOC20/release-notes-20txt.html I added some sections and moved around others. This is going to be the next full-blown release since v1.1.1 so there is a lot of land to cover. This is the only document that tells the user all the new stuff we added to Geronimo. Pls chime in and help beef up the Significant Changes in the 2.0 Release section. Either update the wiki directly or reply to this thread and I'll consolidate all the updates. Cheers! Hernan
Daytrader deployment issues
Greetings, I am having some issues while attempting to deploy Daytrader, both with the latest trunk and the 1.2 branch versions, on respective versions of Geronimo. Both of these revolve around the inability to locate one of the dependencies, ge-activemq-rar. For the 1.2 version I get the following [EMAIL PROTECTED]:~/daytrader$ ./bin/deploy.sh Error: Unable to distribute daytrader-ear-1.2-SNAPSHOT.ear: Missing rar in repositories: org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar [EMAIL PROTECTED]:~/daytrader$ and for the latest trunk on 2.0M6 geronimo, I get the same, except it's looking for 1.1.1 version of ge-activemq-rar instead of 1.2-beta. This is the result of doing a simple mvn install on the daytrader sources, and attempting to deploy the respective ears that are created in modules/ear/target with the respecive deployment plans from the plans directory. I have attempted this with a completely empty local maven repository, with the same results. Here is a copy of a more detailed output from a deploy attempted from within the console on 1.2 Any assistance would be greatly appreciated. Deployment failed: Missing rar in repositories: org.apache.geronimo.modules /ge-activemq-rar/1.2-beta/rar Show full details Missing rar in repositories: org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar org.apache.geronimo.common.DeploymentException: Missing rar in repositories: org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar at org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java:316) at org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java:205) at org.apache.geronimo.client.builder.AppClientModuleBuilder$$FastClassByCGLIB$$93137659.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9911f9d5.createModule(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:759) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:376) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:269) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$73ff197d.getDeploymentPlan(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:595)
Re: Daytrader deployment issues
I'm attempting to get it to run on geronimo-tomcat-j2ee-1.2-beta On 8/1/07, Christopher Blythe [EMAIL PROTECTED] wrote: Erik... What version of Geronimo are you trying to install on? The plan files for DayTrader 1.2 are specific to Geronimo 1.2-beta. Chris On 8/1/07, Erik B. Craig [EMAIL PROTECTED] wrote: Greetings, I am having some issues while attempting to deploy Daytrader, both with the latest trunk and the 1.2 branch versions, on respective versions of Geronimo. Both of these revolve around the inability to locate one of the dependencies, ge-activemq-rar. For the 1.2 version I get the following [EMAIL PROTECTED]:~/daytrader$ ./bin/deploy.sh Error: Unable to distribute daytrader-ear-1.2-SNAPSHOT.ear: Missing rar in repositories: org.apache.geronimo.modules /ge-activemq-rar/1.2-beta/rar [EMAIL PROTECTED]:~/daytrader$ and for the latest trunk on 2.0M6 geronimo, I get the same, except it's looking for 1.1.1 version of ge-activemq-rar instead of 1.2-beta . This is the result of doing a simple mvn install on the daytrader sources, and attempting to deploy the respective ears that are created in modules/ear/target with the respecive deployment plans from the plans directory. I have attempted this with a completely empty local maven repository, with the same results. Here is a copy of a more detailed output from a deploy attempted from within the console on 1.2 Any assistance would be greatly appreciated. Deployment failed: Missing rar in repositories: org.apache.geronimo.modules /ge-activemq-rar/1.2-beta/rar Show full details Missing rar in repositories: org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar org.apache.geronimo.common.DeploymentException: Missing rar in repositories: org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar at org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java:316) at org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java :205) at org.apache.geronimo.client.builder.AppClientModuleBuilder$$FastClassByCGLIB$$93137659.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java :96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9911f9d5.createModule(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:759) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:376) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:269) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$73ff197d.getDeploymentPlan (generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:127) at
[jira] Closed: (GERONIMO-2771) GlassFish specs are being included in 2.0-M2 builds
[ https://issues.apache.org/jira/browse/GERONIMO-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor closed GERONIMO-2771. - Resolution: Fixed Fix Version/s: (was: Verification Required) Closing this issue as the list of the Glassfish jars in the previous comment is up-to-date and it matches what will be released with Geronimo 2.0. GlassFish specs are being included in 2.0-M2 builds --- Key: GERONIMO-2771 URL: https://issues.apache.org/jira/browse/GERONIMO-2771 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0-M6 Reporter: Kevan Miller Assignee: Jarek Gawor Priority: Minor Fix For: 2.0 Several GlassFish spec jars are being included in Geronimo 2.0 repos. I'm guessing they are being pulled in by CXF, but have not investigated. Not too big of a deal, but we should do a bit of housekeeping to eliminate duplication. Some like mail could potentially cause problems... Potential redundancies include: activation-1.1.jar mail-1.4.jar saaj-api-1.3.jar jaxws-api-2.0.jar jaxb-api-2.0.2.jar jaxb-api-2.0.jar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Daytrader deployment issues
Erik... What version of Geronimo are you trying to install on? The plan files for DayTrader 1.2 are specific to Geronimo 1.2-beta. Chris On 8/1/07, Erik B. Craig [EMAIL PROTECTED] wrote: Greetings, I am having some issues while attempting to deploy Daytrader, both with the latest trunk and the 1.2 branch versions, on respective versions of Geronimo. Both of these revolve around the inability to locate one of the dependencies, ge-activemq-rar. For the 1.2 version I get the following [EMAIL PROTECTED]:~/daytrader$ ./bin/deploy.sh Error: Unable to distribute daytrader-ear-1.2-SNAPSHOT.ear: Missing rar in repositories: org.apache.geronimo.modules /ge-activemq-rar/1.2-beta/rar [EMAIL PROTECTED]:~/daytrader$ and for the latest trunk on 2.0M6 geronimo, I get the same, except it's looking for 1.1.1 version of ge-activemq-rar instead of 1.2-beta . This is the result of doing a simple mvn install on the daytrader sources, and attempting to deploy the respective ears that are created in modules/ear/target with the respecive deployment plans from the plans directory. I have attempted this with a completely empty local maven repository, with the same results. Here is a copy of a more detailed output from a deploy attempted from within the console on 1.2 Any assistance would be greatly appreciated. Deployment failed: Missing rar in repositories: org.apache.geronimo.modules /ge-activemq-rar/1.2-beta/rar Show full details Missing rar in repositories: org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar org.apache.geronimo.common.DeploymentException: Missing rar in repositories: org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar at org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java:316) at org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java:205) at org.apache.geronimo.client.builder.AppClientModuleBuilder$$FastClassByCGLIB$$93137659.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9911f9d5.createModule(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:759) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:376) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:269) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$73ff197d.getDeploymentPlan (generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy
Re: [VOTE] Release XBean 3.1
+1 On 8/1/07, Guillaume Nodet [EMAIL PROTECTED] wrote: +1 On 8/1/07, David Blevins [EMAIL PROTECTED] wrote: I have tagged an XBean 3.1 version at http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.1/ Binaries: http://people.apache.org/~dblevins/stage/org/apache/xbean/ Please review the tag/binaries and vote for this release. Once the vote passes, I will upload the release to the repository. [ ] +1 Release XBean 3.1 [ ] +/- 0 [ ] -1 Do not release Here's my +1 -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ -- James --- http://macstrac.blogspot.com/
Re: Problems trying to release tx + cx component jars
Cool :-) --jason On Aug 1, 2007, at 10:00 AM, David Jencks wrote: Jvanzyl has offered to try to get the release plugin to stage these. thanks david jencks On Aug 1, 2007, at 2:03 AM, David Jencks wrote: I tried to get a release candidate together for the tx and cx component jars but have failed. maven-release-plugin tags the jars into genesis and there seems to be way to override this, despite the documentation. http:// jira.codehaus.org/browse/MRELEASE-272 The release procedure at http://cwiki.apache.org/GMOxPMGT/release- branching-process.html works up to the point where I try to execute http://cwiki.apache.org/GMOxPMGT/release-branching-process.html which however fails because the legal files aren't getting into the source jar. If anyone else wants to try, the possibly ready to try to release stuff is at https://svn.apache.org/repos/asf/geronimo/components/ txmanager/branches/2.0 thanks david jencks
Re: Daytrader deployment issues
And you're using the daytrader-1.2-beta-plan.xml file right? Basically, the message you are getting is complaining that it cannot find that specified rar module in the repository. You can double check to see if it is there by checking the repository folder or via the Admin console under the modules section. org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar If they happened to change the module name/version under Geronimo 1.2, all you need to do is update the plan file appropriately. Let me know if that is the case and I can commit the change. On 8/1/07, Erik B. Craig [EMAIL PROTECTED] wrote: I'm attempting to get it to run on geronimo-tomcat-j2ee-1.2-beta On 8/1/07, Christopher Blythe [EMAIL PROTECTED] wrote: Erik... What version of Geronimo are you trying to install on? The plan files for DayTrader 1.2 are specific to Geronimo 1.2-beta. Chris On 8/1/07, Erik B. Craig [EMAIL PROTECTED] wrote: Greetings, I am having some issues while attempting to deploy Daytrader, both with the latest trunk and the 1.2 branch versions, on respective versions of Geronimo. Both of these revolve around the inability to locate one of the dependencies, ge-activemq-rar. For the 1.2 version I get the following [EMAIL PROTECTED]:~/daytrader$ ./bin/deploy.sh Error: Unable to distribute daytrader-ear-1.2-SNAPSHOT.ear: Missing rar in repositories: org.apache.geronimo.modules /ge-activemq-rar/1.2-beta/rar [EMAIL PROTECTED]:~/daytrader$ and for the latest trunk on 2.0M6 geronimo, I get the same, except it's looking for 1.1.1 version of ge-activemq-rar instead of 1.2-beta. This is the result of doing a simple mvn install on the daytrader sources, and attempting to deploy the respective ears that are created in modules/ear/target with the respecive deployment plans from the plans directory. I have attempted this with a completely empty local maven repository, with the same results. Here is a copy of a more detailed output from a deploy attempted from within the console on 1.2 Any assistance would be greatly appreciated. Deployment failed: Missing rar in repositories: org.apache.geronimo.modules /ge-activemq-rar/1.2-beta/rar Show full details Missing rar in repositories: org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar org.apache.geronimo.common.DeploymentException: Missing rar in repositories: org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar at org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java:316) at org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java :205) at org.apache.geronimo.client.builder.AppClientModuleBuilder$$FastClassByCGLIB$$93137659.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java :96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9911f9d5.createModule(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java :759) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:376) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:269) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java :96) at
Re: [VOTE] Release Genesis 1.2
A brief look at the release tgz looks good. +1 --jason On Jul 31, 2007, at 8:21 PM, Matt Hogstrom wrote: Please review and vote on the Genesis release of 1.2. At this location you will find a tar ball with the repository and related artifacts that will be released. http://people.apache.org/~hogstrom/genesis-rc1 Branch with source is at https://svn.apache.org/repos/asf/geronimo/ genesis/branches/1.2/ [ ] +1 Release Genesis 1.2 [ ] 0 No opinion [ ] -1 Do not release this artifact (please provide reason Vote will complete at 2330 ET, August 3 2007.
Re: [VOTE : DISCUSS] Release Genesis 1.2
Um, good point, but lets fix that in 1.3 and let 1.2 be ASIS. --jason On Aug 1, 2007, at 6:19 AM, Anita Kulshreshtha wrote: I would like to know why we do not use a single jdk version for all default configurations. The maven-compiler and maven-idea plugins use 1.4 whereas maven-javadoc plugin uses 1.5. Thanks Anita __ __ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz
[jira] Commented: (GERONIMODEVTOOLS-125) Unable to upgrade from 1.1 to 1.2 Release through Eclipse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517058 ] Bill Middleton commented on GERONIMODEVTOOLS-125: - The problem continues in Eclipse version 3.3.0 (Europa) when doing a clean install of the IDE for Java EE Developers bundle when attempting to add the Geronimo server adapter. I am adding this comment because: 1) I see this issue as a *severe* impediment to adoption of Geronimo (and its variants like IBM Websphere Application Server Comunity Edition) in the developer community. This problem alone virtually neutralizes the project's guiding principle that Geronimo Integrates with the best open source tooling available like Eclipse. 2) Search engines need to pick up on new keywords in 3.3 that are different from those originally reported in 3.2 So, to re-state the issue in 3.3 terms: 1. Clean install of Eclipse 3.3 Java EE bundle from the Europa release as available here: http://www.eclipse.org/downloads/moreinfo/jee.php 2.. Attempt to add a Geronimo server using the Define a New Server dialog, then selecting Download additional server adapters, then selecting org.apache.geronimo.feature. (This choice should display a more meaningful description BTW) The download and install runs, but after restarting, there are no new options available in the Apache folder in the dialog. Under the Product Configuration, the red 'x' shows on the org.apache.geronimo.feature (v1.2.0) plug-in and the status under properties shows the long list of messages originally reported starting with: org.apache.geronimo.deployment.model version 1.1.0 referenced by this feature is missing. The work-around (as posted earlier) is to simply download the most recent version of the plug-in from the site below, then extracting it directly to the Eclipse install directory: http://people.apache.org/dist/geronimo/eclipse/unstable/ A v1.1 and v2.0 Geronimo entry will be available under the Apache folder in the new server dialog. However, the org.apache.geronimo.feature option still remains in the download additional server adapters dialog. Unable to upgrade from 1.1 to 1.2 Release through Eclipse - Key: GERONIMODEVTOOLS-125 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-125 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.2.0 Environment: Linux (JDK 1.4.2) Windows XP (JDK 1.4.2, 1.5.0, 1.6.0) Reporter: Reiner Kappenberger Priority: Critical I've performed the following tasks: 1. Fresh Install of Eclipse (3.2.1) (removed previous eclipse workspace 2. Update eclipse 3. Install Calisto Bundle 4. Install Geronimo support through Don't see your server listed link in Add Server Runtime 5. Update Eclipse to latest version(s) During this latest update I receive the error that files cannot be created. In the configuration I receive the following for the org.apache.geronimo.feature (v1.2.0): Plug-in org.apache.geronimo.deployment.model version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.runtime.v1 version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.deployment.model.edit version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.v11.deployment.model.edit version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.common.deployment.model.edit version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.v11.deployment.model version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.common.deployment.model version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.v11.ui version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.v11.core version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.v1.ui version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.v1.core version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.ui version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.st.core version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.runtime.v11 version 1.1.0 referenced by this feature is missing. Plug-in org.apache.geronimo.runtime.common version 1.1.0 referenced by this feature is missing. Reiner -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3365) config.xml condition vs. load attribute issues
config.xml condition vs. load attribute issues
--
Key: GERONIMO-3365
URL: https://issues.apache.org/jira/browse/GERONIMO-3365
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Jarek Gawor
The initial config.xml contains the following condition:
module condition=props.getProperty('org.apache.geronimo.jaxws.provider',
'axis2') == 'axis2'
name=org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car
But after the server is started and stopped for the first time this entry is
rewritten as:
module condition=props.getProperty('org.apache.geronimo.jaxws.provider',
'axis2') == 'axis2' load=false
name=org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car
The 'load' attribute is added which invalidates the specified condition.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
David... Do you have a JIRA for this yet? On 8/1/07, David Blevins [EMAIL PROTECTED] wrote: That's the info I was looking for. I'll fix this. -David On Aug 1, 2007, at 9:03 AM, David Jencks wrote: And section 13.3.7.2.1 very clearly states in great detail that more specific xml overrides less specific xml. So IMO there's a bug in openejb's current behavior. thanks david jencks On Aug 1, 2007, at 9:00 AM, David Jencks wrote: The spec is clear about this case anyway, on p 336 it says Atransactionattributemaybespecifiedonamethodof thebeanclass tooverridethetransaction attribute value explicitly or implicitly specified on the bean class. thanks david jencks On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote: David... Any idea how this will be handled in EJB 3 beans when the transaction attributes are defined in the annotations? If I were to define a transaction annotation for the whole bean and another for an individual method, would the method level attribute be ignored? Chris On 8/1/07, David Blevins [EMAIL PROTECTED] wrote: On Jul 25, 2007, at 7:57 PM, Christopher Blythe wrote: I was working on DayTrader 2.0 when I found that the resetTrade method for all of the runtime modes (with the exception of Direct mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0 and noticed the same behavior. I then went back and deploy DT 1.2 on GMO 1.1.1 and resetTrade worked for EJB mode like a champ. If you look in the ejb-jar.xml and check out the container transactions, you see the following... container-transaction method ejb-nameTradeEJB/ejb-name method-intfRemote/method-intf method-nameresetTrade/method-name method-params method-paramboolean/method-param /method-params /method ... trans-attributeNotSupported/trans-attribute /container-transaction container-transaction ... method ejb-nameTradeEJB/ejb-name method-name*/method-name /method ... trans-attributeRequired/trans-attribute /container-transaction Took me a couple hours to dig through this but basically what is happening is that the second transaction attribute declaration for TradeEJB (method *) is essentially overwriting the first (method resetTrade(boolean)). These are processed in the order they are declared so fixing it should be as easy as moving the resetTrade (boolean) declaration to be after the * declaration. If you know of a part of the EJB spec that is relevant I'm definitely all ears -- as far as I know it's valid to process them in the order they are declared. For the future (not 2.0) and provided it isn't explicitly prohibited by the spec, we could possibly order the container-transaction declarations for an ejb from least specific to most specific and process them that way -- like we do for interceptor-bindings. If you had some time to do some leg work on digging through the spec that'd be great. -David The impl for resetTrade in the TradeEJB session bean calls to the TradeDirect code in order to perform the reset. The TradeDirect code manages the transaction commits on its own. That is why the resetTrade method in TradeEJB was marked as NotSupported. As I mentioned earlier, this was recognized by the Geronimo 1.1.1 container; however, it looks like the Geronimo 2.0 container is not picking this up. A look at some of the OpenEJB trace information seems to confirm this... 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/ TradeEJB with identity null 22:11:51,437 INFO [Transaction] TX Required: Started transaction [EMAIL PROTECTED] 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying pooled connection MCI: [EMAIL PROTECTED] e MC: [EMAIL PROTECTED] from pool: org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercept or @56525652 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying connection from pool null for managed connection [EMAIL PROTECTED] to tx caching interceptor org.apache.geronimo.connector.outbound.TransactionCachingInterceptor @5 c005c00 22:11:51,546 ERROR [Log] Error: Failed to reset Trade Just for reference, here is the exception that is being thrown 22:51:04,031 ERROR [Log] Error: Failed to reset Trade com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid during global transaction com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid during global transaction at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152) at
[jira] Updated: (GERONIMO-3365) config.xml condition vs. load attribute issues
[
https://issues.apache.org/jira/browse/GERONIMO-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor updated GERONIMO-3365:
--
Priority: Critical (was: Major)
Affects Version/s: 2.0-M7
config.xml condition vs. load attribute issues
--
Key: GERONIMO-3365
URL: https://issues.apache.org/jira/browse/GERONIMO-3365
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.0-M7
Reporter: Jarek Gawor
Priority: Critical
The initial config.xml contains the following condition:
module condition=props.getProperty('org.apache.geronimo.jaxws.provider',
'axis2') == 'axis2'
name=org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car
But after the server is started and stopped for the first time this entry is
rewritten as:
module condition=props.getProperty('org.apache.geronimo.jaxws.provider',
'axis2') == 'axis2' load=false
name=org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car
The 'load' attribute is added which invalidates the specified condition.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Daytrader deployment issues
Errmm, it looks like it's specific to my environment (Ubuntu 7.x, Sun JDK 1.5 release 11), I just tried it on my Mac (Mac OS 10.4.10, Apple JDK 1.5release 5) and it was A-OK. When I figure out the issue, I'll post it. On 8/1/07, Christopher Blythe [EMAIL PROTECTED] wrote: And you're using the daytrader-1.2-beta-plan.xml file right? Basically, the message you are getting is complaining that it cannot find that specified rar module in the repository. You can double check to see if it is there by checking the repository folder or via the Admin console under the modules section. org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar If they happened to change the module name/version under Geronimo 1.2, all you need to do is update the plan file appropriately. Let me know if that is the case and I can commit the change. On 8/1/07, Erik B. Craig [EMAIL PROTECTED] wrote: I'm attempting to get it to run on geronimo-tomcat-j2ee-1.2-beta On 8/1/07, Christopher Blythe [EMAIL PROTECTED] wrote: Erik... What version of Geronimo are you trying to install on? The plan files for DayTrader 1.2 are specific to Geronimo 1.2-beta. Chris On 8/1/07, Erik B. Craig [EMAIL PROTECTED] wrote: Greetings, I am having some issues while attempting to deploy Daytrader, both with the latest trunk and the 1.2 branch versions, on respective versions of Geronimo. Both of these revolve around the inability to locate one of the dependencies, ge-activemq-rar. For the 1.2 version I get the following [EMAIL PROTECTED]:~/daytrader$ ./bin/deploy.sh Error: Unable to distribute daytrader-ear-1.2-SNAPSHOT.ear: Missing rar in repositories: org.apache.geronimo.modules /ge-activemq-rar/1.2-beta/rar [EMAIL PROTECTED]:~/daytrader$ and for the latest trunk on 2.0M6 geronimo, I get the same, except it's looking for 1.1.1 version of ge-activemq-rar instead of 1.2-beta . This is the result of doing a simple mvn install on the daytrader sources, and attempting to deploy the respective ears that are created in modules/ear/target with the respecive deployment plans from the plans directory. I have attempted this with a completely empty local maven repository, with the same results. Here is a copy of a more detailed output from a deploy attempted from within the console on 1.2 Any assistance would be greatly appreciated. Deployment failed: Missing rar in repositories: org.apache.geronimo.modules /ge-activemq-rar/1.2-beta/rar Show full details Missing rar in repositories: org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar org.apache.geronimo.common.DeploymentException: Missing rar in repositories: org.apache.geronimo.modules/ge-activemq-rar/1.2-beta/rar at org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java:316) at org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java :205) at org.apache.geronimo.client.builder.AppClientModuleBuilder$$FastClassByCGLIB$$93137659.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java :96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9911f9d5.createModule(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules (EARConfigBuilder.java :759) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:376) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java :269) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
Re: [VOTE] Release Genesis 1.2
+1 Joe Matt Hogstrom wrote: Please review and vote on the Genesis release of 1.2. At this location you will find a tar ball with the repository and related artifacts that will be released. http://people.apache.org/~hogstrom/genesis-rc1 Branch with source is at https://svn.apache.org/repos/asf/geronimo/genesis/branches/1.2/ [ ] +1 Release Genesis 1.2 [ ] 0 No opinion [ ] -1 Do not release this artifact (please provide reason Vote will complete at 2330 ET, August 3 2007.
Re: relation of camel and servicemix?
On 8/1/07, cui hailin [EMAIL PROTECTED] wrote: so EIP component in servicemix compare with camel? Yes; they are conceptually similar though Camel's become a bit more full featured, plus you can use Camel outside of JBI - such as inside a JMS client or broker, or inside your web services client EIP component in servicemix implement without camel. servicemix integrate camel for instead of EIP component? ServiceMix integrates with everything pretty much :) So both integrate with ServiceMix I'd recommend looking at Camel rather than the EIP component going forward though; as Camel has more EIP patterns implemented allows either Java or XML to be used to define the routing rules. We should probably merge the logic from servicemix-eip into the Camel project and unify them both. -- James --- http://macstrac.blogspot.com/
[jira] Commented: (GERONIMO-1581) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with /
[ https://issues.apache.org/jira/browse/GERONIMO-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517083 ] Jarek Gawor commented on GERONIMO-1581: --- The JSR109 1.2 is pretty clear that jaxrpc-mapping-file or wsdl-file should not start with /. We can discuss if this still should be changed but for now (for Geronimo 2.0) I decided to leave how it is. I only verified that paths that start with / produce nice error messages and do not return NPEs or other unclear messages. webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with / --- Key: GERONIMO-1581 URL: https://issues.apache.org/jira/browse/GERONIMO-1581 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, webservices Affects Versions: 1.1.2 Reporter: Aaron Mulder Priority: Critical Fix For: Verification Required Attachments: WSDescriptorParser.patch It seems like it ought to be legal for the wsdl-file value to start with a / (in fact, the book I got my example from uses that). However, in Geronimo, that results in a java.lang.RuntimeException: Could not open stream to wsdl file. If we can't handle the preceding /, we should probably just strip it if it's there and then go on as normal (without the leading / everything is fine). The same appears to be true for the jaxrpc-mapping-file though it produces an NPE instead of the RuntimeException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1581) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with /
[ https://issues.apache.org/jira/browse/GERONIMO-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-1581: -- Fix Version/s: (was: Verification Required) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with / --- Key: GERONIMO-1581 URL: https://issues.apache.org/jira/browse/GERONIMO-1581 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, webservices Affects Versions: 1.1.2 Reporter: Aaron Mulder Priority: Critical Attachments: WSDescriptorParser.patch It seems like it ought to be legal for the wsdl-file value to start with a / (in fact, the book I got my example from uses that). However, in Geronimo, that results in a java.lang.RuntimeException: Could not open stream to wsdl file. If we can't handle the preceding /, we should probably just strip it if it's there and then go on as normal (without the leading / everything is fine). The same appears to be true for the jaxrpc-mapping-file though it produces an NPE instead of the RuntimeException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
On Aug 1, 2007, at 1:49 PM, Christopher Blythe wrote: David... Do you have a JIRA for this yet? Added one here http://issues.apache.org/jira/browse/OPENEJB-623 -David On 8/1/07, David Blevins [EMAIL PROTECTED] wrote:That's the info I was looking for. I'll fix this. -David On Aug 1, 2007, at 9:03 AM, David Jencks wrote: And section 13.3.7.2.1 very clearly states in great detail that more specific xml overrides less specific xml. So IMO there's a bug in openejb's current behavior. thanks david jencks On Aug 1, 2007, at 9:00 AM, David Jencks wrote: The spec is clear about this case anyway, on p 336 it says Atransactionattributemaybespecifiedonamethodof thebeanclass tooverridethetransaction attribute value explicitly or implicitly specified on the bean class. thanks david jencks On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote: David... Any idea how this will be handled in EJB 3 beans when the transaction attributes are defined in the annotations? If I were to define a transaction annotation for the whole bean and another for an individual method, would the method level attribute be ignored? Chris On 8/1/07, David Blevins [EMAIL PROTECTED] wrote: On Jul 25, 2007, at 7:57 PM, Christopher Blythe wrote: I was working on DayTrader 2.0 when I found that the resetTrade method for all of the runtime modes (with the exception of Direct mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0 and noticed the same behavior. I then went back and deploy DT 1.2 on GMO 1.1.1 and resetTrade worked for EJB mode like a champ. If you look in the ejb-jar.xml and check out the container transactions, you see the following... container-transaction method ejb-nameTradeEJB/ejb-name method-intfRemote/method-intf method-nameresetTrade/method-name method-params method-paramboolean/method-param /method-params /method ... trans-attributeNotSupported/trans-attribute /container-transaction container-transaction ... method ejb-nameTradeEJB/ejb-name method-name*/method-name /method ... trans-attributeRequired/trans-attribute /container-transaction Took me a couple hours to dig through this but basically what is happening is that the second transaction attribute declaration for TradeEJB (method *) is essentially overwriting the first (method resetTrade(boolean)). These are processed in the order they are declared so fixing it should be as easy as moving the resetTrade (boolean) declaration to be after the * declaration. If you know of a part of the EJB spec that is relevant I'm definitely all ears -- as far as I know it's valid to process them in the order they are declared. For the future (not 2.0) and provided it isn't explicitly prohibited by the spec, we could possibly order the container-transaction declarations for an ejb from least specific to most specific and process them that way -- like we do for interceptor-bindings. If you had some time to do some leg work on digging through the spec that'd be great. -David The impl for resetTrade in the TradeEJB session bean calls to the TradeDirect code in order to perform the reset. The TradeDirect code manages the transaction commits on its own. That is why the resetTrade method in TradeEJB was marked as NotSupported. As I mentioned earlier, this was recognized by the Geronimo 1.1.1 container; however, it looks like the Geronimo 2.0 container is not picking this up. A look at some of the OpenEJB trace information seems to confirm this... 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/ TradeEJB with identity null 22:11:51,437 INFO [Transaction] TX Required: Started transaction [EMAIL PROTECTED] 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying pooled connection MCI: [EMAIL PROTECTED] e MC: [EMAIL PROTECTED] from pool: org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercept or @56525652 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying connection from pool null for managed connection [EMAIL PROTECTED] to tx caching interceptor org.apache.geronimo.connector.outbound.TransactionCachingInterceptor @5 c005c00 22:11:51,546 ERROR [Log] Error: Failed to reset Trade Just for reference, here is the exception that is being thrown 22:51:04,031 ERROR [Log] Error: Failed to reset Trade com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid during global transaction com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid during global transaction at
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
On Aug 1, 2007, at 2:44 PM, David Blevins wrote: On Aug 1, 2007, at 1:49 PM, Christopher Blythe wrote: David... Do you have a JIRA for this yet? Added one here http://issues.apache.org/jira/browse/OPENEJB-623 Here click the this link to be notified of when it's fixed: http://issues.apache.org/jira/secure/ViewIssue.jspa? id=12375174watch=true -David -David On 8/1/07, David Blevins [EMAIL PROTECTED] wrote:That's the info I was looking for. I'll fix this. -David On Aug 1, 2007, at 9:03 AM, David Jencks wrote: And section 13.3.7.2.1 very clearly states in great detail that more specific xml overrides less specific xml. So IMO there's a bug in openejb's current behavior. thanks david jencks On Aug 1, 2007, at 9:00 AM, David Jencks wrote: The spec is clear about this case anyway, on p 336 it says Atransactionattributemaybespecifiedonamethodof thebeanclass tooverridethetransaction attribute value explicitly or implicitly specified on the bean class. thanks david jencks On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote: David... Any idea how this will be handled in EJB 3 beans when the transaction attributes are defined in the annotations? If I were to define a transaction annotation for the whole bean and another for an individual method, would the method level attribute be ignored? Chris On 8/1/07, David Blevins [EMAIL PROTECTED] wrote: On Jul 25, 2007, at 7:57 PM, Christopher Blythe wrote: I was working on DayTrader 2.0 when I found that the resetTrade method for all of the runtime modes (with the exception of Direct mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0 and noticed the same behavior. I then went back and deploy DT 1.2 on GMO 1.1.1 and resetTrade worked for EJB mode like a champ. If you look in the ejb-jar.xml and check out the container transactions, you see the following... container-transaction method ejb-nameTradeEJB/ejb-name method-intfRemote/method-intf method-nameresetTrade/method-name method-params method-paramboolean/method-param /method-params /method ... trans-attributeNotSupported/trans-attribute /container-transaction container-transaction ... method ejb-nameTradeEJB/ejb-name method-name*/method-name /method ... trans-attributeRequired/trans-attribute /container-transaction Took me a couple hours to dig through this but basically what is happening is that the second transaction attribute declaration for TradeEJB (method *) is essentially overwriting the first (method resetTrade(boolean)). These are processed in the order they are declared so fixing it should be as easy as moving the resetTrade (boolean) declaration to be after the * declaration. If you know of a part of the EJB spec that is relevant I'm definitely all ears -- as far as I know it's valid to process them in the order they are declared. For the future (not 2.0) and provided it isn't explicitly prohibited by the spec, we could possibly order the container-transaction declarations for an ejb from least specific to most specific and process them that way -- like we do for interceptor-bindings. If you had some time to do some leg work on digging through the spec that'd be great. -David The impl for resetTrade in the TradeEJB session bean calls to the TradeDirect code in order to perform the reset. The TradeDirect code manages the transaction commits on its own. That is why the resetTrade method in TradeEJB was marked as NotSupported. As I mentioned earlier, this was recognized by the Geronimo 1.1.1 container; however, it looks like the Geronimo 2.0 container is not picking this up. A look at some of the OpenEJB trace information seems to confirm this... 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/ TradeEJB with identity null 22:11:51,437 INFO [Transaction] TX Required: Started transaction [EMAIL PROTECTED] 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying pooled connection MCI: [EMAIL PROTECTED] e MC: [EMAIL PROTECTED] from pool: org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercept or @56525652 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying connection from pool null for managed connection [EMAIL PROTECTED] to tx caching interceptor org.apache.geronimo.connector.outbound.TransactionCachingInterceptor @5 c005c00 22:11:51,546 ERROR [Log] Error: Failed to reset Trade Just for reference, here is the exception that is being thrown 22:51:04,031 ERROR [Log] Error: Failed to reset Trade
[jira] Commented: (GERONIMO-3266) Enhance attributes schema (relates to config.xml)
[ https://issues.apache.org/jira/browse/GERONIMO-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517095 ] Jay D. McHugh commented on GERONIMO-3266: - Committed second attempt on schema file revision 561971 GERONIMO-3266 - Second revision of schema - Corrected the attributes level comment - Corrected the gbean level comment Enhance attributes schema (relates to config.xml) - Key: GERONIMO-3266 URL: https://issues.apache.org/jira/browse/GERONIMO-3266 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Create a version 1.2 of the attributes.xsd to allow for comments anywhere in the file. Are there any other enhancements that anyone would be interested in for config.xml? If we can figure out what future changes would be desired, maybe we can 'future-proof' the schema so we won't need to mess with it again (at least for a while). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release specs for JACC, JSP, Servlet
I was looking at the schemas included in the servlet specs jar: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-servlet_2.5_spec-1.1/src/main/schema/ Why are the following not included? javaee_5.xsd javaee_web_services_client_1_2.xsd Why is j2ee_web_services_1_1.xsd included? Do we need to include jsp_2.0.xsd and jsp_2.1.xsd? Thanks Anita Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469
Re: [VOTE: DISCUSS] Release specs for JACC, JSP, Servlet
Resending with the correct subject line.. Anita --- Anita Kulshreshtha [EMAIL PROTECTED] wrote: I was looking at the schemas included in the servlet specs jar: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-servlet_2.5_spec-1.1/src/main/schema/ Why are the following not included? javaee_5.xsd javaee_web_services_client_1_2.xsd Why is j2ee_web_services_1_1.xsd included? Do we need to include jsp_2.0.xsd and jsp_2.1.xsd? Thanks Anita Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469 Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/
[jira] Updated: (GERONIMO-3271) Update all users of the attributes schema to use new version
[ https://issues.apache.org/jira/browse/GERONIMO-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3271: Affects Version/s: (was: 2.0-M7) 2.1 Update all users of the attributes schema to use new version Key: GERONIMO-3271 URL: https://issues.apache.org/jira/browse/GERONIMO-3271 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3271) Update all users of the attributes schema to use new version
[ https://issues.apache.org/jira/browse/GERONIMO-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517115 ] Jay D. McHugh commented on GERONIMO-3271: - Committed - Revision 561988 Update all users of the attributes schema to use new version Key: GERONIMO-3271 URL: https://issues.apache.org/jira/browse/GERONIMO-3271 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-1265) Preserve comments added by users in the config.xml file
[ https://issues.apache.org/jira/browse/GERONIMO-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517117 ] Jay D. McHugh commented on GERONIMO-1265: - Committed revision 561989 - Added new schema (see 3266) - Added support for module level comments Changes inspired by Don Hill's patch - Thanks Don! Preserve comments added by users in the config.xml file --- Key: GERONIMO-1265 URL: https://issues.apache.org/jira/browse/GERONIMO-1265 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0-M5, 1.0, 1.1, 2.1 Reporter: John Sisson Assignee: Jay D. McHugh Attachments: geronimo-1265.patch Currently if a user adds comments to the config.xml file, they will be lost when Geronimo re-generates the file if a configuration change is made (e.g. through the web console). As a temporary measure, the code that re-generates the XML will place a warning at the top of the file warning users not to place comments in 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-3266) Enhance attributes schema (relates to config.xml)
[ https://issues.apache.org/jira/browse/GERONIMO-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3266: Affects Version/s: (was: 2.0-M7) 2.1 2.0 Enhance attributes schema (relates to config.xml) - Key: GERONIMO-3266 URL: https://issues.apache.org/jira/browse/GERONIMO-3266 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 2.0, 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Create a version 1.2 of the attributes.xsd to allow for comments anywhere in the file. Are there any other enhancements that anyone would be interested in for config.xml? If we can figure out what future changes would be desired, maybe we can 'future-proof' the schema so we won't need to mess with it again (at least for a while). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1265) Preserve comments added by users in the config.xml file
[ https://issues.apache.org/jira/browse/GERONIMO-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-1265: Assignee: Jay D. McHugh Affects Version/s: (was: 1.2) (was: 2.0-M7) 2.1 Preserve comments added by users in the config.xml file --- Key: GERONIMO-1265 URL: https://issues.apache.org/jira/browse/GERONIMO-1265 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0-M5, 1.0, 1.1, 2.1 Reporter: John Sisson Assignee: Jay D. McHugh Attachments: geronimo-1265.patch Currently if a user adds comments to the config.xml file, they will be lost when Geronimo re-generates the file if a configuration change is made (e.g. through the web console). As a temporary measure, the code that re-generates the XML will place a warning at the top of the file warning users not to place comments in it. -- 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: (GERONIMO-3266) Enhance attributes schema (relates to config.xml)
[ https://issues.apache.org/jira/browse/GERONIMO-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517095 ] Jay D. McHugh edited comment on GERONIMO-3266 at 8/1/07 4:37 PM: - Committed second attempt on schema file revision 561971 (trunk) revision 561990 (branches/2.0) Second revision of schema - Corrected the attributes level comment - Corrected the gbean level comment was: Committed second attempt on schema file revision 561971 Second revision of schema - Corrected the attributes level comment - Corrected the gbean level comment Enhance attributes schema (relates to config.xml) - Key: GERONIMO-3266 URL: https://issues.apache.org/jira/browse/GERONIMO-3266 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 2.0, 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Create a version 1.2 of the attributes.xsd to allow for comments anywhere in the file. Are there any other enhancements that anyone would be interested in for config.xml? If we can figure out what future changes would be desired, maybe we can 'future-proof' the schema so we won't need to mess with it again (at least for a while). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release specs for JACC, JSP, Servlet
+1 Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 The corresponding tar files are here: http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz The current svn locations are here: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-servlet_2.5_spec-1.1 The future svn locations will be here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1 The vote will conclude at 10:00 PM EST on Thursday, August 2nd.
[jira] Created: (GERONIMO-3366) Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry
Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry --- Key: GERONIMO-3366 URL: https://issues.apache.org/jira/browse/GERONIMO-3366 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M3 Reporter: Ted Kirby Fix For: 2.0 EntityManagerRegistryImpl gets its entityManagerRegistry from the OpenEjbSystem GBean. It needs to start afterwards. A dependency should be added in the plan to insure that this is case, otherwise it will be random, and if they start out of order, an NPE results from EntityManager.persist() calls. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3366) Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry
[ https://issues.apache.org/jira/browse/GERONIMO-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby updated GERONIMO-3366: Attachment: G3366.patch Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry --- Key: GERONIMO-3366 URL: https://issues.apache.org/jira/browse/GERONIMO-3366 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0-M3 Reporter: Ted Kirby Fix For: 2.0 Attachments: G3366.patch EntityManagerRegistryImpl gets its entityManagerRegistry from the OpenEjbSystem GBean. It needs to start afterwards. A dependency should be added in the plan to insure that this is case, otherwise it will be random, and if they start out of order, an NPE results from EntityManager.persist() calls. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Release geronimo-schema-jee_5-1.1 and geronimo-schema-jee_5-1.1
Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-schema-j2ee_1.4-1.2 -- geronimo-schema-jee_5-1.1 The corresponding tar files are here: http://people.apache.org/~prasad/geronimo-schema-j2ee_1.4-1.2.tar.gz http://people.apache.org/~prasad/geronimo-schema-jee_5-1.1.tar.gz The current svn locations (restricted access) are here: https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-j2ee_1.4/branches/1.2/ https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-jee_5/branches/1.1/ The future svn locations (restricted access) will be here: https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-j2ee_1.4/tags/geronimo-schema-j2ee_1.4-1.2 https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-jee_5/tags/geronimo-schema-jee_5-1.1 The vote will conclude at 10:00 PM EST on Saturday, August 4nd. NOTE: These schemas were built with the help of a org.codehaus.mojo/xmlbeans-maven-plugin/2.3.1 . This artifact is currently up for vote. The jar for this artifact is located at http://people.apache.org/~djencks/xmlbeans-maven-plugin-2.3.1.jar So the schema pom.xml in svn branches have not been updated with this version of the artifact yet, pending it's final vote and release. Cheers Prasad
[jira] Assigned: (GERONIMO-3366) Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry
[ https://issues.apache.org/jira/browse/GERONIMO-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3366: -- Assignee: Donald Woods Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry --- Key: GERONIMO-3366 URL: https://issues.apache.org/jira/browse/GERONIMO-3366 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0-M6 Reporter: Ted Kirby Assignee: Donald Woods Priority: Critical Fix For: 2.0, 2.1 Attachments: G3366.patch EntityManagerRegistryImpl gets its entityManagerRegistry from the OpenEjbSystem GBean. It needs to start afterwards. A dependency should be added in the plan to insure that this is case, otherwise it will be random, and if they start out of order, an NPE results from EntityManager.persist() calls. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3366) Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry
[ https://issues.apache.org/jira/browse/GERONIMO-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3366: --- Regression: [Regression] Priority: Critical (was: Major) Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry --- Key: GERONIMO-3366 URL: https://issues.apache.org/jira/browse/GERONIMO-3366 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0-M3 Reporter: Ted Kirby Priority: Critical Fix For: 2.0 Attachments: G3366.patch EntityManagerRegistryImpl gets its entityManagerRegistry from the OpenEjbSystem GBean. It needs to start afterwards. A dependency should be added in the plan to insure that this is case, otherwise it will be random, and if they start out of order, an NPE results from EntityManager.persist() calls. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3365) config.xml condition vs. load attribute issues
[
https://issues.apache.org/jira/browse/GERONIMO-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517128
]
Jarek Gawor commented on GERONIMO-3365:
---
Looks like the console (via view system modules) is forcing this rewrite.
config.xml condition vs. load attribute issues
--
Key: GERONIMO-3365
URL: https://issues.apache.org/jira/browse/GERONIMO-3365
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.0-M7
Reporter: Jarek Gawor
Priority: Critical
The initial config.xml contains the following condition:
module condition=props.getProperty('org.apache.geronimo.jaxws.provider',
'axis2') == 'axis2'
name=org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car
But after the server is started and stopped for the first time this entry is
rewritten as:
module condition=props.getProperty('org.apache.geronimo.jaxws.provider',
'axis2') == 'axis2' load=false
name=org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car
The 'load' attribute is added which invalidates the specified condition.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3365) config.xml condition vs. load attribute issues
[
https://issues.apache.org/jira/browse/GERONIMO-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517130
]
Jarek Gawor commented on GERONIMO-3365:
---
Committed a simple change to ConfigurationOverride.java to prefer the
'condition' attribute over the 'load' attribute. That is, if module has a
condition associated it with, the load attribute will not be written. Committed
revision 562001.
config.xml condition vs. load attribute issues
--
Key: GERONIMO-3365
URL: https://issues.apache.org/jira/browse/GERONIMO-3365
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.0-M7
Reporter: Jarek Gawor
Priority: Critical
The initial config.xml contains the following condition:
module condition=props.getProperty('org.apache.geronimo.jaxws.provider',
'axis2') == 'axis2'
name=org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car
But after the server is started and stopped for the first time this entry is
rewritten as:
module condition=props.getProperty('org.apache.geronimo.jaxws.provider',
'axis2') == 'axis2' load=false
name=org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car
The 'load' attribute is added which invalidates the specified condition.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3366) Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry
[ https://issues.apache.org/jira/browse/GERONIMO-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3366: --- Component/s: OpenEJB Affects Version/s: (was: 2.0-M3) 2.0-M6 Fix Version/s: 2.1 Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry --- Key: GERONIMO-3366 URL: https://issues.apache.org/jira/browse/GERONIMO-3366 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0-M6 Reporter: Ted Kirby Assignee: Donald Woods Priority: Critical Fix For: 2.0, 2.1 Attachments: G3366.patch EntityManagerRegistryImpl gets its entityManagerRegistry from the OpenEjbSystem GBean. It needs to start afterwards. A dependency should be added in the plan to insure that this is case, otherwise it will be random, and if they start out of order, an NPE results from EntityManager.persist() calls. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3366) Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry
[ https://issues.apache.org/jira/browse/GERONIMO-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-3366. -- Resolution: Fixed Ted, thanks for the patch. Committed revision 562004 in branches/2.0 Committed revision 562005 in trunk (2.1) Dependency needed in openejb config to start OpenEjbSystem before the EntityManagerRegistry --- Key: GERONIMO-3366 URL: https://issues.apache.org/jira/browse/GERONIMO-3366 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0-M6 Reporter: Ted Kirby Assignee: Donald Woods Priority: Critical Fix For: 2.0, 2.1 Attachments: G3366.patch EntityManagerRegistryImpl gets its entityManagerRegistry from the OpenEjbSystem GBean. It needs to start afterwards. A dependency should be added in the plan to insure that this is case, otherwise it will be random, and if they start out of order, an NPE results from EntityManager.persist() calls. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Proposed Branch and Release Schedule for Geronimo 2.0
On Jul 31, 2007, at 11:37 PM, Matt Hogstrom wrote: All, It looks like we're winding down and readying for the 2.0 release that is long awaited. I've been working on something at work for the last week that has kept me a little distracted from G so apologies if I missed something in a thread. There are lots of supporting elements that are being released. I saw Tim got some specs out and I'm working on Genesis and some of the Connector / Tx stuff that Jencks did. Assuming these votes succeed and the Law firm of Miller, Miller and Devoto don't find some odd file that we need or an extra one we don't it looks like we can spin up a 2.0 release for a vote later in the week. That in mind, I propose that we look to create the branches/2.0.0 release on thursday. This will be the final release and will undergo the fitting for a release and will not take code changes unless fixing a specific bug. the branches/2.0 will be updated to 2.0.1-SNAPSHOT and can continue the infusion of bug fixes, etc. Please have all your final fixes in branches/2.0 by Thursday morning Eastern time so we can branch and lock this monster down. So, the summary would be: 8/2 Branch branches/2.0 - branches/2.0.0 8/3 Spin up Geronimo RC 1 and start final TCK run (this will include inflight jars that votes expire on Friday). 8/7 Geronimo 2.0 is announced to the world and released 8/7 There is much excitement and rejoicing. Hey Matt, That looks good, especially the excitement and rejoicing part... :-) We might need to slide in a few more fixes. So, the RC1 spin up date may need to be adjusted, slightly. These are good goals to set... --kevan
[jira] Commented: (GERONIMO-3326) ClassLoader memory leak caused by OpenJPA
[ https://issues.apache.org/jira/browse/GERONIMO-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517138 ] Donald Woods commented on GERONIMO-3326: The OpenJPA part of this was committed tonight by Kevin Sutter - r561970 | kwsutter | 2007-08-01 17:55:44 -0400 (Wed, 01 Aug 2007) | 1 line OPENJPA-285. I am going ahead with the integration of Kevan's patches for the t wo memory leaks found in OpenJPA while testing Geronimo. I will post more detai ls in the Issue. Are we ready to commit the Geronimo changes? ClassLoader memory leak caused by OpenJPA - Key: GERONIMO-3326 URL: https://issues.apache.org/jira/browse/GERONIMO-3326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0-M7 Reporter: Kevan Miller Assignee: Kevan Miller Priority: Blocker Fix For: 2.0 Attachments: OpenJPAMemLeak-G.patch, OpenJPAMemLeak-OJPA.patch As David Jencks mentioned in GERONIMO-3305, there's a ClassLoader memory leak in deploy/undeploy. Geronimo is running out of PermGen space in some simple deploy/undeploy scenarios involving OpenJPA. The cause of the problem seems to be the _metas table in PCRegistry. _metas is a ConcurrentReferenceHashMap with WEAK reference keys and HARD reference values. The keys are the PersistenceCapable classes. While the values are the metadata for these classes which are maintained by the internal Meta class. The cause of the ClassLoader memory leak is simple -- if any of the objects/classes held by the Meta class (e.g. fieldTypes) have also been loaded by the same ClassLoader used to load the PersistenceCapable class, the PersistenceCapable class (the weak key) will never be GCed. The value of the HashMap entry will always maintain a hard reference to the ClassLoader. Since the ClassLoader will never be GC'ed, the the the pcClass Class object will never be GC'able... The problem can be easily recreated using current Geronimo trunk and the Geronimo Daytrader application. FYI, here are the GC Roots for one of our ClassLoaders being leaked -- http://people.apache.org/~kevan/PCRegistryLeak.html I've contacted the OpenJPA dev list. Hopefully, can get this resolved, quickly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3365) config.xml condition vs. load attribute issues
[
https://issues.apache.org/jira/browse/GERONIMO-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor resolved GERONIMO-3365.
---
Resolution: Fixed
Fix Version/s: 2.0
Fix committed to 2.0 branch: Committed revision 562012.
config.xml condition vs. load attribute issues
--
Key: GERONIMO-3365
URL: https://issues.apache.org/jira/browse/GERONIMO-3365
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.0-M7
Reporter: Jarek Gawor
Priority: Critical
Fix For: 2.0
The initial config.xml contains the following condition:
module condition=props.getProperty('org.apache.geronimo.jaxws.provider',
'axis2') == 'axis2'
name=org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car
But after the server is started and stopped for the first time this entry is
rewritten as:
module condition=props.getProperty('org.apache.geronimo.jaxws.provider',
'axis2') == 'axis2' load=false
name=org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car
The 'load' attribute is added which invalidates the specified condition.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3305) Out Of Memory Error when Running DayTrader in WebServices Mode
[
https://issues.apache.org/jira/browse/GERONIMO-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor resolved GERONIMO-3305.
---
Resolution: Fixed
Fix Version/s: 2.0
I'm closing this bug as the main issue of this problem was fixed (by caching
the service-ref classes). Please reopen if that's not right.
Out Of Memory Error when Running DayTrader in WebServices Mode
--
Key: GERONIMO-3305
URL: https://issues.apache.org/jira/browse/GERONIMO-3305
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.0-M7
Environment: All
Reporter: Matt Hogstrom
Assignee: Jarek Gawor
Fix For: 2.0
I deployed DayTrader 2.0 on the latest SVN rev 554753 of trunk.
I deploy daytrader-ear-2.0-SNAPSHOT.ear (using the
daytrader-g-2.0-SNAPSHOT-plan.xml in ${DT}/trunk/plans
Create the tables and populate them in the config section.
Switch to WebServices mode
Log in and do portfolio, quotes, buy and sell a few stocks and then logoff.
Try to log in again and I get:
10:34:34,089 ERROR [Log] Error: JSR 109 lookup failed .. defaulting to JSR 101
javax.naming.NamingException: Could not look up : service/Trade [Root
exception is net.sf.cglib.core.CodeGenerationException:
java.lang.reflect.InvocationTargetException--null]
javax.naming.NamingException: Could not look up : service/Trade [Root
exception is net.sf.cglib.core.CodeGenerationException:
java.lang.reflect.InvocationTargetException--null]
at
org.apache.xbean.naming.context.ContextUtil.resolve(ContextUtil.java:65)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:112)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at
org.apache.geronimo.samples.daytrader.soap.TradeWebSoapProxy.getPortFromFactory(TradeWebSoapProxy.java:67)
at
org.apache.geronimo.samples.daytrader.soap.TradeWebSoapProxy.getTrade(TradeWebSoapProxy.java:47)
at
org.apache.geronimo.samples.daytrader.soap.TradeWebSoapProxy.getAccountData(TradeWebSoapProxy.java:122)
at
org.apache.geronimo.samples.daytrader.web.TradeServletAction.doHome(TradeServletAction.java:277)
at
org.apache.geronimo.samples.daytrader.web.TradeServletAction.doLogin(TradeServletAction.java:372)
at
org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(TradeAppServlet.java:126)
at
org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doPost(TradeAppServlet.java:91)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:91)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351)
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:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
