sorry for hijacking the thread, it would be highly beneficial to the
followers (and learners like me)
if the large request response data is posted as pastebin links. IMHO that
make it easy to understand
the conversation.
On Fri, Apr 24, 2015 at 7:48 PM, Shawn McKinney smckin...@apache.org
wrote:
On Mon, Jun 1, 2015 at 10:06 PM, Shawn McKinney smckin...@apache.org
wrote:
On Jun 1, 2015, at 8:22 AM, Kiran Ayyagari kayyag...@apache.org wrote:
On Mon, Jun 1, 2015 at 9:08 PM, Shawn McKinney smckin...@apache.org
wrote:
Hello,
This posting is to inform the community
gt;
yep, the current LdifReader has support for this
>
> Otherwise, we have worked on a tool that process LDIFs and load them
> after having sorted them with Kiran (BulkLoader) that is able to process
> very big files). We have to see if it can be reused easily.
>
yeah, this sorter works well indeed
Kiran Ayyagari
http://keydap.com
hat is able to
> > > process very big files). We have to see if it can be reused easily.
> > >
> > yeah, this sorter works well indeed
> >
> >
> > Kiran Ayyagari
> > http://keydap.com
>
> Hi. Where should I look? Do you have some examples of LdifRea
is a connection pool in use here, and it is not
properly destroyed while the app
is being unloaded from the app server.
Did you try closing the pool in your app's ServletContextListener?
Kiran Ayyagari
http://keydap.com
t worth the trouble.
>
> Thoughts?
>
+1 to change it to string. We can always explicitly mark that as "null"
after using it.
(IMO if the attacker gained access to the OS then we have a bigger
operational security issues than
implementation)
> Shawn
>
>
>
>
>
> Kiran Ayyagari
On Thu, Dec 20, 2018 at 8:51 PM Pike, Christopher wrote:
> I can certainly add appropriate code to remove the field on both ends. I
> was more questioning why the type information is necessary as I don't have
> a use case where I need the type information specified in the object, so it
> is
ffort for a simplified web admin UI the JSON support was
added.
>
>1.
>
> --
> *From:* Kiran Ayyagari
> *Sent:* Thursday, December 20, 2018 12:39:50 AM
> *To:* fortress@directory.apache.org
> *Subject:* Re: FC-250
>
> On Thu, Dec 20, 2018 at 1:4
out which deserialization fails.
Note that the original aim was to only add support for JSON data format
without shuffling too many things. The invocation mechanism still uses
FortRequest just like JAXB.
> ____
> From: Kiran Ayyagari
> Sent: Thursday, December 20, 2018
On Thu, Dec 20, 2018 at 1:40 AM Pike, Christopher wrote:
> This commit is a potentially breaking change. (
> https://github.com/apache/directory-fortress-core/commit/2d8a53071b8d8b5bb3b6256f084a9e12d4a7cc10#diff-280616e1526a17336cdb4ff1855d7439
> )
>
>
> Specifically
>
>
>
On Tue, Mar 5, 2019 at 1:14 AM Shawn McKinney wrote:
>
> > On Mar 3, 2019, at 6:17 AM, Kiran Ayyagari wrote:
> >
> > I have finally got a chance to merge the relevant parts of this code from
> > FC-247 branch.
> > Local build passed after merge but I only ran &q
something breaks.
On Thu, Dec 20, 2018 at 9:58 PM Stefan Seelmann
wrote:
> On 12/20/18 3:59 PM, Kiran Ayyagari wrote:
> > On Thu, Dec 20, 2018 at 6:45 PM Pike, Christopher
> wrote:
> >
> >>
> >>1. Is there a way to give me permission to accept the PR
12 matches
Mail list logo
