You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Brian Minchau <mi...@ca.ibm.com> on 2006/02/14 18:41:25 UTC
Re: public to non-public in Xalan-J serializer - any impact?
Toadie,
please open a JIRA issue against the XalanJ2 project ( at
http://issues.apache.org/jira/secure/Dashboard.jspa ) to track your
request. Mailing lists are good for discussions, but not so good for
remembering what needs fixing/changing.
- Brian
- - - - - - - - - - - - - - - - - - - -
Brian Minchau
XSLT Development
toadie D
<toadie643@gmail.
com> To
Brian Minchau/Toronto/IBM@IBMCA
02/14/2006 11:15 cc
AM
Subject
Re: public to non-public in Xalan-J
serializer - any impact?
Hi Brian
Thanks for the quick reply. Yes, we do realize that using the *For
internal uses only* classes poses some risks.
For the time being, we ended up undo your changes (short term solution) and
recompile the source.
We'll eval your recommendation to implement a ContentHandler for our case
since we aren't using any protected method and/or member vars.
But I think it would be great if the interfaces could be left public and
non-final. There are sufficient warnings (ie. *For internal uses only*) so
it should be up to the user to decide their risk tolerance level.
Thanks
Toadie.
On 2/8/06, Brian Minchau <minchau@ca.ibm.com > wrote:
Looks like I wrote that, but changed some of the leaf classes to "final"
anyway. By extending a class like ToXMLStream you are on a slippery path.
The javadoc for the class says "**For internal use only**". That may be
of
little consolation, but I guess we are trying to keep people from
building
dependancies on non-public APIs.
For the moment what about containing a ToXMLStream rather than inheriting
from it?
class MyXMLSerializer implements ContentHandler {
private final ToXMLStream m_ser;
MyXMLSerializer() {
m_ser = new ToXMLStream();
}
void startDocument() {
m_ser.startDocument();
}
// .... other ContentHandler methods that delegate to m_ser,
}
Will that do, or are you using some protected or package-private methods
or
fields? In the bigger scheme of things we want user's to be happy and
this
issue could be revisited. We could make these classes non-final.
Even classes like ToXMLStream became public again, I guess you know that
these are not public APIs and you can't depend on them. They could go
away
or have methods on them change in the future, but you are prepared for
that, right?
Let us know. Perhaps it is time for 2.7.1 or 2.8 with some changes.
Keep the dialogue going.
Regards,
- Brian
Apache Xalan XSLT Development
minchau@ca.ibm.com
toadie D
< toadie643@gmail.
com> To
xalan-dev@xml.apache.org
02/08/2006 06:12 cc
PM toadie643@gmail.com
Subject
re: public to non-public in Xalan-J
Please respond to serializer - any impact?
xalan-dev
Reference:
http://marc.theaimsgroup.com/?l=xalan-dev&m=107419182613741&w=2
--excerpt--
"public" classes that I'd like to see become package-private.
Is anyone using these directly?
This is my area of greatest concern so it will probably be left as
"public".
==========================================================
- ToHTMLStream
- ToTextStream
- ToXMLStream
--excerpt--
Unfortunately, we are using what Brian has proposed as a feature change
(we
were on 2.5.1 and have recently moved to 2.7.x)
We had (and still do) have a need to extend the ToXMLStream class to
perform a number of tasks.
In 2.7.x, it's now declared as final. So, for implementation that
requires custom XML serialization, what is the general guideline for
implementing those serializer?
It would be nice if we can leverage some of the code that's already
implemented by Apache.
Thanks.
Re: public to non-public in Xalan-J serializer - any impact?
Posted by toadie D <to...@gmail.com>.
Brian
Issue created in JIRA.
Thanks
Toadie.
On 2/14/06, Brian Minchau <mi...@ca.ibm.com> wrote:
>
> Toadie,
> please open a JIRA issue against the XalanJ2 project ( at
> http://issues.apache.org/jira/secure/Dashboard.jspa ) to track your
> request. Mailing lists are good for discussions, but not so good for
> remembering what needs fixing/changing.
>
>
> - Brian
> - - - - - - - - - - - - - - - - - - - -
> Brian Minchau
> XSLT Development
>
>
>
>
> toadie D
> <toadie643@gmail.
> com> To
> Brian Minchau/Toronto/IBM@IBMCA
> 02/14/2006 11:15 cc
> AM
> Subject
> Re: public to non-public in Xalan-J
> serializer - any impact?
>
>
>
>
>
>
>
>
>
>
> Hi Brian
>
> Thanks for the quick reply. Yes, we do realize that using the *For
> internal uses only* classes poses some risks.
> For the time being, we ended up undo your changes (short term solution)
> and
> recompile the source.
>
> We'll eval your recommendation to implement a ContentHandler for our case
> since we aren't using any protected method and/or member vars.
> But I think it would be great if the interfaces could be left public and
> non-final. There are sufficient warnings (ie. *For internal uses only*)
> so
> it should be up to the user to decide their risk tolerance level.
>
> Thanks
>
> Toadie.
>
>
>
> On 2/8/06, Brian Minchau <minchau@ca.ibm.com > wrote:
> Looks like I wrote that, but changed some of the leaf classes to "final"
> anyway. By extending a class like ToXMLStream you are on a slippery path.
>
> The javadoc for the class says "**For internal use only**". That may be
> of
> little consolation, but I guess we are trying to keep people from
> building
> dependancies on non-public APIs.
>
> For the moment what about containing a ToXMLStream rather than inheriting
>
> from it?
>
> class MyXMLSerializer implements ContentHandler {
> private final ToXMLStream m_ser;
>
>
> MyXMLSerializer() {
> m_ser = new ToXMLStream();
> }
>
>
> void startDocument() {
> m_ser.startDocument();
> }
>
>
> // .... other ContentHandler methods that delegate to m_ser,
>
> }
>
> Will that do, or are you using some protected or package-private methods
> or
> fields? In the bigger scheme of things we want user's to be happy and
> this
> issue could be revisited. We could make these classes non-final.
>
> Even classes like ToXMLStream became public again, I guess you know that
> these are not public APIs and you can't depend on them. They could go
> away
> or have methods on them change in the future, but you are prepared for
> that, right?
>
> Let us know. Perhaps it is time for 2.7.1 or 2.8 with some changes.
>
> Keep the dialogue going.
>
> Regards,
> - Brian
> Apache Xalan XSLT Development
> minchau@ca.ibm.com
>
>
>
>
> toadie D
> < toadie643@gmail.
> com> To
>
> xalan-dev@xml.apache.org
> 02/08/2006 06:12 cc
> PM toadie643@gmail.com
> Subject
> re: public to non-public in Xalan-J
> Please respond to serializer - any impact?
> xalan-dev
>
>
>
>
>
>
>
>
>
>
> Reference:
> http://marc.theaimsgroup.com/?l=xalan-dev&m=107419182613741&w=2
>
> --excerpt--
> "public" classes that I'd like to see become package-private.
> Is anyone using these directly?
> This is my area of greatest concern so it will probably be left as
> "public".
> ==========================================================
> - ToHTMLStream
> - ToTextStream
> - ToXMLStream
> --excerpt--
>
>
> Unfortunately, we are using what Brian has proposed as a feature change
> (we
> were on 2.5.1 and have recently moved to 2.7.x)
>
> We had (and still do) have a need to extend the ToXMLStream class to
> perform a number of tasks.
> In 2.7.x, it's now declared as final. So, for implementation that
> requires custom XML serialization, what is the general guideline for
> implementing those serializer?
>
> It would be nice if we can leverage some of the code that's already
> implemented by Apache.
>
> Thanks.
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
>