You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "David DeWolf (JIRA)" <ji...@apache.org> on 2007/02/08 13:59:06 UTC
[jira] Commented: (PLUTO-308) This patch is for new deployment with
JAXB instead of castor and the changes for the new API Revision from 8 to
11.
[ https://issues.apache.org/jira/browse/PLUTO-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471317 ]
David DeWolf commented on PLUTO-308:
------------------------------------
I'm not really in favor of this patch. We should provide backwards compatibility if at all possible, and I don't see any reason why it's not possible in this case. Decisions and findings like these need to be discussed on the dev list.
> This patch is for new deployment with JAXB instead of castor and the changes for the new API Revision from 8 to 11.
> -------------------------------------------------------------------------------------------------------------------
>
> Key: PLUTO-308
> URL: https://issues.apache.org/jira/browse/PLUTO-308
> Project: Pluto
> Issue Type: New Feature
> Components: general
> Affects Versions: 1.1-286-COMPATIBILITY
> Reporter: Torsten Dettborn
> Fix For: 1.1-286-COMPATIBILITY
>
> Attachments: jaxb_n_api-r11.080207.patch
>
>
> Christian has made a patch for the new JAXB binding for the deployment from the portlets, because there are too many problems with the patch (Issue 287) we decided to reject this issue and patch it all in one. Here is the description from Christian:
> "Unfortunately this patch is a big one. In the new spec there are
> qnames, which are used to identify names, e.g. event names. The
> previous implementation of the Portlet Object Model use castor
> for xml binding. Unfortunately castor does not support qnames in
> a way we need it. Thats why i implement the xml data binding with
> jaxb. In the new Spec there are other points JAXB will be used,
> therefor i think using JAXB is not a bad idea.
> My first idea was to change the *DD classes to interfaces and then
> let castor and jaxb implement this classes. In this case we should
> be able to use both xml data bindings together and the user has the
> choice.
> But i ran into several problems with this approach. On the one hand,
> the castor *DD classes doesn't provide all necessary methods
> and therefor much work with the castor implementation has to be
> done. On the other hand i want to use the classes automatically
> generated by jaxb.
> In my mind the best thing would be, to use the castor classes and
> annotate them with jaxb annotations. Then there aren't as much
> changes as with this patch.
> I have gone the other way, a matter of time. I've delete the castor
> things and use jaxb as the only xml data binding.
> What this patch does:
> I have generated (xjc maven plugin) the jaxb classes and add it to the
> repository. Then all occurences of *DD are replaced by the jaxb *Type
> classes. Some methods had to be renamed, and some jaxb classes had to
> be implemented because of XMLSchema conflicts.
> I use the JAXB RI, that is why i had to change the poms and installation
> dependencies. I add a new JaxbDescriptorService interface and the
> corresponding implementation.
> Note:
> With the current portlet-app_2_0.xsd (provided at:
> http://ipc658.inf-swt.uni-jena.de/spec/JSR%202.0%20API/portlet-app_2_0.xsd)
> it is not possible to use old portlet.xml files from JSR168. This has
> to be changed in the final release of the specification. Therefor i had
> to change the portlet.xml files in the repo.
> What has to be done:
> Writing of portlet.xml and web.xml is not supported yet.
> I would appreciate if someone could implement the (IMHO) better approach
> of adding the jaxb annotations to the castor classes."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Descriptor API (was Re: [jira] Commented: (PLUTO-308) This patch
is for new deployment with JAXB instead ...)
Posted by Dettborn <de...@minet.uni-jena.de>.
David H. DeWolf schrieb:
>
>
> Christian Raschka wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Thank you David for your comment. Now i think, there are two possible
>> workarounds for this problem:
>
>
> Sure, thanks for all the work you've done and discussing it on the
> list :)
>
>>
>> 1. we annotate the existing *DD classes with JAXB annotations
>> 2. the JAXB classes extend the *DD classes.
>
>
> I would add a third:
>
> 3. Translate JAXB model into the DD model upon retrieval.
>
>>
>> Both has pros and cons. I would prefer the first one but i don't know if
>> its possible.
>
>
> I believe the first would be ideal, but also don't know if it's
> possible. I really should dive into JAXB more :)
>
I think, this will be the best solution.
> I'd hesitate to do the second if the JAXB versions would contain uniqe
> properties that would only be accessible through casting. This would
> remove the transparency of the services..
>
> The third possibility could be expensive, however, reading of
> descriptors should probably be limited once per portlet app - so I
> wouldn't be too concerned with that aspect.
>
> What do others think?
>
>
>>
>> What do you think about it?
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.2.2 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iD8DBQFFy0IB40Vb1Zesx0kRAiMbAJ9IeV+YwDURcxqJluQ0zFH3V+cRZACfTe11
>> IO4NL36XruQnQk3c0NbXiK0=
>> =deZJ
>> -----END PGP SIGNATURE-----
>>
>
Re: Descriptor API (was Re: [jira] Commented: (PLUTO-308) This patch
is for new deployment with JAXB instead ...)
Posted by "David H. DeWolf" <dd...@apache.org>.
Excellent news! This seems ideal to me.
Thanks!
Christian Raschka wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> i've played around a little bit with annotating the *DD classes with
> jaxb annotations. It seems that's possible. It should be possible to
> change the implementation (from castor to jaxb) just by editing the
> property file.
>
> But because castor doesn't support QNames, if you use castor as
> implementation, its not spec conform.
>
> Is anyone disapproved against implementing this approach?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFzaK940Vb1Zesx0kRAoeEAJ9rtnci8hDuG67gQqHuMDgv7HVz/gCeJlWu
> uV6tiVbsfQochx0xBJRrEI8=
> =TPpw
> -----END PGP SIGNATURE-----
>
Re: Descriptor API (was Re: [jira] Commented: (PLUTO-308) This patch
is for new deployment with JAXB instead ...)
Posted by Christian Raschka <ch...@cs.uni-jena.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
i've played around a little bit with annotating the *DD classes with
jaxb annotations. It seems that's possible. It should be possible to
change the implementation (from castor to jaxb) just by editing the
property file.
But because castor doesn't support QNames, if you use castor as
implementation, its not spec conform.
Is anyone disapproved against implementing this approach?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFzaK940Vb1Zesx0kRAoeEAJ9rtnci8hDuG67gQqHuMDgv7HVz/gCeJlWu
uV6tiVbsfQochx0xBJRrEI8=
=TPpw
-----END PGP SIGNATURE-----
Re: Descriptor API (was Re: [jira] Commented: (PLUTO-308) This patch
is for new deployment with JAXB instead ...)
Posted by "David H. DeWolf" <dd...@apache.org>.
Christian Raschka wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thank you David for your comment. Now i think, there are two possible
> workarounds for this problem:
Sure, thanks for all the work you've done and discussing it on the list :)
>
> 1. we annotate the existing *DD classes with JAXB annotations
> 2. the JAXB classes extend the *DD classes.
I would add a third:
3. Translate JAXB model into the DD model upon retrieval.
>
> Both has pros and cons. I would prefer the first one but i don't know if
> its possible.
I believe the first would be ideal, but also don't know if it's
possible. I really should dive into JAXB more :)
I'd hesitate to do the second if the JAXB versions would contain uniqe
properties that would only be accessible through casting. This would
remove the transparency of the services..
The third possibility could be expensive, however, reading of
descriptors should probably be limited once per portlet app - so I
wouldn't be too concerned with that aspect.
What do others think?
>
> What do you think about it?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFy0IB40Vb1Zesx0kRAiMbAJ9IeV+YwDURcxqJluQ0zFH3V+cRZACfTe11
> IO4NL36XruQnQk3c0NbXiK0=
> =deZJ
> -----END PGP SIGNATURE-----
>
Re: Descriptor API (was Re: [jira] Commented: (PLUTO-308) This patch
is for new deployment with JAXB instead ...)
Posted by Christian Raschka <ch...@cs.uni-jena.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thank you David for your comment. Now i think, there are two possible
workarounds for this problem:
1. we annotate the existing *DD classes with JAXB annotations
2. the JAXB classes extend the *DD classes.
Both has pros and cons. I would prefer the first one but i don't know if
its possible.
What do you think about it?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFy0IB40Vb1Zesx0kRAiMbAJ9IeV+YwDURcxqJluQ0zFH3V+cRZACfTe11
IO4NL36XruQnQk3c0NbXiK0=
=deZJ
-----END PGP SIGNATURE-----
Descriptor API (was Re: [jira] Commented: (PLUTO-308) This patch
is for new deployment with JAXB instead ...)
Posted by "David H. DeWolf" <dd...@apache.org>.
Christian Raschka wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Why do you think, this breaks backwards compatibility?
Because the impression I got from reading the initial description was
that you removed all of the DD classes in lieu of the JAXB Types. After
looking in more detail at the patch, it looks like you've just
duplicated the descriptor services so that they can use jaxb generated
companions.
While this will help compatibility, I still don't think it's ideal. The
descriptor services are intended to be interfaces which provide a clean
facade for accessing the descriptors. Clients should not care which
service implementation they are using, instead, they should simply
utilize the interface methods to retrieve a generic model. Introducing
a JAXB specific service negates this transparency.
>
> - ---
>
> There is a problem with the castor classes: many types aren't similar to
> the portlet XMLSchema. E.g. in IconDD there are String smallIcon and
> String largeIcon. The xsd says, that this have to be PathType (which is
> an extend to String). The JAXB Codegeneration does it well.
Don't things like PathType simply provide xsd level validation over the
format of the String? Looking at the PathType defined in the patch, it
adds no members, methods, etc. . .which differentiate it from a String.
In these cases, I see nothing wrong with using a String to
encapsultate the data. What value does the PathType class provide?
That said, I'm sure there are arguments to be made about modifications
to the DD (Descriptor) classes. By all means, we should make those
modifications when possible, but simply throwing away an entire object
model and forcing those using pluto to digest a totally new one seems
extreme. If nothing else (not ideal, but will work), couldn't we
provide decorations of the Type classes to adapt them to the DD model?
>
> The other point is, that in the castor *DD classes there aren't all
> nesessary methods and fields.
But there's nothing preventing anyone from adding them. Right? In
fact, several have just been added to the trunk due to jira tickets that
were filed.
>
> If we make an interface (e.g. Icon) to both support Castor and JAXB, we
> have to reimplement nearly all castor classes and the corresponding
> castor binding.
This is a simple model. I don't see a reason to introduce interfaces.
There's not logic we'll want to provide different implementations of.
This is simply an encapsulation of data we're talking about.
>
> What is the best way, to solve this problem?
I won't claim to be a JAXB expert, so I'm not sure. My only comment
would be that we should discuss this before introducing a brand new set
of interfaces and associated model. Perhaps the best solution is to
deprecate the old service and replace it with a new one, but I will
still argue that it should be done in an implementation specific manner
so that if someone wanted to utilize a different service implementation
they could. Of course, the JAXBDescriptorService may be just a naming
issue, but I tend to think it's a little more than that. . .
Thoughts?
David
> Christian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFyylg40Vb1Zesx0kRAjoqAJ9NNNlhgV8SjUOF4WwBxnDTnSIYZQCcDhaE
> lL4RcOkR6KoZICMh3/k3D50=
> =prAo
> -----END PGP SIGNATURE-----
>
Re: [jira] Commented: (PLUTO-308) This patch is for new deployment
with JAXB instead of castor and the changes for the new API Revision from
8 to 11.
Posted by Christian Raschka <ch...@cs.uni-jena.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Why do you think, this breaks backwards compatibility?
- ---
There is a problem with the castor classes: many types aren't similar to
the portlet XMLSchema. E.g. in IconDD there are String smallIcon and
String largeIcon. The xsd says, that this have to be PathType (which is
an extend to String). The JAXB Codegeneration does it well.
The other point is, that in the castor *DD classes there aren't all
nesessary methods and fields.
If we make an interface (e.g. Icon) to both support Castor and JAXB, we
have to reimplement nearly all castor classes and the corresponding
castor binding.
What is the best way, to solve this problem?
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFyylg40Vb1Zesx0kRAjoqAJ9NNNlhgV8SjUOF4WwBxnDTnSIYZQCcDhaE
lL4RcOkR6KoZICMh3/k3D50=
=prAo
-----END PGP SIGNATURE-----
Re: [jira] Commented: (PLUTO-308) This patch is for new deployment
with JAXB instead of castor and the changes for the new API Revision from
8 to 11.
Posted by Christian Raschka <ch...@informatik.uni-jena.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Why do you think, this breaks backwards compatibility?
- ---
There is a problem with the castor classes: many types aren't similar to
the portlet XMLSchema. E.g. in IconDD there are String smallIcon and
String largeIcon. The xsd says, that this have to be PathType (which is
an extend to String). The JAXB Codegeneration does it well.
The other point is, that in the castor *DD classes there aren't all
nesessary methods and fields.
If we make an interface (e.g. Icon) to both support Castor and JAXB, we
have to reimplement nearly all castor classes and the corresponding
castor binding.
What is the best way, to solve this problem?
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFyym940Vb1Zesx0kRAgWlAJ9uO48nPbjgy9dHCd8MlKglUaTaagCfY8yN
RugJpKiyXMZDGNKrCcvZddI=
=5gJu
-----END PGP SIGNATURE-----