I am the sole developer of the mods, and I was given permission to submit
them back to the project. This is essentially an update to log4j-mini.
Scott
On Wed, Oct 19, 2011 at 10:38 PM, Curt Arnold wrote:
> You described the "our changes" (not "my changes") and that you were given
> permission,
You described the "our changes" (not "my changes") and that you were given
permission, both of those suggest that it isn't a simple contribution of your
personal original work, hence the likely need for the IP clearance process at
the Incubator PMC. If you think it is debatable whether the IP cl
Sent too soon. I'll help with the move.
Scott
On Oct 19, 2011, at 2:17 AM, Christian Grobmeier
wrote:
On Wed, Oct 19, 2011 at 7:45 AM, Curt Arnold
wrote:
On Oct 18, 2011, at 5:12 PM, Scott Deboy wrote:
I would like to see much of what is in extras and component (at
least functional
Tru2way is a spec (with a reference implementation) defining an
application platform for interactive cable applications. It is based
on the personal basis profile (JavaME) and other frameworks.
On Oct 19, 2011, at 2:18 AM, Christian Grobmeier
wrote:
On Wed, Oct 19, 2011 at 7:02 AM, Cur
No objections. I'll
On Oct 19, 2011, at 2:17 AM, Christian Grobmeier
wrote:
On Wed, Oct 19, 2011 at 7:45 AM, Curt Arnold
wrote:
On Oct 18, 2011, at 5:12 PM, Scott Deboy wrote:
I would like to see much of what is in extras and component (at
least functionality-wise) be rolled in to l
On Wed, Oct 19, 2011 at 7:02 AM, Curt Arnold wrote:
> On Oct 18, 2011, at 3:34 PM, Scott Deboy wrote:
>> I have been given permission to provide our tru2way changes to get log4j 1.2
>> to work on personal basis profile 1.1, if anyone wants them (core and extras
>> and some other tweaks like pull
On Wed, Oct 19, 2011 at 7:45 AM, Curt Arnold wrote:
> On Oct 18, 2011, at 5:12 PM, Scott Deboy wrote:
>
>> I would like to see much of what is in extras and component (at least
>> functionality-wise) be rolled in to log4j 2. If it's in Chainsaw I really
>> doubt that will happen. If it's in ex
On Oct 18, 2011, at 5:12 PM, Scott Deboy wrote:
> I would like to see much of what is in extras and component (at least
> functionality-wise) be rolled in to log4j 2. If it's in Chainsaw I really
> doubt that will happen. If it's in extras it may happen but I still doubt it.
>
> My preference
I'm not sure this would need to go through the incubator. There were very
few changes to log4j that were not compatible, the changes were backward
compatible. What is required is required packaging work to explicitly
exclude classes which I didn't pull in to the PBP-compatible version
(primarily
On Oct 18, 2011, at 3:34 PM, Scott Deboy wrote:
> I have been given permission to provide our tru2way changes to get log4j 1.2
> to work on personal basis profile 1.1, if anyone wants them (core and extras
> and some other tweaks like pulling in the logSF helpers in to the logger
> class)...so
I would like to see much of what is in extras and component (at least
functionality-wise) be rolled in to log4j 2. If it's in Chainsaw I really
doubt that will happen. If it's in extras it may happen but I still doubt
it.
My preference would be to move component and extras and receivers in to
lo
On Tue, Oct 18, 2011 at 10:29 PM, Gary Gregory wrote:
> For me, the fewer jars the better. The best solution: give me logging in one
> jar. If I want to log to some exotic appender that requires a third party
> library, that's fine, that one is on me (or my Ant build) to do the right
> thing. Just
I have been given permission to provide our tru2way changes to get log4j 1.2
to work on personal basis profile 1.1, if anyone wants them (core and extras
and some other tweaks like pulling in the logSF helpers in to the logger
class)...so I don't think we need to worry about core log4j and mobile..
For me, the fewer jars the better. The best solution: give me logging in one
jar. If I want to log to some exotic appender that requires a third party
library, that's fine, that one is on me (or my Ant build) to do the right
thing. Just don't give me a "core" jar and a one jar for each appender or
So, what are we doing now?
I don't want to stop in a deadlock again.
On Wed, Oct 12, 2011 at 6:29 AM, Scott Deboy wrote:
> Maybe everything optional should be pulled out of core - including
> appenders. I assume the reason they are in core is due to the fact that
> people don't want to downloa
The separation seems relatively arbitrary to me. Appenders generally go in
to core. The other side of appenders (receivers) don't. Plugin? Declared
in the DTD...but...not in core. Even though the DTD is in core.
Maybe everything optional should be pulled out of core - including
appenders. I a
On Oct 10, 2011, at 3:23 AM, Christian Grobmeier wrote:
>> Moving component and receivers to core would be more work given the
>> peculiarities of the tests. It took a couple of hours just to move the
>> Rewrite appenders and their tests.
>
>
> Because why exactly? I thought it could be done w
You pulled rewriteappender into core. That action seems inconsistent
with your list of choices here unless you are arbitrarily saying
appenders belong in core but receivers do not.
Did you post a question to the list asking the dev or user list which
classes belonged in core? I can't find
On Mon, Oct 10, 2011 at 7:50 AM, Curt Arnold wrote:
> On Oct 9, 2011, at 10:34 PM, Scott Deboy wrote:
>
>> Can we drive to a resolution on this issue? Does this require a vote? I'd
>> like to do something to get the receivers and component code and Chainsaw
>> out of purgatory. I would prefer
On Fri, Oct 7, 2011 at 7:18 AM, Scott Deboy wrote:
> I don't think adding things to core at this point adds an expectation on
> log4j 2.0 at all personally.
+1
Actually I can't understand this argumentation. Its just blocking. I
mean - don't make log4j1.2.x to good, because people will be
disapp
On Oct 9, 2011, at 10:34 PM, Scott Deboy wrote:
> Can we drive to a resolution on this issue? Does this require a vote? I'd
> like to do something to get the receivers and component code and Chainsaw out
> of purgatory. I would prefer to either pull receivers and component in to
> core (sin
The recent choice to pull some classes but not all of receivers in to
core seems to reinforce the idea they all just belong there.
On Oct 9, 2011, at 8:34 PM, Scott Deboy wrote:
Can we drive to a resolution on this issue? Does this require a
vote? I'd like to do something to get the rece
Can we drive to a resolution on this issue? Does this require a vote? I'd
like to do something to get the receivers and component code and Chainsaw
out of purgatory. I would prefer to either pull receivers and component in
to core (since the dom defines these objects and it seems to have things
I don't think adding things to core at this point adds an expectation on
log4j 2.0 at all personally. I'm against creating a logging attic.
Receivers are the other half of appenders. Unless you only care about
fileappenders, they have utility.
I'd still prefer to see things moved in to core. Ou
I used Nexus for the last release of log4j and struggled with it. If I remember
correctly there were issues with our Maven group ID not starting with
org.apache that prevented the release from being mirrored to Maven central, but
think we finally worked through all the issues.
I would not be in
>> But to be honest, I am not even sure if Nexus has been used before for
>> log4j. Well... lets see if Curt can comment, as he has done the past
>> releases.
>
> Check.
>
> It's easy enough to ask infra to set up Nexus for a component through a
> JIRA, I just did it for Commons IO and a while bac
On Wed, Oct 5, 2011 at 1:30 PM, Christian Grobmeier wrote:
> On Wed, Oct 5, 2011 at 7:25 PM, Gary Gregory wrote:
> > This might help you get started (from Commons):
> > https://wiki.apache.org/commons/UsingNexus
>
> Thanks Gary, Actually I have helped editing this file. :-)
>
> But to be honest,
On Wed, Oct 5, 2011 at 7:25 PM, Gary Gregory wrote:
> This might help you get started (from Commons):
> https://wiki.apache.org/commons/UsingNexus
Thanks Gary, Actually I have helped editing this file. :-)
But to be honest, I am not even sure if Nexus has been used before for
log4j. Well... let
This might help you get started (from Commons):
https://wiki.apache.org/commons/UsingNexus
Gary
On Wed, Oct 5, 2011 at 1:22 PM, Scott Deboy wrote:
> Yes a release ASAP would be great...
>
> I'd love to see a wiki page on how to release as well, with all the steps.
>
> Scott
>
>
> On Wed, Oct 5,
Yes a release ASAP would be great...
I'd love to see a wiki page on how to release as well, with all the steps.
Scott
On Wed, Oct 5, 2011 at 10:16 AM, Christian Grobmeier wrote:
> On Wed, Oct 5, 2011 at 6:47 PM, Scott Deboy wrote:
> > Well, rolling them in to core would be an option. Curt had
On Wed, Oct 5, 2011 at 6:47 PM, Scott Deboy wrote:
> Well, rolling them in to core would be an option. Curt had a rationale for
> companions, from a previous email:
>
> "The motivation to have "companions" as a distinct products was not to keep
> the log4j.jar trim, but allow the companions to be
Well, rolling them in to core would be an option. Curt had a rationale for
companions, from a previous email:
"The motivation to have "companions" as a distinct products was not to keep
the log4j.jar trim, but allow the companions to be available for people who
were stuck with older versions of l
On Wed, Oct 5, 2011 at 11:33 AM, Christian Grobmeier wrote:
> Gary, thanks for explaining your situation
>
> On Wed, Oct 5, 2011 at 4:57 PM, Scott Deboy wrote:
> > We could leave receivers as their own companion...component is so small
> it
> > should either go back in to core or into Chainsaw (t
I had copied all the code in to Chainsaw, but it didn't seem like it would
make sense to have it in both Receivers and Chainsaw.
I think pulling everything in to Extras would work..Extras are mostly
appender-side things (LogSF, Filters, PatternConverters, Rolling and
TriggeringPolicy), but it is s
On Wed, Oct 5, 2011 at 6:09 PM, Scott Deboy wrote:
> Of course, receivers has not yet had an official release, and since
> receivers depends on the component code, we need a release of wherever that
> goes first.
>
> Which means component can't go into chainsaw because of the dependencies..
>
> So
Of course, receivers has not yet had an official release, and since
receivers depends on the component code, we need a release of wherever that
goes first.
Which means component can't go into chainsaw because of the dependencies..
So to get Chainsaw out the door, we first have to move component c
On Wed, Oct 5, 2011 at 5:54 PM, Scott Deboy wrote:
> Yeah, sort of like what happened to zeroconf...
>
> I think Component could go back in to core.
OK.. then lets wait for another couple of hours, maybe other people
want to stand up. Afterwards I will remove the component website, but
leave reic
Yeah, sort of like what happened to zeroconf...
I think Component could go back in to core.
Scott
On Wed, Oct 5, 2011 at 8:46 AM, Christian Grobmeier wrote:
> On Wed, Oct 5, 2011 at 5:44 PM, Scott Deboy wrote:
> > Here's my preference:
> >
> > I would expect more receivers will be added in th
On Wed, Oct 5, 2011 at 5:44 PM, Scott Deboy wrote:
> Here's my preference:
>
> I would expect more receivers will be added in the future, or there may be
> bugs we want to fix..so I would leave receivers and extras as companions and
> move component somewhere (Chainsaw or core).
OK, and receivers
Here's my preference:
I would expect more receivers will be added in the future, or there may be
bugs we want to fix..so I would leave receivers and extras as companions and
move component somewhere (Chainsaw or core).
Scott
On Wed, Oct 5, 2011 at 8:33 AM, Christian Grobmeier wrote:
> Gary, tha
Gary, thanks for explaining your situation
On Wed, Oct 5, 2011 at 4:57 PM, Scott Deboy wrote:
> We could leave receivers as their own companion...component is so small it
> should either go back in to core or into Chainsaw (there are some
> repositoryselector extensions that are useful, etc)..
a
We could leave receivers as their own companion...component is so small it
should either go back in to core or into Chainsaw (there are some
repositoryselector extensions that are useful, etc)..
Scott
On Wed, Oct 5, 2011 at 7:52 AM, Gary Gregory wrote:
> Hi Christian,
>
> We, at Seagull Softwar
Hi Christian,
We, at Seagull Software, a division of Rocket Software, use the jars in our
LegaSuite app server [1] and some tools.
Moving the code would be an impediment to updating to the next release of
the jars.
Gary
[1] http://seagull.rocketsoftware.com/products/application-modernization
O
On Tue, Oct 4, 2011 at 9:44 PM, Gary Gregory wrote:
> We use the XMLSocketReceiver.
Who actually is "we"?
Can you copy it over? Or do you need it were it is?
Cheers
Christian
>
> Gary
>
> On Tue, Oct 4, 2011 at 1:41 PM, Scott Deboy wrote:
>>
>> The sources for the unreleased receivers and com
We use the XMLSocketReceiver.
Gary
On Tue, Oct 4, 2011 at 1:41 PM, Scott Deboy wrote:
> The sources for the unreleased receivers and components companions have
> been copied in to the Chainsaw source tree, based on the assumption that
> they are only useful to Chainsaw. Unless there are any ob
The sources for the unreleased receivers and components companions have been
copied in to the Chainsaw source tree, based on the assumption that they are
only useful to Chainsaw. Unless there are any objections, I plan on
deleting the component and receivers companions from subversion, with
corres
46 matches
Mail list logo
