date:20130712

OSGi support

2013-07-12 Thread John D. Ament

Hi all

I was curious about our OSGi support.  From what I've seen, it looks like
we mostly handle import and export packages, as well as some pax stuff.
 Has anyone tried packaging this into their apps?

[jira] [Updated] (DELTASPIKE-287) re-visit @InvocationOrder

2013-07-12 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-287:


Affects Version/s: (was: 0.4)
Fix Version/s: 1.0.1

> re-visit @InvocationOrder
> -
>
> Key: DELTASPIKE-287
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-287
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Core
>Reporter: Gerhard Petracek
>Assignee: Gerhard Petracek
> Fix For: 1.0.1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DELTASPIKE-350) re-visit @Matches

2013-07-12 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek updated DELTASPIKE-350:


Fix Version/s: (was: 0.5)
   1.0.1

> re-visit @Matches
> -
>
> Key: DELTASPIKE-350
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-350
> Project: DeltaSpike
>  Issue Type: New Feature
>Affects Versions: 0.4
>Reporter: Gerhard Petracek
> Fix For: 1.0.1
>
>
> possible use-cases:
> @CustomStaticQuota(perDay = 1) //gets picked up via meta-data-inheritance
> interface Pages
> {
> interface Public extends ViewConfig, ViewQuota.PDF, ViewQuota.XML, ZIP
> {
> @CustomUrlMapping("/item/#{item}/")
> class Item implements Public
> {
> }
> }
> //folder - because it's of type ViewConfig
> interface Private extends ViewConfig
> {
> }
> interface ViewQuota //technically not(!) needed (see ZIP) - just for 
> better grouping
> {
> @Matches(pattern = "*.xml")
> interface XML
> {
> }
> @Matches(pattern = "*.pdf")
> @CustomStaticQuota(perDay = 100) //overrule quota
> interface PDF
> {
> }
> }
> @Matches(pattern = "*.zip")
> interface ZIP
> {
> }
> }
> @ViewMetaData
> @interface CustomStaticQuota
> {
> int perDay();
> }
> @ViewMetaData
> @interface CustomUrlMapping
> {
> String value();
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (DELTASPIKE-368) Move KEYS and deltaspike files to root directory

2013-07-12 Thread Gerhard Petracek (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek closed DELTASPIKE-368.
---

Resolution: Won't Fix

> Move KEYS and deltaspike files to root directory
> 
>
> Key: DELTASPIKE-368
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-368
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Build
>Reporter: Bruno Leonardo Gonçalves
>Priority: Minor
>
> We could move the files of deltaspike directory and KEYS file to the root of 
> the repository tree, avoiding redundancy in names. For example, the 
> openwebbeans repository keeps the files KEYS, LICENSE and NOTICE in the root 
> directory together with all assets and modules, maintaining the directory 
> structure of the project clearer.
> This change proceeds or there are other points to keep the project structure 
> in its own directory?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Data Module

2013-07-12 Thread Jason Porter

On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau
wrote:

> Ps: you can make a cdi bean an ejb from cdi extension
>

No, the bootstrapping for each container do not communicate to my knowledge.


> Le 12 juil. 2013 08:12, "Romain Manni-Bucau"  a
> écrit :
>
> > Hi
> >
> > Depending the case DTO are not an option.
> >
> > I agree in rest app i wouldnt it but if not possible (maybe through
> > another Bean) it would kill this module for half of the usages i see
> since
> > i'd need to add this layer.
> > Le 12 juil. 2013 06:55, "hantsy"  a écrit :
> >
> >> No DTO please, data module for data access, why we care about DTO.
> >>
> >> A question about the data, the difference for EJB and none EJB
> >> environment.
> >>
> >> if possible in a EJB envoriment, proxy the Repository and add @Stateless
> >> and transaction declaration to Repository automatically at runtime.
> >>
> >> Regards
> >>
> >> Hantsy
> >> On 7/10/2013 23:23, Thomas Hug wrote:
> >> > I wouldn't label the feature with DTO but rather as some general
> result
> >> > transformation - might also be useful for e.g. native queries. Going
> >> back
> >> > to the API suggestion, from that perspective such an annotation should
> >> > probably also work on method level, so I'd keep the forEntity out
> there.
> >> >
> >> >
> >> > On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament <
> john.d.am...@gmail.com
> >> >wrote:
> >> >
> >> >> Personally, I don't like this idea.
> >> >>
> >> >> A DAO should do DAO stuff.
> >> >> A DTO should do DTO stuff.
> >> >>
> >> >> The transformation of your entities into some other POJO shouldn't be
> >> >> inside your DAO.
> >> >>
> >> >> Right now, I use google guava to do DTO work on entities going back
> and
> >> >> forth over a REST API.  Works well IMHO.
> >> >>
> >> >> John
> >> >>
> >> >>
> >> >> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
> >> >> wrote:
> >> >>
> >> >>> globally my answer meant "if forEntity is sometimes mandatory,
> >> sometimes
> >> >>> not this is maybe not the right place"
> >> >>>
> >> >>> i thought to add it to mapper config
> >> >>>
> >> >>> *Romain Manni-Bucau*
> >> >>> *Twitter: @rmannibucau *
> >> >>> *Blog: **http://rmannibucau.wordpress.com/*<
> >> >>> http://rmannibucau.wordpress.com/>
> >> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >> >>> *Github: https://github.com/rmannibucau*
> >> >>>
> >> >>>
> >> >>>
> >> >>> 2013/7/10 Thomas Hug 
> >> >>>
> >>  Making forEntity non-optional would then be redundant for the
> regular
> >> >>> cases
> >>  using the base interface, so I wouldn't. But I see that it should
> be
> >>  clearly documented then as things might get confusing...
> >> 
> >> 
> >>  On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> >>  wrote:
> >> 
> >> > do you mean you force forEntity = Person.class?
> >> >
> >> > looks ok for me since the only constraint is to add the dto types
> >>  somewhere
> >> > :)
> >> >
> >> > *Romain Manni-Bucau*
> >> > *Twitter: @rmannibucau *
> >> > *Blog: **http://rmannibucau.wordpress.com/*<
> >> > http://rmannibucau.wordpress.com/>
> >> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >> > *Github: https://github.com/rmannibucau*
> >> >
> >> >
> >> >
> >> > 2013/7/10 Thomas Hug 
> >> >
> >> >> Hmm and I assumed DTOs are dead and buried :-)
> >> >>
> >> >> Packing this in the base interface feels kind of clunky to me -
> >> >> also
> >> >> considering that there are repositories without the need to
> extend
> >> >>> the
> >> > base
> >> >> interface. What about something like
> >> >>
> >> >> @Repository(forEntity = Person.class)
> >> >> @ResultMapper(entityMapper = MapperX.class, keyMapper =
> >> >>> MapperY.class)
> >> >> public interface PersonRepository extends
> >> >> EntityRepository >> >> DtoPk> { ... }
> >> >>
> >> >> Having the Entity on @Repository takes precedence and the type
> >>  parameters
> >> >> are in this case just for convenience.
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau
> >> >> wrote:
> >> >>
> >> >>> +1
> >> >>>
> >> >>> just to complete this thread the main issue is not the
> >> >>> implementation
> >> > but
> >> >>> the exposed API:
> >> >>>
> >> >>> public interface EntityRepository
> >> >>>
> >> >>> would become
> >> >>>
> >> >>> public interface EntityDtoRepository >> >>> Dto,
> >> >>> DtoPk>
> >> >>>
> >> >>> *Romain Manni-Bucau*
> >> >>> *Twitter: @rmannibucau *
> >> >>> *Blog: **http://rmannibucau.wordpress.com/*<
> >> >>> http://rmannibucau.wordpress.com/>
> >> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >> >>> *Github: https://github.com/rmannibucau*
> >> >>>
> >> >>>

Re: Data Module

2013-07-12 Thread Romain Manni-Bucau

@John: oops, was a type, "can" was "cannot", i meant adding @stateless will
do nothing.

about dto or not both are needed, i dont propose to force it, i just
mention it is common to need it.

the proposed API sounds fine for me.

I don't want this thread to be a troll, dto usage depends on the
architecture of the app and that's not the role of DS to say it is good or
not (the answer would obviously be wrong here ;).

DTO (or whatever name you want) are larger than entity/other object, it can
always be data cleanup. So basically we need a layer to be able to modify
what is returned, nothing more.

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/7/12 John D. Ament 

> Yep, if you want to do it in the JPA layer you can do something like that.
>
> In my case, my front end data objects aren't exposed to our JPA libraries,
> so it's not an option.
>
> @Romain
>
> How do you make a CDI object a remote EJB? Or are you referring to
> transactional state? As far as I know, you cannot setup an MDB in a CDI
> extension.
>
>
> On Fri, Jul 12, 2013 at 6:59 AM, hantsy  wrote:
>
> > Your requirement is based on your experience, i do not think a must in
> > REST application.
> >
> > Some case we can wrap the result in query result like this.
> >
> > select new UserResult(name, email ) from  User u
> >
> > to get a  ValueObject directly.
> >
> >
> > Hantsy
> > On 7/12/2013 14:12, Romain Manni-Bucau wrote:
> > > Hi
> > >
> > > Depending the case DTO are not an option.
> > >
> > > I agree in rest app i wouldnt it but if not possible (maybe through
> > another
> > > Bean) it would kill this module for half of the usages i see since i'd
> > need
> > > to add this layer.
> > > Le 12 juil. 2013 06:55, "hantsy"  a écrit :
> > >
> > >> No DTO please, data module for data access, why we care about DTO.
> > >>
> > >> A question about the data, the difference for EJB and none EJB
> > environment.
> > >>
> > >> if possible in a EJB envoriment, proxy the Repository and add
> @Stateless
> > >> and transaction declaration to Repository automatically at runtime.
> > >>
> > >> Regards
> > >>
> > >> Hantsy
> > >> On 7/10/2013 23:23, Thomas Hug wrote:
> > >>> I wouldn't label the feature with DTO but rather as some general
> result
> > >>> transformation - might also be useful for e.g. native queries. Going
> > back
> > >>> to the API suggestion, from that perspective such an annotation
> should
> > >>> probably also work on method level, so I'd keep the forEntity out
> > there.
> > >>>
> > >>>
> > >>> On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament <
> john.d.am...@gmail.com
> > >>> wrote:
> > >>>
> >  Personally, I don't like this idea.
> > 
> >  A DAO should do DAO stuff.
> >  A DTO should do DTO stuff.
> > 
> >  The transformation of your entities into some other POJO shouldn't
> be
> >  inside your DAO.
> > 
> >  Right now, I use google guava to do DTO work on entities going back
> > and
> >  forth over a REST API.  Works well IMHO.
> > 
> >  John
> > 
> > 
> >  On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
> >  wrote:
> > 
> > > globally my answer meant "if forEntity is sometimes mandatory,
> > >> sometimes
> > > not this is maybe not the right place"
> > >
> > > i thought to add it to mapper config
> > >
> > > *Romain Manni-Bucau*
> > > *Twitter: @rmannibucau *
> > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > http://rmannibucau.wordpress.com/>
> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > *Github: https://github.com/rmannibucau*
> > >
> > >
> > >
> > > 2013/7/10 Thomas Hug 
> > >
> > >> Making forEntity non-optional would then be redundant for the
> > regular
> > > cases
> > >> using the base interface, so I wouldn't. But I see that it should
> be
> > >> clearly documented then as things might get confusing...
> > >>
> > >>
> > >> On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> > >> wrote:
> > >>
> > >>> do you mean you force forEntity = Person.class?
> > >>>
> > >>> looks ok for me since the only constraint is to add the dto types
> > >> somewhere
> > >>> :)
> > >>>
> > >>> *Romain Manni-Bucau*
> > >>> *Twitter: @rmannibucau *
> > >>> *Blog: **http://rmannibucau.wordpress.com/*<
> > >>> http://rmannibucau.wordpress.com/>
> > >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > >>> *Github: https://github.com/rmannibucau*
> > >>>
> > >>>
> > >>>
> > >>> 2013/7/10 Thomas Hug 
> > >>>
> >  Hmm and I assumed DTOs are dead and buried :-)
> > 
> >  Packing this in the ba

Re: Data Module

2013-07-12 Thread John D. Ament

Yep, if you want to do it in the JPA layer you can do something like that.

In my case, my front end data objects aren't exposed to our JPA libraries,
so it's not an option.

@Romain

How do you make a CDI object a remote EJB? Or are you referring to
transactional state? As far as I know, you cannot setup an MDB in a CDI
extension.


On Fri, Jul 12, 2013 at 6:59 AM, hantsy  wrote:

> Your requirement is based on your experience, i do not think a must in
> REST application.
>
> Some case we can wrap the result in query result like this.
>
> select new UserResult(name, email ) from  User u
>
> to get a  ValueObject directly.
>
>
> Hantsy
> On 7/12/2013 14:12, Romain Manni-Bucau wrote:
> > Hi
> >
> > Depending the case DTO are not an option.
> >
> > I agree in rest app i wouldnt it but if not possible (maybe through
> another
> > Bean) it would kill this module for half of the usages i see since i'd
> need
> > to add this layer.
> > Le 12 juil. 2013 06:55, "hantsy"  a écrit :
> >
> >> No DTO please, data module for data access, why we care about DTO.
> >>
> >> A question about the data, the difference for EJB and none EJB
> environment.
> >>
> >> if possible in a EJB envoriment, proxy the Repository and add @Stateless
> >> and transaction declaration to Repository automatically at runtime.
> >>
> >> Regards
> >>
> >> Hantsy
> >> On 7/10/2013 23:23, Thomas Hug wrote:
> >>> I wouldn't label the feature with DTO but rather as some general result
> >>> transformation - might also be useful for e.g. native queries. Going
> back
> >>> to the API suggestion, from that perspective such an annotation should
> >>> probably also work on method level, so I'd keep the forEntity out
> there.
> >>>
> >>>
> >>> On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament  >>> wrote:
> >>>
>  Personally, I don't like this idea.
> 
>  A DAO should do DAO stuff.
>  A DTO should do DTO stuff.
> 
>  The transformation of your entities into some other POJO shouldn't be
>  inside your DAO.
> 
>  Right now, I use google guava to do DTO work on entities going back
> and
>  forth over a REST API.  Works well IMHO.
> 
>  John
> 
> 
>  On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
>  wrote:
> 
> > globally my answer meant "if forEntity is sometimes mandatory,
> >> sometimes
> > not this is maybe not the right place"
> >
> > i thought to add it to mapper config
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau *
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/7/10 Thomas Hug 
> >
> >> Making forEntity non-optional would then be redundant for the
> regular
> > cases
> >> using the base interface, so I wouldn't. But I see that it should be
> >> clearly documented then as things might get confusing...
> >>
> >>
> >> On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
> >> wrote:
> >>
> >>> do you mean you force forEntity = Person.class?
> >>>
> >>> looks ok for me since the only constraint is to add the dto types
> >> somewhere
> >>> :)
> >>>
> >>> *Romain Manni-Bucau*
> >>> *Twitter: @rmannibucau *
> >>> *Blog: **http://rmannibucau.wordpress.com/*<
> >>> http://rmannibucau.wordpress.com/>
> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> >>> *Github: https://github.com/rmannibucau*
> >>>
> >>>
> >>>
> >>> 2013/7/10 Thomas Hug 
> >>>
>  Hmm and I assumed DTOs are dead and buried :-)
> 
>  Packing this in the base interface feels kind of clunky to me -
>  also
>  considering that there are repositories without the need to extend
> > the
> >>> base
>  interface. What about something like
> 
>  @Repository(forEntity = Person.class)
>  @ResultMapper(entityMapper = MapperX.class, keyMapper =
> > MapperY.class)
>  public interface PersonRepository extends
>  EntityRepository  DtoPk> { ... }
> 
>  Having the Entity on @Repository takes precedence and the type
> >> parameters
>  are in this case just for convenience.
> 
> 
> 
>  On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau
>  wrote:
> 
> > +1
> >
> > just to complete this thread the main issue is not the
> > implementation
> >>> but
> > the exposed API:
> >
> > public interface EntityRepository
> >
> > would become
> >
> > public interface EntityDtoRepository > Dto,
> > DtoPk>
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau

Re: Data Module

2013-07-12 Thread hantsy

Your requirement is based on your experience, i do not think a must in
REST application.

Some case we can wrap the result in query result like this.

select new UserResult(name, email ) from  User u

to get a  ValueObject directly.


Hantsy
On 7/12/2013 14:12, Romain Manni-Bucau wrote:
> Hi
>
> Depending the case DTO are not an option.
>
> I agree in rest app i wouldnt it but if not possible (maybe through another
> Bean) it would kill this module for half of the usages i see since i'd need
> to add this layer.
> Le 12 juil. 2013 06:55, "hantsy"  a écrit :
>
>> No DTO please, data module for data access, why we care about DTO.
>>
>> A question about the data, the difference for EJB and none EJB environment.
>>
>> if possible in a EJB envoriment, proxy the Repository and add @Stateless
>> and transaction declaration to Repository automatically at runtime.
>>
>> Regards
>>
>> Hantsy
>> On 7/10/2013 23:23, Thomas Hug wrote:
>>> I wouldn't label the feature with DTO but rather as some general result
>>> transformation - might also be useful for e.g. native queries. Going back
>>> to the API suggestion, from that perspective such an annotation should
>>> probably also work on method level, so I'd keep the forEntity out there.
>>>
>>>
>>> On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament >> wrote:
>>>
 Personally, I don't like this idea.

 A DAO should do DAO stuff.
 A DTO should do DTO stuff.

 The transformation of your entities into some other POJO shouldn't be
 inside your DAO.

 Right now, I use google guava to do DTO work on entities going back and
 forth over a REST API.  Works well IMHO.

 John


 On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau
 wrote:

> globally my answer meant "if forEntity is sometimes mandatory,
>> sometimes
> not this is maybe not the right place"
>
> i thought to add it to mapper config
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau *
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/7/10 Thomas Hug 
>
>> Making forEntity non-optional would then be redundant for the regular
> cases
>> using the base interface, so I wouldn't. But I see that it should be
>> clearly documented then as things might get confusing...
>>
>>
>> On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau
>> wrote:
>>
>>> do you mean you force forEntity = Person.class?
>>>
>>> looks ok for me since the only constraint is to add the dto types
>> somewhere
>>> :)
>>>
>>> *Romain Manni-Bucau*
>>> *Twitter: @rmannibucau *
>>> *Blog: **http://rmannibucau.wordpress.com/*<
>>> http://rmannibucau.wordpress.com/>
>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>> *Github: https://github.com/rmannibucau*
>>>
>>>
>>>
>>> 2013/7/10 Thomas Hug 
>>>
 Hmm and I assumed DTOs are dead and buried :-)

 Packing this in the base interface feels kind of clunky to me -
 also
 considering that there are repositories without the need to extend
> the
>>> base
 interface. What about something like

 @Repository(forEntity = Person.class)
 @ResultMapper(entityMapper = MapperX.class, keyMapper =
> MapperY.class)
 public interface PersonRepository extends
 EntityRepository>>> DtoPk> { ... }

 Having the Entity on @Repository takes precedence and the type
>> parameters
 are in this case just for convenience.



 On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau
 wrote:

> +1
>
> just to complete this thread the main issue is not the
> implementation
>>> but
> the exposed API:
>
> public interface EntityRepository
>
> would become
>
> public interface EntityDtoRepository Dto,
> DtoPk>
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau *
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/7/10 Jean-Louis MONTEIRO 
>
>> Hello guys,
>>
>> Just used DS Data module yesturday, and I was wondering if we
> could
 add a
>> feature allowing on-the-fly conversion to DTO.
>> For example, we could use modelmapper (or similar to convert
 DAO
>>> return
>> values to DTO objects).
>>
>> Adding a

OSGi support

[jira] [Updated] (DELTASPIKE-287) re-visit @InvocationOrder

[jira] [Updated] (DELTASPIKE-350) re-visit @Matches

[jira] [Closed] (DELTASPIKE-368) Move KEYS and deltaspike files to root directory

Re: Data Module

Re: Data Module

Re: Data Module

Re: Data Module

8 matches

Site Navigation

Mail list logo

Footer information