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 H. DeWolf" <dd...@apache.org> on 2007/02/08 15:26:04 UTC

Descriptor API (was Re: [jira] Commented: (PLUTO-308) This patch is for new deployment with JAXB instead ...)


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: 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-----