Re: Securing the Derby Network Server in Geronimo - related to GERONIMO-342
Jeremy Boynes [EMAIL PROTECTED] wrote on 31/01/2005 10:33:58 AM: [EMAIL PROTECTED] wrote: Derby's DRDA (Distributed Relational Database Architecture) Network Server by default only listens for connections on the loopback address (which is a good default) and does not have authentication turned on. Therefore on a multiuser O/S this level of security seems inadequate as any user on the localhost could connect to it using the DB2 Universal Connector (specifying any userid and password as it will be ignored by the server) and start creating databases/tables etc. Hmm - I thought that a username and password had to be supplied for a network connection. Yes, the IBM JCC driver forces you to specify a userid and password, but the username and password is only validated on the server if authentication is turned on. By default authentication is turned off. Also the username is used as the current schema for the connection. See: http://incubator.apache.org/derby/manuals/develop/develop97.html Also for authorization, by default users are given read/write access (fullAccess) : http://incubator.apache.org/derby/manuals/develop/develop109.html John Q1. Are there any plans on how a default Geronimo configuration would secure the embedded Derby Network Server? At the moment we are relying on Derby database security. Ultimately I hope to integrate that into the JACC authentication providers used by the rest of the container, and have a dream at some point of integrating Derby's authorization with the JACC policy provider. Q2. What would be the best way to restrict the remote IP addresses that Derby will accept connections from (e.g. particular IP addresses)? Should a policy file be used and passed to the JVM when starting Geronimo (see http://incubator.apache.org/derby/manuals/admin/hubprnt30.html ) or is there a better way for Geronimo? I haven't looked at that. Q3. Should we have some simple authentication enabled by shipping a sample geronimo\var\derby\derby.properties file that has something like the following? # #Security settings # derby.connection.requireAuthentication=true derby.authentication.provider=BUILTIN # # User and password list for Derby BUILTIN authentication provider # derby.user.system=manager derby.user.myapp=myapppswd I would prefer not to and at least integrate with the user/password realm we use for securing JMX remoting - that would mean in the default case the usernames/passwords would be the same. Of course, an admin could also set up a separate realm for the database. -- Jeremy
[jira] Commented: (GERONIMO-546) web service client xsd has been modified... change it back
[ http://issues.apache.org/jira/browse/GERONIMO-546?page=comments#action_58289 ] Bruce Snyder commented on GERONIMO-546: --- Upon further investigation, I figured out that the j2ee_1_4.xsd includes the j2ee_web_services_client_1_1.xsd. Running the j2ee_1_4.xsd through the Castor Source Generator works just fine. web service client xsd has been modified... change it back -- Key: GERONIMO-546 URL: http://issues.apache.org/jira/browse/GERONIMO-546 Project: Apache Geronimo Type: Bug Components: deployment Versions: 1.0-M3 Reporter: David Jencks Assignee: David Jencks in revision 125988 I commented out a key/uniqueness constraint in modules/j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd that xmlbeans 1.0 cannot deal with. After switching to xmlbeans 2 this change should be reverted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-559) NullPointerException if config attribute is not passed on deploy:startRemoteServer goal
NullPointerException if config attribute is not passed on
deploy:startRemoteServer goal
---
Key: GERONIMO-559
URL: http://issues.apache.org/jira/browse/GERONIMO-559
Project: Apache Geronimo
Type: Bug
Reporter: John Sisson
Priority: Minor
Attachments: StartRemoteServer.diff
NullPointerException if config attribute is not passed on
deploy:startRemoteServer goal.
For example, the following will fail:
deploy:startRemoteServer geronimoTarget=${maven.build.dir}/geronimo
/
java.lang.NullPointerException
at java.util.StringTokenizer.init(StringTokenizer.java:146)
at java.util.StringTokenizer.init(StringTokenizer.java:176)
at
org.apache.geronimo.deployment.mavenplugin.StartRemoteServer.execute(StartRemoteServer.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-559) NullPointerException if config attribute is not passed on deploy:startRemoteServer goal
[ http://issues.apache.org/jira/browse/GERONIMO-559?page=history ]
John Sisson updated GERONIMO-559:
-
Attachment: StartRemoteServer.diff
Patch
geronimo\plugins\maven-geronimo-plugin\src\java\org\apache\geronimo\deployment\mavenplugin\StartRemoteServer.java
so that it checks whether config is not null before trying to pass it to the
StringTokenizer.
NullPointerException if config attribute is not passed on
deploy:startRemoteServer goal
---
Key: GERONIMO-559
URL: http://issues.apache.org/jira/browse/GERONIMO-559
Project: Apache Geronimo
Type: Bug
Reporter: John Sisson
Priority: Minor
Attachments: StartRemoteServer.diff
NullPointerException if config attribute is not passed on
deploy:startRemoteServer goal.
For example, the following will fail:
deploy:startRemoteServer
geronimoTarget=${maven.build.dir}/geronimo /
java.lang.NullPointerException
at java.util.StringTokenizer.init(StringTokenizer.java:146)
at java.util.StringTokenizer.init(StringTokenizer.java:176)
at
org.apache.geronimo.deployment.mavenplugin.StartRemoteServer.execute(StartRemoteServer.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-559) NullPointerException if config attribute is not passed on deploy:startRemoteServer goal
[ http://issues.apache.org/jira/browse/GERONIMO-559?page=history ]
David Jencks reassigned GERONIMO-559:
-
Assign To: David Jencks
NullPointerException if config attribute is not passed on
deploy:startRemoteServer goal
---
Key: GERONIMO-559
URL: http://issues.apache.org/jira/browse/GERONIMO-559
Project: Apache Geronimo
Type: Bug
Reporter: John Sisson
Assignee: David Jencks
Priority: Minor
Fix For: 1.0-M4
Attachments: StartRemoteServer.diff
NullPointerException if config attribute is not passed on
deploy:startRemoteServer goal.
For example, the following will fail:
deploy:startRemoteServer
geronimoTarget=${maven.build.dir}/geronimo /
java.lang.NullPointerException
at java.util.StringTokenizer.init(StringTokenizer.java:146)
at java.util.StringTokenizer.init(StringTokenizer.java:176)
at
org.apache.geronimo.deployment.mavenplugin.StartRemoteServer.execute(StartRemoteServer.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-559) NullPointerException if config attribute is not passed on deploy:startRemoteServer goal
[ http://issues.apache.org/jira/browse/GERONIMO-559?page=history ]
David Jencks closed GERONIMO-559:
-
Resolution: Fixed
Fix Version: 1.0-M4
Applied in rev 149230. Thanks!
NullPointerException if config attribute is not passed on
deploy:startRemoteServer goal
---
Key: GERONIMO-559
URL: http://issues.apache.org/jira/browse/GERONIMO-559
Project: Apache Geronimo
Type: Bug
Reporter: John Sisson
Assignee: David Jencks
Priority: Minor
Fix For: 1.0-M4
Attachments: StartRemoteServer.diff
NullPointerException if config attribute is not passed on
deploy:startRemoteServer goal.
For example, the following will fail:
deploy:startRemoteServer
geronimoTarget=${maven.build.dir}/geronimo /
java.lang.NullPointerException
at java.util.StringTokenizer.init(StringTokenizer.java:146)
at java.util.StringTokenizer.init(StringTokenizer.java:176)
at
org.apache.geronimo.deployment.mavenplugin.StartRemoteServer.execute(StartRemoteServer.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: runtime vs builder, was: SpringApplicationImpl
OK - all understood - I will get back into the code today and tomorrow and try to sort this out. There may be a few more questions flying about later :-) Jules Jeremy Boynes wrote: Adding to what David said with some clarification of runtime vs. builder. The intention is that running systems contain only the stuff needed to actually run applications. They use a Geronimo kernel to load and manage Configurations, where each Configuration is a package of GBean instances and code (either directly or via repository dependencies). The GBeans are stored in a persisted offline form, currently by serializing their persistent attributes. The builders have the job of converting user-land artifacts such as J2EE modules (EARs, WARs, etc) or non-J2EE packagings (.SPR?) into Configurations that the runtime can use. A collection of builders bundled together forms a deployer. Deployers can run standalone - reading a module and spitting out a Configuration archive - or online (in-server) where they do the same thing but add the Configuration they built into the running system. The former mode is intended for production use where you would deploy once and then run the same Configuration in many places; the online mode is intended for development use where you just want the thing running as quickly as possible. If you look at the J2EE stuff, we have, for example, both jetty and jetty-builder. jetty is the runtime system containing the stuff used to bridge between GBeans and jetty containers; jetty-builder is the builder stuff used to convert a WAR into jetty GBeans. There would be a similar relationship between spring the runtime which bridged the Geronimo kernel and the Spring framework core, and spring-builder the thing that converted a .SPR module into a Configuration. A general rule is to do as much configuration work as possible in the builder - it means there is less chance of things failing at runtime, it means the runtime code is cleaner, it means you can do computationally expensive analysis of the module without impacting a production system (e.g. figuring out a transaction or security domain, pre-compiling queries, parsing validating XML, building interceptor stacks ...) Finally, it would be good if you can separate the Spring configuration from the J2EE one completely - it would then be possible to have a server that dealt with Spring applications natively without needing all that elephantine J2EE baggage :-) -- Jeremy David Jencks wrote: On Jan 28, 2005, at 3:39 PM, Jules Gosnell wrote: Jeremy Boynes wrote: From the source: // I know that this should not be here (in the j2ee package) but, // until someone who knows what they are doing has time to have a look // at it, this seems the path of least resistance... Move to the spring module? -- Jeremy spring - or spring-builder ? Definitely spring. spring-builder generally won't be available in running systems, only in ones that happen to have online deployment configured. I tried it in the spring-builder jar (I'm not using the spring module), but, in org.apache.geronimo.gbean.runtime.GBeanInstance one of the ctors does this : type = classLoader.loadClass(gbeanInfo.getClassName()); org.apache.geronimo.j2ee.management.impl.* must be in a classloader that is accessible to this code, whereas org.apache.geronimo.spring.deployment.* did not seem to be - it could never find the class. I just wanted the thing working quickly, so I chose the path of least resistance. I will revisit this soon. You don't want the builders in any classpath that is needed only by the running system. So, if you include via dependency the spring builder in j2ee-deployer-plan and runtime-deployer-plan, don't include it anywhere else. Assuming you come up with stuff in the spring module, that would presumably be included as a dependency in the j2ee-server-plan which should make it available to the code above. (actually just making sure the parentId chain of the module you are deploying includes the spring module should work) Deployment types seem to be a closed set that have to be known to Geronimo at build time (see org.apache.geronimo.kernel.config.ConfigurationModuleType). So I decided that since the system was already so tightly coupled another temporary coupling would not be so harmful ;-) - I thought about not putting it in the j2ee package and creating another one, but decided that that would just create more mess. I shall just have to try a few alternatives and give you guys a shortlist of solutions so that you can pick one... BTW - I also had to hack the SPRDeployer config into the j2ee-runtime-deployer-plan.xml - sorry. Deployers seem to be collected up using a wildcarded ObjectName and if yours is not around at the time, you miss the bus... - perhaps I could move it back into the spring-deployer-plan.xml and force its loading before this happens - it was late when I checked all this in This should
Re: problem with axis/xerces and web apps
Thanks for your help, David. I got things working, but it took a fair bit of messing around. It seems that Axis really likes to be loaded by the same classloader as the code that it's working with. For example, when I used the Axis that's built into Geronimo I got Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.axis.utils.BeanPropertyDescriptor.set(BeanPropertyDescriptor.java:117) ... when Axis tried to load one of my classes (which are in the war file). This looks like a similar problem to the Xerces problem that started this thread (i.e. can't load a class using the context classloader and then cast it). So in the end I've got Axis and Castor in the war file, and context-priority-classloader=true and that works for me. I'm using Geronimo's commons-logging and commons-discovery, however. Can I ask about something? It seems from the comments on http://wiki.apache.org/geronimo/Deployment#head-754164850f38c1ecdaf6b8ed894cb192bc36c5f4-2 and the default false value of context-priority-classloader that Geronimo's preferred configuration is to load classes from the container-wide classloader first, then the war file classloader. In the Servlet spec it's recommended that classes be loaded from the war first. Is this a case where you guys think that the spec is off-base or just an oversight? It doesn't really matter since it's a recommendation rather than a requirement, but it would be cool if Geronimo's default could follow the spec's recommendation. Again, thanks for your help on this, Toby
Jonas...
http://news.com.com/Open-source+software+gets+J2EE+nod/2110-7344_3 -5557582.html?part=rsstag=5557582subj=news.7344.5 -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
http://jonas.objectweb.org/
http://jonas.objectweb.org/ Lets catch them... -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Created: (GERONIMO-560) MailcapCommandMap.getCommand() should handle wildcards
MailcapCommandMap.getCommand() should handle wildcards -- Key: GERONIMO-560 URL: http://issues.apache.org/jira/browse/GERONIMO-560 Project: Apache Geronimo Type: Bug Components: specs Reporter: Jeremy Boynes Assigned to: Jeremy Boynes The pattern matching for getCommand() is too strict. RFC1524 allows mailcap files with wildcard mime types e.g. multipart/related multipart/* multipart I'm not clear on exactly how multiple mappings get resolved but right now we match directly which is too strict. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-560) MailcapCommandMap.getCommand() should handle wildcards
[ http://issues.apache.org/jira/browse/GERONIMO-560?page=history ] Jeremy Boynes resolved GERONIMO-560: Resolution: Fixed Support implicit and explicit wildcards Also we now strip parameters from the mimeType we are looking up MailcapCommandMap.getCommand() should handle wildcards -- Key: GERONIMO-560 URL: http://issues.apache.org/jira/browse/GERONIMO-560 Project: Apache Geronimo Type: Bug Components: specs Reporter: Jeremy Boynes Assignee: Jeremy Boynes The pattern matching for getCommand() is too strict. RFC1524 allows mailcap files with wildcard mime types e.g. multipart/related multipart/* multipart I'm not clear on exactly how multiple mappings get resolved but right now we match directly which is too strict. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-560) MailcapCommandMap.getCommand() should handle wildcards
[ http://issues.apache.org/jira/browse/GERONIMO-560?page=comments#action_58337 ] Jeremy Boynes commented on GERONIMO-560: Fixed rev 149311 and 149312 MailcapCommandMap.getCommand() should handle wildcards -- Key: GERONIMO-560 URL: http://issues.apache.org/jira/browse/GERONIMO-560 Project: Apache Geronimo Type: Bug Components: specs Reporter: Jeremy Boynes Assignee: Jeremy Boynes The pattern matching for getCommand() is too strict. RFC1524 allows mailcap files with wildcard mime types e.g. multipart/related multipart/* multipart I'm not clear on exactly how multiple mappings get resolved but right now we match directly which is too strict. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-560) MailcapCommandMap.getCommand() should handle wildcards
[ http://issues.apache.org/jira/browse/GERONIMO-560?page=history ] Jeremy Boynes closed GERONIMO-560: -- Been told it works :-) MailcapCommandMap.getCommand() should handle wildcards -- Key: GERONIMO-560 URL: http://issues.apache.org/jira/browse/GERONIMO-560 Project: Apache Geronimo Type: Bug Components: specs Reporter: Jeremy Boynes Assignee: Jeremy Boynes The pattern matching for getCommand() is too strict. RFC1524 allows mailcap files with wildcard mime types e.g. multipart/related multipart/* multipart I'm not clear on exactly how multiple mappings get resolved but right now we match directly which is too strict. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
