[jira] [Assigned] (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom reassigned GERONIMO-4350: Assignee: (was: Dain Sundstrom) > Connection proxying to imitate DissociatableManagedConnection can easily > cause problems > --- > > Key: GERONIMO-4350 > URL: https://issues.apache.org/jira/browse/GERONIMO-4350 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.1, 2.1.4, 2.2 >Reporter: David Jencks > Fix For: Wish List > > > We have some code to imitate the DissociatableManagedConnection to avoid > connection leaks that proxies connections from the supplied > ManagedConnectionFactory: the proxy implements all the interfaces of the > connection, but not the class itself. However, there's nothing stopping the > ConnectionFactory from casting the (now proxied) connection to the > implementation class it expects. > The TxConnect project at sourceforge illustrates this approach in the > EisConnectionFactory. > http://txconnect.sourceforge.net > One possible solution would be to have a flag to turn on this proxying > behavior. I don't immediately see a way to detect if the problem will occur. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] Created: (GERONIMO-5842) InternetAddress.parse fails on a valid address
InternetAddress.parse fails on a valid address
--
Key: GERONIMO-5842
URL: https://issues.apache.org/jira/browse/GERONIMO-5842
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: mail
Reporter: Dain Sundstrom
The InternetAddress parser is restricting the local part to not have multiple
dots in a row. Although this may be rfc822 compliant, email address on the
internet can and do have multiple dot in the local part. For example the email
address "k..al...@enron.com" was an address at Enron and is included in the
Enron email corpus:
InternetAddress.parse("k..al...@enron.com");
Exception in thread "main" javax.mail.internet.AddressException: Invalid local
part (k..al...@enron.com,2)
at
javax.mail.internet.AddressParser.illegalAddress(AddressParser.java:1126)
at
javax.mail.internet.AddressParser.validateLocalPart(AddressParser.java:1287)
at
javax.mail.internet.AddressParser.validateAddressSpec(AddressParser.java:1232)
at
javax.mail.internet.AddressParser.validateSimpleAddress(AddressParser.java:1213)
at
javax.mail.internet.AddressParser.parseSingleAddress(AddressParser.java:440)
at
javax.mail.internet.AddressParser.parseAddressList(AddressParser.java:91)
at javax.mail.internet.InternetAddress.parse(InternetAddress.java:557)
at javax.mail.internet.InternetAddress.parse(InternetAddress.java:529)
at javax.mail.internet.InternetAddress.parse(InternetAddress.java:517)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed GERONIMO-4350. Resolution: Invalid Assignee: David Jencks (was: Dain Sundstrom) The problem was in user code that was attempting to downcast a connection proxy to a specific implementation class which is not allowed by the JEE Connector specification. > Connection proxying to imitate DissociatableManagedConnection can easily > cause problems > --- > > Key: GERONIMO-4350 > URL: https://issues.apache.org/jira/browse/GERONIMO-4350 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.1, 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1.4, 2.2 > > > We have some code to imitate the DissociatableManagedConnection to avoid > connection leaks that proxies connections from the supplied > ManagedConnectionFactory: the proxy implements all the interfaces of the > connection, but not the class itself. However, there's nothing stopping the > ConnectionFactory from casting the (now proxied) connection to the > implementation class it expects. > The TxConnect project at sourceforge illustrates this approach in the > EisConnectionFactory. > http://txconnect.sourceforge.net > One possible solution would be to have a flag to turn on this proxying > behavior. I don't immediately see a way to detect if the problem will occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (XBEAN-111) Only register Converters with the VM when requested
[ https://issues.apache.org/jira/browse/XBEAN-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed XBEAN-111. Resolution: Fixed > Only register Converters with the VM when requested > --- > > Key: XBEAN-111 > URL: https://issues.apache.org/jira/browse/XBEAN-111 > Project: XBean > Issue Type: Improvement > Components: reflect >Affects Versions: 3.4, 3.4.1, 3.4.2 >Reporter: Dain Sundstrom >Assignee: Dain Sundstrom > Fix For: 3.4.3 > > > Registering the Converters in xbean-reflect with the VM PropertyEditorManager > creates lots of problems for some libraries and IDEs. Since xbean-reflect > has a private converter registry there is no need to register the Converters > with the VM. > I have add the boolean flag registerWithVM to PropertyEditors. When this > flag is set, all Converters registered with PropertyEditors are registered > with the VM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (XBEAN-111) Only register Converters with the VM when requested
Only register Converters with the VM when requested --- Key: XBEAN-111 URL: https://issues.apache.org/jira/browse/XBEAN-111 Project: XBean Issue Type: Improvement Components: reflect Affects Versions: 3.4.2, 3.4.1, 3.4 Reporter: Dain Sundstrom Assignee: Dain Sundstrom Fix For: 3.4.3 Registering the Converters in xbean-reflect with the VM PropertyEditorManager creates lots of problems for some libraries and IDEs. Since xbean-reflect has a private converter registry there is no need to register the Converters with the VM. I have add the boolean flag registerWithVM to PropertyEditors. When this flag is set, all Converters registered with PropertyEditors are registered with the VM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638652#action_12638652 ] Dain Sundstrom commented on GERONIMO-4350: -- I'm not sure I understand the problem. IIRC, a spec-compliant RA is required to list all interfaces that are needed by calling code (so we know what to add to the proxy). Anyway, if this is something we want/need to support, I can this of a few workarounds/solutions (listed in order of difficulty for Geronimo): 1) add a getDelegate method one of the interfaces like JDBC and JPA use 2) add a flag to turn of connection GC 3) rewrite the connection pool code to use weak references for garbage detection Option 3 is the most reliable but a lot more work. > Connection proxying to imitate DissociatableManagedConnection can easily > cause problems > --- > > Key: GERONIMO-4350 > URL: https://issues.apache.org/jira/browse/GERONIMO-4350 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.1, 2.2 >Reporter: David Jencks >Assignee: Dain Sundstrom > Fix For: 2.1.4, 2.2 > > > We have some code to imitate the DissociatableManagedConnection to avoid > connection leaks that proxies connections from the supplied > ManagedConnectionFactory: the proxy implements all the interfaces of the > connection, but not the class itself. However, there's nothing stopping the > ConnectionFactory from casting the (now proxied) connection to the > implementation class it expects. > The TxConnect project at sourceforge illustrates this approach in the > EisConnectionFactory. > http://txconnect.sourceforge.net > One possible solution would be to have a flag to turn on this proxying > behavior. I don't immediately see a way to detect if the problem will occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3540) Session.loadProviders(ProviderInfo info, InputStream is) doesn't seem to handle comments correctly
Session.loadProviders(ProviderInfo info, InputStream is) doesn't seem to handle comments correctly -- Key: GERONIMO-3540 URL: https://issues.apache.org/jira/browse/GERONIMO-3540 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: mail Affects Versions: 2.0.2, 2.0.1, 2.0 Reporter: Dain Sundstrom Assignee: Rick McGuire After reviewing the Session code, it doesn't appear that loadProviders is checking for comments. I believe that if you have an entry like this: # foo=bar; protocol=imap; type=store; class=com.sun.mail.imap.IMAPStore; vendor=Sun Microsystems, Inc.; it would process the entry. I have not tested this, so I could be wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3539) Can not override providers using META-INF/javamail.providers file
Can not override providers using META-INF/javamail.providers file
-
Key: GERONIMO-3539
URL: https://issues.apache.org/jira/browse/GERONIMO-3539
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: mail
Affects Versions: 2.0.2, 2.0.1, 2.0
Reporter: Dain Sundstrom
Assignee: Rick McGuire
The Session.loadProviders(ClassLoader cl) loads provider files from:
META-INF/javamail.default.providers
${java.home}/lib/javamail.providers
META-INF/javamail.providers
but should be
${java.home}/lib/javamail.providers
META-INF/javamail.providers
META-INF/javamail.default.providers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3267) Naming lookup fails. Reported error for a different name than requested
[
https://issues.apache.org/jira/browse/GERONIMO-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom reassigned GERONIMO-3267:
Assignee: Matt Hogstrom (was: Dain Sundstrom)
I believe David Jencks committed a fix for this earlier today. Please verify.
> Naming lookup fails. Reported error for a different name than requested
>
>
> Key: GERONIMO-3267
> URL: https://issues.apache.org/jira/browse/GERONIMO-3267
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Environment: All
>Reporter: Matt Hogstrom
>Assignee: Matt Hogstrom
> Fix For: 2.0-M7
>
>
> DayTrader 1.2 deploy's correctly on 2.0 but when an attempt to execute a
> SessionBean is tried a JNDI lookup fails. Here is the code from
> TradeBean.java
>InitialContext ic = new
> InitialContext();
>*this is line 1041 --->* qConnFactory = (ConnectionFactory)
> ic.lookup("*java:comp/env/jms/QueueConnectionFactory*");
> {panel:title=Name Not Found Exception| borderStyle=dashed| borderColor=#ccc|
> titleBGColor=#F7D6C1| bgColor=#CE}
> The lookup fails with a name not found exception. What is odd is that the
> exception says:
> javax.naming.NameNotFoundException: Name
> "*java:openejb/Resource/jms/TradeBrokerQCF*" not found.
> at
> org.apache.openejb.core.ivm.naming.IvmContext.federate(IvmContext.java:172)
> at
> org.apache.openejb.core.ivm.naming.IvmContext.lookup(IvmContext.java:129)
> at
> org.apache.openejb.core.ivm.naming.IntraVmJndiReference.getObject(IntraVmJndiReference.java:38)
> at
> org.apache.openejb.core.ivm.naming.Reference.getContent(Reference.java:40)
> at
> org.apache.xbean.naming.context.ContextUtil.resolve(ContextUtil.java:61)
> 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:363)
> *at
> org.apache.geronimo.samples.daytrader.ejb.TradeBean.ejbCreate(TradeBean.java:1041)*
> 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.proceed(ReflectionInvocationContext.java:129)
> at
> org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67)
> at
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:177)
> at
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:156)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:211)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:65)
> at
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:230)
> at
> org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
> at $Proxy25.resetTrade(Unknown Source)
> at
> org.apache.geronimo.samples.daytrader.TradeAction.resetTrade(TradeAction.java:510)
> at
> org.apache.geronimo.samples.daytrader.web.TradeConfigServlet.doResetTrade(TradeConfigServlet.java:73)
> at
> org.apache.geronimo.samples.daytrader.web.TradeConfigServlet.service(TradeConfigServlet.java:362)
> 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.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardCont
[jira] Updated: (GERONIMO-2950) Build test failure in geronimo-naming
[ https://issues.apache.org/jira/browse/GERONIMO-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated GERONIMO-2950: - Component/s: naming Priority: Minor (was: Major) Affects Version/s: 2.0-M6 Fix Version/s: 2.0-M7 Assignee: Kevan Miller (was: Dain Sundstrom) > Build test failure in geronimo-naming > - > > Key: GERONIMO-2950 > URL: https://issues.apache.org/jira/browse/GERONIMO-2950 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: naming >Affects Versions: 2.0-M6 >Reporter: Kevan Miller >Assignee: Kevan Miller >Priority: Minor > Fix For: 2.0-M7 > > Attachments: GERONIMO-2950.patch > > > server/trunk builds are failing in geronimo-naming junit tests. > Running org.apache.geronimo.gjndi.JavaCompContextTest > lookup(String) milliseconds: 432 > Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.461 sec <<< > FAILURE! > --- > Test set: org.apache.geronimo.gjndi.JavaCompContextTest > --- > Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.462 sec <<< > FAILURE! > testSchemeLookup(org.apache.geronimo.gjndi.JavaCompContextTest) Time > elapsed: 0.006 sec <<< ERROR! > javax.naming.NotContextException: java:comp/env/hello > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:161) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597) > at > org.apache.xbean.naming.context.ContextFlyweight.lookup(ContextFlyweight.java:44) > at > org.apache.geronimo.gjndi.JavaCompContextTest.testSchemeLookup(JavaCompContextTest.java:86) > > I'm going to remove the test and have Dain fix... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2950) Build test failure in geronimo-naming
[ https://issues.apache.org/jira/browse/GERONIMO-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated GERONIMO-2950: - Attachment: GERONIMO-2950.patch Problem is fixed in xbean-naming 3.1-SNAPSHOT, but I don't think we should change versions until the next G version is shipped as the fix could cause unintended regressions. > Build test failure in geronimo-naming > - > > Key: GERONIMO-2950 > URL: https://issues.apache.org/jira/browse/GERONIMO-2950 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Kevan Miller >Assignee: Dain Sundstrom > Attachments: GERONIMO-2950.patch > > > server/trunk builds are failing in geronimo-naming junit tests. > Running org.apache.geronimo.gjndi.JavaCompContextTest > lookup(String) milliseconds: 432 > Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.461 sec <<< > FAILURE! > --- > Test set: org.apache.geronimo.gjndi.JavaCompContextTest > --- > Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.462 sec <<< > FAILURE! > testSchemeLookup(org.apache.geronimo.gjndi.JavaCompContextTest) Time > elapsed: 0.006 sec <<< ERROR! > javax.naming.NotContextException: java:comp/env/hello > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:161) > at > org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597) > at > org.apache.xbean.naming.context.ContextFlyweight.lookup(ContextFlyweight.java:44) > at > org.apache.geronimo.gjndi.JavaCompContextTest.testSchemeLookup(JavaCompContextTest.java:86) > > I'm going to remove the test and have Dain fix... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2768) geronimo-j2ee-management_1.1_spec is still using geronimo-ejb_2.1_spec instead of new ejb_3.0_spec
[ https://issues.apache.org/jira/browse/GERONIMO-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed GERONIMO-2768. Resolution: Fixed Fix Version/s: (was: 2.0-M5) 2.0-M6 > geronimo-j2ee-management_1.1_spec is still using geronimo-ejb_2.1_spec > instead of new ejb_3.0_spec > -- > > Key: GERONIMO-2768 > URL: https://issues.apache.org/jira/browse/GERONIMO-2768 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Affects Versions: 2.0-M2 >Reporter: Donald Woods >Assignee: Dain Sundstrom >Priority: Minor > Fix For: 2.0-M6 > > Attachments: G2768.patch > > > geronimo/spces/trunk/geronimo-j2ee-management_1.1_spec is still using > geronimo-ejb_2.1_spec-1.1 instead of the new geronimo-ejb_3.0_spec-1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3137) Servlets must rollback uncommitted transaction when the service method exits
Servlets must rollback uncommitted transaction when the service method exits Key: GERONIMO-3137 URL: https://issues.apache.org/jira/browse/GERONIMO-3137 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: web Reporter: Dain Sundstrom Assigned To: David Jencks Servlets must rollback uncommitted transaction when the service method exits. The servlet should check for a tx on entry and if one is not present on entry but there is one on exit, it should be rolled back. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3125) AdminObjectRefBuilder does not handle UserTransaction resource-env-refs
AdminObjectRefBuilder does not handle UserTransaction resource-env-refs --- Key: GERONIMO-3125 URL: https://issues.apache.org/jira/browse/GERONIMO-3125 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Reporter: Dain Sundstrom Assigned To: David Jencks In Jee 5 is is legal to have @Resource and , to add a UserTransaction (or EJB Context) to the ENC. This AdminObjectRefBuilder does not understand this yet and attempts to resolve an AdminObject for these refs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2972) Bind JavaMail Session to Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed GERONIMO-2972. Resolution: Fixed Fix Version/s: 2.0-M4 Assignee: Christopher M. Cardona (was: Dain Sundstrom) Committed revision 524985. Thanks! > Bind JavaMail Session to Global JNDI > > > Key: GERONIMO-2972 > URL: https://issues.apache.org/jira/browse/GERONIMO-2972 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: mail >Affects Versions: 2.0-M5 >Reporter: Christopher M. Cardona > Assigned To: Christopher M. Cardona > Fix For: 2.0-M4 > > Attachments: GERONIMO-2972.patch, mailsession1-plan.xml, > sendmail.war, testjndi.war > > > Auto bind JavaMail Session objects to Global JNDI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2972) Bind JavaMail Session to Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom reassigned GERONIMO-2972: Assignee: Dain Sundstrom (was: Christopher M. Cardona) > Bind JavaMail Session to Global JNDI > > > Key: GERONIMO-2972 > URL: https://issues.apache.org/jira/browse/GERONIMO-2972 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: mail >Affects Versions: 2.0-M5 >Reporter: Christopher M. Cardona > Assigned To: Dain Sundstrom > Attachments: GERONIMO-2972.patch, mailsession1-plan.xml, > sendmail.war, testjndi.war > > > Auto bind JavaMail Session objects to Global JNDI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3046) When starting Daytrader after deploy on 2.0-SNAPSHOT ejb-jar is started before its dependencies have been started
[ https://issues.apache.org/jira/browse/GERONIMO-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom reassigned GERONIMO-3046: Assignee: Matt Hogstrom (was: Dain Sundstrom) I believe this is fixed with r524261 > When starting Daytrader after deploy on 2.0-SNAPSHOT ejb-jar is started > before its dependencies have been started > - > > Key: GERONIMO-3046 > URL: https://issues.apache.org/jira/browse/GERONIMO-3046 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0-M4, 2.0-M5 >Reporter: Matt Hogstrom > Assigned To: Matt Hogstrom > Fix For: 2.0-M4 > > > Testing deployment of Daytrader on Geronimo 2.0 - M4 (as well as trunk) the > dt-ejb.jar is started before the messaging component it depends on. As a > consequence, startup of the application fails as a dependent resource (a > messaging queue) is not found. > Talked to Dain about this and he thinks he knows where this needs to be > addressed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2969) Transaction recovery broken for MDBs
Transaction recovery broken for MDBs Key: GERONIMO-2969 URL: https://issues.apache.org/jira/browse/GERONIMO-2969 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector, OpenEJB Reporter: Dain Sundstrom Transaction recovery for MDBs is not currently working because the OpenEJB MdbContainer does not register the XAResources from an ActivationSpec with the Geronimo transaction manager. This means that Geronimo has no resource name to write in to the transaction recovery log. I commented out the code in the HowlLog that enforces a registered name to the MDB container will function, but the recover process will not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2959) PersistenceUnitRefBuilder does not create unique enough name queries
PersistenceUnitRefBuilder does not create unique enough name queries Key: GERONIMO-2959 URL: https://issues.apache.org/jira/browse/GERONIMO-2959 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: naming Reporter: Dain Sundstrom Assigned To: David Jencks PersistenceUnitRefBuilder creates abstract name queries like ?name=cmp#org.apache.geronimo.persistence.PersistenceUnitGBean which is not unique enough to differentiate persistence units with overlapping names from different persistence modules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2862) Detect Yoko classes are not endorsed
Detect Yoko classes are not endorsed Key: GERONIMO-2862 URL: https://issues.apache.org/jira/browse/GERONIMO-2862 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: CORBA Reporter: Dain Sundstrom Assigned To: Rick McGuire When the Yoko classes are not installed in the endorsed directory, we get non-obvious exceptions like the following from the Yoko code. java.lang.NoSuchMethodError: org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_changed(Ljava/lang/String;S)V at org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange(PIManager.java:532) at org.apache.yoko.orb.OBPortableServer.POAManager_impl.activate(POAManager_impl.java:213) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.initialize(TransientNameService.java:130) We should be able to detect that the Yoko specs are not endorsed and throw an specific exception informing the user how to fix the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2176) deploy time validations lost in openejb rewrite
[ https://issues.apache.org/jira/browse/GERONIMO-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed GERONIMO-2176. Resolution: Fixed Fix Version/s: 2.0-beta2 This was fixed a while ago. > deploy time validations lost in openejb rewrite > --- > > Key: GERONIMO-2176 > URL: https://issues.apache.org/jira/browse/GERONIMO-2176 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: Dain Sundstrom > Fix For: 2.0-beta2 > > > I tried deploying a stateless session bean that lacked an ejbCreate method. > It deployed successfully in trunk but in 1.1 it complained about the missing > ejbCreate method. Seems like some validation must have gotten lost. > The app I used is the one attached to GERONIMO-2125: I added the ejbCreate > method in the jar subproject TestSession. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2416) ProxyMethodInterceptor should work with classes that have start,stop methods
[
https://issues.apache.org/jira/browse/GERONIMO-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom reassigned GERONIMO-2416:
Assignee: David Jencks (was: Dain Sundstrom)
> ProxyMethodInterceptor should work with classes that have start,stop methods
>
>
> Key: GERONIMO-2416
> URL: https://issues.apache.org/jira/browse/GERONIMO-2416
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: kernel
>Affects Versions: 1.2
>Reporter: David Jencks
> Assigned To: David Jencks
>Priority: Critical
> Fix For: 2.0
>
>
> jetty6 components usually have lifecycle methods start,stop, and possibly
> others. If we write a gbean extending these objects ProxyMethodInterceptor
> blows up with an ArrayIndexOutOfBoundsException (-1). I don't understand why
> this happens, and there might be a different cause, but the gbeans that have
> this problem all extend jetty objects with start methods.
> A really bad workaround that lets the server start is this patch:
> Index:
> modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/basic/ProxyMethodInterceptor.java
> ===
> ---
> modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/basic/ProxyMethodInterceptor.java
> (revision 447903)
> +++
> modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/basic/ProxyMethodInterceptor.java
> (working copy)
> @@ -110,14 +110,29 @@
> invokers[getSuperIndex(proxyType, proxyType.getMethod("equals",
> new Class[]{Object.class}))] = new EqualsInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("hashCode", null))] = new HashCodeInvoke();
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("toString", null))] = new
> ToStringInvoke(proxyType.getName());
> -if(GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getState", null))] = new GetStateInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getStateInstance", null))] = new
> GetStateInstanceInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("start", null))] = new StartInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("startRecursive", null))] = new
> StartRecursiveInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("stop", null))] = new StopInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getStartTime", null))] = new GetStartTimeInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getObjectName", null))] = new
> GetObjectNameInvoke(kernel);
> +if (GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
> +int superIndex;
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("getState", null))) > -1) {
> +invokers[superIndex] = new GetStateInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("getStateInstance", null))) > -1) {
> +invokers[superIndex] = new
> GetStateInstanceInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("start", null))) > -1) {
> +invokers[superIndex] = new StartInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("startRecursive", null))) > -1) {
> +invokers[superIndex] = new StartRecursiveInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("stop", null))) > -1) {
> +invokers[superIndex] = new StopInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("getStartTime", null))) > -1) {
> +invokers[superIndex] = new GetStartTimeInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("getObjectName", null))) > -1) {
> +invokers[superIndex] = new GetObjectNameInvoke(kernel);
> +}
> }
> } catch (Exception e) {
> // this can not happen... all classes must implement equals,
> hashCode and toString
> Dain, do you have any clues why this is happening?
--
This message is automatically generated by JIRA.
-
Yo
[jira] Commented: (GERONIMO-2416) ProxyMethodInterceptor should work with classes that have start,stop methods
[
https://issues.apache.org/jira/browse/GERONIMO-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474577
]
Dain Sundstrom commented on GERONIMO-2416:
--
you can't proxy a final method
> ProxyMethodInterceptor should work with classes that have start,stop methods
>
>
> Key: GERONIMO-2416
> URL: https://issues.apache.org/jira/browse/GERONIMO-2416
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: kernel
>Affects Versions: 1.2
>Reporter: David Jencks
> Assigned To: Dain Sundstrom
>Priority: Critical
> Fix For: 2.0
>
>
> jetty6 components usually have lifecycle methods start,stop, and possibly
> others. If we write a gbean extending these objects ProxyMethodInterceptor
> blows up with an ArrayIndexOutOfBoundsException (-1). I don't understand why
> this happens, and there might be a different cause, but the gbeans that have
> this problem all extend jetty objects with start methods.
> A really bad workaround that lets the server start is this patch:
> Index:
> modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/basic/ProxyMethodInterceptor.java
> ===
> ---
> modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/basic/ProxyMethodInterceptor.java
> (revision 447903)
> +++
> modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/basic/ProxyMethodInterceptor.java
> (working copy)
> @@ -110,14 +110,29 @@
> invokers[getSuperIndex(proxyType, proxyType.getMethod("equals",
> new Class[]{Object.class}))] = new EqualsInvoke(kernel);
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("hashCode", null))] = new HashCodeInvoke();
> invokers[getSuperIndex(proxyType,
> proxyType.getMethod("toString", null))] = new
> ToStringInvoke(proxyType.getName());
> -if(GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getState", null))] = new GetStateInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getStateInstance", null))] = new
> GetStateInstanceInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("start", null))] = new StartInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("startRecursive", null))] = new
> StartRecursiveInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("stop", null))] = new StopInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getStartTime", null))] = new GetStartTimeInvoke(kernel);
> -invokers[getSuperIndex(proxyType,
> proxyType.getMethod("getObjectName", null))] = new
> GetObjectNameInvoke(kernel);
> +if (GeronimoManagedBean.class.isAssignableFrom(proxyType)) {
> +int superIndex;
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("getState", null))) > -1) {
> +invokers[superIndex] = new GetStateInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("getStateInstance", null))) > -1) {
> +invokers[superIndex] = new
> GetStateInstanceInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("start", null))) > -1) {
> +invokers[superIndex] = new StartInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("startRecursive", null))) > -1) {
> +invokers[superIndex] = new StartRecursiveInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("stop", null))) > -1) {
> +invokers[superIndex] = new StopInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("getStartTime", null))) > -1) {
> +invokers[superIndex] = new GetStartTimeInvoke(kernel);
> +}
> +if ((superIndex = getSuperIndex(proxyType,
> proxyType.getMethod("getObjectName", null))) > -1) {
> +invokers[superIndex] = new GetObjectNameInvoke(kernel);
> +}
> }
> } catch (Exception e) {
> // this can not happen... all classes must implement equals,
> hashCode and toString
> Dain, do you have any clues why this is happening?
--
This message is automatically generated by JIR
[jira] Resolved: (GERONIMO-2831) openejb3 installs jndi context rooted at the wrong place
[
https://issues.apache.org/jira/browse/GERONIMO-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom resolved GERONIMO-2831.
--
Resolution: Fixed
Fix Version/s: (was: 2.0-beta1)
Looks correct.
> openejb3 installs jndi context rooted at the wrong place
>
>
> Key: GERONIMO-2831
> URL: https://issues.apache.org/jira/browse/GERONIMO-2831
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 2.0-M2
>Reporter: David Jencks
> Assigned To: Dain Sundstrom
>
> GeronimoThreadContextListener is installing the jndi context from openejb
> into the geronimo root context. However, the openejb context has entries
> starting with java:comp whereas the root context expects the java:comp to be
> stripped off. As a result nothing can be looked up in the java:comp
> namespace.
> // Get the jndi context
> Context jndiContext = ejbDeployment.getComponentContext();
> try {
> jndiContext = (Context) jndiContext.lookup("java:comp");
> } catch (NamingException e) {
> throw new IllegalStateException("jndiContext did not contain
> expected java:comp subcontext", e);
> }
> fixes the problem, but this lookup should be done only once wen the
> ejbDeployment is started.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2800) Connector Lazy Activation leaks managed connections
[ https://issues.apache.org/jira/browse/GERONIMO-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470441 ] Dain Sundstrom commented on GERONIMO-2800: -- I think I have fixed this problem in revision 503969. When connections are closed or destroyed do not reassociate the connection again or throw an exception. Instead simply invoke the handle and let the handle throw the exception. Please verify. > Connector Lazy Activation leaks managed connections > --- > > Key: GERONIMO-2800 > URL: https://issues.apache.org/jira/browse/GERONIMO-2800 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.0-M2 >Reporter: Kevan Miller > Assigned To: Kevan Miller > Fix For: 2.0-beta1 > > > GERONIMO-2715 added "lazy connection" support to geronimo-connector. > I'm seeing problems where connectors are not being reused properly. The > result is that connectors are not being returned to their pool. Eventually, > the pool of available connections is exhausted and no more connections can be > obtained from the pool. > The basic scenario is: > Connection c = ConnectionFactory.createConnection(); > c.close(); > c.close(); > Connection newC = ConnectionFactory.createConnection(); > newC.close(); > On the first c.close(), the connectionInfo is disassociated from the > ConnectionProxy. However, on the second c.close(), connectionInfo is > re-associated with the ConnectionProxy. However, since the second close() > call is idempotent, the connection never leaves the pool. When a new > Connection is created, the connection is re-used from the pool, but has two > ConnectionInfo's being tracked as handles. This extra handle prevents the > ConnectionInfo from ever being returned to the pool. > I'm a relative novice when it comes to our Connector implementation. It's > possible that I'm missing another point where the problem could be fixed. > However, I don't see it. I'm also worried about concurrency issues with the > current approach. > I plan on setting lazyConnect to false in the transaction-jta11 and > client-transaction configs. If there aren't ideas on fixing, I think we'll > want to revert the lazy connection code... > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2768) geronimo-j2ee-management_1.1_spec is still using geronimo-ejb_2.1_spec instead of new ejb_3.0_spec
[ https://issues.apache.org/jira/browse/GERONIMO-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466656 ] Dain Sundstrom commented on GERONIMO-2768: -- If you look at the pom: http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0-M1/geronimo-j2ee-management_1.1_spec-1.0-M1.pom you will see that the spec is marked as "provided", which means that the environment will provide this dependency, and it is not dependency transitively inherited. So what is the rush? > geronimo-j2ee-management_1.1_spec is still using geronimo-ejb_2.1_spec > instead of new ejb_3.0_spec > -- > > Key: GERONIMO-2768 > URL: https://issues.apache.org/jira/browse/GERONIMO-2768 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Affects Versions: 2.0-M2 >Reporter: Donald Woods > Assigned To: Dain Sundstrom >Priority: Minor > Fix For: 2.0-M2 > > Attachments: G2768.patch > > > geronimo/spces/trunk/geronimo-j2ee-management_1.1_spec is still using > geronimo-ejb_2.1_spec-1.1 instead of the new geronimo-ejb_3.0_spec-1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2715) Connector Lazy Activation
[ https://issues.apache.org/jira/browse/GERONIMO-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed GERONIMO-2715. Resolution: Fixed Committed to trunk (2.0-M2) in revision 494503. Committed to branches/1.2 in revision 494504. > Connector Lazy Activation > - > > Key: GERONIMO-2715 > URL: https://issues.apache.org/jira/browse/GERONIMO-2715 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: connector >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0-M2 > > > The ConnectionTrackingCoordinator now supports lazy connector activation via > the optional 'lazyActivation' GBean attribute. Currently, the CTC tracks all > connections opened in a component instance and when the component is > reentered, all previously open connections are reconnected. The new optional > mode waits to reconnect connection until they are actually used. If the > connection is not used, then it is not connected. This is accomplished by > proxying the Connection instance. The proxy implements all interfaces that > the Connection implemented, so the proxy can still be cast to a vendor > specific connection interface (think Oracle JDBC Connection sub-interface). > One very nice side effect of this feature is that is reduces the burden to > track open connections on a per component basis. Without lazy activation, > each component instance must track previously open connections, so that they > can be reconnected. With lazy activation, the proxy is performing this > tracking, so the component is free to not track that information. Of course, > components will still want to demarc component entrance and exit so the > Connector system can return handles to the connection pool (for connectors > that support disassociation), but that is a much simpler task. This > relaxation of the requirements for a component integrator is very important > to OpenEJB3 as we now use JPA for CMP and will not be able to implement all > of the connector tracking rules that we were when we had complete control > over the CMP implementation. This will also make integration with component > frameworks Spring much easier since connection tracking can be optional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2715) Connector Lazy Activation
Connector Lazy Activation - Key: GERONIMO-2715 URL: https://issues.apache.org/jira/browse/GERONIMO-2715 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: connector Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Fix For: 1.2, 2.0-M2 The ConnectionTrackingCoordinator now supports lazy connector activation via the optional 'lazyActivation' GBean attribute. Currently, the CTC tracks all connections opened in a component instance and when the component is reentered, all previously open connections are reconnected. The new optional mode waits to reconnect connection until they are actually used. If the connection is not used, then it is not connected. This is accomplished by proxying the Connection instance. The proxy implements all interfaces that the Connection implemented, so the proxy can still be cast to a vendor specific connection interface (think Oracle JDBC Connection sub-interface). One very nice side effect of this feature is that is reduces the burden to track open connections on a per component basis. Without lazy activation, each component instance must track previously open connections, so that they can be reconnected. With lazy activation, the proxy is performing this tracking, so the component is free to not track that information. Of course, components will still want to demarc component entrance and exit so the Connector system can return handles to the connection pool (for connectors that support disassociation), but that is a much simpler task. This relaxation of the requirements for a component integrator is very important to OpenEJB3 as we now use JPA for CMP and will not be able to implement all of the connector tracking rules that we were when we had complete control over the CMP implementation. This will also make integration with component frameworks Spring much easier since connection tracking can be optional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2411) Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts
[ http://issues.apache.org/jira/browse/GERONIMO-2411?page=all ] Dain Sundstrom closed GERONIMO-2411. Fix Version/s: (was: 2.0) Resolution: Fixed Fixed. License inclusion is now enforced by the genesis plugin. If you find a problem archive, open a specific jira. > Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts > -- > > Key: GERONIMO-2411 > URL: http://issues.apache.org/jira/browse/GERONIMO-2411 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) >Affects Versions: 1.0, 1.2, 1.x, 1.1, 1.1.1, 1.1.x, 1.1.2 >Reporter: Matt Hogstrom > Assigned To: Dain Sundstrom >Priority: Blocker > Fix For: 1.2 > > > For release of these artifacts they need to include the LICENSE and NOTICE > files. Currently the build does not automatically include them. The M2 > build needs to be updated to include these artifacts in the build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1868) Calculate /console prefix dynamically for SVG, etc.
[ http://issues.apache.org/jira/browse/GERONIMO-1868?page=all ] Dain Sundstrom updated GERONIMO-1868: - Fix Version/s: (was: 1.2) This doesn't need to be fixed in 1.2. If you do fix it, simply reassign it to 1.2 and close the issue. > Calculate /console prefix dynamically for SVG, etc. > --- > > Key: GERONIMO-1868 > URL: http://issues.apache.org/jira/browse/GERONIMO-1868 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.0 >Reporter: Aaron Mulder > Assigned To: Christopher M. Cardona > > The path to the console is hardcoded in svrInfoNormal.jsp and car/index.jsp > right now. There's a method somewhere to calculate this (PortletManager?) > and we should use it or something equivalent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2578) No message in web console and hugh stacktrace in server console, if deployment fails
[ http://issues.apache.org/jira/browse/GERONIMO-2578?page=all ] Dain Sundstrom updated GERONIMO-2578: - Fix Version/s: (was: 1.2) Affects Version/s: 1.2 edited affects version instead of fix version > No message in web console and hugh stacktrace in server console, if > deployment fails > > > Key: GERONIMO-2578 > URL: http://issues.apache.org/jira/browse/GERONIMO-2578 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 > Environment: Windows XP, should be valid for all platforms >Reporter: Rakesh Midha > Assigned To: Rakesh Midha >Priority: Minor > > In case for some reason the deployment with web console fails, the server > console is filled with hugh stacktrace, but user deploying the application is > given no status update on failure or success. User is just redirected back to > "Install New Application" page. > This sounds wrong for two reasons : > 1. User should be updated with a failure update, reason and what to do? > 2. Instead of server console, use logs. i.e. instead of system.out.println or > printstacktrace is log files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2550) Plugin enhancement to allow the download of a Zip/Jar bundle and extraction location outside repository
[ http://issues.apache.org/jira/browse/GERONIMO-2550?page=all ] Dain Sundstrom updated GERONIMO-2550: - Fix Version/s: (was: 1.2) This won't be addressed in 1.2 unless you provide a patch in the next few days. If you do, simply reassign this issue to 1.2. > Plugin enhancement to allow the download of a Zip/Jar bundle and extraction > location outside repository > --- > > Key: GERONIMO-2550 > URL: http://issues.apache.org/jira/browse/GERONIMO-2550 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.x >Reporter: Donald Woods > Assigned To: Donald Woods > > Plugin enhancement to allow the download of a Zip/Jar bundle and extraction > to a filesystem location besides /repository. > Example uses: > 1) Download a Docs zipfile bundle and extract it to GERONIMO_HOME/docs > 2) Download a Samples zipfile bundle and extract it to GERONIMO_HOME/samples > 3) Download Java Service Wrapper and extract it to GERONIMO_HOME/jsw > 4) Download PHP and extract it to GERONIMO_HOME/php > . . . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2578) No message in web console and hugh stacktrace in server console, if deployment fails
[ http://issues.apache.org/jira/browse/GERONIMO-2578?page=all ] Dain Sundstrom updated GERONIMO-2578: - Affects Version/s: (was: 1.2) This won't be fixed in 1.2 unless there is a patch in the next few days. If you do create a patch in the next few days, reassign this issue to 1.2. > No message in web console and hugh stacktrace in server console, if > deployment fails > > > Key: GERONIMO-2578 > URL: http://issues.apache.org/jira/browse/GERONIMO-2578 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment > Environment: Windows XP, should be valid for all platforms >Reporter: Rakesh Midha > Assigned To: Rakesh Midha >Priority: Minor > Fix For: 1.2 > > > In case for some reason the deployment with web console fails, the server > console is filled with hugh stacktrace, but user deploying the application is > given no status update on failure or success. User is just redirected back to > "Install New Application" page. > This sounds wrong for two reasons : > 1. User should be updated with a failure update, reason and what to do? > 2. Instead of server console, use logs. i.e. instead of system.out.println or > printstacktrace is log files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2111) Change Default WebContainer behaviour to disable AccessLogging
[ http://issues.apache.org/jira/browse/GERONIMO-2111?page=comments#action_12457956 ] Dain Sundstrom commented on GERONIMO-2111: -- Are you going to address this in 1.2? > Change Default WebContainer behaviour to disable AccessLogging > -- > > Key: GERONIMO-2111 > URL: http://issues.apache.org/jira/browse/GERONIMO-2111 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) >Reporter: Matt Hogstrom > Assigned To: Matt Hogstrom > Fix For: 1.2 > > > Currently Tomcat and Jetty have access logging enabled by default. This > should be changed to have it disabled by default for all geronimo assemblies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2455) Upgrade to new MX4J service release
[ http://issues.apache.org/jira/browse/GERONIMO-2455?page=all ] Dain Sundstrom updated GERONIMO-2455: - Fix Version/s: (was: 1.2) This won't be fixed in 1.2 > Upgrade to new MX4J service release > --- > > Key: GERONIMO-2455 > URL: http://issues.apache.org/jira/browse/GERONIMO-2455 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.1.1, 1.1, 1.0, 1.1.2, 1.2 >Reporter: Kevan Miller > Assigned To: Kevan Miller > Fix For: 1.1.2 > > > There's a timing hole in the mx4j Monitor implementation. In some scenarios, > a Monitor will not receive an appropriate Notifcation after being started. > The fix for the problem has been committed to mx4j head. I've run tests using > a private build from mx4j head, all looks well. > Once available, we should upgrade to the mx4j service release 3.0.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2170) Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories
[ http://issues.apache.org/jira/browse/GERONIMO-2170?page=all ] Dain Sundstrom closed GERONIMO-2170. Resolution: Fixed This should no longer be a problem. If you find a bad repo, please open a jira with a specific problem. > Tagged versions of Geronimo should not include people.apache.org/repository > in their list of maven repositories > --- > > Key: GERONIMO-2170 > URL: http://issues.apache.org/jira/browse/GERONIMO-2170 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.1.2 >Reporter: Kevan Miller > Assigned To: Kevan Miller > Fix For: 1.1.x, 1.2 > > > Geronimo 1.1.0 includes people.apache.org/repository in its list of maven > repo's. This repository is liable to be relocated in the future and is not > used to hold "released" version of packages. A tagged version of geronimo > should not be dependent on any resources in this repository. > 1.1.1 should not use this repository (and therefore will not be dependent on > any resources in the repository). The release checklist should be updated to > insure that this mistake is not repeated in the future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2411) Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts
[ http://issues.apache.org/jira/browse/GERONIMO-2411?page=comments#action_12457952 ] Dain Sundstrom commented on GERONIMO-2411: -- Fixed those, but found some more: ./applications/console/geronimo-console-framework/target/geronimo-console-framework-1.2-SNAPSHOT.war ./applications/console/geronimo-console-standard/target/geronimo-console-standard-1.2-SNAPSHOT.war ./applications/geronimo-ca-helper/target/geronimo-ca-helper-1.2-SNAPSHOT.war ./applications/geronimo-examples/geronimo-jsp-examples/target/geronimo-jsp-examples-1.2-SNAPSHOT.war ./applications/geronimo-examples/geronimo-servlet-examples/target/geronimo-servlet-examples-1.2-SNAPSHOT.war ./applications/geronimo-ldap-demo/target/geronimo-ldap-demo-1.2-SNAPSHOT.war ./applications/geronimo-remote-deploy/target/geronimo-remote-deploy-1.2-SNAPSHOT.war ./applications/geronimo-uddi-server/target/geronimo-uddi-server-1.2-SNAPSHOT.war ./applications/geronimo-welcome/target/geronimo-welcome-1.2-SNAPSHOT.war ./assemblies/geronimo-boilerplate-j2ee/target/geronimo-boilerplate-j2ee-1.2-SNAPSHOT.jar ./assemblies/geronimo-boilerplate-minimal/target/geronimo-boilerplate-minimal-1.2-SNAPSHOT.jar > Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts > -- > > Key: GERONIMO-2411 > URL: http://issues.apache.org/jira/browse/GERONIMO-2411 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) >Affects Versions: 1.0, 1.2, 1.x, 1.1, 1.1.1, 1.1.x, 1.1.2 >Reporter: Matt Hogstrom > Assigned To: Dain Sundstrom >Priority: Blocker > Fix For: 2.0, 1.2 > > > For release of these artifacts they need to include the LICENSE and NOTICE > files. Currently the build does not automatically include them. The M2 > build needs to be updated to include these artifacts in the build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2411) Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts
[ http://issues.apache.org/jira/browse/GERONIMO-2411?page=comments#action_12457938 ] Dain Sundstrom commented on GERONIMO-2411: -- The following jars don't have license or notice files: org/apache/geronimo/modules/geronimo-clustering/1.2-SNAPSHOT/geronimo-clustering-1.2-SNAPSHOT.jar org/apache/geronimo/modules/geronimo-clustering-builder-wadi/1.2-SNAPSHOT/geronimo-clustering-builder-wadi-1.2-SNAPSHOT.jar org/apache/geronimo/modules/geronimo-clustering-wadi/1.2-SNAPSHOT/geronimo-clustering-wadi-1.2-SNAPSHOT.jar org/apache/geronimo/modules/geronimo-jetty-clustering-wadi/1.2-SNAPSHOT/geronimo-jetty-clustering-wadi-1.2-SNAPSHOT.jar org/apache/geronimo/modules/geronimo-transformer/1.2-SNAPSHOT/geronimo-transformer-1.2-SNAPSHOT.jar org/apache/geronimo/modules/geronimo-clustering/1.2-SNAPSHOT/geronimo-clustering-1.2-SNAPSHOT.jar > Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts > -- > > Key: GERONIMO-2411 > URL: http://issues.apache.org/jira/browse/GERONIMO-2411 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) >Affects Versions: 1.0, 1.2, 1.x, 1.1, 1.1.1, 1.1.x, 1.1.2 >Reporter: Matt Hogstrom > Assigned To: Dain Sundstrom >Priority: Blocker > Fix For: 2.0, 1.2 > > > For release of these artifacts they need to include the LICENSE and NOTICE > files. Currently the build does not automatically include them. The M2 > build needs to be updated to include these artifacts in the build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2555) Windows scripts don't work when used from different drive
[ http://issues.apache.org/jira/browse/GERONIMO-2555?page=all ] Dain Sundstrom closed GERONIMO-2555. Resolution: Fixed Applied to 1.2 and 2.0. Thanks for the patch! > Windows scripts don't work when used from different drive > - > > Key: GERONIMO-2555 > URL: http://issues.apache.org/jira/browse/GERONIMO-2555 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: general >Affects Versions: 1.2 > Environment: Windows XP >Reporter: Mark DeLaFranier > Assigned To: Dain Sundstrom > Fix For: 1.1.2, 1.2, 2.0 > > Attachments: GERONIMO-2555.patch > > > If the scripts: geronimo.bat, startup.bat, shutdown.bat, deploy.bat are > launched from a drive other than the one Geronimo is located the "cd" > portions do not work when trying to determine the script location. > In order for a cross drive CD to work, the /d option must be used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2555) Windows scripts don't work when used from different drive
[ http://issues.apache.org/jira/browse/GERONIMO-2555?page=all ] Dain Sundstrom updated GERONIMO-2555: - Affects Version/s: (was: 1.1.2) > Windows scripts don't work when used from different drive > - > > Key: GERONIMO-2555 > URL: http://issues.apache.org/jira/browse/GERONIMO-2555 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: general >Affects Versions: 1.2 > Environment: Windows XP >Reporter: Mark DeLaFranier > Assigned To: Dain Sundstrom > Fix For: 1.2, 1.1.2, 2.0 > > Attachments: GERONIMO-2555.patch > > > If the scripts: geronimo.bat, startup.bat, shutdown.bat, deploy.bat are > launched from a drive other than the one Geronimo is located the "cd" > portions do not work when trying to determine the script location. > In order for a cross drive CD to work, the /d option must be used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2411) Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts
[ http://issues.apache.org/jira/browse/GERONIMO-2411?page=comments#action_12457023 ] Dain Sundstrom commented on GERONIMO-2411: -- That's nice, but the current reality is the files are published independently. Therefore we need to make sure they contain the proper legal files. > Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts > -- > > Key: GERONIMO-2411 > URL: http://issues.apache.org/jira/browse/GERONIMO-2411 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) >Affects Versions: 1.0, 1.2, 1.x, 1.1, 1.1.1, 1.1.x, 1.1.2 >Reporter: Matt Hogstrom > Assigned To: Dain Sundstrom >Priority: Blocker > Fix For: 2.0, 1.2 > > > For release of these artifacts they need to include the LICENSE and NOTICE > files. Currently the build does not automatically include them. The M2 > build needs to be updated to include these artifacts in the build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2377) deploying a new datasource with the same name does not indicate any problem in the console
[ http://issues.apache.org/jira/browse/GERONIMO-2377?page=all ] Dain Sundstrom closed GERONIMO-2377. Resolution: Fixed Applied to 1.2 and 2.0. Thanks for the patch Bill Dudney! > deploying a new datasource with the same name does not indicate any problem > in the console > -- > > Key: GERONIMO-2377 > URL: http://issues.apache.org/jira/browse/GERONIMO-2377 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2 >Reporter: Bill Dudney > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > Attachments: GERONIMO-2377.bdudney.patch > > > Console acts as if it deployeed the datasource but the console spits out an > error message; > Deployer operation failed: Module console.dbpool/DefaultDS/1.0/rar already > exists in the server. Try to undeploy it first or use the redeploy command. > org.apache.geronimo.common.DeploymentException: Module > console.dbpool/DefaultDS/1.0/rar already exists in the server. Try to > undeploy it first or use the redeploy command. > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > 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:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) > at java.lang.Thread.run(Thread.java:552) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2377) deploying a new datasource with the same name does not indicate any problem in the console
[ http://issues.apache.org/jira/browse/GERONIMO-2377?page=all ] Dain Sundstrom reassigned GERONIMO-2377: Assignee: Dain Sundstrom (was: Bill Dudney) > deploying a new datasource with the same name does not indicate any problem > in the console > -- > > Key: GERONIMO-2377 > URL: http://issues.apache.org/jira/browse/GERONIMO-2377 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2 >Reporter: Bill Dudney > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > Attachments: GERONIMO-2377.bdudney.patch > > > Console acts as if it deployeed the datasource but the console spits out an > error message; > Deployer operation failed: Module console.dbpool/DefaultDS/1.0/rar already > exists in the server. Try to undeploy it first or use the redeploy command. > org.apache.geronimo.common.DeploymentException: Module > console.dbpool/DefaultDS/1.0/rar already exists in the server. Try to > undeploy it first or use the redeploy command. > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > 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:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) > at java.lang.Thread.run(Thread.java:552) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2169) Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch)
[ http://issues.apache.org/jira/browse/GERONIMO-2169?page=all ] Dain Sundstrom closed GERONIMO-2169. Resolution: Invalid 1.2 doesn't use maven 1 anymore > Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding > tagged version of OpenEJB (not a branch) > --- > > Key: GERONIMO-2169 > URL: http://issues.apache.org/jira/browse/GERONIMO-2169 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.1.1, 1.1.2 >Reporter: Kevan Miller > Assigned To: Matt Hogstrom > Fix For: 1.2 > > > The m:co goal in tags/1.1.0 will checkout the branches/2.1 version of > OpenEJB. It should be checking out tags/v2_1. > We need to fix in Geronimo 1.1.1. The release process should be updated to > insure we don't repeat this mistake in the future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2637) Remove Peer transport setup from JMS portlet in 1.2
Remove Peer transport setup from JMS portlet in 1.2 --- Key: GERONIMO-2637 URL: http://issues.apache.org/jira/browse/GERONIMO-2637 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: console Reporter: Dain Sundstrom Assigned To: Paul McMahan Fix For: 1.2 The Peer transport doesn't work in 1.2 so the portlet option to configure it should be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1786) JMS Listeners for protocols activeio, peer and openwire fail to start
[ http://issues.apache.org/jira/browse/GERONIMO-1786?page=all ] Dain Sundstrom updated GERONIMO-1786: - Fix Version/s: (was: 1.2) Assignee: (was: Dain Sundstrom) After the upgrade to ActiveIO 3.0 the same problem exists. On inspection of the code the Peer transport doesn't support this operation. The GUI for this feature will be removed from 1.2. > JMS Listeners for protocols activeio, peer and openwire fail to start > - > > Key: GERONIMO-1786 > URL: http://issues.apache.org/jira/browse/GERONIMO-1786 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ, console >Affects Versions: 1.0, 1.2, 1.1, 1.1.1 > Environment: Geronimo 1.0.0 >Reporter: Donald Woods > Fix For: 2.0 > > > Even though addition of JMS Listeners for activeio, peer and openwire > protocols is successful, the listeners fail to > start with the following exceptions. > activeio --- java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > openwire --- javax.jms.JMSException: Could not load protocol: openwire. > Reason: java.lang.ClassNotFoundException: > org.activemq.transport.openwire.OpenWireTransportServerChannelFactory > peer --- javax.jms.JMSException: Could not load protocol: peer. Reason: > java.lang.ClassNotFoundException: > org.activemq.transport.peer.PeerTransportServerChannelFactory > Stack trace of the same. > 192: 14:17:49,499 ERROR [GBeanInstanceState] Error while starting; GBean is > now in the FAILED state: > objectName="geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.0/car,J2EEServer=geronimo,br > oker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.12340-aio" > 193: java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > 194: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTranspo > rtServerChannelFactory.java:60) > 195: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFact > ory.java:49) > 196: at > org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) > 197: at > org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) > 198: at > org.activemq.broker.impl.BrokerConnectorImpl.(BrokerConnectorImpl.java:69) > 199: at > org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:161) > 200: at > org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:129) > 201: at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java(Compiled > Code)) > 202: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > 203: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > 204: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) > 205: at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) > 206: at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) > 207: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java > :365) > 208: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > 209: at > org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$2b4c85ae.startRecursive() > 210: at > org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:79) > 211: at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > 212: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > 213: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > 214: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > 215: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > 216: at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > 217: at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > 218: at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > 219: at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > 220: at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > 221: at
[jira] Updated: (GERONIMO-2551) Plugin hits NPE if maven-metadata listed artifact doesn't exist or JAR artifact maven-metadata doesn't exist
[ http://issues.apache.org/jira/browse/GERONIMO-2551?page=all ] Dain Sundstrom updated GERONIMO-2551: - Assignee: Paul McMahan (was: Dain Sundstrom) > Plugin hits NPE if maven-metadata listed artifact doesn't exist or JAR > artifact maven-metadata doesn't exist > > > Key: GERONIMO-2551 > URL: http://issues.apache.org/jira/browse/GERONIMO-2551 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.1.1, 1.1.x, 1.2 >Reporter: Donald Woods > Assigned To: Paul McMahan > Fix For: 1.2, 2.0 > > Attachments: G2551-1.1.1.patch > > > 1) If an artifact version listed in a repos maven-metadata.xml doesn't exist, > then the PluginInstallerGBean code takes a NPE. > 2) If a maven-metadat.xml doesn't exist for a dependent JAR file artifact the > selected repo, then the PluginInstallerGBean code takes a NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2129) Allow user to specify the pool size for Stateless Session beans
[ http://issues.apache.org/jira/browse/GERONIMO-2129?page=all ] Dain Sundstrom reassigned GERONIMO-2129: Assignee: Matt Hogstrom If this is not going to make it into 1.2, please move to another release. > Allow user to specify the pool size for Stateless Session beans > --- > > Key: GERONIMO-2129 > URL: http://issues.apache.org/jira/browse/GERONIMO-2129 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Matt Hogstrom > Assigned To: Matt Hogstrom > Fix For: 1.2 > > > OpenEJB has code implemented to Pool Stateless session beans. This support > is currently hardcoded to a cache size of one which eliminates any > performance benefit of caching. A new attribute will be added to the OpenEJB > XSD that will allow the user to specify the pool size to be used for a > deployed stateless session bean. > The attribute will be and will take an integer value as its > argument. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2630) sun j2ee schemas are being redistributed in jsp and servlet specs
[ http://issues.apache.org/jira/browse/GERONIMO-2630?page=all ] Dain Sundstrom reassigned GERONIMO-2630: Assignee: Kevan Miller FWIU Kevan is looking at this one. > sun j2ee schemas are being redistributed in jsp and servlet specs > - > > Key: GERONIMO-2630 > URL: http://issues.apache.org/jira/browse/GERONIMO-2630 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Affects Versions: 1.2, 2.0 >Reporter: Kevan Miller > Assigned To: Kevan Miller >Priority: Blocker > Fix For: 1.2, 2.0 > > > A variety of Sun J2EE xsd's and dtd's are being redistributed in our corba > 3.0, jsp and servlet specs. > We had the same problem in our j2ee-schema module a while back. Without > written outhorization from Sun, we cannot redistribute these xsd's and dtd's. > Here's a list of problem files, that I see: > trunk/geronimo-corba_3.0_spec/src/main/idl/CosTransactions.idl:11://Copyright > 1995-1996, Sun Microsystems, Inc. > trunk/geronimo-jsp_2.0_spec/src/main/schema/jsp_2_0.xsd:18: Copyright > 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-jsp_2.0_spec/src/main/schema/web-jsptaglibrary_2_0.xsd:19: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-jsp_2.1_spec/src/main/schema/jsp_2_0.xsd:34: Copyright > 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-jsp_2.1_spec/src/main/schema/jsp_2_1.xsd:35: Copyright > 2003-2005 Sun Microsystems, Inc. > trunk/geronimo-jsp_2.1_spec/src/main/schema/web-jsptaglibrary_2_0.xsd:35: > Copyright 2003 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-jsp_2.1_spec/src/main/schema/web-jsptaglibrary_2_1.xsd:36: > Copyright 2003-2005 Sun Microsystems, Inc. > trunk/geronimo-servlet_2.4_spec/src/main/schema/j2ee_1_4.xsd:18: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.4_spec/src/main/schema/j2ee_web_services_1_1.xsd:18: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.4_spec/src/main/schema/j2ee_web_services_client_1_1.xsd:18: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.4_spec/src/main/schema/web-app_2_3.dtd:2:Copyright > 2000-2001 Sun Microsystems, Inc. 901 San Antonio Road, > trunk/geronimo-servlet_2.4_spec/src/main/schema/web-app_2_3.dtd:38:Copyright > 2000-2001 Sun Microsystems, Inc., > trunk/geronimo-servlet_2.4_spec/src/main/schema/web-app_2_4.xsd:18: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.5_spec/src/main/java/javax/servlet/http/package.html:6: > Copyright 2001 Sun Microsystems, Inc. All Rights Reserved. > trunk/geronimo-servlet_2.5_spec/src/main/java/javax/servlet/package.html:6: > Copyright 2001 Sun Microsystems, Inc. All Rights Reserved. > trunk/geronimo-servlet_2.5_spec/src/main/schema/j2ee_1_4.xsd:34: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.5_spec/src/main/schema/j2ee_web_services_1_1.xsd:34: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.5_spec/src/main/schema/j2ee_web_services_client_1_1.xsd:34: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.5_spec/src/main/schema/web-app_2_3.dtd:18:Copyright > 2000-2001 Sun Microsystems, Inc. 901 San Antonio Road, > trunk/geronimo-servlet_2.5_spec/src/main/schema/web-app_2_3.dtd:54:Copyright > 2000-2001 Sun Microsystems, Inc., > trunk/geronimo-servlet_2.5_spec/src/main/schema/web-app_2_4.xsd:34: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2339) Empty auth-constraint tag in web app security-constraint does not prevent access to resource
[ http://issues.apache.org/jira/browse/GERONIMO-2339?page=all ] Dain Sundstrom closed GERONIMO-2339. Resolution: Won't Fix Assignee: Vamsavardhana Reddy > Empty auth-constraint tag in web app security-constraint does not prevent > access to resource > > > Key: GERONIMO-2339 > URL: http://issues.apache.org/jira/browse/GERONIMO-2339 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security, Tomcat >Affects Versions: 1.1.1 > Environment: Geronimo Tomcat 1.1.1 >Reporter: Vamsavardhana Reddy > Assigned To: Vamsavardhana Reddy > Fix For: 1.1.2, 1.2, 2.0 > > Attachments: g2339.war > > > I have the following security constraint in web.xml > > > No Access > /forbidden/* > > > > This means /forbidden/* is not accessible by any user. The permission woks > fine if the application is deployed in Geronimo Jetty distribution. > If the application is deployed in Geronimo Tomcat distribution, URLs > /forbidden/* are accessible by all users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2210) Enable tests (geronimo-connector-builder :: **/Connector15DCBTest.java)
[ http://issues.apache.org/jira/browse/GERONIMO-2210?page=all ]
Dain Sundstrom updated GERONIMO-2210:
-
Fix Version/s: 2.0
(was: 1.2)
Assignee: Anita Kulshreshtha
No need to back port the fix to 1.2. If this is fixed in trunk, please close
the issue.
> Enable tests (geronimo-connector-builder :: **/Connector15DCBTest.java)
> ---
>
> Key: GERONIMO-2210
> URL: http://issues.apache.org/jira/browse/GERONIMO-2210
> Project: Geronimo
> Issue Type: Sub-task
> Security Level: public(Regular issues)
>Affects Versions: 1.2
>Reporter: Jason Dillon
> Assigned To: Anita Kulshreshtha
> Fix For: 2.0
>
>
> A few tests failed in non-obvious ways when run under the m2 build. Need
> someone who knows these tests better to inspect, resolve and enable the test
> (remove the test exclusions in the pom).
> The test fails with (on the console):
> {noformat}
> Ignoring connectiondefinition-instance/config-setting ServerUrl (no matching
> config-property in J2EE DD)
> Ignoring connectiondefinition-instance/config-setting UserName (no matching
> config-property in J2EE DD)
> Ignoring connectiondefinition-instance/config-setting Password (no matching
> config-property in J2EE DD)
> Geronimo connector deployment plan has admin object with interface
> 'javax.jms.Queue' and class 'org.activemq.message.ActiveMQQueue' but the
> ra.xml does not have a matching adminobject declared. Deleting this
> adminobject from the Geronimo plan.
> Geronimo connector deployment plan has admin object with interface
> 'javax.jms.Queue' and class 'org.activemq.message.ActiveMQQueue' but the
> ra.xml does not have a matching adminobject declared. Deleting this
> adminobject from the Geronimo plan.
> Geronimo connector deployment plan has admin object with interface
> 'javax.jms.Topic' and class 'org.activemq.message.ActiveMQTopic' but the
> ra.xml does not have a matching adminobject declared. Deleting this
> adminobject from the Geronimo plan.
> {noformat}
> And in the surefire report:
> {noformat}
> ---
> Test set: org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest
> ---
> Tests run: 4, Failures: 3, Errors: 1, Skipped: 0, Time elapsed: 1.488 sec <<<
> FAILURE!
> testCreateDatabase(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.66 sec <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.geronimo.connector.deployment.jsr88.ConnectionDefinition.configure(ConnectionDefinition.java:64)
> at
> org.apache.geronimo.connector.deployment.jsr88.ResourceAdapter.setConnectionDefinition(ResourceAdapter.java:111)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testCreateDatabase(Connector15DCBTest.java:114)
> testWriteWithNulls(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.046 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at junit.framework.Assert.assertEquals(Assert.java:207)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testWriteWithNulls(Connector15DCBTest.java:205)
> testCreateJMSResource(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.382 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<7> but was:<4>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at junit.framework.Assert.assertEquals(Assert.java:207)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testCreateJMSResource(Connector15DCBTest.java:355)
> testLoadJMSResources(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.38 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<7> but was:<4>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at junit.framework.Assert.assertEquals(Assert.java:207)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testLoadJMSResources
[jira] Updated: (GERONIMO-2283) Common libs portlet guesses wrong group ID, gives no usage advice
[ http://issues.apache.org/jira/browse/GERONIMO-2283?page=all ] Dain Sundstrom updated GERONIMO-2283: - Fix Version/s: (was: 1.2) Assignee: Vamsavardhana Reddy > Common libs portlet guesses wrong group ID, gives no usage advice > - > > Key: GERONIMO-2283 > URL: http://issues.apache.org/jira/browse/GERONIMO-2283 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: Vamsavardhana Reddy > Fix For: 1.1.x, 2.0 > > > When selecting a file for the repository portlet, it selected the version > number as the group ID. It should probably default to a blank group ID and > make the user enter it -- the best it can select from the file name is > probably the artifact, version, and type. > Also, it should have an option where you pick a JAR and it gives you the > dependency syntax you need to add that JAR to the classpath for an > application or other Geronimo module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2283) Common libs portlet guesses wrong group ID, gives no usage advice
[ http://issues.apache.org/jira/browse/GERONIMO-2283?page=comments#action_12456575 ] Dain Sundstrom commented on GERONIMO-2283: -- Still a problem in 1.2 > Common libs portlet guesses wrong group ID, gives no usage advice > - > > Key: GERONIMO-2283 > URL: http://issues.apache.org/jira/browse/GERONIMO-2283 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.1 >Reporter: Aaron Mulder > Fix For: 1.2, 1.1.x, 2.0 > > > When selecting a file for the repository portlet, it selected the version > number as the group ID. It should probably default to a blank group ID and > make the user enter it -- the best it can select from the file name is > probably the artifact, version, and type. > Also, it should have an option where you pick a JAR and it gives you the > dependency syntax you need to add that JAR to the classpath for an > application or other Geronimo module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1786) JMS Listeners for protocols activeio, peer and openwire fail to start
[ http://issues.apache.org/jira/browse/GERONIMO-1786?page=comments#action_12456572 ] Dain Sundstrom commented on GERONIMO-1786: -- May be cause by using activeio 3.0 SNAPSHOT when we should be using the 3.0 release. Will try upgrading. > JMS Listeners for protocols activeio, peer and openwire fail to start > - > > Key: GERONIMO-1786 > URL: http://issues.apache.org/jira/browse/GERONIMO-1786 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ, console >Affects Versions: 1.0, 1.1, 1.2, 1.1.1 > Environment: Geronimo 1.0.0 >Reporter: Donald Woods > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > > Even though addition of JMS Listeners for activeio, peer and openwire > protocols is successful, the listeners fail to > start with the following exceptions. > activeio --- java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > openwire --- javax.jms.JMSException: Could not load protocol: openwire. > Reason: java.lang.ClassNotFoundException: > org.activemq.transport.openwire.OpenWireTransportServerChannelFactory > peer --- javax.jms.JMSException: Could not load protocol: peer. Reason: > java.lang.ClassNotFoundException: > org.activemq.transport.peer.PeerTransportServerChannelFactory > Stack trace of the same. > 192: 14:17:49,499 ERROR [GBeanInstanceState] Error while starting; GBean is > now in the FAILED state: > objectName="geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.0/car,J2EEServer=geronimo,br > oker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.12340-aio" > 193: java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > 194: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTranspo > rtServerChannelFactory.java:60) > 195: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFact > ory.java:49) > 196: at > org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) > 197: at > org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) > 198: at > org.activemq.broker.impl.BrokerConnectorImpl.(BrokerConnectorImpl.java:69) > 199: at > org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:161) > 200: at > org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:129) > 201: at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java(Compiled > Code)) > 202: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > 203: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > 204: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) > 205: at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) > 206: at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) > 207: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java > :365) > 208: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > 209: at > org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$2b4c85ae.startRecursive() > 210: at > org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:79) > 211: at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > 212: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > 213: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > 214: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > 215: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > 216: at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > 217: at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > 218: at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > 219: at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > 220: at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > 221: at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerIm
[jira] Assigned: (GERONIMO-1786) JMS Listeners for protocols activeio, peer and openwire fail to start
[ http://issues.apache.org/jira/browse/GERONIMO-1786?page=all ] Dain Sundstrom reassigned GERONIMO-1786: Assignee: Dain Sundstrom > JMS Listeners for protocols activeio, peer and openwire fail to start > - > > Key: GERONIMO-1786 > URL: http://issues.apache.org/jira/browse/GERONIMO-1786 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ, console >Affects Versions: 1.0, 1.1, 1.2, 1.1.1 > Environment: Geronimo 1.0.0 >Reporter: Donald Woods > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > > Even though addition of JMS Listeners for activeio, peer and openwire > protocols is successful, the listeners fail to > start with the following exceptions. > activeio --- java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > openwire --- javax.jms.JMSException: Could not load protocol: openwire. > Reason: java.lang.ClassNotFoundException: > org.activemq.transport.openwire.OpenWireTransportServerChannelFactory > peer --- javax.jms.JMSException: Could not load protocol: peer. Reason: > java.lang.ClassNotFoundException: > org.activemq.transport.peer.PeerTransportServerChannelFactory > Stack trace of the same. > 192: 14:17:49,499 ERROR [GBeanInstanceState] Error while starting; GBean is > now in the FAILED state: > objectName="geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.0/car,J2EEServer=geronimo,br > oker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.12340-aio" > 193: java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > 194: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTranspo > rtServerChannelFactory.java:60) > 195: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFact > ory.java:49) > 196: at > org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) > 197: at > org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) > 198: at > org.activemq.broker.impl.BrokerConnectorImpl.(BrokerConnectorImpl.java:69) > 199: at > org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:161) > 200: at > org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:129) > 201: at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java(Compiled > Code)) > 202: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > 203: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > 204: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) > 205: at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) > 206: at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) > 207: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java > :365) > 208: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > 209: at > org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$2b4c85ae.startRecursive() > 210: at > org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:79) > 211: at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > 212: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > 213: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > 214: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > 215: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > 216: at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > 217: at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > 218: at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > 219: at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > 220: at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > 221: at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > 222: at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) > 223:
[jira] Assigned: (GERONIMO-2560) Realm added using SecurityRealm portlet does not work
[ http://issues.apache.org/jira/browse/GERONIMO-2560?page=all ] Dain Sundstrom reassigned GERONIMO-2560: Assignee: Vamsavardhana Reddy > Realm added using SecurityRealm portlet does not work > - > > Key: GERONIMO-2560 > URL: http://issues.apache.org/jira/browse/GERONIMO-2560 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, security >Affects Versions: 1.2, 2.0 >Reporter: Vamsavardhana Reddy > Assigned To: Vamsavardhana Reddy >Priority: Critical > Fix For: 1.2, 2.0 > > > A new security realm added using SecurityRealm portlet does not get listed in > the portlet. There are no deployment errors. Also, if an application is > configured to authenticate against this realm, login is failing since the > realm could not be found. > The deployment plan for security realms generated in the console seems to use > a "service" tag in place of "gbean" tag. If the service tag is changed to > gbean tag, the realm is getting listed in the SecurityRealm portlet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2549) NullPointerException: CommandListConfigurations
[ http://issues.apache.org/jira/browse/GERONIMO-2549?page=all ] Dain Sundstrom closed GERONIMO-2549. Resolution: Fixed Thanks for the patch Mark DeLaFranier > NullPointerException: CommandListConfigurations > --- > > Key: GERONIMO-2549 > URL: http://issues.apache.org/jira/browse/GERONIMO-2549 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.2 > Environment: windows xp >Reporter: Mark DeLaFranier > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > Attachments: GERONIMO-2549.patch > > > > deploy.bat search-plugins http://bogus-server/maven2 > Using GERONIMO_BASE: D:\geronimo\1.2 > Using GERONIMO_HOME: D:\geronimo\1.2 > Using GERONIMO_TMPDIR: D:\geronimo\1.2\var\temp > Using JRE_HOME:d:\dev\jdk142 > Username: system > Password: *** > Exception in thread "main" java.lang.NullPointerException > at > org.apache.geronimo.deployment.cli.CommandListConfigurations.execute(CommandListConfigurations.java:84) > at > org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:160) > at > org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:314) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2613) Some portlets in the console can't size correctly
[ http://issues.apache.org/jira/browse/GERONIMO-2613?page=all ] Dain Sundstrom updated GERONIMO-2613: - Fix Version/s: (was: 1.2) (was: 2.0) > Some portlets in the console can't size correctly > - > > Key: GERONIMO-2613 > URL: http://issues.apache.org/jira/browse/GERONIMO-2613 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console > Environment: this is for revision r480769 >Reporter: Hernan Cunico > > Here is a list of portlets I saw having rendering problems. > JMS Server Manager (uses just 50% of the available space) > Installed Web Applications (does not wrap up, have to scroll sideways) > Installed J2EE Connectors (does not wrap up, have to scroll sideways) > Installed System Modules (does not wrap up, have to scroll sideways) > Console Realm, both Console Realm Users and Console Realm Groups (uses just > 50% of the available space) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1431) Make deploy tool and hot deploy directory work better together
[ http://issues.apache.org/jira/browse/GERONIMO-1431?page=all ] Dain Sundstrom updated GERONIMO-1431: - Fix Version/s: 2.0 (was: 1.2) > Make deploy tool and hot deploy directory work better together > -- > > Key: GERONIMO-1431 > URL: http://issues.apache.org/jira/browse/GERONIMO-1431 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment, Hot Deploy Dir >Affects Versions: 1.0 >Reporter: Aaron Mulder >Priority: Critical > Fix For: 2.0 > > Attachments: hotdeploydelete.patch > > > Right now if you deploy something with the deploy tool and then drop an > update in the hot deploy directory, it doesn't work. The hot deploy dir > expects you to only use the hot dpeloy dir for that module. > Likewise, if you deploy something with the hot deploy dir and then undeploy > it with the deploy tool, it is not deleted from the hot deploy dir. > Both of those can be fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2387) Server life cycle log entries should be generated by the server
[ http://issues.apache.org/jira/browse/GERONIMO-2387?page=all ] Dain Sundstrom updated GERONIMO-2387: - Fix Version/s: (was: 1.2) > Server life cycle log entries should be generated by the server > --- > > Key: GERONIMO-2387 > URL: http://issues.apache.org/jira/browse/GERONIMO-2387 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Kevan Miller > Fix For: 1.1.2, 2.0 > > > By default, geronimo should generate life cycle log entries. For example: > 1) "starting" with environmental information > 2) "started" > 3) stopping -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2555) Windows scripts don't work when used from different drive
[ http://issues.apache.org/jira/browse/GERONIMO-2555?page=all ] Dain Sundstrom reassigned GERONIMO-2555: Assignee: Dain Sundstrom > Windows scripts don't work when used from different drive > - > > Key: GERONIMO-2555 > URL: http://issues.apache.org/jira/browse/GERONIMO-2555 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: general >Affects Versions: 1.2, 1.1.2 > Environment: Windows XP >Reporter: Mark DeLaFranier > Assigned To: Dain Sundstrom > Fix For: 1.1.2, 1.2, 2.0 > > Attachments: GERONIMO-2555.patch > > > If the scripts: geronimo.bat, startup.bat, shutdown.bat, deploy.bat are > launched from a drive other than the one Geronimo is located the "cd" > portions do not work when trying to determine the script location. > In order for a cross drive CD to work, the /d option must be used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2551) Plugin hits NPE if maven-metadata listed artifact doesn't exist or JAR artifact maven-metadata doesn't exist
[ http://issues.apache.org/jira/browse/GERONIMO-2551?page=all ] Dain Sundstrom reassigned GERONIMO-2551: Assignee: Dain Sundstrom > Plugin hits NPE if maven-metadata listed artifact doesn't exist or JAR > artifact maven-metadata doesn't exist > > > Key: GERONIMO-2551 > URL: http://issues.apache.org/jira/browse/GERONIMO-2551 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.1.1, 1.1.x, 1.2 >Reporter: Donald Woods > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > Attachments: G2551-1.1.1.patch > > > 1) If an artifact version listed in a repos maven-metadata.xml doesn't exist, > then the PluginInstallerGBean code takes a NPE. > 2) If a maven-metadat.xml doesn't exist for a dependent JAR file artifact the > selected repo, then the PluginInstallerGBean code takes a NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2549) NullPointerException: CommandListConfigurations
[ http://issues.apache.org/jira/browse/GERONIMO-2549?page=all ] Dain Sundstrom reassigned GERONIMO-2549: Assignee: Dain Sundstrom > NullPointerException: CommandListConfigurations > --- > > Key: GERONIMO-2549 > URL: http://issues.apache.org/jira/browse/GERONIMO-2549 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.2 > Environment: windows xp >Reporter: Mark DeLaFranier > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > Attachments: GERONIMO-2549.patch > > > > deploy.bat search-plugins http://bogus-server/maven2 > Using GERONIMO_BASE: D:\geronimo\1.2 > Using GERONIMO_HOME: D:\geronimo\1.2 > Using GERONIMO_TMPDIR: D:\geronimo\1.2\var\temp > Using JRE_HOME:d:\dev\jdk142 > Username: system > Password: *** > Exception in thread "main" java.lang.NullPointerException > at > org.apache.geronimo.deployment.cli.CommandListConfigurations.execute(CommandListConfigurations.java:84) > at > org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:160) > at > org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:314) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2493) Integrate Axis2 webservices
[ http://issues.apache.org/jira/browse/GERONIMO-2493?page=all ] Dain Sundstrom updated GERONIMO-2493: - Fix Version/s: (was: 1.2) Axis 2 will be integrated in 2.0 not 1.2 > Integrate Axis2 webservices > --- > > Key: GERONIMO-2493 > URL: http://issues.apache.org/jira/browse/GERONIMO-2493 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 1.2 >Reporter: David Jencks > Fix For: 2.0 > > > Integrate axis 2 for webservices. Probably at least 3 steps > - pojo ws > - ejb ws > - ws client -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2411) Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts
[ http://issues.apache.org/jira/browse/GERONIMO-2411?page=all ] Dain Sundstrom updated GERONIMO-2411: - Summary: Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts (was: CAR, WAR and EAR artifacts are missing NOTICE and LICENSE files.) Issue Type: Task (was: Bug) Assignee: Dain Sundstrom Priority: Blocker (was: Major) > Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts > -- > > Key: GERONIMO-2411 > URL: http://issues.apache.org/jira/browse/GERONIMO-2411 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) >Affects Versions: 1.0, 1.2, 1.x, 1.1, 1.1.1, 1.1.x, 1.1.2 >Reporter: Matt Hogstrom > Assigned To: Dain Sundstrom >Priority: Blocker > Fix For: 2.0, 1.2 > > > For release of these artifacts they need to include the LICENSE and NOTICE > files. Currently the build does not automatically include them. The M2 > build needs to be updated to include these artifacts in the build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2559) cannot stop activemq via kernel shutdown
[ http://issues.apache.org/jira/browse/GERONIMO-2559?page=all ] Dain Sundstrom closed GERONIMO-2559. Resolution: Fixed This was fixed some where in 1.2 :) > cannot stop activemq via kernel shutdown > > > Key: GERONIMO-2559 > URL: http://issues.apache.org/jira/browse/GERONIMO-2559 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 1.2 > Environment: sun j2se 1.5.0_07 >Reporter: Paul McMahan > Fix For: 1.2, 2.0 > > > Shutdown the server from the admin console. This ends up invoking > kernel.shutdown(). The following stack trace is generated: > 11:59:25,265 ERROR [JournalPersistenceAdapter] Could not stop service: > org.apach > [EMAIL PROTECTED] Reason: java.lang.Nul > lPointerException > java.lang.NullPointerException > at > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT > rackingCoordinator.handleReleased(ConnectionTrackingCoordinator.java:127) > at > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT > rackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod > Invoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio > n.java:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. > java:820) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 > 7) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat > ionInvoker.java:35) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro > xyMethodInterceptor.java:97) > at > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT > racker$$EnhancerByCGLIB$$c20afa50.handleReleased() > at > org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor. > returnConnection(ConnectionTrackingInterceptor.java:81) > at > org.apache.geronimo.connector.outbound.GeronimoConnectionEventListene > r.connectionClosed(GeronimoConnectionEventListener.java:67) > at > org.tranql.connector.AbstractManagedConnection.connectionClosed(Abstr > actManagedConnection.java:102) > at > org.tranql.connector.jdbc.ConnectionHandle.close(ConnectionHandle.jav > a:97) > at > org.apache.activemq.store.jdbc.DefaultDatabaseLocker.stop(DefaultData > baseLocker.java:81) > at > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.stop(JDBCPersis > tenceAdapter.java:202) > at > org.apache.activemq.store.journal.JournalPersistenceAdapter.stop(Jour > nalPersistenceAdapter.java:254) > at > org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) > at > org.apache.activemq.broker.BrokerService.stop(BrokerService.java:443) > at > org.apache.activemq.gbean.BrokerServiceGBeanImpl.doStop(BrokerService > GBeanImpl.java:107) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBean > Instance.java:1146) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop( > GBeanInstanceState.java:337) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan > ceState.java:188) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja > va:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja > va:423) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan > ceState.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja > va:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja > va:423) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan > ceState.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja > va:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja > va:423) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager$Shutdown > Hook.run(KernelConfigurationManager.java:310) > at > org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(Basi > cKernel.java:668) > at > org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.jav > a:645) > at > org.apache.geronimo.console.servermanager.ServerManagerPortlet.doView > (ServerManagerPortlet.java:72) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) > at > org.
[jira] Updated: (GERONIMO-1917) repository doesn't deal well with case insensitive file systems
[ http://issues.apache.org/jira/browse/GERONIMO-1917?page=all ] Dain Sundstrom updated GERONIMO-1917: - Fix Version/s: 2.0 (was: 1.2) This will not be fixed in 1.2 > repository doesn't deal well with case insensitive file systems > --- > > Key: GERONIMO-1917 > URL: http://issues.apache.org/jira/browse/GERONIMO-1917 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.1, 1.1.1, 1.1.x, 1.1.2 >Reporter: David Jencks > Fix For: 1.1.2, 2.0 > > > If you've installed a configuration A/B/1/car and then look for a/b/1/car, > the repository will claim it's there on a case insensitive file system, but > then further logic in the config store/ manager blows up because those are > different artifacts. Solution appears to be to check when locating an > artifact that the case from the file system matches the case you are asking > for. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1987) Change "configuration" to "module"
[ http://issues.apache.org/jira/browse/GERONIMO-1987?page=all ] Dain Sundstrom closed GERONIMO-1987. Fix Version/s: 1.1 (was: 1.2) Resolution: Fixed All completed sub-tasks were closed in 1.1 > Change "configuration" to "module" > -- > > Key: GERONIMO-1987 > URL: http://issues.apache.org/jira/browse/GERONIMO-1987 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 1.1 >Reporter: Dain Sundstrom > Fix For: 1.1 > > > It seems like "configuration" can be confusing, as it more traditionally > refers to a larger scope like an entire installation. For example, if you > say you have two different WebLogic configurations or two different Apache > (HTTP) configurations, you're saying either you have two installations, or > you have two totally separate product configurations available for the same > product installation. You're not saying you have an app and a database pool > within one runtime, but that's what "two different configurations" presently > would mean in relation to Geronimo. > It seems like it would be clearer to say that a Geronimo installation loads > many modules, and each module includes many components (GBeans). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1991) Change "configuration" to "module" in java classes
[ http://issues.apache.org/jira/browse/GERONIMO-1991?page=all ] Dain Sundstrom closed GERONIMO-1991. Resolution: Later Assignee: Dain Sundstrom Renaming the classes isn't important. > Change "configuration" to "module" in java classes > -- > > Key: GERONIMO-1991 > URL: http://issues.apache.org/jira/browse/GERONIMO-1991 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2540) Naming builders do not see classes located in a war in an ear
[ http://issues.apache.org/jira/browse/GERONIMO-2540?page=all ] Dain Sundstrom closed GERONIMO-2540. Resolution: Fixed > Naming builders do not see classes located in a war in an ear > - > > Key: GERONIMO-2540 > URL: http://issues.apache.org/jira/browse/GERONIMO-2540 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: naming >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > > When building ejb references that class loader of the outer ear is used > instead of the module class loader. This means that the naming builder will > not be able to see the war classes. This problem also occurs in the other > naming builders. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2540) Naming builders do not see classes located in a war in an ear
Naming builders do not see classes located in a war in an ear - Key: GERONIMO-2540 URL: http://issues.apache.org/jira/browse/GERONIMO-2540 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: naming Reporter: Dain Sundstrom Assigned To: Dain Sundstrom When building ejb references that class loader of the outer ear is used instead of the module class loader. This means that the naming builder will not be able to see the war classes. This problem also occurs in the other naming builders. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2528) Move generic webservice specifc code to a separate builder module
[ http://issues.apache.org/jira/browse/GERONIMO-2528?page=all ] Dain Sundstrom closed GERONIMO-2528. Resolution: Fixed > Move generic webservice specifc code to a separate builder module > - > > Key: GERONIMO-2528 > URL: http://issues.apache.org/jira/browse/GERONIMO-2528 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: webservices >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > > The geronimo-axis-builder module contains generic webservice processing code > that should be available separately. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2528) Move generic webservice specifc code to a separate builder module
Move generic webservice specifc code to a separate builder module - Key: GERONIMO-2528 URL: http://issues.apache.org/jira/browse/GERONIMO-2528 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: webservices Reporter: Dain Sundstrom Assigned To: Dain Sundstrom The geronimo-axis-builder module contains generic webservice processing code that should be available separately. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2503) Webapp classloader prefers WEB-INF/lib over WEB-INF/classes
[ http://issues.apache.org/jira/browse/GERONIMO-2503?page=comments#action_12443984 ] Dain Sundstrom commented on GERONIMO-2503: -- This fix broke deployment of any war file that kept the Servlet implementation classes in WEB-INF/classes. I fixed this in GERONIMO-2511. > Webapp classloader prefers WEB-INF/lib over WEB-INF/classes > --- > > Key: GERONIMO-2503 > URL: http://issues.apache.org/jira/browse/GERONIMO-2503 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: web >Affects Versions: 1.1.1, 1.1 > Environment: windows and linux, jetty and tomcat >Reporter: Nikla Ratinen > Assigned To: Rick McGuire > Fix For: 1.1.2, 1.2 > > Attachments: patch.txt, test.war > > > Application classloader looks in WAR's WEB-INF/lib before WEB-INF/classes. > This is in violation of servlet 2.4 (and 2.3) specification, 9.5 Directory > Structure, which states: > "TheWeb application class loader must load classes from the WEB-INF/ classes > directory first, and then from library JARs in the WEB-INF/lib directory." > This behaviour prevents web application from overriding classes and resources > from included libraries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2511) WEB-INF/Classes is not visible during deployment
[ http://issues.apache.org/jira/browse/GERONIMO-2511?page=all ] Dain Sundstrom closed GERONIMO-2511. Resolution: Fixed Changed the copy loop to keep a collection of libraries. Then moved the back the code that installed the WEB-INF/classes to below the copy loop and added a loop below that to install the libs. > WEB-INF/Classes is not visible during deployment > > > Key: GERONIMO-2511 > URL: http://issues.apache.org/jira/browse/GERONIMO-2511 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: web >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > > AbstractWebModuleBuilder was changed in GERONIMO-2503 to add the > WEB-INF/classes before adding the jar contents to the repository. This does > not work because the code that adds the urls to the class loader checks if > the URL exists before adding it. This means that the WEB-INF/classes > directory is ignored during deployment causing deployments to fail that have > the servlet implementation classes in the WEB-INF/classes directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2511) WEB-INF/Classes is not visible during deployment
WEB-INF/Classes is not visible during deployment Key: GERONIMO-2511 URL: http://issues.apache.org/jira/browse/GERONIMO-2511 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: web Reporter: Dain Sundstrom Assigned To: Dain Sundstrom AbstractWebModuleBuilder was changed in GERONIMO-2503 to add the WEB-INF/classes before adding the jar contents to the repository. This does not work because the code that adds the urls to the class loader checks if the URL exists before adding it. This means that the WEB-INF/classes directory is ignored during deployment causing deployments to fail that have the servlet implementation classes in the WEB-INF/classes directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2510) CORBA/RMI delegate code requires delegate implementation to be on the system classpath
CORBA/RMI delegate code requires delegate implementation to be on the system
classpath
--
Key: GERONIMO-2510
URL: http://issues.apache.org/jira/browse/GERONIMO-2510
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: CORBA
Reporter: Dain Sundstrom
When the java.rmi.Util class is loaded, it uses Class.forName to load the
UtilDelegate specified in a system property. This is what yoko uses:
private static UtilDelegate delegate = null;
private static final String defaultDelegate =
"org.apache.yoko.rmi.impl.UtilImpl";
static {
// Initialize delegate
String delegateName = System.getProperty("javax.rmi.CORBA.UtilClass",
defaultDelegate);
try {
delegate = (UtilDelegate)Class.forName(delegateName).newInstance();
} catch (Exception e) {
throw new RuntimeException("Can not create Util delegate:
"+delegateName, e);
}
}
IIRC Class.forName(String) uses the class loader of the class containing the
code, and since java.rmi.Util will always be on the system class path our
delegate must be on the system class path :(
I see a few choices:
* change yoko to use the thread context class loader... then add a gbean to set
the property and load the Util class. repeat of every delegate class.
* write a delegate delegate that allows us to swap out the actual delegate
implementation later
* split out out delegate class into a jar we can put on the system class path
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2509) Appclient missing activeio from the class path
[ http://issues.apache.org/jira/browse/GERONIMO-2509?page=all ] Dain Sundstrom closed GERONIMO-2509. Resolution: Fixed Added dependency on activeio and geronimo-interceptor to the client plan. > Appclient missing activeio from the class path > -- > > Key: GERONIMO-2509 > URL: http://issues.apache.org/jira/browse/GERONIMO-2509 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: application client >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > > JaasLoginServiceRemotingClient uses some code from ActiveIO but the activeio > jar in on in the application client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2509) Appclient missing activeio from the class path
Appclient missing activeio from the class path -- Key: GERONIMO-2509 URL: http://issues.apache.org/jira/browse/GERONIMO-2509 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: application client Reporter: Dain Sundstrom Assigned To: Dain Sundstrom JaasLoginServiceRemotingClient uses some code from ActiveIO but the activeio jar in on in the application client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2508) An empty enterprise naming context does not cotain a context at java:comp/env
[ http://issues.apache.org/jira/browse/GERONIMO-2508?page=all ]
Dain Sundstrom closed GERONIMO-2508.
Resolution: Fixed
ENC now adds an empty "env" context if not env bindings are present in the
context map.
> An empty enterprise naming context does not cotain a context at java:comp/env
> -
>
> Key: GERONIMO-2508
> URL: http://issues.apache.org/jira/browse/GERONIMO-2508
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: naming
>Reporter: Dain Sundstrom
> Assigned To: Dain Sundstrom
>Priority: Blocker
>
> For a component without any defined enc values, the following code will throw
> an exception:
> new InitialContext().lookup("java:comp/env");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2508) An empty enterprise naming context does not cotain a context at java:comp/env
An empty enterprise naming context does not cotain a context at java:comp/env
-
Key: GERONIMO-2508
URL: http://issues.apache.org/jira/browse/GERONIMO-2508
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: naming
Reporter: Dain Sundstrom
Assigned To: Dain Sundstrom
Priority: Blocker
For a component without any defined enc values, the following code will throw
an exception:
new InitialContext().lookup("java:comp/env");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (XBEAN-55) Custom Map values aren't parsed properly
[ http://issues.apache.org/jira/browse/XBEAN-55?page=all ] Dain Sundstrom closed XBEAN-55. --- Fix Version/s: 2.7 Resolution: Fixed Thanks Dan > Custom Map values aren't parsed properly > > > Key: XBEAN-55 > URL: http://issues.apache.org/jira/browse/XBEAN-55 > Project: XBean > Issue Type: Bug > Components: spring >Affects Versions: 2.6 >Reporter: Dan Diephouse > Assigned To: Dain Sundstrom > Fix For: 2.7 > > Attachments: mappatch > > > If you use the custom map syntax that I wrote, it only supports setting > values which are Strings. This patch fixes that issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (XBEAN-55) Custom Map values aren't parsed properly
[ http://issues.apache.org/jira/browse/XBEAN-55?page=all ] Dain Sundstrom reassigned XBEAN-55: --- Assignee: Dain Sundstrom > Custom Map values aren't parsed properly > > > Key: XBEAN-55 > URL: http://issues.apache.org/jira/browse/XBEAN-55 > Project: XBean > Issue Type: Bug > Components: spring >Affects Versions: 2.6 >Reporter: Dan Diephouse > Assigned To: Dain Sundstrom > Attachments: mappatch > > > If you use the custom map syntax that I wrote, it only supports setting > values which are Strings. This patch fixes that issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1960) Reject invalid GBean references at deployment time
[ http://issues.apache.org/jira/browse/GERONIMO-1960?page=all ] Dain Sundstrom closed GERONIMO-1960. Resolution: Fixed > Reject invalid GBean references at deployment time > -- > > Key: GERONIMO-1960 > URL: http://issues.apache.org/jira/browse/GERONIMO-1960 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment, kernel >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: Dain Sundstrom > Fix For: 1.1.1, 1.2 > > Attachments: 1960.patch, filestore.jar, geronimo-service.xml, > geronimo-service.xml, openejb-1960.patch > > > Invalid GBean references are not identified until the component attempts to > start which is very inconvenient for users. > If you deploy the attached JAR and plan, it is distributed successfully but > fails during startup when the GBean in the plan can't find ServerInfo. This > is not correct behavior -- we should fail during distribute if there are bad > GBean references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1960) Reject invalid GBean references at deployment time
[ http://issues.apache.org/jira/browse/GERONIMO-1960?page=all ] Dain Sundstrom updated GERONIMO-1960: - Issue Type: Improvement (was: Bug) Workflow: RTC Workflow (was: jira) > Reject invalid GBean references at deployment time > -- > > Key: GERONIMO-1960 > URL: http://issues.apache.org/jira/browse/GERONIMO-1960 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment, kernel >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: Dain Sundstrom > Fix For: 1.2, 1.1.1 > > Attachments: 1960.patch, filestore.jar, geronimo-service.xml, > geronimo-service.xml, openejb-1960.patch > > > Invalid GBean references are not identified until the component attempts to > start which is very inconvenient for users. > If you deploy the attached JAR and plan, it is distributed successfully but > fails during startup when the GBean in the plan can't find ServerInfo. This > is not correct behavior -- we should fail during distribute if there are bad > GBean references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1960) Reject invalid GBean references at deployment time
[ http://issues.apache.org/jira/browse/GERONIMO-1960?page=all ] Dain Sundstrom updated GERONIMO-1960: - Summary: Reject invalid GBean references at deployment time (was: Bad GBean reference isn't caught during deployment) Description: Invalid GBean references are not identified until the component attempts to start which is very inconvenient for users. If you deploy the attached JAR and plan, it is distributed successfully but fails during startup when the GBean in the plan can't find ServerInfo. This is not correct behavior -- we should fail during distribute if there are bad GBean references. was:If you deploy the attached JAR and plan, it is distributed successfully but fails during startup when the GBean in the plan can't find ServerInfo. This is not correct behavior -- we should fail during distribute if there are bad GBean references. Priority: Major (was: Blocker) > Reject invalid GBean references at deployment time > -- > > Key: GERONIMO-1960 > URL: http://issues.apache.org/jira/browse/GERONIMO-1960 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment, kernel >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: Dain Sundstrom > Fix For: 1.2, 1.1.1 > > Attachments: 1960.patch, filestore.jar, geronimo-service.xml, > geronimo-service.xml, openejb-1960.patch > > > Invalid GBean references are not identified until the component attempts to > start which is very inconvenient for users. > If you deploy the attached JAR and plan, it is distributed successfully but > fails during startup when the GBean in the plan can't find ServerInfo. This > is not correct behavior -- we should fail during distribute if there are bad > GBean references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (GERONIMO-1960) Bad GBean reference isn't caught during deployment
[ http://issues.apache.org/jira/browse/GERONIMO-1960?page=all ] Dain Sundstrom reopened GERONIMO-1960: -- > Bad GBean reference isn't caught during deployment > -- > > Key: GERONIMO-1960 > URL: http://issues.apache.org/jira/browse/GERONIMO-1960 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment, kernel >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: Dain Sundstrom >Priority: Blocker > Fix For: 1.2, 1.1.1 > > Attachments: 1960.patch, filestore.jar, geronimo-service.xml, > geronimo-service.xml, openejb-1960.patch > > > If you deploy the attached JAR and plan, it is distributed successfully but > fails during startup when the GBean in the plan can't find ServerInfo. This > is not correct behavior -- we should fail during distribute if there are bad > GBean references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2354) Replace concurrent with backport-concurrent-util
[ http://issues.apache.org/jira/browse/GERONIMO-2354?page=comments#action_12432699 ] Dain Sundstrom commented on GERONIMO-2354: -- +1 looks good to me > Replace concurrent with backport-concurrent-util > > > Key: GERONIMO-2354 > URL: http://issues.apache.org/jira/browse/GERONIMO-2354 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 1.2 >Reporter: Jason Dillon > Attachments: GERONIMO-2354-openejb2.diff, > GERONIMO-2354-openejb2.diff, GERONIMO-2354.diff, GERONIMO-2354.diff > > > Replace usage of concurrent classes with backport-concurrent-util. > Preparation for using java.util.concurrent in JDK 1.5, and reduce the need > for 2 sets of concurrent classes on the boot classloader. > Sill need to include concurrent, as activeio and openejb still have some > dependencies upon it... but this brings us a step closer to not needing both. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2364) Update geronimo to use ActiveMQ 4.1.x
[ http://issues.apache.org/jira/browse/GERONIMO-2364?page=comments#action_12432698 ] Dain Sundstrom commented on GERONIMO-2364: -- +1 Looks good to me > Update geronimo to use ActiveMQ 4.1.x > - > > Key: GERONIMO-2364 > URL: http://issues.apache.org/jira/browse/GERONIMO-2364 > Project: Geronimo > Issue Type: RTC > Security Level: public(Regular issues) > Components: ActiveMQ >Reporter: Hiram Chirino > Assigned To: Hiram Chirino > Fix For: 1.2 > > Attachments: GERONIMO-2364.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2153) Global JNDI
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=all ] Dain Sundstrom reassigned GERONIMO-2153: Assignee: Dain Sundstrom > Global JNDI > --- > > Key: GERONIMO-2153 > URL: http://issues.apache.org/jira/browse/GERONIMO-2153 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: naming >Affects Versions: 1.2 >Reporter: Krishnakumar B > Assigned To: Dain Sundstrom > Attachments: ConnectorJNDIBindingGBean.java, > GeronimoGlobalContext.java, jndi-project.zip > > > Implementing Global JNDI for server > Requirements > * Non -persistent > * Read/Write > * Bindings to JNDI/COS-NAMING/JAXR > * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2305) geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad
[ http://issues.apache.org/jira/browse/GERONIMO-2305?page=all ] Dain Sundstrom updated GERONIMO-2305: - Attachment: GERONIMO-2305.patch This patch should fix the problem, but please verify before I apply it. > geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad > --- > > Key: GERONIMO-2305 > URL: http://issues.apache.org/jira/browse/GERONIMO-2305 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.1 > Environment: Geronimo-jetty-1.1 running in Java 1.5.0_06 on Mac OS X > or Java 1.5.0_06 on XP > Aug. 6 Trinidad snapshot - > http://people.apache.org/maven-snapshot-repository/org/apache/myfaces/trinidad/ >Reporter: Chris Herborth >Priority: Blocker > Attachments: devSignup.war, devSignup.war, GERONIMO-2305.patch > > > Web application (built with current MyFaces and Trinidad) crashes during page > loading with this stack trace: > 7-Aug-2006 10:40:40 AM > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider getCapabilities > SEVERE: could not get capabilities from capabilities document > java.lang.IllegalArgumentException: Expected url [jar:file:/C:/Documents and > Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/capabilities.xml], > but was [jar:file:/C:/Documents and > Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/htmlBasic.xml] > at > org.apache.geronimo.kernel.classloader.JarFileUrlStreamHandler.openConnection(JarFileUrlStreamHandler.java:63) > at java.net.URL.openConnection(Unknown Source) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilityDataDocumentParser.parse(CapabilityDataDocumentParser.java:60) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:315) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:226) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:293) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:212) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getDefaultAgentCapabilities(CapabilitiesDocument.java:117) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument.(CapabilitiesDocument.java:38) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.endElement(CapabilitiesDocumentParser.java:184) > at > org.apache.myfaces.adfinternal.share.xml.TreeBuilder$Handler.endElement(TreeBuilder.java:463) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at > org.apache.myfaces.adfinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:166) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.createInstance(CapabilitiesDocumentParser.java:67) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilityDocument(CapabilitiesProvider.java:128) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilities(CapabilitiesProvider.java:110) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider.getCapabilities(CapabilitiesProvider.java:91) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl._getCapabilityMap(AdfFacesAgentImpl.java:263) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl._initialize(AdfFacesAgentImpl.java:233) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl.(AdfFacesAgentImpl.java:40) > at > org.apache.myfaces.adfinternal.context.AdfFacesContextImpl.getAgent(AdfFacesContextImpl.java:533) > at > org.apache.myfaces.adfinternal.renderkit.core.CoreRenderKit
[jira] Closed: (GERONIMO-2277) Remove TransactionContextManager
[ http://issues.apache.org/jira/browse/GERONIMO-2277?page=all ] Dain Sundstrom closed GERONIMO-2277. > Remove TransactionContextManager > > > Key: GERONIMO-2277 > URL: http://issues.apache.org/jira/browse/GERONIMO-2277 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > Fix For: 1.2 > > Attachments: GERONIMO-2277.patch > > > If you use the Geronimo TransactionContextManager, you can't use the > TransactionManager interface directly since the TCM needs to know about all > TM calls. Additionally, to use the TCM you must demarcate all changes in > "component context" by starting an unspecified transaction context. This is > all quite invasive and makes it hard to use our code in third part > environments such as Spring or plain old Tomcat. > I propose we remove the TransactionContextManager and replaced all uses with > a plain old TransactionManager. This will also allow us to removed all code > from web containers, app client and timer that was simply demarcating an > unspecified transaction context, which is no longer needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2277) Remove TransactionContextManager
[ http://issues.apache.org/jira/browse/GERONIMO-2277?page=all ] Dain Sundstrom updated GERONIMO-2277: - Attachment: GERONIMO-2277.patch I merged all changes from head back into notcm and fixed the m2 build. I also made a few changes noted below based on requests for David. I suggest you test the notcm branch directly. If you want to try the merge, use the same command as before, and you'll have to resolve some conflicts (I have no idea why svn marks them as conflicts). Here are the commands I used: svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo cd geronimo svn merge -r 427246:HEAD https://svn.apache.org/repos/asf/geronimo/branches/dain/notcm . # resolve the conflicts by taking the files from notcm mv bootstrap.merge-right* \ bootstrap svn resolved bootstrap chmod u+x bootstrap mv pom.xml.merge-right* \ pom.xml svn resolved pom.xml mv m2-assemblies/geronimo-boilerplate-j2ee/src/main/resources/var/security/keystores/geronimo-default.merge-right* \ m2-assemblies/geronimo-boilerplate-j2ee/src/main/resources/var/security/keystores/geronimo-default svn resolved m2-assemblies/geronimo-boilerplate-j2ee/src/main/resources/var/security/keystores/geronimo-default mv m2-assemblies/geronimo-boilerplate-minimal/src/main/resources/var/security/keystores/geronimo-default.merge-right* \ m2-assemblies/geronimo-boilerplate-minimal/src/main/resources/var/security/keystores/geronimo-default svn resolved m2-assemblies/geronimo-boilerplate-minimal/src/main/resources/var/security/keystores/geronimo-default # run the m2 build or run the m1 build ./bootstrap mvn clean install # maven new > Remove TransactionContextManager > > > Key: GERONIMO-2277 > URL: http://issues.apache.org/jira/browse/GERONIMO-2277 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > Fix For: 1.2 > > Attachments: GERONIMO-2277.patch > > > If you use the Geronimo TransactionContextManager, you can't use the > TransactionManager interface directly since the TCM needs to know about all > TM calls. Additionally, to use the TCM you must demarcate all changes in > "component context" by starting an unspecified transaction context. This is > all quite invasive and makes it hard to use our code in third part > environments such as Spring or plain old Tomcat. > I propose we remove the TransactionContextManager and replaced all uses with > a plain old TransactionManager. This will also allow us to removed all code > from web containers, app client and timer that was simply demarcating an > unspecified transaction context, which is no longer needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2277) Remove TransactionContextManager
[ http://issues.apache.org/jira/browse/GERONIMO-2277?page=all ] Dain Sundstrom updated GERONIMO-2277: - Attachment: (was: GERONIMO-2277.patch) > Remove TransactionContextManager > > > Key: GERONIMO-2277 > URL: http://issues.apache.org/jira/browse/GERONIMO-2277 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > Fix For: 1.2 > > > If you use the Geronimo TransactionContextManager, you can't use the > TransactionManager interface directly since the TCM needs to know about all > TM calls. Additionally, to use the TCM you must demarcate all changes in > "component context" by starting an unspecified transaction context. This is > all quite invasive and makes it hard to use our code in third part > environments such as Spring or plain old Tomcat. > I propose we remove the TransactionContextManager and replaced all uses with > a plain old TransactionManager. This will also allow us to removed all code > from web containers, app client and timer that was simply demarcating an > unspecified transaction context, which is no longer needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2277) Remove TransactionContextManager
[ http://issues.apache.org/jira/browse/GERONIMO-2277?page=all ] Dain Sundstrom updated GERONIMO-2277: - Attachment: GERONIMO-2277.patch > Remove TransactionContextManager > > > Key: GERONIMO-2277 > URL: http://issues.apache.org/jira/browse/GERONIMO-2277 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > Fix For: 1.2 > > Attachments: GERONIMO-2277.patch > > > If you use the Geronimo TransactionContextManager, you can't use the > TransactionManager interface directly since the TCM needs to know about all > TM calls. Additionally, to use the TCM you must demarcate all changes in > "component context" by starting an unspecified transaction context. This is > all quite invasive and makes it hard to use our code in third part > environments such as Spring or plain old Tomcat. > I propose we remove the TransactionContextManager and replaced all uses with > a plain old TransactionManager. This will also allow us to removed all code > from web containers, app client and timer that was simply demarcating an > unspecified transaction context, which is no longer needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2277) Remove TransactionContextManager
[ http://issues.apache.org/jira/browse/GERONIMO-2277?page=all ] Dain Sundstrom updated GERONIMO-2277: - Patch Info: [Patch Available] The best way to test this chang is to use svn merge directly instead of using the patch commnd. This is because the svn merge handles adding, removing and relocating files. To merge the changes from the notcm branch execute the following command from within geronimo/trunk svn merge -r 427246:HEAD https://svn.apache.org/repos/asf/geronimo/branches/dain/notcm . You should not receive any conflicts during the merge. Once this is complete, run the following commands to remove the existing openejb checkout and checkout the new related openejb code (this will be merged directly in openejb): rm -rf openejb/ maven m:co Then simply run the maven build with the following command: maven install Altermatively, you can use the attached patch insted of the svn merge command. > Remove TransactionContextManager > > > Key: GERONIMO-2277 > URL: http://issues.apache.org/jira/browse/GERONIMO-2277 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > Fix For: 1.2 > > > If you use the Geronimo TransactionContextManager, you can't use the > TransactionManager interface directly since the TCM needs to know about all > TM calls. Additionally, to use the TCM you must demarcate all changes in > "component context" by starting an unspecified transaction context. This is > all quite invasive and makes it hard to use our code in third part > environments such as Spring or plain old Tomcat. > I propose we remove the TransactionContextManager and replaced all uses with > a plain old TransactionManager. This will also allow us to removed all code > from web containers, app client and timer that was simply demarcating an > unspecified transaction context, which is no longer needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2277) Remove TransactionContextManager
Remove TransactionContextManager Key: GERONIMO-2277 URL: http://issues.apache.org/jira/browse/GERONIMO-2277 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: transaction manager Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Fix For: 1.2 If you use the Geronimo TransactionContextManager, you can't use the TransactionManager interface directly since the TCM needs to know about all TM calls. Additionally, to use the TCM you must demarcate all changes in "component context" by starting an unspecified transaction context. This is all quite invasive and makes it hard to use our code in third part environments such as Spring or plain old Tomcat. I propose we remove the TransactionContextManager and replaced all uses with a plain old TransactionManager. This will also allow us to removed all code from web containers, app client and timer that was simply demarcating an unspecified transaction context, which is no longer needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2224) Add a geronimo specific system property for controlling dom, sax, and transformer creation
[ http://issues.apache.org/jira/browse/GERONIMO-2224?page=all ] Dain Sundstrom updated GERONIMO-2224: - Fix Version/s: 1.1.2 (was: 1.1.x) Affects Version/s: 1.1 Patch has been applied to 1.2 (trunk) and will be applied to 1.1.2 once it is cut. > Add a geronimo specific system property for controlling dom, sax, and > transformer creation > -- > > Key: GERONIMO-2224 > URL: http://issues.apache.org/jira/browse/GERONIMO-2224 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: core >Affects Versions: 1.1 >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > Fix For: 1.2, 1.1.2 > > Attachments: factory.patch > > > It is common for poorly coded application to set the > javax.xml.parsers.DocumentBuilderFactory, javax.xml.parsers.SAXParserFactory, > or javax.xml.transform.TransformerFactory properties directly. If the value > of these system properties do not point to a modern xml parser such as > xerces, critical Geronimo services such as the LocalAttributeManager will > stop working. This due to only modern parsers supporting the setAttribute > method on the factory (specifically crimson throws an exception). > The attached patch redirects all call to > DocumentBuilderFactory.newInstance(), SAXParserFactory.newInstance() and > TransformerFactory.newInstance() to a Geronimo XmlUtil class. This class > checks the property geronimo.xml.parsers.DocumentBuilderFactory, > geronimo.xml.parsers.SAXParserFactory, or > geronimo.xml.transform.TransformerFactor, and if present creates that > factory. Otherwise the code simply delegates to the default newInstance > implementation. > Once this patch has been committed the server can be launched with a full xml > factory declaration using the following command: > java \ > > -Dgeronimo.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl > \ > > -Dgeronimo.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl > \ > > -Dgeronimo.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl > \ > -jar bin/server.jar > * This patch includes a test case for the new functionality. > * This patch includes two new classes which must be svn added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (XBEAN-28) Update xbean poms with current site and mailing list addresses
[ http://issues.apache.org/jira/browse/XBEAN-28?page=all ] Dain Sundstrom closed XBEAN-28. --- Resolution: Duplicate Copy of XBEAN-17 > Update xbean poms with current site and mailing list addresses > -- > > Key: XBEAN-28 > URL: http://issues.apache.org/jira/browse/XBEAN-28 > Project: XBean > Issue Type: Bug >Affects Versions: 2.5 >Reporter: John Sisson > Assigned To: Dain Sundstrom >Priority: Minor > Fix For: 2.6 > > > Update xbean poms with current site and mailing list addresses. They > currently point to xbean.org. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (XBEAN-31) [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build
[ http://issues.apache.org/jira/browse/XBEAN-31?page=comments#action_12425811 ] Dain Sundstrom commented on XBEAN-31: - +1 very cool > [RTC] it would be great if the m2 plugin would automatically add the XSD and > .xsd.html files as artifacts into the build > > > Key: XBEAN-31 > URL: http://issues.apache.org/jira/browse/XBEAN-31 > Project: XBean > Issue Type: Wish > Components: maven-plugin >Reporter: james strachan > Assigned To: Guillaume Nodet > Fix For: 2.6 > > Attachments: XBEAN-31.diff > > > So that the XSD and HTML reference would be automatically deployed into the > m2 repository. > See the attach-artifact for how to do it manually in each POM. But given how > many projects are using the m2 plugin it would simplify our lives if the m2 > plugin did this for us > http://mojo.codehaus.org/build-helper-maven-plugin/howto.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
