Re: where to place a Config-Diff algorigthm

[Jean-Louis MONTEIRO]

>> Some values may have been updated, some might have been deleted and some
>> other added.
>> Returning a set might not be enough, isn't it?

>We really only need the property names which got changed:
>* new ones
>* deleted ones
>* the ones with different values
>
>So a Set is fine.

The thing is that you will get the key of everything that changed which
requires to invalidate the cache for all entries (lock?).
Or you would need to iterate all the keys, compare again old/new and delete
entries from cache, do nothing for add (? they will be lazily added during
lookup maybe) and invalidate the updated values.

That seems to be heavy to handle for nothing has during compare we have all
information already.



Le mar. 5 juin 2018 à 09:10, Mark Struberg  a
écrit :

> Hi JL!
>
> Thanks for the feedback!
> And yes, this will also be important for ConfigJSR (and later mp-config as
> well).
>
>
> > First it's all about config, so maybe having a method name "diff" is
> > enough. No need for "diffConfig".
>
> Well, diff alone is imo a bit too short as it doesn't have any context
> about what to diff.
> Thus I'd prefer diffConfig.
>
>
> > Some values may have been updated, some might have been deleted and some
> > other added.
> > Returning a set might not be enough, isn't it?
>
> We really only need the property names which got changed:
> * new ones
> * deleted ones
> * the ones with different values
>
> So a Set is fine.
>
> LieGrue,
> strub
>
>
> > Am 05.06.2018 um 08:59 schrieb Jean-Louis MONTEIRO :
> >
> > Few thoughts ...
> >
> > I did not follow really deltaspike to be honest, but I do follow
> MP-Config
> > for instance.
> >
> > First it's all about config, so maybe having a method name "diff" is
> > enough. No need for "diffConfig".
> >
> > Some values may have been updated, some might have been deleted and some
> > other added.
> > Returning a set might not be enough, isn't it?
> >
> > Jean-Louis
> >
> >
> >
> >
> >
> >
> > Le mar. 5 juin 2018 à 08:55, Mark Struberg  a
> > écrit :
> >
> >> Hi folks!
> >>
> >> For the new DS-1.9 feature to 'push' config changes we need an algorithm
> >> to detect whether an old and a new config differs.
> >>
> >> The signature would be something like:
> >>
> >> /**
> >> *
> >> * A Set of all the attributes which differ between the old and new
> config
> >> Map. An empty Set if there is no difference.
> >> */
> >> public Set diffConfig(Map oldValues, Map >> String> newValues)
> >>
> >> This is intended for e.g. background threads which read from a database
> >> once per second and compare the old values with the new ones.
> >> If there was any difference then the set of attributes get reported back
> >> to the Config (which in turn clears the caches, etc).
> >>
> >>
> >> Now where to put this method?
> >>
> >> My candidate would be
> >> org.apache.deltaspike.core.api.config.ConfigResolver.ConfigProvider
> >> I do not want to put it into the Config interface itself because it is
> not
> >> a user contract thingy.
> >> And I also do not want to put it into ConfigResolver becasue I'd like to
> >> have the impl only available internally and not bloat the ConfigResolver
> >> any further.
> >>
> >> Wdyt?
> >>
> >> LieGrue,
> >> strub
>
>

Re: where to place a Config-Diff algorigthm

[Jean-Louis MONTEIRO]

Few thoughts ...

I did not follow really deltaspike to be honest, but I do follow MP-Config
for instance.

First it's all about config, so maybe having a method name "diff" is
enough. No need for "diffConfig".

Some values may have been updated, some might have been deleted and some
other added.
Returning a set might not be enough, isn't it?

Jean-Louis






Le mar. 5 juin 2018 à 08:55, Mark Struberg  a
écrit :

> Hi folks!
>
> For the new DS-1.9 feature to 'push' config changes we need an algorithm
> to detect whether an old and a new config differs.
>
> The signature would be something like:
>
> /**
>  *
>  * A Set of all the attributes which differ between the old and new config
> Map. An empty Set if there is no difference.
>  */
> public Set diffConfig(Map oldValues, Map String> newValues)
>
> This is intended for e.g. background threads which read from a database
> once per second and compare the old values with the new ones.
> If there was any difference then the set of attributes get reported back
> to the Config (which in turn clears the caches, etc).
>
>
> Now where to put this method?
>
> My candidate would be
> org.apache.deltaspike.core.api.config.ConfigResolver.ConfigProvider
> I do not want to put it into the Config interface itself because it is not
> a user contract thingy.
> And I also do not want to put it into ConfigResolver becasue I'd like to
> have the impl only available internally and not bloat the ConfigResolver
> any further.
>
> Wdyt?
>
> LieGrue,
> strub

Re: [ANNOUNCE] Release of Apache DeltaSpike 1.6.0

[Jean-Louis MONTEIRO]

Congrats.

Le mer 6 avr. 2016 01:52, Gerhard Petracek  a écrit :

> The Apache DeltaSpike team is pleased to announce the 24th release of
> DeltaSpike.
>
> Apache DeltaSpike is not a CDI-container, but a portable CDI extension.
>
> Documentation:
> http://deltaspike.apache.org/documentation/
>
> Download:
> http://deltaspike.apache.org/download.html
>
> Release Notes:
> http://s.apache.org/DS_1.6.0
>
> Enjoy!
>
> Gerhard Petracek
>

Re: [VOTE] Release of Apache DeltaSpike 1.1.0

[Jean-Louis MONTEIRO]

Very cool to see the project moving forward.
Thank you guys.

2014-11-02 15:58 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com:

 @karl: see e.g. [1]

 regards,
 gerhard

 [1] http://s.apache.org/iua



 2014-11-02 12:31 GMT+01:00 karl.kil...@gmail.com:

  Hello,
 
  It runs well for me. I would like to try the new stuff, any release
 notes?
 
  Thanks for all the work guys!
 
  Cheers
 
   2 nov 2014 kl. 08:05 skrev Romain Manni-Bucau rmannibu...@gmail.com:
  
   +1
   Le 1 nov. 2014 21:49, Gerhard Petracek gerhard.petra...@gmail.com
 a
   écrit :
  
   +1
  
   regards,
   gerhard
  
  
  
   2014-11-01 21:46 GMT+01:00 Gerhard Petracek gpetra...@apache.org:
  
   Hi,
  
   I was running the needed tasks to get the 12th release of Apache
   DeltaSpike out.
   The artifacts are deployed to Nexus [1] (and [2]).
  
   The tag is available at [3] and will get pushed to the ASF repository
   once
   the vote passed.
  
   Please take a look at the 1.1.0 artifacts and vote!
  
   Please note:
   This vote is majority approval with a minimum of three +1 votes
 (see
   [4]).
  
   
   [ ] +1 for community members who have reviewed the bits
   [ ] +0
   [ ] -1 for fatal flaws that should cause these bits not to be
 released,
   and why..
   
  
   Thanks,
   Gerhard
  
   [1]
  
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1015
   [2]
  
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1015/org/apache/deltaspike/deltaspike-project/1.1.0/deltaspike-project-1.1.0-source-release.zip
   [3]
  
 https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.1.0
   [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
  
 




-- 
Jean-Louis

Re: Result (was: Re: [VOTE] logo-color)

[Jean-Louis MONTEIRO]

Awesome


2014-06-17 19:11 GMT+00:00 Gerhard Petracek gpetra...@apache.org:

 thank you for voting!

 most voted for [1] - we have a new logo!

 regards,
 gerhard

 [1] http://s.apache.org/DS_LOGO_BLUE_VOTE2



 2014-06-14 20:55 GMT+02:00 Gerhard Petracek gerhard.petra...@gmail.com:

  hi @ all,
 
  this second vote is about the color and therefore the final logo.
 
  i've uploaded the candidates provided by jim at [1]-[4].
  please send a +1 for one of them.
 
  regards,
  gerhard
 
  [1] http://s.apache.org/DS_LOGO_BLUE_VOTE2
  [2] http://s.apache.org/DS_LOGO_ORANGE_VOTE2
  [3] http://s.apache.org/DS_LOGO_PURPLE_VOTE2
  [4] http://s.apache.org/DS_LOGO_RED_VOTE2
 
 




-- 
Jean-Louis

Re: first steps for the next release

[Jean-Louis MONTEIRO]

Awesome.
Thanks Gerhard


2014-06-07 8:20 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:

 +1, thks Gerhard
 Le 6 juin 2014 21:21, Gerhard Petracek gerhard.petra...@gmail.com a
 écrit :

  hi @ all,
 
  if there are no objections, i will start with the first steps for the
 next
  release (v1.0.0) by the end of next week.
 
  regards,
  gerhard
 




-- 
Jean-Louis

Re: [DISCUSS] next release as 1.0?

[Jean-Louis MONTEIRO]

 v0.x limits our growth
Indeed



2014-05-24 22:45 GMT+02:00 Gerhard Petracek gpetra...@apache.org:

 (as we know) we still have to improve the documentation, examples,...
 however, one of the first impressions is the version number.
 since v0.x limits our growth, i'm ok to release v1.

 regards,
 gerhard



 2014-05-19 13:45 GMT+02:00 Pete Muir pm...@redhat.com:

  Hi all,
 
  (Note Rafael is away on vacation atm, so I am responding partly for him
 ;-)
 
  I definitely agree with getting to 1.0 asap. However also agree that we
  need to make sure we are ready.
 
  If there are issues with docs, please open issues, I know Rafael will be
  pleased to pick any that are open up when he is back from vacation. Same
  for any issues like performance.
 
  I’ve also asked for help with the docs from our docs team at Red Hat.
 This
  would be more of a general edit to make them read nicely, and put them
 in a
  good order for a user to follow, rather than adding new content.
 However, I
  haven’t managed to secure any time before July/August. I will follow up
  with the list when I have some details.
 
  On 19 May 2014, at 12:40, Thomas Andraschko andraschko.tho...@gmail.com
 
  wrote:
 
   +0
   - no logo
   - documentation... there are many TODOs. Also a docu for some for the
   really core features is not available (like Deactivatable).
   - we should check the performance of the modules. (i already openend
 some
   improvements for the JSF module)
  
  
   2014-05-19 12:39 GMT+02:00 Karl Kildén karl.kil...@gmail.com:
  
   Design help for the logo
  
   Saw that mail just now, sounds great :-)
  
  
   On 19 May 2014 12:37, Karl Kildén karl.kil...@gmail.com wrote:
  
   +0 because I would really like to see a logotype selected before 1.0.
  
   I am aware of https://issues.jboss.org/browse/DESIGN-520 and I am
 also
   fine with going with one already proposed. I just feel that every
  project
   needs a good logo
  
  
   On 19 May 2014 11:55, Christian Kaltepoth christ...@kaltepoth.de
   wrote:
  
   +1
  
  
   2014-05-19 11:34 GMT+02:00 Romain Manni-Bucau 
 rmannibu...@gmail.com
  :
  
   +1
  
  
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
   2014-05-19 11:13 GMT+02:00 Mark Struberg strub...@yahoo.de:
  
   Hi!
  
   Is there ANYTHING which holds us back from moving our version to
   1.0?
  
   We are long overdue and there are SOOO many companies using
   DeltaSpike in
   production since years now...
  
   LieGrue,
   strub
  
  
  
  
  
   --
   Christian Kaltepoth
   Blog: http://blog.kaltepoth.de/
   Twitter: http://twitter.com/chkal
   GitHub: https://github.com/chkal
  
  
  
  
 
 




-- 
Jean-Louis

Re: [COMMUNITY] DeltaSpike += Rafael Benevides

[Jean-Louis MONTEIRO]

Congrats.


2014-05-20 4:26 GMT-07:00 Gerhard Petracek gpetra...@apache.org:

 The DeltaSpike PMC is proud to announce a new addition to our community.

 Please welcome Rafael Benevides as the newest DeltaSpike committer!

 @Rafael:
 Please add yourself to the developers section (in
 deltaspike/parent/pom.xml).

 Welcome  regards,
 Gerhard




-- 
Jean-Louis

Re: [VOTE] Release of Apache DeltaSpike 0.7

[Jean-Louis MONTEIRO]

Looks good guys.
+1

JLouis


2014-05-01 23:06 GMT+02:00 Mark Struberg strub...@yahoo.de:

 +1

 LieGrue,
 strub





  On Thursday, 1 May 2014, 17:12, Cody Lerum cody.le...@gmail.com wrote:
   +1
 
  builds and tests weld and owb fine on win 8.1 x64 7u51
 
 
  On Wed, Apr 30, 2014 at 2:22 PM, Gerhard Petracek gpetra...@apache.org
  wrote:
   Hi,
 
   I was running the needed tasks to get the 7th release of Apache
 DeltaSpike
   out.
   The artifacts are deployed to Nexus [1] (and [2]).
 
   The tag is available at [3] and will get pushed to the ASF repository
 once
   the vote passed.
 
   Please take a look at the 0.7 artifacts and vote!
 
   Please note:
   This vote is majority approval with a minimum of three +1 votes
  (see [4]).
 
   
   [ ] +1 for community members who have reviewed the bits
   [ ] +0
   [ ] -1 for fatal flaws that should cause these bits not to be
 released, and
   why..
   
 
   Thanks,
   Gerhard
 
   [1]
 
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1003/
   [2]
 
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1003/org/apache/deltaspike/deltaspike-project/0.7/deltaspike-project-0.7-source-release.zip
   [3]
 https://github.com/os890/deltaspike-vote/tree/deltaspike-project-0.7
   [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
 




-- 
Jean-Louis

Re: [DISCUSS] releases

[Jean-Louis MONTEIRO]

Awesome.
Looking forward to give that a try.

JLouis


2014-04-04 9:49 GMT+02:00 Mark Struberg strub...@yahoo.de:

 +1

 LieGrue,
 strub


 On Thursday, 3 April 2014, 16:55, Thomas Andraschko 
 andraschko.tho...@gmail.com wrote:

 +1
 
 
 
 2014-04-03 16:14 GMT+02:00 Rafael Benevides benevi...@redhat.com:
 
  +1
 
  I like continuous releases to mitigate risk and it also gives the
 feeling
  to the early adopters and users that the project is being updated
 without
  the need to check the sources ;)
 
  Em 03/04/14 09:49, Christian Kaltepoth escreveu:
 
   +1
 
 
  2014-04-03 14:44 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
 
   +1
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2014-04-03 14:42 GMT+02:00 Gerhard Petracek 
 gerhard.petra...@gmail.com
  :
 
  hi @ all,
 
  initially we agreed on releasing early and often.
  so far the average was ~3 releases per year. imo it should be more
 like
 
  1-2
 
  releases every quarter (for sure depending on the resolved tickets).
 
  if there are no objections, we could do the next release in about a
 
  month.
 
  regards,
  gerhard
 
 
 
 
 
 
 
 




-- 
Jean-Louis

Re: Deactivation DeltaSpikeContextExtension

[Jean-Louis MONTEIRO]

Thanks Gerhard


2014-02-27 12:27 GMT+01:00 Gerhard Petracek gerhard.petra...@gmail.com:

 done - thx for the review.

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2014-02-27 11:52 GMT+01:00 Jean-Louis MONTEIRO jeano...@gmail.com:

  Hello guys,
 
  Would be great to make that extension deactivable.
  FYI, http://deltaspike.apache.org/spi.html is wrong.
 
  The key for the property should
  be org.apache.deltaspike.core.spi.activation.ClassDeactivator and not
  org.apache.deltaspike.core.api.activation.ClassDeactivator
 
  Thanks
 
  --
  Jean-Louis
 




-- 
Jean-Louis

Re: [Discuss] Data Module - Transactional Repositories

[Jean-Louis MONTEIRO]

+1 for 2/ as well.
That is right from an end user experience point of view.
Also right to reuse and put in common some parts of JPA and Data module
Closer to Java EE 7 @Transactional approach

JLouis



2014-02-12 11:20 GMT+01:00 Thomas Hug thomas@gmail.com:

 Not sure where we stopped in the discussion but AFAIR we had two approaches
 here:

 1) An automatic internal tx handling if one is needed by the query,
 probably similar to what the JPA module does in the
 EnvironmentAwareTransactionStrategy. Could eventually be controlled by an
 attribute on @Repository defaulting to active.

 2) Integration with @Transactional of the JPA module. For this we'd also
 have to look at:
 - Aligning EntityManager resolution between the two modules. That could
 include moving the EntityManagerResolver into the JPA module API and
 eventually removing the current qualifier-based resolution. That one would
 need some more thoughts to get out something consistent.
 -  Eventually exposing the resolved EM @TransactionScoped so the repository
 can easily access it.
 - Deal with PartialBeans not picking up interceptors - AFAIR this was
 reported to be an issue on some Weld versions?

 +1 on 2) - makes for me much more sense from a user perspective.




-- 
Jean-Louis

Re: [jira] [Commented] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs

[Jean-Louis MONTEIRO]

Thanks Thomas.
Will you do that yourself, or do you want me to do the arquillian test and
submit a new patch?

JLouis


2014-02-07 Thomas Hug (JIRA) j...@apache.org:


 [
 https://issues.apache.org/jira/browse/DELTASPIKE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894286#comment-13894286]

 Thomas Hug commented on DELTASPIKE-518:
 ---

 Looks good. I'd prefer an Arquillian test though so we can also get rid of
 the OpenJPA test dependency.

  DS Data should support Wrapped JPA APIs
  ---
 
  Key: DELTASPIKE-518
  URL:
 https://issues.apache.org/jira/browse/DELTASPIKE-518
  Project: DeltaSpike
   Issue Type: Bug
   Components: Data-Module
 Affects Versions: 0.5
 Reporter: Jean-Louis MONTEIRO
 Assignee: Romain Manni-Bucau
  Fix For: 0.6
 
  Attachments: DELTASPIKE-518.patch
 
 
  In containers like TomEE, you usually don't get the provider
 implementation directly but a wrapper instead. Currently, DS data fails
 saying it does not know the provider.



 --
 This message was sent by Atlassian JIRA
 (v6.1.5#6160)




-- 
Jean-Louis

Re: [DISCUSS] DeltaSpike Launch Module

[Jean-Louis MONTEIRO]

+1
The core is very stable.
Users are afraid by 0.5 or 0.6 in terms of quality.
From my experience with DS, core module at least is very stable.

JSF and Data work fine as well.
Currently, we don't have a 1.0 mainly because some other modules are not
totally merged nor stable maybe, right?

Jean-Louis


2014-02-07 Mark Struberg strub...@yahoo.de:

 Agree, it sounds good but I'd rather focus on (finnally!) shipping DS-1.0
 for now.

 I'll give it a tough test drive in the next weeks to see what we miss
 before the milestone.

 John, you could probably do a draft on github?

 LieGrue,
 stru




 On Friday, 7 February 2014, 6:15, Romain Manni-Bucau 
 rmannibu...@gmail.com wrote:

 Hi
 
 I see the use case but deltaspike needs so much work on existing code
 (jsf,
 security, transactional, data for the one I see) that I think we shouldnt
 add new things while we dont propose something working fine out of the
 box.
 
 Wdyt?
 
 Le 7 févr. 2014 02:31, John D. Ament john.d.am...@gmail.com a écrit :
 
  Hi all
 
  I've been working a bit on a POC.  The idea is to run a light weight
  Java SE application that does some basic bootstrapping and container
  services. The SE app would be configured with a basic socket listener
  using Netty and delegate requests to a REST provider.  The idea behind
  it is that CDI forms the low level core of the container, where a
  developer can deploy services they build on their own.  The
  application is meant to be an API type server (deploy REST APIs) that
  runs using Netty, starts up a CDI container using DeltaSpike Container
  Control API.  The launch module would handle the basic bootstrap of
  the rest provider, instantiating the CDI container using
  ContainerControl, and handle the necessary bootstrap for lookup up
  resources and registering with the provider.  This type of module
  would compete with Spring Boot.
 
  Currently what I have leverages Weld 2.1.1 and RestEasy.  The
  equivalent should work for CXF.  There's no hard dependency on Weld.
 
  I was thinking the module structure would include an api, spi,
  impl-resteasy and impl-cxf.
 
  Some things I'd like to add:
 
  - Automatic bootstrap of JPA (via JPA module)
  - Transaction intercepting (probably need to pull in the Geronimo lib)
  - Probably also register some providers automatically as well.
 
  Let me know your thoughts.
 
  John
 
 
 




-- 
Jean-Louis

Re: [jira] [Commented] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs

[Jean-Louis MONTEIRO]

Hello guys,

Just submitted a patch for that issue.
There is also a test case now.

Would be great if someone car have a look and lemme know.

In my opinion, the unwrap method should be used in any case and we could
simplify all the factory stuff and remove the 3 implementations I guess.

Happy to give it a try if you want.
Jean-Louis




2014-02-06 Romain Manni-Bucau (JIRA) j...@apache.org:


 [
 https://issues.apache.org/jira/browse/DELTASPIKE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893437#comment-13893437]

 Romain Manni-Bucau commented on DELTASPIKE-518:
 ---

 +1 sirona is doing it as well

  DS Data should support Wrapped JPA APIs
  ---
 
  Key: DELTASPIKE-518
  URL:
 https://issues.apache.org/jira/browse/DELTASPIKE-518
  Project: DeltaSpike
   Issue Type: Bug
   Components: Data-Module
 Affects Versions: 0.5
 Reporter: Jean-Louis MONTEIRO
 
  In containers like TomEE, you usually don't get the provider
 implementation directly but a wrapper instead. Currently, DS data fails
 saying it does not know the provider.



 --
 This message was sent by Atlassian JIRA
 (v6.1.5#6160)




-- 
Jean-Louis

[jira] [Updated] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs

[Jean-Louis MONTEIRO (JIRA)]

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

Jean-Louis MONTEIRO updated DELTASPIKE-518:
---

Attachment: DELTASPIKE-518.patch

Here is a patch.


 DS Data should support Wrapped JPA APIs
 ---

 Key: DELTASPIKE-518
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-518
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 0.5
Reporter: Jean-Louis MONTEIRO
 Attachments: DELTASPIKE-518.patch


 In containers like TomEE, you usually don't get the provider implementation 
 directly but a wrapper instead. Currently, DS data fails saying it does not 
 know the provider.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

JSF Security regression

[Jean-Louis MONTEIRO]

Hello guys,

I'm currently facing a regression on Securty module.
Just wanted to know if you are aware of?

I was using 0.5 with the following
@View(basePath = /, extension = xhtml, navigation =
View.NavigationMode.REDIRECT)
public interface Navigation extends ViewConfig {
@View
class Index implements Navigation {}

@View
class Login implements Navigation {}

@View(basePath = /post/)
interface PostsNavigation extends Navigation {}

@View
class Post implements PostsNavigation {}

@Secured(LoggedInUserVoter.class)
interface SecuredPostsNavigation extends PostsNavigation {}

@View(name = create-post)
class CreatePost implements SecuredPostsNavigation {}

@View(name = edit-post)
class EditPost implements SecuredPostsNavigation {}
}

When I switch to 0.6-SNAPSHOT (cause of the DS Data bug), it does not work
anymore.
Here is the error
INFO - class:
org.apache.deltaspike.jsf.impl.config.view.ViewConfigPathValidator
activated=true
SEVERE - invalid view-config found
java.lang.IllegalStateException: path '/navigation/securedPostsNavigation/'
is missing, but mapped by:
com.github.rmannibucau.blog.front.controller.Navigation$SecuredPostsNavigation

If you are not aware, I will investigate and propose a fix.

JLouis

-- 
Jean-Louis

Re: Data Module

[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 mapper interface to delegate to would also allow people to plug
their own implementation in.

WDYT?

JLouis


2013/7/1 Thomas Hug thomas@gmail.com

 Hi John
 Thnx for the message, missed that one. Looks like there's a default profile
 needed (test-persistence.xml only part of the specific server profiles).
 Will check tonight.


 On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament john.d.am...@gmail.com
 wrote:

  Hi
 
  Whoever brought in the data module, can you double check your tests and
  license headers?
 
  I think it's just your tests, but it's failing during a rat check
 
 
 
 https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/
 
  John
 




-- 
Jean-Louis