Re: New JDBC components for ServiceMix
That would be a great addition ! A JBI component please :-) Lightweight components are kinda deprecated and have lots of problems with classloaders. A standard JBI component should be quite easy to write, although servicemix-common is not much documented. On 7/31/07, Artur Karazniewicz [EMAIL PROTECTED] wrote: Guys, I plan to start implementation of new JDBC components for ServiceMix. I know that for the time being we have simple JDBC component, but to be honest - it's really simple and in my experience we should provide something more sophisticated (I plan to provide support for selects, updates/inserts, stored procedures and database polling). Just want to check if, maybe, someone is working on something like this right now? If yes please let me know, I want to avoid duplicated work, also would like, with pleasure, offer my help working on this. If no, please, could You judge - that would be better to develop LW component, like current JDBC (but more powerful) or would You prefer JBI component? What are Your thoughts. regards Artur -- View this message in context: http://www.nabble.com/New-JDBC-components-for-ServiceMix-tf4193713s12049.html#a11926363 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
Re: relation of camel and servicemix?
so EIP component in servicemix compare with camel? EIP component in servicemix implement without camel. servicemix integrate camel for instead of EIP component? 2007/7/31, James Strachan [EMAIL PROTECTED]: On 7/28/07, cui.hailin [EMAIL PROTECTED] wrote: i recently study camel . i read the message at http://activemq.apache.org/camel/:Apache Camel can be used as a routing and mediation engine for the following projects,include servicemix. relation of NMR and camel? Camel is a mediation routing engine which can be deployed within the NMR. relation of drools and camel? Drools implements RETE which is good for things like business rules with forward/backward chaining etc. Camel implements the Enterprise Integration Patterns and focusses on integration routing rules based on EIP rather than using RETE -- James --- http://macstrac.blogspot.com/
[jira] Resolved: (SM-1008) Resequencer pattern for EIP component
[ https://issues.apache.org/activemq/browse/SM-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-1008. - Resolution: Fixed Fix Version/s: 3.2 Assignee: Guillaume Nodet Thanks a lot, Martin. This is a really nice addition to ServiceMix. Do you think you would be able to add a small paragraph to the documentation on the web site? URL: http://svn.apache.org/viewvc?view=revrev=561660 Resequencer pattern for EIP component - Key: SM-1008 URL: https://issues.apache.org/activemq/browse/SM-1008 Project: ServiceMix Issue Type: New Feature Components: servicemix-eip Affects Versions: 3.2 Environment: Java 1.5 Reporter: Martin Krasser Assignee: Guillaume Nodet Fix For: 3.2 Attachments: patch-servicemix-core.txt, patch-servicemix-eip.txt, resequencer-sample.zip Attached are patches that include a resequencer endpoint for the servicemix-eip component. - patch-servicemix-eip.txt: resequencer classes - patch-servicemix-core.txt: general helper classes The resequencing algorithm is designed to work on streams of objects (e.g. MessageExchanges) based on a timeout policy. It works slightly different than Camel's resequencer as it doesn't make batch-reads of predefined (maximum) size (although a capacity parameter prevents the resequencer from running out of memory). The algorithm details are described in the javadocs of class - org.apache.servicemix.eip.support.resequence.ResequencerEngine This class is independent of JBI/ServiceMix. It can be configured to work on any stream of objects by providing a SequenceElementComparatorE implementation. The class - org.apache.servicemix.eip.patterns.Resequencer is the EIP endpoint that uses the resequencing algorithm. An example shows how to use the resequencer (resequencer-sample.zip), in addition to the unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
AW: [jira] Resolved: (SM-1008) Resequencer pattern for EIP component
Guillaume, Thank you for applying the patch. I'll add a resequencer paragraph to the servicemix-eip documentation within the next days. Cheers, Martin -Ursprüngliche Nachricht- Von: Guillaume Nodet (JIRA) [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. August 2007 07:05 An: servicemix-dev@geronimo.apache.org Betreff: [jira] Resolved: (SM-1008) Resequencer pattern for EIP component [ https://issues.apache.org/activemq/browse/SM- 1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-1008. - Resolution: Fixed Fix Version/s: 3.2 Assignee: Guillaume Nodet Thanks a lot, Martin. This is a really nice addition to ServiceMix. Do you think you would be able to add a small paragraph to the documentation on the web site? URL: http://svn.apache.org/viewvc?view=revrev=561660 Resequencer pattern for EIP component - Key: SM-1008 URL: https://issues.apache.org/activemq/browse/SM-1008 Project: ServiceMix Issue Type: New Feature Components: servicemix-eip Affects Versions: 3.2 Environment: Java 1.5 Reporter: Martin Krasser Assignee: Guillaume Nodet Fix For: 3.2 Attachments: patch-servicemix-core.txt, patch-servicemix- eip.txt, resequencer-sample.zip Attached are patches that include a resequencer endpoint for the servicemix-eip component. - patch-servicemix-eip.txt: resequencer classes - patch-servicemix-core.txt: general helper classes The resequencing algorithm is designed to work on streams of objects (e.g. MessageExchanges) based on a timeout policy. It works slightly different than Camel's resequencer as it doesn't make batch-reads of predefined (maximum) size (although a capacity parameter prevents the resequencer from running out of memory). The algorithm details are described in the javadocs of class - org.apache.servicemix.eip.support.resequence.ResequencerEngine This class is independent of JBI/ServiceMix. It can be configured to work on any stream of objects by providing a SequenceElementComparatorE implementation. The class - org.apache.servicemix.eip.patterns.Resequencer is the EIP endpoint that uses the resequencing algorithm. An example shows how to use the resequencer (resequencer-sample.zip), in addition to the unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-1011) WSDLFlattenner / SchemaCollection do not handle nested schemas inclusions properly
[
https://issues.apache.org/activemq/browse/SM-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39822
]
Guillaume Nodet commented on SM-1011:
-
Why I understand how your changes would avoid the exception, I' d like to
understand how to reproduce the problem.
Could you trim down your schemas to the minimum and attach them please ?
WSDLFlattenner / SchemaCollection do not handle nested schemas inclusions
properly
--
Key: SM-1011
URL: https://issues.apache.org/activemq/browse/SM-1011
Project: ServiceMix
Issue Type: Bug
Components: servicemix-common
Affects Versions: incubation
Environment: Windows XP
Reporter: Konrad Argasinski
Fix For: incubation
Attachments: nested schemas.txt
WSDLFlattener fails to analyse JSR-181 SU WSDL which imports multi-level
(nested) schemas structure.
My JSR-181 SU WSDL imports A1.xsd schema. A1.xsd includes B1.xsd, B2.xsd and
B3.xsd. B1.xsd includes C1.xsd.
The schema is used by JAXB during the project build and it works ok, however
when the SU gets deployed on ServiceMix I receive following error:
loc-messageNOT_FOUND_ERR: An attempt is made to reference a node in a
context where it does not exist./loc-message
stack-trace![CDATA[org.w3c.dom.DOMException: NOT_FOUND_ERR: An attempt is
made to reference a node in a context where it does not exist.
at org.apache.xerces.dom.ParentNode.internalRemoveChild(Unknown Source)
at org.apache.xerces.dom.ParentNode.removeChild(Unknown Source)
at
org.apache.servicemix.common.tools.wsdl.SchemaCollection.handleImports(SchemaCollection.java:150)
The full stack trace is attached.
As workaround I compiled my custom SchemaCollection and it works ok now,
however I think a better fix is needed.
My custom changes in org.apache.servicemix.common.tools.wsdl.SchemaCollection
are:
around line 149 I have replaced:
String location = ce.getAttribute(schemaLocation);
schema.getRoot().removeChild(ce);
with:
String location = ce.getAttribute(schemaLocation);
Node parentNode = ce.getParentNode();
Element root = schema.getRoot();
if (root == parentNode) {
log.debug(Removing child include node: + ce);
schema.getRoot().removeChild(ce);
} else {
log.warn(Skipping child include node removal: + ce);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-537) Define several endpoint implementations instead of having only one
[ https://issues.apache.org/activemq/browse/SM-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SM-537: --- Fix Version/s: 3.2 Define several endpoint implementations instead of having only one -- Key: SM-537 URL: https://issues.apache.org/activemq/browse/SM-537 Project: ServiceMix Issue Type: New Feature Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.2 It would be much more easy to know which kind of endpoint is it and which attributes are mandatory. Having more specialized classes will also be easier to maintain. http:consumer ... http:provider ... jms:consumer .. jms:provider jms:jca-consumer ... jms:jca-provider .. jms:amq-consumer jms:amq-provider .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Upcoming Genesis release
Hrm... how are you using this profile? Its got a few old plugins listed, and a few pinned snapshot artifacts... eh, whatever I don't really care. Maybe you should release it... :-( --jason On Jul 28, 2007, at 7:35 PM, Matt Hogstrom wrote: The staging profile ... yes. On Jul 28, 2007, at 9:52 PM, [EMAIL PROTECTED] wrote: I will spin it. Still wondering if anyone is using the release profile... Can't tell from your response. Are you using it? --jason -Original Message- From: Matt Hogstrom [EMAIL PROTECTED] Date: Sat, 28 Jul 2007 21:38:16 To:dev@geronimo.apache.org Subject: Re: Upcoming Genesis release I agree...the current profiles work. Lots of things to do but let's push this one out. Jason, are you up settin it on fire or prefer someone else do the honors.? If you want I can prolly spin a release up tomorrow sometime. On Jul 28, 2007, at 8:43 AM, Jason Dillon wrote: Just a quick note, we are gonna have to release Genesis 1.2 soonish to support the 2.0 build. While its not perfect (or even close) it does work now and so I'm going to recommend we release it more or less asis. I did a quick sanity check last week, and now I'm asking if anyone knows of any common m2 pom stuff that needs to be changed? Is anyone using that release profile? While its kinda what we eventually what, what is there now doesn't really work IIRC. Anyone using it? --jason
WARNING of schema changes
I fixed some bugs in trunk and expect to port them back to 2.0 shortly as soon as I verify it builds and causes no obvious tck problems. However the change is not backwards compatible so I thought a warning would be a good idea. GERONIMO-2286 GERONIMO-1874 GERONIMO-3140 The backwards incompatible change is to use patternType for external- rar in the app client plan and external-path in the ear plan. The previous strings will now give validation errors. The functionality improvement is that I've hooked up an ArtifactResolver to the code that processes these, so you can provide incomplete patterns and geronimo will try to fill them in. In particular you don't need to specify the version (as long as there's only one) so e.g. the same daytrader plan will work for multiple g versions after this. I think but haven't proved that this also is a big help for GERONIMO-3140 where IIRC I found that client_artifact_aliases wasn't getting used during app client deployment, instead the already started module on the left side of client_artifact_aliases.properties was getting used. Anyway when I check things are still fine I will commit to 2.0 and update the daytrader plan. Right now daytrader will work against 2.0 but not trunk. thanks david jencks
[jira] Closed: (GERONIMO-2286) app client plan still uses Strings for dependency Module IDs
[ https://issues.apache.org/jira/browse/GERONIMO-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2286. -- Resolution: Fixed Fix Version/s: (was: 1.x) 2.0.x Fixed in trunk rev 561259 Fixed in 2.0 rev 561286 Fixed in daytrader (schema mods) rev 561287. Use PatternType element for external rars, and external paths, and cook up an ArtifactResolver so you can leave bits out. This means client_artifact_aliases.properties will be used when available to help with app client deployment. app client plan still uses Strings for dependency Module IDs Key: GERONIMO-2286 URL: https://issues.apache.org/jira/browse/GERONIMO-2286 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: application client, deployment Affects Versions: 1.1 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 2.0, 2.0.x The geronimo-application-client schema has: xs:complexType name=resourceType xs:sequence xs:choice xs:element name=external-rar type=xs:string/ xs:element name=internal-rar type=xs:string/ /xs:choice xs:element ref=connector:connector/ /xs:sequence /xs:complexType That would typically be used like this: resource external-rartranql/tranql-connector/1.2/rar/external-rar connector ... /resource Everywhere else we've changed elements holding module IDs to be of patternType, using separate groupId, artifactId, version, and type elements. There's no reason external-rar should still be a single slash-delimited String here (though internal-rar should be since it's presumably a path within the JAR?). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3140) Artifact aliasing doesn't work for already-started modules
[ https://issues.apache.org/jira/browse/GERONIMO-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516659 ] David Jencks commented on GERONIMO-3140: These changes may help the situation: trunk rev 561259 2.0 rev 561286 daytrader (schema mods) rev 561287. Use PatternType element for external rars, and external paths, and cook up an ArtifactResolver so you can leave bits out. This means client_artifact_aliases.properties will be used when available to help with app client deployment. Artifact aliasing doesn't work for already-started modules -- Key: GERONIMO-3140 URL: https://issues.apache.org/jira/browse/GERONIMO-3140 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M5 Reporter: David Jencks Assignee: David Jencks Fix For: Wish List We normally alias server modules on the client so that a reference to e.g. the transaction-jta11 module gets turned into a reference to client-transaction. However if the module with this reference is already started on the server while deployment is happening, there's no opportunity to do this aliasing during deployment. E.g. the openjpa module depends on the tm module and is normally started: so any app client using opnejpa will appear at deploy time to have 2 tms, one from tx-jta11 through the openjpa dependency and one from client-transaction. One hacky workaround is to ignore duplicate gbean matches during deployment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1874) synthetic ears should allow use of modules outside the g repository
[ https://issues.apache.org/jira/browse/GERONIMO-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-1874. -- Resolution: Fixed Fix Version/s: (was: Wish List) 2.1 2.0 Fixed in trunk rev 561259 Fixed in 2.0 rev 561286 Fixed in daytrader (schema mods) rev 561287. Use PatternType element for external rars, and external paths, and cook up an ArtifactResolver so you can leave bits out. This means client_artifact_aliases.properties will be used when available to help with app client deployment. As noted in previous comment, I don't think allowing pointers to arbitrary stuff is very useful, use an exploded ear instead. synthetic ears should allow use of modules outside the g repository --- Key: GERONIMO-1874 URL: https://issues.apache.org/jira/browse/GERONIMO-1874 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0, 2.1 Currently synthetic ears or external modules in an ear only accept external artifacts that are in the geronimo repo, identified by an Artifact. We should also allow specification of a path that is not in the repository. Perhaps this could be resolved using ServerInfo if the path is not absolute. I think that changing the meaning of the current external-path to actually mean a path and introducing a new element such as artifact perhaps with all the parts to indicate an artifact in the repo would be a good idea. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: WARNING of schema changes
I've merged this with 2.0 and updated daytrader plans. Let me know if there are any problems. thanks david jencks On Jul 31, 2007, at 1:30 AM, David Jencks wrote: I fixed some bugs in trunk and expect to port them back to 2.0 shortly as soon as I verify it builds and causes no obvious tck problems. However the change is not backwards compatible so I thought a warning would be a good idea. GERONIMO-2286 GERONIMO-1874 GERONIMO-3140 The backwards incompatible change is to use patternType for external-rar in the app client plan and external-path in the ear plan. The previous strings will now give validation errors. The functionality improvement is that I've hooked up an ArtifactResolver to the code that processes these, so you can provide incomplete patterns and geronimo will try to fill them in. In particular you don't need to specify the version (as long as there's only one) so e.g. the same daytrader plan will work for multiple g versions after this. I think but haven't proved that this also is a big help for GERONIMO-3140 where IIRC I found that client_artifact_aliases wasn't getting used during app client deployment, instead the already started module on the left side of client_artifact_aliases.properties was getting used. Anyway when I check things are still fine I will commit to 2.0 and update the daytrader plan. Right now daytrader will work against 2.0 but not trunk. thanks david jencks
Re: What to do with legacy EJB 2.1 code in DayTrader?
On Jul 30, 2007, at 10:47 AM, Christopher Blythe wrote: I like having the 2.1 code around as well for the same reasons you stated. I just don't like the idea of having the two implementations inter-mingled in the same ear/jar. It makes DayTrader's usefulness as a code sample for developers a lot harder to swallow. I also have a hard time believing that there are going to be a lot of production applications out there that use both EJB 2.1 and 3.0 components in the same package. So, my original thinking was to, use DT 1.2 as the J2EE 1.4 based sample and DT 2.0 as the EE 5 based sample. Another option I just thought of is to refactor the packaging such that two ejb jar files can be created, one for the EJB 2.1 legacy code and another for the new EJB 3.0 components. The pom files could then be modified to create two ear files. Thoughts? From a usage perspective, it's great to have a single ear with multiple, selectable modes. If that's impractical, I'm ok with multiple ears. --kevan
[jira] Assigned: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
[
https://issues.apache.org/jira/browse/GERONIMO-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller reassigned GERONIMO-3348:
--
Assignee: Kevan Miller
java.lang.NoSuchMethodError in
org.springframework.context.i18n.LocaleContextHolder
---
Key: GERONIMO-3348
URL: https://issues.apache.org/jira/browse/GERONIMO-3348
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.0-M6
Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686
Pentium III (Katmai) GenuineIntel GNU/Linux
JDK-1.5.0.12
Reporter: Aleksandr Tarutin
Assignee: Kevan Miller
When deploying and running [Proximity|http://proximity.abstracthorizon.org/]
it works without any problem in geronimo-1.1.1. But when the same application
is deployed to 2.0-M6 following exception is thrown:
{noformat}
15:57:53,267 INFO [DirectoryHotDeployer] Deploying proximity
15:57:56,690 WARN [JettyModuleBuilder] Web application . does not contain a
WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem,
depending on whether you have things like resource references that need to be
resolved. You can also give the deployer a separate deployment plan file on
the command line.
15:58:04,709 WARN [JspModuleBuilderExtension] Invalid transformed taglib
org.apache.xmlbeans.XmlException: Invalid deployment descriptor: errors:
jar:file:/opt/geronimo-jetty6-jee5-2.0-M6/repository/default/proximity/1185307073730/proximity-1185307073730.war/WEB-INF/lib/bsf-2.3.0.jar!/META-INF/taglib.tld:15:3:
error: cvc-datatype-valid.1.1: string value 'BSF JSP Support' does not match
pattern for tld-canonical-nameType in namespace
http://java.sun.com/xml/ns/javaee
Descriptor:
!--a tab library descriptor--
taglib xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; version=2.1
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
!--after this the default space is
http://java.sun.com/j2ee/dtds/jsptaglibrary_1_2.dtd--
tlib-version2.0/tlib-version
short-nameBSF JSP Support/short-name
urihttp://jakarta.apache.org/taglibs//uri
tag
namescriptlet/name
tag-classorg.apache.taglibs.bsf.scriptlet/tag-class
body-contenttagdependent/body-content
attribute
namelanguage/name
requiredtrue/required
/attribute
/tag
tag
nameexpression/name
tag-classorg.apache.taglibs.bsf.expression/tag-class
body-contenttagdependent/body-content
attribute
namelanguage/name
requiredtrue/required
/attribute
/tag
/taglib
at
org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.validateDD(XmlBeansUtil.java:218)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.convertToTaglibSchema(JspModuleBuilderExtension.java:675)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.parseTldFile(JspModuleBuilderExtension.java:433)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.getListenerClasses(JspModuleBuilderExtension.java:420)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.createJspClassFinder(JspModuleBuilderExtension.java:180)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.addGBeans(JspModuleBuilderExtension.java:149)
at
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension$$FastClassByCGLIB$$1f60ab3b.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:828)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.j2ee.deployment.ModuleBuilderExtension$$EnhancerByCGLIB$$6720f345.addGBeans(generated)
at
org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:484)
at
org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
On Jul 25, 2007, at 2:23 PM, Aleksandr Tarutin (JIRA) wrote: java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder -- - Key: GERONIMO-3348 URL: https://issues.apache.org/jira/browse/ GERONIMO-3348 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M6 Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686 Pentium III (Katmai) GenuineIntel GNU/Linux JDK-1.5.0.12 Reporter: Aleksandr Tarutin This problem is caused by incompatibilities between the spring jars included within the cxf module and the spring jars included within the application. I think this is going to be a pretty common failure scenario. Rather than require a lot of Spring users to create a geronimo deployment plan, I'd like to add the necessary hidden- classes to the jetty6-deployer defaultEnvironment, namely: --- jetty6-deployer/src/plan/plan.xml (revision 560807) +++ jetty6-deployer/src/plan/plan.xml (working copy) @@ -130,7 +130,10 @@ typecar/type /dependency /dependencies -hidden-classes/ +hidden-classes +filterorg.springframework./filter +filterorg.apache.cxf./filter +/hidden-classes non-overridable-classes filterjava./filter filterjavax./filter I'm running some TCK tests, now. Assuming things look good, I'd like to commit to 2.0. Any objections? We could do nothing and require users to create a geronimo deployment plan which hides these same classes, instead. However, I'd like to make this scenario work out-of- the-box... Jarek has mentioned that with a bit of work, our cxf module need not be dependent on Spring configuration. This seems like a good idea. I'd certainly like to see the dependency dropped. However, don't see that happening in time for 2.0. --kevan
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
+1 -Donald Kevan Miller wrote: On Jul 25, 2007, at 2:23 PM, Aleksandr Tarutin (JIRA) wrote: java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder --- Key: GERONIMO-3348 URL: https://issues.apache.org/jira/browse/GERONIMO-3348 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M6 Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686 Pentium III (Katmai) GenuineIntel GNU/Linux JDK-1.5.0.12 Reporter: Aleksandr Tarutin This problem is caused by incompatibilities between the spring jars included within the cxf module and the spring jars included within the application. I think this is going to be a pretty common failure scenario. Rather than require a lot of Spring users to create a geronimo deployment plan, I'd like to add the necessary hidden-classes to the jetty6-deployer defaultEnvironment, namely: --- jetty6-deployer/src/plan/plan.xml(revision 560807) +++ jetty6-deployer/src/plan/plan.xml(working copy) @@ -130,7 +130,10 @@ typecar/type /dependency /dependencies -hidden-classes/ +hidden-classes +filterorg.springframework./filter +filterorg.apache.cxf./filter +/hidden-classes non-overridable-classes filterjava./filter filterjavax./filter I'm running some TCK tests, now. Assuming things look good, I'd like to commit to 2.0. Any objections? We could do nothing and require users to create a geronimo deployment plan which hides these same classes, instead. However, I'd like to make this scenario work out-of-the-box... Jarek has mentioned that with a bit of work, our cxf module need not be dependent on Spring configuration. This seems like a good idea. I'd certainly like to see the dependency dropped. However, don't see that happening in time for 2.0. --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
On Jul 31, 2007, at 8:44 AM, Kevan Miller wrote: I'm running some TCK tests, now. Assuming things look good, I'd like to commit to 2.0. Any objections? We could do nothing and require users to create a geronimo deployment plan which hides these same classes, instead. However, I'd like to make this scenario work out-of-the-box... +1 I agree this would be good for 2.0. Pluto 1.2 uses spring to configure itself so I experienced some of these problems first hand while setting up the new dynamic console framework. Like you say, in most cases users can probably work around it with hidden-class filters or arranging their modules in a certain way. But that's not entirely straight forward and can limit their options with respect to how their application can be deployed. Spring applications should work out of the box. Best wishes, Paul
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
+1 (assuming it doesn't affect TCK) ;-) Joe Kevan Miller wrote: On Jul 25, 2007, at 2:23 PM, Aleksandr Tarutin (JIRA) wrote: java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder --- Key: GERONIMO-3348 URL: https://issues.apache.org/jira/browse/GERONIMO-3348 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M6 Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686 Pentium III (Katmai) GenuineIntel GNU/Linux JDK-1.5.0.12 Reporter: Aleksandr Tarutin This problem is caused by incompatibilities between the spring jars included within the cxf module and the spring jars included within the application. I think this is going to be a pretty common failure scenario. Rather than require a lot of Spring users to create a geronimo deployment plan, I'd like to add the necessary hidden-classes to the jetty6-deployer defaultEnvironment, namely: --- jetty6-deployer/src/plan/plan.xml(revision 560807) +++ jetty6-deployer/src/plan/plan.xml(working copy) @@ -130,7 +130,10 @@ typecar/type /dependency /dependencies -hidden-classes/ +hidden-classes +filterorg.springframework./filter +filterorg.apache.cxf./filter +/hidden-classes non-overridable-classes filterjava./filter filterjavax./filter I'm running some TCK tests, now. Assuming things look good, I'd like to commit to 2.0. Any objections? We could do nothing and require users to create a geronimo deployment plan which hides these same classes, instead. However, I'd like to make this scenario work out-of-the-box... Jarek has mentioned that with a bit of work, our cxf module need not be dependent on Spring configuration. This seems like a good idea. I'd certainly like to see the dependency dropped. However, don't see that happening in time for 2.0. --kevan
[jira] Closed: (GERONIMO-3270) Avoid CMP foreign key violations
[ https://issues.apache.org/jira/browse/GERONIMO-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-3270. -- Resolution: Fixed Fix Version/s: (was: 2.0.x) 2.0 Avoid CMP foreign key violations - Key: GERONIMO-3270 URL: https://issues.apache.org/jira/browse/GERONIMO-3270 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Kevan Miller Fix For: 2.0 A recent OpenJPA change (see https://issues.apache.org/jira/browse/OPENJPA-235) can cause foreign key violations in CMP. May be that we (CMP) need to provide OpenJPA information about foreign keys. We can, however, avoid the problem by specifying OpenJPA to maintain operation-order. This is what I intend to do, in the short-term... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3364) Finalize License/Notice files for 2.0 release
Finalize License/Notice files for 2.0 release - Key: GERONIMO-3364 URL: https://issues.apache.org/jira/browse/GERONIMO-3364 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: Kevan Miller Update the global LICENSE and NOTICE files to match our current dependencies, plus additional cleanup (proper copyright dates, etc). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3364) Finalize License/Notice files for 2.0 release
[ https://issues.apache.org/jira/browse/GERONIMO-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-3364: --- Fix Version/s: 2.0 Finalize License/Notice files for 2.0 release - Key: GERONIMO-3364 URL: https://issues.apache.org/jira/browse/GERONIMO-3364 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Affects Versions: 2.0 Reporter: Kevan Miller Fix For: 2.0 Update the global LICENSE and NOTICE files to match our current dependencies, plus additional cleanup (proper copyright dates, etc). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
config.xml
We used to include a config.xml.original in the var/config directory. This made it possible to back up to the default configuration, if config.xml became corrupted. It would be good to get this back in... --kevan
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
I'm +1 on the testing this out. I seem to remember that a while ago I've had some problems with CXF when the hidden-classes/ was actually enabled for Spring classes in the Jetty config but maybe it will work better now. See: http://www.mail-archive.com/dev@geronimo.apache.org/msg41202.html. Please also run the testsuite/webservices-testsuite/jaxws-tests/jaxws-*/ tests to verify that everything works ok after the change. But I have a few comments on this change in general. First, why are we adding the hidden-classes/ bits for Spring and CXF only? Aren't we in the same boat with other libraries, e.g. Axis2, Commons Logging, etc.? Also, I think the hidden-classes/ change should go into both Tomcat and Jetty configs (since for example the Tomcat assembly could be switched to run CXF). Jarek On 7/31/07, Kevan Miller [EMAIL PROTECTED] wrote: On Jul 25, 2007, at 2:23 PM, Aleksandr Tarutin (JIRA) wrote: java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder -- - Key: GERONIMO-3348 URL: https://issues.apache.org/jira/browse/ GERONIMO-3348 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M6 Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686 Pentium III (Katmai) GenuineIntel GNU/Linux JDK-1.5.0.12 Reporter: Aleksandr Tarutin This problem is caused by incompatibilities between the spring jars included within the cxf module and the spring jars included within the application. I think this is going to be a pretty common failure scenario. Rather than require a lot of Spring users to create a geronimo deployment plan, I'd like to add the necessary hidden- classes to the jetty6-deployer defaultEnvironment, namely: --- jetty6-deployer/src/plan/plan.xml (revision 560807) +++ jetty6-deployer/src/plan/plan.xml (working copy) @@ -130,7 +130,10 @@ typecar/type /dependency /dependencies -hidden-classes/ +hidden-classes +filterorg.springframework./filter +filterorg.apache.cxf./filter +/hidden-classes non-overridable-classes filterjava./filter filterjavax./filter I'm running some TCK tests, now. Assuming things look good, I'd like to commit to 2.0. Any objections? We could do nothing and require users to create a geronimo deployment plan which hides these same classes, instead. However, I'd like to make this scenario work out-of- the-box... Jarek has mentioned that with a bit of work, our cxf module need not be dependent on Spring configuration. This seems like a good idea. I'd certainly like to see the dependency dropped. However, don't see that happening in time for 2.0. --kevan
testsuite
Prasad, Are we actually running the testsuite now? If not, can we at least start running the webservices-testsuite as it does not require the selenium stuff? Thanks, Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: Yes Jarek. That's one of my TODOs. Thanks to Jason Dillon, we now have a selenium:xvfb goal that will allow us to run this testsuite headless. However, it is not working exactly as desired. Jason is helping us fix it. As soon as it is ready, I'll plug in the testsuite too for daily builds. Cheers Prasad On 6/22/07, Jarek Gawor [EMAIL PROTECTED] wrote: Also, I think we should start running the entire testsuite. We have quite a bit of tests there that should tell us if some basic functionality is broken. Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: I was wondering if we should also publish the artifacts automatically after a successful build. Looking at the apache-snapshots repo, the last published snapshots are more than 2 weeks old. So is it a good idea to publish snaps also after a successful build ? If so, what is a good frequency ? Nightly ? Cheers Prasad On 22 Jun 2007 14:41:15 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OpenEJB trunk at 549821 Geronimo Revision: 549821 built with tests skipped See the full build-1000.log file at http://people.apache.org/~prasad/binaries/20070622/build-1000.log Download the binaries from http://people.apache.org/~prasad/binaries/20070622 [INFO] Reactor Summary: [INFO] [INFO] Geronimo .. SUCCESS [8.947s] [INFO] Geronimo Local Repository . SUCCESS [12.839s] [INFO] Geronimo Build Support SUCCESS [0.023s] [INFO] Geronimo Build Support, Groovy Library SUCCESS [9.188s] [INFO] Geronimo Test Support . SUCCESS [0.041s] [INFO] Geronimo Test Support :: Common ... SUCCESS [6.046s] [INFO] Geronimo Test Support :: Selenium . SUCCESS [5.195s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EJB SUCCESS [1.444s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: WAR SUCCESS [3.967s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: RAR SUCCESS [1.941s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EAR SUCCESS [0.307s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EJB SUCCESS [0.659s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: WAR SUCCESS [0.240s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: RAR SUCCESS [0.101s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EAR SUCCESS [0.107s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 ... SUCCESS [0.030s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EJB SUCCESS [0.739s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: WAR SUCCESS [0.279s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: RAR SUCCESS [0.118s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EAR SUCCESS [0.100s] [INFO] Geronimo :: Modules ... SUCCESS [0.033s] [INFO] Geronimo :: Activation SUCCESS [4.314s] [INFO] Geronimo :: ActiveMQ Resource Adapter . SUCCESS [0.603s] [INFO] Geronimo :: Kernel SUCCESS [8.881s] [INFO] Geronimo :: Common SUCCESS [1.314s] [INFO] Geronimo :: Util .. SUCCESS [4.986s] [INFO] Geronimo :: CLI ... SUCCESS [6.771s] [INFO] Geronimo :: System SUCCESS [7.076s] [INFO] Geronimo :: Management API SUCCESS [3.827s] [INFO] Geronimo :: ActiveMQ Management Interfaces SUCCESS [0.608s] [INFO] Geronimo :: Interceptor ... SUCCESS [0.507s] [INFO] Geronimo :: J2EE .. SUCCESS [2.502s] [INFO] Geronimo :: Core .. SUCCESS [0.956s] [INFO] Geronimo :: Security .. SUCCESS [10.488s] [INFO] Geronimo :: Deployment SUCCESS [3.010s] [INFO] Geronimo :: Transaction
Update README file
I think our README.txt file could stand a bit of updating... Things like: Apache Geronimo milestone build M4 (August 10, 2005) I'd also like to see usage instructions for shell scripts (e.g. geronimo.sh/geronimo.bat, etc) rather than/or in addition to explicit java commands... If someone wants to take a crack at this, that would be great. Otherwise, I'll work on it after I finish license/notice stuff. --kevan
Re: config.xml
It would be nice to be able to embed comments in the config.xml. On Jul 31, 2007, at 10:46 AM, Kevan Miller wrote: We used to include a config.xml.original in the var/config directory. This made it possible to back up to the default configuration, if config.xml became corrupted. It would be good to get this back in... --kevan
Re: KEYS ?
Good point. I think we have the KEYs file in a couple of places. on people there is: /www/people.apache.org/ ./repo/m1-ibiblio-rsync-repository/geronimo/KEYS ./repo/m2-ibiblio-rsync-repository/org/apache/geronimo/KEYS ./repo/m1-ibiblio-rsync-repository/org.apache.xbean/KEYS ./repo/m2-ibiblio-rsync-repository/org/apache/xbean/KEYS ./repo/m2-ibiblio-rsync-repository.backup/org/apache/geronimo/ genesis/KEYS ./repo/m2-ibiblio-rsync-repository.backup/org/apache/geronimo/KEYS ./repo/m2-ibiblio-rsync-repository.backup/org/apache/xbean/KEYS on /www/www.apache.org/dist/ .geronimo/KEYS We also have a web link from http://www.apache.org/dist/geronimo/KEYS Not sure if there are other references (and yes, I know these are outside svn :) On Jul 30, 2007, at 12:35 PM, Dain Sundstrom wrote: I'm not sure, but it may be mentioned in old binaries as the location for verifying the signatures. I could be completely wrong... I just have a memory of some external references. If you do move the file, I'd definitely search the website for references. -dain On Jul 27, 2007, at 12:35 PM, Jason Dillon wrote: What external references are you referring to? I believe that it does have symlink support, though I hardly ever use it. --jason On Jul 27, 2007, at 12:29 PM, Dain Sundstrom wrote: I think there are external references to this file, but I'm not sure how we should deal with them. Does svn have symlink support? -dain On Jul 26, 2007, at 3:52 PM, Jason Dillon wrote: Should keys move up to a peer to the STATUS file too? Seems these are project global, not specific to the server bits... --jason
Re: config.xml
Matt, Comments can now be embedded in config.xml. I think I also saw this in the m-5 release notes. http://issues.apache.org/jira/browse/GERONIMO-1265 Don On 7/31/07, Matt Hogstrom [EMAIL PROTECTED] wrote: It would be nice to be able to embed comments in the config.xml. On Jul 31, 2007, at 10:46 AM, Kevan Miller wrote: We used to include a config.xml.original in the var/config directory. This made it possible to back up to the default configuration, if config.xml became corrupted. It would be good to get this back in... --kevan
New JDBC components for ServiceMix
Guys, I plan to start implementation of new JDBC components for ServiceMix. I know that for the time being we have simple JDBC component, but to be honest - it's really simple and in my experience we should provide something more sophisticated (I plan to provide support for selects, updates/inserts, stored procedures and database polling). Just want to check if, maybe, someone is working on something like this right now? If yes please let me know, I want to avoid duplicated work, also would like, with pleasure, offer my help working on this. If no, please, could You judge - that would be better to develop LW component, like current JDBC (but more powerful) or would You prefer JBI component? What are Your thoughts. regards Artur -- View this message in context: http://www.nabble.com/New-JDBC-components-for-ServiceMix-tf4193713s12049.html#a11926363 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
On Jul 31, 2007, at 10:47 AM, Jarek Gawor wrote: I'm +1 on the testing this out. I seem to remember that a while ago I've had some problems with CXF when the hidden-classes/ was actually enabled for Spring classes in the Jetty config but maybe it will work better now. See: http://www.mail-archive.com/dev@geronimo.apache.org/msg41202.html. Please also run the testsuite/webservices-testsuite/jaxws-tests/jaxws-*/ tests to verify that everything works ok after the change. But I have a few comments on this change in general. First, why are we adding the hidden-classes/ bits for Spring and CXF only? Aren't we in the same boat with other libraries, e.g. Axis2, Commons Logging, etc.? Also, I think the hidden-classes/ change should go into both Tomcat and Jetty configs (since for example the Tomcat assembly could be switched to run CXF). Yes, there is always an exposure for problems with parent libraries. As you might expect, what libraries are exposed to client applications has been discussed, before... You could make a case that we should offer a simple configuration mode where we offer only strict EE interfaces to client applications, default would remain our current behavior. I don't see this happening for 2.0. As to why treat Spring differently: 1. Spring is especially prone to version incompatibilities. We only include spring core, context, and beans jars in the cxf module. Since most apps will have additional Spring jar files, we are exposed to problems caused by method signature incompatibilities. 2. Spring problems are what have shown up on our user list/jiras. Yes. I had the same filters in the tomcat deployer... --kevan
Re: config.xml
Out of curiosity, what was the reason for removing config.xml.original? Jason Warner On 7/31/07, Don Hill [EMAIL PROTECTED] wrote: Matt, Comments can now be embedded in config.xml. I think I also saw this in the m-5 release notes. http://issues.apache.org/jira/browse/GERONIMO-1265 Don On 7/31/07, Matt Hogstrom [EMAIL PROTECTED] wrote: It would be nice to be able to embed comments in the config.xml. On Jul 31, 2007, at 10:46 AM, Kevan Miller wrote: We used to include a config.xml.original in the var/config directory. This made it possible to back up to the default configuration, if config.xml became corrupted. It would be good to get this back in... --kevan
Re: testsuite
Sure. Let me hook up just this one testsuite. The selenium:xvfb goal is working with some workarounds. However, the corba-testsuite is breaking the entire testrun. (https://issues.apache.org/jira/browse/GERONIMO-3360). But I guess I can run just the webservices-testsuite for now or remove corba-testsuite from the mix. Cheers Prasad On 7/31/07, Jarek Gawor [EMAIL PROTECTED] wrote: Prasad, Are we actually running the testsuite now? If not, can we at least start running the webservices-testsuite as it does not require the selenium stuff? Thanks, Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: Yes Jarek. That's one of my TODOs. Thanks to Jason Dillon, we now have a selenium:xvfb goal that will allow us to run this testsuite headless. However, it is not working exactly as desired. Jason is helping us fix it. As soon as it is ready, I'll plug in the testsuite too for daily builds. Cheers Prasad On 6/22/07, Jarek Gawor [EMAIL PROTECTED] wrote: Also, I think we should start running the entire testsuite. We have quite a bit of tests there that should tell us if some basic functionality is broken. Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: I was wondering if we should also publish the artifacts automatically after a successful build. Looking at the apache-snapshots repo, the last published snapshots are more than 2 weeks old. So is it a good idea to publish snaps also after a successful build ? If so, what is a good frequency ? Nightly ? Cheers Prasad On 22 Jun 2007 14:41:15 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OpenEJB trunk at 549821 Geronimo Revision: 549821 built with tests skipped See the full build-1000.log file at http://people.apache.org/~prasad/binaries/20070622/build-1000.log Download the binaries from http://people.apache.org/~prasad/binaries/20070622 [INFO] Reactor Summary: [INFO] [INFO] Geronimo .. SUCCESS [8.947s] [INFO] Geronimo Local Repository . SUCCESS [12.839s] [INFO] Geronimo Build Support SUCCESS [0.023s] [INFO] Geronimo Build Support, Groovy Library SUCCESS [9.188s] [INFO] Geronimo Test Support . SUCCESS [0.041s] [INFO] Geronimo Test Support :: Common ... SUCCESS [6.046s] [INFO] Geronimo Test Support :: Selenium . SUCCESS [5.195s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EJB SUCCESS [1.444s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: WAR SUCCESS [3.967s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: RAR SUCCESS [1.941s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EAR SUCCESS [0.307s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EJB SUCCESS [0.659s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: WAR SUCCESS [0.240s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: RAR SUCCESS [0.101s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EAR SUCCESS [0.107s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 ... SUCCESS [0.030s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EJB SUCCESS [0.739s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: WAR SUCCESS [0.279s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: RAR SUCCESS [0.118s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EAR SUCCESS [0.100s] [INFO] Geronimo :: Modules ... SUCCESS [0.033s] [INFO] Geronimo :: Activation SUCCESS [4.314s] [INFO] Geronimo :: ActiveMQ Resource Adapter . SUCCESS [0.603s] [INFO] Geronimo :: Kernel SUCCESS [8.881s] [INFO] Geronimo :: Common SUCCESS [1.314s] [INFO] Geronimo :: Util .. SUCCESS [4.986s] [INFO] Geronimo :: CLI ... SUCCESS [6.771s] [INFO] Geronimo :: System SUCCESS [7.076s] [INFO] Geronimo :: Management API SUCCESS [3.827s] [INFO] Geronimo :: ActiveMQ Management Interfaces SUCCESS
Re: config.xml
The work to allow comments to be embedded in the config.xml were not yet completed because they will require a change to the schema. I will get back to working on this. Jay Don Hill wrote: Matt, Comments can now be embedded in config.xml. I think I also saw this in the m-5 release notes. http://issues.apache.org/jira/browse/GERONIMO-1265 http://issues.apache.org/jira/browse/GERONIMO-1265 Don On 7/31/07, *Matt Hogstrom* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It would be nice to be able to embed comments in the config.xml. On Jul 31, 2007, at 10:46 AM, Kevan Miller wrote: We used to include a config.xml.original in the var/config directory. This made it possible to back up to the default configuration, if config.xml became corrupted. It would be good to get this back in... --kevan
Re: [VOTE] Release specs for JACC, JSP, Servlet
I have not ever reviewed/voted on specs and I wanted to know what should be checked before voting. Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 The corresponding tar files are here: http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz The current svn locations are here: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-servlet_2.5_spec-1.1 The future svn locations will be here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1 The vote will conclude at 10:00 PM EST on Thursday, August 2nd.
RE: [jira] Commented: (SM-1001) FtpReceiverEndpoint (InternalEndpoint)
Guillaumme, Thanks for reviewing the patch. I thought of having the flexibility of specifying opeations and their parameters either while configuring the endpoint (xbean.xml) or as part of the message. As the endpoint is required to be thread-safe I now feel that we can not have both the options. What are your thoughts on this.. May be I do not understand the internals completely... I considered the follwing usecases. 1. Send InOnly exchanges to a target endpoint. 2. Answer to an InOut exchange (operations like file/directory listing, get file content etc) Again, when you talk about a real WSDL, if I understand correctly you mean to create static wsdl for all the operations possible. How do you envisage to differentiate the different MEPs for the same operations (sending the file content to a target vs returing to the consumer), do you expect to have different operations for them in the WSDL?? Can you please elaborate your thoughts on this? Regards, Rabi Mishra, Wipro Technologies,Office: +91-20-39104549, VOIP:842 2545,CELL+91(0)9890363765 http://rabisblog.blogspot.com/ c++; /* this makes c bigger but returns the old value */ -Original Message- From: Guillaume Nodet (JIRA) [mailto:[EMAIL PROTECTED] Sent: Monday, July 30, 2007 8:12 PM To: [EMAIL PROTECTED] Subject: [jira] Commented: (SM-1001) FtpReceiverEndpoint (InternalEndpoint) [ https://issues.apache.org/activemq/browse/SM-1001?page=com.atlassian.jir a.plugin.system.issuetabpanels:comment-tabpanel#action_39796 ] Guillaume Nodet commented on SM-1001: - I think there is one big problem: the message contains some informations used to configure the endpoint when the message is received. This means that the endpoint is not thread safe. Endpoints have to be, as they are given exchanges concurrently. Another thing is that I' d really like to have a real WSDL to describe the interface for this endpoint, the operations and their parameters. FtpReceiverEndpoint (InternalEndpoint) --- Key: SM-1001 URL: https://issues.apache.org/activemq/browse/SM-1001 Project: ServiceMix Issue Type: Improvement Reporter: Rabi Attachments: patch.txt FtpReceiverEndpoint (InternalEndpoint) - Can accpet in-out mep for listing files - Supports InOnly mep for get/mget operations... Usage: xbean configuration: -- beans xmlns:ftp=http://servicemix.apache.org/ftp/1.0; xmlns:b=http://servicemix.apache.org/samples/ftp-receiver; ftp:receiver service=b:ftpReceiver endpoint=endpoint uri=ftp://rabi:[EMAIL PROTECTED] ftp:target ftp:exchange-target service=b:pipeline/ /ftp:target /ftp:receiver Input Message structure - ?xml version=1.0 encoding=UTF-8? ftp:input xmlns:ftp=http://servicemix.apache.org/ftp/1.0; operation=mget recursive=true filter=* relativeUri=/inbox /ftp:input Output for file listing STATUS: 200 ?xml version='1.0' encoding='UTF-8'? ftp:list xmlns:ftp=http://servicemix.apache.org/ftp/1.0; ftp:directory name=/http/inbox/data/inner ftp:file/http/inbox/data/inner/tx.xml/ftp:file /ftp:directory ftp:file/http/inbox/data/servicemix.xml/ftp:file /ftp:list This is a very simple version. Please suggest on the improvements.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
Re: testsuite
Hi Prasad, I'm looking into that now. Will let you know when it is fixed Prasad Kashyap wrote: Sure. Let me hook up just this one testsuite. The selenium:xvfb goal is working with some workarounds. However, the corba-testsuite is breaking the entire testrun. (https://issues.apache.org/jira/browse/GERONIMO-3360). But I guess I can run just the webservices-testsuite for now or remove corba-testsuite from the mix. Cheers Prasad On 7/31/07, Jarek Gawor [EMAIL PROTECTED] wrote: Prasad, Are we actually running the testsuite now? If not, can we at least start running the webservices-testsuite as it does not require the selenium stuff? Thanks, Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: Yes Jarek. That's one of my TODOs. Thanks to Jason Dillon, we now have a selenium:xvfb goal that will allow us to run this testsuite headless. However, it is not working exactly as desired. Jason is helping us fix it. As soon as it is ready, I'll plug in the testsuite too for daily builds. Cheers Prasad On 6/22/07, Jarek Gawor [EMAIL PROTECTED] wrote: Also, I think we should start running the entire testsuite. We have quite a bit of tests there that should tell us if some basic functionality is broken. Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: I was wondering if we should also publish the artifacts automatically after a successful build. Looking at the apache-snapshots repo, the last published snapshots are more than 2 weeks old. So is it a good idea to publish snaps also after a successful build ? If so, what is a good frequency ? Nightly ? Cheers Prasad On 22 Jun 2007 14:41:15 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OpenEJB trunk at 549821 Geronimo Revision: 549821 built with tests skipped See the full build-1000.log file at http://people.apache.org/~prasad/binaries/20070622/build-1000.log Download the binaries from http://people.apache.org/~prasad/binaries/20070622 [INFO] Reactor Summary: [INFO] [INFO] Geronimo .. SUCCESS [8.947s] [INFO] Geronimo Local Repository . SUCCESS [12.839s] [INFO] Geronimo Build Support SUCCESS [0.023s] [INFO] Geronimo Build Support, Groovy Library SUCCESS [9.188s] [INFO] Geronimo Test Support . SUCCESS [0.041s] [INFO] Geronimo Test Support :: Common ... SUCCESS [6.046s] [INFO] Geronimo Test Support :: Selenium . SUCCESS [5.195s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EJB SUCCESS [1.444s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: WAR SUCCESS [3.967s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: RAR SUCCESS [1.941s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EAR SUCCESS [0.307s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EJB SUCCESS [0.659s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: WAR SUCCESS [0.240s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: RAR SUCCESS [0.101s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EAR SUCCESS [0.107s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 ... SUCCESS [0.030s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EJB SUCCESS [0.739s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: WAR SUCCESS [0.279s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: RAR SUCCESS [0.118s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EAR SUCCESS [0.100s] [INFO] Geronimo :: Modules ... SUCCESS [0.033s] [INFO] Geronimo :: Activation SUCCESS [4.314s] [INFO] Geronimo :: ActiveMQ Resource Adapter . SUCCESS [0.603s] [INFO] Geronimo :: Kernel SUCCESS [8.881s] [INFO] Geronimo :: Common SUCCESS [1.314s] [INFO] Geronimo :: Util .. SUCCESS [4.986s] [INFO] Geronimo :: CLI ... SUCCESS [6.771s] [INFO] Geronimo :: System SUCCESS [7.076s] [INFO] Geronimo :: Management API SUCCESS [3.827s] [INFO] Geronimo :: ActiveMQ Management Interfaces SUCCESS [0.608s] [INFO] Geronimo :: Interceptor ... SUCCESS [0.507s] [INFO] Geronimo :: J2EE .. SUCCESS [2.502s] [INFO] Geronimo :: Core .. SUCCESS [0.956s] [INFO] Geronimo :: Security .. SUCCESS [10.488s] [INFO] Geronimo :: Deployment
Re: testsuite
Thanx Tim. But don't sweat too much about it., esp if you have 2.0 priorities. I can wait. Cheers Prasad On 7/31/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi Prasad, I'm looking into that now. Will let you know when it is fixed Prasad Kashyap wrote: Sure. Let me hook up just this one testsuite. The selenium:xvfb goal is working with some workarounds. However, the corba-testsuite is breaking the entire testrun. (https://issues.apache.org/jira/browse/GERONIMO-3360). But I guess I can run just the webservices-testsuite for now or remove corba-testsuite from the mix. Cheers Prasad On 7/31/07, Jarek Gawor [EMAIL PROTECTED] wrote: Prasad, Are we actually running the testsuite now? If not, can we at least start running the webservices-testsuite as it does not require the selenium stuff? Thanks, Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: Yes Jarek. That's one of my TODOs. Thanks to Jason Dillon, we now have a selenium:xvfb goal that will allow us to run this testsuite headless. However, it is not working exactly as desired. Jason is helping us fix it. As soon as it is ready, I'll plug in the testsuite too for daily builds. Cheers Prasad On 6/22/07, Jarek Gawor [EMAIL PROTECTED] wrote: Also, I think we should start running the entire testsuite. We have quite a bit of tests there that should tell us if some basic functionality is broken. Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: I was wondering if we should also publish the artifacts automatically after a successful build. Looking at the apache-snapshots repo, the last published snapshots are more than 2 weeks old. So is it a good idea to publish snaps also after a successful build ? If so, what is a good frequency ? Nightly ? Cheers Prasad On 22 Jun 2007 14:41:15 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OpenEJB trunk at 549821 Geronimo Revision: 549821 built with tests skipped See the full build-1000.log file at http://people.apache.org/~prasad/binaries/20070622/build-1000.log Download the binaries from http://people.apache.org/~prasad/binaries/20070622 [INFO] Reactor Summary: [INFO] [INFO] Geronimo .. SUCCESS [8.947s] [INFO] Geronimo Local Repository . SUCCESS [12.839s] [INFO] Geronimo Build Support SUCCESS [0.023s] [INFO] Geronimo Build Support, Groovy Library SUCCESS [9.188s] [INFO] Geronimo Test Support . SUCCESS [0.041s] [INFO] Geronimo Test Support :: Common ... SUCCESS [6.046s] [INFO] Geronimo Test Support :: Selenium . SUCCESS [5.195s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EJB SUCCESS [1.444s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: WAR SUCCESS [3.967s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: RAR SUCCESS [1.941s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EAR SUCCESS [0.307s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EJB SUCCESS [0.659s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: WAR SUCCESS [0.240s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: RAR SUCCESS [0.101s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EAR SUCCESS [0.107s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 ... SUCCESS [0.030s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EJB SUCCESS [0.739s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: WAR SUCCESS [0.279s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: RAR SUCCESS [0.118s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EAR SUCCESS [0.100s] [INFO] Geronimo :: Modules ... SUCCESS [0.033s] [INFO] Geronimo :: Activation SUCCESS [4.314s] [INFO] Geronimo :: ActiveMQ Resource Adapter . SUCCESS [0.603s] [INFO] Geronimo :: Kernel SUCCESS [8.881s] [INFO] Geronimo :: Common SUCCESS [1.314s] [INFO] Geronimo :: Util .. SUCCESS [4.986s] [INFO] Geronimo :: CLI ... SUCCESS [6.771s] [INFO] Geronimo :: System SUCCESS [7.076s] [INFO] Geronimo :: Management API SUCCESS [3.827s] [INFO] Geronimo :: ActiveMQ Management
[jira] Commented: (GERONIMO-3266) Enhance attributes schema (relates to config.xml)
[ https://issues.apache.org/jira/browse/GERONIMO-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516742 ] Jay D. McHugh commented on GERONIMO-3266: - I believe that this will allow for comments at just about every level of config.xml. Is there any other type of information that we need/want to be able to store? I would rather get all foreseeable changes in now, so that we don't end coming out with attributes-1.3, 1.4, ... If no one has any suggestions of other information that should (could) be stored in config.xml then I'll mark this as finished in about a week (Aug 6, 2007) Enhance attributes schema (relates to config.xml) - Key: GERONIMO-3266 URL: https://issues.apache.org/jira/browse/GERONIMO-3266 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Create a version 1.2 of the attributes.xsd to allow for comments anywhere in the file. Are there any other enhancements that anyone would be interested in for config.xml? If we can figure out what future changes would be desired, maybe we can 'future-proof' the schema so we won't need to mess with it again (at least for a while). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release specs for JACC, JSP, Servlet
On Jul 31, 2007, at 12:27 PM, Jay D. McHugh wrote: I have not ever reviewed/voted on specs and I wanted to know what should be checked before voting. Hi Jay, Good question. Here's a start of a list 1. Do the poms look correct? 2. Are the legal t's and i's crossed and dotted? License/Notice files in all the jars and in the source. Apache source license headers in all of the source files. 3. Do the specs work? Usually this means we satisfied with their bahavior in tck testing. Others? --kevan
Re: testsuite
On Jul 31, 2007, at 8:49 AM, Prasad Kashyap wrote: Sure. Let me hook up just this one testsuite. The selenium:xvfb goal is working with some workarounds. What workarounds? --jason However, the corba-testsuite is breaking the entire testrun. (https://issues.apache.org/jira/browse/GERONIMO-3360). But I guess I can run just the webservices-testsuite for now or remove corba-testsuite from the mix. Cheers Prasad On 7/31/07, Jarek Gawor [EMAIL PROTECTED] wrote: Prasad, Are we actually running the testsuite now? If not, can we at least start running the webservices-testsuite as it does not require the selenium stuff? Thanks, Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: Yes Jarek. That's one of my TODOs. Thanks to Jason Dillon, we now have a selenium:xvfb goal that will allow us to run this testsuite headless. However, it is not working exactly as desired. Jason is helping us fix it. As soon as it is ready, I'll plug in the testsuite too for daily builds. Cheers Prasad On 6/22/07, Jarek Gawor [EMAIL PROTECTED] wrote: Also, I think we should start running the entire testsuite. We have quite a bit of tests there that should tell us if some basic functionality is broken. Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: I was wondering if we should also publish the artifacts automatically after a successful build. Looking at the apache-snapshots repo, the last published snapshots are more than 2 weeks old. So is it a good idea to publish snaps also after a successful build ? If so, what is a good frequency ? Nightly ? Cheers Prasad On 22 Jun 2007 14:41:15 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OpenEJB trunk at 549821 Geronimo Revision: 549821 built with tests skipped See the full build-1000.log file at http://people.apache.org/ ~prasad/binaries/20070622/build-1000.log Download the binaries from http://people.apache.org/~prasad/ binaries/20070622 [INFO] Reactor Summary: [INFO] - --- [INFO] Geronimo .. SUCCESS [8.947s] [INFO] Geronimo Local Repository . SUCCESS [12.839s] [INFO] Geronimo Build Support SUCCESS [0.023s] [INFO] Geronimo Build Support, Groovy Library SUCCESS [9.188s] [INFO] Geronimo Test Support . SUCCESS [0.041s] [INFO] Geronimo Test Support :: Common ... SUCCESS [6.046s] [INFO] Geronimo Test Support :: Selenium . SUCCESS [5.195s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EJB SUCCESS [1.444s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: WAR SUCCESS [3.967s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: RAR SUCCESS [1.941s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EAR SUCCESS [0.307s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EJB SUCCESS [0.659s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: WAR SUCCESS [0.240s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: RAR SUCCESS [0.101s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EAR SUCCESS [0.107s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 ... SUCCESS [0.030s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EJB SUCCESS [0.739s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: WAR SUCCESS [0.279s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: RAR SUCCESS [0.118s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EAR SUCCESS [0.100s] [INFO] Geronimo :: Modules ... SUCCESS [0.033s] [INFO] Geronimo :: Activation SUCCESS [4.314s] [INFO] Geronimo :: ActiveMQ Resource Adapter . SUCCESS [0.603s] [INFO] Geronimo :: Kernel SUCCESS [8.881s] [INFO] Geronimo :: Common SUCCESS [1.314s] [INFO] Geronimo :: Util .. SUCCESS [4.986s] [INFO] Geronimo :: CLI ... SUCCESS [6.771s] [INFO] Geronimo :: System SUCCESS [7.076s] [INFO] Geronimo :: Management API SUCCESS [3.827s] [INFO] Geronimo :: ActiveMQ Management Interfaces SUCCESS [0.608s] [INFO] Geronimo :: Interceptor ... SUCCESS [0.507s] [INFO] Geronimo :: J2EE .. SUCCESS [2.502s] [INFO] Geronimo :: Core .. SUCCESS [0.956s] [INFO] Geronimo :: Security .. SUCCESS
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
On Jul 31, 2007, at 10:47 AM, Jarek Gawor wrote: I'm +1 on the testing this out. I seem to remember that a while ago I've had some problems with CXF when the hidden-classes/ was actually enabled for Spring classes in the Jetty config but maybe it will work better now. See: http://www.mail-archive.com/dev@geronimo.apache.org/msg41202.html. Please also run the testsuite/webservices-testsuite/jaxws-tests/jaxws-*/ tests to verify that everything works ok after the change. OK. So, there are testsuite failures. I'm not seeing problems with other testing, however... I see why you removed the hidden-classes filter... Looks like we're in a bit of a Catch-22... I assume restructuring the spring-based configuration of cxf is pretty disruptive/potentially error-prone? Looks like some apps which include Spring and use jaxws could run into the same type of catch-22. Their only option would be to include the same version of spring that's used by our cxf module... --kevan
Re: testsuite
My workaround where the -Pheadless profile doesn't work. To make it work, I'll have to execute the xvfb goal before the start-server goal in the default profile. Cheers Prasad On 7/31/07, Jason Dillon [EMAIL PROTECTED] wrote: On Jul 31, 2007, at 8:49 AM, Prasad Kashyap wrote: Sure. Let me hook up just this one testsuite. The selenium:xvfb goal is working with some workarounds. What workarounds? --jason However, the corba-testsuite is breaking the entire testrun. (https://issues.apache.org/jira/browse/GERONIMO-3360). But I guess I can run just the webservices-testsuite for now or remove corba-testsuite from the mix. Cheers Prasad On 7/31/07, Jarek Gawor [EMAIL PROTECTED] wrote: Prasad, Are we actually running the testsuite now? If not, can we at least start running the webservices-testsuite as it does not require the selenium stuff? Thanks, Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: Yes Jarek. That's one of my TODOs. Thanks to Jason Dillon, we now have a selenium:xvfb goal that will allow us to run this testsuite headless. However, it is not working exactly as desired. Jason is helping us fix it. As soon as it is ready, I'll plug in the testsuite too for daily builds. Cheers Prasad On 6/22/07, Jarek Gawor [EMAIL PROTECTED] wrote: Also, I think we should start running the entire testsuite. We have quite a bit of tests there that should tell us if some basic functionality is broken. Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: I was wondering if we should also publish the artifacts automatically after a successful build. Looking at the apache-snapshots repo, the last published snapshots are more than 2 weeks old. So is it a good idea to publish snaps also after a successful build ? If so, what is a good frequency ? Nightly ? Cheers Prasad On 22 Jun 2007 14:41:15 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OpenEJB trunk at 549821 Geronimo Revision: 549821 built with tests skipped See the full build-1000.log file at http://people.apache.org/ ~prasad/binaries/20070622/build-1000.log Download the binaries from http://people.apache.org/~prasad/ binaries/20070622 [INFO] Reactor Summary: [INFO] - --- [INFO] Geronimo .. SUCCESS [8.947s] [INFO] Geronimo Local Repository . SUCCESS [12.839s] [INFO] Geronimo Build Support SUCCESS [0.023s] [INFO] Geronimo Build Support, Groovy Library SUCCESS [9.188s] [INFO] Geronimo Test Support . SUCCESS [0.041s] [INFO] Geronimo Test Support :: Common ... SUCCESS [6.046s] [INFO] Geronimo Test Support :: Selenium . SUCCESS [5.195s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EJB SUCCESS [1.444s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: WAR SUCCESS [3.967s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: RAR SUCCESS [1.941s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EAR SUCCESS [0.307s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EJB SUCCESS [0.659s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: WAR SUCCESS [0.240s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: RAR SUCCESS [0.101s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EAR SUCCESS [0.107s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 ... SUCCESS [0.030s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EJB SUCCESS [0.739s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: WAR SUCCESS [0.279s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: RAR SUCCESS [0.118s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EAR SUCCESS [0.100s] [INFO] Geronimo :: Modules ... SUCCESS [0.033s] [INFO] Geronimo :: Activation SUCCESS [4.314s] [INFO] Geronimo :: ActiveMQ Resource Adapter . SUCCESS [0.603s] [INFO] Geronimo :: Kernel SUCCESS [8.881s] [INFO] Geronimo :: Common SUCCESS [1.314s] [INFO] Geronimo :: Util .. SUCCESS [4.986s] [INFO] Geronimo :: CLI ... SUCCESS [6.771s] [INFO] Geronimo :: System SUCCESS [7.076s] [INFO] Geronimo :: Management API SUCCESS [3.827s] [INFO] Geronimo ::
Re: [jira] Commented: (SM-1001) FtpReceiverEndpoint (InternalEndpoint)
On 7/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Guillaumme,
Thanks for reviewing the patch. I thought of having the flexibility of
specifying opeations and their parameters either while configuring the
endpoint (xbean.xml) or as part of the message. As the endpoint is
required to be thread-safe I now feel that we can not have both the
options.
What are your thoughts on this.. May be I do not understand the
internals completely...
Configuring opertions and parameters based on the message itself is
not a problem,
but you can not store these parameters in properties on the endpoint.
You have to use local variables for that and pass them along to the
processing method.
I considered the follwing usecases.
1. Send InOnly exchanges to a target endpoint.
2. Answer to an InOut exchange (operations like file/directory listing,
get file content etc)
Again, when you talk about a real WSDL, if I understand correctly you
mean to create static wsdl for all the operations possible. How do you
envisage to differentiate the different MEPs for the same operations
(sending the file content to a target vs returing to the consumer), do
you expect to have different operations for them in the WSDL??
Can you please elaborate your thoughts on this?
Sure.
You need to think about the service as a web service or even a java
interface (they can be mapped together somehow).
So let' s say you have a java interface that describes your service:
interface FtpSenderService {
public void sendFile(String ftpUrl, Document doc);
public Document getFile(String ftpUrl);
public ListString listFiles(String ftpUrl);
}
(this is just an example of how to express the various operations you
mentioned).
Then you can translate it to a WSDL (using a tool or write it directly).
The idea is to have a formal contract for the endpoint.
I don' t think we need to use jaxb2 or a marshalling layer here and the
DOM xml should be sufficient (as it is currently). The only difference is
that there will be a namespace defined and an explicit contract for
this endpoint.
Makes sense?
Regards,
Rabi Mishra,
Wipro Technologies,Office: +91-20-39104549, VOIP:842
2545,CELL+91(0)9890363765
http://rabisblog.blogspot.com/
c++; /* this makes c bigger but returns the old value */
-Original Message-
From: Guillaume Nodet (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Monday, July 30, 2007 8:12 PM
To: [EMAIL PROTECTED]
Subject: [jira] Commented: (SM-1001) FtpReceiverEndpoint
(InternalEndpoint)
[
https://issues.apache.org/activemq/browse/SM-1001?page=com.atlassian.jir
a.plugin.system.issuetabpanels:comment-tabpanel#action_39796 ]
Guillaume Nodet commented on SM-1001:
-
I think there is one big problem: the message contains some
informations used to configure the endpoint when the message is
received.
This means that the endpoint is not thread safe. Endpoints have to be,
as they are given exchanges concurrently.
Another thing is that I' d really like to have a real WSDL to describe
the interface for this endpoint, the operations and their parameters.
FtpReceiverEndpoint (InternalEndpoint)
---
Key: SM-1001
URL: https://issues.apache.org/activemq/browse/SM-1001
Project: ServiceMix
Issue Type: Improvement
Reporter: Rabi
Attachments: patch.txt
FtpReceiverEndpoint (InternalEndpoint)
- Can accpet in-out mep for listing files
- Supports InOnly mep for get/mget operations...
Usage:
xbean configuration:
--
beans xmlns:ftp=http://servicemix.apache.org/ftp/1.0;
xmlns:b=http://servicemix.apache.org/samples/ftp-receiver;
ftp:receiver service=b:ftpReceiver
endpoint=endpoint
uri=ftp://rabi:[EMAIL PROTECTED]
ftp:target
ftp:exchange-target service=b:pipeline/
/ftp:target
/ftp:receiver
Input Message structure
-
?xml version=1.0 encoding=UTF-8? ftp:input
xmlns:ftp=http://servicemix.apache.org/ftp/1.0; operation=mget
recursive=true filter=* relativeUri=/inbox /ftp:input Output
for file listing
STATUS: 200
?xml version='1.0' encoding='UTF-8'? ftp:list
xmlns:ftp=http://servicemix.apache.org/ftp/1.0;
ftp:directory name=/http/inbox/data/inner
ftp:file/http/inbox/data/inner/tx.xml/ftp:file
/ftp:directory
ftp:file/http/inbox/data/servicemix.xml/ftp:file
/ftp:list
This is a very simple version. Please suggest on the improvements..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and
Re: testsuite
Kay. I don't really think that is a workarond :-p. but I understand Just wanted to make sure there were not other wrinkles in the plugin ;-) --jason -Original Message- From: Prasad Kashyap [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 14:25:49 To:dev@geronimo.apache.org Subject: Re: testsuite My workaround where the -Pheadless profile doesn't work. To make it work, I'll have to execute the xvfb goal before the start-server goal in the default profile. Cheers Prasad On 7/31/07, Jason Dillon [EMAIL PROTECTED] wrote: On Jul 31, 2007, at 8:49 AM, Prasad Kashyap wrote: Sure. Let me hook up just this one testsuite. The selenium:xvfb goal is working with some workarounds. What workarounds? --jason However, the corba-testsuite is breaking the entire testrun. (https://issues.apache.org/jira/browse/GERONIMO-3360). But I guess I can run just the webservices-testsuite for now or remove corba-testsuite from the mix. Cheers Prasad On 7/31/07, Jarek Gawor [EMAIL PROTECTED] wrote: Prasad, Are we actually running the testsuite now? If not, can we at least start running the webservices-testsuite as it does not require the selenium stuff? Thanks, Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: Yes Jarek. That's one of my TODOs. Thanks to Jason Dillon, we now have a selenium:xvfb goal that will allow us to run this testsuite headless. However, it is not working exactly as desired. Jason is helping us fix it. As soon as it is ready, I'll plug in the testsuite too for daily builds. Cheers Prasad On 6/22/07, Jarek Gawor [EMAIL PROTECTED] wrote: Also, I think we should start running the entire testsuite. We have quite a bit of tests there that should tell us if some basic functionality is broken. Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: I was wondering if we should also publish the artifacts automatically after a successful build. Looking at the apache-snapshots repo, the last published snapshots are more than 2 weeks old. So is it a good idea to publish snaps also after a successful build ? If so, what is a good frequency ? Nightly ? Cheers Prasad On 22 Jun 2007 14:41:15 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OpenEJB trunk at 549821 Geronimo Revision: 549821 built with tests skipped See the full build-1000.log file at http://people.apache.org/ ~prasad/binaries/20070622/build-1000.log Download the binaries from http://people.apache.org/~prasad/ binaries/20070622 [INFO] Reactor Summary: [INFO] - --- [INFO] Geronimo .. SUCCESS [8.947s] [INFO] Geronimo Local Repository . SUCCESS [12.839s] [INFO] Geronimo Build Support SUCCESS [0.023s] [INFO] Geronimo Build Support, Groovy Library SUCCESS [9.188s] [INFO] Geronimo Test Support . SUCCESS [0.041s] [INFO] Geronimo Test Support :: Common ... SUCCESS [6.046s] [INFO] Geronimo Test Support :: Selenium . SUCCESS [5.195s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EJB SUCCESS [1.444s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: WAR SUCCESS [3.967s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: RAR SUCCESS [1.941s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EAR SUCCESS [0.307s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EJB SUCCESS [0.659s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: WAR SUCCESS [0.240s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: RAR SUCCESS [0.101s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EAR SUCCESS [0.107s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 ... SUCCESS [0.030s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EJB SUCCESS [0.739s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: WAR SUCCESS [0.279s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: RAR SUCCESS [0.118s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EAR SUCCESS [0.100s] [INFO] Geronimo :: Modules ... SUCCESS [0.033s] [INFO] Geronimo :: Activation SUCCESS [4.314s] [INFO] Geronimo :: ActiveMQ Resource Adapter . SUCCESS [0.603s] [INFO] Geronimo :: Kernel SUCCESS [8.881s] [INFO] Geronimo :: Common SUCCESS [1.314s] [INFO] Geronimo :: Util
Re: [VOTE] Release specs for JACC, JSP, Servlet
On Jul 30, 2007, at 10:04 PM, Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 +1. Looks good. One comment -- I'm not a big fan of the NOTICE file contents, however. For example: // -- // NOTICE file corresponding to the section 4d of The Apache License, // Version 2.0, in this case for Servlet 2.5 // -- Servlet 2.5 Copyright 2003-2007 The Apache Software Foundation ... I think it would be better if it was: // -- // NOTICE file corresponding to the section 4d of The Apache License, // Version 2.0, in this case for the Apache Geronimo Servlet 2.5 Specification // -- Apache Geronimo Servlet 2.5 Specification Copyright 2003-2007 The Apache Software Foundation ... Not necessary that this be changed, but could be updated, also... --kevan
Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder
On 7/31/07, Kevan Miller [EMAIL PROTECTED] wrote: OK. So, there are testsuite failures. I'm not seeing problems with other testing, however... I see why you removed the hidden-classes filter... Looks like we're in a bit of a Catch-22... I assume restructuring the spring-based configuration of cxf is pretty disruptive/potentially error-prone? Looks like some apps which include Spring and use jaxws could run into the same type of catch-22. Their only option would be to include the same version of spring that's used by our cxf module... Yes, I think so. But I could spend a day or two to see what it would take to configure CXF without Spring. Jarek
Re: Update README file
Kevan, I'll take a stab at it Kevan Miller wrote: I think our README.txt file could stand a bit of updating... Things like: Apache Geronimo milestone build M4 (August 10, 2005) I'd also like to see usage instructions for shell scripts (e.g. geronimo.sh/geronimo.bat, etc) rather than/or in addition to explicit java commands... If someone wants to take a crack at this, that would be great. Otherwise, I'll work on it after I finish license/notice stuff. --kevan -- Thanks, Tim McConnell
Re: KEYS ?
Well, I think we should probably consolidate all these ;-) --jason On Jul 31, 2007, at 8:16 AM, Matt Hogstrom wrote: Good point. I think we have the KEYs file in a couple of places. on people there is: /www/people.apache.org/ ./repo/m1-ibiblio-rsync-repository/geronimo/KEYS ./repo/m2-ibiblio-rsync-repository/org/apache/geronimo/KEYS ./repo/m1-ibiblio-rsync-repository/org.apache.xbean/KEYS ./repo/m2-ibiblio-rsync-repository/org/apache/xbean/KEYS ./repo/m2-ibiblio-rsync-repository.backup/org/apache/geronimo/ genesis/KEYS ./repo/m2-ibiblio-rsync-repository.backup/org/apache/geronimo/KEYS ./repo/m2-ibiblio-rsync-repository.backup/org/apache/xbean/KEYS on /www/www.apache.org/dist/ .geronimo/KEYS We also have a web link from http://www.apache.org/dist/geronimo/KEYS Not sure if there are other references (and yes, I know these are outside svn :) On Jul 30, 2007, at 12:35 PM, Dain Sundstrom wrote: I'm not sure, but it may be mentioned in old binaries as the location for verifying the signatures. I could be completely wrong... I just have a memory of some external references. If you do move the file, I'd definitely search the website for references. -dain On Jul 27, 2007, at 12:35 PM, Jason Dillon wrote: What external references are you referring to? I believe that it does have symlink support, though I hardly ever use it. --jason On Jul 27, 2007, at 12:29 PM, Dain Sundstrom wrote: I think there are external references to this file, but I'm not sure how we should deal with them. Does svn have symlink support? -dain On Jul 26, 2007, at 3:52 PM, Jason Dillon wrote: Should keys move up to a peer to the STATUS file too? Seems these are project global, not specific to the server bits... --jason
Re: testsuite
Well, I just want to ensure it's not a 2.0-specific problem. Prasad Kashyap wrote: Thanx Tim. But don't sweat too much about it., esp if you have 2.0 priorities. I can wait. Cheers Prasad On 7/31/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi Prasad, I'm looking into that now. Will let you know when it is fixed Prasad Kashyap wrote: Sure. Let me hook up just this one testsuite. The selenium:xvfb goal is working with some workarounds. However, the corba-testsuite is breaking the entire testrun. (https://issues.apache.org/jira/browse/GERONIMO-3360). But I guess I can run just the webservices-testsuite for now or remove corba-testsuite from the mix. Cheers Prasad On 7/31/07, Jarek Gawor [EMAIL PROTECTED] wrote: Prasad, Are we actually running the testsuite now? If not, can we at least start running the webservices-testsuite as it does not require the selenium stuff? Thanks, Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: Yes Jarek. That's one of my TODOs. Thanks to Jason Dillon, we now have a selenium:xvfb goal that will allow us to run this testsuite headless. However, it is not working exactly as desired. Jason is helping us fix it. As soon as it is ready, I'll plug in the testsuite too for daily builds. Cheers Prasad On 6/22/07, Jarek Gawor [EMAIL PROTECTED] wrote: Also, I think we should start running the entire testsuite. We have quite a bit of tests there that should tell us if some basic functionality is broken. Jarek On 6/22/07, Prasad Kashyap [EMAIL PROTECTED] wrote: I was wondering if we should also publish the artifacts automatically after a successful build. Looking at the apache-snapshots repo, the last published snapshots are more than 2 weeks old. So is it a good idea to publish snaps also after a successful build ? If so, what is a good frequency ? Nightly ? Cheers Prasad On 22 Jun 2007 14:41:15 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OpenEJB trunk at 549821 Geronimo Revision: 549821 built with tests skipped See the full build-1000.log file at http://people.apache.org/~prasad/binaries/20070622/build-1000.log Download the binaries from http://people.apache.org/~prasad/binaries/20070622 [INFO] Reactor Summary: [INFO] [INFO] Geronimo .. SUCCESS [8.947s] [INFO] Geronimo Local Repository . SUCCESS [12.839s] [INFO] Geronimo Build Support SUCCESS [0.023s] [INFO] Geronimo Build Support, Groovy Library SUCCESS [9.188s] [INFO] Geronimo Test Support . SUCCESS [0.041s] [INFO] Geronimo Test Support :: Common ... SUCCESS [6.046s] [INFO] Geronimo Test Support :: Selenium . SUCCESS [5.195s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EJB SUCCESS [1.444s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: WAR SUCCESS [3.967s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: RAR SUCCESS [1.941s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EAR SUCCESS [0.307s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 ... SUCCESS [0.025s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EJB SUCCESS [0.659s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: WAR SUCCESS [0.240s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: RAR SUCCESS [0.101s] [INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EAR SUCCESS [0.107s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 ... SUCCESS [0.030s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EJB SUCCESS [0.739s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: WAR SUCCESS [0.279s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: RAR SUCCESS [0.118s] [INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EAR SUCCESS [0.100s] [INFO] Geronimo :: Modules ... SUCCESS [0.033s] [INFO] Geronimo :: Activation SUCCESS [4.314s] [INFO] Geronimo :: ActiveMQ Resource Adapter . SUCCESS [0.603s] [INFO] Geronimo :: Kernel SUCCESS [8.881s] [INFO] Geronimo :: Common SUCCESS [1.314s] [INFO] Geronimo :: Util .. SUCCESS [4.986s] [INFO] Geronimo :: CLI ... SUCCESS [6.771s] [INFO] Geronimo :: System SUCCESS [7.076s] [INFO] Geronimo :: Management API SUCCESS [3.827s] [INFO] Geronimo :: ActiveMQ Management Interfaces SUCCESS [0.608s] [INFO] Geronimo :: Interceptor ... SUCCESS [0.507s] [INFO] Geronimo :: J2EE
Re: [VOTE] Release specs for JACC, JSP, Servlet
Ok, good info to know. Thanks Kevan Miller wrote: On Jul 30, 2007, at 10:04 PM, Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 +1. Looks good. One comment -- I'm not a big fan of the NOTICE file contents, however. For example: // -- // NOTICE file corresponding to the section 4d of The Apache License, // Version 2.0, in this case for Servlet 2.5 // -- Servlet 2.5 Copyright 2003-2007 The Apache Software Foundation ... I think it would be better if it was: // -- // NOTICE file corresponding to the section 4d of The Apache License, // Version 2.0, in this case for the Apache Geronimo Servlet 2.5 Specification // -- Apache Geronimo Servlet 2.5 Specification Copyright 2003-2007 The Apache Software Foundation ... Not necessary that this be changed, but could be updated, also... --kevan -- Thanks, Tim McConnell
[jira] Updated: (GERONIMO-3360) corba-marshall and corba-mytime tests failing
[
https://issues.apache.org/jira/browse/GERONIMO-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim McConnell updated GERONIMO-3360:
Hi Prasad, I've promoted a fix for the corba-mytime test for both trunk and the
2.0 branch.
We have encountered this marshalling exception before (see
https://issues.apache.org/jira/browse/GERONIMO-3247).
Since Rick is investigating why it has resurfaced I shall assign it to him for
final resolution. Thanks
corba-marshall and corba-mytime tests failing
-
Key: GERONIMO-3360
URL: https://issues.apache.org/jira/browse/GERONIMO-3360
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: testsuite
Affects Versions: 2.0, 2.0.x, 2.1
Reporter: Prasad Kashyap
Assignee: Tim McConnell
Fix For: 2.0.x
exception in corba-marshall :
{code}
[INFO] [INFO] long passed to EJB: 1218738708599296309
[INFO] [WARNING] java.lang.Exception: long array test RemoteException:
[3675022138608874094, -4905270342012320510] java.rmi.RemoteException: null;
nested exception is:
[INFO] [WARNING] org.omg.CORBA.UNKNOWN: vmcid: 0x0 minor code: 0x0
completed: No
[INFO] [WARNING] at
org.apache.geronimo.testsuite.corba.marshal.JavaPrimitives.marshal(JavaPrimitives.java:415)
[INFO] [WARNING] at
org.apache.geronimo.testsuite.corba.marshal.MarshalEJBClient.main(MarshalEJBClient.java:43)
[INFO] [WARNING] at java.lang.reflect.Method.invoke(Method.java:585)
[INFO] [WARNING] at
org.apache.geronimo.client.AppClientContainer.main(AppClientContainer.java:185)
{code}
Exception in corba-mytime:
{code}
[WARNING] Deployer operation failed: start of
org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car failed
[WARNING] org.apache.geronimo.kernel.config.LifecycleException: start of
org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car failed
[WARNING] Caused by:
org.apache.geronimo.kernel.config.InvalidConfigException: Unknown start
exception
[WARNING] at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:514)
[WARNING] at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
[WARNING] at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530)
[WARNING] ... 35 more
[WARNING] Caused by: org.apache.geronimo.gbean.InvalidConfigurationException:
Configuration org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car
failed to start due to the following reasons:
[WARNING] The service
EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,StatelessSessionBean=MyTime,j2eeType=TSSLink,name=IdentityTokenNoSecurity
did not start because
org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car?EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity
did not start.
[WARNING] The service
EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity
did not start because IDL:omg.org/PortableServer/POA/AdapterAlreadyExists:1.0
[WARNING]
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3360) corba-marshall and corba-mytime tests failing
[
https://issues.apache.org/jira/browse/GERONIMO-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim McConnell updated GERONIMO-3360:
Assignee: Rick McGuire (was: Tim McConnell)
corba-marshall and corba-mytime tests failing
-
Key: GERONIMO-3360
URL: https://issues.apache.org/jira/browse/GERONIMO-3360
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: testsuite
Affects Versions: 2.0, 2.0.x, 2.1
Reporter: Prasad Kashyap
Assignee: Rick McGuire
Fix For: 2.0.x
exception in corba-marshall :
{code}
[INFO] [INFO] long passed to EJB: 1218738708599296309
[INFO] [WARNING] java.lang.Exception: long array test RemoteException:
[3675022138608874094, -4905270342012320510] java.rmi.RemoteException: null;
nested exception is:
[INFO] [WARNING] org.omg.CORBA.UNKNOWN: vmcid: 0x0 minor code: 0x0
completed: No
[INFO] [WARNING] at
org.apache.geronimo.testsuite.corba.marshal.JavaPrimitives.marshal(JavaPrimitives.java:415)
[INFO] [WARNING] at
org.apache.geronimo.testsuite.corba.marshal.MarshalEJBClient.main(MarshalEJBClient.java:43)
[INFO] [WARNING] at java.lang.reflect.Method.invoke(Method.java:585)
[INFO] [WARNING] at
org.apache.geronimo.client.AppClientContainer.main(AppClientContainer.java:185)
{code}
Exception in corba-mytime:
{code}
[WARNING] Deployer operation failed: start of
org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car failed
[WARNING] org.apache.geronimo.kernel.config.LifecycleException: start of
org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car failed
[WARNING] Caused by:
org.apache.geronimo.kernel.config.InvalidConfigException: Unknown start
exception
[WARNING] at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:514)
[WARNING] at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
[WARNING] at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530)
[WARNING] ... 35 more
[WARNING] Caused by: org.apache.geronimo.gbean.InvalidConfigurationException:
Configuration org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car
failed to start due to the following reasons:
[WARNING] The service
EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,StatelessSessionBean=MyTime,j2eeType=TSSLink,name=IdentityTokenNoSecurity
did not start because
org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car?EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity
did not start.
[WARNING] The service
EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity
did not start because IDL:omg.org/PortableServer/POA/AdapterAlreadyExists:1.0
[WARNING]
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3271) Update all users of the attributes schema to use new version
[ https://issues.apache.org/jira/browse/GERONIMO-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh reassigned GERONIMO-3271: --- Assignee: Jay D. McHugh Update all users of the attributes schema to use new version Key: GERONIMO-3271 URL: https://issues.apache.org/jira/browse/GERONIMO-3271 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3165) Extended persistence contexts need to use some openejb facilities so they can get created when a stateful bean instance is created
[ https://issues.apache.org/jira/browse/GERONIMO-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516797 ] Ted Kirby commented on GERONIMO-3165: - Looks like the commit number is r538730, where GERONIMO-3132 was fixed also. Extended persistence contexts need to use some openejb facilities so they can get created when a stateful bean instance is created -- Key: GERONIMO-3165 URL: https://issues.apache.org/jira/browse/GERONIMO-3165 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0-M6 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0-M6 We have to end up with new EntityManagers whenever a stateful session bean with extended persistence context is created. This means we have to hook up with openejb somehow. Simplest is to basically use a bunch of their framework for extended pc entity managers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release specs for JACC, JSP, Servlet
+1 for your first release Tim. Cheers Prasad On 7/30/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 The corresponding tar files are here: http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz The current svn locations are here: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-servlet_2.5_spec-1.1 The future svn locations will be here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1 The vote will conclude at 10:00 PM EST on Thursday, August 2nd. -- Thanks, Tim McConnell
[jira] Reopened: (GERONIMO-3357) run-as role is ignored in web.xml
[
https://issues.apache.org/jira/browse/GERONIMO-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aman Nanner reopened GERONIMO-3357:
---
I will attach a test case which demonstrates that does not work.
run-as role is ignored in web.xml
---
Key: GERONIMO-3357
URL: https://issues.apache.org/jira/browse/GERONIMO-3357
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0-M7
Environment: Windows XP SP2
Reporter: Aman Nanner
Assignee: David Jencks
Priority: Critical
Fix For: 2.0
It seems that any run-as roles defined in a web.xml of a web application
are ignored. For example, consider the following web.xml fragment:
{code:xml}
servlet
servlet-nameExceptionPage/servlet-name
jsp-file/error/Exception.jsp/jsp-file
run-as
role-nameTESTSYSTEM/role-name
/run-as
/servlet
{code}
The JSP is never run as the TESTSYSTEM role in this case, and thus access to
method-restricted EJBs fails from the JSP. I cannot see in the
TomcatGeronimoRealm where this run-as role is being set, or if it is
accessing the credential store to get the run-as subject.
Below is the fragment of my geronimo-application.xml where I define the
security policy:
{code:xml}
security:security
security:credential-store
security:pattern
sys:name
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;MyCredentialStore/sys:name
/security:pattern
/security:credential-store
security:role-mappings
security:role role-name=TESTSYSTEM
security:run-as-subject
security:realmTestingRealm/security:realm
security:idtest-system/security:id
/security:run-as-subject
security:realm realm-name=TestingRealm
security:principal
class=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal
name=TESTSYSTEM /
/security:realm
/security:role
/security:role-mappings
/security:security
sys:gbean name=TestingRealm
class=org.apache.geronimo.security.realm.GenericSecurityRealm
sys:attribute name=realmNameTestingRealm/sys:attribute
sys:reference name=ServerInfo
sys:nameServerInfo/sys:name
/sys:reference
sys:xml-reference name=LoginModuleConfiguration
log:login-config
xmlns:log=http://geronimo.apache.org/xml/ns/loginconfig-2.0;
log:login-module control-flag=REQUIRED
wrap-principals=false
log:login-domain-nameTestingRealm/log:login-domain-name
log:login-module-classcom.testing.security.TestingLoginModule/log:login-module-class
log:option name=userSelectSELECT username, password FROM
utl_user WHERE username=?/log:option
log:option
name=dataSourceApplicationMxi/Testing/1/ear/log:option
log:option name=groupSelectSELECT name, 'TESTSYSTEM' as
role_name FROM dual/log:option
log:option
name=dataSourceNamecom/testing/jdbc/TestDS/log:option
/log:login-module
/log:login-config
/sys:xml-reference
/sys:gbean
sys:gbean name=MyCredentialStore
class=org.apache.geronimo.security.credentialstore.SimpleCredentialStoreImpl
xml-attribute name=credentialStore
credential-store
xmlns=http://geronimo.apache.org/xml/ns/credentialstore-1.0;
!-- uncomment this and the default subject in the jettty
console plan gives you admin console permissions --
realm name=TestingRealm
subject
idtest-system/id
credential
typeorg.apache.geronimo.security.credentialstore.NameCallbackHandler/type
valueananner/value
/credential
credential
typeorg.apache.geronimo.security.credentialstore.PasswordCallbackHandler/type
valuepassword/value
/credential
/subject
/realm
/credential-store
/xml-attribute
/sys:gbean
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3357) run-as role is ignored in web.xml
[
https://issues.apache.org/jira/browse/GERONIMO-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aman Nanner updated GERONIMO-3357:
--
Attachment: testing.ear.zip
This EAR file demonstrates the test case.
Access the page: http://localhost/testing.
The index.jsp file is defined with a run-as role so that it can make a
restricted EJB call.
run-as role is ignored in web.xml
---
Key: GERONIMO-3357
URL: https://issues.apache.org/jira/browse/GERONIMO-3357
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0-M7
Environment: Windows XP SP2
Reporter: Aman Nanner
Assignee: David Jencks
Priority: Critical
Fix For: 2.0
Attachments: testing.ear.zip
It seems that any run-as roles defined in a web.xml of a web application
are ignored. For example, consider the following web.xml fragment:
{code:xml}
servlet
servlet-nameExceptionPage/servlet-name
jsp-file/error/Exception.jsp/jsp-file
run-as
role-nameTESTSYSTEM/role-name
/run-as
/servlet
{code}
The JSP is never run as the TESTSYSTEM role in this case, and thus access to
method-restricted EJBs fails from the JSP. I cannot see in the
TomcatGeronimoRealm where this run-as role is being set, or if it is
accessing the credential store to get the run-as subject.
Below is the fragment of my geronimo-application.xml where I define the
security policy:
{code:xml}
security:security
security:credential-store
security:pattern
sys:name
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;MyCredentialStore/sys:name
/security:pattern
/security:credential-store
security:role-mappings
security:role role-name=TESTSYSTEM
security:run-as-subject
security:realmTestingRealm/security:realm
security:idtest-system/security:id
/security:run-as-subject
security:realm realm-name=TestingRealm
security:principal
class=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal
name=TESTSYSTEM /
/security:realm
/security:role
/security:role-mappings
/security:security
sys:gbean name=TestingRealm
class=org.apache.geronimo.security.realm.GenericSecurityRealm
sys:attribute name=realmNameTestingRealm/sys:attribute
sys:reference name=ServerInfo
sys:nameServerInfo/sys:name
/sys:reference
sys:xml-reference name=LoginModuleConfiguration
log:login-config
xmlns:log=http://geronimo.apache.org/xml/ns/loginconfig-2.0;
log:login-module control-flag=REQUIRED
wrap-principals=false
log:login-domain-nameTestingRealm/log:login-domain-name
log:login-module-classcom.testing.security.TestingLoginModule/log:login-module-class
log:option name=userSelectSELECT username, password FROM
utl_user WHERE username=?/log:option
log:option
name=dataSourceApplicationMxi/Testing/1/ear/log:option
log:option name=groupSelectSELECT name, 'TESTSYSTEM' as
role_name FROM dual/log:option
log:option
name=dataSourceNamecom/testing/jdbc/TestDS/log:option
/log:login-module
/log:login-config
/sys:xml-reference
/sys:gbean
sys:gbean name=MyCredentialStore
class=org.apache.geronimo.security.credentialstore.SimpleCredentialStoreImpl
xml-attribute name=credentialStore
credential-store
xmlns=http://geronimo.apache.org/xml/ns/credentialstore-1.0;
!-- uncomment this and the default subject in the jettty
console plan gives you admin console permissions --
realm name=TestingRealm
subject
idtest-system/id
credential
typeorg.apache.geronimo.security.credentialstore.NameCallbackHandler/type
valueananner/value
/credential
credential
typeorg.apache.geronimo.security.credentialstore.PasswordCallbackHandler/type
valuepassword/value
/credential
/subject
/realm
/credential-store
/xml-attribute
/sys:gbean
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3357) run-as role is ignored in web.xml
[
https://issues.apache.org/jira/browse/GERONIMO-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516820
]
David Jencks commented on GERONIMO-3357:
OK, with your app I see the problem, at least in jetty. The difference between
our apps is that yours uses the default subject in the web app, whereas mine
uses an authenticated subject in the web app.
run-as role is ignored in web.xml
---
Key: GERONIMO-3357
URL: https://issues.apache.org/jira/browse/GERONIMO-3357
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0-M7
Environment: Windows XP SP2
Reporter: Aman Nanner
Assignee: David Jencks
Priority: Critical
Fix For: 2.0
Attachments: testing.ear.zip
It seems that any run-as roles defined in a web.xml of a web application
are ignored. For example, consider the following web.xml fragment:
{code:xml}
servlet
servlet-nameExceptionPage/servlet-name
jsp-file/error/Exception.jsp/jsp-file
run-as
role-nameTESTSYSTEM/role-name
/run-as
/servlet
{code}
The JSP is never run as the TESTSYSTEM role in this case, and thus access to
method-restricted EJBs fails from the JSP. I cannot see in the
TomcatGeronimoRealm where this run-as role is being set, or if it is
accessing the credential store to get the run-as subject.
Below is the fragment of my geronimo-application.xml where I define the
security policy:
{code:xml}
security:security
security:credential-store
security:pattern
sys:name
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;MyCredentialStore/sys:name
/security:pattern
/security:credential-store
security:role-mappings
security:role role-name=TESTSYSTEM
security:run-as-subject
security:realmTestingRealm/security:realm
security:idtest-system/security:id
/security:run-as-subject
security:realm realm-name=TestingRealm
security:principal
class=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal
name=TESTSYSTEM /
/security:realm
/security:role
/security:role-mappings
/security:security
sys:gbean name=TestingRealm
class=org.apache.geronimo.security.realm.GenericSecurityRealm
sys:attribute name=realmNameTestingRealm/sys:attribute
sys:reference name=ServerInfo
sys:nameServerInfo/sys:name
/sys:reference
sys:xml-reference name=LoginModuleConfiguration
log:login-config
xmlns:log=http://geronimo.apache.org/xml/ns/loginconfig-2.0;
log:login-module control-flag=REQUIRED
wrap-principals=false
log:login-domain-nameTestingRealm/log:login-domain-name
log:login-module-classcom.testing.security.TestingLoginModule/log:login-module-class
log:option name=userSelectSELECT username, password FROM
utl_user WHERE username=?/log:option
log:option
name=dataSourceApplicationMxi/Testing/1/ear/log:option
log:option name=groupSelectSELECT name, 'TESTSYSTEM' as
role_name FROM dual/log:option
log:option
name=dataSourceNamecom/testing/jdbc/TestDS/log:option
/log:login-module
/log:login-config
/sys:xml-reference
/sys:gbean
sys:gbean name=MyCredentialStore
class=org.apache.geronimo.security.credentialstore.SimpleCredentialStoreImpl
xml-attribute name=credentialStore
credential-store
xmlns=http://geronimo.apache.org/xml/ns/credentialstore-1.0;
!-- uncomment this and the default subject in the jettty
console plan gives you admin console permissions --
realm name=TestingRealm
subject
idtest-system/id
credential
typeorg.apache.geronimo.security.credentialstore.NameCallbackHandler/type
valueananner/value
/credential
credential
typeorg.apache.geronimo.security.credentialstore.PasswordCallbackHandler/type
valuepassword/value
/credential
/subject
/realm
/credential-store
/xml-attribute
/sys:gbean
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release specs for JACC, JSP, Servlet
+1 -Donald Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 The corresponding tar files are here: http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz The current svn locations are here: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-servlet_2.5_spec-1.1 The future svn locations will be here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1 The vote will conclude at 10:00 PM EST on Thursday, August 2nd. smime.p7s Description: S/MIME Cryptographic Signature
[jira] Updated: (GERONIMO-3357) run-as role is ignored in web.xml
[
https://issues.apache.org/jira/browse/GERONIMO-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks updated GERONIMO-3357:
---
Attachment: testing2.ear
I take it back, geronimo is working fine. There were a lot of configuration
problems in your app:
1. no servlet mapping for your jsp, so it was getting served by the default jsp
servlet, which doesn't have a run-as role. I added a mapping to test, so
localhost:8080/testing/test gets the jsp. This illustrates why the default jsp
servlet may be a bad idea.
2. wrong principal in the role-mapping. MXSYSTEM is not produced by
geronimo-adming realm. I changed it to admin.
Also the schemas have changed a bit, I updated to use jetty and the new
configuration-store-ref element.
I might have updated to an uncommitted schema namespace */jetty-2.0, in which
case you can wait until I commit or move it back to 1.2.
run-as role is ignored in web.xml
---
Key: GERONIMO-3357
URL: https://issues.apache.org/jira/browse/GERONIMO-3357
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0-M7
Environment: Windows XP SP2
Reporter: Aman Nanner
Assignee: David Jencks
Priority: Critical
Fix For: 2.0
Attachments: testing.ear.zip, testing2.ear
It seems that any run-as roles defined in a web.xml of a web application
are ignored. For example, consider the following web.xml fragment:
{code:xml}
servlet
servlet-nameExceptionPage/servlet-name
jsp-file/error/Exception.jsp/jsp-file
run-as
role-nameTESTSYSTEM/role-name
/run-as
/servlet
{code}
The JSP is never run as the TESTSYSTEM role in this case, and thus access to
method-restricted EJBs fails from the JSP. I cannot see in the
TomcatGeronimoRealm where this run-as role is being set, or if it is
accessing the credential store to get the run-as subject.
Below is the fragment of my geronimo-application.xml where I define the
security policy:
{code:xml}
security:security
security:credential-store
security:pattern
sys:name
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;MyCredentialStore/sys:name
/security:pattern
/security:credential-store
security:role-mappings
security:role role-name=TESTSYSTEM
security:run-as-subject
security:realmTestingRealm/security:realm
security:idtest-system/security:id
/security:run-as-subject
security:realm realm-name=TestingRealm
security:principal
class=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal
name=TESTSYSTEM /
/security:realm
/security:role
/security:role-mappings
/security:security
sys:gbean name=TestingRealm
class=org.apache.geronimo.security.realm.GenericSecurityRealm
sys:attribute name=realmNameTestingRealm/sys:attribute
sys:reference name=ServerInfo
sys:nameServerInfo/sys:name
/sys:reference
sys:xml-reference name=LoginModuleConfiguration
log:login-config
xmlns:log=http://geronimo.apache.org/xml/ns/loginconfig-2.0;
log:login-module control-flag=REQUIRED
wrap-principals=false
log:login-domain-nameTestingRealm/log:login-domain-name
log:login-module-classcom.testing.security.TestingLoginModule/log:login-module-class
log:option name=userSelectSELECT username, password FROM
utl_user WHERE username=?/log:option
log:option
name=dataSourceApplicationMxi/Testing/1/ear/log:option
log:option name=groupSelectSELECT name, 'TESTSYSTEM' as
role_name FROM dual/log:option
log:option
name=dataSourceNamecom/testing/jdbc/TestDS/log:option
/log:login-module
/log:login-config
/sys:xml-reference
/sys:gbean
sys:gbean name=MyCredentialStore
class=org.apache.geronimo.security.credentialstore.SimpleCredentialStoreImpl
xml-attribute name=credentialStore
credential-store
xmlns=http://geronimo.apache.org/xml/ns/credentialstore-1.0;
!-- uncomment this and the default subject in the jettty
console plan gives you admin console permissions --
realm name=TestingRealm
subject
idtest-system/id
credential
typeorg.apache.geronimo.security.credentialstore.NameCallbackHandler/type
valueananner/value
/credential
credential
typeorg.apache.geronimo.security.credentialstore.PasswordCallbackHandler/type
valuepassword/value
[jira] Closed: (GERONIMO-3357) run-as role is ignored in web.xml
[
https://issues.apache.org/jira/browse/GERONIMO-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks closed GERONIMO-3357.
--
Resolution: Cannot Reproduce
Example supplied was misconfigured and when corrected worked fine.
run-as role is ignored in web.xml
---
Key: GERONIMO-3357
URL: https://issues.apache.org/jira/browse/GERONIMO-3357
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0-M7
Environment: Windows XP SP2
Reporter: Aman Nanner
Assignee: David Jencks
Priority: Critical
Fix For: 2.0
Attachments: testing.ear.zip, testing2.ear
It seems that any run-as roles defined in a web.xml of a web application
are ignored. For example, consider the following web.xml fragment:
{code:xml}
servlet
servlet-nameExceptionPage/servlet-name
jsp-file/error/Exception.jsp/jsp-file
run-as
role-nameTESTSYSTEM/role-name
/run-as
/servlet
{code}
The JSP is never run as the TESTSYSTEM role in this case, and thus access to
method-restricted EJBs fails from the JSP. I cannot see in the
TomcatGeronimoRealm where this run-as role is being set, or if it is
accessing the credential store to get the run-as subject.
Below is the fragment of my geronimo-application.xml where I define the
security policy:
{code:xml}
security:security
security:credential-store
security:pattern
sys:name
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;MyCredentialStore/sys:name
/security:pattern
/security:credential-store
security:role-mappings
security:role role-name=TESTSYSTEM
security:run-as-subject
security:realmTestingRealm/security:realm
security:idtest-system/security:id
/security:run-as-subject
security:realm realm-name=TestingRealm
security:principal
class=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal
name=TESTSYSTEM /
/security:realm
/security:role
/security:role-mappings
/security:security
sys:gbean name=TestingRealm
class=org.apache.geronimo.security.realm.GenericSecurityRealm
sys:attribute name=realmNameTestingRealm/sys:attribute
sys:reference name=ServerInfo
sys:nameServerInfo/sys:name
/sys:reference
sys:xml-reference name=LoginModuleConfiguration
log:login-config
xmlns:log=http://geronimo.apache.org/xml/ns/loginconfig-2.0;
log:login-module control-flag=REQUIRED
wrap-principals=false
log:login-domain-nameTestingRealm/log:login-domain-name
log:login-module-classcom.testing.security.TestingLoginModule/log:login-module-class
log:option name=userSelectSELECT username, password FROM
utl_user WHERE username=?/log:option
log:option
name=dataSourceApplicationMxi/Testing/1/ear/log:option
log:option name=groupSelectSELECT name, 'TESTSYSTEM' as
role_name FROM dual/log:option
log:option
name=dataSourceNamecom/testing/jdbc/TestDS/log:option
/log:login-module
/log:login-config
/sys:xml-reference
/sys:gbean
sys:gbean name=MyCredentialStore
class=org.apache.geronimo.security.credentialstore.SimpleCredentialStoreImpl
xml-attribute name=credentialStore
credential-store
xmlns=http://geronimo.apache.org/xml/ns/credentialstore-1.0;
!-- uncomment this and the default subject in the jettty
console plan gives you admin console permissions --
realm name=TestingRealm
subject
idtest-system/id
credential
typeorg.apache.geronimo.security.credentialstore.NameCallbackHandler/type
valueananner/value
/credential
credential
typeorg.apache.geronimo.security.credentialstore.PasswordCallbackHandler/type
valuepassword/value
/credential
/subject
/realm
/credential-store
/xml-attribute
/sys:gbean
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release specs for JACC, JSP, Servlet
+1 ... good job On Jul 30, 2007, at 10:04 PM, Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 The corresponding tar files are here: http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz The current svn locations are here: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- servlet_2.5_spec-1.1 The future svn locations will be here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- servlet_2.5_spec-1.1 The vote will conclude at 10:00 PM EST on Thursday, August 2nd. -- Thanks, Tim McConnell
Re: [VOTE] Release specs for JACC, JSP, Servlet
+1 Tim McConnell wrote: Hi, Please review and vote on the release of the following Geronimo specs: -- geronimo-jacc_1.1_spec-1.0 -- geronimo-jsp_2.1_spec-1.0 -- geronimo-servlet_2.5_spec-1.1 The corresponding tar files are here: http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz The current svn locations are here: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-servlet_2.5_spec-1.1 The future svn locations will be here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jacc_1.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsp_2.1_spec-1.0 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1 The vote will conclude at 10:00 PM EST on Thursday, August 2nd.
[VOTE] Release Genesis 1.2
Please review and vote on the Genesis release of 1.2. At this location you will find a tar ball with the repository and related artifacts that will be released. http://people.apache.org/~hogstrom/genesis-rc1 Branch with source is at https://svn.apache.org/repos/asf/geronimo/ genesis/branches/1.2/ [ ] +1 Release Genesis 1.2 [ ] 0 No opinion [ ] -1 Do not release this artifact (please provide reason Vote will complete at 2330 ET, August 3 2007.
Proposed Branch and Release Schedule for Geronimo 2.0
All, It looks like we're winding down and readying for the 2.0 release that is long awaited. I've been working on something at work for the last week that has kept me a little distracted from G so apologies if I missed something in a thread. There are lots of supporting elements that are being released. I saw Tim got some specs out and I'm working on Genesis and some of the Connector / Tx stuff that Jencks did. Assuming these votes succeed and the Law firm of Miller, Miller and Devoto don't find some odd file that we need or an extra one we don't it looks like we can spin up a 2.0 release for a vote later in the week. That in mind, I propose that we look to create the branches/2.0.0 release on thursday. This will be the final release and will undergo the fitting for a release and will not take code changes unless fixing a specific bug. the branches/2.0 will be updated to 2.0.1- SNAPSHOT and can continue the infusion of bug fixes, etc. Please have all your final fixes in branches/2.0 by Thursday morning Eastern time so we can branch and lock this monster down. So, the summary would be: 8/2 Branch branches/2.0 - branches/2.0.0 8/3 Spin up Geronimo RC 1 and start final TCK run (this will include inflight jars that votes expire on Friday). 8/7 Geronimo 2.0 is announced to the world and released 8/7 There is much excitement and rejoicing. If I missed something please chime in. Cheers.
Re: svn commit: r561635 - in /geronimo/genesis/tags/geronimo-txmanager-parent-2.0: ./ geronimo-connector/pom.xml geronimo-transaction/pom.xml pom.xml
Looks like the SCM section needs to be updated, so the tags get created in the right place in svn (under components/tags instead of genesis/tags) -Donald [EMAIL PROTECTED] wrote: Author: hogstrom Date: Tue Jul 31 20:50:47 2007 New Revision: 561635 URL: http://svn.apache.org/viewvc?view=revrev=561635 Log: [maven-scm] copy for tag geronimo-txmanager-parent-2.0 Added: geronimo/genesis/tags/geronimo-txmanager-parent-2.0/ - copied from r561633, geronimo/components/txmanager/trunk/ geronimo/genesis/tags/geronimo-txmanager-parent-2.0/geronimo-connector/pom.xml - copied unchanged from r561634, geronimo/components/txmanager/trunk/geronimo-connector/pom.xml geronimo/genesis/tags/geronimo-txmanager-parent-2.0/geronimo-transaction/pom.xml - copied unchanged from r561634, geronimo/components/txmanager/trunk/geronimo-transaction/pom.xml geronimo/genesis/tags/geronimo-txmanager-parent-2.0/pom.xml - copied unchanged from r561634, geronimo/components/txmanager/trunk/pom.xml smime.p7s Description: S/MIME Cryptographic Signature
