RE: [SUBMIT] Timezone support for date elements of pattern layou t

[Mark Womack <mw...@bevocal.com>]

> mwomack@apache.org wrote:
> > Wow.  Ceki, I am surprised you have not commented on this yet.
> 
> Mark,
> 
> Be kind.  Maybe Ceki also has a real life that has kept him away from 
> this list.  I had a little extra time on my hands this past 
> weekend, and 
> I had been thinking about this idea since the first time Ceki had 
> pointed me to his enhancements document.  So I just put my current 
> thoughts on paper.

I wasn't picking on anybody.  I'm the last person to tell anyone to spend
more time working for free on open source projects and not on the projects
that pay the bills.

But I don't know, Mike.  Submitting useful code, writing test cases to go
with it, picking up projects when you have extra time...keep that up and you
might become a committer.

> That's an implementation detail.  I intend to use reflection 
> to find the 
> relevant o.a.l.helpers.PatternConverter that is then added to 
> the linked 
> list.  If I do this right, it should be possible to create new 
> PatternConverter subclasses for new Pattern Ids, and to find 
> these new 
> PatternConverters in the Classpath.  I haven't yet figured 
> out the best 
> way to find new PatternConverter subclasses (since they won't 
> be in the 
> o.a.l.helpers package), so any suggestions would be appreciated.

I have wondered about this as well for other cases.  It would be useful to
have some code that searches the classpath for classes that implement a
given interface/class.  But I think that this code would be very time
consuming, searching the entire classpath, inspecting all the classes.  If
you think of a good way, I think we would all like to hear about it.

> > But frankly, I think that doing this is not required to 
> accept Mike's first
> > round of changes he has submitted.  
> 
> This would be nice.  I've imported the current 1.3 code to my 
> machine, 
> and I have looked at how some of the proposed changes might 
> affect other 
> classes.  For example, I think that my ideas would require changes to 
> o.a.l.helpers.FormattingInfo.  Since this class is only usable within 
> its package (even though the class itself is public) I don't expect 
> changes to it to break other code.  However, I don't know if 
> there are 
> any implementations of Log4J with new classes added to the the Log4J 
> packages.  I don't think I've seen anything in the documentation 
> discouraging creating classes in packages already found in the Log4J 
> distribution.
> 
> Is this a situation about which I should be concerned?

Do you think your first round of changes will affect the
o.a.l.helpers.FormattingInfo?  Can you elaborate?

And I don't know what the policy is on this.  Anyone can write classes that
end up in the same package, and thus have access to package level
classes/members.  Ceki, are we trying to maintain api compatibility at that
level?

-Mark

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [SUBMIT] Timezone support for date elements of pattern layou t

["Michael A. McAngus" <ma...@infinet.com>]

Mark Womack wrote:


> 
> I have wondered about this as well for other cases.  It would be useful to
> have some code that searches the classpath for classes that implement a
> given interface/class.  But I think that this code would be very time
> consuming, searching the entire classpath, inspecting all the classes.  If
> you think of a good way, I think we would all like to hear about it.

Yes, searching the classpath would be time consuming.  Fortunately, it 
would happen only during PatterLayout setup.  Unfortunately, that setup 
can occur at any time.

If I come up with a good solution, this dev list will be one of the 
first places I go to tell about it.

> 
> 
>>>But frankly, I think that doing this is not required to 
>>
>>accept Mike's first
>>
>>>round of changes he has submitted.  
>>
>>This would be nice.  I've imported the current 1.3 code to my 
>>machine, 
>>and I have looked at how some of the proposed changes might 
>>affect other 
>>classes.  For example, I think that my ideas would require changes to 
>>o.a.l.helpers.FormattingInfo.  Since this class is only usable within 
>>its package (even though the class itself is public) I don't expect 
>>changes to it to break other code.  However, I don't know if 
>>there are 
>>any implementations of Log4J with new classes added to the the Log4J 
>>packages.  I don't think I've seen anything in the documentation 
>>discouraging creating classes in packages already found in the Log4J 
>>distribution.
>>
>>Is this a situation about which I should be concerned?
> 
> 
> Do you think your first round of changes will affect the
> o.a.l.helpers.FormattingInfo?  Can you elaborate?

No, the changes I am contemplating for Conversion Words will probably 
require changes to FormattingInfo.

> 
> And I don't know what the policy is on this.  Anyone can write classes that
> end up in the same package, and thus have access to package level
> classes/members.  Ceki, are we trying to maintain api compatibility at that
> level?
> 

-- 
Cheers,
Mike McAngus
mam@infinet.com



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>