Re: [VOTE] Apache Isis Core release 1.9.0 RC2

[GESCONSULTOR - Óscar Bou]

+1


> El 31/8/2015, a las 19:37, Martin Grigorov  escribió:
> 
> +1
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> 
> On Mon, Aug 31, 2015 at 12:57 PM, Dan Haywood 
> wrote:
> 
>> My +1 also.
>> On 31 Aug 2015 09:12, "Jeroen van der Wal"  wrote:
>> 
>>> Here's my +1
>>> 
>>> Cheers,
>>> Jeroen
>>> 
>>> On 29 August 2015 at 10:14, Dan Haywood 
>>> wrote:
>>> 
 Folks,
 
 I've cut another release candidate for Apache Isis Core and the
>> simpleapp
 archetype:
 
 * Core 1.9.0
 * SimpleApp Archetype 1.9.0
 
 This release has backed out ISIS-1044 (visibility filtering of objects
>> to
 support multi-tenancy); testing showed that more work is required in
>> this
 area.
 
 The source code artifacts have been uploaded to staging repositories on
 repository.apache.org:
 
 *
 
 
>>> 
>> http://repository.apache.org/content/repositories/orgapacheisis-1035/org/apache/isis/core/isis/1.9.0/isis-1.9.0-source-release.zip
 *
 
 
>>> 
>> http://repository.apache.org/content/repositories/orgapacheisis-1035/org/apache/isis/archetype/simpleapp-archetype/1.9.0/simpleapp-archetype-1.9.0-source-release.zip
 
 For each zip there is a corresponding signature file (append .asc to
>> the
 zip's url).
 
 
 In the source code repo the code has been tagged as isis-1.9.0-RC2 and
 simpleapp-archetype-1.9.0-RC2; see
 https://git-wip-us.apache.org/repos/asf?p=isis.git
 
 For instructions on how to verify the release (build from binaries
>> and/or
 use in Maven directly), see
 
>> http://isis.apache.org/guides/cg.html#_cg_committers_verifying-releases
 
 Please verify the release and cast your vote.  The vote will be open
>> for
>>> a
 minimum of 72 hours.
 
 [ ] +1
 [ ]  0
 [ ] -1
 
>>> 
>> 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou 

   http://es.linkedin.com/in/oscarbou 

   http://www.GesConsultor.com  




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: [VOTE] Apache Isis Core release 1.9.0 RC1

[GESCONSULTOR - Óscar Bou]

Hi Dan.

The following “Build Failure” appears on the Maven log.

I can remove the “-o” switch but not sure is the intention here, as it will 
download also from the apache repo.


[INFO] 
[INFO] 
[INFO] Building Isis Schemas 1.9.0
[INFO] 
[WARNING] The POM for org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:jar:0.12.3 is 
missing, no dependency information available
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Isis ... SUCCESS [  6.393 s]
[INFO] Isis Unit Test Support  SUCCESS [  5.679 s]
[INFO] Isis AppLib ... SUCCESS [  6.769 s]
[INFO] Isis Schemas .. FAILURE [  0.003 s]
[INFO] Isis Log4j Impls .. SKIPPED
[INFO] Isis MetaModel  SKIPPED
[INFO] Isis Runtime .. SKIPPED
[INFO] Isis Core Wrapper Service . SKIPPED
[INFO] Isis WebServer  SKIPPED
[INFO] Isis Security Bypass .. SKIPPED
[INFO] Isis Security Shiro ... SKIPPED
[INFO] Isis Spec Support . SKIPPED
[INFO] Isis Integration Testing Support .. SKIPPED
[INFO] Isis RestfulObjects Viewer AppLib . SKIPPED
[INFO] Isis RestfulObjects Viewer Rendering .. SKIPPED
[INFO] Isis RestfulObjects Viewer Server . SKIPPED
[INFO] Isis Wicket Viewer  SKIPPED
[INFO] Isis Wicket Viewer Applib . SKIPPED
[INFO] Isis Wicket Viewer Model .. SKIPPED
[INFO] Isis Wicket Viewer UI Components .. SKIPPED
[INFO] Isis Wicket Viewer Implementation . SKIPPED
[INFO] Isis Maven Plugin (isis-maven-plugin) . SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 19.977 s
[INFO] Finished at: 2015-08-26T10:04:49+01:00
[INFO] Final Memory: 38M/242M
[INFO] 
[ERROR] Plugin org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:0.12.3 or one of its 
dependencies could not be resolved: Cannot access 
com-springsource-repository-bundles-external 
(http://repository.springsource.com/maven/bundles/external/) in offline mode 
and the artifact org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:jar:0.12.3 has not 
been downloaded from it before. - [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
Building Module ./simpleapp-archetype-1.9.0/
[INFO] Scanning for projects...
[INFO] 
[INFO] Using the builder 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder
 with a thread count of 1
[INFO] 
[INFO] 
[INFO] Building simpleapp-archetype 1.9.0
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ simpleapp-archetype 
---
[INFO] 
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (validate-enforce) @ 
simpleapp-archetype ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ 
simpleapp-archetype ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (process-remote-resources) 
@ simpleapp-archetype ---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
simpleapp-archetype ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 63 resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
simpleapp-archetype ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-archetype-plugin:2.2:jar (default-jar) @ simpleapp-archetype 
---
[INFO] Building archetype jar: 
/Users/oscarboubou/dev/verify-isis-release/simpleapp-archetype-1.9.0/target/simpleapp-archetype-1.9.0
[INFO] 
[INFO]  maven-source-plugin:2.2.1:jar 

Re: [jira] [Commented] (ISIS-1157) Cache safe Actions results by annotating them

[GESCONSULTOR - Óscar Bou]

Hi, Dan.

I’ve noticed the merge.

I’ve just updated that branch to reference the originally invoked class and 
action.

Could you review it again, please?

Many thanks,

Oscar





 El 14/7/2015, a las 6:58, ASF subversion and git services (JIRA) 
 j...@apache.org escribió:
 
 
[ 
 https://issues.apache.org/jira/browse/ISIS-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14625820#comment-14625820
  ] 
 
 ASF subversion and git services commented on ISIS-1157:
 ---
 
 Commit f5ccde834d0ce06adf06b83dd82a4b35e1537eee in isis's branch 
 refs/heads/ISIS-1157 from [~oscarbou]
 [ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=f5ccde8 ]
 
 ISIS-1157: Partial implementation proposal
 
 Tests still pending.
 
 
 Cache safe Actions results by annotating them
 -
 
Key: ISIS-1157
URL: https://issues.apache.org/jira/browse/ISIS-1157
Project: Isis
 Issue Type: Improvement
 Components: Core
   Reporter: Oscar Bou
   Assignee: Oscar Bou
 
 As discussed on the Isis mailing list [1].
 Currently, there's service called QueryResultsCache [2] that allows to cache 
 the results of an Action/method invocation.
 We want to introduce this capability for Safe Actions by simply annotating 
 them.
 Current proposal is to extend the SemanticsOf annotation param with a new 
 type: SemanticsOf.SAFE_AND_REQUEST_CACHED
 A usage example would be:
 
 {code}
@Override
@Action(semantics = SemanticsOf.SAFE_AND_REQUEST_CACHED)
public SortedSetIESG relevantSnpGenotypes(final IE inputElement,
final Kit kit) {
if (kit != null) {
return 
 kit.findAllAssociatedSNPGenotypesForInputElement(inputElement, 
 AlgorithmImplementation.this.IESGClass);
} else {
return Sets.newTreeSet();
}
}
 {code}
 [1] 
 http://mail-archives.apache.org/mod_mbox/isis-users/201505.mbox/%3c575da9cb-14e6-4dd0-9565-c03c759bd...@gesconsultor.com%3E
 [2] https://isis.apache.org/reference/services/query-results-cache.html
 
 
 
 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: Jetty upgrade on recent commit

[GESCONSULTOR - Óscar Bou]

Many thanks, Dan.

We will try this.

Cheers,

Oscar



 El 7/7/2015, a las 9:00, Dan Haywood d...@haywood-associates.co.uk escribió:
 
 (I just posted a similar message to users@i.a.o)
 
 
 
 OK, I believe I have this issue (if using 1.9.0-SNAPSHOT, of not being able
 to deploy the built WAR to Tomcat) fixed.
 
 It requires an adjustment to your webapp's pom.xml file; I've updated the
 migration notes [1] (for existing code) and the archetype (for new)
 
 Any probs, let me know.
 Thx
 Dan
 
 [1]
 http://isis.apache.org/migration-notes.html#_migration-notes_1.8.0-to-1.9.0_war-packaging
 
 On 1 July 2015 at 09:05, Dan Haywood d...@haywood-associates.co.uk wrote:
 
 Thanks for digging into this Oscar... I'll look at tomorrow.
 
 Cheers
 Dan
 
 
 
 On 30 June 2015 at 18:27, GESCONSULTOR - Óscar Bou o@gesconsultor.com
 wrote:
 
 Hi, Dan.
 
 Latest commit made that upgrades Jetty to 9.2 introduces a issue to those
 using the generated WAR file “as is on Tomcat.
 
 It fails with the following exception:
 
 GRAVE: Error during ServletContainerInitializer processing
 javax.servlet.ServletException: Not running on Jetty, JSR-356 support
 unavailable
at
 org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer.onStartup(WebSocketServerContainerInitializer.java:146)
at
 org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5513)
at
 org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at
 org.apache.catalina.core.StandardHost.addChild(StandardHost.java:649)
at
 org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1081)
at
 org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1877)
at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecuto
 
 
 Simply removing the  jetty-all-9.2.11.v20150529.jar” jar from the WAR
 avoids it.
 
 On [1] seems there’s a way to avoid it by defining a property the
 WebAppContext.
 
 Might it be better managed through Maven ?
 
 
 HTH,
 
 Oscar
 
 [1] http://dev.eclipse.org/mhonarc/lists/jetty-users/msg04207.html 
 http://dev.eclipse.org/mhonarc/lists/jetty-users/msg04207.html
 
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Jetty upgrade on recent commit

[GESCONSULTOR - Óscar Bou]

Hi, Dan.

Latest commit made that upgrades Jetty to 9.2 introduces a issue to those using 
the generated WAR file “as is on Tomcat.

It fails with the following exception:

GRAVE: Error during ServletContainerInitializer processing
javax.servlet.ServletException: Not running on Jetty, JSR-356 support 
unavailable
at 
org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer.onStartup(WebSocketServerContainerInitializer.java:146)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5513)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:649)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1081)
at 
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1877)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecuto


Simply removing the  jetty-all-9.2.11.v20150529.jar” jar from the WAR avoids 
it.

On [1] seems there’s a way to avoid it by defining a property the WebAppContext.

Might it be better managed through Maven ?


HTH,

Oscar 

[1] http://dev.eclipse.org/mhonarc/lists/jetty-users/msg04207.html 
http://dev.eclipse.org/mhonarc/lists/jetty-users/msg04207.html

Re: Reworked website, with new user guide and reference guide

[GESCONSULTOR - Óscar Bou]

Really impressive!

There’s a lot to read in detail in the User Guide introduction. Just marked to 
read in detail :))

Thanks, Dan.


Cheers,

Oscar




 El 16/6/2015, a las 18:38, Dan Haywood d...@haywood-associates.co.uk 
 escribió:
 
 I think I'm pushing the limits of the JQuery tocify plugin [1]; the
 guides are each about 1Mb in size.
 
 The way I use it ... click on headings in the toc and have the main guide
 scroll through to that point ... works well enough for me.  And I like the
 way that the toc plugin retains prev/next history; that's also useful.
 
 But if you find a better toc plugin still, I'll be happy to integrate it :-)
 
 Cheers
 Dan
 
 
 
 
 [1] http://gregfranko.com/jquery.tocify.js/
 
 On 16 June 2015 at 17:33, Mike Burton mi...@mycosystems.co.uk wrote:
 
 Hi Dan,
 
 That looks brilliant, very nice work!!
 
 Minor observation- When I first opened the site I could scroll through the
 RHS contents-pane, but thereafter any scrolling I did scrolled the LHS main
 text instead.
 
 Mike Burton
 mi...@mycosystems.co.uk
 
 On 16 Jun 2015, at 07:48, Dan Haywood d...@haywood-associates.co.uk
 wrote:
 
 Hi folks,
 
 Over the last month or so I've been reworking the Isis website, to:
 
 - consolidate our how-to documentation into a comprehensive user guide
 [1]
 - provide a corresponding reference guide [2]
 - rework from Markdown to Asciidoctor
 
 I've pushed the updated site this morning.   The home page [3] is
 substantially the same, but the documentation page [4] has been
 overhauled
 and simplified with big prominent buttons to the two new guides.
 
 So you know, these guides do reference some feature in 1.9.0-SNAPSHOT, so
 if you are working on 1.8.0 and can't find something that's discussed,
 that'll be why.  (Releasing 1.9.0 is the next thing on my todo list).
 
 The guides are mostly complete, though there are still some placeholders
 here and there.  I decided to release them in their current state because
 even slightly unfinished I think they are far better than what we had
 before.
 
 Feedback welcome, as ever.
 
 Thx
 Dan
 
 PS: The source for all this is in our git repo [5], and can be built
 locally [6].  Pull requests welcome!
 PPS: if you don't see any changes, then force reload of the page (ctrl-R
 or
 similar).
 
 [1] http://isis.apache.org/guides/ug.html
 [2] http://isis.apache.org/guides/rg.html
 [3] http://isis.apache.org/
 [4] http://isis.apache.org/documentation.html
 [5]
 
 https://github.com/apache/isis/tree/master/adocs/documentation/src/main/asciidoc
 [6]
 https://github.com/apache/isis/tree/master/adocs/documentation/README.md
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

FixtureScripts - method to initiate a new transaction

[GESCONSULTOR - Óscar Bou]

Hi all.

When using FixtureScripts, there can be many actions that, on the real world, 
are execute in different time contexts.

For example, a user creates an Account on the webapp and after that executes 
different actions.

That’s relevant if using the queryResultsCache service (or the new planned 
“@Action” annotation extension) because the results previously created (i.e., 
the Account) might be available on the cache.

So perhaps some mechanism like the nextTransation() method might be also 
introduced on FixtureScripts.

What do you think?

Regards,

Oscar

Re: FixtureScripts - method to initiate a new transaction

[GESCONSULTOR - Óscar Bou]

Related with this, I’m trying to test the following:

   @Test
public void totalOrRatio() {

// given
kit.assignToPerson(account.getAccountOwner());

this.nextRequest();

kit.getRegisteredForPerson().setSex(Sex.Man);

….
}

Where the Kit.getRegisteredForPerson() is cached:

// {{ RegisteredForPerson (property)
@Property(editing = Editing.DISABLED, notPersisted = true)
@MemberOrder(sequence = 1)
public Person getRegisteredForPerson() {
return this.queryResultsCache.execute(new CallablePerson() {
@Override
public Person call() throws Exception {
return Kit.this.findRegisteredToPerson();
}
}, this.getClass(), findRegisteredToPerson);
}

// }}


Despite invoking “this.nextRequest()” on the integtest, seems that the cache is 
still alive (being it a @RequestScoped service).

Would this also need to be improved for testing @RequestScoped services? 


Thanks!





 El 28/5/2015, a las 13:39, GESCONSULTOR - Óscar Bou o@gesconsultor.com 
 escribió:
 
 Hi all.
 
 When using FixtureScripts, there can be many actions that, on the real world, 
 are execute in different time contexts.
 
 For example, a user creates an Account on the webapp and after that executes 
 different actions.
 
 That’s relevant if using the queryResultsCache service (or the new planned 
 “@Action” annotation extension) because the results previously created (i.e., 
 the Account) might be available on the cache.
 
 So perhaps some mechanism like the nextTransation() method might be also 
 introduced on FixtureScripts.
 
 What do you think?
 
 Regards,
 
 Oscar
 
 
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: FixtureScripts - method to initiate a new transaction

[GESCONSULTOR - Óscar Bou]

The concrete exception thrown is:

java.lang.AssertionError: Transaction is in state of 'COMMITTED'
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.isis.core.integtestsupport.IsisSystemForTest.commitTran(IsisSystemForTest.java:744)
at 
org.apache.isis.core.integtestsupport.scenarios.ScenarioExecutionForIntegration.endTran(ScenarioExecutionForIntegration.java:76)
at 
org.apache.isis.core.integtestsupport.IntegrationTestAbstract.nextTransaction(IntegrationTestAbstract.java:80)
at 
org.apache.isis.core.integtestsupport.IntegrationTestAbstract.nextRequest(IntegrationTestAbstract.java:91)
at 
com.tellmegen.integtests.domain.model.algorithms.complexdiseases.ComplexDiseaseAlgorithmImplementationTests.totalOrRatio(ComplexDiseaseAlgorithmImplementationTests.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.apache.isis.core.unittestsupport.jmocking.JUnitRuleMockery2$1.evaluate(JUnitRuleMockery2.java:146)
at 
org.apache.isis.core.integtestsupport.ExceptionRecognizerTranslate$TranslationStatement.evaluate(ExceptionRecognizerTranslate.java:32)
at 
org.apache.isis.core.integtestsupport.IntegrationTestAbstract$IsisTransactionRule$1.evaluate(IntegrationTestAbstract.java:214)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)





 El 28/5/2015, a las 14:00, GESCONSULTOR - Óscar Bou o@gesconsultor.com 
 escribió:
 
 Related with this, I’m trying to test the following:
 
@Test
 public void totalOrRatio() {
 
 // given
 kit.assignToPerson(account.getAccountOwner());
 
 this.nextRequest();
 
 kit.getRegisteredForPerson().setSex(Sex.Man);
 
 ….
 }
 
 Where the Kit.getRegisteredForPerson() is cached:
 
 // {{ RegisteredForPerson (property)
 @Property(editing = Editing.DISABLED, notPersisted = true)
 @MemberOrder(sequence = 1)
 public Person getRegisteredForPerson() {
 return this.queryResultsCache.execute(new CallablePerson() {
 @Override
 public Person call() throws Exception {
 return Kit.this.findRegisteredToPerson();
 }
 }, this.getClass(), findRegisteredToPerson);
 }
 
 // }}
 
 
 Despite invoking “this.nextRequest()” on the integtest, seems that the cache 
 is still alive (being it a @RequestScoped service).
 
 Would this also need to be improved for testing @RequestScoped services? 
 
 
 Thanks!
 
 
 
 
 
 El 28/5/2015, a las 13:39, GESCONSULTOR - Óscar Bou o@gesconsultor.com 
 mailto:o@gesconsultor.com escribió:
 
 Hi all.
 
 When using FixtureScripts, there can be many actions that, on the real 
 world, are execute in different time contexts.
 
 For example, a user

New Pull Request on the Isis Add-On isis-module-excel

[GESCONSULTOR - Óscar Bou]

Hi all.

I’ve just created a new PR at [1].

Basically, it skips headers which are “blank” (empty).
Sometimes, the Excel file contains empty columns at the end, that would be 
processed as “normal” columns, but, as they have no property name on the header 
(is empty) a NullPointerException is thrown.

Some weeks ago I did a similar commit for skipping empty rows instead of empty 
columns (as on this one).


Please, any committer, review and merge if possible in order to keep all team 
synched.


Many thanks!

Oscar



[1] https://github.com/isisaddons/isis-module-excel/pull/11

Re: [RESULT] [VOTE] Apache Isis Core release 1.8.0

[GESCONSULTOR - Óscar Bou]

Hi all.

My testimonial +1.

I've not been able to test the released artifacts but we've been working in 
production with this release the last weeks with success.

Great job to all.


 El 23/2/2015, a las 22:42, Dan Haywood d...@haywood-associates.co.uk 
 escribió:
 
 The vote has completed with the following result :
 
  +4 (binding): Kevin Meyer, Martin Grigorov, Dan Haywood, Jeroen van der
 Wal
  +1 (non binding): Vladimir Nisevic
 
 The vote is SUCCESSFUL.
 
 Thanks to all who voted.

Re: Revamped i18n support

[GESCONSULTOR - Óscar Bou]

Really helpful, Dan, for all us not native English speakers.

Many thanks!!!


 El 18/2/2015, a las 19:47, Dan Haywood d...@haywood-associates.co.uk 
 escribió:
 
 Folks,
 
 fyi, just sneaking into the 1.8.0 release, we now have revamped and much
 improved i18n support based on gettext .po files.
 
 For more info, see this page on the site [1], and resolves ISIS-903 [2]
 
 Cheers
 Dan
 
 
 [1] http://isis.apache.org/config/i18n-support.html
 [2] https://issues.apache.org/jira/browse/ISIS-903

Re: Domain Objects Lifecycle and Events published on removing

[GESCONSULTOR - Óscar Bou]

Hi, Dan.

I've updated the pull request.

It still has an unexpected behavior when using the refactored 
EventBusServiceJdo, being that when an Exception is thrown during action 
processing (ie, on EXECUTING) the transaction is marked to be aborted but the 
execution flow continues (and seems not to abort).

Perhaps an Exception might be thrown when detected or something similar?
I had tests expecting an Exception that were previously passing and currently 
not.
But not sure when the exception might be thrown.


Thanks,

Oscar



 El 8/2/2015, a las 13:04, GESCONSULTOR - Óscar Bou o@gesconsultor.com 
 escribió:
 
 Hi, Dan.
 
 I've just sent a pull request [1] containing an initial implementation of an 
 Axon-based EventBusService.
 
 I've refactored some classes in order to reuse Isis logic as much as possible.
 
 
 Please, can you review it?
 
 Thanks,
 
 Oscar
 
 
 [1] https://github.com/apache/isis/pull/23 
 https://github.com/apache/isis/pull/23
 
 
 El 6/2/2015, a las 19:47, Dan Haywood d...@haywood-associates.co.uk 
 mailto:d...@haywood-associates.co.uk escribió:
 
 Hi Oscar,
 sorry not to reply on this post... just getting around to it.
 
 Yes, your email makes sense to me; I hadn't known that Guava buffered 
 events, but I can see why the fact that it does could cause this multi-level 
 cascade issue.
 
 I had a poke around its Javadoc but couldn't see any way to turn it off.
 
 It ought to be possible to swap in an Axion-based event bus instead though.  
 Write a service implementing Isis' EventBusService API, and make sure that 
 the subscribers use Axion's own subscription API, obviously.
 
 With the Guava implementation I had to install a special exception handler 
 [8] so that a subscriber could veto or abort an transaction; an Axion 
 implementation would need to do something similar.
 
 If you do write an implementation, then it can be registered (and take 
 precedence over the built-in guava impl) just by explicitly registering in 
 isis.properties, like we used to do.
 
 ~~~
 As for CQRS Jeroen and I joke about my antipathy for it as a pattern.  
 But actually, it's not really true... I can, truth be told, see benefits 
 from applying some of its ideas, if only to help decouple the app (different 
 rates of change of behaviour = commands vs structure = query).
 
 So, in Isis a CQRS app one would have dumb entities, and all behaviour would 
 be either contributed actions or event bus subscribers.   Indeed, we are 
 gradually refactoring Estatio into this structure, so that we can (a) focus 
 on its core domain - an invoice calculation engine - and (b) potentially 
 reuse some of its building block modules in other apps.
 
 Cheers
 Dan
 
 
 [8] 
 https://github.com/apache/isis/blob/b5f73ec3dcae8015d11004915c15dd81c2945238/core/runtime/src/main/java/org/apache/isis/core/runtime/services/eventbus/EventBusServiceDefault.java#L91
  
 https://github.com/apache/isis/blob/b5f73ec3dcae8015d11004915c15dd81c2945238/core/runtime/src/main/java/org/apache/isis/core/runtime/services/eventbus/EventBusServiceDefault.java#L91
 
 
 On 17 January 2015 at 16:17, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com mailto:o@gesconsultor.com wrote:
 Hi all.
 
 I'm fighting against current Event Bus implementation, as it's currently 
 based on Guava Event Bus.
 
 It has one characteristic that is not allowing me to implement, for example, 
 cascade deleting of Domain Entities, nested in 3 levels (Entity2 references 
 Entity1, and Entity3 references Entity2. When deleting an Entity1 instance I 
 want to delete - or set to null, etc. - Entity2 and Entity3 also).
 
 This is due to Guava EventBus current implementation, that enqueues Events 
 posted instead of dispatching them at the very moment [1] as a programmer 
 would expect with a sequential execution flow. 
 
 That originates limitations on nested behaviors when you post an Event 
 once you're processing an Event (ie, you're entered a @Subscriber).
 For example, Events dispatched from actions that act on the EXECUTING phase: 
 - if invoked by the user from the UI the @Subscriber's code will be executed 
 PRIOR to the action's code.
 - but if invoked as part of a previous Event handler (ie, when still 
 executing a previous Event @Subscriber's code) it will be queued and will be 
 executed AFTER the action's code. 
 
 In [1] the problem is explained quite clearly, and also the solution if this 
 one is not the desired behavior (to delete 3 lines, as currently it's not 
 configurable...).
 
 
 
 I'm trying to explain this over Estatio.
 
 On [2], the Party entity declares a remove action that posts an Event.
 
 On 3], the AgreementRoles service is subscribed to the Event. 
 But imagine that we want to delete all AgreementRole instances instead of 
 setting the reference to null or to another Party.
 For that, we would declare and invoke a similar remove action to the one 
 defined for Party ([2]), with an @ActionInteraction for posting an Event

Re: Considering merging the Wicket viewer into Core framework

[GESCONSULTOR - Óscar Bou]

ok for me also.

Cheers,

Oscar


 El 3/2/2015, a las 15:23, Kevin Meyer ke...@kmz.co.za escribió:
 
 No objections from me. 
 Cheers, 
 Kevin
 
 On 2 February 2015 23:24:32 CET, Dan Haywood d...@haywood-associates.co.uk 
 wrote:
 Hi folks,
 
 Over the last few releases we've been slowly rationalizing the various
 Maven modules, and for 1.8.0 I'd like to go one further step and merge
 the
 Wicket viewer into core also.
 
 * it's the defacto (human usable) UI for Isis
 * the use cases that it supports are to a large extent driving the
 evolution of Isis' metamodel
 * it simplifies the release process (hopefully will encourage us
 committers
 to do more frequent releases)
 
 From a user (ie programmer) perspective, the impact will be that some
 of
 the Maven dependencies will change.  We'll update the archetypes though
 to
 make it easy to see the changes.
 
 I'll leave this thread open a few days to allow opinions to be aired;
 if I
 hear nothing then will assume lazy consensus.
 
 Thx
 Dan
 
 -- 
 Sent from my phone with K-9 Mail.
 Please excuse my brevity.


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Related Object column might be left aligned by default

[GESCONSULTOR - Óscar Bou]

Hi all.

In Wicket viewer, the related object column is centered instead of left aligned.

Do you agree that it would be left aligned also (as any other text column by 
default)?

I can open a ticket if agreed.

Regards,

Oscar

Re: Exception on webapp with latest SNAPSHOT

[GESCONSULTOR - Óscar Bou]

Same case here...

I've deleted the .m2 isis folders and all seems to work ok.

The root cause seems to be that some modules has been moved into core 
(including restful viewer, shiro, etc.), and there was a mix of packages, 
versions, etc.

I've seen on the sample ToDo app the correct config with 1.8.0-SNAPSHOT and now 
runs smoothly.

Thanks,

Oscar


 El 26/1/2015, a las 12:16, Jeroen van der Wal jer...@stromboli.it escribió:
 
 For wat it's worth: I had some unexpected errors and could only solve these
 by removing the appropriate .m2 repository artefacts.
 
 Cheers,
 
 Jeroen
 
 On 26 January 2015 at 08:51, Martin Grigorov mgrigo...@apache.org wrote:
 
 Hi,
 
 I cannot reproduce this here.
 The exception message says that there is no markup file for
 WicketSignInPage,
 i.e. there is no WicketSignInPage.html next to WicketSignInPage.class.
 Just double checked and the file is in isis-viewer-wicket-ui.jar
 
 @Oscar: please try again and ping me if you still face this problem. We
 will debug it together!
 
 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov
 
 On Sun, Jan 25, 2015 at 6:09 PM, Dan Haywood d...@haywood-associates.co.uk
 
 wrote:
 
 Martin,
 could you look into this tomorrow?
 Cheers
 Dan
 
 
 On 25 January 2015 at 09:47, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:
 
 
 Hi all.
 
 Yesterday I updated my webapp modules to the Apache Isis latest
 SNAPSHOTs
 and now the following exception is thrown.
 
 It's thrown 12 times (from id = 1 to id = 12) each time I access the 
 http://localhost:8080/wicket; URL.
 
 Perhaps a new service is missing or something like that?
 
 Thanks!!!
 
 
 
 10:44:43,728  [RequestCycleExtra1794653408@qtp-1755306561-2 WARN ]
 
 10:44:43,729  [RequestCycleExtra1794653408@qtp-1755306561-2 WARN ]
 Handling the following exception
 org.apache.wicket.markup.MarkupNotFoundException: Can not determine
 Markup. Component is not yet connected to a parent. [Page class =
 org.apache.isis.viewer.wicket.ui.pages.login.WicketSignInPage, id = 1,
 render count = 1]
at org.apache.wicket.Component.getMarkup(Component.java:749)
at
 org.apache.wicket.Component.internalRender(Component.java:2309)
at org.apache.wicket.Component.render(Component.java:2272)
at org.apache.wicket.Page.renderPage(Page.java:1024)
at
 
 
 org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:129)
at
 
 
 org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:228)
at
 
 
 org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
at
 
 
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
at
 
 
 org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
 
 
 org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261)
at
 
 
 org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218)
at
 
 
 org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
at
 
 
 org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
at
 
 
 org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
at
 
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)
at
 
 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at
 
 
 org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
at
 
 
 org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
at
 
 
 org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at
 
 
 org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at
 
 
 org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at
 
 
 org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
at
 
 
 org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at
 
 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at
 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at
 
 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at
 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at
 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152

Exception on webapp with latest SNAPSHOT

[GESCONSULTOR - Óscar Bou]

Hi all.

Yesterday I updated my webapp modules to the Apache Isis latest SNAPSHOTs and 
now the following exception is thrown.

It's thrown 12 times (from id = 1 to id = 12) each time I access the 
http://localhost:8080/wicket; URL.

Perhaps a new service is missing or something like that?

Thanks!!!



10:44:43,728  [RequestCycleExtra1794653408@qtp-1755306561-2 WARN ]  

10:44:43,729  [RequestCycleExtra1794653408@qtp-1755306561-2 WARN ]  
Handling the following exception
org.apache.wicket.markup.MarkupNotFoundException: Can not determine Markup. 
Component is not yet connected to a parent. [Page class = 
org.apache.isis.viewer.wicket.ui.pages.login.WicketSignInPage, id = 1, render 
count = 1]
at org.apache.wicket.Component.getMarkup(Component.java:749)
at org.apache.wicket.Component.internalRender(Component.java:2309)
at org.apache.wicket.Component.render(Component.java:2272)
at org.apache.wicket.Page.renderPage(Page.java:1024)
at 
org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:129)
at 
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:228)
at 
org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
at 
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
at 
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at 
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
at 
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
at 
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
at 
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at 
org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
at 
org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
at 
org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at 
org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at 
org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at 
org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
at 
org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at 
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at 
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
10:44:43,730  [RequestCycleExtra1794653408@qtp-1755306561-2 WARN ]  

10:44:43,730  [WebRequestCycleForIsis 1794653408@qtp-1755306561-2 WARN ]  
Unable to obtain exceptionRecognizers (no session), will be treated as 
unrecognized exception
10:44:43,767  [RequestCycleExtra1794653408@qtp-1755306561-2 WARN ]  






10:44:44,177  [RequestCycleExtra1794653408@qtp-1755306561-2 WARN ]  

10:44:44,177  [WebRequestCycleForIsis 1794653408@qtp-1755306561-2 WARN ]  
Unable to obtain exceptionRecognizers (no session), will be treated as 
unrecognized exception
10:44:44,246  [RequestCycle 1794653408@qtp-1755306561-2 ERROR]  Error 
during processing error message
org.apache.wicket.markup.MarkupNotFoundException: Can 

Re: Domain Objects Lifecycle and Events published on removing

[GESCONSULTOR - Óscar Bou]

Hi Dan.

I’ve just updated the issue description.

Just an “idiomatic issue”.

I understand that an object can be saved when initially created, and after 
updating an existing object.

So for me domainEventOnSave would be triggered both when saving newly created 
objects, and when updating previously created objects.

Would it be better naming it something like “domainEventOnCreate” ?

Seems JDO lifecycle callbacks are named something similar [1].

Regards,

Oscar


[1] 
http://www.datanucleus.org/products/datanucleus/jdo/lifecycle_callbacks.html 
http://www.datanucleus.org/products/datanucleus/jdo/lifecycle_callbacks.html


 El 13/1/2015, a las 18:39, Dan Haywood d...@haywood-associates.co.uk 
 escribió:
 
 
 
 On 13 January 2015 at 17:19, GESCONSULTOR - Óscar Bou o@gesconsultor.com 
 mailto:o@gesconsultor.com wrote:
 ok, Dan.
 
  But that would include something like @DomainObjectInteraction, in order to 
 customize the event (and the event handler) ?
 
 
 
 Yeah, though into @DomainObject rather than a new annotation.
 
 Why? because in ISIS-970 the existing annotations @ActionInteraction / 
 @PropertyInteraction / @CollectionInteraction are being deprecated to be 
 replaced by into @Action / @Property / @Collection, 
 
 eg:
 @ActionInteraction(SomethingChangedEvent.class)
 
 will become
 
 @Action(domainEvent=SomethingChangedEvent.class)
 
 
 ~~~
 
 Therefore I suggest
 
 @DomainObject(
 domainEventOnLoad = ...,
 domainEventOnSave = ...,
 domainEventOnUpdate = ...,
 domainEventOnDelete = ...,
 )
 
 I don't think there's any need to have a pairs of hooks (eg 
 domainEventOnSaving / domainEventOnSaved), because the domainEvent itself has 
 phases, ie EXECUTING and EXECUTED.  So we can reuse that.
 
 I'm not sure at this stage if the other vetoing phases 
 (HIDE/DISABLE/VALIDATE) all makes sense, though possibly the OnLoad event 
 could honour HIDE and DISABLE (providing a way by which a subscriber could 
 prevent an object from being either viewed or being edited).
 
 If the above sounds ok, can you do me a favour and copy/paste some of the 
 above into the ISIS-803 ticket?
 
 
 Cheers
 Dan
 
 
 
  
 El 13/1/2015, a las 15:21, Dan Haywood d...@haywood-associates.co.uk 
 mailto:d...@haywood-associates.co.uk escribió:
 
 Hi Oscar
 
 Although we probably won't use this in Estatio, it is (I think) a valid use 
 case.
 
 We do in fact have a ticket for it already, ISIS-803 [1].  And the original 
 ticket that introduced the event bus, ISIS-550 [2], although it didn't 
 implement the feature, did mention it.
 
 In a similar vein, if we implement ISIS-803 then I think the recently raised 
 ISIS-1005 [3] is probably redundant (or at least, is part of ISIS-803).
 
 In terms of priorities, I want to get my @Action / @Property / @Collection 
 stuff finished off.  Then I'll take a look at this and see how much work it 
 is to squeeze in for 1.8.0 or not.
 
 HTH
 Dan
 
 
 [1] https://issues.apache.org/jira/browse/ISIS-803 
 https://issues.apache.org/jira/browse/ISIS-803
 [2] https://issues.apache.org/jira/browse/ISIS-550 
 https://issues.apache.org/jira/browse/ISIS-550
 [3] https://issues.apache.org/jira/browse/ISIS-1005 
 https://issues.apache.org/jira/browse/ISIS-1005
 
 
 ~
 
 
 On 13 January 2015 at 14:06, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com mailto:o@gesconsultor.com wrote:
 Hi, Dan and Jeroen for your pointing me towards those examples.
 
 As I'm seeing on Estatio, event publishing is made through an 
 @ActionInteraction annotation, which requires to always delete entities by 
 means of that action.
 
 I attached the event post to the removing framework method for publishing 
 the event every time an object is going to be delete, independently it's 
 made through a custom action or through container().remove(). 
 That way, I can be sure the business logic is going to be executed ALWAYS 
 despite how the other developers implement this.
 
 We can re-implement all this event logic for assuring that we always delete 
 this kind of domain objects through that action, but I thought previous 
 solution would work better, as it's directly attached to the object's 
 lifecycle.
 
 In previous threads we talked about the option of being notified of 
 framework's events.
 
 Perhaps implementing a @DomainObjectInteraction annotation in a similar way 
 to @ActionInteraction could have sense.
 
 What do you think?
 
 Thanks,
 
 Oscar
 
 
 
 
 
 
 
 
 El 12/1/2015, a las 20:38, Jeroen van der Wal jer...@stromboli.it 
 mailto:jer...@stromboli.it escribió:
 
 
 Here's a sample of invalidating the removal of a Party in case it plays
 role in an agreement:
 https://github.com/estatio/estatio/blob/master/estatioapp/dom/src/main/java/org/estatio/dom/agreement/AgreementRoles.java#L143
  
 https://github.com/estatio/estatio/blob/master/estatioapp/dom/src/main/java/org/estatio/dom/agreement/AgreementRoles.java#L143
 
 HTH
 
 On 12 January 2015 at 19:38, Dan Haywood d...@haywood

Re: Domain Objects Lifecycle and Events published on removing

[GESCONSULTOR - Óscar Bou]

ok, Dan.

 But that would include something like @DomainObjectInteraction, in order to 
customize the event (and the event handler) ?


 El 13/1/2015, a las 15:21, Dan Haywood d...@haywood-associates.co.uk 
 escribió:
 
 Hi Oscar
 
 Although we probably won't use this in Estatio, it is (I think) a valid use 
 case.
 
 We do in fact have a ticket for it already, ISIS-803 [1].  And the original 
 ticket that introduced the event bus, ISIS-550 [2], although it didn't 
 implement the feature, did mention it.
 
 In a similar vein, if we implement ISIS-803 then I think the recently raised 
 ISIS-1005 [3] is probably redundant (or at least, is part of ISIS-803).
 
 In terms of priorities, I want to get my @Action / @Property / @Collection 
 stuff finished off.  Then I'll take a look at this and see how much work it 
 is to squeeze in for 1.8.0 or not.
 
 HTH
 Dan
 
 
 [1] https://issues.apache.org/jira/browse/ISIS-803 
 https://issues.apache.org/jira/browse/ISIS-803
 [2] https://issues.apache.org/jira/browse/ISIS-550 
 https://issues.apache.org/jira/browse/ISIS-550
 [3] https://issues.apache.org/jira/browse/ISIS-1005 
 https://issues.apache.org/jira/browse/ISIS-1005
 
 
 ~
 
 
 On 13 January 2015 at 14:06, GESCONSULTOR - Óscar Bou o@gesconsultor.com 
 mailto:o@gesconsultor.com wrote:
 Hi, Dan and Jeroen for your pointing me towards those examples.
 
 As I'm seeing on Estatio, event publishing is made through an 
 @ActionInteraction annotation, which requires to always delete entities by 
 means of that action.
 
 I attached the event post to the removing framework method for publishing 
 the event every time an object is going to be delete, independently it's made 
 through a custom action or through container().remove(). 
 That way, I can be sure the business logic is going to be executed ALWAYS 
 despite how the other developers implement this.
 
 We can re-implement all this event logic for assuring that we always delete 
 this kind of domain objects through that action, but I thought previous 
 solution would work better, as it's directly attached to the object's 
 lifecycle.
 
 In previous threads we talked about the option of being notified of 
 framework's events.
 
 Perhaps implementing a @DomainObjectInteraction annotation in a similar way 
 to @ActionInteraction could have sense.
 
 What do you think?
 
 Thanks,
 
 Oscar
 
 
 
 
 
 
 
 
 El 12/1/2015, a las 20:38, Jeroen van der Wal jer...@stromboli.it 
 mailto:jer...@stromboli.it escribió:
 
 
 Here's a sample of invalidating the removal of a Party in case it plays
 role in an agreement:
 https://github.com/estatio/estatio/blob/master/estatioapp/dom/src/main/java/org/estatio/dom/agreement/AgreementRoles.java#L143
  
 https://github.com/estatio/estatio/blob/master/estatioapp/dom/src/main/java/org/estatio/dom/agreement/AgreementRoles.java#L143
 
 HTH
 
 On 12 January 2015 at 19:38, Dan Haywood d...@haywood-associates.co.uk 
 mailto:d...@haywood-associates.co.uk
 wrote:
 
 Hi Oscar,
 
 I think we can support this use case, but admittedly it isn't - yet - well
 documented.
 
 First thing to say is that the removing lifecycle code hook method that
 you quote isn't actually part of your stacktrace.  As it happens, that's
 probably a good thing...  support for them is a little bit patchy (there
 might be bugs).
 
 So, when I look at your stack trace, what's actually happening is that:
 * BusinessEntity.deleteFromAssignedToBusinessProcesses(...) is performing a
 removeElement on a wrapped collection, which fires an event via:
 * CollectionRemoveFromFacetForInteractionAbstract, which is handled by
 * RelationshipsBCMInformationEventHandler.on
 
 So, what you should do in the handler is to look at the event's phase.
 In fact, you really must pay attention to the phase because it is called
 multiple times:
 
 switch(ev,getPhase()) {
case HIDE:
   ...
case DISABLE:
   ...
case VALIDATE:
   ...
case EXECUTING:
   ...
case EXECUTED:
   ...
 }
 
 As you have probably guessed, your code wants to go into the EXECUTING
 bit, which is the pre-execute callback.  I imagine at the moment it is
 firing for all the cases, including the EXECUTED bit, and that's most
 likely why JDO then complains at you when you try to access that deleted
 object.
 
 Hope that makes sense / works... if not, then we can go round the loop.
 
 Cheers
 Dan
 
 
 
 
 
 
 
 Two things about
 Rather than do this on the removing() callback, I suggest you emit an event
 on the action that The event that
 
 On 12 January 2015 at 18:24, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com mailto:o@gesconsultor.com wrote:
 
 Hi all.
 
 I want to get notified when a domain object is going to be removed.
 
 I have defined it as this:
 
 public class Relationship {
 
   …
 
public void removing() {
this.eventBusService.post(new RelationshipRemovingEvent(this));
}
  ...
 
 }
 
 And an Event Handler like this:
 
 public class

Re: Domain Objects Lifecycle and Events published on removing

[GESCONSULTOR - Óscar Bou]

Hi, Dan and Jeroen for your pointing me towards those examples.

As I'm seeing on Estatio, event publishing is made through an 
@ActionInteraction annotation, which requires to always delete entities by 
means of that action.

I attached the event post to the removing framework method for publishing the 
event every time an object is going to be delete, independently it's made 
through a custom action or through container().remove(). 
That way, I can be sure the business logic is going to be executed ALWAYS 
despite how the other developers implement this.

We can re-implement all this event logic for assuring that we always delete 
this kind of domain objects through that action, but I thought previous 
solution would work better, as it's directly attached to the object's lifecycle.

In previous threads we talked about the option of being notified of framework's 
events.

Perhaps implementing a @DomainObjectInteraction annotation in a similar way to 
@ActionInteraction could have sense.

What do you think?

Thanks,

Oscar








 El 12/1/2015, a las 20:38, Jeroen van der Wal jer...@stromboli.it escribió:
 
 Here's a sample of invalidating the removal of a Party in case it plays
 role in an agreement:
 https://github.com/estatio/estatio/blob/master/estatioapp/dom/src/main/java/org/estatio/dom/agreement/AgreementRoles.java#L143
 
 HTH
 
 On 12 January 2015 at 19:38, Dan Haywood d...@haywood-associates.co.uk
 wrote:
 
 Hi Oscar,
 
 I think we can support this use case, but admittedly it isn't - yet - well
 documented.
 
 First thing to say is that the removing lifecycle code hook method that
 you quote isn't actually part of your stacktrace.  As it happens, that's
 probably a good thing...  support for them is a little bit patchy (there
 might be bugs).
 
 So, when I look at your stack trace, what's actually happening is that:
 * BusinessEntity.deleteFromAssignedToBusinessProcesses(...) is performing a
 removeElement on a wrapped collection, which fires an event via:
 * CollectionRemoveFromFacetForInteractionAbstract, which is handled by
 * RelationshipsBCMInformationEventHandler.on
 
 So, what you should do in the handler is to look at the event's phase.
 In fact, you really must pay attention to the phase because it is called
 multiple times:
 
 switch(ev,getPhase()) {
case HIDE:
   ...
case DISABLE:
   ...
case VALIDATE:
   ...
case EXECUTING:
   ...
case EXECUTED:
   ...
 }
 
 As you have probably guessed, your code wants to go into the EXECUTING
 bit, which is the pre-execute callback.  I imagine at the moment it is
 firing for all the cases, including the EXECUTED bit, and that's most
 likely why JDO then complains at you when you try to access that deleted
 object.
 
 Hope that makes sense / works... if not, then we can go round the loop.
 
 Cheers
 Dan
 
 
 
 
 
 
 
 Two things about
 Rather than do this on the removing() callback, I suggest you emit an event
 on the action that The event that
 
 On 12 January 2015 at 18:24, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:
 
 Hi all.
 
 I want to get notified when a domain object is going to be removed.
 
 I have defined it as this:
 
 public class Relationship {
 
   …
 
public void removing() {
this.eventBusService.post(new RelationshipRemovingEvent(this));
}
  ...
 
 }
 
 And an Event Handler like this:
 
 public class RelationshipsBCMInformationEventHandler extends
 AbstractXMSService {
 
// {{ RELATIONSHIPS EVENTS HANDLER
 
@Subscribe
@Programmatic
public void on(final RelationshipRemovingEvent event) {
try {
final RelationshipBCMInformation relationshipBCMInformation =
 
 this.wrap(this.relationshipsBCMInformation).businessContinuityInformation(event.getRelationship());
this.getContainer().remove(relationshipBCMInformation);
this.getContainer().flush();
} catch (final Exception e) {
e.printStackTrace();
throw new ApplicationException(e);
}
}
 
// }}
 
// {{ injected: RelationshipsBCMInformation
@Inject
private RelationshipsBCMInformation relationshipsBCMInformation;
 
// }}
 
// {{ injected: EventBusService
@Programmatic
@PostConstruct
public void postConstruct() {
this.eventBusService.register(this);
}
 
@Programmatic
@PreDestroy
public void preDestroy() {
this.eventBusService.unregister(this);
}
 
@javax.inject.Inject
private EventBusService eventBusService;
// }}
 
 }
 
 
 
 Problem is that when the code enters the “on” event handler, the
 reference
 to the relationship accessed on event.getRelationship()” is already
 marked
 as deleted:
 
 
 javax.jdo.JDOUserException: No es posible leer campos de un objeto
 borrado
 
 FailedObject:0[OID]com.xms.framework.architecture.domain.model.Relationship
at
 
 org.datanucleus.api.jdo.state.PersistentNewDeleted.transitionReadField

New Pull request: abortTransaction message on EXECUTED is incorrect

[GESCONSULTOR - Óscar Bou]

Hi folks!

I’ve created a new pull request on Github improving current exception 
formatting when thrown on the EXECUTED phase.

You can find it on [1].

HTH,

Oscar

[1] https://github.com/apache/isis/pull/19 
https://github.com/apache/isis/pull/19

@PostsPropertyChangedEvent no longer working on latest SNAPSHOT

[GESCONSULTOR - Óscar Bou]

Hi all.

I’m testing against latest 1.8.0-SNAPSHOT and seems that 
@PostsPropertyChangedEvent support has been removed.
In order to make it work again, it’s enough to just use the 
@PropertyInteraction annotation instead, passing the Event class to it (same 
way the @PostsPropertyChangedEvent worked).

I think support for this is going to be included also on the new @Property 
annotation currently developing, but after that the current website might be 
updated [1].

HTH,

Oscar




[1] http://isis.apache.org/reference/services/event-bus-service.html 
http://isis.apache.org/reference/services/event-bus-service.html

Infitinite recursion after updating to latest SNAPSHOT

[GESCONSULTOR - Óscar Bou]

Hi all,

I’m in the process of upgrading to the latest Apache Isis snapshot our codebase.

I’ve entered an infinite recursion when using the updating() platform’s method:

@PersistenceCapable(identityType = IdentityType.DATASTORE)
@DatastoreIdentity(strategy = IdGeneratorStrategy.IDENTITY)
@Inheritance(strategy = InheritanceStrategy.SUBCLASS_TABLE/*
   * , customStrategy =
   * complete-table
   */)
@Version(strategy = VersionStrategy.VERSION_NUMBER, extensions = { 
@Extension(vendorName = datanucleus, key = field-name, value = 
versionField) })
public abstract class AbstractXMSDomainObject extends 
org.apache.isis.applib.AbstractDomainObject implements DomainObject, 
ComparableAbstractXMSDomainObject {

…
public void updating() {
this.setDateUpdated(Clock.getTimeAsDateTime().toDate());
this.setUpdatedByUser(this.domainFactoryService.currentUserName());
}
…
}


This was running smoothly with the previous 1.6.0-SNAPSHOT we were using.

The exception log is  the following:


[…]

at 
org.datanucleus.api.jdo.JDOCallbackHandler.preDirty(JDOCallbackHandler.java:262)
at 
org.datanucleus.state.JDOStateManager.updateField(JDOStateManager.java:2007)
at 
org.datanucleus.state.JDOStateManager.setObjectField(JDOStateManager.java:1935)
at 
com.xms.framework.api.domain.model.isis.AbstractXMSDomainObject.setDateUpdated(AbstractXMSDomainObject.java)
at 
com.xms.framework.api.domain.model.isis.AbstractXMSDomainObject.updating(AbstractXMSDomainObject.java:284)
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
org.apache.isis.core.commons.lang.MethodExtensions.invoke(MethodExtensions.java:53)
at 
org.apache.isis.core.commons.lang.MethodExtensions.invoke(MethodExtensions.java:47)
at 
org.apache.isis.core.commons.lang.MethodUtil.invoke(MethodUtil.java:35)
at 
org.apache.isis.core.metamodel.adapter.ObjectAdapter$InvokeUtils.invokeAll(ObjectAdapter.java:342)
at 
org.apache.isis.core.metamodel.facets.object.callbacks.update.UpdatingCallbackFacetViaMethod.invoke(UpdatingCallbackFacetViaMethod.java:67)
at 
org.apache.isis.core.metamodel.facets.object.callbacks.CallbackFacet$Util.callCallback(CallbackFacet.java:44)
at 
org.apache.isis.objectstore.jdo.datanucleus.persistence.FrameworkSynchronizer$4.run(FrameworkSynchronizer.java:256)
at 
org.apache.isis.objectstore.jdo.datanucleus.persistence.FrameworkSynchronizer$8.call(FrameworkSynchronizer.java:350)
at 
org.apache.isis.objectstore.jdo.datanucleus.persistence.FrameworkSynchronizer$8.call(FrameworkSynchronizer.java:346)
at 
org.apache.isis.objectstore.jdo.datanucleus.persistence.FrameworkSynchronizer.withLogging(FrameworkSynchronizer.java:335)
at 
org.apache.isis.objectstore.jdo.datanucleus.persistence.FrameworkSynchronizer.withLogging(FrameworkSynchronizer.java:346)
at 
org.apache.isis.objectstore.jdo.datanucleus.persistence.FrameworkSynchronizer.preDirtyProcessingFor(FrameworkSynchronizer.java:229)
at 
org.apache.isis.objectstore.jdo.datanucleus.persistence.IsisLifecycleListener$4.doRun(IsisLifecycleListener.java:111)
at 
org.apache.isis.objectstore.jdo.datanucleus.persistence.IsisLifecycleListener$RunnableAbstract.run(IsisLifecycleListener.java:206)
at 
org.apache.isis.objectstore.jdo.datanucleus.persistence.IsisLifecycleListener.withLogging(IsisLifecycleListener.java:185)
at 
org.apache.isis.objectstore.jdo.datanucleus.persistence.IsisLifecycleListener.preDirty(IsisLifecycleListener.java:107)
at 
org.datanucleus.api.jdo.JDOCallbackHandler.preDirty(JDOCallbackHandler.java:262)
at 
org.datanucleus.state.JDOStateManager.updateField(JDOStateManager.java:2007)
at 
org.datanucleus.state.JDOStateManager.setObjectField(JDOStateManager.java:1935)
at 
com.xms.framework.api.domain.model.isis.AbstractXMSDomainObject.setDateUpdated(AbstractXMSDomainObject.java)
at 
com.xms.framework.api.domain.model.isis.AbstractXMSDomainObject.updating(AbstractXMSDomainObject.java:284)
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
org.apache.isis.core.commons.lang.MethodExtensions.invoke(MethodExtensions.java:53)
at 
org.apache.isis.core.commons.lang.MethodExtensions.invoke(MethodExtensions.java:47)
at 
org.apache.isis.core.commons.lang.MethodUtil.invoke(MethodUtil.java:35)
at 

IllegalStateException: Event bus has already been created; too late to register any further (singleton) subscribers

[GESCONSULTOR - Óscar Bou]

Hi all,

I’m launching tests with have Services with Event Handlers this way:

public class MonitoringSystemInitializer {
…
private static class MonitoringIntegTestBuilder extends 
IsisSystemForTest.Builder {

private MonitoringIntegTestBuilder() {
…
this.withServices(new 
ExternalSystemsMonitoringInformationEventHandler() ...
 
...
}
…
}



public class ExternalSystemsMonitoringInformationEventHandler extends 
AbstractXMSService {

   …

// {{ injected: EventBusService
@Programmatic
@PostConstruct
public void postConstruct() {
this.eventBusService.register(this);
}

@Programmatic
@PreDestroy
public void preDestroy() {
this.eventBusService.unregister(this);
}

@javax.inject.Inject
private EventBusService eventBusService;
// }}


}




When launching the tests the following exception is thrown:



java.lang.IllegalStateException: Event bus has already been created; too late 
to register any further (singleton) subscribers
at 
org.apache.isis.core.runtime.services.eventbus.EventBusServiceDefault.register(EventBusServiceDefault.java:68)
at 
com.xms.framework.risk.domain.model.RiskCategories.setEventBusService(RiskCategories.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.isis.core.metamodel.services.ServicesInjectorDefault.invokeMethod(ServicesInjectorDefault.java:254)
at 
org.apache.isis.core.metamodel.services.ServicesInjectorDefault.invokeInjectorMethod(ServicesInjectorDefault.java:286)
at 
org.apache.isis.core.metamodel.services.ServicesInjectorDefault.autowire(ServicesInjectorDefault.java:239)
at 
org.apache.isis.core.metamodel.services.ServicesInjectorDefault.autowireViaPrefixedMethods(ServicesInjectorDefault.java:229)
at 
org.apache.isis.core.metamodel.services.ServicesInjectorDefault.injectServices(ServicesInjectorDefault.java:182)
at 
org.apache.isis.core.metamodel.services.ServicesInjectorDefault.injectServicesInto(ServicesInjectorDefault.java:148)
at 
org.apache.isis.core.runtime.persistence.adaptermanager.AdapterManagerDefault.mapAndInjectServices(AdapterManagerDefault.java:750)
at 
org.apache.isis.core.runtime.persistence.adaptermanager.AdapterManagerDefault.adapterFor(AdapterManagerDefault.java:184)
at 
org.apache.isis.core.runtime.system.persistence.PersistenceSession.createServiceAdapters(PersistenceSession.java:208)
at 
org.apache.isis.core.runtime.system.persistence.PersistenceSession.initServices(PersistenceSession.java:194)
at 
org.apache.isis.core.runtime.system.persistence.PersistenceSession.open(PersistenceSession.java:184)
at 
org.apache.isis.core.runtime.system.session.IsisSessionDefault.open(IsisSessionDefault.java:97)
at 
org.apache.isis.core.runtime.system.context.IsisContextStatic.openSessionInstance(IsisContextStatic.java:71)
at 
org.apache.isis.core.runtime.system.context.IsisContext.openSession(IsisContext.java:271)
at 
org.apache.isis.core.integtestsupport.IsisSystemForTest.openSession(IsisSystemForTest.java:405)
at 
org.apache.isis.core.integtestsupport.IsisSystemForTest.openSession(IsisSystemForTest.java:400)
at 
org.apache.isis.core.integtestsupport.IsisSystemForTest.bounceSystem(IsisSystemForTest.java:395)
at 
org.apache.isis.core.integtestsupport.IntegrationTestAbstract$IsisTransactionRule$1.evaluate(IntegrationTestAbstract.java:202)
at 
org.apache.isis.core.unittestsupport.jmocking.JUnitRuleMockery2$1.evaluate(JUnitRuleMockery2.java:146)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:168)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at 

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[GESCONSULTOR - Óscar Bou]

.
 com.mycompany.myapp.pd.*com.mycompany.myapp.ui.*
 David.
 
 On Thursday, 1 January 2015 3:24 AM, Branham, Jeremy [HR] 
 jeremy.d.bran...@sprint.com wrote:
 
 
 What would it look like with @Model?
 Giving more specificity than ‘Object’ but opening the interpretation to 
 Entities and ViewModels.
 
 Or am I overlooking something? [I am new to Isis]
 
 (fyi - there is a name clash with Model in Spring-MVC)
 
 
 Jeremy D. Branham
 Tel: **DOTNET
 
 From: Jeroen van der Wal [mailto:jer...@stromboli.it]
 Sent: Wednesday, December 31, 2014 7:37 AM
 To: dev; users
 Subject: Re: ISIS-970 ... (new annotations) please review if you get a 
 chance...
 
 I like this discussion because it's defining where Apache Isis is right now. 
 Personally I think Isis has grown far beyond the concepts of DDD so sticking 
 to it's grammar would limit ourselves.
 
 In the applications I'm developing things aren't black or white: we have view 
 models that represent documents in a CMIS document store but in DDD terms 
 they are domain entities. We have view models that are based on entries in a 
 database view but in DDD terms these are domain entities. We have view models 
 that are created on the fly and never get persisted but in DDD terms they are 
 domain entities.
 
 As you might expect I opt to simply call everything a domain object. Residing 
 in the application's domain object model. Very easy to explain to newcomers 
 too.
 
 Cheers,
 
 Jeroen
 
 
 On Wed, Dec 31, 2014 at 1:13 PM, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.commailto:o@gesconsultor.com wrote:
 Hi to all.
 
 
 I'm thinking about it but still convinced of option 1 ...
 
 In my opinion, annotations are going to be our main API. So they must be 
 thought from the user's perspective, more than from the implementation's 
 perspective.
 
 In that way, aligning with DDD concepts (that are the most widely spread) is 
 more important to me than implementation criteria.
 
 So I would keep my vote for implementing:
 
 @DomainEntity
 @ViewModel
 @DomainEntityLayout
 @ViewModelLayout
 
 
 
 Regarding adding the Domain preffix to properties and collections, I think 
 it's not needed.
 
 As Dan's exposed, they are present on any type of class (despite being a 
 domain or application level one).
 As they're annotations an not classes, in my current setup (based on Apache 
 Isis latest snapshot):
 - @Property does not conflict with any other annotation (i.e., no identically 
 named annotation is present on any dependency).
 - @Collection does not conflict with any other annotation.
 - @Action clashes with the javax.xml.ws.Action annotation.
 - @Parameter clashes with the org.junit.runners.parammetrized.Parameter 
 annotation.
 
 None of them can be confused with Isis ones by a junior developer.
 
 In fact, this clash conflict was already present with @Named (that it's going 
 to be kept) and same other Apache Isis annotations without being more 
 relevant.
 
 So my opinion would be to not add the Domain prefix to them.
 
 
 Perhaps this could also be a good moment to add a collateral debate :)
 
 In my head, I also associate Collections with Properties. I would consider 
 Simple Properties and Collection Properties.
 So perhaps naming could be instead SimpleProperty and CollectionProperty 
 ? :-))
 
 
 
 HTH,
 
 Oscar
 
 
 
 
 
 
 El 31/12/2014, a las 12:39, Vladimir Nišević 
 vnise...@gmail.commailto:vnise...@gmail.com escribió:
 
 
 I would vote for most well described DDD terms (described in Evans book) - 
 this would help users to adopt/understand ISIS framework easier and have a 
 kind of reference documentation. Term 'Object' is too general, and Business 
 Object modelling antipatterns are also very wide spreaded, e.g. by people 
 like enterpise information modelling architects...
 
 Regs, Vladimir
 
 
 
 Am 31.12.2014 um 07:40 schrieb Dan Haywood 
 d...@haywood-associates.co.ukmailto:d...@haywood-associates.co.uk:
 
 
 On 30 December 2014 at 23:44, David Tildesley 
 davo...@yahoo.co.nzmailto:davo...@yahoo.co.nz wrote:
 
 +1 for the counter proposal (although I would suggest cloning/deriving
 @DomainObjectLayout to @ViewModelLayout etc. so that Domain* tags are 
 not used in ViewModel - less confusing).
 
 On a different thread to dev@ I also made a related proposal that @Property, 
 @Collection, @Action etc be renamed to @DomainProperty, @DomainCollection, 
 @DomainAction etc... the primary reason being that clashes with @Collection 
 clashes with java.util.Collection, plus I like the idea of all Isis-related 
 annotations starting with an @DomainXxx prefix.
 
 No one's commented on that, yet.
 
 Given your preference of @ViewModel and reserving @Domain to be strictly 
 for domain layer concepts, would I be right to guess you wouldn't be in 
 favour of adding Domain as a prefix to all those annotations?
 
 
 
 
 
 
 
  On Tuesday, 30 December 2014 3:07 AM, Dan Haywood  
 d...@haywood-associates.co.ukmailto:d...@haywood-associates.co.uk wrote:
 
 
 On 29 December 2014 at 13:23

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[GESCONSULTOR - Óscar Bou]

Hi to all.


I'm thinking about it but still convinced of option 1 ...

In my opinion, annotations are going to be our main API. So they must be 
thought from the user's perspective, more than from the implementation's 
perspective.

In that way, aligning with DDD concepts (that are the most widely spread) is 
more important to me than implementation criteria.

So I would keep my vote for implementing:

@DomainEntity
@ViewModel
@DomainEntityLayout
@ViewModelLayout



Regarding adding the Domain preffix to properties and collections, I think 
it's not needed.

As Dan's exposed, they are present on any type of class (despite being a 
domain or application level one).
As they're annotations an not classes, in my current setup (based on Apache 
Isis latest snapshot):
- @Property does not conflict with any other annotation (i.e., no identically 
named annotation is present on any dependency).
- @Collection does not conflict with any other annotation.
- @Action clashes with the javax.xml.ws.Action annotation.
- @Parameter clashes with the org.junit.runners.parammetrized.Parameter 
annotation.

None of them can be confused with Isis ones by a junior developer.

In fact, this clash conflict was already present with @Named (that it's going 
to be kept) and same other Apache Isis annotations without being more relevant.

So my opinion would be to not add the Domain prefix to them.


Perhaps this could also be a good moment to add a collateral debate :)

In my head, I also associate Collections with Properties. I would consider 
Simple Properties and Collection Properties. 
So perhaps naming could be instead SimpleProperty and CollectionProperty ? 
:-))



HTH,

Oscar





 El 31/12/2014, a las 12:39, Vladimir Nišević vnise...@gmail.com escribió:
 
 I would vote for most well described DDD terms (described in Evans book) - 
 this would help users to adopt/understand ISIS framework easier and have a 
 kind of reference documentation. Term 'Object' is too general, and Business 
 Object modelling antipatterns are also very wide spreaded, e.g. by people 
 like enterpise information modelling architects...
 
 Regs, Vladimir
 
 
 Am 31.12.2014 um 07:40 schrieb Dan Haywood d...@haywood-associates.co.uk:
 
 On 30 December 2014 at 23:44, David Tildesley davo...@yahoo.co.nz wrote:
 
 +1 for the counter proposal (although I would suggest cloning/deriving
 @DomainObjectLayout to @ViewModelLayout etc. so that Domain* tags are
 not used in ViewModel - less confusing).
 
 On a different thread to dev@ I also made a related proposal that
 @Property, @Collection, @Action etc be renamed to @DomainProperty,
 @DomainCollection, @DomainAction etc... the primary reason being that
 clashes with @Collection clashes with java.util.Collection, plus I like the
 idea of all Isis-related annotations starting with an @DomainXxx prefix.
 
 No one's commented on that, yet.
 
 Given your preference of @ViewModel and reserving @Domain to be strictly
 for domain layer concepts, would I be right to guess you wouldn't be in
 favour of adding Domain as a prefix to all those annotations?
 
 
 
 
 
 
On Tuesday, 30 December 2014 3:07 AM, Dan Haywood 
 d...@haywood-associates.co.uk wrote:
 
 
 On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:
 
 Ok.
 
 So let's raise some questions/doubts :)
 
 *** @DomainObject  ***
 
 Is a ViewModel a DomainObject at all ?
 it's a good question, and I've debated it myself.  Let me lay out my
 thinking on this so far and see if we can collectively come to a view on
 this.
 
 First thing to note is that there are two varieties of view models (even
 though the implementation is identical)
 
 - those that are part of the domain layer and are, conceptually at least,
 entities, but where the persistence is managed outside of Isis.  An example
 is a document in a CMS
 - those that are part of the application layer, and represent a view on top
 of one or more entities.
 
 Of course, we expect an application layer to depend on the domain layer and
 not vice versa, but even so, because some view models are conceptually
 entities I suspect that in a typical Isis application it will be reasonable
 to allow JDO-managed domain entities to interact with externally-managed
 view model entities.
 
 
 Because of this, I've been thinking of DomainObject as being a superset
 of both entities and view models.
 
 
 
 
 I would consider them as a different kind, so the @ViewModel annotation
 shouldn't be deleted.
 
 You are certainly right that quite a few of the features in @DomainObject
 don't apply to view models (even if conceptually they are entities)...
 because we rely on JDO to implement.  Specifically:
 
 - auditing... requires JDO so doesn't apply to view models
 - publishing ... requires JDO so doesn't apply to view models
 - bounded = not sure... even though doesn't depend on JDO, suspect that it
 isn't supported for view models
 
 - autoComplete ... is supported for view models
 - editing

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[GESCONSULTOR - Óscar Bou]

Ok.

So let's raise some questions/doubts :)

*** @DomainObject  ***

Is a ViewModel a DomainObject at all ?

I would consider them as a different kind, so the @ViewModel annotation 
shouldn't be deleted.
Also, perhaps we can introduce Isis platform logic like not saving/persisting 
view models, etc. If that would be the case, the editing and 
editingDisabledReason at least might not have any sense. 


If so, I would better align with DDD naming conventions, in order to gain 
acceptance.

So, names should be @Entity or @DomainEntity (for avoiding name collision with 
JPA) - instead of @DomainObject -.


I like the @DomainService name, as it can act as a DDD Factory and/or 
Repository.


As currently there's no special support for AggregateRoots or ValueObjects, 
no more annotations are needed.


So the proposed set would be:
• @ViewModel and @ViewModelLayout
• @DomainService and @DomainServiceLayout
• @DomainEntity and @DomainEntityLayout
• @Property and @PropertyLayout
• @Collection and @CollectionLayout
• @Action and @ActionLayout
• @Parameter and @ParameterLayout


*** @Property  ***

- I would propose to rename notPersisted to transient.
- Also, not sure about the exact meaning of regexPatternFlags. Should it be 
an Enum?
- I misunderstood cardinality. I always associated it with a number. 
Perhaps a better name could be isMandatory with a TRUE | FALSE | DEFAULT 
enum associated to its value? Another alternative could be persisting and 
default values DEFAULT | OPTIONAL | MANDATORY. Or, in order to be more 
generic (for example, to use the same name on the @Parameter annotation, it 
could be something like required.


*** @Parameter  ***

- Same as @Property. I suggest to rename cardinality to required.



HTH,

Oscar




 El 29/12/2014, a las 11:45, Martin Grigorov mgrigo...@apache.org escribió:
 
 Hi,
 
 Looks good to me!
 
 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov
 
 On Mon, Dec 29, 2014 at 12:36 PM, Dan Haywood d...@haywood-associates.co.uk
 wrote:
 
 Hi folks,
 
 have done some further tidy up on the new annotations for domain semantics,
 ie @DomainObject, @Property, @Collection, @Action and @Parameter.
 
 Nothing yet implemented in terms of facet factories, but think I have the
 annotations themselves pretty much finalized [1].
 
 Would appreciate a review from anyone interested, save me reworking stuff
 
 Cheers
 Dan
 
 [1] https://issues.apache.org/jira/browse/ISIS-970
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[GESCONSULTOR - Óscar Bou]

 El 29/12/2014, a las 15:26, Dan Haywood d...@haywood-associates.co.uk 
 escribió:
 
 On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:
 
 
 
 *** @Property  ***
 
 - I would propose to rename notPersisted to transient.
 
 
 So maybe traversable might be a better name (default = true)
 

From the uses you provide, seems that uses like:

- whether a changed property should be audited (ignore those that are
NotPersisted)
- whether a property of a view model should be used as part of its memento
(for @ViewModel)

are consequences of being transient or, at least, not part of the Isis 
Metamodel ??? 



 Given that we've historically used @Optional, perhaps it should be called
 optional = TRUE|FALSE|DEFAULT.   Also in JDO we write
 @javax.jdo.Column(allowNulls=true) so I think it'd be better to see
 @Property(optional=TRUE) rather than @Property(mandatory=FALSE).
 

I like a lot your @Property(optional=TRUE) proposal :)


 
 
 
 *** @Parameter  ***
 
 - Same as @Property. I suggest to rename cardinality to required.
 
 
 
 same comment; change to @Parameter(optional=TRUE|FALSE).  Javadoc to say
 that DEFAULT shouldn't be used (but is a synonym for FALSE).


Also here: @Parameter(optional=TRUE|FALSE)

Thanks!

 
 
 Thx again
 Dan
 
 
 
 
 
 HTH,
 
 Oscar
 
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[GESCONSULTOR - Óscar Bou]

 
 As currently there's no special support for AggregateRoots or
 ValueObjects, no more annotations are needed.
 
 
 Sounds like a vote to deprecate.  Jeroen has said the same thing.  Perhaps
 they should be deleted in v2.0 and reappear, if we want them back, in v3.0.

I agree with Jeroen.

Currently there's nothing specific about Aggregate Roots on Apache Isis, at 
least on the most used modules, AFAK.


 
 * replace @DomainObject(viewModel=false)   with
 @DomainEntity(persistence=JDO)
   ... this would be the default

I like it :)


 * replace @DomainObject(viewModel=true)with
 @DomainEntity(persistence=EXTERNAL)

This one also!

   ... for view models representing externally-persisted entities.  In the
 Javadoc, say that auditing, publishing and bounded are not supported for
 these
 * keep @ViewModel
 ... extend to include the non-entity stuff from @DomainObject that does
 apply (basically, I think that's just objectType )
  ... the intention being that this is used for application-layer views.

I agree. It should be kept for those use cases.


 
 keep @DomainObjectLayout, because everything in it applies equally to both
 view models (either variety) and JDO entities.


M I would prefer to keep symmetry... I know it introduces some 
redundant checks on implementation but, from the user's perspective, is a 
clearer model ...

 
 
 I'll reply on your points on @Property and @Parameter separately.
 
 Thx
 Dan
 
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[GESCONSULTOR - Óscar Bou]

 
 Um, but they *are* part of the Isis metamodel, because we want them to be
 rendered in the UI.   It's just that they aren't part of (what I suppose
 one might call) the persistence model.
 
 Any other suggestions if neither traversable nor notPersisted appeal?
 

No idea ... As per
 It's just that they aren't part of (what I suppose
 one might call) the persistence model.


Seems that the logical one would be notPersisted. But for you seems not 
compatible with previous @NotPersisted annotation ...

Re: Swagger - API description standard. Relevant for Restful Objects?

[GESCONSULTOR - Óscar Bou]

Simply to comment.

On [1] seems that Apache Camel latest release also documents its API using 
Swagger.

Regards,

Oscar

[1] http://www.infoq.com/news/2014/10/apache-camel-2.14


 El 25/9/2014, a las 15:26, Dan Haywood d...@haywood-associates.co.uk 
 escribió:
 
 yeah, looks really nice, Swagger.  Have made a note.
 
 On 12 September 2014 07:11, QUALITEC - Óscar Bou o...@qualitec.es wrote:
 
 
 Hi to all,
 
 I've just recently discovered the Swagger specification.
 
 There's an intro here [1], the full specification implementation can be
 found on [2] and a good example at [3].
 
 It seems a commonly accepted way to describe REST-based APIs.
 
 So perhaps it could be a great complement to current RestfulObjects
 specification.
 
 Regards,
 
 Oscar
 
 
 
 
 [1]
 http://www.infoworld.com/t/web-services/swagger-aims-become-the-de-facto-standard-apis-250196?source=IFWNLE_nlt_stradev_2014-09-11
 
 [2] https://github.com/wordnik/swagger-spec
 
 [3] http://petstore.swagger.wordnik.com


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: [ANNOUNCE] New committer - Martin Grigorov

[GESCONSULTOR - Óscar Bou]

Hi, Martin!

Welcome here and really nice contributions!

The viewer was a really important component. 
I've just convinced a mate to use the latest SNAPSHOT for a new project and 
that has given to me the opportunity yo try it.

It's really cool, so a great work all you.

Also, I've seen a lot of understanding of other parts of the framework, so it's 
really nice to count with you.

Regards,

Oscar



 El 5/12/2014, a las 9:53, Kevin Meyer ke...@kmz.co.za escribió:
 
 Congratulations, Martin, and welcome!
 
 As Jeroen says, I look forward to meeting you at the next IsisCon!
 
 Kind regards,
 Kevin
 
 
 On Thu, December 4, 2014 16:28, Dan Haywood wrote:
 I'm delighted to announce that Martin Grigorov has been voted in as a
 committer on Isis, and also as a member of the Isis PMC.  The first gives
 Martin the right to commit changes directly to Isis' codebase, the second
 gives him the right to be involved in future votes.
 
 Martin is already a key committer on the Apache Wicket [1,2] project, as
 well as actively contributing to the companion Wicket-bootstrap [3,4]
 project.  But you also can't failed to have noticed his involvement in
 Isis' users and dev lists recently.
 
 
 Initially Martin got involved because Jeroen and I asked him to help
 bootstrappify the Wicket viewer [5].  Even though that piece of work is
 substantially complete, Martin continues to be actively involved,
 providing patches and working on other tickets, and from speaking with him
 I know
 he's keen to get involved with all aspects of Isis, not just the Wicket
 viewer.  For recent contributions, check out these github statistics [6]
 and his activity stream on JIRA [7].
 
 I'm looking forward to working with Martin in the future; another great
 addition to Isis' committers.  So please join me in welcoming him to our
 happy band!
 
 Dan Haywood
 Apache Isis PMC Chair
 
 
 [1] http://wicket.apache.org/
 [2] https://github.com/apache/wicket/graphs/contributors
 [3] https://github.com/l0rdn1kk0n/wicket-bootstrap
 [4] https://github.com/l0rdn1kk0n/wicket-bootstrap/graphs/contributors
 [5] https://issues.apache.org/jira/browse/ISIS-537
 [6] https://github.com/apache/isis/graphs/contributors
 [7] https://issues.apache.org/jira/secure/ViewProfile.jspa?name=mgrigorov
 
 
 
 
 -- 
 Kevin Meyer
 Ljubljana, Slovenia
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com http://www.gesconsultor.com/ 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: Heads up! Significant UI changes in 1.8.0

[GESCONSULTOR - Óscar Bou]

Really well done, team.

In our case that originated (two years ago) to opt for adapting our 
custom-made viewer.

This will be of interest for a great part of the community for sure ...




El 22/10/2014, a las 09:11, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Just so you are all aware...
 
 ... in 1.8.0 we will be refactoring the Wicket viewer to leverage Martin
 Grigorov's integration [1] with Bootstrap [2].  (Martin is one of the core
 Apache Wicket committers).
 
 What that means is that we'll be able to support themeable pages,
 optionally switchable by the end-user.  We'll probably bundle some prebuilt
 themes from bootswatch [3], And you'll also be able to develop your own
 themes, eg using bootswatchr [4].
 
 We'll also try to provide a custom theme that is as close as possible to
 the current look-n-feel, but it will inevitably differ in some regards.
 
 This is still work-in-progress, but to get a flavour, see [5]
 
 All feedback welcome
 
 Cheers
 Dan
 
 [1] https://github.com/l0rdn1kk0n/wicket-bootstrap
 [2] http://getbootstrap.com/
 [3] http://bootswatch.com/
 [4] http://bootswatchr.com/
 [5] http://imgur.com/a/RcO5u


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: [VOTE] Apache Isis Core release 1.7.0 RC2 and related components

[GESCONSULTOR - Óscar Bou]

Hi to all.

+1 also to release.

I also needed the -L switch for the curl command, same as Martin.

Also, the script contained carriage returns that I needed to remove with:

sed -i -e 's/\r$//' verify-isis-release.sh 

I also needed 2 maven executions:
- one online, due to missing dependencies.
- one offline, in order to test it properly compiles once the dependencies are 
resolved.

Regarding functionalities included on this release, really great job!!!

Regards,

Oscar




El 16/10/2014, a las 09:15, Martin Grigorov mgrigo...@apache.org escribió:

 +1 to release
 
 tested:
 1) Download and build with verify-isis-script.sh
 Random usage of isis-app-kitchensink application
 
 2) rm -rf ~/.m2/repository
 add two repository items to isis-app-kitchensink/pom.xml for Isis and
 Wicket-Viewer using the Maven staging repos
 Random usage of isis-app-kitchensink application
 
 
 Notes:
 - verify-isis-script.sh needs '-L|--location' option to curl because of the
 change in the Maven staging repo. The provided urls respond with code 302
 and the redirects should be followed.
 
 
 
 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov
 
 On Wed, Oct 15, 2014 at 9:58 AM, Dan Haywood d...@haywood-associates.co.uk
 wrote:
 
 I've cut an (RC2) release for Apache Isis Core and related components:
 
 * Core 1.7.0
 * Wicket Viewer 1.7.0
 * SimpleApp Archetype 1.7.0
 * TodoApp Archetype 1.7.0
 
 The source code artifacts have been uploaded to staging repositories on
 repository.apache.org:
 
 *
 
 http://repository.apache.org/content/repositories/orgapacheisis-1030/org/apache/isis/core/isis/1.7.0/isis-1.7.0-source-release.zip
 *
 
 http://repository.apache.org/content/repositories/orgapacheisis-1027/org/apache/isis/viewer/isis-viewer-wicket/1.7.0/isis-viewer-wicket-1.7.0-source-release.zip
 *
 
 http://repository.apache.org/content/repositories/orgapacheisis-1028/org/apache/isis/archetype/simpleapp-archetype/1.7.0/simpleapp-archetype-1.7.0-source-release.zip
 *
 
 http://repository.apache.org/content/repositories/orgapacheisis-1029/org/apache/isis/archetype/todoapp-archetype/1.7.0/todoapp-archetype-1.7.0-source-release.zip
 
 For each zip there is a corresponding signature file (append .asc to the
 zip's url).
 
 In the source code repo the code has been tagged as isis-1.7.0-RC2,
 isis-viewer-wicket-1.7.0-RC2, simpleapp-archetype-1.7.0-RC2 and
 todoapp-archetype-1.7.0-RC2.  (Note that for the last three components, RC2
 is identical to RC1).
 
 For instructions on how to verify the release (build from binaries and/or
 use in Maven directly), see
 http://isis.apache.org/contributors/verifying-releases.html
 
 Please verify the release and cast your vote.  The vote will be open for a
 minimum of 72 hours.
 
 [ ] +1
 [ ]  0
 [ ] -1
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: ApacheISIS Vulnerability Bad Object Filter

[GESCONSULTOR - Óscar Bou]

Hi to all.

I think Dan's proposal is the best implementation possible, as it would not be 
embedded on the Domain, which would imply that could, for example, being 
configured by an admin through a UI.

This is related with an Isis Authorization module we talked about on IsisCon, 
considering things like a RBAC style (see [1], [2] for Shiro related materials; 
[3] [4] for RBAC generic introduction).

Nearly all business applications will suffer for implementing this requisite, 
so it's a good candidate for a generic Isis module.

Thanks,

Oscar

[1] 
https://shiro.apache.org/2011/05/24/the-new-rbac-resource-based-access-control.html

[2] http://sangeeth.github.com/java/shiro/rbac-using-shiro.html

[3] http://csrc.nist.gov/groups/SNS/rbac/

[4] http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf



El 30/07/2014, a las 23:37, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Hmm, not particularly keen on this suggestion... having role names embedded
 in annotations isn't a good idea, I think.
 
 For myself, I'd rather that this requirement was handled in a cross-cutting
 fashoin, through some sort of extension to the Isis' authorizor API.
 
 However, to solve this issue properly, I think we might need to extend
 Isis' security model somewhat.  Right now in the authorizor we check if a
 given user (via their roles) can view/use each of an object's members
 (properties/collections/actions) but we don't have the concept of checking
 if the user can view the object at all.
 
 If we did introduce this idea (of object-level checks), then we could also
 implement some sort of plug-in point for the authorizor such that
 instance-based authorizers (eg in a chain of responsibility pattern) could
 be added to supplement Isis' usual class-based authorizors.
 
 I know this design would work because the Naked Objects sister project
 (on .NET) works this way.
 
 Hopefully that makes some sort of sense thoughts, anyone?
 
 Dan
 
 
 
 
 On 29 July 2014 22:56, matias nahuel heredia mat...@informaticos.com
 wrote:
 
 El 29/07/14 08:16, Dan Haywood escribió:
 
 On 29 July 2014 02:28, matias nahuel heredia mat...@informaticos.com
 wrote:
 
 hi Dan!!
 how can i fix this vulnerability in Apache isis?
 https://www.youtube.com/watch?v=AghmbcVE710
 
 
 thanks for recording this, helps explain the issue.
 
 What we're talking about here is per-instance security... the idea that
 some users shouldn't be able to access some object instances (even though
 they do in general have access to other instances of a given class type,
 such as ToDoItem).
 
 As of Isis 1.6.0, the best I can suggest is to use the loaded() lifecycle
 callback (on ToDoItem itself) and have it thrown an exception if the
 object
 should not be accessible.  Then, the ExceptionRecognizer can be used to
 translate this exception into a user-friendly error message.  If the
 loaded() lifecycle callback throws the javax.jdo.ObjectNotFoundException
 then this is already detected by the default implementation of
 ExceptionRecognizer (namely ExceptionRecognizerCompositeFo
 rJdoObjectStore):
 
 
 final String ownedBy = getOwnedBy();
 final String currentUser = container.getUser().getName();
 if(!ownedBy.equals(currentUser)) {
 throw new JDOObjectNotFoundException(No such object);
 }
 
 
 This code results in a redirect to the error page with a message: Unable
 to load object. Has it been deleted by someone else?  No such object.
 The Unable to load object. Has it been deleted by someone else? bit
 comes
 from the ExceptionRecognizer, the No such object comes from the loaded()
 method.
 
 I can think of two improvements.
 
 First, it would be to move this cross-cutting concern out of the entity
 (ToDoItem) and into some single subscriber that could do this sort of
 verification for all classes.  We do have a ticket [1] to do this, I'll
 bring it forward to tackle in the next release 1.7.0.
 
 Second, the stack trace shown by Isis is rather ugly and also leaks the
 information that there is an object with the given identifier (even if the
 object itself isn't shown).  So perhaps the ExceptionRecognizer needs to
 become more sophisticated such that the stack trace will be suppressed in
 some cases.
 
 I've raised a ticket for this requirement [2], citing this thread [3]
 
 Let me know your thoughts on the above.
 
 Thanks
 Dan
 
 
 [1] https://issues.apache.org/jira/browse/ISIS-803
 [2] https://issues.apache.org/jira/browse/ISIS-846
 
 i think the better way to validate this is the creation of metanotation
 in the Framework
 like that
 @forUser(name=getOwnedBy,allfor=role1,role2)
 public class NameClass
 {
 
 
 }
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son 

Re: [VOTE] Apache Isis Core 1.6.0 and related components (RC2)

[GESCONSULTOR - Óscar Bou]

+1


El 21/07/2014, a las 17:18, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Folks,
 
 I've cut a (further) release candidate RC2 for Apache Isis Core and related
 components:
 * Core 1.6.0
 * Wicket Viewer 1.6.0
 * TodoApp Archetype 1.6.0
 * SimpleApp Archetype 1.6.0
 
 Note that
 * Core now incorporates the JDO Object store, Restful Objects viewer and
 Shiro Security.
 * TodoApp Archetype was previously called the 'Quickstart
 (Wicket/Restful/JDO) Archetype'
 * SimpleApp Archetype was prevoiously called the
 'Simple (Wicket/Restful/JDO) Archetype'
 
 The artifacts have been uploaded to staging repository on
 repository.apache.org:
 
 *
 https://repository.apache.org/service/local/repositories/orgapacheisis-1018/content/org/apache/
 isis/core/isis/1.6.0/isis-1.6.0-source-release.zip
 *
 https://repository.apache.org/service/local/repositories/orgapacheisis-1019/content/org/apache/
 isis/viewer/isis-viewer-wicket/1.6.0/isis
 -viewer-wicket-1.6.0-source-release.zip
 *
 https://repository.apache.org/service/local/repositories/orgapacheisis-1020/content/org/apache/
 isis
 /archetype/todoapp-archetype/1.6.0/todoapp-archetype-1.6.0-source-release.zip
 *
 https://repository.apache.org/service/local/repositories/orgapacheisis-1020/content/org/apache/isis/archetype/simpleapp-archetype/1.6.0/simpleapp-archetype-1.6.0-source-release.zip
 
 For each zip there is a corresponding signature file (append .asc to the
 zip's url).
 
 In the source code repo the code has been tagged as isis-1.6.0-RC2.
 
 Our website contains some suggestions of how to verify the release, see
 http://isis.apache.org/contributors/verifying-releases.html.  There is also
 a script you can use, http://isis
 .apache.org/contributors/verifying-releases-script.html.
 
 Please verify the release and cast your vote.  The vote will be open for a
 minimum of 72 hours.
 
 [ ] +1
 [ ]  0
 [ ] -1


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: [jira] [Resolved] (ISIS-796) lifecycle callback updating() is not firing

[GESCONSULTOR - Óscar Bou]

Really nice ... and useful :))


El 18/07/2014, a las 11:59, Dan Haywood (JIRA) j...@apache.org escribió:

 
 [ 
 https://issues.apache.org/jira/browse/ISIS-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
  ]
 
 Dan Haywood resolved ISIS-796.
 --
 
Resolution: Fixed
 
 lifecycle callback updating() is not firing
 -
 
Key: ISIS-796
URL: https://issues.apache.org/jira/browse/ISIS-796
Project: Isis
 Issue Type: Bug
 Components: Core: Objectstore: JDO
   Affects Versions: objectstore-jdo-1.4.0
Environment: jdo objectstore on in-memory hsqldb
   Reporter: Thomas Koren
   Assignee: Dan Haywood
Fix For: core-1.6.0
 
 
 when trying to override lifecycle callbacks, only some of them fire as 
 expected.
 working:
 - created()
 - saving()
 - persisting()
 - saved()
 - persisted()
 - updated()
 missing:
 - updating()
 - loading()
 - loaded()
 no yet tested:
 - removing()
 - removed()
 test scenario:
 - create new entity of class X
 - list all entities of X
 - open created instance
 - edit property
 - click 'ok'
 result:
 according to the logfile, updated is called right after the corresponding 
 datastore UPDATE (as expected), but updating is missing.
 
 
 
 --
 This message was sent by Atlassian JIRA
 (v6.2#6252)


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Isis Demo link on the website

[GESCONSULTOR - Óscar Bou]

Hi to all.

I've just noticed the link on Screenshots - Online Demo pointint to [1].

The user and password for testing is not written in any screen, etc. I think. 
Despite being the default sven  pass combination.


HTH,

Oscar


[1] http://mmyco.co.uk:8180/isis-onlinedemo/

Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing

[GESCONSULTOR - Óscar Bou]

Just one more thing for the roadmap.

We also mentioned on IsisCon (but also I can remember Dan mentioned something 
similar on the mailing list as his intention for version 2) that domain objects 
(domain entity instances) could be wrapped by default, acting as a 
container of the business logic and ensuring it was preserved by default when 
invoked  from other domain objects.

That would imply that, for example, a call to:

domainObject.someAction(x, y, z);

Would always validate the parameters, choices, etc. and all other associated 
business logic.

And that a call to:

domainObject.setXXX(x);

would always preserve the business rules implemented on the modifyXXX, 
validateXXX, clearXXX methods, for example.


It has many advantages, for example for testing. It really avoids programming 
errors originated by invoking in the domain actions or setters without taking 
into account validations or business logic inside the modifyXXX methods, for 
example.

In our case, nearly all our actions are setter invocations are made through:

this.wrap(domainObject).setXXX,  this.wrap(domainObject).actionXXX 

or, if they're hidden or disabled,

this.wrapSkipRules(domainObject).setXXX,  
this.wrapSkipRules(domainObject).actionXXX 


That strategy of always wrapping helps REALLY A LOT while debugging.


Sincerelly, this was one of our expectations when we arrived to Isis. And we 
don't know of any other platform that always tries to preserve all business 
logic.


Thay would imply that Isis would act as a true hexagonal architecture when 
the UI just is another port-adapter, with exactly the same behavior as any 
other invokation from any other port-adapter, and what it's most exclusive of 
any platform, doing the same with intra-domain invocations.

Any thoughts?


Thanks,

Oscar


 




El 10/06/2014, a las 21:28, Kevin Meyer - KMZ ke...@kmz.co.za escribió:

 Quick immediate reply:
 
 ~
 Some of the ideas that follow build upon each other, some are independent
 of each other.  I won't attempt to outline an exact timetable, but you can
 see that some of this work could be performed in parallel.  For example,
 improved Shiro support (4) could be done at the same time as simplifying
 the framework (1).
 
 1. Simplifying the framework
 
 * Isis will run only as a server-side webapp.  This implies that the DnD
 viewer will be retired.  This will also enable Isis' bootstrapping to be
 simplified and rationalized.
 
 By the way: A DnD viewer can be later re-implemented, if so desired. 
 
 * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
 ObjectStore implementation then made part of core.  The other ObjectStore
 implementations will be retired.  This step in particular should enable
 considerable simplification
 
 As described, this is a temporary state, with a future plan to later 
 abstract out a new Objectstore API to support other objectstore 
 frameworks. See below.
 
 * Isis will adopt the Shiro authentication classes rather than define its
 own.  This will also allow authentication to be moved into the core.
 
 I have no comment :)
 
 3. Alternative Persistence providers
 
 Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
 object tracking) and on DataNucleus in particular, the next step in the
 roadmap is to re-introduce pluggability so that developers can use other
 ORM implementations; particularly for the JPA API.  Being an Apache product
 means that we cannot dependent on certain licenses, but we certainly
 provide alternative implemenation based on either Apache OpenJPA, or on
 EclipseLink (the old TopLink product).
 
 We might also look to provide an implementation for the market leader,
 namely Hibernate.  However, because Hibernate is LGPL, this implementation
 would need to live outside of Apache Isis' formal codebase, eg in the
 apache-extras.org site or perhaps just likely on github.
 
 
 4. Improved support for Shiro
 
 We've noticed a number of users wanting to use our Shiro integration, with
 Shiro configured to use a JDBC Realm.  It ought to be relatively simple to
 build Isis entities that map onto the Shiro concepts (users, roles,
 permissions).  In this way Isis could provide a self-contained security
 subsystem for managing users out-of-the-box.
 
 We anticipate delivering this as an optional module that could be included
 as necessary.
 
 An extension of this is to deliver a standalone application built with Isis
 for administrating the users/roles/permissions for any application
 configured to use the Shiro JDBC realm (not just an Isis application).
 
 The discussions I've had and heard regarding other application 
 development suites lead me to believe that this would be an extremely 
 useful add-on!  I'd almost like to request that this be the first thing 
 worked on, before any of the fundamental changes listed above.
 
 But that's just my wish.
 
 (I'd like to demo that Isis can also support RBAC, out-of-the-box).
 
 
 
 5. Other Reusable 

Re: [jira] [Created] (ISIS-803) Replace lifecycle methods with additional EventBus events.

[GESCONSULTOR - Óscar Bou]

Hi, Dan.

I think that the lifecycle PostsXXX events were still incomplete.

There's one thing I don't have clear enough from your comments.

Also, we cannot impede that a user use the JDO or JPA standard methods. So, 
despite they are a not good practice, we at least should support when the 
standard JDO (JPA in the future) lifecycle methods are used (i.e., by 
detecting the changes on those domain objects, if that's used by Isis; but 
not sure if there's something special to do by Isis).



El 13/06/2014, a las 08:29, Dan Haywood (JIRA) j...@apache.org escribió:

 Dan Haywood created ISIS-803:
 
 
 Summary: Replace lifecycle methods with additional EventBus 
 events.
 Key: ISIS-803
 URL: https://issues.apache.org/jira/browse/ISIS-803
 Project: Isis
  Issue Type: Improvement
  Components: Core
Affects Versions: core-1.5.0
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: core-2.0.0
 
 
 This issue is to remove a feature that is only partly implemented in the JDO 
 objectstore, namely the lifecycle methods.
 
 Jeroen and I were discussing this, and think they are possibly an 
 anti-pattern since they tend to lead to fragile code.
 
 Rather than have the object pushing changes to others, it would be better 
 if an event were broadcast via the EventBus.  That way a subscribing service 
 could pull appropriate changes and do whatever is necessary.
 
 
 
 --
 This message was sent by Atlassian JIRA
 (v6.2#6252)


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: [jira] [Comment Edited] (ISIS-781) Add edit capability to view objects

[GESCONSULTOR - Óscar Bou]

It seems ok to me also.

Currently, if you want to execute business logic when changing a field's value, 
it usually impacts on the UI as there's an associated action and the field is 
marked as @Disabled.
It was not so common to write the business logic on a modifyXXX method.

It's true that the entity must be fully refreshed as its properties could be 
changed due to action's or modifyXXX behavior (at least for those with a 
modifyXXX method; for those with a simple setXXX method perhaps is safe to 
assume that only that field has changed, so the refresh option can be avoided 
if simply the entered value is preserved).






El 17/05/2014, a las 10:17, Dan Haywood (JIRA) j...@apache.org escribió:

 
[ 
 https://issues.apache.org/jira/browse/ISIS-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998522#comment-13998522
  ] 
 
 Dan Haywood edited comment on ISIS-781 at 5/17/14 8:17 AM:
 ---
 
 Related to this, Jeroen and I have been talking about maybe changing the 
 Wicket viewer so that it works a bit like JIRA ... only allow a single field 
 to be updated at a time.  I've raised ISIS-784 for this.
 
 If this was done, then potentially quite a lot of code in Wicket viewer might 
 simplify... I'm thinking that much of the current edit stuff could go and 
 instead use the existing code for invoking actions.
 
 One of the side-effects of such a refactoring is that we would inherit the 
 ability that the result of the action/edit could be a different object.
 
 How that relates to this is that, although it would seem that the view model 
 object is mutable, in fact the user would be looking at a new object that has 
 taken the place of the original.
 
 
 was (Author: danhaywood):
 Related to this, Jeroen and I have been talking about maybe changing the 
 Wicket viewer so that it works a bit like JIRA ... only allow a single field 
 to be updated at a time.  
 
 If this was done, then potentially quite a lot of code in Wicket viewer might 
 simplify... I'm thinking that much of the current edit stuff could go and 
 instead use the existing code for invoking actions.
 
 One of the side-effects of such a refactoring is that we would inherit the 
 ability that the result of the action/edit could be a different object.
 
 How that relates to this is that, although it would seem that the view model 
 object is mutable, in fact the user would be looking at a new object that has 
 taken the place of the original.
 
 Add edit capability to view objects
 ---
 
Key: ISIS-781
URL: https://issues.apache.org/jira/browse/ISIS-781
Project: Isis
 Issue Type: Improvement
 Components: Core
   Affects Versions: core-1.4.0
   Reporter: David Tildesley
   Assignee: Dan Haywood
Fix For: viewer-wicket-1.5.0
 
 
 View object should have the same capability as domain object in the viewer. 
 Currently it does not support edit. Without this capability, actions must 
 be employed and state management becomes more of an issue on the server side.
 The view object should support all of the viewer specific semantics that the 
 domain objects support via the viewer generation. 
 
 
 
 --
 This message was sent by Atlassian JIRA
 (v6.2#6252)


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: [jira] [Created] (ISIS-804) Make (entity) properties read-only by default.

[GESCONSULTOR - Óscar Bou]

Hi to all.

Mmmm... this is a quite controversial proposal!!!

Nice to be able to discuss about this so disruptive implementation :-))

In my opinion, this can lead to quite misinterpretations. The usual 
expectations for anybody coming into Isis (or migrating his current JDO - JPA 
in the near future - into Isis) there would be for all properties with both 
getter and setter to be writable.

If we analize our entities, nearly all properties have getters and setters. 
This proposal would force us to create modifyXXX and clearXXX methods for all 
them, invalidating the model.

Perhaps this more restrictive model could be optional, but my opinion would be 
to keep it as writeable by default (as it's assumed by nearly all other 
platforms or frameworks).

Just my 2 cents...

Also, to implement modifyXXX and clearXX would not imply that tests are 
available for all them, so the responsibility to properly testing them would 
not be delegated to the platform. So the programmer would not avoid to write to 
all tests.

Sorry for not agreeing (by now ..) :-))



El 13/06/2014, a las 08:41, Dan Haywood (JIRA) j...@apache.org escribió:

 Dan Haywood created ISIS-804:
 
 
 Summary: Make (entity) properties read-only by default.
 Key: ISIS-804
 URL: https://issues.apache.org/jira/browse/ISIS-804
 Project: Isis
  Issue Type: Improvement
  Components: Core
Affects Versions: core-1.5.0
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: core-1.6.0
 
 
 Currently properties are read/write by default; the programmer has to 
 annotate with @Disabled (or equivalent) to make read-only.
 
 While this subtractive programming approach is nice for demo's, the truth 
 is that with larger applications, if not rigorously and completely tested, 
 the end-user may get the opportunity to change something that they ought not; 
 potentially corrupting data.
 
 It would be better (and safer) for properties to be read-only by default.
 
 The presence of the modifyXxx(...)/clearXxx() supporting methods would then 
 indicate that they are read-write.
 
 Another possible benefit is that - if we implement ISIS-273 (to read from 
 fields) then the amount of boilerplate would substantially be reduced if a 
 tool like Lombok was used.  That is, read-only properties would consist 
 solely of a private field; read-write properties would be the field plus the 
 modify/clear.
 
 It might also make sense for the clearXxx() method to be optional; that is, 
 to allow modifyXxx(..) to be called with null.
 
 NB: for view models, properties could (perhaps) remain as read-write; there 
 are no side-effects.
 
 This change requires discussion on the mailing list.
 
 
 
 --
 This message was sent by Atlassian JIRA
 (v6.2#6252)


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: [VOTE] Apache Isis Core release 1.5.0 and related components

[GESCONSULTOR - Óscar Bou]

+1

El 05/06/2014, a las 23:56, Jeroen van der Wal jer...@stromboli.it escribió:

 +1
 
 On Mon, Jun 2, 2014 at 6:14 PM, Dan Haywood
 d...@haywood-associates.co.uk wrote:
 my own +1.
 
 
 
 
 On 2 June 2014 16:22, Maurizio Taverna tavernamauri...@gmail.com wrote:
 
 +1
 
 
 2014-06-02 15:37 GMT+02:00 Dan Haywood d...@haywood-associates.co.uk:
 
 Folks,
 
 I've cut a release for Apache Isis Core and related components:
 * Core 1.5.0
 * JDO Object Store 1.5.0
 * Wicket Viewer 1.5.0
 * Restful Objects Viewer 2.3.0
 * Shiro Security 1.5.0
 * Quickstart Archetype 1.5.0
 * Simple Archetype 1.5.0
 
 The artifacts have been uploaded to staging repositories on
 repository.apache.org:
 
 *
 
 
 https://repository.apache.org/service/local/repositories/orgapacheisis-1012/content/org/apache/isis/core/isis/1.5.0/isis-1.5.0-source-release.zip
 *
 
 
 https://repository.apache.org/service/local/repositories/orgapacheisis-1012/content/org/apache/isis/objectstore/isis-objectstore-jdo/1.5.0/isis-objectstore-jdo-1.5.0-source-release.zip
 *
 
 
 https://repository.apache.org/service/local/repositories/orgapacheisis-1012/content/org/apache/isis/viewer/isis-viewer-wicket/1.5.0/isis-viewer-wicket-1.5.0-source-release.zip
 *
 
 
 https://repository.apache.org/service/local/repositories/orgapacheisis-1012/content/org/apache/isis/viewer/isis-viewer-restfulobjects/2.3.0/isis-viewer-restfulobjects-2.3.0-source-release.zip
 *
 
 
 https://repository.apache.org/service/local/repositories/orgapacheisis-1012/content/org/apache/isis/security/isis-security-shiro/1.5.0/isis-security-shiro-1.5.0-source-release.zip
 *
 
 
 https://repository.apache.org/service/local/repositories/orgapacheisis-1013/content/org/apache/isis/archetype/quickstart_wicket_restful_jdo-archetype/1.5.0/quickstart_wicket_restful_jdo-archetype-1.5.0-source-release.zip
 *
 
 
 https://repository.apache.org/service/local/repositories/orgapacheisis-1013/content/org/apache/isis/archetype/simple_wicket_restful_jdo-archetype/1.5.0/simple_wicket_restful_jdo-archetype-1.5.0-source-release.zip
 
 For each zip there is a corresponding signature file (append .asc to the
 zip's url).
 
 In the source code repo the releases are on the prepare/isis-1.5.0-RC1
 branch, with tags for each release associated with relevant commits on
 that
 branch.
 
 Our website contains some suggestions of how to verify the release, see
 http://isis.apache.org/contributors/verifying-releases.html.  There is
 also
 a script you can use,
 http://isis.apache.org/contributors/verifying-releases-script.html.
 
 Please verify the release and cast your vote.  The vote will be open for
 a
 minimum of 72 hours.
 
 [ ] +1
 [ ]  0
 [ ] -1
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: Event Bus Service - DN behavior auto registering services with methods annotated with @Subscribe

[GESCONSULTOR - Óscar Bou]

 behaviour:
 
 given the reference is not in the collection
 when the reference is added
 then add() returns true
 and then user sees ...???
 
 given the reference is already in the collection
 when the reference is added
 then add() returns false
 and then user sees ...???
 
 given (the reference may or may not be in the collection)
 when an attempt is made to add the reference
 and when a system exception occurs (eg database server down)
 then add() should throw an exception.
 and then user sees ...???
 
 Dan
 
 
 
 
 HTH,
 
 Oscat
 
 
 
 
 Disculpa que sea breve.
 Enviado desde mi móvil
 
 El 16/05/2014, a las 16:39, Dan Haywood d...@haywood-associates.co.uk
 escribió:
 
 On 16 May 2014 09:43, GESCONSULTOR - Óscar Bou o@gesconsultor.com
 wrote:
 
 
 Hi all.
 Hi Oscar,
 this has only just come through to my mailbox, even though you sent it
 ~5
 hours ago.  I've also been having a variety of commit messages etc
 delayed,
 some by as much as 5 days(!).  Not sure if the problem is at my end or
 at
 ASFs (but I suspect perhaps the latter...)
 
 Have you noticed any delays?
 
 
 
 I'm implementing the new support for automatic simple and collection
 properties change events (@PostsPropertyChangedEvent, @
 PostsCollectionAddedToEvent, @PostsCollectionRemovedFromEvent) and the
 new
 mechanism works really nice :-))
 
 I've just initially forgot to register the service as an event
 subscriber,
 thinking that it was unnecessary. So perhaps auto-registering the
 service
 when detecting the guava's @Subscribe annotation would be a good
 enhancement.
 OK, I'll raise a ticket.
 
 
 
 
 I've found that an exception thrown by DN has been hidden by Isis.
 Just so I'm clear ... this is unrelated to the event bus stuff, correct?
 
 
 
 
 The root-cause is because I have not properly defined the @Inheritance
 mappings correctly, but the relevant thing from Isis perspective is
 that DN
 does not throw any exception if, on a collection annotated with @Join,
 the
 add is not properly executed.
 
 
 When the
 
 this.getAggregatedServices().add(service);
 
 
 Is called, the following exception occurs:
 [snip]
 But DN does not throw any exception. It simply returns false when
 exiting
 the
 
 this.getAggregatedServices().add(service);
 
 method ...
 
 The DN implementation is on [1].
 
 So seems that it's mandatory to evaluate the result of add 
 I don't think this is a bug, I believe that DN is conforming to the
 semantics of Set#add(...).  I've just mailed Andy @ DN for
 clarification.
 
 
 
 I understand that an ApplicationException should be raised in all
 cases.
 What would be a convenient idiom we can all use?
 From the Javadocs:
 
 Adds the specified element to this set if it is not already present
 (optional operation). More formally, adds the specified element e to
 this
 set if the set contains no element e2 such that (e==null ? e2==null :
 e.equals(e2)). If this set already contains the element, the call leaves
 the set unchanged and returns false.
 
 If it returns false, it means that the element is already in the set;
 the
 post-condition is the same.   So the idiom is simply to ignore the
 return
 code, it doesn't matter if true of false is returned.
 
 
 Of course, this relies on a correct implementation of equals(); one
 option
 is to use Isis' ObjectContracts helper class.
 
 
 HTH
 Dan
 
 
 
 
 
 Thanks,
 
 Oscar
 
 
 
 
 
 
 [1]
 
 https://github.com/datanucleus/datanucleus-core/blob/master/src/main/java/org/datanucleus/store/types/wrappers/backed/TreeSet.java#L719
 
 
 
 
 
 
 
 
 
 
 
 
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: Unable to finish partial implementation of

[GESCONSULTOR - Óscar Bou]

Hi, Dan.

Many thanks. I'll complete it with the CollectionRemoveFrom... logic.

I've seen now the treat to avoid using the CollectionFacet on:

final Object referencedObject = 
AdapterUtils.unwrap(referencedObjectAdapter);

// get hold of underlying collection
final Object collection = 
getterFacet.getProperty(targetAdapter);

// don't post event if has set semantics and contains object
if(collection instanceof Set) {
Set? set = (Set?) collection;
if(set.contains(referencedObject)) {
return;
}
}


That's clear now!

Also, I've seen you've introduced a WrapperFactory policy that seems to not 
force the Disable or Hidden checks, but stills execute the business logic 
associated. 

So this way we can always configure use 

wrapperFactory(domainObject).setXXX

to ensure that the business logic on the modifyXXX methods is execute, despite 
the property is hidden or disabled.

That's really useful on domain entities code.

Unlike the previous case, on BDD tests (testing the user's behavior) it makes 
more sense to test forcing those hidden and disabled policies.


So, how (or where) should be inject, configure or invoke the WrapperFactory on 
each case?
- Domain Entities.
- BDD tests.

I'm sure there's something I'm missing...

Thanks,

Oscar






El 07/05/2014, a las 09:56, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Hi Oscar,
 I've just pushed branch ISIS-550; this pretty much implements the collection 
 add-to stuff.
 
 The CollectionFacet isn't needed; that's for iterating over collections, not 
 for manipulating them.
 
 Take a look at the ToDoItem class, specifically its getDependencies() method. 
  Note also the add(...) method, and how it can use the wrap(...) even though 
 the colleciton is disabled (via ToDoItem.layout.json).
 
 Cheers
 Dan
 
 
 
 
 
 
 2014-05-06 17:35 GMT+01:00 GESCONSULTOR - Óscar Bou o@gesconsultor.com:
 Many thanks.
 
 Cheers,
 
 Oscar
 
 
 El 06/05/2014, a las 17:05, Dan Haywood d...@haywood-associates.co.uk 
 escribió:
 
 
 Thanks for starting on this Oscar ... I'll look at it this eve.
 
 Cheers
 Dan
 
 
 
 On 6 May 2014 15:49, GESCONSULTOR - Óscar Bou o@gesconsultor.comwrote:
 
 
 Hi, Dan.
 
 I've tried to complete an implementation of @PostsCollectionAddedToEvent,
 but unable to complete it.
 
 I think that there's a need to import CollectionFacet, in order to detect
 if the element had been previously added to the collection, and that forces
 to specify if it's a JavaCollection or an ArrayCollection.
 
 Dan, please, can you complete this one?
 
 I can replicate it aftewards for @PostsCollectionRemovedFromEvent
 
 
 We need it for decoupling one projection that must be generated
 automatically from another context, and that's the best way we've found.
 The alternatives seems to be to implement on each collection the addToXXX,
 removeFromXXX and inside those methods, post the event.
 
 
 
 Many Thanks,
 
 Oscar
 
 
 [1] https://issues.apache.org/jira/browse/ISIS-550
 
 
 
 
 Óscar Bou Bou
 Responsable de Producto
 Auditor Jefe de Certificación ISO 27001 en BSI
 CISA, CRISC, APMG ISO 2, ITIL-F
 
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
 
http://es.linkedin.com/in/oscarbou
 
http://www.GesConsultor.com 
 
 
 
 
 Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
 información reservada que no puede ser difundida. Si usted ha recibido este 
 correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
 remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
 mensaje ni divulgar su contenido a ninguna persona.
 Su dirección de correo electrónico junto a sus datos personales constan en un 
 fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de 
 mantener el contacto con Ud. Si quiere saber de qué información disponemos de 
 Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito 
 al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
 Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), 
 y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
 responsabilidad comprobar que este mensaje o sus archivos adjuntos no 
 contengan virus informáticos, y en caso que los tuvieran eliminarlos.
 
 
 
 
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente

Re: ISIS-550 (event bus) and ISIS-769 (precommit)

[GESCONSULTOR - Óscar Bou]

Thinking more about this, it will be called on each property / collection 
initialized/updated if those actions are called inside a wrap. 

In our case, those projected entities are generated from each value set to a 
property or added to a collection (imagine that the one-to-one, many-to-one or 
many-to-many relationship has in fact an attached Relationship entity where 
the user can further specify additional properties of that relationship; that's 
our case).

So to be informed through events when a Relationship must be 
created/updated/deleted is just enough and we can maintain it through the 
@PostsXXX annotations just introduced.

Thanks,

Oscar





El 11/05/2014, a las 21:28, GESCONSULTOR o@gesconsultor.com escribió:

 For ach property / collection value I mean.
 
 I was planning to use his feature to create a complete projection of one 
 model entities in another domain (with related entities)
 
 Disculpa que sea breve. 
 Enviado desde mi móvil
 
 El 11/05/2014, a las 19:50, Dan Haywood d...@haywood-associates.co.uk 
 escribió:
 
 Hi Oscar,
 
 OK, so ISIS-550 [1] and ISIS-769 [2] are both committed in master.  I've
 marked them as resolved, but please re-open if you encounter any issues.
 
 Cheers
 Dan
 
 [1] https://issues.apache.org/jira/browse/ISIS-550
 [2] https://issues.apache.org/jira/browse/ISIS-769

Unable to finish partial implementation of

[GESCONSULTOR - Óscar Bou]

Hi, Dan.

I've tried to complete an implementation of @PostsCollectionAddedToEvent, but 
unable to complete it.

I think that there's a need to import CollectionFacet, in order to detect if 
the element had been previously added to the collection, and that forces to 
specify if it's a JavaCollection or an ArrayCollection.

Dan, please, can you complete this one?

I can replicate it aftewards for @PostsCollectionRemovedFromEvent


We need it for decoupling one projection that must be generated automatically 
from another context, and that's the best way we've found. 
The alternatives seems to be to implement on each collection the addToXXX, 
removeFromXXX and inside those methods, post the event.



Many Thanks,

Oscar


[1] https://issues.apache.org/jira/browse/ISIS-550

Re: Unable to finish partial implementation of

[GESCONSULTOR - Óscar Bou]

Many thanks.

Cheers,

Oscar


El 06/05/2014, a las 17:05, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Thanks for starting on this Oscar ... I'll look at it this eve.
 
 Cheers
 Dan
 
 
 
 On 6 May 2014 15:49, GESCONSULTOR - Óscar Bou o@gesconsultor.comwrote:
 
 
 Hi, Dan.
 
 I've tried to complete an implementation of @PostsCollectionAddedToEvent,
 but unable to complete it.
 
 I think that there's a need to import CollectionFacet, in order to detect
 if the element had been previously added to the collection, and that forces
 to specify if it's a JavaCollection or an ArrayCollection.
 
 Dan, please, can you complete this one?
 
 I can replicate it aftewards for @PostsCollectionRemovedFromEvent
 
 
 We need it for decoupling one projection that must be generated
 automatically from another context, and that's the best way we've found.
 The alternatives seems to be to implement on each collection the addToXXX,
 removeFromXXX and inside those methods, post the event.
 
 
 
 Many Thanks,
 
 Oscar
 
 
 [1] https://issues.apache.org/jira/browse/ISIS-550
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: IsisCon 2014, 6-7 June, Milan Italy

[GESCONSULTOR - Óscar Bou]

Hi to all.

So seems that most of you are going to be also on Saturday the whole day, and 
leave Sunday, isn't it?

We will arrive Thursday night, so no opportunity to meet until Friday.

Seems that the plan is to meet for two whole days, is that correct?

We need that to close the departure.

Regards,

Oscar




El 22/04/2014, a las 11:36, Jeroen van der Wal jer...@stromboli.it escribió:

 There are two good hotel options:
 
 1. Ibis Milano Centro, ~ 85 euro per night
 2. NH Milano Touring, ~ 125 euro per night
 
 I tried to negotiate a group discount a various hotels but they won't beat
 the prices of these two.
 
 I will be Milan an Thursday too so we could meet up for dinner that night.
 
 Kind regards,
 
 Jeroen
 
 [1] http://www.booking.com/hotel/it/ibismilanocentromilano.nl.html
 [2] http://www.booking.com/hotel/it/jollyhoteltouringmilano.en-gb.html
 
 
 
 On Tue, Apr 22, 2014 at 2:25 AM, Kevin Meyer - KMZ ke...@kmz.co.za wrote:
 
 Does anyone have any recommendations where to stay, or made any
 reservations yet? Otherwise, I'll choose something close to the venue
 semi-randomly via Booking.com...
 
 I'll most likely be arriving on Thursday night by shuttle from Ljubljana -
 probably dropped off either at the railway station or the hotel and
 returning on Sunday.
 
 Regards,
 Kevin
 
 On 27 Mar 2014 at 11:42, Dan Haywood wrote:
 
 Just a further reminder that we would love to have a couple of members of
 the user community along to meet with us in Milan in June.  We expect
 there
 to be 4 or 5 committers at the meet; all other things being equal, we'll
 just have a great time discussing Isis and generally hanging out with
 each
 other.
 
 But if you can make it to Italy for either one or both of the days, we'd
 love to meet you.
 
 Cheers
 Dan
 
 
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

Re: IsisCon 2014, 6-7 June, Milan Italy

[GESCONSULTOR - Óscar Bou]

Hi to all.

Finally we've found a booking that allows us to arrive Thursday afternoon (so 
we can meet on the evening) and depart Saturday at 15:30 h aprox.

Nice to meet you all there !!! :-))




El 23/04/2014, a las 19:35, Kevin Meyer - KMZ ke...@kmz.co.za escribió:

 Hi all,
 
 Yes, I am preparing for two whole days for the event.
 
 I've made a provisional booking at the Ibis Milano Centro, arriving 
 (possibly late) on Thursday, leaving sometime during Sunday day (I 
 don't know precise times yet, as the shuttle service I'm using doesn't 
 provide them until the day before departure).
 
 The extra meta-data is that my wife'll be with me, but she's happy to 
 leave me alone for the conference event - though she'll may join us on 
 Friday evening. She's happy to wander around Milan during the days ;)
 
 Regards,
 Kevin
 
 On 23 Apr 2014 at 16:10, GESCONSULTOR - Óscar Bou wrote:
 
 
 Hi to all. 
 
 So seems that most of you are going to be also on Saturday the whole day, 
 and leave Sunday, isn't 
 it?
 
 We will arrive Thursday night, so no opportunity to meet until Friday.
 
 Seems that the plan is to meet for two whole days, is that correct?
 
 We need that to close the departure.
 
 Regards,
 
 Oscar
 
 
 
 
 El 22/04/2014, a las 11:36, Jeroen van der Wal jer...@stromboli.it 
 escribió:
 
There are two good hotel options:
 
1. Ibis Milano Centro, ~ 85 euro per night
2. NH Milano Touring, ~ 125 euro per night
 
I tried to negotiate a group discount a various hotels but they won't beat
the prices of these two.
 
I will be Milan an Thursday too so we could meet up for dinner that night.
 
Kind regards,
 
Jeroen
 
[1] http://www.booking.com/hotel/it/ibismilanocentromilano.nl.html
[2] http://www.booking.com/hotel/it/jollyhoteltouringmilano.en-gb.html
 
 
 
On Tue, Apr 22, 2014 at 2:25 AM, Kevin Meyer - KMZ ke...@kmz.co.za 
 wrote:
 
Does anyone have any recommendations where to stay, or made any
reservations yet? Otherwise, I'll choose something close to the venue
semi-randomly via Booking.com...
 
I'll most likely be arriving on Thursday night by shuttle from Ljubljana -
probably dropped off either at the railway station or the hotel and
returning on Sunday.
 
Regards,
Kevin
 
 
 
 


Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou

   http://es.linkedin.com/in/oscarbou

   http://www.GesConsultor.com 




Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un 
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener 
el contacto con Ud. Si quiere saber de qué información disponemos de Ud., 
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al 
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: 
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y 
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su 
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan 
virus informáticos, y en caso que los tuvieran eliminarlos.

IsisCon 2014 - Travel logistics

[GESCONSULTOR - Óscar Bou]

Hi to all.

We are booking our flight, and basically there are 2 options for the departure: 
Saturday afternoon and Sunday afternoon.

Our arrival is planned for Thursday night.

What are the travel plans of others?

Regards,

Oscar

BDD Testing - Scenario outlines speed should be improved

[GESCONSULTOR - Óscar Bou]

We have implemented some BDD tests as Scenario Outlines [1].

But just for one execution, is spending aprox. 15 min in completing a Scenario 
Outline with aprox. 20 scenarios.

The problem is that they become really slow, as the whole Isis system is 
recreated for each example.

Following best practices, Scenarios should be independent, but I think there 
should be ways to guarantee it without sacrificing speed.
- Isis System does not need to be recreated (introspected) for each Scenario, 
as the source code has not changed.
- Database can be recreated, or perhaps there's an abstraction on DataNucleus 
or JDBC to empty a DataStore without re-creating the table structure from the 
JDO annotations.

Perhaps are other alternatives to improve their speed that does not require 
refactoring the Isis BDD integrations tests implementation?

Regards,

Oscar

[1] 
http://jnye.co/Posts/11/repeating-bdd-tests-using-scenario-outlines-and-an-examples-table-with-specflow

Re: Comments on GSOC2014 ReputationBox proposal

[GESCONSULTOR - Óscar Bou]

Hi all.David, we are REALLY pleased with the BDD support. To offer some stats, we currently have more than 4000 BDD steps in nearly 100 scenarios (and growing on a fast rate) fully managed with Isis, and it works REALLY well :-))Every new aspect on the domain is implemented 80% of time through the Isis BDD support, an 20% through "normal" Isis Integration tests.Really helpful.HTH,OscarEl 09/04/2014, a las 07:23, Dileepa Jayakody dileepajayak...@gmail.com escribió:Thanks guys.I'm new to BDD scenarios, so I will go through the Isis documentation pointed out by Oscar to get an idea about it.Regards,Dileepa
On Wed, Apr 9, 2014 at 8:35 AM, David Tildesley davo...@yahoo.co.nz wrote:
Hi Oscar,Thanks - I want to have a go at using the BDD integration - good to know that someone is using it and is pleased with it. 
If we were all in a room doing consensus based domain modelling together we probably wouldn't need to do sequence diagrams - we would already be familiar with the behaviour on the model and we would have the significant behaviour on the model itself in terms of methods including signatures - in which case it's easy to visualise the call sequence. All so if using the Coad's DNC model archetype shape then there is an inherent call flow direction.
Regards,David.  
   On Wednesday, 9 April 2014 5:13 AM, GESCONSULTOR - Óscar Bou o@gesconsultor.com wrote:
Hi, David.Nice addition.A complementary approach (or currently the alternative to us) to sequence diagrams would be to define different features and scenarios on BDD [1].
From those BDD scenarios Dileepa can directly implement them thanks to the excellent Isis BDD support (it has greatly changed our dev process; we have a programmer here that says he currently talks Spanish, Catalan and a bit of English and Gherkin), or perhaps do a fine-grained analysis through sequence diagrams.
HTH,Oscar[1]http://isis.apache.org/core/specsupport-and-integtestsupport.html
El 08/04/2014, a las 02:58, David Tildesley davo...@yahoo.co.nz escribió:
I should add that I didn't show parameters and return types on the methods. The best thing to do next is to validate your domain model by sequence diagram for a key scenario (but following Demeters Law - "Only talk to your immediatefriends" so that the model remains
 loosely coupled).Regards,David.On Tuesday, 8 April 2014 8:55 AM, David Tildesley davo...@yahoo.co.nz wrote:
Hi Dileepa,ContactedParty is useful when you have more than one user inbox for the same user and you want to consolidate Contacts across multiple inboxes. If there is always just one inbox (one account) or you don't need or want Contactconsolidation, then you don't need it and you shift the attributes down to the "...Inbox".
Yes, CriteriaReputation is the most granular from what I picking up from your explanations and diagram - the other reputations are computed from multiple CriteriaReputation
 using some algorithm (maybe just a weighted average -whatever you decide).Regards,David.
Óscar Bou BouResponsable de ProductoAuditor Jefe de Certificación ISO 27001 en BSICISA, CRISC, APMG ISO 2, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com


Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de
 correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. ,Paseode laCastellana, 153 bajo - 28046 (Madrid), yAvda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.






  

Óscar Bou BouResponsable de ProductoAuditor Jefe de Certificación ISO 27001 en BSICISA, CRISC, APMG ISO 2,ITIL-F902 900 231 / 620 267 520http://www.twitter.com/oscarbouhttp://es.linkedin.com/in/oscarbouhttp://www.GesConsultor.comEste mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad d

Re: Comments on GSOC2014 ReputationBox proposal

[GESCONSULTOR - Óscar Bou]

Hi, David.Nice addition.A complementary approach (or currently the alternative to us) to sequence diagrams would be to define different features and scenarios on BDD [1].From those BDD scenarios Dileepa can directly implement them thanks to the excellent Isis BDD support (it has greatly changed our dev process; we have a programmer here that says he currently talks Spanish, Catalan and a bit of English and Gherkin), or perhaps do a fine-grained analysis through sequence diagrams.HTH,Oscar[1]http://isis.apache.org/core/specsupport-and-integtestsupport.htmlEl 08/04/2014, a las 02:58, David Tildesley davo...@yahoo.co.nz escribió:I should add that I didn't show parameters and return types on the methods. The best thing to do next is to validate your domain model by sequence diagram for a key scenario (but following Demeters Law - "Only talk to your immediatefriends" so that the model remains loosely coupled).Regards,David.On Tuesday, 8 April 2014 8:55 AM, David Tildesley davo...@yahoo.co.nz wrote:Hi Dileepa,ContactedParty is useful when you have more than one user inbox for the same user and you want to consolidate Contacts across multiple inboxes. If there is always just one inbox (one account) or you don't need or want Contactconsolidation, then you don't need it and you shift the attributes down to the "...Inbox".Yes, CriteriaReputation is the most granular from what I picking up from your explanations and diagram - the other reputations are computed from multiple CriteriaReputation using some algorithm (maybe just a weighted average -whatever you decide).Regards,David.Óscar Bou BouResponsable de ProductoAuditor Jefe de Certificación ISO 27001 en BSICISA, CRISC, APMG ISO 2, ITIL-F902 900 231 / 620 267 520http://www.twitter.com/oscarbouhttp://es.linkedin.com/in/oscarbouhttp://www.GesConsultor.comEste mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. ,Paseode laCastellana, 153 bajo - 28046 (Madrid), yAvda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.

Re: Collections as Action Params - alternative implementation

[GESCONSULTOR - Óscar Bou]

Sure!There's a small extension to it, for admitting multiple params on the action signature, that was also needed by us.If, instead of having:public class TodoItem { ... private TodoItem parentTodoItem;  @Bulk public void addRelatedTodo(@Named("To-Do Item") @BulkParam TodoItemtodoItem) {    } ...}I have:public class TodoItem { ... private TodoItem parentTodoItem;  @Bulk public void addRelatedTodo(@Named("To-Do Item") @BulkParam TodoItemtodoItem, @Named("Comments") String comments) {    } ...}The viewer would pass the same description on every action call.So, only one param can be annotated with @BulkParam, but the viewer will ask for the other params (the usual way) and pass the same values on each action call.I'll raise a ticket.Thanks,OscarEl 05/04/2014, a las 11:19, Dan Haywood d...@haywood-associates.co.uk escribió:Hi Oscar,I really like this idea, in particular (a) the benefit that it only impactsthe viewer and (b) the symmetry with our existing @Bulk annotation.Why don't you raise a ticket for this, capturing the above sketch?CheersDanOn 4 April 2014 10:54, GESCONSULTOR - Óscar Bou o@gesconsultor.comwrote:Hi to all.We are evaluating to support on our custom viewer an alternativeimplementation to admitting Collections as params.I want to detail it here to listen to your suggestions and drawbacksdetected.Imagine I want to create a hierarchy of To-Do Items, when one To-Do Itemcan only have 1 parent.Imagine also that I have the following action:public class TodoItem { ... private TodoItem parentTodoItem;  @Bulk public void addChildTodo(@Named("To-Do Item") TodoItem todoItem) {    } ...}If I mark that action as a @Bulk action, I can select on the wicket viewermultiple TodoItems and add to all them one given To-Do Item as its child.Clearly that's not valid, as each To-Do Item can only have one parent. Soit's not possible for all the selected To-Dos to be the parent of the onepassed as a parameter.So I would like to implement something like this:public class TodoItem { ... private TodoItem parentTodoItem;  public void addChildTodo(@Named("To-Do Items") CollectionTodoItemtodoItems) {    } ...}Where the user inputs a selection of To-Do Items to include all them aschild items for the selected one. As we saw before, this action cannot be@Bulk as multiple parents are not allowed.But currently Isis does not support Collections as parameters.We can go that way in our custom viewer, but perjaps there's analternative approach that, with some limitations, allow us to not breakIsis on Integration Tests, the viewer, etc. (we could also being able tomark this method as @Programmatic, but we want the params to be validatedfor not nulls, etc. by calling them inside athis.wrap(domainObject).addChildTodo(...);The point is that if we introduce a new annotation, @BulkParam, and use itthis way:public class TodoItem { ... private TodoItem parentTodoItem;  public void addChildTodo(@Named("To-Do Item") @BulkParam TodoItemtodoItem) {    } ...}The viewer can allow us to choose a Collection of To-Do Items and toexecute for each one, the given action passing it as the parameter.For that, it must admit a User Interface that allows, for example, tocheck a given ToDoItem on a grid, if no auto-complete method is defined forthat entity, or if the entity has an autocomplete, to filter or check on agrid on a left panel and see the selected items on a right panel.The User Interface is really similar to the one needed for implementingCollections as parameters, so it can be a first step that only affects theviewer.In this context marking it as a @Bulk action does not have any meaning, assaid before, but there are multiple use cases (such as m-n relationships)where it could also be marked with @Bulk without breaking anything.And it introduce also one implementation advantage over only admittingCollections.Imagine for example this other use case:public class TodoItem { ... private TodoItem parentTodoItem;  @Bulk public void addRelatedTodo(@Named("To-Do Item") @BulkParam TodoItemtodoItem) {    } ...}Where on To-Do item can be related with any other given (zero or more).On the previous case, only one method implementation would be needed tosupport both the case of only one To-Do Item selected, or a Collection ofTo-Do Items selected.But if the @BulkParam annotation would not be supported, we might decideto "refactor" the current action:public class TodoItem { ... private TodoItem parentTodoItem;  @Bulk public void addRelatedTodo(@Named("To-Do Item") TodoItem todoItem) {    } ...}topublic class TodoItem { ... private TodoItem parentTodoItem;  @Bulk public void addRelatedTodo(@Named("To-Do Items") CollectionTodoItemtodoItems) {    } ...}And introduce a for-loop on all implementations.Or, as an alternative, to implement both actions like this:public class TodoItem { ... private T

Re: Comments on GSOC2014 ReputationBox proposal

[GESCONSULTOR - Óscar Bou]

Hi Dileepa.Not sure about this, but seems a little "strange" the "cycle" on your model between the Context, Criteria and Reputation entities.Perhaps the Context is a more generic entity than Criteria, and it's the Criteria what should have a relationship with a Context, and also with Reputation?Something like this:http://yuml.me/3aa65a6fHTH,OscarEl 04/04/2014, a las 17:56, Dileepa Jayakody dileepajayak...@gmail.com escribió:Hi Oscar and all,On Thu, Apr 3, 2014 at 1:52 PM, GESCONSULTOR - Óscar Bouo@gesconsultor.comwrote:Hi Deleepa,Seeing at your last diagram, shouldn't the Criteria be related with (is specific to) a Context? If so, a relationship would also be needed.Yes, I agree. The criteria to calculate reputation depends on the context. Therefore there should be a relationship[Context]1-1..*[Criteria].I have modified the diagram like this :http://yuml.me/26953ad7Perhaps the Computation Algorithm could also be specific for one or more Contexts. In that case, a relationship is also needed.I think, now that Context has a relationship with Criteria, the relationship between the ComputationAlgo and Context could be derived through the Criteria entity. Also, perhaps the relationship between Reputation and Criteria is redundant, as it can be obtained through the ReputationValue. It could be modeled as a derived relationship in Isis.Yes, Thanks for pointing out. Removed this relationship between Reputation and CriteriaHTH,OscarEl 03/04/2014, a las 09:59, Dileepa Jayakody dileepajayak...@gmail.com escribió:Hi Dan and all,I modified the diagram and the latest is :http://yuml.me/75c87f26On Thu, Apr 3, 2014 at 12:50 PM, Dileepa Jayakody dileepajayak...@gmail.comwrote:Thanks Dan,I will modify the diagram with proper notations and reply withexplanations..On Thu, Apr 3, 2014 at 12:31 PM, Dan Haywood d...@haywood-associates.co.ukwrote:On 2 April 2014 08:09, Dileepa Jayakody dileepajayak...@gmail.comwrote:Hi All,After doing some background reading on Reputation object modeling [1],(good to hear)Ihave extended my class diagram to describe the reputation analysismodel inmy application :http://yuml.me/c97453ecThere are some discrepancies between this diagram and the descriptionbelow...An entityNot sure if having an entity called "entity" is a particularly good idea;could get confusing...has a reputationThe diagram shows the "entity" entity as having many reputations.An entity can have different reputations in different contexts. As anexample entity might have a good reputation for email context but badreputation for marketing context.Hence, [Reputation]1-1[Context] and [Entity]1-0..*[Reputation]which describes it's value. EmailContact, Emailare the 2 entity objects in my application.The diagram shows EmailContact and Email as having (an association with)an"entity", rather than being (implementing) entity. But I think the latteris probably what you want; Entity is an interface and EmailContact andEmail implement them.Yep, I wanted to show the inheritance relationship. Sorry for the mistakewith notation. I have modified this in the latest diagram.Reputation is an interface implemented by ReputationObject class.The diagram doesn't show this, it shows an association.Inyuml.me, think that is shown using RepuationObject -^ ReputationAlso, ReputationObject isn't a particular great name. Why have Reputationas an interface at all; as I understand it there's likely only one impl.I agree. I removed ReputationObject and added Reputation as an entity inthe diagram.Reputation has a particular context/domain in which it isearned(eCommerce,films, technical forums etc ),Reputation *-1 Contextin this case the context is emailcommunication. The reputation's value is represented by theReputationValueobject which is calculated based on a certain criteria (In my case thecriteria are People associated with the email, topic and actions in theemail). Criteria defines the required parameters and theComputationAlgorithm to be used to calculate reputation value.The reputation value is calculated by the particularComputationAlgorithmusing the parameters given by the criteria. This is where theimplementation specific stuff comes in for calculation. Mahoutrecommendation algorithms, Drools rules are implementations of suchComputationAlgorithms.From an implementation standpoint, my first pass would be to implementComputationAlgorithm as an enum. That way it can be polymorphicallydispatched to.Overall, I like the way that the domain is getting richer. But I do stillworry pragmatically about where these entities are all to be persisted,andhow to they are sync'ed. Perhaps you could extend the diagram and usestereotypes to indicate for each entity whether its native persistence isin Isis, or Mahout, or gmail, or somewhere else.Yes, I will design the persistence model and we can discuss over that.Could also indicate if types are entities or value types.HTHDan[1] Adrian Paschke, Rehab Alnemr, Christoph Meinel, The Rule ResponderDistributed Reputation 

Re: Comments on GSOC2014 ReputationBox proposal

[GESCONSULTOR - Óscar Bou]

Hi Deleepa,Seeing at your last diagram, shouldn't the Criteria be related with (is specific to) a Context? If so, a relationship would also be needed.Perhaps the Computation Algorithm could also be specific for one or more Contexts. In that case, a relationship is also needed.Also, perhaps the relationship between Reputation and Criteria is redundant, as it can be obtained through the ReputationValue. It could be modeled as a derived relationship in Isis.HTH,OscarEl 03/04/2014, a las 09:59, Dileepa Jayakody dileepajayak...@gmail.com escribió:Hi Dan and all,I modified the diagram and the latest is :http://yuml.me/75c87f26On Thu, Apr 3, 2014 at 12:50 PM, Dileepa Jayakody dileepajayak...@gmail.comwrote:Thanks Dan,I will modify the diagram with proper notations and reply withexplanations..On Thu, Apr 3, 2014 at 12:31 PM, Dan Haywood d...@haywood-associates.co.ukwrote:On 2 April 2014 08:09, Dileepa Jayakody dileepajayak...@gmail.comwrote:Hi All,After doing some background reading on Reputation object modeling [1],(good to hear)Ihave extended my class diagram to describe the reputation analysismodel inmy application : http://yuml.me/c97453ecThere are some discrepancies between this diagram and the descriptionbelow...An entityNot sure if having an entity called "entity" is a particularly good idea;could get confusing...has a reputationThe diagram shows the "entity" entity as having many reputations.An entity can have different reputations in different contexts. As anexample entity might have a good reputation for email context but badreputation for marketing context.Hence, [Reputation]1-1[Context] and [Entity]1-0..*[Reputation]which describes it's value. EmailContact, Emailare the 2 entity objects in my application.The diagram shows EmailContact and Email as having (an association with)an"entity", rather than being (implementing) entity. But I think the latteris probably what you want; Entity is an interface and EmailContact andEmail implement them.Yep, I wanted to show the inheritance relationship. Sorry for the mistakewith notation. I have modified this in the latest diagram.Reputation is an interface implemented by ReputationObject class.The diagram doesn't show this, it shows an association.Inyuml.me, think that is shown using RepuationObject -^ ReputationAlso, ReputationObject isn't a particular great name. Why have Reputationas an interface at all; as I understand it there's likely only one impl.I agree. I removed ReputationObject and added Reputation as an entity inthe diagram.Reputation has a particular context/domain in which it isearned(eCommerce,films, technical forums etc ),Reputation *-1 Contextin this case the context is emailcommunication. The reputation's value is represented by theReputationValueobject which is calculated based on a certain criteria (In my case thecriteria are People associated with the email, topic and actions in theemail). Criteria defines the required parameters and theComputationAlgorithm to be used to calculate reputation value.The reputation value is calculated by the particularComputationAlgorithmusing the parameters given by the criteria. This is where theimplementation specific stuff comes in for calculation. Mahoutrecommendation algorithms, Drools rules are implementations of suchComputationAlgorithms.From an implementation standpoint, my first pass would be to implementComputationAlgorithm as an enum. That way it can be polymorphicallydispatched to.Overall, I like the way that the domain is getting richer. But I do stillworry pragmatically about where these entities are all to be persisted,andhow to they are sync'ed. Perhaps you could extend the diagram and usestereotypes to indicate for each entity whether its native persistence isin Isis, or Mahout, or gmail, or somewhere else.Yes, I will design the persistence model and we can discuss over that.Could also indicate if types are entities or value types.HTHDan[1] Adrian Paschke, Rehab Alnemr, Christoph Meinel, The Rule ResponderDistributed Reputation Management System for the Semantic WebThanks,DileepaÓscar Bou BouResponsable de ProductoAuditor Jefe de Certificación ISO 27001 en BSICISA, CRISC, APMG ISO 2, ITIL-F902 900 231 / 620 267 520http://www.twitter.com/oscarbouhttp://es.linkedin.com/in/oscarbouhttp://www.GesConsultor.comEste mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia 

Re: Comments on GSOC2014 ReputationBox proposal

[GESCONSULTOR - Óscar Bou]

Mmmm... seems not properly pasted it.

Try this one:

http://yuml.me/7801f5db

Or, if also considering the EmailContact relationship with UserInbox a derived 
one (the same EmailContact could have Emails on different UserInbox'es):

http://yuml.me/2359d93b


Just to question the model :-)

Regards,

Oscar


El 25/03/2014, a las 22:00, GESCONSULTOR - Óscar Bou o@gesconsultor.com 
escribió:

 Hi, Dileepa.
 
 Just some questions for helping in validating the model.
 
 Why not a variation like this?
 http://yuml.me/edit/825d7db5
 
 Still not clear to me why the Reputation entity has a relationship with 
 EmailContact also, and not only to an Email. 
 The EmailContact relationship could always be derived from the Emails sender 
 (EmailContact) so, unless you're explicitly modeling that derived 
 relationship, it shouldn't appear.
 
 HTH,
 
 Oscar
 
 
 
 
 El 25/03/2014, a las 21:20, Dileepa Jayakody dileepajayak...@gmail.com 
 escribió:
 
 Hi Dan and all,
 
 Here is the basic class diagram for the domain entitiies in RB :
 http://yuml.me/825d7db5
 
 Please note that I have used the name EmailContact instead of
 EmailSenderProfile for clarity purpose. Effectively this entity represents
 the email contacts in the user's inbox.
 
 Each email and email contact will have a corresponding Reputation entity.
 And in the view  models, EmailReputationViewModel will display emails with
 their reputation data and ContactReputationViewModel will display email
 contacts with their reputation data in the RB web application.
 
 Your ideas and suggestions are most welcome.
 
 Thanks,
 Dileepa
 
 
 On Tue, Mar 25, 2014 at 3:42 PM, Dileepa Jayakody dileepajayak...@gmail.com
 wrote:
 
 Hi Dan,
 
 Thanks a lot for your insight. Please see my comments inline below.
 
 
 On Tue, Mar 25, 2014 at 1:21 PM, Dan Haywood d...@haywood-associates.co.uk
 wrote:
 
 Hi Dileepa,
 
 I've just posted the comments below on your GSOC proposal.  I know that
 you can't make further changes to the proposal, so I'm posting them here on
 the dev list, so we can keep the conversation going.
 
 So..
 
 * good to see you intend to set up a project on github for this; please
 do this asap.  That way you can start to capture docs/working notes.  I
 also suggest that you set up github pages for your site [1].
 
 
 * What I'd like to see right now is some sort of UML diagram; you could
 sketch one using yuml.me [2] and add it to your github site.  I can't
 quite work out how the persistent domain entities relate to each other.  In
 particular, are EmailSenderProfile and Reputation in 1-1 correspondence?
 
 
 I will draw a ER diagram for the domain entities and we can enhance it
 over discussions.
 Yes I pictured EmailSenderProfile as the representation of an email sender
 (a contact) and each email sender will have a corresponding reputation
 score (accumulated and normalized reputation-score over the emails sent by
 him) represented by the Reputation domain entity.
 
 
 
 * In your timeline I noticed you said Commit all code to github, only
 on Aug 11.  It's much better practice (and will help mentors guide you) if
 you commit changes as you go.  That way it's also safely backed up, and you
 can go back in time if you mess up.
 
 
 Yes I agree, in fact I didn't mean I'm going to commit all code at once
 only on Aug 11. I meant to say I'm planning to finish development  and
 commit everything by Aug 11.
 I strongly agree on getting feedback along the way of development, after
 all I'm looking at using agile development for my project :). Sorry for
 having interpreted my idea in a misleading way on the proposal.
 
 
 * You might also want to version control the academic paper, too, if your
 university lets you.
 
 
 Some further points relating to the design:
 
 * You have Email as a persistent entity.  I'm a bit worried what that
 might mean about storage and also synchronization.  Is it necessary to have
 the Email persisted in Isis?  If not persisted, then should the Email
 entity be a view model, or as a fake persistent entity utilizing a new
 StoreManager impl in JDO.  See the recent thread [3] on this topic.
 
 Email entity will have several attributes such as : id, sender-id,
 reputation-score. sender-id will be mapped to the EmailSenderProfile and
 reputation-score will be a score given by the ML process evaluating the
 reputation of the email. Could email-entity be a view model in this
 scenario? If so what is the advantage of defining it as a view-model?
 
 I think we can discuss more on this with a ER diagram for the application.
 I will come up with a ER diagram asap.
 
 
 * Conversely, does Mahout require some sort of persistent dataset of
 emails in order to do the reputation scoring?  Or does it just hold
 aggregated information?  If the former, I worry that we now have each email
 stored in potentially 3 places: gmail, Isis and Mahout.  Keeping these in
 sync would be a nightmare.
 
 
 AFAIK Mahout process requires a persistent dataset (file

Re: [jira] [Commented] (ISIS-743) Remove the concept of transient objects and of @NotPersistable; instead we have view models.

[GESCONSULTOR - Óscar Bou]

Just one question.Currently, the interface seems to be mandatory only for generating the OID.That "forces" the framework to not being able to use "plain" POJOs as view models, as all them must implement that interface.If, when the interface is not implemented by the entity, the OID would be generated as "some useful" combination of the class and a hash, any "non-JDO managed" class could be returned from an action and being properly managed by the viewers, etc.Could it be possible?I'm sure I'm missing other requirements, but prefer to launch the question, as not allowing any class to be returned by an action (obviously, non-editable) has always disturbed me, and seems related.Thanks,OscarEl 20/03/2014, a las 16:59, Dan Haywood d...@haywood-associates.co.uk escribió:David said:Some more thoughts/assumptions on transient domain objects:1. oid - annotate an attribute or use attribute naming pattern2. Restful remoting mean client maintains required state - client doesn'tcare whether domain object is transient or not.3. Restful remoting means the server trashes the domain object instanceafter the response. However domain behaviour is not transferred andeverytime a behaviour is invoked on a domain object graph, the domain graphhas to re-instantiated at the server - big performance hit unlessdeveloper uses a cache (ehcache or similar).Am I wide of the mark with any of the above?Jeroen said:I do agree with David that there are plenty of use cases to think of wherehaving a transient domain object on the server can be useful. I amwondering how comparable architectures deal with transient objects, perhapsan analogy with a Stateful Session Bean can be made? [1]. This would make agood topic of conversation on the IsisCon conference too.[1]http://www.jguru.com/faq/view.jsp?EID=917And on 19 March 2014 21:29, David Tildesley davo...@yahoo.co.nz alsosaid:Maybe "transient" is misleading in my side of the discussion. Essentiallya viewer should be able to instantiate an ISIS domain object that has noconnection to DataNucleus, repository as such but can still have a domainservice implementation fetch and put data from an external source (via,web-service, jms, whatever) and inject into the domain object. That keepsmy domain layer intact and doesn't result in bleeding any domain behaviourout to other layers (e.g. view objects which are logically in the UI layer).However as Dan points out, this doesn't sit well with RESTful style. In atraditional app, UI layer (usually using a MVC model) will make severalinvocations on domain object graph behaviour (fine grained method levelcalls) with state being maintained in the session for as long as neededover a series of client requests. This is not the case with RESTful style.Client is responsible for maintaining state with the server having noobligations in this regard. This does not sit well with a fine-grainedmethod invocation on the domain layer - you would normally go for those bigcoarse grained calls and end up re-implementing a domain layer in theclient that replicates domain behaviour. This is where the RESTful modelfalls into a heap (in my opinion) as the tradeoff is very significant. Toretain the "finegrained" domain layer invocation on the server side in theRESTful style would necessitate rebuilding the relevant domain object graphwith every calland trashing it afterwards. This rebuilding "hit" could be mitigated bycareful use of caching on the domain service layer, however the lifecycleof the domain object graph has to be completed on every RESTful invocation.There's quite a few subtle points here to discuss.One thing to say first off, perhaps "view model" also is not the right termfor what we have in Isis; it suggests that the object is only forpresentation purposes, but in fact it could be used as an entity that ismanaged externally too. In fact, over in Ireland on the "sister" .NETproject, we are doing something very similar to this with the equivalentfunctionality provided by NO MVC.Anyway... I understand the objection loud and clear about not having to beforced to use DataNucleus to obtain entities. And I also hear what you aresaying about REST and it moving all the state management client-side intothe viewer. Obviously this isn't the intention; we want the domain logicto be expressed only in one place, namely in Isis. This is non-negotiable,we're not trying to build something like EmberJS.To answer the REST point briefly: the standard pattern is to have some sortof (server-side) resource that represents the conversation/transaction.This is analogous to Jeroen's point about stateful session beans. I'llcome back to this in a moment.Let me get back to the main point about using Isis for domain objects whosepersistence is managed by some other mechanism. I think that our (perhapsmisnamed) ViewModel mechanism will actually work quite well here; theviewModelMemento() method / viewModelInit(String) methods provide a simplemechanism by which the view model provide/gets a handle 

Re: [jira] [Updated] (ISIS-736) For GSOC, - build a real-life app in some suitable domain, along with a semi-academic write-up of their learnings

[GESCONSULTOR - Óscar Bou]

Hi, Dileepa.Another option if your business rules can change on each implementation, is to "externalize" them to a Rules engine, such as Drools (see [1] and [2]).The rules can be written on a "file" an loaded at run-time [3] and they can also be changed at runtime.And you can also define a DSL for your rules "talking your own language" [4].There's currently one proposed GSOC task to integrate it with Isis [5].Perhaps the expressiveness of your rules can be higher (any Java code) and without being restricted to the query language of Mahout (no experience with it).You could send the stream at real-time to the Drools engine integrated with Isis and afterwards save in a database.After being processed with the rules engine they can be saved to the Hadoop cluster through DataNucleus JDO [6] (I've never tried it) or simply to a PostgreSQL or MySQL database (not requiring the use of BigData).We could support you if needed with Drools.HTH,Oscar[1]https://www.jboss.org/drools/[2]https://www.jboss.org/drools/drools-expert.html[3]http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/index.html#d0e5108[4]http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/index.html#d0e9394[5]https://issues.apache.org/jira/browse/ISIS-738[6]http://www.datanucleus.org/products/accessplatform/datastores/hbase.htmlEl 14/03/2014, a las 20:26, Dileepa Jayakody (JIRA) j...@apache.org escribió:  [ https://issues.apache.org/jira/browse/ISIS-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]Dileepa Jayakody updated ISIS-736:-- Attachment: EmailReputationSystem_v2.pngContinuing the discussion on the mailing thread.Please refer the high-level system architecture for my application: ReputationBox. I have attached the image.The implementation of the system will be mainly 2 parts.1. Implementing the ReputationBox server (which imports emails from the mailbox, performs reputation analysis and stores reputation-data. Machine Learning will be used here for analysis and reputation prediction for incoming emails.Probably need to integrate Apache Mahout, Solr for this)2. Implementing the ReputationBox client (which displays the reputation information attached to each email and sender. The initial client will probably be a web-app displaying reputation info)Would love to receive feedback and suggestions on how to use Isis to implement my application.Thanks,DileepaFor GSOC, - build a "real-life" app in some suitable domain, along with a semi-academic write-up of their learnings---   Key: ISIS-736   URL: https://issues.apache.org/jira/browse/ISIS-736 Project: IsisIssue Type: Wish Reporter: Dan Haywood  Labels: gsoc, gsoc2014   Attachments: EmailReputationSystem_v2.png- to would give us another substantial example app, along with some marketing material about how learnable Isis--This message was sent by Atlassian JIRA(v6.2#6252)Óscar Bou BouResponsable de ProductoAuditor Jefe de Certificación ISO 27001 en BSICISA, CRISC, APMG ISO 2, ITIL-F902 900 231 / 620 267 520http://www.twitter.com/oscarbouhttp://es.linkedin.com/in/oscarbouhttp://www.GesConsultor.comEste mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. ,Paseode laCastellana, 153 bajo - 28046 (Madrid), yAvda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.

Re: BDD tests speed improvement with DN options

[GESCONSULTOR - Óscar Bou]

Yes, I'll do.El 12/03/2014, a las 10:51, Dan Haywood d...@haywood-associates.co.uk escribió:On 12 March 2014 09:47, GESCONSULTOR - Óscar Bouo@gesconsultor.comwrote:Hi Dan.I have the following alternatives:- Create a new descendant of IsisConfigurationDefault for tests (IsisConfigurationDefaultForTests) with those properties added by default.this one, I think.Let's call it IsisConfigurationForTests (skip the "Default" suffix, can only be one default).Will you raise the ticket/implement?CheersDan- Directly modifyIsisConfigurationDefault to add them by default.As it's a private method defined on each SystemInitializer I don't see any other "generic" way...El 10/03/2014, a las 11:11, Dan Haywood d...@haywood-associates.co.uk escribió:Hi Oscar,Thanks for this, makes sense.Could you raise a ticket and make the commit... it looks simple enough.And, perhaps, add a short page to our website (somewhere under core/bdd, Iguess).CheersDanOn Monday, 10 March 2014, GESCONSULTOR - Óscar Bou o@gesconsultor.comwrote:Hi to all,Just to let others now.Our BDD test suites are becoming quite large and we were experiencing longexecution times when running them.They can be greatly improved simply by configuring DataNucleus to notvalidate tables and indexes. As all the schema is recreated on eachfeature, seems not necessary.For that, simply add on the SystemInitializer the following lines:private IsisConfiguration testConfiguration() { final IsisConfigurationDefault testConfiguration = newIsisConfigurationDefault(); // Don't do validations that consume setup time.testConfiguration.add("isis.persistor.datanucleus.impl.datanucleus.autoCreateSchema","true");testConfiguration.add("isis.persistor.datanucleus.impl.datanucleus.validateTables","false");testConfiguration.add("isis.persistor.datanucleus.impl.datanucleus.validateConstraints","false");HTH,OscarÓscar Bou BouResponsable de ProductoAuditor Jefe de Certificación ISO 27001 en BSICISA, CRISC, APMG ISO 2, ITIL-Fcontactenos.html.gif902 900 231 / 620 267 520Pasted Graphic 1.tiffhttp://www.twitter.com/oscarbougesdatos-software.gifhttp://es.linkedin.com/in/oscarboublog.pnghttp://www.GesConsultor.comgesconsultor_logo_blue_email.pngEste mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. ,Paseode laCastellana, 153 bajo - 28046 (Madrid), yAvda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Óscar Bou BouResponsable de ProductoAuditor Jefe de Certificación ISO 27001 en BSICISA, CRISC, APMG ISO 2,ITIL-F902 900 231 / 620 267 520http://www.twitter.com/oscarbouhttp://es.linkedin.com/in/oscarbouhttp://www.GesConsultor.comEste mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. ,Paseode laCastellana, 153 bajo - 28046 (Madrid), yAvda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.

Re: [VOTE] Apache Isis Core release 1.4.0 and related components

[GESCONSULTOR - Óscar Bou]

+1

Great release :-)

No problems while doing it...

Previous problems on tests regarding Spanish locale has been properly solved 
and all them pass OK.



El 09/03/2014, a las 18:50, Jeroen van der Wal jer...@stromboli.it escribió:

 +1
 
 My experience was similar to Kevin's but finally managed.

Re: Information for Google Summer of Code 2014

[GESCONSULTOR - Óscar Bou]

Hi to all.There can be more general-purpose integrations if we generalize some implementation over Apache Camel [1] components [2].Also, another really useful (and cool ;-) platforms for automation would be:- Twilio [3] (for voice calls, SMS messaging, etc.).- Zapier [4] (automates more than 250 apps).- ITTT [5] (similar to Zapier).I'm sure there are plenty of scenarios that could benefit the most "traditional" applications (for example, by integrating with Evernote, etc.).[1]https://camel.apache.org[2]https://camel.apache.org/components.html[3]https://www.twilio.com[4] https://zapier.com[5] http://ittt.comEl 06/03/2014, a las 09:09, Dan Haywood d...@haywood-associates.co.uk escribió:I'm cc'ing users@ on this, since there might be folk there who would chipin...On 6 March 2014 00:16, Eshan Sudharaka esudhar...@gmail.com wrote:Hi Dan,I went through some documentation and got some very basic understandingabout Apache ISIS. And I build that toDo app and try went through the appcode.I am interested in developing following Project Idea.- to build some new off-the-shelf domain services, like the current Exceland Word mail merge ones- eg email- eg SMSing- eg Drools rules engineSo the idea is to build a generic service which can be used across the allof apps developing using ISIS. can you please provide some further detailson this.Is it similar tohttp://isis.apache.org/reference/services/command-context.html ? ProvidingAPI for get above services.Yes, it's similar in concept.I think the closest existing services are actually the domain services Ihave on my github repo for Word, Excel and String interpolation [1], [2],[3].I think it'd also be worthwhile providing some domain entities (mapped tobe persistent with JDO) to represent the domain concepts, for example anEmailTemplate or SmsMessageTemplate. This could become an all-purpose"communication channel" module for others to reuse. Note that Estatio [4]already provides a Links repo/Link entity that leverages [3].The JDO implementation of the CommandService and BackgroundService [4],[5](as used by the command-context service that you referenced) has supportfor this with the CommandJdo entity. Similarly the JDO impl ofAuditingService provides an AuditEntryJdo entity [6], and the JDO impl ofPublishingService provides a PublishedEventJdo entity [7]. So there areplenty of examples to work from.I have less things to say about the Drools rules engine, but I'm sure it'dbe useful. Oscar's project has done some sort of integration, so perhapsthere are ideas there that could be generalised. Oscar?My only concern about this project is whether it is large enough in scopeto fill up an entire summer. I wrote the string interpolation service [3]in an evening, for example, and the Links/Link service in Estatio only tooka couple more hours.  But maybe an all-purpose comms channel module plusa rules engine service (with additional entities to administer the rulesthemselves) might be big enough.HTHDan[1]https://github.com/danhaywood/isis-domainservice-docx[2]https://github.com/danhaywood/isis-domainservice-excel[3]https://github.com/danhaywood/isis-domainservice-stringinterpolator[4]https://github.com/estatio/estatio[5]http://isis.apache.org/components/objectstores/jdo/services/command-service-jdo.html[6]http://isis.apache.org/components/objectstores/jdo/services/background-command-service-jdo.html[7]http://isis.apache.org/components/objectstores/jdo/services/auditing-service-jdo.html[8]http://isis.apache.org/components/objectstores/jdo/services/publishing-service-jdo.htmlThanksOn Fri, Feb 28, 2014 at 3:42 PM, Dan Haywoodd...@haywood-associates.co.ukwrote:Hi Eshan,Thanks for your interest in GSOC and in Isis itself, of course.We had two students last year, and I mentored them (with Maurizio asco-mentor); they both built a viewer against the Restful Objectsinterface[1], [2].I must admit though that I had intended to skip mentoring a GSOC projectthis year, and I don't think any of the other committers are interested(speak up if no!)That's not to say I don't have several ideas for projects, for example:- build a "real-life" app in some suitable domain, along with asemi-academic write-up of their learnings - to would give us another substantial example app, along with somemarketing material about how learnable Isis- documentation: develop screencasts for all the various features that wehave - cos people would rather watch youtube than read- to build some new off-the-shelf domain services, like the current Exceland Word mail merge ones- eg email- eg SMSing- eg Drools rules engine- to develop an integration with Lucene, for full text-search across thedomain- I don't think this is a full summer's work though- to develop an oAuth integration- probably not a full summer's work though (even though I'm not exactlysure what an oAuth integration actually is)- to write a clean-room implementation of a JDO enhancer, as areplacementfor the DN one, and that ideally integrates with the JRebel plugin- 

Re: Information for Google Summer of Code 2014

[GESCONSULTOR - Óscar Bou]

i've talked with my wife and she allows me to complement you, Dan, where possible... :-))El 28/02/2014, a las 11:12, Dan Haywood d...@haywood-associates.co.uk escribió:Hi Eshan,Thanks for your interest in GSOC and in Isis itself, of course.We had two students last year, and I mentored them (with Maurizio asco-mentor); they both built a viewer against the Restful Objects interface[1], [2].I must admit though that I had intended to skip mentoring a GSOC projectthis year, and I don't think any of the other committers are interested(speak up if no!)That's not to say I don't have several ideas for projects, for example:- build a "real-life" app in some suitable domain, along with asemi-academic write-up of their learnings - to would give us another substantial example app, along with somemarketing material about how learnable Isis- documentation: develop screencasts for all the various features that wehave - cos people would rather watch youtube than read- to build some new off-the-shelf domain services, like the current Exceland Word mail merge ones- eg email- eg SMSing- eg Drools rules engine- to develop an integration with Lucene, for full text-search across thedomain- I don't think this is a full summer's work though- to develop an oAuth integration- probably not a full summer's work though (even though I'm not exactlysure what an oAuth integration actually is)- to write a clean-room implementation of a JDO enhancer, as a replacementfor the DN one, and that ideally integrates with the JRebel plugin- not really Isis-specific, but would definitely benefit the Isiscommunity- implement "Kemble", our proposed DSL for Isis, using XTend [3]So do say if any of the above strike you as interesting. HOWEVER, sinceI'm less that 50:50 about being a mentor this year, I'd need to see somereal commitment during the "getting to know you" phase of the programmebefore I decide to take it on.HTHDan[1] https://github.com/DImuthuUpe/ISIS_Android_Viewer[2] https://github.com/bhargavgolla/isisJavaScript/[3] https://issues.apache.org/jira/browse/ISIS-369On 28 February 2014 05:18, Eshan Sudharaka esudhar...@gmail.com wrote:Dear Members,I am a university student studying computer science at University ofColombo School of Computing, Sri Lankahttp://ucsc.cmb.ac.lk/.http://www.cse.mrt.ac.lk/ Iam interested in submitting a proposal for Google Summer Of Code 2014. Iam from a Java background and having few experiences of frameworks likeSpring, Hibernate, Struts. It will be really nice If you can provide someguidance on this. (Like how to contribute and existing CR 's to beimplemented )--*~Thanks  Regards~*Eshan Sudharakahttp://esudharaka.blogspot.com/Óscar Bou BouResponsable de ProductoAuditor Jefe de Certificación ISO 27001 en BSICISA, CRISC, APMG ISO 2, ITIL-F902 900 231 / 620 267 520http://www.twitter.com/oscarbouhttp://es.linkedin.com/in/oscarbouhttp://www.GesConsultor.comEste mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. ,Paseode laCastellana, 153 bajo - 28046 (Madrid), yAvda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.

Re: Maxlength for Text type

[GESCONSULTOR - Óscar Bou]

Hi, Deepak.By default, DataNucleus implementation has a default length for String fields of 255 [1], despite it can be changed by config.If you want longer lengths, you must explicitly add it to the @Column annotation.Simply replace your code by:private String response; @javax.jdo.annotations.Column(allowsNull = "true", jdbcType = "text", length = 1000) @MemberOrder(name = "Response", sequence = "11") @MultiLine(numberOfLines = 10) @TypicalLength(800) public String getResponse() {   return response; }Perhaps the@TypicalLength could be deduced from the @Column(length...), but "Typical" is not the same as "Max" length (as the @Column annotation indicates)...In Estatio, Dan and Jeroen have centralized all data types lengths to an external class, and I find it particularly useful. See [2].HTH,Oscar[1]http://www.datanucleus.org/servlet/jira/browse/NUCAPIJDO-37[2]https://github.com/estatio/estatio/blob/master/dom/src/main/java/org/estatio/dom/JdoColumnLength.javaEl 28/01/2014, a las 07:45, Dan Haywood d...@haywood-associates.co.uk escribió:It might be the database you're using that has that limit, and/or the@Column annotation you have.I'm just working on an entity right now that has a "memento" property, oflength 1024. its annotation is: @javax.jdo.annotations.Column(allowsNull="false", length=1024) @MultiLine(numberOfLines=20) @Hidden(where=Where.ALL_TABLES) @MemberOrder(name="Target",sequence = "4") @Disabled public String getMemento() { ... }This is fine on HSQLDB.HTHDanOn 28 January 2014 03:52, Deepak Gopalakrishnan dgk...@gmail.com wrote:Hello Dev,I've been trying an entity which has a property as below...private String response; @javax.jdo.annotations.Column(allowsNull = "true", jdbcType = "text") @MemberOrder(name = "Response", sequence = "11") @MultiLine(numberOfLines = 10) @TypicalLength(800) public String getResponse() {   return response; }My expected behaviour is a text area with any number of characters ( or avery high upper limit). I however get an error stating that the valuecharacter count exceeds 255 characters ( which is varchar count i believe)Please tell me what I'm missing here.--Regards,*Deepak Gopalakrishnan**Mobile*:+918891509774*Skype* : deepakgk87http://myexps.blogspot.comÓscar Bou BouResponsable de ProductoAuditor Jefe de Certificación ISO 27001 en BSICISA, CRISC, APMG ISO 2, ITIL-F902 900 231 / 620 267 520http://www.twitter.com/oscarbouhttp://es.linkedin.com/in/oscarbouhttp://www.GesConsultor.comEste mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. ,Paseode laCastellana, 153 bajo - 28046 (Madrid), yAvda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.

Re: Fast workflow on Isis

[GESCONSULTOR - Óscar Bou]

Thanks a lot, Dan!It's going to be of great help. Let's license and try it.El 22/01/2014, a las 23:42, Dan Haywood d...@haywood-associates.co.uk escribió:OK, then.https://github.com/danhaywood/isis-jrebel-pluginYou'll need to use build from source for the moment.My limited testing shows that it works for the "simple" app, but I've nottried it out on anything bigger like Estatio.But try it out (and I'll put a screencast together for this, since Isuspect it might be popular...)On 18 January 2014 18:55, GESCONSULTOR o@gesconsultor.com wrote:Really nice!Another time-saving feature of Isis, like the auto-generated UI,persistence support, BDD and unit tests integration,etc.Our time can be spent thinking, implementing and testing the domain modelat least a 80%, without loosing it with dev or deployment infrastructureops!El 18/01/2014, a las 17:46, Dan Haywood d...@haywood-associates.co.ukescribió:Been doing some further experiments on JRebel, so as a quick update, I*think* it's doable, but requires a small enhancement to DataNucleus.For further reading, see [1] and [2][1] https://issues.apache.org/jira/browse/ISIS-651[2] http://www.datanucleus.org/servlet/jira/browse/NUCCORE-1104On 10 January 2014 17:46, GESCONSULTOR o@gesconsultor.com wrote:Many Thanks for moving forward this, Dan.It can really boost our productivity.For what I've read JRebel is the best way. It was just an alternativefound.El 10/01/2014, a las 17:54, Dan Haywood d...@haywood-associates.co.ukescribió:On 27 December 2013 23:12, GESCONSULTOR - Óscar Bouo@gesconsultor.comwrote:Hi to all.Dan, some days ago you commented the possibility to accelerate theworkflow by integrating with JRebel.Just to mention, seems on the Ninja Framework they have achievedsomethingsimilar as detailed in [1].This functionality is introduced at [2], where it references anarticlein[3].Perhaps it's a different approach to accelerate the Isis workflow.Thanks for this, Oscar.However, in [1], they say:*You start Ninja’s SuperDevMode in a console. Then you edit a Java fileinyour IDE and save it. Your IDE will then compile your Java file to aclassfile. Ninja’s SuperDevMode recognizes that and restarts Ninja within asecond. You can then switch to your browser and verify that yourchangeswork at http://localhost:8080 http://localhost:8080/ . *So I don't think this will work, because Isis takes rather longer thanasecond to build up its metamodel.I'm pretty certain that JRebel is the right way to go ... I spoke tooneoftheir evangelists at a conference in November, so reckon it'll work.Wecan invalidate Isis' metamodel ok (theDeveloperUtilitiesServiceDefault#refreshLayout() method), the only realunknown is how to invalidate the DN metamodel similarly.Let me go ask Andy Jefferson about that...DanHTH,Oscar[1] http://www.ninjaframework.org/documentation/super_dev_mode.html[2] http://www.ninjaframework.org/documentation/getting_started.html[3]http://java.jiderhamn.se/2011/12/11/classloader-leaks-i-how-to-find-classloader-leaks-with-eclipse-memory-analyser-mat/Óscar Bou BouResponsable de ProductoAuditor Jefe de Certificación ISO 27001 en BSICISA, CRISC, APMG ISO 2, ITIL-F902 900 231 / 620 267 520http://www.twitter.com/oscarbouhttp://es.linkedin.com/in/oscarbouhttp://www.GesConsultor.comEste mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. ,Paseode laCastellana, 153 bajo - 28046 (Madrid), yAvda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.

Re: ISIS with JPA

[GESCONSULTOR - Óscar Bou]

Due to our project timeframes we cannot leader this effort, but as we have 
working with both JDO and JPA we can also provide support for it if needed 
(pointing to equivalent annotations, ways of doing things, etc.).

HTH,

Oscar





El 07/01/2014, a las 08:14, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 On 6 January 2014 11:29, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.comwrote:
 
 ... There's no guide as it would be needed to implement something
 equivalent to the isis-objectstore-jdo [1].
 
 Perhaps Jeroen or Dan can give you an estimate about the effort it would
 require.
 
 
 I reckon it'd take about 30 days work for me to implement.
 
 But the main issue is freeing up the time to work on it; my time working on
 Isis is largely building out features in support of Estatio [2]; so having
 JPA API support isn't a priority in that respect.  We're more likely to
 prioritize building a next-gen viewer using AngularJS and the RO viewer
 (isis-viewer-restful).
 
 If anyone is keen to do the work though, then I'd be happy to spend a day
 with someone going through the JDO implementation, and identifying in
 detail the porting needed.
 
 Dan
 
 [2] https://github.com/estatio/estatio

Test not passing on latest Isis SNAPSHOT when executed with Spanish locale

[GESCONSULTOR - Óscar Bou]

Hi, Dan and Jeroen.

There's a test that it's not successfully executed on the latest ISIS snapshot. 
Seems there are problems related to user locale (my machine's locale is a 
Spanish one).

I've some some recent commits related to Joda.

The log message is at bottom of this message. 

I've just created ISIS-645 for this.

HTH,

Oscar



---
Test set: 
org.apache.isis.applib.services.xmlsnapshot.XmlSnapshotServiceAbstractTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.209 sec  
FAILURE!
test(org.apache.isis.applib.services.xmlsnapshot.XmlSnapshotServiceAbstractTest)
  Time elapsed: 0.208 sec   ERROR!
java.lang.IllegalArgumentException: Invalid format: 01-Apr-2013 is malformed 
at Apr-2013
at 
org.joda.time.format.DateTimeFormatter.parseLocalDateTime(DateTimeFormatter.java:828)
at 
org.joda.time.format.DateTimeFormatter.parseLocalDate(DateTimeFormatter.java:772)
at 
org.apache.isis.applib.services.xmlsnapshot.XmlSnapshotServiceAbstract.getChildElementValue(XmlSnapshotServiceAbstract.java:75)
at 
org.apache.isis.applib.services.xmlsnapshot.XmlSnapshotServiceAbstractTest.test(XmlSnapshotServiceAbstractTest.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)

Re: ISIS-486: modal dialogs for action prompts

[GESCONSULTOR - Óscar Bou]

Really well-looking, Jeroen.

Regarding navigability through actions, I think that perhaps there are 2 
distinct use cases that should be treated differently as such:

1. The user creates an Aggregate Root (such as an Order). As such, normally 
want to navigate to the newly created one.
2. The user creates an Entity that is part of an Aggregate (such as an Order 
Line / Item). In this case, normally the user wants to stay on the Order by 
default. If not, he/she can always navigate by clicking on the item collections 
link to the newly created item.

Implementing that desired default behavior by Isis could be easily done with an 
annotation that can be associated with an action, such as @NotNavigate (sure 
there are better names :-).

By default, the Isis framework viewers open the action's returned entity (such 
as when invoking Orders.createOrder(...) ), but that behavior could be 
overridden annotating with @NotNavigate the ( Order.createItem(...) ) action:

public class Order {

   ...

   @NotNavigate
   public OrderItem createItem(...) {
...
   }

}


Currently, we are forced to choose to return void or return an object, as that 
mandates the Isis viewer behavior. With that annotation, the value returned 
does not always imposes the navigation behavior.

Perhaps there are better solutions or some pitfalls on this proposal.

HTH,

Oscar



El 02/12/2013, a las 22:57, Jeroen van der Wal jer...@stromboli.it escribió:

 Thanks for reminding Dan, screenshot now as link [1]
 
 [1]
 https://dl.dropboxusercontent.com/u/1930710/Attachments/Screen%20Shot%202013-12-02%20at%2010.03.35%20PM.png
 
 
 On Mon, Dec 2, 2013 at 10:23 PM, Dan Haywood
 d...@haywood-associates.co.ukwrote:
 
 Hi Jeroen,
 Screenshots get stripped from the mailing list, so you'll need to post it
 somewhere online.  How about updating the screenshots on Estatio's README?
 
 By the way, I have a further commit... discovered that default values for
 parameters are not honoured second time around (ie bring up an action
 prompt, then cancel, then bring it up again).
 
 Cheers
 Dan
 
 
 
 On 2 December 2013 21:17, Jeroen van der Wal jer...@stromboli.it wrote:
 
 The modal dialog really improves the usability, thanks Dan. I've attached
 attached a screenshot which tells more then thousand words.
 
 I just recently learned that you can use java.lang.Object as the return
 type of an action and return whatever domain object or collection you
 programmatically decide. So your action basically is the controller.
 Nice!
 Sounds familiar to what Oscar is doing.
 
 Cheers,
 
 Jeroen
 
 
 
 
 On Mon, Dec 2, 2013 at 7:37 PM, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:
 
 
 
 Good done.
 
 We also use modal dialogs on our custom viewer to avoid context
 switching. The same dialog redirects to a Domain Object if that's the
 result of the action invocation, or currently shows a Collection in a
 grid
 on the same dialog if that's the result of the action. The user can then
 navigate to any of the objects in the collection.
 
 
 
 El 02/12/2013, a las 17:54, Dan Haywood d...@haywood-associates.co.uk
 escribió:
 
 Hi folks,
 
 just an fyi that I've committed and pushed ISIS-486 [1], to render the
 Wicket viewer's action prompts in modal dialogs.   This should make
 for
 a
 better overall user experience.
 
 To use, you'll need to build from source, as per [2].
 
 In case there are issues, the old behaviour (action prompts on their
 own
 page) can be enabled by adding the following property:
 
 isis.viewer.wicket.disableModalDialogs=true
 
 into WEB-INF/viewer_wicket.properties (or isis.properties if you
 prefer).
 I'll probably remove this original behaviour before pushing out a
 final
 release, though.
 
 Cheers
 Dan
 
 
 [1] https://issues.apache.org/jira/browse/ISIS-486
 [2] http://isis.apache.org/contributors/building-isis.html
 
 
 
 

Re: ISIS-486: modal dialogs for action prompts

[GESCONSULTOR - Óscar Bou]

Hi, Dan.

I like a lot the idea of explicitly having an annotation for Aggregate Roots 
(and, commercially speaking, it can be a big call to all those interested on 
DDD...). I'm sure we will find more use cases for that annotation in the near 
future, as it will force us to consider the distinct semantics of ARs vs 
child Entities in different places.

Also, I like also a lot the idea to have idioms that can be expressed through 
Isis templates  but a bit unsure about imposing them (it's clearly not the 
case on what you're proposing).

I assume that the target to evaluate would always be the entity you are 
invoking the action from. 
If it's not an AR, in theory it should be showed without being able to modify 
it (as a Value Object) in order to force the invariants imposed by the AR. 
Despite that, in our case, we could have contributed actions (from the AR, or 
actions from the Entity delegated to the AR) that would allow for properly 
modifying it within the context of its AR. And, if no invariants must be 
preserved on some fields, they simply could be safely edited ... So, basically, 
if properly implemented through Isis (with disabled, hidden and actions) a 
child entity can safely be edited preserving all invariants.

As a derivation, on action invoked on Domain Services, Isis viewers will always 
navigate to the returned entity, despite it's an AR or not (no reason on DDD to 
return it from a Service, but no need neither to explicitly forbid it for those 
following bad practices).
 
HTH,

Oscar




El 03/12/2013, a las 12:21, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 That's an interesting idea, Oscar.
 
 The issue arises from the fact that there are potentially two different
 callers of the Order#createItem method:
 a) the Isis framework itself - in which case, as we all know, the signature
 of the methdo is used to determine presentation/navigation
 b) other domain objects, ie programmatic interaction.  In some cases the
 caller might want the aggregate root (Order), at other times the aggregated
 (OrderItem).
 
 Actually, being strict about (b), under DDD the aggregate root should never
 return one of its constituent parts.  That would argue that even for
 programmatic interactions (b) the method should only return Order, not
 OrderItem.
 
 If we relax that rule, though, then one solution is to split out the method
 according to its two different callers, and have one method delegate to the
 other; eg:
 
 public class Order {
public Order createItem( ... )  {
doCreateItem(...);
return this;
   }
   @Programmatic
   pubilc OrderItem doCreateItem(  ) {
   OrderItem item = ...
   ...
   return item;
   }
 }
 
 I suspect the above pattern/idiom is sufficient in many cases.
 
 But if that seems like too much boilerplate, and we really did want to have
 a single method (such that Isis renders the Order even though an OrderItem
 is returned) then I think I'd prefer to simply annotate which of our
 entities are aggregate roots, ie
 
 @AggregateRoot
 public class Order { ... }
 
 Then, the rule would be that if the returned object does not have the
 AggregateRootFacet, then we instead navigate to the target aggregate root.
 
 Thoughts?
 Dan
 
 
 
 
 On 3 December 2013 10:01, GESCONSULTOR - Óscar Bou
 o@gesconsultor.comwrote:
 
 
 Really well-looking, Jeroen.
 
 Regarding navigability through actions, I think that perhaps there are 2
 distinct use cases that should be treated differently as such:
 
 1. The user creates an Aggregate Root (such as an Order). As such,
 normally want to navigate to the newly created one.
 2. The user creates an Entity that is part of an Aggregate (such as an
 Order Line / Item). In this case, normally the user wants to stay on the
 Order by default. If not, he/she can always navigate by clicking on the
 item collections link to the newly created item.
 
 Implementing that desired default behavior by Isis could be easily done
 with an annotation that can be associated with an action, such as
 @NotNavigate (sure there are better names :-).
 
 By default, the Isis framework viewers open the action's returned entity
 (such as when invoking Orders.createOrder(...) ), but that behavior could
 be overridden annotating with @NotNavigate the ( Order.createItem(...) )
 action:
 
 public class Order {
 
   ...
 
   @NotNavigate
   public OrderItem createItem(...) {
...
   }
 
 }
 
 
 Currently, we are forced to choose to return void or return an object, as
 that mandates the Isis viewer behavior. With that annotation, the value
 returned does not always imposes the navigation behavior.
 
 Perhaps there are better solutions or some pitfalls on this proposal.
 
 HTH,
 
 Oscar
 
 
 
 El 02/12/2013, a las 22:57, Jeroen van der Wal jer...@stromboli.it
 escribió:
 
 Thanks for reminding Dan, screenshot now as link [1]
 
 [1]
 
 https://dl.dropboxusercontent.com/u/1930710/Attachments/Screen%20Shot%202013-12-02%20at%2010.03.35

Re: ISIS-486: modal dialogs for action prompts

[GESCONSULTOR - Óscar Bou]

This is a mixed approach and I would prefer it also.

The viewer annotation @Void (if it's for the viewer, perhaps @NotNavigate or 
something more specific or explicit would be better than the generic term 
void ) would have preference on the viewer's behavior.

In absence, the logic could be to search for @AggregateRoot on the action's 
entity.


El 03/12/2013, a las 13:49, Jeroen van der Wal jer...@stromboli.it escribió:

 I also prefer an annotation and not put boilerplate code in the domain for
 ui purposes. An @AggregateRoot annotation doesn't meet all our requirements
 though: we have cases where child objects are an aggregate in it's own:
 
 Lease - @AggregateRoot
 + LeaseItem - aggregate for terms
   + LeaseTerm
 
 Another approach in this case would be to use a viewer directive to ignore
 the result of an action and to return to the calling page. Something like:
 
 public class LeaseItem {
...
@Void
public LeaseTerm newTerm(...) {...}
...
 }
 
 This solution would also solve situations where you want to navigate away
 from an aggregate root.
 
 Cheers,
 
 Jeroen
 
 
 On Tue, Dec 3, 2013 at 12:48 PM, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:
 
 
 Hi, Dan.
 
 I like a lot the idea of explicitly having an annotation for Aggregate
 Roots (and, commercially speaking, it can be a big call to all those
 interested on DDD...). I'm sure we will find more use cases for that
 annotation in the near future, as it will force us to consider the distinct
 semantics of ARs vs child Entities in different places.
 
 Also, I like also a lot the idea to have idioms that can be expressed
 through Isis templates  but a bit unsure about imposing them (it's
 clearly not the case on what you're proposing).
 
 I assume that the target to evaluate would always be the entity you are
 invoking the action from.
 If it's not an AR, in theory it should be showed without being able to
 modify it (as a Value Object) in order to force the invariants imposed by
 the AR.
 Despite that, in our case, we could have contributed actions (from the AR,
 or actions from the Entity delegated to the AR) that would allow for
 properly modifying it within the context of its AR. And, if no invariants
 must be preserved on some fields, they simply could be safely edited ...
 So, basically, if properly implemented through Isis (with disabled, hidden
 and actions) a child entity can safely be edited preserving all
 invariants.
 
 As a derivation, on action invoked on Domain Services, Isis viewers will
 always navigate to the returned entity, despite it's an AR or not (no
 reason on DDD to return it from a Service, but no need neither to
 explicitly forbid it for those following bad practices).
 
 HTH,
 
 Oscar
 
 
 
 
 El 03/12/2013, a las 12:21, Dan Haywood d...@haywood-associates.co.uk
 escribió:
 
 That's an interesting idea, Oscar.
 
 The issue arises from the fact that there are potentially two different
 callers of the Order#createItem method:
 a) the Isis framework itself - in which case, as we all know, the
 signature
 of the methdo is used to determine presentation/navigation
 b) other domain objects, ie programmatic interaction.  In some cases the
 caller might want the aggregate root (Order), at other times the
 aggregated
 (OrderItem).
 
 Actually, being strict about (b), under DDD the aggregate root should
 never
 return one of its constituent parts.  That would argue that even for
 programmatic interactions (b) the method should only return Order, not
 OrderItem.
 
 If we relax that rule, though, then one solution is to split out the
 method
 according to its two different callers, and have one method delegate to
 the
 other; eg:
 
 public class Order {
   public Order createItem( ... )  {
   doCreateItem(...);
   return this;
  }
  @Programmatic
  pubilc OrderItem doCreateItem(  ) {
  OrderItem item = ...
  ...
  return item;
  }
 }
 
 I suspect the above pattern/idiom is sufficient in many cases.
 
 But if that seems like too much boilerplate, and we really did want to
 have
 a single method (such that Isis renders the Order even though an
 OrderItem
 is returned) then I think I'd prefer to simply annotate which of our
 entities are aggregate roots, ie
 
 @AggregateRoot
 public class Order { ... }
 
 Then, the rule would be that if the returned object does not have the
 AggregateRootFacet, then we instead navigate to the target aggregate
 root.
 
 Thoughts?
 Dan
 
 
 
 
 On 3 December 2013 10:01, GESCONSULTOR - Óscar Bou
 o@gesconsultor.comwrote:
 
 
 Really well-looking, Jeroen.
 
 Regarding navigability through actions, I think that perhaps there are 2
 distinct use cases that should be treated differently as such:
 
 1. The user creates an Aggregate Root (such as an Order). As such,
 normally want to navigate to the newly created one.
 2. The user creates an Entity that is part of an Aggregate (such as an
 Order Line / Item). In this case, normally the user wants

Re: ISIS-486: modal dialogs for action prompts

[GESCONSULTOR - Óscar Bou]

Simple and clear. I like it. :-))

But not sure if on the provided example the viewer would prevent to navigate to 
the newly created one.

I would expect the logic to be the next one:

1. Verify if the action is annotated with @NotNavigate or @Navigate. If so, 
execute that behavior (as it's explicitly mandated).
2. Verify if the action's returned entity is an @AggregateRoot. If so, navigate 
to it.
3. Verify if the Entity owning the invoked action is an @AggregateRoot. If so, 
navigate to it.
4. Simply close the dialog.


The Isis meta-model validation should forbid to use @Navigate on actions 
returning void.


El 03/12/2013, a las 14:52, Jeroen van der Wal jer...@stromboli.it escribió:

 @NotNagivate is indeed a better term. But if we use @AggregateRoot as
 default behavior we also need a directive to excplicity move away from the
 aggregate:
 
 @AggregateRoot
 public class Invoice {
...
public Invoice creditThisInvoice() {
// The @AR annotation prevents the viewer going to this new invoice
...
return newlyCreatedInvoice;
}
 }
 
 Perhapse introduce @Navigate as well?
 
 
 
 On Tue, Dec 3, 2013 at 2:02 PM, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:
 
 This is a mixed approach and I would prefer it also.
 
 The viewer annotation @Void (if it's for the viewer, perhaps @NotNavigate
 or something more specific or explicit would be better than the generic
 term void ) would have preference on the viewer's behavior.
 
 In absence, the logic could be to search for @AggregateRoot on the
 action's entity.
 
 
 El 03/12/2013, a las 13:49, Jeroen van der Wal jer...@stromboli.it
 escribió:
 
 I also prefer an annotation and not put boilerplate code in the domain
 for
 ui purposes. An @AggregateRoot annotation doesn't meet all our
 requirements
 though: we have cases where child objects are an aggregate in it's own:
 
 Lease - @AggregateRoot
 + LeaseItem - aggregate for terms
  + LeaseTerm
 
 Another approach in this case would be to use a viewer directive to
 ignore
 the result of an action and to return to the calling page. Something
 like:
 
 public class LeaseItem {
   ...
   @Void
   public LeaseTerm newTerm(...) {...}
   ...
 }
 
 This solution would also solve situations where you want to navigate away
 from an aggregate root.
 
 Cheers,
 
 Jeroen
 
 
 On Tue, Dec 3, 2013 at 12:48 PM, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:
 
 
 Hi, Dan.
 
 I like a lot the idea of explicitly having an annotation for Aggregate
 Roots (and, commercially speaking, it can be a big call to all those
 interested on DDD...). I'm sure we will find more use cases for that
 annotation in the near future, as it will force us to consider the
 distinct
 semantics of ARs vs child Entities in different places.
 
 Also, I like also a lot the idea to have idioms that can be expressed
 through Isis templates  but a bit unsure about imposing them (it's
 clearly not the case on what you're proposing).
 
 I assume that the target to evaluate would always be the entity you
 are
 invoking the action from.
 If it's not an AR, in theory it should be showed without being able to
 modify it (as a Value Object) in order to force the invariants imposed
 by
 the AR.
 Despite that, in our case, we could have contributed actions (from the
 AR,
 or actions from the Entity delegated to the AR) that would allow for
 properly modifying it within the context of its AR. And, if no
 invariants
 must be preserved on some fields, they simply could be safely edited ...
 So, basically, if properly implemented through Isis (with disabled,
 hidden
 and actions) a child entity can safely be edited preserving all
 invariants.
 
 As a derivation, on action invoked on Domain Services, Isis viewers will
 always navigate to the returned entity, despite it's an AR or not (no
 reason on DDD to return it from a Service, but no need neither to
 explicitly forbid it for those following bad practices).
 
 HTH,
 
 Oscar
 
 
 
 
 El 03/12/2013, a las 12:21, Dan Haywood d...@haywood-associates.co.uk
 escribió:
 
 That's an interesting idea, Oscar.
 
 The issue arises from the fact that there are potentially two different
 callers of the Order#createItem method:
 a) the Isis framework itself - in which case, as we all know, the
 signature
 of the methdo is used to determine presentation/navigation
 b) other domain objects, ie programmatic interaction.  In some cases
 the
 caller might want the aggregate root (Order), at other times the
 aggregated
 (OrderItem).
 
 Actually, being strict about (b), under DDD the aggregate root should
 never
 return one of its constituent parts.  That would argue that even for
 programmatic interactions (b) the method should only return Order, not
 OrderItem.
 
 If we relax that rule, though, then one solution is to split out the
 method
 according to its two different callers, and have one method delegate to
 the
 other; eg:
 
 public class Order {
  public Order createItem

Re: If using trunk, must register entities eagerly (ISIS-611)

[GESCONSULTOR - Óscar Bou]

Just to clarify, for people migrating to the latest snapshot after this commit, 
the only (optional) thing to do is remove the RegisterEntities from 
isis.properties as it's no longer needed, isn't it?


El 27/11/2013, a las 09:31, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Folks,
 for anyone working off the latest in source, I've just implemented a change
 in ISIS-611 making it mandatory for entities to be registered with JDO
 eagerly.
 
 If they are not, then the app won't boot (ie fails early).
 
 Details are at:
 http://isis.apache.org/components/objectstores/jdo/eagerly-registering-entities.html
 
 (This is the problem that was breaking Estatio for Jeroen, on the back of a
 change I made in ISIS-597.  I broke the ordering, basically.  Humble pie
 has been duly eaten).
 
 Thx
 Dan

Re: [VOTE] Apache Isis Wicket Viewer release 1.3.1 and archetypes

[GESCONSULTOR - Óscar Bou]

+1


El 05/11/2013, a las 00:41, Jeroen van der Wal jer...@stromboli.it escribió:

 +1
 
 
 On Mon, Nov 4, 2013 at 10:33 PM, Dan Haywood
 d...@haywood-associates.co.ukwrote:
 
 My +1
 
 
 On 4 November 2013 19:07, Bhargav Golla bhargav.go...@gmail.com wrote:
 
 +1
 
 Bhargav Golla
 Developer. Freelancer.
 Github http://www.github.com/bhargavgolla |
 LinkedINhttp://www.linkedin.com/in/bhargavgolla
 | Website http://www.bhargavgolla.com/
 
 
 On Mon, Nov 4, 2013 at 7:46 PM, Maurizio Taverna
 tavernamauri...@gmail.comwrote:
 
 +1
 
 
 2013/11/4 Dan Haywood d...@haywood-associates.co.uk
 
 I've staged a release for Apache Isis Wicket Viewer 1.3.1 and
 corresponding
 updated versions of the two archetypes (simple and quickstart).
 
 This is a patch release that fixes a number of small but significant
 issues
 with the Wicket UI [1].  It is based on Isis Core 1.3.0.
 
 The artifacts have been staged to staging repositories on
 repository.apache.org [2,3,4].  Each has a corresponding .asc
 signature
 file (same URL, suffix .asc).
 
 In the source code repo the code has been tagged as
 isis-viewer-wicket-1.3.1-RC1.
 
 Our website contains some suggestions of how to verify the release
 [5]
 
 Please verify the release and cast your vote.  The vote will be open
 for
 a
 minimum of 72 hours.
 
 [ ] +1
 [ ]  0
 [ ] -1
 
 
 
 
 [1]
 https://issues.apache.org/jira/browse/ISIS/fixforversion/12325543
 [2]
 
 
 
 
 https://repository.apache.org/content/repositories/orgapacheisis-061/org/apache/isis/viewer/isis-viewer-wicket/1.3.1/isis-viewer-wicket-1.3.1-source-release.zip
 [3]
 
 
 
 
 https://repository.apache.org/content/repositories/orgapacheisis-062/org/apache/isis/archetype/simple_wicket_restful_jdo-archetype/1.3.1/simple_wicket_restful_jdo-archetype-1.3.1-source-release.zip
 [4]
 
 
 
 
 https://repository.apache.org/content/repositories/orgapacheisis-063/org/apache/isis/archetype/quickstart_wicket_restful_jdo-archetype/1.3.1/quickstart_wicket_restful_jdo-archetype-1.3.1-source-release.zip
 [5] http://isis.apache.org/contributors/verifying-releases.html
 
 
 
 

Re: Vote for core 1.3.0 will be closed tomorrow.

[GESCONSULTOR - Óscar Bou]

Hi, Dan.


[ERROR] Failed to execute goal on project isis: Could not resolve dependencies 
for project org.apache.isis.core:isis:pom:1.3.0: Cannot access 
com-springsource-repository-bundles-external 
(http://repository.springsource.com/maven/bundles/external/) in offline mode 
and the artifact com.google.guava:guava:jar:15.0 has not been downloaded from 
it before. - [Help 1]
[


Despite that, all went ok.

Regards,

Oscar


El 24/10/2013, a las 13:05, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 fyi, the vote for 1.3.0 is due to finish tomorrow (after 72 hours).
 
 Right now we have +3 PMC votes, +2 others.
 
 If you want to cast a vote, please take the time today to do so.
 
 Thx
 Dan

Re: Vote for core 1.3.0 will be closed tomorrow.

[GESCONSULTOR - Óscar Bou]

That appeared if trying to build isis-core forcing maven offline (mvn clean 
install -o) as detailed on [1].

If run with mvn clean install it went ok.


[1] http://isis.apache.org/contributors/verifying-releases.html




El 24/10/2013, a las 14:25, GESCONSULTOR - Óscar Bou o@gesconsultor.com 
escribió:

 Hi, Dan.
 
 
 [ERROR] Failed to execute goal on project isis: Could not resolve 
 dependencies for project org.apache.isis.core:isis:pom:1.3.0: Cannot access 
 com-springsource-repository-bundles-external 
 (http://repository.springsource.com/maven/bundles/external/) in offline mode 
 and the artifact com.google.guava:guava:jar:15.0 has not been downloaded from 
 it before. - [Help 1]
 [
 
 
 Despite that, all went ok.
 
 Regards,
 
 Oscar
 
 
 El 24/10/2013, a las 13:05, Dan Haywood d...@haywood-associates.co.uk 
 escribió:
 
 fyi, the vote for 1.3.0 is due to finish tomorrow (after 72 hours).
 
 Right now we have +3 PMC votes, +2 others.
 
 If you want to cast a vote, please take the time today to do so.
 
 Thx
 Dan
 

Re: [VOTE] Apache Isis Core release 1.3.0 and other components

[GESCONSULTOR - Óscar Bou]

+1


El 24/10/2013, a las 09:42, Jeroen van der Wal jer...@stromboli.it escribió:

 +1
 
 
 On Wed, Oct 23, 2013 at 2:15 AM, DImuthu Upeksha dimuthu.upeks...@gmail.com
 wrote:
 
 +1
 
 
 On Tue, Oct 22, 2013 at 11:59 PM, Dan Haywood
 d...@haywood-associates.co.ukwrote:
 
 my own +1
 
 
 On 22 October 2013 19:18, Bhargav Golla bhargav.go...@gmail.com wrote:
 
 +1
 
 Bhargav Golla
 Developer. Freelancer.
 Github http://www.github.com/bhargavgolla |
 LinkedINhttp://www.linkedin.com/in/bhargavgolla
 | Website http://www.bhargavgolla.com/
 
 
 On Tue, Oct 22, 2013 at 7:32 PM, Maurizio Taverna 
 tavernamauri...@gmail.com
 wrote:
 
 +1
 
 
 2013/10/22 Dan Haywood d...@haywood-associates.co.uk
 
 Folks,
 I've staged a release for Apache Isis Core and a number of other
 components.
 
 Specifically, the components proposed for release are:
 - isis-core 1.3.0
 - isis-objectstore-jdo 1.3.0
 - isis-viewer-wicket 1.3.0
 - isis-viewer-restfulobjects 2.1.0
 - isis-security-shiro 1.3.0
 - quickstart_wicket_restful_jdo-archetype 1.3.0
 - simple_wicket_restful_jdo-archetype 1.3.0
 
 The new simple archetype is a very minimal app, ie much less
 hassle
 than
 stripping back the ToDo app generated by the quickstart archetype.
 
 The artifacts have been staged to staging repositories on
 repository.apache.org:
 
 -
 
 
 
 
 
 https://repository.apache.org/content/repositories/orgapacheisis-001/org/apache/isis/core/isis/1.3.0/isis-1.3.0-source-release.zip
 -
 
 
 
 
 
 https://repository.apache.org/content/repositories/orgapacheisis-005/org/apache/isis/objectstore/isis-objectstore-jdo/1.3.0/isis-objectstore-jdo-1.3.0-source-release.zip
 -
 
 
 
 
 
 https://repository.apache.org/content/repositories/orgapacheisis-006/org/apache/isis/viewer/isis-viewer-wicket/1.3.0/isis-viewer-wicket-1.3.0-source-release.zip
 -
 
 
 
 
 
 https://repository.apache.org/content/repositories/orgapacheisis-010/org/apache/isis/viewer/isis-viewer-restfulobjects/2.1.0/isis-viewer-restfulobjects-2.1.0-source-release.zip
 -
 
 
 
 
 
 https://repository.apache.org/content/repositories/orgapacheisis-011/org/apache/isis/security/isis-security-shiro/1.3.0/isis-security-shiro-1.3.0-source-release.zip
 -
 
 
 
 
 
 https://repository.apache.org/content/repositories/orgapacheisis-012/org/apache/isis/archetype/quickstart_wicket_restful_jdo-archetype/1.3.0/quickstart_wicket_restful_jdo-archetype-1.3.0-source-release.zip
 -
 
 
 
 
 
 https://repository.apache.org/content/repositories/orgapacheisis-014/org/apache/isis/archetype/simple_wicket_restful_jdo-archetype/1.3.0/simple_wicket_restful_jdo-archetype-1.3.0-source-release.zip
 
 Each zip file has a corresponding signature, with suffix .asc
 
 In the source code repo there are tags for each of these artifacts:
 - isis-1.3.0-RC1
 - isis-objectstore-jdo-1.3.0-RC1
 - isis-viewer-wicket-1.3.0-RC1
 - isis-viewer-restfulobjects-2.1.0-RC1
 - isis-security-shiro-1.3.0-RC1
 - quickstart_wicket_restful_jdo-1.3.0-RC1
 - simple_wicket_restful_jdo-1.3.0-RC1
 
 Our website contains some suggestions of how to verify the release,
 see
 http://isis.apache.org/contributors/verifying-releases.html and
 also
 
 
 
 
 http://isis.staging.apache.org/contributors/verifying-releases-script.html
 
 Please verify the release and cast your vote.  The vote will be
 open
 for
 a
 minimum of 72 hours.
 
 [ ] +1
 [ ]  0
 [ ] -1
 
 
 
 
 
 
 
 --
 Regards
 
 W.Dimuthu Upeksha
 Undergraduate
 Department of Computer Science And Engineering
 
 University of Moratuwa, Sri Lanka
 

Re: Revamping the Isis website

[GESCONSULTOR - Óscar Bou]

Hi, Dan (again).


I've just scrolled to all 20 slides, and I expected more. As they're like a 
little tutorial about the capabilities of the framework, it does not get 
bored, at least for me ...

But it's true its a little bit strange to have so much slides on a main page 
carousel.

So I would vote for the second option, including both the individual 
screenshots and the carousel.

HTH,

Oscar


El 11/10/2013, a las 12:17, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Folks,
 
 In a few weeks time I'm doing a session at Oredev [1] in Sweden, so am
 planning to get a release out of Isis in readiness for that
 
 I'm also updating our website, with an updated home page [2] having a
 crarousel of screenshots from the todo app.  Currently this replaces the
 screenshot page.
 
 As of this point the carousel runs to 20 or so slides, but I reckon it
 could be as long as 60 slides if I documented all of the main features of
 Isis that are shown in the todo app.
 
 Is that good, or bad?
 
 Alternatively, the carousel could show the main highlights, and then there
 could be a reinstate screenshots page (perhaps the full carousel) of all 60
 slides.
 
 Anyway, I'd appreciate any feedback.
 
 Thx
 Dan
 
 PS: I've also updated to Bootstrap3; so if you see any layout glitches,
 that would also be good to know.
 
 
 [1]
 http://oredev.org/2013/wed-fri-conference/rrraddd-ridiculously-rapid-domain-driven-and-restful-apps-with-apache-isis
 [2] http://isis.apache.org/

Re: [jira] [Created] (ISIS-537) Convert Wicket viewer to use Bootstrap, so that it can be themed.

[GESCONSULTOR - Óscar Bou]

Hi, Dan.

Just to let you know. 

We are adapting this week our UI to a Bootstrap theme. It's being really easy 
by using LESS [1], as it allows to mix distinct CSS styles.

In that way, we can have a predefined CSS style for our UI components (i.e., 
.wm_gesconsultor .wmbutton), and, on a styles.less file, define it as an 
extension to the .btn.blue class defined on a styles.css file.

As an example:

@import style-metro.less;
@import bootstrap.less; 
@import style.less; 


.wm_gesconsultor .wmbutton {
:extend(.btn.blue all);
border: 0px solid !important;
}

.wm_gesconsultor .dijitButtonNode {
:extend(.btn.blue all);

border: 0px solid !important;
margin: 4px;
padding: 0px;
overflow: hidden;
left: 0px;
top: 0px;
width: 72px;
height: 24px;
line-height: normal;
}


On this way, for changing the theme, only the .less file must be upgraded, to 
map the isis-button, etc. to the new css defined on the style that the 
user wants to.

HTH,

Oscar


[1] http://lesscss.org/


El 17/09/2013, a las 22:55, Dan Haywood (JIRA) j...@apache.org escribió:

 Dan Haywood created ISIS-537:
 
 
 Summary: Convert Wicket viewer to use Bootstrap, so that it can 
 be themed.
 Key: ISIS-537
 URL: https://issues.apache.org/jira/browse/ISIS-537
 Project: Isis
  Issue Type: New Feature
  Components: Viewer: Wicket
Affects Versions: viewer-wicket-1.2.0
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: viewer-wicket-1.4.0
 
 
 Using https://github.com/l0rdn1kk0n/wicket-bootstrap as the wicket/bootstrap 
 integration.
 
 --
 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: [jira] [Created] (ISIS-537) Convert Wicket viewer to use Bootstrap, so that it can be themed.

[GESCONSULTOR - Óscar Bou]

Sure!


Really good news! Isis is becoming a powerful horse for BDD-driven, 
database-agnostic Domain implementation.

We are at the moment that strongly experienced UI developers are in need, so 
welcome aboard!

Regards,

Oscar




El 18/09/2013, a las 09:39, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Very good... glad we're evolving your bespoke UI and Isis out-of-the-box
 UIs sympathetically.
 
 Meanwhile, I've asked offline whether Martin Grigorov (a Wicket committer
 and who I know has been following Isis) and his colleague, Michael Haitz,
 whether they would be interested in helping me to port Wicket to Bootstrap
 using their wicket-bootstrap integration [1].  Glad to say they are both
 enthusiastic to do so.  Michael has forked the Isis repo [1], and I have
 push rights.  I made a start stripping out the current CSS and integrating
 in wicket-bootstrap; I'm doing this work in a fork [3] so can do a merge
 when complete.
 
 No timescales defined for this, but I'm very happy to have two experienced
 Wicketeers help me on this.
 
 Later!
 Dan
 
 
 [1] https://github.com/l0rdn1kk0n/wicket-bootstrap
 [2] https://github.com/l0rdn1kk0n/isis
 [3] https://github.com/l0rdn1kk0n/isis/tree/ISIS-537
 
 
 
 On 18 September 2013 08:30, GESCONSULTOR - Óscar Bou o@gesconsultor.com
 wrote:
 
 
 Hi, Dan.
 
 Just to let you know.
 
 We are adapting this week our UI to a Bootstrap theme. It's being really
 easy by using LESS [1], as it allows to mix distinct CSS styles.
 
 In that way, we can have a predefined CSS style for our UI components
 (i.e., .wm_gesconsultor .wmbutton), and, on a styles.less file, define it
 as an extension to the .btn.blue class defined on a styles.css file.
 
 As an example:
 
 @import style-metro.less;
 @import bootstrap.less;
 @import style.less;
 
 
 .wm_gesconsultor .wmbutton {
:extend(.btn.blue all);
border: 0px solid !important;
 }
 
 .wm_gesconsultor .dijitButtonNode {
:extend(.btn.blue all);
 
border: 0px solid !important;
margin: 4px;
padding: 0px;
overflow: hidden;
left: 0px;
top: 0px;
width: 72px;
height: 24px;
line-height: normal;
 }
 
 
 On this way, for changing the theme, only the .less file must be upgraded,
 to map the isis-button, etc. to the new css defined on the style that
 the user wants to.
 
 HTH,
 
 Oscar
 
 
 [1] http://lesscss.org/
 
 
 El 17/09/2013, a las 22:55, Dan Haywood (JIRA) j...@apache.org
 escribió:
 
 Dan Haywood created ISIS-537:
 
 
Summary: Convert Wicket viewer to use Bootstrap, so that it
 can be themed.
Key: ISIS-537
URL: https://issues.apache.org/jira/browse/ISIS-537
Project: Isis
 Issue Type: New Feature
 Components: Viewer: Wicket
   Affects Versions: viewer-wicket-1.2.0
   Reporter: Dan Haywood
   Assignee: Dan Haywood
Fix For: viewer-wicket-1.4.0
 
 
 Using https://github.com/l0rdn1kk0n/wicket-bootstrap as the
 wicket/bootstrap integration.
 
 --
 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: [Android viewer]APK for testing

[GESCONSULTOR - Óscar Bou]

My congrats also, Dimuthu!

It looks really good and its response time is also quite fast on both Android 
versions.

As the link to the latest video was not on this thread, I add it [1] 


Keep the good job!


Thanks,

Oscar


[1] http://www.youtube.com/watch?v=AtMPW0B-ZRE



El 11/09/2013, a las 09:42, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Good stuff, Dimuthu!
 
 
 On 10 September 2013 15:26, DImuthu Upeksha dimuthu.upeks...@gmail.comwrote:
 
 Hi Dan.
 Ok I will update them. Application does not depend on screen size. You can
 run it on any device that has a supporting android version. I have attached
 an image of it running on nexus 7 tablet.
 
 Thnx
 Dimuthu
 
 
 On Tue, Sep 10, 2013 at 10:27 AM, Dan Haywood 
 d...@haywood-associates.co.uk wrote:
 
 Good stuff, Dimuthu.
 
 Could you update your README [1] (or provide links into your wiki [2])
 giving step-by-step details of how to try it out?  I'm thinking both the
 client installation onto the phone, and also running the server.
 
 Also: question: what size screens does your viewer run on?  Could I run
 it on a Nexus tablet, for example?
 
 Cheers
 Dan
 
 [1] https://github.com/DImuthuUpe/ISIS_Android_Viewer
 [2] https://github.com/DImuthuUpe/ISIS_Android_Viewer/wiki
 
 
 On 10 September 2013 03:01, DImuthu Upeksha 
 dimuthu.upeks...@gmail.comwrote:
 
 It seems like dev@isis.apache.org does not accept mails larger than
 1MB. So I uploaded my apk to dropbox [1]. You can download it from that
 link.
 
 [1] https://www.dropbox.com/s/vmlvwp1ee3e0l6a/ISIS_Android_Viewer.apk
 
 
 
 On Tue, Sep 10, 2013 at 7:25 AM, DImuthu Upeksha 
 dimuthu.upeks...@gmail.com wrote:
 
 Hi Dan,
 I bundled the project in to an APK file so that anyone who has an
 Android device can test it. It currently support from android 2.2 to 4.2. 
 I
 didn't test it in versions below 2.2. If you have time please try it and
 give me some feedbacks to improve it
 
 Thnx
 Dimuthu
 --
 Regards
 
 W.Dimuthu Upeksha
 Undergraduate
 Department of Computer Science And Engineering
 
 University of Moratuwa, Sri Lanka
 
 
 
 
 --
 Regards
 
 W.Dimuthu Upeksha
 Undergraduate
 Department of Computer Science And Engineering
 
 University of Moratuwa, Sri Lanka
 
 
 
 
 
 --
 Regards
 
 W.Dimuthu Upeksha
 Undergraduate
 Department of Computer Science And Engineering
 
 University of Moratuwa, Sri Lanka
 

Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions

[GESCONSULTOR - Óscar Bou]

Mmmm... I understand those arguments.

Just for doing a lateral thinking exercise and question the current status, 
I'm going to question some things :-)


In practice, if taken until the end, what that would implied, is:
- that we should remove the Isis' @Optional annotation (among others).
- that we would implement some Facets for the meta-model that would not have a 
corresponding Isis annotation (so the Isis metadata would not be complete 
in terms of its own meta-model).
- that we are always going to use on Isis webapps JDO as the ORM metadata (if 
one decision criteria is number of developers it will be important to support 
JPA in the future), 
- that we are always going to use on Isis webapps DN as an object store (I'm 
happy with this right now),
- that we are always going to use on Isis webapps an object store in our apps, 
and use cases where it's not present would not be Isis use cases (unless we 
mark all entities as transient or something like that; not clear to me...). For 
example, we have an IT Real-time Monitoring Bounded Context where we want to 
use Isis. On that BC we would not have available those Isis features (whatever 
they will be in the future).


My opinion, a corresponding Isis annotation would be needed for any Facet, but 
to be concrete:
- for Facets that change the domain's behavior (such as the managed 
relationships; my code is becoming full of flush()'es just for updating the 
parent collection's size; this could be managed by Isis instead of delegating 
to DN).
- for Facets corresponding to behaviors delegated to one adapter's 
implementation that will be maintained as-is that can be required to be known 
by other adapters (such as mandatory properties, or imagine that we apply some 
bean validations on the UI for avoiding network traffic, so the UI would need 
access through the meta-model to those validations, etc.).


But this is just a theroretical discussion regarding a long-term vision.
Perhaps the KISS principle dictates to avoid any functionality duplication.

So it's also interesting to consider the costs to avoid previous handicaps, 
that I think would be:
- in terms of implementation, simply to have an Isis annotation for specifying 
the Facet's behavior. 
- in terms of maintainability, update it when the Facet behavior changes (that 
would imply also a change on the adapter that implements the delegated behavior 
- i.e. the objectstore or any other adapter that provides it -).

Perhaps they would be manageable for most cases, and we could align with the 
(at least my) vision.



Thanks,

Oscar










El 09/09/2013, a las 08:55, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 On 8 September 2013 11:55, Kevin Meyer - KMZ ke...@kmz.co.za wrote:
 
 I must admit that was one of our expectations when we firstly
 approximated Isis, perhaps because we were following the email list
 or saw the SQL Objectstore, etc.
 
 In fact, seems that recently we have taken the opposite path (by
 requiring nearly all Entity properties to be annotated with
 @Column(allowsNull=true|false), instead of improving the JDO
 Object Store usage of the Isis meta-model.
 
 When I first started with Isis (when it was still Naked Objects), I was
 really drawn to the fact that any POJO that I prototyped could be
 re-used as is elsewhere, as it contained no framework clutter.
 
 As Oscar says, this is now exactly the opposite. If the assumption is
 that Isis will always be the deployment framework, this is just fine!
 
 But we cannot expected to map/solve all ORM requirements on the Isis
 metamodel, so the end situation will be some inferred, some
 explicited for sure.
 
 In the SQL OS, I provided for hints to be specified in the properties
 file (overriding property-field mappings, table naming, etc) (and
 Eclipse could handle refactoring/renaming if the full name name was
 used in the properties file) - leaving the POJO clean of DB clutter.
 
 
 Yes, it's true that we now have the Isis metadata as secondary to the JDO
 annotations.
 
 This breaks symmetry and means that, to deploy Isis against a different
 ObjectStore, that at best those JDO annotations are redundant, at worst one
 that one would have put in equivalent metadata for the other OS (eg SQL OS'
 properties).
 
 As mentioned, we could invert this.  Using the DataNucleus metadata API
 [1], we could programmatically build up the DataNucleus metamodel from the
 Isis metamodel.  Where required, we could also recognize some subset of the
 JDO annotations that have no Isis equivalent (eg mappedBy for
 bidirectional annotations).  Or, I suppose, we could add in our own
 equivalent Isis annotations.
 
 I'm not convinced that this is the right thing to do though, for two
 reasons:
 
 1. there are many potential users out there that understand JDO (and JPA,
 of course, when we get around to support it's annotations).  Requiring them
 to learn the Isis equivalents is going to put them off.
 
 2. I don't think that being able to 

Re: Using JDO helper methods to check existence of an object for a test

[GESCONSULTOR - Óscar Bou]

That sounds really nice...



Are stress tests also included, in addition to regression tests? 

That raised on the list the previous weeks.  It will be really interesting to 
know if there are any concurrency issues at Wicket, Isis or DN. 

Seems that Selenium can also be used in a grid configuration to simulate stress 
load tests.

The creator of Selenium has founded also a company specialized on web stress 
tests [1]. As it's integrated with Amazon Web Services, you can configure your 
stress environment (and pay for it). 

I've just registered a trial account right now and seems good.

[1] https://home.wpm.neustar.biz/



El 08/09/2013, a las 09:45, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 That's fine with me.
 
 This week I'm starting to look at automated web browser tests (possibly
 using Geb [1] as a layer over Selenium).  Plan is for Estatio to act as a
 regression suite for Isis as a whole.  So no immediate rush my end.
 
 Cheers
 Dan
 
 
 [1] http://www.gebish.org/
 
 
 On 8 September 2013 08:35, GESCONSULTOR o@gesconsultor.com wrote:
 
 For sure!
 
 Unless you or Jeremy plan to use it immediately let me check and improve
 it this week through some BDD features we must implement.
 
 Thanks,
 
 Oscar
 
 
 El 08/09/2013, a las 09:20, Dan Haywood d...@haywood-associates.co.uk
 escribió:
 
 Looks very good, Oscar, exactly the sort of thing that should be in the
 framework, I think.
 
 Could you raise a ticket and provide a commit?  If you have the time,
 perhaps you could also refactor the ToDo app to show its use?
 
 Many thanks
 
 Cheers
 Dan
 
 
 
 On 7 September 2013 19:05, GESCONSULTOR - Óscar Bou
 o@gesconsultor.comwrote:
 
 
 I've just been thinking about a way to avoid to define a Spec
 Transformer
 for every Entity class in the Domain.
 
 As it's just infrastructure software, I thought that was just
 enough.
 
 The attached code allows to use just one Spec Transformer when the Glue
 is
 written like this:
 -  the employee with name PETER
 - the employee named PETER
 - the property with reference REF-001
 - the property referenced REF-001
 - the product with id PR-001
 
 From there, we know that:
 - The Entity singular name is employee (so it can be obtained from the
 Isis Object Specifications, reinforcing the Ubiquitous Language use on
 BDD
 specifications).
 - We must search by name
 - The name must be PETER
 
 
 
 For using it, I must define a Glue like this one:
 
 Define a Glue like this one:
 @When(The company (employee with name \[^\]*\) has a role assigned)
 public void
 
 the_company_employee_with_name(@Transform(GenericIsisJdoTransformer.class)
 final  Employee employee) {
  ...
 }
 
 
 
 First proof-of-concept code version follows this text.
 
 It can be improved in many ways, for allowing customization through
 inheritance, avoiding JDO through the use of the Apache Isis query
 methods,
 etc.
 
 
 But I would let you know, right to know if you think it can be useful.
 
 On this way, the only implemented classes  are the ones supporting the
 Glues (and only the Spec Transformers for more specific use cases).
 
 
 HTH,
 
 Oscar
 
 
 
 
 
 -
 
 
 
 
 package com.xms.framework.testing.integration.spectransformers;
 
 import java.util.HashMap;
 import java.util.Map;
 import java.util.regex.Matcher;
 import java.util.regex.Pattern;
 
 import javax.jdo.Query;
 
 import org.opensaml.artifact.InvalidArgumentException;
 
 import org.apache.isis.applib.DomainObjectContainer;
 import org.apache.isis.core.metamodel.spec.ObjectSpecification;
 import org.apache.isis.core.runtime.system.context.IsisContext;
 import org.apache.isis.core.specsupport.scenarios.ScenarioExecution;
 import
 
 org.apache.isis.objectstore.jdo.datanucleus.service.support.IsisJdoSupportImpl;
 
 /**
 * Requires the Gherkin's capture in the format '([entitySingularName]
 [(.+?)
 * name(d)|(.+?) reference|(.+?) id] \[entityId]\)'.
 * p
 * For example:
 * ul
 * lithe employee with name PETER/li
 * lithe employee named PETER/li
 * lithe property with reference REF-001/li
 * lithe property referenced REF-001/li
 * lithe product with id PR-001/li
 * /ul
 * p
 * For matching the first one we will need the following Gherkin regular
 * expression:
 * ul
 * li
 * \\@When(The company's (employee with name \[^\]*\) has a role
 assigned)/li
 * /ul
 * p
 * From there, we know that:
 * ul
 * liThe Entity singular name is employee./li
 * liWe must search by name/li
 * liThe name must be PETER/li
 * /ul
 *
 */
 public class GenericIsisJdoTransformer extends
 NullRecognizingTransformerObject {
 
   private static MapString, ObjectSpecification
 specificationsBySingularName;
 
   /**
* Tries to obtain the Entity class name, id and search field from
 the
* Cucumber capture, and find it on the JDO Object Store.
*
* @see com.xms.framework.testing.integration.spectransformers.
*  NullRecognizingTransformer#transformNonNull(java.lang.String)
*/
   @Override
   protected

Re: [DISCUSSION] Mothballing SQL ObjectStore, auto-inferring JDO annotations from Isis conventions

[GESCONSULTOR - Óscar Bou]

I must admit that was one of our expectations when we firstly approximated 
Isis, perhaps because we were following the email list or saw the SQL 
Objectstore, etc.

In fact, seems that recently we have taken the opposite path (by requiring 
nearly all Entity properties to be annotated with 
@Column(allowsTrue=true|false), instead of improving the JDO Object Store 
usage of the Isis meta-model.

It would also have another advantage: it would be the way to also support JPA 
implementations (or lessen the effort required).

But we cannot expected to map/solve all ORM requirements on the Isis metamodel, 
so the end situation will be some inferred, some explicited for sure.


I think that perhaps we must clarify Apache Isis responsibilities, and 
concentrate on them. 
So let me do a quick-and-dirty Envisionning exercise (it's Sunday...).



VISION STATEMENT:
Apache Isis intend to provide programmers with the best framework for 
implementing Domain-Driven Applications that interact with its environment 
without compromising business logic.

For that, I would say (for debating) the following (quick) responsibilities:
- The core responsibilities are:
1. to ease on Domain implementation (Entities, their relationships, and 
behavior / business rules / actions). 
2. to ease on Domain interaction with the environment (establishing ways to 
securely share that Domain Rules with the environment - applications or 
humans -).
3. to ease on Business Logic protection against business-logic thieves such 
as UIs and ORMs (by having all contextual info needed for the domain, and 
also for the actors interacting with the Domain).

From such a perspective:
a. From the ORM framework, we only need on the meta-model those annotations 
that affects the behavior of the Domain (read-only / transient, required, etc.) 
or the way the actors interact with it (memo/blob fields, etc.). But we don't 
need any information regarding how the ORM framework will store the domain, for 
example (any related to inheritance mappings, table or field names, etc.).

b. From Bean Validation frameworks, in theory we need all... It's all related 
to Domain's behavior. But we can simply consider it as another idiom to 
express Domain logic, and, as such, we should be able to use it internally on 
the Domain, but also to communicate it to external actors such as the UI and 
ORMs (nothing needed for the latter; it's currently implemented on Hibernate 
and seems that previous specification also on DataNucleus). 

c. For viewers (including webapp, RESTful Objects, etc. but also the ORM 
framework - it's just another adapter- detailed after), we need to give 
access to the domain structure (mainly Entities, their relationships, and 
behavior / business rules / actions) and contextual information about the 
status of the domain (and, perhaps, about the actors interacting with them, 
acting as a Glue or as a coordinator between all those interacting with them 
- like using information about the status of the ObjectStore to show in the 
User Interface, the Security Service, etc.). 


So perhaps a. would be my response to auto-inferring annotations right 
now... Those affecting the Domain's behavior yes, those about internals no...


Please, tell me if any other framework is as close to Alistair Cockburn's 
Ports and Adapters or Hexagonal Architecture as Apache Isis is [1].

It's interesting to read the Nature of the Solution section from the Apache 
Isis perspective. 

-- Citation -- 

THE PROBLEM
Both the user-side and the server-side problems actually are caused by the 
same error in design and programming — the entanglement between the business 
logic and the interaction with external entities. The asymmetry to exploit is 
not that between ‘’left’’ and ‘’right’’ sides of the application but between 
‘’inside’’ and ‘’outside’’ of the application. The rule to obey is that code 
pertaining to the ‘’inside’’ part should not leak into the ‘’outside’’ part. 

-- Me: And we have the means to communicate between inside and outside through 
the RESTful Objects specification.


CONSIDERATIONS ABOUT THE USER INTERFACE

For each external device there is an ‘’adapter’’ that converts the API 
definition to the signals needed by that device and vice versa. A graphical 
user interface or GUI is an example of an adapter that maps the movements of a 
person to the API of the port. Other adapters that fit the same port are 
automated test harnesses such as FIT or Fitnesse, batch drivers, and any code 
needed for communication between applications across the enterprise or net.


CONSIDERATIONS ABOUT THE DATABASE

On another side of the application, the application communicates with an 
external entity to get data. The protocol is typically a database protocol. 
From the application’s perspective, if the database is moved from a SQL 
database to a flat file or any other kind of database, the conversation across 
the API should not change. Additional adapters for the same 

Re: Isis session and transaction management on a custom viewer

[GESCONSULTOR - Óscar Bou]

Thanks a lot, David.

Yes, we have other platforms integrated with CAS, so the session could be kept 
alive longer than the Isis web session, so that could potentially occur.

If I've understood well, you have enabled the Shiro Native Session as per [1], 
isn't it ? 
With CAS the remember me feature is managed by the CAS Server, and also the 
SSO session time out ([2]), so in this case the native session manager seems 
not to be needed (nor compatible), but it could be the default configuration 
for Apache Isis webapps, with the advantages you pointed out.

Just to point others interested on CAS and Shiro, there's a really simple demo 
project right here [3].


Thanks again for sharing your conclusions when figured out.


Regards,

Oscar


[1] http://shiro.apache.org/web.html
[2] 
https://wiki.jasig.org/display/CASUM/HOWTO+Configure+Single+Sign+On+Session+Timeout
[3] https://github.com/leleuj/cas-shiro-demo


El 06/09/2013, a las 23:42, David Tildesley davo...@yahoo.co.nz escribió:

 Hi Oscar,
 
 David (me) wrote:
 
 I guess if you don't have desktop (kerberos)  SSO to the CAS sts then you 
 haven't got the same issue as us if you keep the cas token timeout less than 
 the http session timeout.
 
 Scrub that previous assumption - you will have the same problem if the user 
 is accessing other services and therefore keeping the CAS SSO token alive - 
 they will arrive back at the application with the http session expired but 
 with a valid CAS token and Shiro will dutifully authenticate them and pass 
 them to a resource with a brand new session - same potential for a bad user 
 experience. Our solution (when we figure it all out) should work for your 
 scenarios also.
 
 David.
 
 
 
 From: David Tildesley davo...@yahoo.co.nz
 To: us...@isis.apache.org us...@isis.apache.org 
 Cc: dev dev@isis.apache.org 
 Sent: Saturday, 7 September 2013 9:37 AM
 Subject: Re: Isis session and transaction management on a custom viewer
 
 
 Hi Oscar,
 
 That's good (CAS) where Shiro has a plugin. We (it's not my money) weren't 
 prepared to invest in writing a Kerberos authentication plugin for Shiro when 
 Weblogic already does Kerberos authentication and it's already got the tick 
 from Ent architecture.
 
 I'll let you know what conclusions we come to on the session timeout and 
 logout - it's all about giving the user a good experience as SSO can 
 confuse them when it seamlessly logs them back in but they get a different 
 session. 
 
 Cheers,
 David.
 
 
 
 From: GESCONSULTOR - Óscar Bou o@gesconsultor.com
 To: us...@isis.apache.org; David Tildesley davo...@yahoo.co.nz 
 Cc: dev dev@isis.apache.org 
 Sent: Saturday, 7 September 2013 3:17 AM
 Subject: Re: Isis session and transaction management on a custom viewer
 
 
 Hi, David.
 
 Really interesting. This second  we plan to integrate with the CAS SSO 
 platform the Isis domain, as detailed in [1]. 
 
 Authentication in CAS, authorization in Domain, thanks to Shiro (and also on 
 CAS on ). 
 
 It would be helpful to know about your approach to logout and session timeout 
 when you implement it. But in our case seems that CAS will manage that 
 functionality, instead of Shiro.
 
 Thanks,
 
 Oscar
 
 
 
 [1] http://shiro.apache.org/cas.html
 
 El 06/09/2013, a las 12:52, David Tildesley davo...@yahoo.co.nz escribió:
 
 Hi Dan,
 
 Dan wrote:
 
 If using Isis' Shiro integration for authenticaiotn/authorizatino, then
 there are also Shiros session management to consider [4].  I am pretty sure
 the default for that is also HttpSession, but it would seem to be pluggable
 and they say it supports clusters [5].
 
 You're right. Played with this by co-incidence today. I think this default 
 causes some loss of useful Shiro features (deferring to the container). 
 Turned on Shiro native session manager today by simple property in 
 Shiro.ini as per Shiro documentation[4]. Works ok and adds more capability 
 (e.g. ability to define Shiro session event listener,define Shiro session 
 timeout, ...). We are leaning towards form based container based 
 authentication (already hooked Shiro into trusting container authentication 
 and leaving Shiro to do authorisation). Reason is that we are using 
 container authentication for NegotiateAssertion for enterprise desktop SSO 
 (Kerberos) and we make this a permanent feature and also  have a fall 
 through (SUFFICIENT)  AD ldap authenticator defined as next container 
 authentication provider - simply to make life easy for the testers. We hope 
 to log events off the Shiro session events (start, stop, ...) . But we've 
 still got work to do
 around this and the side affects (e.g. session timeout and logout 
 behaviour). 
 
 If  using native session manager then need to name the Shiro session cookie 
 something other than the default JSESSIONID because it causes weirdness when 
 the container also produces a session cookie of the same name.
 
 David.
 
 
 [2] http

Re: Screencast #3

[GESCONSULTOR - Óscar Bou]

Just to clarify, the point is that our current viewer, based on Wavemaker, is 
implemented in DOJO, and we have all screen widgets composition code.

As we must refactor the Isis session management, perhaps a good solution 
would be to re-use the js viewer code, but, as you pointed out, that will be 
better done on the future project with Stef and Richard.


Thanks and keep the good work,

Oscar



El 06/09/2013, a las 22:47, GESCONSULTOR o@gesconsultor.com escribió:

 Yes, that was what I meant.
 
 Thanks!
 
 
 El 06/09/2013, a las 21:15, Bhargav Golla bhargav.go...@gmail.com escribió:
 
 I am sorry. I didn't exactly understand your question. Are you asking if we
 can use my code with minor changes, to use it with other UI libraries? If
 so, currently, no. As part of my plan post GSoC, as discussed with Dan, I
 would be working on something similar to this idea, with what Stef and
 Richard are working on in Spiro. We will work to improve their models file
 to act as a complete interface to all Isis interactions, so that developers
 can then develop any JS viewer by making use of this models file.
 
 Bhargav Golla
 Developer. Freelancer.
 B.E (Hons.) Computer Science
 BITS-Pilani
 Github http://www.github.com/bhargavgolla |
 LinkedINhttp://www.linkedin.com/in/bhargavgolla
 | Website http://www.bhargavgolla.com/
 
 
 On Sat, Sep 7, 2013 at 12:32 AM, GESCONSULTOR o@gesconsultor.comwrote:
 
 Looks really well, Bhargav.
 
 Just to know, Would it be relatively easy to reuse the classes
 interacting with Isis (for obtaining properties and collections, updating
 properties or executing actions) on an existing project made with other
 JavaScript UI libraries, like ExtJS, Vaadin or the ones here [1]?
 
 Thanks,
 
 Oscar
 
 
 [1]
 http://speckyboy.com/2010/05/17/15-javascript-web-ui-libraries-frameworks-and-libraries/
 
 
 El 06/09/2013, a las 20:43, Bhargav Golla bhargav.go...@gmail.com
 escribió:
 
 As Dan rightly pointed out, replaced the captions to top of video and
 have
 added new captions to annotate the video better. The video is now live
 here[1]. I have added the screencast of work I had done yesterday also.
 
 [1] http://youtu.be/o_REbP2OlNU
 
 Regards
 
 Bhargav Golla
 Developer. Freelancer.
 B.E (Hons.) Computer Science
 BITS-Pilani
 Github http://www.github.com/bhargavgolla |
 LinkedINhttp://www.linkedin.com/in/bhargavgolla
 | Website http://www.bhargavgolla.com/
 
 
 On Fri, Sep 6, 2013 at 1:10 PM, Dan Haywood 
 d...@haywood-associates.co.ukwrote:
 
 Hi Bhargav,
 thanks for doing this, you've been making good progress.
 One thing though... the caption at the bottom obscures the toastr
 notifications.  Could you redo that bit and upload a new version of the
 screencast?
 Also, perhaps you could rework the captions so that they change, and
 identify what is being demonstrated.  It can be a little hard to follow
 as
 it stands.
 Thx
 Dan
 
 
 
 On 5 September 2013 20:15, Bhargav Golla bhargav.go...@gmail.com
 wrote:
 
 Hello
 
 I have uploaded the updated screencast on youtube. Viewer gets object's
 collections and performs actions on objects (apart from Add/Remove
 Dependency, which is part of this sprint). You can find the same
 here[1].
 
 [1] http://youtu.be/Y5eVBY4Kh1s
 
 Regards
 Bhargav Golla
 Developer. Freelancer.
 B.E (Hons.) Computer Science
 BITS-Pilani
 Github http://www.github.com/bhargavgolla | LinkedIN
 http://www.linkedin.com/in/bhargavgolla
 | Website http://www.bhargavgolla.com/
 

Re: [DISCUSSION] next gen viewer

[GESCONSULTOR - Óscar Bou]

First of all, the meeting is a great idea ! 
Count, at least, with me... On those dates, perhaps one mate can join.

Regarding the UI, I'm also a big fan of bootstrap. As there's a clear 
distinction between code and themes, and with such high adoption, in the future 
we will be able to change the UI appearance  easily (for selling software 
that's a really important point, competing with packages with similar 
functionalities). 

Regarding the tab metaphor, we are using it together with modal forms (in 
excess, I would say... And as we don't have a modern theme right now seems 
a bit updated; that was also a plus for the wicket migration to bootstrap :-).

We like the SPA metaphor, but a proper mechanism for navigating and bookmarking 
an entity's form or action form is needed. 

Seeing the Spiro screenshots, the navigation metaphor, including the  + , 
seems a good idea, but as it's opening the linked entity to the right (on 
current screenshots) instead of directly opening the entity's page (or SPA 
form), I'm not sure about user-adoption. It also requires the right part of the 
screen (on those screenshots) to be empty, in order to show it. 

Perhaps there's a slight variation that could adapt better to user expectations 
and screen size. When first clicked, the entity could show on a modal form (not 
loosing the main context). In that modal form the  +  button would be 
available and, when clicked, it would changed the context by closing the 
modal form and opening on the main screen that entity's form - or action form -.

Not sure... Perhaps some user-adoption tests needed :-)


Regards,

Oscar



El 07/09/2013, a las 10:25, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Breaking this out to a new thread...
 
 ~~~
 Over the last few days I've (coincidentally) been having off-list
 discussions with both Maurizio and Jeroen, thinking about what the next gen
 viewer should be implemented and might look like.
 
 We're all agreed, I think, that it should be a stateless RO-based viewer,
 and that it should build on Spiro [1].
 
 In other words, the next gen viewer will be an SPA app, with AngularJS
 underneath, making RESTful calls to the Isis-provided backend.  The SPA app
 would (as they all do) use some sort of templating framework and widget
 framework for generate the GUI.  For the latter, I think that Bootstrap is
 a candidate (though Jeroen didn't agree, I think).
 
 Although (hopefully) scalable to the internet, the intent should still
 primarily be for problem solvers, not process followers, ie for those who
 are familiar with the domain.
 
 What that implies is solving the modality problem; allowing the user to
 switch context and to associate different contexts.  The original DnD
 viewer - whatever other faults it might have had - was very good at
 supporting this, with its desktop (windowed) metaphor.  Adam Howard's
 (currently stagnant) AROW viewer [2] also adopts a desktop metaphor.
 
 At the other end of the spectrum, my Wicket viewer is very page oriented.
 This means that the user looks only at one object at a time.  The
 autocomplete stuff makes it easier to associate stuff, and the bookmarks
 panel helps provide some sense of context, but I'm the first to admit that
 the Wicket viewer is closer to a website than an webapp.
 
 Maurizio's DHTMLX viewer is more page oriented [3], but the use of tabs
 does go a long way to mitigating this.  I probably should acknowledge that
 tabs is a better metaphor for helping the user to maintain context than the
 sliding bookmarks I've implemented in the Wicket viewer.
 
 Anyway... no work on a new RO viewer is going to happen this side of Xmas,
 but it might be worth arranging some sort of get together over a offsite
 weekend (in Europe, somewhere) to thrash out ideas.I'm thinking
 something like Mar~May next year (depending on how well Estatio beds in
 when it goes live).
 
 Let me know your thoughts, and whether you'd be interested in meeting up to
 discuss this (or any other Isis-related stuff, I suppose).
 
 Cheers
 Dan
 
 
 [1] https://github.com/nakedobjectsgroup/spiro
 [2] http://simple-dusk-6870.herokuapp.com/arow-fpc.html
 [3] http://isis-viewer-dhtmlx.appspot.com
 
 
 
 
 
 On 7 September 2013 09:03, GESCONSULTOR - Óscar Bou
 o@gesconsultor.comwrote:
 
 Just to clarify, the point is that our current viewer, based on Wavemaker,
 is implemented in DOJO, and we have all screen widgets composition code.
 
 As we must refactor the Isis session management, perhaps a good solution
 would be to re-use the js viewer code, but, as you pointed out, that will
 be better done on the future project with Stef and Richard.
 
 
 Thanks and keep the good work,
 
 Oscar
 
 
 
 El 06/09/2013, a las 22:47, GESCONSULTOR o@gesconsultor.com
 escribió:
 
 Yes, that was what I meant.
 
 Thanks!
 
 
 El 06/09/2013, a las 21:15, Bhargav Golla bhargav.go...@gmail.com
 escribió:
 
 I am sorry. I didn't exactly understand your question. Are you

Re: [DISCUSSION] next gen viewer

[GESCONSULTOR - Óscar Bou]

+1 To David   :-))


 
 With ISIS able to generate many viewers, then perhaps we are looking at
 the real game changer in the enterprise being ISIS.
 

Ooh, please keep saying that!  (Still hoping for one of the opinion formers
of the tech community - the Martin Fowlers etc - to rediscover NO via Isis
and take a similar view).





El 07/09/2013, a las 12:22, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 On 7 September 2013 11:02, GESCONSULTOR - Óscar Bou
 o@gesconsultor.comwrote:
 
 
 
 First of all, the meeting is a great idea !
 Count, at least, with me... On those dates, perhaps one mate can join.
 
 
 Good stuff... I thought you might be interested!
 
 
 
 
 Regarding the UI, I'm also a big fan of bootstrap. As there's a clear
 distinction between code and themes, and with such high adoption, in the
 future we will be able to change the UI appearance  easily (for selling
 software that's a really important point, competing with packages with
 similar functionalities).
 
 
 Yeah, themeability is important if Isis is to succeed as a framework.
 
 
 
 Regarding the tab metaphor, we are using it together with modal forms
 (in excess, I would say... And as we don't have a modern theme right
 now seems a bit updated; that was also a plus for the wicket migration to
 bootstrap :-).
 
 We like the SPA metaphor, but a proper mechanism for navigating and
 bookmarking an entity's form or action form is needed.
 
 
 The ideal might be to find some way of combining the hierarchical grouping
 capability of the sliding bookmark panel with the accessibility of the
 tabs.  Perhaps each tab is the root aggregate, but lets the user select any
 object within the aggregate.
 
 These are the sort of ideas we should kick around in a face-to-face meetup.
 
 
 
 Seeing the Spiro screenshots, the navigation metaphor, including the  +
 , seems a good idea, but as it's opening the linked entity to the right
 (on current screenshots) instead of directly opening the entity's page (or
 SPA form), I'm not sure about user-adoption. It also requires the right
 part of the screen (on those screenshots) to be empty, in order to show it.
 
 Perhaps there's a slight variation that could adapt better to user
 expectations and screen size. When first clicked, the entity could show on
 a modal form (not loosing the main context). In that modal form the  + 
 button would be available and, when clicked, it would changed the context
 by closing the modal form and opening on the main screen that entity's form
 - or action form -.
 
 Not sure... Perhaps some user-adoption tests needed :-)
 
 
 Yeah, coming up with a usable generic UI is non-trivial, irrespective of
 the actual technologies used.
 
 They are going to be doing some more work on Spiro soon; that might come up
 with some more ideas.
 
 Cheers
 Dan
 
 
 
 
 Regards,
 
 Oscar
 
 
 
 El 07/09/2013, a las 10:25, Dan Haywood d...@haywood-associates.co.uk
 escribió:
 
 Breaking this out to a new thread...
 
 ~~~
 Over the last few days I've (coincidentally) been having off-list
 discussions with both Maurizio and Jeroen, thinking about what the next
 gen
 viewer should be implemented and might look like.
 
 We're all agreed, I think, that it should be a stateless RO-based viewer,
 and that it should build on Spiro [1].
 
 In other words, the next gen viewer will be an SPA app, with AngularJS
 underneath, making RESTful calls to the Isis-provided backend.  The SPA
 app
 would (as they all do) use some sort of templating framework and widget
 framework for generate the GUI.  For the latter, I think that Bootstrap
 is
 a candidate (though Jeroen didn't agree, I think).
 
 Although (hopefully) scalable to the internet, the intent should still
 primarily be for problem solvers, not process followers, ie for those
 who
 are familiar with the domain.
 
 What that implies is solving the modality problem; allowing the user to
 switch context and to associate different contexts.  The original DnD
 viewer - whatever other faults it might have had - was very good at
 supporting this, with its desktop (windowed) metaphor.  Adam Howard's
 (currently stagnant) AROW viewer [2] also adopts a desktop metaphor.
 
 At the other end of the spectrum, my Wicket viewer is very page oriented.
 This means that the user looks only at one object at a time.  The
 autocomplete stuff makes it easier to associate stuff, and the bookmarks
 panel helps provide some sense of context, but I'm the first to admit
 that
 the Wicket viewer is closer to a website than an webapp.
 
 Maurizio's DHTMLX viewer is more page oriented [3], but the use of tabs
 does go a long way to mitigating this.  I probably should acknowledge
 that
 tabs is a better metaphor for helping the user to maintain context than
 the
 sliding bookmarks I've implemented in the Wicket viewer.
 
 Anyway... no work on a new RO viewer is going to happen this side of
 Xmas,
 but it might be worth arranging some sort of get together over a offsite

Re: Using JDO helper methods to check existence of an object for a test

[GESCONSULTOR - Óscar Bou]

I've just been thinking about a way to avoid to define a Spec Transformer for 
every Entity class in the Domain.

As it's just infrastructure software, I thought that was just enough. 

The attached code allows to use just one Spec Transformer when the Glue is 
written like this:
-  the employee with name PETER
- the employee named PETER
- the property with reference REF-001
- the property referenced REF-001
- the product with id PR-001 

From there, we know that:
- The Entity singular name is employee (so it can be obtained from the Isis 
Object Specifications, reinforcing the Ubiquitous Language use on BDD 
specifications).
- We must search by name
- The name must be PETER



For using it, I must define a Glue like this one:

Define a Glue like this one:
@When(The company (employee with name \[^\]*\) has a role assigned)
public void 
the_company_employee_with_name(@Transform(GenericIsisJdoTransformer.class) 
final  Employee employee) {
   ...
}



First proof-of-concept code version follows this text.

It can be improved in many ways, for allowing customization through 
inheritance, avoiding JDO through the use of the Apache Isis query methods, etc.


But I would let you know, right to know if you think it can be useful. 

On this way, the only implemented classes  are the ones supporting the Glues 
(and only the Spec Transformers for more specific use cases).


HTH, 

Oscar





-




package com.xms.framework.testing.integration.spectransformers;

import java.util.HashMap;
import java.util.Map;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

import javax.jdo.Query;

import org.opensaml.artifact.InvalidArgumentException;

import org.apache.isis.applib.DomainObjectContainer;
import org.apache.isis.core.metamodel.spec.ObjectSpecification;
import org.apache.isis.core.runtime.system.context.IsisContext;
import org.apache.isis.core.specsupport.scenarios.ScenarioExecution;
import 
org.apache.isis.objectstore.jdo.datanucleus.service.support.IsisJdoSupportImpl;

/**
 * Requires the Gherkin's capture in the format '([entitySingularName] [(.+?)
 * name(d)|(.+?) reference|(.+?) id] \[entityId]\)'.
 * p
 * For example:
 * ul
 * lithe employee with name PETER/li
 * lithe employee named PETER/li
 * lithe property with reference REF-001/li
 * lithe property referenced REF-001/li
 * lithe product with id PR-001/li
 * /ul
 * p
 * For matching the first one we will need the following Gherkin regular
 * expression:
 * ul
 * li
 * \\@When(The company's (employee with name \[^\]*\) has a role 
assigned)/li
 * /ul
 * p
 * From there, we know that:
 * ul
 * liThe Entity singular name is employee./li
 * liWe must search by name/li
 * liThe name must be PETER/li
 * /ul
 * 
 */
public class GenericIsisJdoTransformer extends 
NullRecognizingTransformerObject {

private static MapString, ObjectSpecification 
specificationsBySingularName;

/**
 * Tries to obtain the Entity class name, id and search field from the
 * Cucumber capture, and find it on the JDO Object Store.
 * 
 * @see com.xms.framework.testing.integration.spectransformers.
 *  NullRecognizingTransformer#transformNonNull(java.lang.String)
 */
@Override
protected Object transformNonNull(final String capture) {

return this.findFromCapture(capture);

}

/**
 * @param entityName
 *Name of the Entity specified on the Gherkin's capture.
 * @return
 */
private ObjectSpecification specificationOf(final String entityName) {

if (IsisJdoTransformer.specificationsBySingularName == null) {
IsisJdoTransformer.specificationsBySingularName = new 
HashMapString, ObjectSpecification();

for (final ObjectSpecification current : 
IsisContext.getSpecificationLoader().allSpecifications()) {


IsisJdoTransformer.specificationsBySingularName.put(current.getSingularName().toLowerCase(),
 current);
}

}
return 
IsisJdoTransformer.specificationsBySingularName.get(entityName.toLowerCase());

}

private final Class? entityClassFrom(final String capture) {

// The Entity Id will be between .
String entityName = ;

final String[] recognizedPatterns = { ( with name ), ( named ), ( 
with reference ), ( referenced ), ( with id ) };

for (final String currentPattern : recognizedPatterns) {
final Pattern p = Pattern.compile(currentPattern);
final Matcher m = p.matcher(capture);
if (m.find()) {
entityName = capture.substring(0, m.start());
break;
}
}

if (entityName == ) {
throw new InvalidArgumentException(String.format(Cannot find the 
entity's name on the capture %s. The format must be '([entitySingularName] 
[with name|with reference|named|referenced] \[entityId]\)', capture));
}

final ObjectSpecification specification = 

Re: Isis session and transaction management on a custom viewer

[GESCONSULTOR - Óscar Bou]

Thanks for the detailed explanation and the links to those resources. 

As we currently have an Apache Isis integration with our viewer, we knew the 
high-level structure, but it needs to be improved (experiencing some session 
or transaction management problems that originated the request).

We are interfacing Isis only through generic repositories (responsible of 
generating screens, etc.) and a generic action execution service (that finds 
the proper Object Specification, etc.). We are obtaining the proper choices, 
default values, hidden state, (not auto-complete by now; at most in 2 weeks), 
etc.

With the provided information we expect to being able to solve those session 
handling problems.

We will look at them in detail, and come here if any doubt is raised.

Thanks again,

Oscar



El 05/09/2013, a las 15:52, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Hi Oscar,
 apols for the delay in replying on this; within...
 
 And, I'm cc'ing this to dev@i.a.o; I think it belongs there better.
 
 Dan
 
 On 26 August 2013 15:45, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.comwrote:
 
 [snip]
 ... we have some questions about current design:
 
 1.- Stateful (Wicket) vs Stateless (RestFul Objects): why the Wicket
 viewer needs to hold the state,
 
 
 The Apache Wicket framework is stateful, that's just the way it is.  In
 fact, it's one of the principles of the framework to handle this [2].  One
 needs to be aware of this [3].
 
 
 from an Apache Isis perspective? Just to hold the current user context
 information?
 
 
 No, more than this.  Every component (widget) in the page is backed by a
 Wicket model (LoadableDetachableModel); these must be serializable because
 they are stored in the session.  Isis entities are not serializable (nor
 would we want them to be), but the OIDs are (eg TODO|123).   Isis handles
 this by providing mementos (for entity, property, collection, action,
 parameter).  Thus, EntityModel is a Wicket model that wraps an
 ObjectAdapterMemento.
 
 But, yes, Isis itself does also have a session which represents the current
 user.  This is its
 org.apache.isis.core.commons.authentication.AuthenticationSession.  Isis
 delegates to Wicket to store this for it in the HttpSession; this is done
 through 
 org.apache.isis.viewer.wicket.viewer.integration.wicket.AuthenticatedWebSessionForIsis
 (IsisWicketApplication#getWebSessionClass).  By this, Wicket keeps track of
 the user making the request.
 
 If using Isis' Shiro integration for authenticaiotn/authorizatino, then
 there are also Shiros session management to consider [4].  I am pretty sure
 the default for that is also HttpSession, but it would seem to be pluggable
 and they say it supports clusters [5].
 
 
 
 
 Why to choose for other webapps integrating with Isis the stateful design,
 instead of the - more scalable - stateless design?
 
 
 Umm.  As [3] says, Wicket's reliance on session management means it
 wouldn't be suitable for an Amazon scale website.  But I believe it's an
 appropriate technology for a typical enterprise app (that might use a farm
 of clustered servers for big deployments).
 
 Restful Objects in contrast is deliberately stateful.  There is still the
 user identity issue to contend with, but that's pluggable.  I hope that
 someone (who knows more about this than me) might help work through an
 oauth or equivalent implementation.  My understanding (I'm by no means a
 security expert on this) is that these solutions are scalable because the
 user credentials ultimately are stored in HTTP headers (encrypted suitably,
 of course, according to the oauth protocols etc etc).
 
 
 
 2.- Is there any class we can inherit from for stateless or stateful
 clients, that will be maintained in the future, as Apache Isis evolve, that
 takes care of web session handling, security (shiro) session, transaction
 management, etc. ? Perhaps we can inherit from classes currently existing
 on the Wicket viewer (or the Restful Objects viewer).
 
 
 Look at the classes above as a start point, see if you can untangle them.
 
 There is a ticket to better integrate Shiro and Wicket [6].  Right now we
 logout of the Wicket viewer by invalidating Wicket's authentication
 session.  However, Shiro doesn't know about this, so it preserves its
 sessions.  We do (seemingly) still get the behaviour we want, but
 improvements could be made here.
 
 
 
 
 
 3.- Is there any other point we must take into account with this approach
 - the custom viewer interacting with the Apache Isis domain - ?
 
 
 The biggest immediate risk is that you get the scoping wrong.  There is a
 reasonably clear separation of scopes; see ApplicationScopedComponent,
 SessionScopedComponent, TransactionalScopedComponent.  There's an old
 diagram I did [7] which shows this (it might be a bit out of date, but
 shows the general pattern).
 
 The biggest ongoing risk is that - because the API is not formally
 documented - that we change the code and break the custom

Re: Isis session and transaction management on a custom viewer

[GESCONSULTOR - Óscar Bou]

Hi, David.

Really interesting. This second  we plan to integrate with the CAS SSO platform 
the Isis domain, as detailed in [1]. 

Authentication in CAS, authorization in Domain, thanks to Shiro (and also on 
CAS on ). 

It would be helpful to know about your approach to logout and session timeout 
when you implement it. But in our case seems that CAS will manage that 
functionality, instead of Shiro.

Thanks,

Oscar



[1] http://shiro.apache.org/cas.html

El 06/09/2013, a las 12:52, David Tildesley davo...@yahoo.co.nz escribió:

 Hi Dan,
 
 Dan wrote:
 
 If using Isis' Shiro integration for authenticaiotn/authorizatino, then
 there are also Shiros session management to consider [4].  I am pretty sure
 the default for that is also HttpSession, but it would seem to be pluggable
 and they say it supports clusters [5].
 
 You're right. Played with this by co-incidence today. I think this default 
 causes some loss of useful Shiro features (deferring to the container). 
 Turned on Shiro native session manager today by simple property in 
 Shiro.ini as per Shiro documentation[4]. Works ok and adds more capability 
 (e.g. ability to define Shiro session event listener,define Shiro session 
 timeout, ...). We are leaning towards form based container based 
 authentication (already hooked Shiro into trusting container authentication 
 and leaving Shiro to do authorisation). Reason is that we are using container 
 authentication for NegotiateAssertion for enterprise desktop SSO (Kerberos) 
 and we make this a permanent feature and also  have a fall through 
 (SUFFICIENT)  AD ldap authenticator defined as next container 
 authentication provider - simply to make life easy for the testers. We hope 
 to log events off the Shiro session events (start, stop, ...) . But we've 
 still got work to do
 around this and the side affects (e.g. session timeout and logout 
 behaviour). 
 
 If  using native session manager then need to name the Shiro session cookie 
 something other than the default JSESSIONID because it causes weirdness when 
 the container also produces a session cookie of the same name.
 
 David.
 
 
 [2] http://wicket.apache.org/meet/introduction.html
 [3] http://www.jtict.com/blog/wicket-isnt-suited-for-websites/
 [4] http://shiro.apache.org/session-management.html
 [5] http://shiro.apache.org/web.html#Web-ServletContainerSessions
 [6] https://issues.apache.org/jira/browse/ISIS-299
 [7]
 https://github.com/apache/isis/blob/master/core/src/docbkx/guide-runtime-to-incorporate/images/architecture.png

Re: Conditional choices and defaults

[GESCONSULTOR - Óscar Bou]

Really nice feature, Dan.

There are a lot of use cases out there (including in our domain) that will 
benefit from it.

While executing a BDD tests, I noticed that the business rule that requires 
to only being able to select one of the possible choices was not forced for 
wrapped objects, so I understand that it's only currently forced by viewers.

So it's possible to assign to a wrapped action a param value that is not on the 
choices. I only achieved to force that by means of a validateXXX method, 
whose implementation included to verify that the param's value was on the 
Collection returned by the choicesXXX method.

As the choices and auto-complete param validations can be computationally 
expensive (requires querying the database and validating that the value is 
included on the returned resultset), and the same can happen to other business 
rules validations, it could be considered to create a new annotation named 
similar to @ValidationScope({DOMAIN, VIEWER, OBJECTSTORE}).

What do you think?

Thanks,

Oscar





El 23/08/2013, a las 19:40, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Folks,
 just to let you know of a new (rather overdue) feature that I've just
 committed [1], which is the ability to set up conditional choices and also
 defaults.
 
 Examples are:
 - category/subcategory... where the subcategory depends on the parent
 category, or
 - country/state ... where the state depends on the country.
 
 You can see an example of the first in Isis ToDo app [2], eg:
 
 public ToDoItem updateCategory(
final ToDoItem item,
final @Named(Category) Category category,
final @Named(Subcategory) Subcategory subcategory) {
item.setCategory(category);
item.setSubcategory(subcategory);
return item;
}
 
public Category default1UpdateCategory(
final ToDoItem item) {
return item.getCategory();
}
public Subcategory default2UpdateCategory(
final ToDoItem item) {
return item.getSubcategory();
}
 
public ListSubcategory choices2UpdateCategory(
final ToDoItem item, final Category category) {
return Subcategory.listFor(category);
}
 
 
 Note how the choices method now takes parameters; it can therefore see the
 current value of the category.
 
 Similarly, you can see an example fo the second in Estatio [3], eg:
 
public CommunicationChannelOwner newPostal(
final @Named(Owner) CommunicationChannelOwner owner,
final @Named(Type) CommunicationChannelType type,
final Country country,
final State state,
final @Named(Address Line 1) String address1,
final @Named(Address Line 2) @Optional String address2,
final @Named(Postal Code) String postalCode,
final @Named(City) String city) {
communicationChannels.newPostal(owner, type, address1, address2,
 postalCode, city, state, country);
return owner;
}
...
public CommunicationChannelType default1NewPostal() {
return choices1NewPostal().get(0);
}
public Country default2NewPostal() {
return countries.allCountries().get(0);
}
public ListState choices3NewPostal(
final CommunicationChannelOwner owner,
final CommunicationChannelType type,
final Country country) {
return states.findStatesByCountry(country);
}
public State default3NewPostal() {
return states.findStatesByCountry(default2NewPostal()).get(0);
}
 
 Here the type is an entity.
 
 ~~~
 When I was doing the checkin, I realized that I haven't implemented
 validation checking.  So I've descoped it.  It isn't actually an issue if
 you have choices, because it isn't possible to enter any other value
 anyway.  But in the more general case I can see this might be needed.  If
 anyone discovers a need, raise a new ticket.
 
 Cheers
 Dan
 
 
 [1] https://issues.apache.org/jira/browse/ISIS-478
 [2]
 https://github.com/apache/isis/blob/52bc369a0906a900fbbddf3cd7ae610d75b987a3/example/application/quickstart_wicket_restful_jdo/dom/src/main/java/dom/todo/ToDoItemContributions.java#L166
 [3]
 https://github.com/estatio/estatio/blob/3bb6e8d1a80b512a5fadf6a0f6268405a81cbbe8/dom/src/main/java/org/estatio/dom/communicationchannel/CommunicationChannelContributedActions.java#L71

Re: BDD - Domain Object property not validated after persist ?

[GESCONSULTOR - Óscar Bou]

Really nice. With those validations the power and expressiveness of the Isis 
domain classes will be really high!

I'll take a look at the implementation classes you mention on the ticket, and, 
specially, to the commit when available on git.

Regarding the constraint groups specification on JSR-349 [1], it's a really 
powerful feature. 
If Apache Isis ignore the groups that must be validated, we would force while 
persisting() the entity that all constraints are ok, while only the groups 
defined  by the user should be validated. 
Another problem it could introduced would be with database generated ids [2] 
annotated with @NotNull.

Instead, I think that Isis could follow an approach similar to the ones on the 
specification for JPA 2 [3] and/or Hibernate [4]. For the former, similar 
properties could be specify on the isis.properties file (or another one related 
to the object persistor), and for the former the hability to register 
validation listerners on the Isis lifecycle.

Hope this helps,

Oscar


[1] 
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#chapter-groups
[2] http://beanvalidation.org/proposals/BVAL-234/
[3] 
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#d0e5006
[4] 
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#validator-checkconstraints-orm-hibernateevent




El 13/08/2013, a las 09:18, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 On 6 August 2013 18:49, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.comwrote:
 
 For the last part of the email (property validation) I was just looking
 again at the JSR-349 specification, whose last version has just been
 approved and incorporated to Java 7.
 
 Seems that the reference implementation (Hibernate Validator) is Apache
 licensed [1].
 
 How should it be used within an Apache Isis domain implementation?
 
 I've raised a new ticket ISIS-491 [2] for this; the comments sketch out
 the implementation.
 
 
 
 
 
 [1]
 http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/
 
 [2] https://issues.apache.org/jira/browse/ISIS-491

Re: BDD - Domain Object property not validated after persist ?

[GESCONSULTOR - Óscar Bou]

] http://isis.apache.org/applib-guide/how-tos/about.html


El 06/08/2013, a las 08:15, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Oscar,
 
 You've convinced me... we should keep our entities consistent across the
 layers.  More discussion inline below
 Dan
 
 
 On 5 August 2013 17:00, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.comwrote:
 
 But I presume there was a reason that you put your call to
 AbstractXMSDomainObjectRepositoryAndFactory#.doFindByProp(...) in this
 closure.  Can you tell me explain further for me?
 
 
 The reason is that we are adapting our current viewer (user interface) to
 Isis. There is common functionality to all screens (such as filtering,
 searching, saving a domain object, refresh, etc.) that work with methods
 defined on a base repository (AbstractXMSDomainObjectRepositoryAndFactory).
 
 As all Isis interaction is made inside those methods, we surrounded all
 that logic within a Isis transaction, thinking that would allow as to avoid
 custom web session filters, etc.
 It was the closest place to the code interacting with Isis. Can you
 explain a bit the advantages about why should it be done on a higher
 layer - the web session - (perhaps if not done through a web session
 filter it can introduce some session management problems (seeing
 different object sets or different Isis sessions depending on the session
 returned by Tomcat - in different states/update time - , etc.).
 
 
 Part of the reason is in keeping the responsibilities of the various
 implementations consistent with each other.  The Wicket viewer and the RO
 viewer now both set up transactions before doing any work, in other words
 we are using session/transaction in view design.
 
 I only added the IsisTransactionFilterForRestfulObjects very recently;
 until then it was also relying on the lazy creation of transactions down in
 the PersistenceManager.   But what it also means is that any queries for
 objects are done without a transaction in place (I guess that the JDO/DN
 and/or the RDBMS creates one implicitly).  I could see in the future that
 we might want to allow the user to use isolation level 3 rather than level
 1, ie guarantee that a transaction exists and is present.
 
 
 
 
 
 At the moment we only ever apply such validation at the UI layer,
 mediating
 between the viewer layer and the domain object model/layer.
 
 This was not our expectation. And I think this is not the expected
 behavior in other validation frameworks. I'll further detail this.
 
 
 You've convinced me... we should keep our entities consistent across the
 layers.  I don't know that I really thought otherwise, was just aware that
 this was an area where the current implementation of Isis was less than
 ideal.
 
 [snip]
 
 
 So, at least, I could expect:
 - After any action execution, all domain objects are in compliance with
 all defined invariants.
 - During action execution, I could understand that objects are not
 conformant with invariants.
 - If a property is modified on a viewer, when the object changes are
 saved/persisted (sent to Isis and, through it, to the database) all
 invariants are in place.
 
 
 I've been mulling on how we can implement easily implement this.  I'm not
 sure that FrameworkSynchronizer is the right place, because that will be
 called multiple times throughout the xactn.  Instead, in IsisTransaction
 itself we have several enlistXxx() methods, already called by the JDO
 objectstore/FrameworkSynchronizer, originally added for auditing and
 publishing purposes.
 
 So, it seems it would be relatively trivial to additionally spin through
 all enlisted objects, and fire the validation checks on them, just prior to
 commit.  This would be a bit like a pre-commit trigger.
 
 Another benefit of this design is that we know that at this point JDO/DN
 will have locked these objects exclusively, so there is no chance of the
 objects being changed under our feet.
 
 I think this is what the ticket you've raised, ISIS-487, should now
 implement.
 
 
 
 
 If we were on a CQRS architecture, all property changes would be
 considered a command and the DDD domain invariants would be guaranteed
 before and after executing a command. And perhaps that would be the meaning
 of an Isis Transaction, differenciating it from a database transaction or
 an application layer transaction (such as in SAP, where it's referred as
 an operations requiring work in one or more than one views, as in a
 wizard)).
 
 
 I don't see an IsisTransaction as having a different scope to a database
 transaction; it's a single short-lived transaction in force for the
 duration of the invocation of an object action (or property edit).  But
 what it can/does provide is this ability to find the enlisted objects and
 do useful things to/with them.
 
 Appreciate you spending the time to make these arguments; good stuff.
 
 Dan

Re: BDD - Domain Object property not validated after persist ?

[GESCONSULTOR - Óscar Bou]

For the last part of the email (property validation) I was just looking again 
at the JSR-349 specification, whose last version has just been approved and 
incorporated to Java 7.

Seems that the reference implementation (Hibernate Validator) is Apache 
licensed [1].

How should it be used within an Apache Isis domain implementation?



[1] 
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/




El 06/08/2013, a las 19:10, GESCONSULTOR - Óscar Bou o@gesconsultor.com 
escribió:

 Thanks for your responses, Dan and Jeroen. Nice to be in such a responsive 
 environment :-)
 
 
 Part of the reason is in keeping the responsibilities of the various
 implementations consistent with each other.  The Wicket viewer and the RO
 viewer now both set up transactions before doing any work, in other words
 we are using session/transaction in view design.
 
 Ok. We've been working with Hibernate this way without problems. So it's a 
 design option. And clearly, as I was not sure about the Isis transaction 
 management implementation, I implemented the session-per-operation 
 antipattern [1].
 
 As we must implement the session in view for our own viewer (custom 
 Java-Spring-Dojo UI), is there any class we can reuse or inherit from? Or 
 should we copy-and-adapt the IsisTransactionFilterForRestfulObjects for 
 example?
 
 This same problem will be experienced by all the other viewers planned 
 (Javascript, DHTMLX, etc.) and also for anybody planning to integrate Isis 
 in their current applications, so it would be good for those use cases to 
 provide and support a generic session filter (similar to Spring's 
 OpenSessionInViewFilter, for example [2]), that is independent of the 
 implementation technology used by the viewer (only on a session).
 
 I've been mulling on how we can implement easily implement this.  I'm not
 sure that FrameworkSynchronizer is the right place, because that will be
 called multiple times throughout the xactn.  Instead, in IsisTransaction
 itself we have several enlistXxx() methods, already called by the JDO
 objectstore/FrameworkSynchronizer, originally added for auditing and
 publishing purposes.
 
 So, it seems it would be relatively trivial to additionally spin through
 all enlisted objects, and fire the validation checks on them, just prior to
 commit.  This would be a bit like a pre-commit trigger.
 
 Another benefit of this design is that we know that at this point JDO/DN
 will have locked these objects exclusively, so there is no chance of the
 objects being changed under our feet.
 
 I think this is what the ticket you've raised, ISIS-487, should now
 implement.
 
 I've seen those classes, and seems that it can be the correct way for this 
 use case (validating before persisting), but there's another point detailed 
 next that I don't have as clear.
 
 If we were on a CQRS architecture, all property changes would be
 considered a command and the DDD domain invariants would be guaranteed
 before and after executing a command. 
 
 
 I seems to me that with the previous solution Isis will work as expected when 
 executing an action. 
 
 But I have more doubts when changing properties. We could consider a change 
 in the value of a property a simple kind of action, inside a setter 
 method. But on Isis we also have other logic attached to a property change 
 (such as the validateXXX, hideXXX, disableXXX, etc.). 
 
 The first time we looked at Isis and read the How to add business rules 
 section [3], we thought that Isis generated a proxy with CGLIB and when the 
 setter was invoked from any point in the Domain layer code (an action's 
 code, a service programmatic method, etc), the Isis proxy firstly invoked the 
 hiddenXXX, disableXXX and validateXXX methods (as on a wrapped object), in 
 order to verify that the property change was valid.
 
 
 Basically, our expectations when working with code at the domain layer (such 
 as in the domain objects and services actions and programmatic methods, and 
 on BDD unit-integration tests) were that:
 - property change validation was done by intercepting/proxying the setter 
 call (avoiding the use of any modifyXXX methods).
 - domain object validation was done before committing to the database 
 (obviously, a user could always perform a custom validation by invoking the 
 proper container's method).
 
 The second one is the previously discussed one. But can we also expect the 
 first option - or something equivalent - ?
 
 If not implemented, the logic of the domain layer code would not respect 
 the validation rules defined with Isis, forcing the introduction of 
 modifyXXX, addToXXX, removeFromXXX, etc. methods (as in managed 
 relationships), and replacing the normal setter invocations with a custom 
 modifyXXX methods, for example, just with the purpose of preserving the 
 business rules. 
 If, by error, a user invokes directly the setter, the Isis validation logic 
 would not be executed, which could lead

Clearer messages for validation exceptions (specially MandatoryExceptions)

[GESCONSULTOR - Óscar Bou]

Hi to all.

We've made a small change on Isis applib that allows clearer messages for 
validation exceptions.

We wanted to move from this:

org.apache.isis.applib.services.wrapper.InvalidException: Mandatory
at 
org.apache.isis.core.wrapper.internal.DomainObjectInvocationHandler.toException(DomainObjectInvocationHandler.java:584)
at 
org.apache.isis.core.wrapper.internal.DomainObjectInvocationHandler.notifyListenersAndVetoIfRequired(DomainObjectInvocationHandler.java:556)
at 
org.apache.isis.core.wrapper.internal.DomainObjectInvocationHandler.handleActionMethod(DomainObjectInvocationHandler.java:506)
at 
org.apache.isis.core.wrapper.internal.DomainObjectInvocationHandler.invoke(DomainObjectInvocationHandler.java:236)
at 
org.apache.isis.core.wrapper.internal.InvocationHandlerMethodInterceptor.intercept(InvocationHandlerMethodInterceptor.java:37)
at 
com.xms.framework.risk.domain.model.RiskRegister$$EnhancerByCGLIB$$d42e255.addQuantitativeRiskToAsset(generated)
at 
com.xms.framework.risk.integration.glue.risk.RiskRegisterGlue.when_add_quantitative_risk_to_this_risk_register_with_asset_and_threat_and_likelihood_and_impact(RiskRegisterGlue.java:152)
at ✽.When I add a new quantitative risk to the risk register with name 
risk 1 and asset A1 and threat T1 and likelihood 0.50 and impact 
1000.00(com/xms/framework/risk/integration/specs/RiskAssessmentSpec_Risk_levelOfRisk.feature:56)


To something like this:

org.apache.isis.applib.services.wrapper.InvalidException: Source: 
com.xms.framework.risk.domain.model.RiskRegister@2012052f. Reason: Mandatory. 
Identifier: 
com.xms.framework.risk.domain.model.RiskRegister#addQuantitativeRiskToAsset(java.lang.String,java.lang.String,com.xms.framework.architecture.domain.model.Entity,com.xms.framework.risk.domain.model.threat.Threat,java.math.BigDecimal,java.math.BigDecimal).
 Position: 2. Proposed: null
at 
org.apache.isis.core.wrapper.internal.DomainObjectInvocationHandler.toException(DomainObjectInvocationHandler.java:584)
at 
org.apache.isis.core.wrapper.internal.DomainObjectInvocationHandler.notifyListenersAndVetoIfRequired(DomainObjectInvocationHandler.java:556)
at 
org.apache.isis.core.wrapper.internal.DomainObjectInvocationHandler.handleActionMethod(DomainObjectInvocationHandler.java:506)
at 
org.apache.isis.core.wrapper.internal.DomainObjectInvocationHandler.invoke(DomainObjectInvocationHandler.java:236)
at 
org.apache.isis.core.wrapper.internal.InvocationHandlerMethodInterceptor.intercept(InvocationHandlerMethodInterceptor.java:37)
at 
com.xms.framework.risk.domain.model.RiskRegister$$EnhancerByCGLIB$$d42e255.addQuantitativeRiskToAsset(generated)
at 
com.xms.framework.risk.integration.glue.risk.RiskRegisterGlue.when_add_quantitative_risk_to_this_risk_register_with_asset_and_threat_and_likelihood_and_impact(RiskRegisterGlue.java:152)
at ✽.When I add a new quantitative risk to the risk register with name 
risk 1 and asset A1 and threat T1 and likelihood 0.50 and impact 
1000.00(com/xms/framework/risk/integration/specs/RiskAssessmentSpec_Risk_levelOfRisk.feature:56)



We have created a new getReasonMessage() method on InteractionEvent as this:


public abstract class InteractionEvent extends EventObject {

.

/**
 * The reason message, if any, that this interaction may have been vetoed or
 * otherwise disallowed.
 * 
 * p
 * This message should be overridden by subclasses for containing the 
Reason, the Identifier and any other relevant context information.
 * 
 * @return
 */
public String getReasonMessage() {
if (this.getIdentifier() != null) {
return String.format(Reason: %s. Identifier: %s, this.getReason(), 
this.getIdentifier());
} else {
return String.format(Reason: %s, this.getReason());
}
}

.

}

And use that method to construct the InteractionException, instead of  
getReason():

public abstract class InteractionException extends ApplicationException {



 public InteractionException(final InteractionEvent interactionEvent) {
-super(interactionEvent.getReason());
+super(interactionEvent.getReasonMessage());
 this.interactionEvent = interactionEvent;
 }


}


Please, find a git patch attached.

Perhaps there are better ways to implement it. If needed we can create the Jira 
issue.


Thanks,

Oscar

 

Re: Managed relationships and Estatio

[GESCONSULTOR - Óscar Bou]

Thanks a lot, Dan.

Relationships are first-class Domain citizens, so this is really important :-)

Just a question related to yesterday's BDD implementation (really useful links 
on the documentation you wrote). If the relationships are going to be managed 
by DN, there could be a lot of @unit tests (all those where bidir relationships 
are used) that could fail, couldn't it ? 


Just to clarify it before refactoring, an example with the Agreement - Roles 
relationship would be refactored this way:

Agreement.java:

The relationship, field, getter and setter remains identical (with the same DN 
annotation):

 @javax.jdo.annotations.Persistent(mappedBy = agreement)
private SortedSetAgreementRole roles = new TreeSetAgreementRole();

@MemberOrder(name = Roles, sequence = 11)
@Disabled
@Render(Type.EAGERLY)
public SortedSetAgreementRole getRoles() {
return roles;
}

public void setRoles(final SortedSetAgreementRole actors) {
this.roles = actors;
}


Remove the following bidir contract methods:

 public void addToRoles(final AgreementRole agreementRole) {
// check for no-op
if (agreementRole == null || getRoles().contains(agreementRole)) {
return;
}
// associate new
getRoles().add(agreementRole);
agreementRole.setAgreement(this);
}

public void removeFromRoles(final AgreementRole agreementRole) {
// check for no-op
if (agreementRole == null || !getRoles().contains(agreementRole)) {
return;
}
// dissociate existing
getRoles().remove(agreementRole);
agreementRole.setAgreement(null);
}


AgreementRole.java:

No changes on field, getter, setter and annotations (despite the  
@javax.jdo.annotations.Column(name = AGREEMENT_ID)  is optional, just for 
changing the name of the generated table column, isn't it?):

 @javax.jdo.annotations.Column(name = AGREEMENT_ID)
private Agreement? agreement;

@Title(sequence = 3, prepend = :)
@MemberOrder(sequence = 1)
@Hidden(where = Where.REFERENCES_PARENT)
public Agreement? getAgreement() {
return agreement;
}

public void setAgreement(final Agreement? agreement) {
this.agreement = agreement;
}

Remove the bidir contract methods:

public void modifyAgreement(final Agreement? agreement) {
Agreement? currentAgreement = getAgreement();
// check for no-op
if (agreement == null || agreement.equals(currentAgreement)) {
return;
}
// delegate to parent to associate
if (currentAgreement != null) {
currentAgreement.removeFromRoles(this);
}
agreement.addToRoles(this);
}

public void clearAgreement() {
Agreement? currentAgreement = getAgreement();
// check for no-op
if (currentAgreement == null) {
return;
}
// delegate to parent to dissociate
currentAgreement.removeFromRoles(this);
}




So, basically, with just the field, getter, setter and required DN annotations 
on each side would be enough for production system and integration tests (if 
the collection is a Set or SortedSet), wouldn't it?

As I told at the beginning, also for unit tests? It would avoid to load all DN 
stuff. I've seen your InMemoryDB class and the blog post commenting about it, 
but still not sure about if it's going to be enough for testing Domain behavior 
/ actions. 

As you are currently making the tests on Estatio, which kind of tests must be 
done as @integration with current Isis implementation, and for which ones the 
faster @unit scope can be used?


We are going to start to make some tests regarding relationships (including 1-1 
relationships, with needed flush() in our previous tests). I'll keep you 
informed.


Thanks,

Oscar






El 17/07/2013, a las 08:20, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 On 15 July 2013 12:42, Dan Haywood d...@haywood-associates.co.uk wrote:
 
 
 On 12 July 2013 10:27, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.comwrote:
 
 
 
 
 Please, what do you think? If you are not in favor of implementing
 managed relationships, what are the reasons in order to properly understand
 it?
 
 
 [snip]
 rather than get Isis to do this, perhaps all we need to do is to figure
 out a way to make JDO do the heavy lifting for us.  All the JDO docs [4]
 are a little confusing, it does seem to me that the combination of using
 Sets/SortedSets and calling DOC#flush() ought to do the trick.
 
 Could you do some experiments on that and report back?
 
 
 
 Just wanted to follow up on this.  In writing the Agreement#addRole BDD
 specs for Estatio, I hit an issue with one of them [5] whereby I appeared
 to get duplicate AgreementRole's in the Lease's roles collection.  You can
 reproduce this issue by changing the setXxx() to modifyXxx() in [6], and
 also by commenting out the nextTransaction() method in [7

Re: Managed relationships and Estatio

[GESCONSULTOR - Óscar Bou]

 
 Agreed, some unit tests may break (see my notes above).
 
 Given that relationships are always modified through actions, I am
 considering adding in additional code, clearly marked as being just for
 unit tests... something like:
 
 setAgreement(agreement);
 // for unit tests only; JDO will automatically maintain this
 if(!agreement.getRoles().contains(this)) { agreement.getRoles().add(this); }
 
 It's ugly, I know, but I think I'd rather one line of commented ugliness
 than all the noise of those helper methods.
 
 
 


Instead of modifying each Domain Entity, perhaps some reflection hack on the 
unit tests? I don't know the internals, not sure how this could be achieved and 
the effort required. If not possible, I would prefer to add those conditions to 
the tests.


Regarding duplication of the same object on a DN Set under some 
circumstances, the SortedSet is descending from Set, so it's curious... I don't 
know DN implementation internals neither, but, could it be a problem with 
equalTo, compare, etc contracts? It's just so strange...


All tests by now seem to work ok with just DN annotations, managing DN all 
bidir relationships. There are still some pending (we have migrated to the 
latest Isis snapshot). If anything changes, I will properly inform.








El 17/07/2013, a las 10:21, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 I'm mailing this to users@i.a.o and cc'ing to dev@i.a.o, because it's
 relevant to all, I think.
 
 
 
 On 17 July 2013 08:28, GESCONSULTOR - Óscar Bou o@gesconsultor.comwrote:
 
 
 Just a question related to yesterday's BDD implementation (really useful
 links on the documentation you wrote). If the relationships are going to be
 managed by DN, there could be a lot of @unit tests (all those where bidir
 relationships are used) that could fail, couldn't it ?
 
 
 Yup, that's true I think.  I've just been through Estatio to remove these
 helpers.  There were one or two unit tests that broke... that's probably
 more an indication that we don't have nearly enough coverage yet.
 
 What I did in the unit tests - in the given portion - is explicitly set
 both sides of the relationship; see for example [1].
 
 In one case [2] I had to remove an assert because the other side is not
 maintained automatically (more on this below)
 
 I deleted one test [3] that is now tested through the BDD spec.
 
 
 
 
 Just to clarify it before refactoring, an example with the Agreement -
 Roles relationship would be refactored this way:
 
 Agreement.java:
 
 The relationship, field, getter and setter remains identical (with the
 same DN annotation):
 [snip]
 
 Remove the following bidir contract methods:
 
 public void addToRoles(final AgreementRole agreementRole) {
 }
 
public void removeFromRoles(final AgreementRole agreementRole) {
}
 
 correct.
 
 
 
 
 AgreementRole.java:
 
 No changes on field, getter, setter and annotations (despite the
 @javax.jdo.annotations.Column(name = AGREEMENT_ID)  is optional, just
 for changing the name of the generated table column, isn't it?):
 
 
 correct.
 
 
 
 [snip]
 
 
 Remove the bidir contract methods:
 
 public void modifyAgreement(final Agreement? agreement) {
}
 
public void clearAgreement() {
}
 
 correct.
 
 
 
 
 
 
 So, basically, with just the field, getter, setter and required DN
 annotations on each side would be enough for production system and
 integration tests (if the collection is a Set or SortedSet), wouldn't it?
 
 
 correct.
 
 
 
 
 As I told at the beginning, also for unit tests?
 
 
 
 Agreed, some unit tests may break (see my notes above).
 
 Given that relationships are always modified through actions, I am
 considering adding in additional code, clearly marked as being just for
 unit tests... something like:
 
 setAgreement(agreement);
 // for unit tests only; JDO will automatically maintain this
 if(!agreement.getRoles().contains(this)) { agreement.getRoles().add(this); }
 
 It's ugly, I know, but I think I'd rather one line of commented ugliness
 than all the noise of those helper methods.
 
 
 
 
 It would avoid to load all DN stuff. I've seen your InMemoryDB class and
 the blog post commenting about it, but still not sure about if it's going
 to be enough for testing Domain behavior / actions.
 
 
 That class is just a utility, something I knocked up as a way to set up
 mock service/repo expectations.  I don't think it has any impact on this
 discussion
 
 
 
 As you are currently making the tests on Estatio, which kind of tests must
 be done as @integration with current Isis implementation, and for which
 ones the faster @unit scope can be used?
 
 
 for now, I'm just focusing on writing @integration specs.  I know that puts
 me in conflict with JBRainsberger [4], but it mitigates the risk of
 misunderstanding what JDO/DN is doing under the hood.
 
 What I have found is that, with an @integration spec passing, then when I
 change the tag to @unit, JMock gives me useful information

Re: Estatio has been open sourced...

[GESCONSULTOR - Óscar Bou]

Thanks a lot and Congratulations! 

Nice way to start a week: a fully open-source application made with Isis and 
BDD implementation.

In my case, compiling against latest snapshot of Isis and the Estatio webapp 
has a dependency management problem regarding the SQL SERVER driver (should be 
commented):

- estatio-webapp/pom.xml: 
profile
idm2e/id
activation
!-- if running in Eclipse, this profile makes the SQL Server 
JDBC available on classpath (nb: driver must be manually installed to local 
repo manually using mvn install-file) --
property
namem2e.version/name
/property
/activation
dependencies
!-- dependency --
!-- groupIdcom.microsoft.sqlserver/groupId --
!-- artifactIdjdbc/artifactId --
!-- version4.0/version --
!-- /dependency --
/dependencies
/profile



I'm now in a hurry but will fully execute it after.

Thanks again,

Oscar









El 15/07/2013, a las 14:06, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Folks,
 
 You might be interested to know that Estatio, the application that Jeroen
 and I have been working on part-time for the last 12 months, has been open
 sourced under ASLv2.
 
 Jeroen has far deeper domain knowledge in this area than I, and has written
 the majority of the app; most of my time over the last 12 months has been
 devoted to enhancing Isis in support of this app.  As such, we now have the
 JDO objectstore, the Wicket viewer, Shiro security, and lots of supporting
 changes in Isis core.  In that time we've also seen Isis graduate as a
 top-level project, get a new website and extensive docs, be repackaged in a
 more modular fashion, and of course, took on Jeroen (and also Maurizio) as
 new committers.
 
 I should say that the app is still under development, and there are plenty
 of bugs and issues, but development is progressing well.  The plan is for
 this to go live in Nov; I suspect it will get some follow-on releases and
 enhancements after that.
 
 Anyway, you can take a look-see; the code is available up on github [1].
 If you get the time, let me know whether or not the thing builds and runs
 for you.
 
 If you look at the license files you'll see that the code is (c)
 Eurocommercial Properties NV [2].  This is Dutch estate management company
 who, by paying for Jeroen's and my development time, have been sponsoring
 Isis' development.  I'm immensely grateful to them for their support. It's
 possible that the ownership of the code might, in time, be spun off to some
 other legal entity. Nevertheless, once we've gone live I do intend to put
 some more permanent thanks to ECP on the website recognizing their huge
 contribution to Isis.
 
 I'm also hopeful that Estatio will become a reference application for Isis,
 demonstrating the sorts of apps that one can build with Isis.  Hopefully it
 also embodies some good practices for others to follow.
 
 Anyway, do take a look; any feedback welcome.
 
 [1] https://github.com/estatio/estatio
 [2] http://www.eurocommercialproperties.com/

Re: EventBusService ... opinions, please.

[GESCONSULTOR - Óscar Bou]

 the 
traditional approach is just better for me.


Hope this helps,

Oscar






El 30/06/2013, a las 15:55, Dan Haywood d...@haywood-associates.co.uk 
escribió:

 Hi Oscar,
 Thanks for these references.
 
 The key thing you said that's helped me was:
 
 All our Event Handlers are located on previously subscribed Services, so
 they will be in memory. If they need any Domain Object, they query the
 repositories on the event handler. Obviously, multiple Event Handlers can
 be registered for one kind of Event.
 
 That to me seems like the correct solution... don't have individual
 entities subscribing to events, instead have the domain service(s) act as
 the subscriber.  As you say, when an event is received, have the service
 identify the impacted domain entities and then call them.  That's such an
 obvious approach I feel a bit embarrassed for going down the wrong path.
 
 Anyway... I'm going to refactor the EventBusService and take out that
 subscriber loading/hint stuff.  And, then I'll implement a simplified
 version of the @PostsEvent annotation, also without the hint/loading stuff.
 
 ~~~
 With respect to Axon, I know you mentioned it before, and I took a look
 through its getting started guide.  There's rather a lot of boilerplate in
 there, which - I've always argued - is liable to slow down / inhibit the
 development of a ubiquitous language.  Since you use Axon, you can tell me
 if I'm mistaken in this or not.
 
 I don't know that the CommandHandler stuff in Axon makes much sense from an
 Isis standpoint; our RO viewer gives us something like that for free, I
 would've though.  Neither am I certain that an EventStore is the best
 persistence mechanism for the majority of enterprise apps that get built.
 But being able to raise events *does* make sense to me as a way of
 decoupling chunks of business logic; hence the EventBusService.
 
 Cheers
 Dan
 
 
 On 30 June 2013 11:38, GESCONSULTOR - Óscar Bou o@gesconsultor.comwrote:
 
 Opss!!! Let me resend it. The previous one did not contained the proper
 links.
 
 Just to clarify, when a Command has the @TargetAggregateIdentifier
 annotation on one of its fields, the Command Bus will previously load that
 Entity from the Repository and, after that, will invoke the command on that
 Entity. More details on [2].
 
 On the default implementation, the Domain Entity identifier field (which
 must be compared against the @TargetAggregateIdentifier) is also annotated
 with @AggregateIdentifier. The used Repository only needs a findById
 method for locating it and dispatch the command (it's also possible to
 query specifying also the expected version, but this is out of scope).
 
 
 Hope this helps again,
 
 Oscar
 
 
 
 
 
 Hi, Dan.
 
 I'm going to adopt your style of not mixing links with the post.
 
 We are currently using as our Domain Event Bus one of the implementations
 available on the Axon Framework [1].
 
 As it's a CQRS framework, there is a difference between Command Handlers
 and Event Handlers.
 
 All our Event Handlers are located on previously subscribed Services, so
 they will be in memory. If they need any Domain Object, they query the
 repositories on the event handler. Obviously, multiple Event Handlers can
 be registered for one kind of Event.
 
 For Command Handlers, it's possible to pass a field which contains the
 Aggregate Identifier (annotated with @TargetAggregateIdentifier), and also
 to annotate as a @CommandHandler a constructor method (if the command's
 responsibility is to create a Domain Entity). Note that only one Command
 Handler can be registered for each kind of command. If more than one is
 present, only the last one found will be notified by the Command Bus about
 the Command dispatched (detailed info on [2]).
 
 There is detailed documentation about Command Handlers [2] (including the
 interface for sending Commands) and Event Handlers [3] (they cannot be
 sent, just received) available.
 
 There's a new quickstart tutorial on Axon with a small example based also
 on a ToDo domain entity [4].
 
 Hope this helps,
 
 Oscar
 
 
 
 [1] http://www.axonframework.org/
 [2] http://www.axonframework.org/docs/2.0/command-handling.html
 [3] http://www.axonframework.org/docs/2.0/event-processing.html
 [4] http://www.axonframework.org/axon-2-quickstart-guide/
 
 
 
 El 30/06/2013, a las 10:38, Dan Haywood d...@haywood-associates.co.uk
 escribió:
 
 Folks,
 Looking for opinions here.
 
 I recently committed an EventBusService, so that one can programmatically
 post an event via Guava's EventBus:
 
 public void setStartDate(LocalDate dt) {
  this.setStartDate = dt;
  eventBusService.post(new StartDateChangedEvent(this, oldValue,
 newValue), getFoos(), getBars(), ...)
 }
 
 Guava then invokes any object that has a method annotated @Subscribe
 accepting the event type:
 
 @Subscribe
 public void handle(StartDateChangedEvent ev) { ... }
 
 It's trivially easy for domain objects to register themselves with the
 event bus