Hi all,
today I tried to build synapse and got the following error during test
execution:
org.apache.maven.surefire.booter.SurefireExecutionException: Unable to instantia
te POJO 'class org.apache.synapse.transport.mail.TestFolder'; nested exception i
s java.lang.InstantiationException: org.ap
[mailto:[EMAIL PROTECTED]
Gesendet: Di 06.05.2008 01:19
An: dev@synapse.apache.org
Betreff: Re: Build problem
Eric,
I corrected the problem yesterday (SVN revision 653167) by adding an
exclusion pattern. What sources do you use to build Synapse?
Andreas
On 06 May 2008, at 00:46, Hubert, Eric
Hi Ruwan,
as I was at home, your assumption has been correct. I was using
Windows... Ok, I validated this now at work... of course I also used a
Windows machine for this test now. Works like a charm.
Thanks,
Eric
From: Ruwan Linton [mailto:[EMAIL PR
Hi all,
trying to build synapse 1.2 branch including execution of unit tests I receive
the following errors:
Tests in error:
testThreadSafety(org.apache.synapse.mediators.bsf.ScriptMediatorTest)
testThreadSafety(org.apache.synapse.mediators.bsf.ScriptMediatorTest)
[...]
testThreadSafe
Hi Asankha,
thanks for you hint. Switching to Java 5 did the trick. I already have a small
wrapper script around maven and can easily switch between different
environments for building. I just didn't know the limitation of BSF and that I
have to use Java 5. Thanks for that info!
Regards,
E
Hi all,
at least on Windows (but I guess the same applies to Unix) the
SynapseCommodityServiceTest is broken. I suspect this is due to the following
change in ServerManager:
public void setSynapseXMLPath(String synapseXMLPath) {
-this.synapseXMLPath = synapseXMLPath;
+if
does not take place as the
test uses its own "bootstrap" code to start the needed transports for the test.
Atleast this is my understanding.
Regards,
Eric
Hi Eric/Asankha,
I just checked the code,
On Fri, May 16, 2008 at 5:29 AM, Hubert, Er
Hi Asankha,
> Can you get an update of Synapse, I've fixed this issue caused
> by my fault..
No problem, it is working fine now.
Regards,
Eric
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [E
Hi Synapse Devs,
is there a way to split the synapse configuration into several files? Our plan
is to include some generated fragments. Relative paths should be used.
Is the only way to achieve this to register a custom entityresolver to the
xmlparserconfiguration? One way could be to extend th
Hi Asankha,
> > is there a way to split the synapse configuration into several
files?
> Our plan is to include some generated fragments. Relative paths should
be
> used.
> >
> Are you suggesting, or looking for a way, to dynamically discover the
> full configuration to be applied, looking at a bun
Hi,
how can we send back a fault from an in-sequence? Regarding the Hessian
support, is there a way to generate a Hessian fault?
Background:
1) In a switch mediator within the in-sequence we want to send back a
fault for the default case and log this.
2) If the requested URL does not match with
Hi Ruwan,
ok, sounds good. I'm not aware of something well known and widely used which
uses port 8243. So I'm +1 on this. ;-)
Ooopppseee, I just realized that I missed the dev list from my original reply,
Cc:ing dev list
Thanks,
Ruwan
On Fri, May 23, 2008 a
ation;
On Thu, May 22, 2008 at 9:21 PM, Ruwan Linton <[EMAIL PROTECTED]>
wrote:
Hi Eric,
Please see my comments in line;
On Thu, May 22, 2008 at 8:53 PM, Hubert, Eric <[EMAIL PROTECTED]>
wrote:
Hi,
how can we send back a fault from an in-sequence? Regarding the Hessian
support,
end back a fault from an in-sequence
Hi Eric,
I just tried the sample 352 and was working fine for me. May be this is
a scripting problem.
Are you using some other scripting jar than what we ship with
Synapse/ESB?
Thanks,
Ruwan
On Fri, May 23, 2008 at 1:43 PM, Hubert, Eric <[EMAIL PROTECTED
find them out and fix them.
Thanks,
Ruwan
On Fri, May 23, 2008 at 3:40 PM, Hubert, Eric <[EMAIL PROTECTED]>
wrote:
Hi Ruwan,
Thanks for your cross test! No, we didn't change any of the libraries.
If I find the time, I'll try the sample on my own and contact the
developer
ongly suggest you to go with the existing
mediators and if there are any issues lets find them out and fix them.
Thanks,
Ruwan
On Fri, May 23, 2008 at 3:40 PM, Hubert, Eric
<[EMAIL PROTECTED]> wrote:
Fri, May 23, 2008 at 4:30 PM, Hubert, Eric
<[EMAIL PROTECTED]> wrote:
Hi Ruwan,
this is only a missunderstanding. Of course we will try
to go the way you suggested. There is no special requirement to use the
script mediator here.
e could you please try the sample 5 and see what
happens?
Thanks,
Ruwan
On Fri, May 23, 2008 at 8:30 PM, Hubert, Eric
<[EMAIL PROTECTED]> wrote:
Hi Ruwan,
I now tried this approach with th
Hi all,
today I would like to discuss some options to improve the load balancing
support of Apache Synapse. As not all of my ideas have settled, I may
miss some pieces of the current implementation and would like to get
some feedback about my ideas, I decided to not create a JIRA for that
immediat
Hi Azeez,
your explanations sounds reasonable to me. I also like the idea of renaming
your proposal from intelligentLoadbalance to something like dynamicLoadbalance
as this describes the way in which the actual members of the LB group are
discovered. The algorithm is responsible for the actual
Hi Rajith,
it is not much about newer application servers. In fact it is a requirement of
the Java EE specification. In the Java EE 1.3 spec it was only forbidden in the
EJB container, if I'm not wrong. At least the wording had not been very strict
on this. Since J2EE 1.4 all J2EE/JEE servers
Hi devs!
first of all I'd like to apologize for posting a "user-problem" to two
dev-lists. I only did this as have not much background knowledge of the NIO
implementation and think a solid understanding of NIO is necessary to help
tackling our problem.
We are using the WSO2 ESB which is based
Oleg,
thanks a lot for your reply! Please see my comments inline!
> > The problem is I don't understand the cause of this exception. It occurs
> during the read on a Socket-Channel. So I think the server might close the
> connection while the ESB is reading. But maybe internally some kind of
> po
Hi Asankha,
thanks for your reply as well! Please see my comments below!
> One thing you could analyze is the TCP socket timeout times in the
> different environments..
Hmm, TCP socket timeout should be the same, but I will investigate.
Also our response times are pretty low. Average of 10-15 ms
Hi Asankha,
> I think this is a good idea.. as we will close the session on our own
> without an exception, and then BEA can close it from that side
Ok, then I will go ahead and try this out. Is there a way to check
whether this property has been applied properly by Synapse? Some
JMX-monitoring
Hi all,
unfortunately decreasing the synapse (nhttp) socket timeout to 25000 ms did not
change anything to the current situation. I'm also thinking about what may be
the difference between Hessain and SOAP in this regard.
Reading RFC 2068 Appendix 19.7:
"However, a persistent connection wit
Hi all,
I think you remember that I already brought up the exact same idea. So, I'm +1
on this. I guess that is one think a lot of users are doing when they start
getting more familiar with Synapse. That's why I think changing the defaults
makes perfectly sense.
Regards,
Eric
PS (offtop
Hi all,
sounds like an interersting idea. We actually define it in exactly that
way on an endpoint level in our custom "repository" and generate a
synapse.xml containing the property mediator to set this property. It
would be more straightforward to be able to set this at the endpoint
level. Th
Hi devs,
we are facing an issue in Apache Synapse where HttpClientWorkers are in
the process of writing a response back to the client using
HttpCoreNIOSender.sendAsyncResponse(), but are then waiting at
org.apache.http.nio.util.SharedOutputBuffer.flushContent() to get
notified by someone...
I'd l
Hi Oleg,
Thanks for your reply, which already helped me a little bit to improve my
understanding.
> I am very sorry but we currently have almost nothing in terms of
> documentation for HttpCore. I am planning to start working on an
> HttpCore tutorial in August.
Oh yes, a tutorial would be very
Hi,
yes, marking a fault as a response by default sounds also reasonable to
me. If there are really cases where this is not what you want, you can
simply leave the code as it is, but just initialize the markAsResponse
to true by default so the user would only need to configure something if
he w
Hi all,
I have also noticed the exact same exception, but it only rarely occurs in our
environment. Since June I find it about 20 times spread around 3 different
servers. Last occurrence has been on August 11. I tried to reproduce this but
had no luck. As we are currently “hunting” bigger pr
Hi Oleg,
> > just wanted to ask you what are your plans for releasing HttpCore
4.0
> beta3?
> >
> > Do you plan to release it any time soon?
> >
> > Regards,
> >Eric
> I try to make sure there is a release every three months or so. End of
> September or mid October would be the next planned re
Hi Andreas,
> For the transports in Synapse it would imply splitting up the
> synapse-transports module into several Maven modules. Maybe the first
> step is to get rid of the dependencies in Synapse's master POM and
> declare them at module level as we discussed sime time ago in SYNAPSE-396.
Fro
> IDE based debugging is kinda painful to setup, isn't using JDB
(command line)
> as stated above easier? I'd like to have an opinion on this.
Hmm, maybe I misunderstand something regarding "IDE based debugging",
but any IDE I'm aware of supports remote debugging. And it is very easy
to setup. So
Hi all,
+1 for releasing Synapse 1.3 anytime soon.
We have seen a lot of critical bug fixes as well as nice improvements during
the last couple of months which we should share with the community.
> be a good time to also visit the open JIRA's and see what else are on
> the high priority list..
>> Security.setProperty("networkaddress.cache.ttl", myValue1);
>> Security.setProperty("networkaddress.cache.negative.ttl", myValue2);
> So I believe you do not want to set this to a specific hard coded value in >
> the startup scripts?
Yes Asankha, you are right with your assumption. :-) Set
Hi all,
before asking a question regarding the existing API, I'd like to mention the
targeted use case (requirement):
Detect/count application level faults passed from the service over Synapse to
the client independent of the application level protocol (e.g. SOAP/Hessian)
used on top of the tra
Hi Asankha,
thanks for your detailed and very helpful reply. Please find my comments
inline!
> MessageContext.isFaultResponse()
> This seems like a left over and unused/unwanted API method that we
need
> to clean up.. I would consider a cleanup along with the move of the
core
> API's into a separ
Hi Synapse-Devs,
Since more than a year I've been actively following the Synapse users and dev
mailings lists. Some of you may have also noticed my efforts to improve Synapse
from a user's perspective by reporting bugs and submitting feature requests
including implementation ideas and minor cod
nto a success product.
Thanks,
Ruwan
On Mon, Mar 9, 2009 at 3:55 AM, Hubert, Eric wrote:
Hi Synapse-Devs,
Since more than a year I've been actively following the Synapse users and dev
mailings lists. Some of you may have also noticed my efforts to improve Synapse
from a user's
Hi all,
> This is great news.. I truly appreciate all your help in the past to
> improve the NIO transport, endpoints and JMX support
Thanks for the positive feedback!
> Do you have any specific JDK 6 stuff in mind? The main issue I see is
> with the BSF mediator.. but I would still like to cont
Hi all,
while developing and testing the fault detection in the HessianMessageBuilder
I'll noticed that I had to change our custom developed code.
The question is whether the code we use is considered part of the API of
Synapse or not.
AbstractmediatorFactory once exposed a protected method c
> I prefer to support the compatibility.. I've myself encountered this
> issue when developing custom mediators.. In future, we should always try
> to deprecate old methods and then delete them in the next major version
>
> So +1 for your patch.. you will need to attach it to a JIRA to grant the
>
Hi Andreas,
> No, basically the code would take an OMElement and return a Reader
> that represents the text content of that element. It would take care
> of doing this in an optimal way (constant memory usage and minimal
> usage of intermediate buffers), i.e. it would provide the same
> functional
Hi all,
Today I stumbled over an issue with a misconfiguration in synapse.xml.
A loadbalancing group did not contain any endpoints.
Currently this case is not handled in the code very nicely.
If the send mediator is used with the load balancing group, the client
does not get a response and block
> > Two solutions would be acceptable to me:
> > a) The ESB does not start if a load balancing group is empty and output
> > the name(s) of the empty laodbalance groups. This approach might cause
> > compatibility issues with existing (mis)configurations. Also unused
> > configuration parts would c
Indika,
> I may wrong but state full means outcome of the current request may be
> depend on what previous requests did. If it is session ware, then it
> depends on previous requests on the current session. Keeping life
> cycle state (initialized, destroyed), not relate with above thing.
I agree
Hi Synapse-Devs,
While having a look at the AbstractMediator class I noticed all the deprecated
methods. From my perspective deprecating methods to keep backward compatibility
is generally a good thing. Unfortunately you didn't use the @deprecated
JavaDoc-Tag to provide information about the re
Many thanks Andreas!
> Good point. I've modified the Javadoc to include the relevant @deprecated
> tags.
Now reading the JavaDoc everything is clear.
Indika,
Are we currently missing a core dependency for jline?
Something like:
jline
jline
0.9.94
Or did I make a mistake in updating some pom?
Regards,
Eric
dika kumara [mailto:indika.k...@gmail.com]
> Sent: Saturday, March 14, 2009 4:48 PM
> To: dev@synapse.apache.org
> Subject: Re: jline
>
> Eric
>
> I just checked . I didn't get build issue.
>
> Thanks
> Indika
>
> On Sat, Mar 14, 2009 at 7:53 PM, Hubert, Eric
>
Hi Andreas,
> Is it possible to tell Findbugs and/or PMD to ignore specific false
> positives using annotations (either Javadoc style or Java 5)?
Sorry, I completely forgot to answer this question. In addition to specifying a
specific ruleset it is possible to deactivate a rule in a specific cont
> HessianMessageFormatter/Builder could be improved and test cases added
>
>
> [ https://issues.apache.org/jira/browse/SYNAPSE-
> 517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Asankha C. Perera resolved SYNAPSE-517.
> ---
>
Hi all,
if someone wants to use the FaultMediator in conjunction with Hessian messages
he has to know that he to set the HTTP status code to 200, after using the
FaultMediator and before using the SendMediator.
Normally (for SOAP messages) the HTTP status code is 500, but Ruwan once
created a
possible approach that we
can take, may be we could add this bit of logic to the Fault mediator
because that is a mediator but not the core of synapse, so the fault
mediator is aware of the hessian protocol.
Thanks,
Ruwan
On Sat, Mar 14, 2009 at 11:43 PM, Hubert, Eric
wrote:
Hi all,
if someone
I thought it might be useful for discussion to also have some sample code to
illustrate b).
Please find attached a quick implementation showing the idea.
Regards,
Eric
> Hi all,
>
> if someone wants to use the FaultMediator in conjunction with Hessian
> messages he has to know that he to
> For two reasons:
>
> 1. Message formatters should be protocol independent (even if they
> have access to the full MessageContext).
This is currently not the case. Whereas the rest of Synapse is totally
unaware of any Hessian specifics, the Hessian Builder/Formatter pair is
actually the protocol
le? Hmmm, seems to be the wrong list to ask this, but actually Synapse is
currently very tightly coupled with Axis2.
I hope someone more knowledgeable can comment on this idea.
Regards,
Eric
>
> Andreas
>
> On Sun, Mar 15, 2009 at 00:11, Hubert, Eric
> wrote:
> > I t
> >> 1. Message formatters should be protocol independent (even if they
> >> have access to the full MessageContext).
> >
> > This is currently not the case. Whereas the rest of Synapse is totally
> > unaware of any Hessian specifics, the Hessian Builder/Formatter pair is
> > actually the protocol
ation from hessian any other. (though this is not possible for the
moment because the hessian message builder keeps the binary message as it is
and is not going to build the message).
Thanks,
Ruwan
On Mon, Mar 16, 2009 at 1:31 AM, Andreas Veithen
wrote:
On Sun, Mar 15, 2009 at 20:36, Hubert,
Yes, this has been exactly the direction I was looking for. I guess
Asankha made just a typo in the name of the suggested property and
wanted to use FAULTS_AS_HTTP200 as 500 would be the current default.
Then the rest of the sentence setting it to true in the
HessianMessageBuilder would still apply
on, but of course FindBugs and PMD comes at the compile phase to
collect the information to be presented in the report.
Thanks,
Ruwan
On Mon, Mar 16, 2009 at 2:31 AM, Hubert, Eric
wrote:
> Cool!
>
> Now, probably it doesn't make sense to use both PMD and findbugs,
> especial
Hi all,
sorry for the gap in response. I was actually very busy due to some platform
live issues which needed my attention.
Anyway I tried to finish up the discussed work on the handling of synapse
generated faults send out as a Hessian message.
Looking at the possibilities I discarded the ap
> My suggestions are:
>
>
> <... other such properties.../>
>
>
+1
I thought exactly the same while reading the original mail. The short name with
"env" could be quite confusing for new users which are not the deeply involved
into the technical details. There is often an association En
Hi,
> Do we need configuration changes for this? We can set these properties
> using property mediator and then introduces some layer (before sending
> message) that do work based on these special properties- special
> property handlers.
I'm not sure whether the generic approach will always be th
Hi,
It seems like we have a Jira downtime so I answer directly on the list.
> Asankha C. Perera resolved SYNAPSE-521.
> ---
>
> Resolution: Fixed
> Assignee: Asankha C. Perera
>
> Thanks Eric for the fix. I just removed an unused constant "HTTP_SC_O
Hi all,
while working on patch to make direct use of the existing MBeans in Synapse I
was wondering about the current order of actions during Synapse startup.
If I'm not wrong it looks like the transports are started somewhere in the
middle of the Synapse startup. Is this observation correct? I
Hi all,
hmm, I quickly tried to change the order and it seems to work without problems.
> This is a side effect of the historical and now burned-in dependency on
> Axis2.. In Synapse, the startup script actually starts Axis2, and then
> again gets triggered on the startup of Axis2, for the actual
Hi all,
unfortunately at the moment I'm still not able to help much with this
discussion as I did not spend enough time to understand the coupling of Axis2
and Synapse in detail.
Generally what Indika writes about the decoupling of transports and mediation
engine makes definitely sense from my
+1
The only task I would like to add is validating the current startup process, as
I find it quite important.
Although it is normal within Apache projects to run in CTR and I’m generally a
big fan, I think before big changes it would make sense to discuss the details
a bit more on the li
me concept by sending error indicating
> synapse is not ready (may be mapping error to http or any application
> level protocol or soap fault) so that client can retry.
>
> Thanks
> Indika
>
> On Tue, Mar 31, 2009 at 11:13 AM, Hubert, Eric
> wrote:
> > Hi all,
> &g
Hi Ruwan,
thanks for taking the time to review the startup/shutdown logic implemented. In
terms of structure and readability I also widely liked the changes. I have only
those real world usage’s concerns. So if you are already at it could you please
also look at the shutdown process!
In mos
Hi Synapse devs,
No worries, I don't want to start a discussion about exception handling in
general, I just would like to understand the reasoning of your design choice. I
stumbled over some areas in the code where I noticed that an original exception
is caught, logged AND rethrown wrapped insi
Hi Asankha,
thanks for your reply. Humans life would be to boring, if we would always share
the same opinion. ;-)
> This basically follows some ideas from Joshua Bloch (Effective Java:
> Programming Language Guide), and some discussions on the use of checked
> exceptions vs runtime exceptions.
A
the start order that is going to be a double work for the stop process.
Thanks,
Ruwan
On Thu, Apr 2, 2009 at 2:17 PM, Hubert, Eric wrote:
Hi Ruwan,
thanks for taking the time to review the startup/shutdown logic implemented. In
terms of structure and readability I also widely liked the
> I wrote the code to get the engine to wait a maximum number of seconds -
> for these in-process messages to complete, the callbacks to get replies
> etc. However, once the graceful timeout specified by a user expires, we
> shutdown the engine. This code is already within the WSO2 ESB 1.7.x and
>
I am trying to come up with a proposal to implement this. When we do a
considerable change, it is better to discuss things before commiting to
implement that even though we are operating on CTR model.
Ruwan, I fully agree. While reading the dev list I noticed quite often that the
final resul
Hi,
although it is a quite trivial change from context name /soap to /services we
have seen a couple of problems/irritated users, so I asked myself whether it
wouldn't be easily possible to configure something in axis2.xml to use /soap as
an alias for /services.
This way we could document the
e
ManagedLifecycle interface called start, apart from the init and destroy
methods so that the start method will be called after starting the
listener manager, from the ServerManager class.
This resolves the issue...
WDYT?
Thanks,
Ruwan
On Fri, Apr 3, 2009 at 3:19 PM, Hubert, Eric
wrote:
> > ./slf4j-log4j12-1.5.6.jar
>
> There is at least one dependency (I don't remember which one) that
> uses SLF4J as abstract logging framework. Since we use log4j as
> concrete implementation, we need the SLF4J-log4j bridge.
It looks like there are more than one dependency, but the one Andrea
I put my comments inline as well.
Please see my comments inline;
What I meant in my original proposal is exactly this, but without preStart I
think preStart is equivalent to the init, but we need postStart or some other
meaning full method to do post startup tasks.
Yeah, at the mom
> Instead of moving the amqp transport to experimental, why not split
> the synapse-transport module and have a separate module for each
> transport? This would make dependency management much easier because
> it would be clear which dependency is used by which transport. Also
> when using Maven to
Hi,
I am completely OK with keeping this, but not QuickFixJ and other
related dependencies, because FIX is a domain specific transport which
wont be required for many users
I share the same opinion as Ruwan. I remember we already had some
discussions about this:
http://www.nabble.
a bit more information to it and most importantly we
should publish it in a way so that an interested user can easily locate
it.
Thanks,
Hiranya
On Sat, Apr 4, 2009 at 6:44 PM, Hubert, Eric
wrote:
Hi,
I am completely OK with keeping this, but not QuickFixJ and other
related dependencies, b
The second option is to log a message by default if its sent to
/soap/xxx on the console.. so that the user knows what went wrong..
Of course +1 for this.
I agree.. lets just do this now...
This sounds to be the best option. What is send back to the client in
case the context does not m
Thanks Ruwan! Your changes to the startup look straightforward and correct to
me.
Current startup order after you change reads as follows (main changes are bold):
1 SynapseServer.main()
1.1
ServerConfigurationInformationFactory.createServerConfigurationInformation(args);
1.2 Serve
Sorry for the late reply, I’ve been very busy this week. Please see my comments
inline!
The steps you have listed are correct and please note that the ServerManager
has been now instrumented with the following sequence of life cycle methods and
I have realized that at least for now we do not
If you look at the way synapse operates, even though it seems like a module of
axis2 it is really not, it just uses the axis2 handler architecture to leverage
the other axis2 features while getting the message dispatched into synapse. So
I propose to drop the module and programaticaly register t
Hi all,
At the weekend I took some time to work on improving JMX and security support:
https://issues.apache.org/jira/browse/SYNAPSE-526
Basically I incorporated the feedback received and had a look on Indikas quite
flexible Security API he first introduced to datasources. As I'm already
inter
Hi Andreas,
thanks for quickly fixing this! I was working on a couple of small improvements
and was very confused as this suddenly happened. I was not sure whether it was
related to my changes or the svn up. ;-)
Regards,
Eric
> See SYNAPSE-525.
>
> Andreas
Hi all,
I'm still facing an issue which looks like a recursion (not the same), if the
endpoint url is a non existing one resulting in a connection refused.
Here is my endpoint config:
12
fault
3
500
/java/modules/core/src/main/java/org/apache/synapse/endpoints/WSDLEndpoint.java
Regards,
Eric
From: Hubert, Eric [mailto:eric.hub...@foxmobile.com]
Sent: Saturday, April 18, 2009 7:20 PM
To: dev@synapse.apache.org
Subject: RE: Endless recursion in
: Endless recursion in FaultHandler.handleFault()
Eric I properly fixed this you may verify this, sorry for the trouble.
Thanks,
Ruwan
On Sat, Apr 18, 2009 at 10:35 PM, Hubert, Eric
wrote:
Hi Andreas,
thanks for quickly fixing this! I was working on a couple of small improvements
and was
Hi all,
> I went though this change before the weekend, and it looked ok - I was
> expecting feedback from Indika as this touches on the security / secret
> stuff brought in recently.. but lets not delay it anymore as this
> touches a few files, unless Ruwan / Andreas has any feedback not to
> com
committers.
Thanks,
Eric
> -Original Message-
> From: Hubert, Eric [mailto:eric.hub...@foxmobile.com]
> Sent: Tuesday, April 21, 2009 9:11 AM
> To: dev@synapse.apache.org
> Subject: RE: Build failed in Hudson: Synapse - Trunk » Apache Synapse -
> Utility classe
Hi all,
thanks a lot for the warm welcome and the trust. Regarding the ICLA I
have to first pass some legal concerns with my employer. We are
currently discussing the option of signing a CCLA. I'm afraid that this
will take some time.
I'll keep you updated on the progress. In the meantime I
Hi all,
I'll have a look at this and will fix it. From the stack it looks like the
shutdown order is wrong. Unfortunately I'll be travelling today without having
access to the net today, but tonight or tomorrow I'll submit a patch to correct
this if no one beats me to it.
Regards,
Eric
> -
nks,
Ruwan
On Sat, Apr 25, 2009 at 2:51 PM, Hubert, Eric wrote:
Hi all,
I'll have a look at this and will fix it. From the stack it looks like the
shutdown order is wrong. Unfortunately I'll be travelling today without having
access to the net today, but tonight or tomorrow I&
Hi Ruwan,
I submitted a patch which should fix this issue you reported. Fortunately I was
not able to reproduce it locally. Could you please first apply this patch
locally and test if it fixes the issue for you!
By the way, which log4j configuration are we using if running the server from
syna
1 - 100 of 161 matches
Mail list logo
