headers
Andrew Perepelytsya (JIRA | 2 Feb 2009 16:26

[mule-jira] Commented: (MULE-4002) Support Spring Security HTTP Channel Security


    [
http://www.mulesource.org/jira/browse/MULE-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28661#action_28661
] 

Andrew Perepelytsya commented on MULE-4002:
-------------------------------------------

My investigation showed that spring-security exhibits strong dependency on servlet's filter and
request classes in this area. Will need to rescope the issue, as it can't be used as a generic http security
config mechanism in Mule without having to use servlets.

> Support Spring Security HTTP Channel Security
> ---------------------------------------------
>
>                 Key: MULE-4002
>                 URL: http://www.mulesource.org/jira/browse/MULE-4002
>             Project: Mule
>          Issue Type: Improvement
>          Components: Modules: Security (Acegi, PGP, JAAS, others)
>            Reporter: Dan Diephouse
>            Assignee: Andrew Perepelytsya
>            Priority: Major
>             Fix For: ITR14, 2.x Product Backlog
>
>
> Background: users using RESTpack (or even just the http transport) need a way to secure their applications.
> Description: Users should be able to secure their applications based on URL patterns and by the HTTP
operation used (GET vs POST vs DELETE). Spring Security provides a mechanism to do this: http://static.springframework.org/spring-security/site/reference/html/ns-config.html#ns-requires-channel
> Acceptance criteria:
(Continue reading)

Permalink | Reply | 0 comments |
headers
D Henton (JIRA | 2 Feb 2009 19:50

[mule-jira] Commented: (MULE-4073) remoteSync set to true required for smtp transport to send mail


    [
http://www.mulesource.org/jira/browse/MULE-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28663#action_28663
] 

D Henton commented on MULE-4073:
--------------------------------

I've done some further work on this and found that the true requirement is not the REMOTE SYNC settings. All
of that is irrelevant. It turns out that the requirement for issuing the emails is SHUTTING DOWN THE MULE
INSTANCE. 

Turns out i turned off the mule instance (which occurs in the test case) and didn't try leaving it on.

Using the James mail server out of the box, logs from James indicate mule connects, but only releases the
content to the mail box when the mule instance is shut down. I don't know about you, but if this is the case
SMTP mail is unworkable in mule 2.x. Configurations are above, with or without the remotesync on the mail. 

This is my current test code:

=======================================

package com.mason.mule.mailer;

import org.mule.api.MuleContext;
import org.mule.api.MuleMessage;
import org.mule.config.spring.SpringXmlConfigurationBuilder;
import org.mule.context.DefaultMuleContextFactory;
import org.mule.module.client.MuleClient;
(Continue reading)

Permalink | Reply | 0 comments |
headers
D Henton (JIRA | 2 Feb 2009 22:32

[mule-jira] Commented: (MULE-4073) remoteSync set to true required for smtp transport to send mail


    [
http://www.mulesource.org/jira/browse/MULE-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28669#action_28669
] 

D Henton commented on MULE-4073:
--------------------------------

Turns out to have been an antivirus issue. Consider this one dead.

> remoteSync set to true required for smtp transport to send mail
> ---------------------------------------------------------------
>
>                 Key: MULE-4073
>                 URL: http://www.mulesource.org/jira/browse/MULE-4073
>             Project: Mule
>          Issue Type: Bug
>          Components: Core: Transports
>    Affects Versions: 2.1.1
>         Environment: windows XP, james mail server, exchange mail server
>            Reporter: D Henton
>            Priority: Major
>             Fix For: 2.1.x Backlog
>
>
> Successful routing of email to an email server with the attached configuration has an absolute
requirement for the remoteSync and synchronous settings as listed. 
> The configuration is lifted from the functional email testing resources of the full source of 2.1.2 . In 
that configuration both of those settings are absent.
> This has not been tested against greenway testing server. This may be an issue with how closely greenway
(Continue reading)

Permalink | Reply | 0 comments |
headers
Puneet Gupta (JIRA | 3 Feb 2009 02:26

[mule-jira] Created: (MULE-4136) #[map-payload:key*] expression evaluator does not return any values.

#[map-payload:key*] expression evaluator does not return any values.
--------------------------------------------------------------------

                 Key: MULE-4136
                 URL: http://www.mulesource.org/jira/browse/MULE-4136
             Project: Mule
          Issue Type: Bug
          Components: Core: Expressions
    Affects Versions: 2.2
         Environment: standalone
            Reporter: Puneet Gupta

If you configure a expression evaluator with a * suffix, the value is not returned.

--

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.mulesource.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 2 comments |
headers
Dan Diephouse (JIRA | 3 Feb 2009 02:28

[mule-jira] Closed: (MULE-3936) Integrate schema validation and JAXP XPath filters from Intel XML project


     [
http://www.mulesource.org/jira/browse/MULE-3936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Diephouse closed MULE-3936.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 2.2

This is now integrated and documented.

http://fisheye.codehaus.org/changelog/mule/?cs=13916
http://www.mulesource.org/display/MULE2USER/XML+Module (see xpath extractor, xpath filter, and
schema validation filter)

> Integrate schema validation and JAXP XPath filters from Intel XML project
> -------------------------------------------------------------------------
>
>                 Key: MULE-3936
>                 URL: http://www.mulesource.org/jira/browse/MULE-3936
>             Project: Mule
>          Issue Type: Improvement
>          Components: Modules: XML, XSLT, XPath
>            Reporter: Dan Diephouse
>            Assignee: Dan Diephouse
>            Priority: Major
>             Fix For: ITR14, 2.2, 2.x Product Backlog
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Diephouse (JIRA | 3 Feb 2009 02:57

[mule-jira] Commented: (MULE-4122) Consider changing Filter Spring beans scope from prototype to singleton


    [
http://www.mulesource.org/jira/browse/MULE-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28671#action_28671
] 

Dan Diephouse commented on MULE-4122:
-------------------------------------

Can we wait until Dan F gets back later this week to fix this issue? He implemented the hashCode stuff for a
reason which I don't fully understand. I'd like to slim down what goes into the hashCode() to fix this
issue, but I'd like to run it by him first.

> Consider changing Filter Spring beans scope from prototype to singleton
> -----------------------------------------------------------------------
>
>                 Key: MULE-4122
>                 URL: http://www.mulesource.org/jira/browse/MULE-4122
>             Project: Mule
>          Issue Type: Improvement
>          Components: Core: Routing / Filters
>    Affects Versions: 2.1.2
>            Reporter: David Dossot
>            Priority: Blocker
>             Fix For: ITR14, 2.x Product Backlog
>
>
> I had an interesting issue with the attached configuration leading to AbstractConnector.requesters
pool constantly growing, with no object being reused ever.
> I have tracked the problem in AbstractEndpoint.hashCode() which combines the hashcode of different
related objects into one. The endpoint filter is one of these objects. Because the filter objects are by
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Dossot (JIRA | 3 Feb 2009 08:04

[mule-jira] Created: (MULE-4137) Log4jNotificationLoggerAgent is useless

Log4jNotificationLoggerAgent is useless
---------------------------------------

                 Key: MULE-4137
                 URL: http://www.mulesource.org/jira/browse/MULE-4137
             Project: Mule
          Issue Type: Bug
          Components: Core: Agents
    Affects Versions: 2.1.2
            Reporter: David Dossot

I don't see how its private attribute eventLogger could be something else than null with the big chunk of
code commented out in doInitialise.

Because it is null, logEvent does nothing.

Could it be possible to uncomment these lines, until the OSGi/PAX quagmire is sorted out:

        else
        {
                /* ... */

                eventLogger = Logger.getLogger(logName);

                /* ... */              
        }

so at least a logger will be active?

PS. That would also call for a review of getDescription, which does not acknowledge the fact a non-blank
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jammart Raphaël (JIRA | 3 Feb 2009 08:36

[mule-jira] Commented: (MULE-3433) file connector ignores custom messageReceiver defined in service-overrides, when file endpoint is used with quartz endpoint


    [
http://www.mulesource.org/jira/browse/MULE-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28672#action_28672
] 

Jammart Raphaël commented on MULE-3433:
---------------------------------------

The problem is not limited on messageReceiver. 
For example, considering file endpoint, each nested tag is ignored when the endpoint is referenced by
quartz job endpoint:

<!-- FILE CONNECTORS -->
	<file:connector name="initialfilePollingConnector" moveToDirectory="${scandirectory.tmp}"
streaming="true" moveToPattern="#[ORIGINALNAME]" autoDelete="true"
fileAge="${initial.file.fileAge}" pollingFrequency="2000">
	</file:connector>

<!-- GLOBAL ENDPOINT DEFINITIONS -->
	
	<file:endpoint name="initialFilePollingEndPoint" path="${scandirectory.in}"
		connector-ref="initialfilePollingConnector">
		<file:filename-wildcard-filter pattern="*.pdf" />
	</file:endpoint>

<inbound>
				<quartz:inbound-endpoint name="initialPollingEndpoint"
					cronExpression="${initial.file.polling.frequency.cronexpression}"
					jobName="initialFilePollingQuartzJob" connector-ref="quartzConn" synchronous="true">					
					<quartz:endpoint-polling-job>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jammart Raphaël (JIRA | 3 Feb 2009 08:52

[mule-jira] Commented: (MULE-3433) file connector ignores custom messageReceiver defined in service-overrides, when file endpoint is used with quartz endpoint


    [
http://www.mulesource.org/jira/browse/MULE-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28673#action_28673
] 

Jammart Raphaël commented on MULE-3433:
---------------------------------------

In the previous example, the filename wildcard filter is ignored. 
If the file endpoint is used alone (not referenced in the quartz endpoind) the filter is applied.

I encounter the same problem if i try to define a custom filename parser in the file connector like this:

<file:connector name="initialfilePollingConnector"
		moveToDirectory="${scandirectory.tmp}" streaming="true"
	    autoDelete="true" fileAge="${initial.file.fileAge}" pollingFrequency="2000">
	    <file:custom-filename-parser class="com.xx.yy.zz.OriginalFileNameParser"/>
</file:connector>

The OriginalFileNameParser is not applied when the file connector is used with the quartz connector.

> file connector ignores custom messageReceiver defined in service-overrides, when file endpoint is
used with quartz endpoint
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MULE-3433
>                 URL: http://www.mulesource.org/jira/browse/MULE-3433
>             Project: Mule
>          Issue Type: Bug
>          Components: Transport: Quartz
(Continue reading)

Permalink | Reply | 0 comments |
headers
chewygumstix | 3 Feb 2009 16:06
Favicon

spring-context-2.5.xsd not valid


I'm new to Mule so there's probably a simple explanation for this.

I've created a very simple Mule config file (
http://www.nabble.com/file/p21811683/hello-config.xml hello-config.xml ).
I'm using XMLSpy to edit all of XML files and when I save this example I get
the following error messages. (
http://www.nabble.com/file/p21811683/errors.txt errors.txt ).

The error is reported for line 3 of spring-context-2.5.xsd:
<xsd:import namespace="http://www.springframework.org/schema/beans"/>

I can proceed and save the file and Mule runs fine, but I'd really like to
understand why these errors are being reported.

Thanks!
--

-- 
View this message in context: http://www.nabble.com/spring-context-2.5.xsd-not-valid-tp21811683p21811683.html
Sent from the Mule - Issues mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 1 comment |

Gmane