8:09 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
All,
I'm sorry if the solution is obvious, but I couldn't find anything
that would give me an appropriate solution for this.
Basically, I have a task that involves adding a new property to nodes
[1]. However, when I start GateIn with data generated by an instance
without the patch, I get some exceptions related to the fact that the
new field is not present on the data storage.
Naively, I would expect the JCR to automatically add this new field to
the nodes that don't have it yet (as it would be trivial to just
create this field if it's not present), but it seems it's not the
case. So, I checked the JCR documentation, and there doesn't seems to
be anything related to this scenario, except perhaps for section
1.9.5.3 (Changing or removing existing PropertyDefinition or child
NodeDefinition) [2]
It seems to me that this is a change on a running system, not a
"migration" scenario.
So, the question is: what is the proper way to add a new property to a
node without having problems with the old data?
1 -
https://github.com/jpkrohling/gatein-portal/commit/7627fef1ad6f484c29c8eb...
2 -
http://docs.jboss.org/exojcr/1.15.7-GA/developer/en-US/html_single/#JCR.N...
Thanks!
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS39E1AAoJECKM1e+fkPrXwWgH/3hcjzo+wBRgsi5UfdcJOEM5
HGZzE8+OKIDnUVbRVWdpxbEd4r+6HSggcNMx/FbMA6Y0MccCmgECh63rFC+6Xxci
U4/JhyVNJAFTlpCPTD2Jx+Ov8T1DU5x3HZu8SYFEVjQOIbTtVJk9IcT/g7O7xSNY
Q7FY6rdwMqHrQk6jRGOQ+U1BNx0gGdLk5yEcZow3NVqlUIzNtnCooTJxgFLlIA76
ejN4eynOC7i6KJPBS0SWXZEnVPaIxtxWhoAn+djRXVacgigBveamtdTNXJCkQPmv
waP4wAW79mM0HOK9MbFnankhF9tGOFArPqyc7zKopQh4y9ts3oPMPZ99Mt5EOAM=
=iwU2
-----END PGP SIGNATURE-----
8:32 a.m.
If you want to define a new property to a give node type you will indeed
have to do what you pointed out (
http://docs.jboss.org/exojcr/1.15.7-GA/developer/en-US/html_single/#JCR.N...),
it is not done automatically by the JCR as the default update policy used
is IGNORE_IF_EXIST and in your case you need REPLACE_IF_EXISTS as described
in the how to. So you will need do it manually and do it within the context
of the data migration.
Another approach would be to define a mixin type that only defines your
property and add this mixin type on demand to your nodes, this way the old
node type won't be modified
On Wed, Jan 22, 2014 at 2:09 PM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
All,
I'm sorry if the solution is obvious, but I couldn't find anything
that would give me an appropriate solution for this.
Basically, I have a task that involves adding a new property to nodes
[1]. However, when I start GateIn with data generated by an instance
without the patch, I get some exceptions related to the fact that the
new field is not present on the data storage.
Naively, I would expect the JCR to automatically add this new field to
the nodes that don't have it yet (as it would be trivial to just
create this field if it's not present), but it seems it's not the
case. So, I checked the JCR documentation, and there doesn't seems to
be anything related to this scenario, except perhaps for section
1.9.5.3 (Changing or removing existing PropertyDefinition or child
NodeDefinition) [2]
It seems to me that this is a change on a running system, not a
"migration" scenario.
So, the question is: what is the proper way to add a new property to a
node without having problems with the old data?
1 -
https://github.com/jpkrohling/gatein-portal/commit/7627fef1ad6f484c29c8eb...
2 -
http://docs.jboss.org/exojcr/1.15.7-GA/developer/en-US/html_single/#JCR.N...
Thanks!
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS39E1AAoJECKM1e+fkPrXwWgH/3hcjzo+wBRgsi5UfdcJOEM5
HGZzE8+OKIDnUVbRVWdpxbEd4r+6HSggcNMx/FbMA6Y0MccCmgECh63rFC+6Xxci
U4/JhyVNJAFTlpCPTD2Jx+Ov8T1DU5x3HZu8SYFEVjQOIbTtVJk9IcT/g7O7xSNY
Q7FY6rdwMqHrQk6jRGOQ+U1BNx0gGdLk5yEcZow3NVqlUIzNtnCooTJxgFLlIA76
ejN4eynOC7i6KJPBS0SWXZEnVPaIxtxWhoAn+djRXVacgigBveamtdTNXJCkQPmv
waP4wAW79mM0HOK9MbFnankhF9tGOFArPqyc7zKopQh4y9ts3oPMPZ99Mt5EOAM=
=iwU2
-----END PGP SIGNATURE-----
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
8:42 a.m.
is this change discussed or agreed somewhere ? or are you just working on a POC ?
Julien Viet
julienviet.com
On Wednesday 22 January 2014 at 15:32, Nicolas Filotto wrote:
If you want to define a new property to a give node type you will
indeed have to do what you pointed out
(http://docs.jboss.org/exojcr/1.15.7-GA/developer/en-US/html_single/#JCR.N...),
it is not done automatically by the JCR as the default update policy used is
IGNORE_IF_EXIST and in your case you need REPLACE_IF_EXISTS as described in the how to. So
you will need do it manually and do it within the context of the data migration.
Another approach would be to define a mixin type that only defines your property and add
this mixin type on demand to your nodes, this way the old node type won't be modified
On Wed, Jan 22, 2014 at 2:09 PM, Juraci Paixão Kröhling <jpkroehling(a)redhat.com
(mailto:jpkroehling@redhat.com)> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> All,
>
> I'm sorry if the solution is obvious, but I couldn't find anything
> that would give me an appropriate solution for this.
>
> Basically, I have a task that involves adding a new property to nodes
> [1]. However, when I start GateIn with data generated by an instance
> without the patch, I get some exceptions related to the fact that the
> new field is not present on the data storage.
>
> Naively, I would expect the JCR to automatically add this new field to
> the nodes that don't have it yet (as it would be trivial to just
> create this field if it's not present), but it seems it's not the
> case. So, I checked the JCR documentation, and there doesn't seems to
> be anything related to this scenario, except perhaps for section
> 1.9.5.3 (Changing or removing existing PropertyDefinition or child
> NodeDefinition) [2]
>
> It seems to me that this is a change on a running system, not a
> "migration" scenario.
>
> So, the question is: what is the proper way to add a new property to a
> node without having problems with the old data?
>
> 1 -
>
https://github.com/jpkrohling/gatein-portal/commit/7627fef1ad6f484c29c8eb...
>
> 2 -
>
http://docs.jboss.org/exojcr/1.15.7-GA/developer/en-US/html_single/#JCR.N...
>
> Thanks!
> Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJS39E1AAoJECKM1e+fkPrXwWgH/3hcjzo+wBRgsi5UfdcJOEM5
> HGZzE8+OKIDnUVbRVWdpxbEd4r+6HSggcNMx/FbMA6Y0MccCmgECh63rFC+6Xxci
> U4/JhyVNJAFTlpCPTD2Jx+Ov8T1DU5x3HZu8SYFEVjQOIbTtVJk9IcT/g7O7xSNY
> Q7FY6rdwMqHrQk6jRGOQ+U1BNx0gGdLk5yEcZow3NVqlUIzNtnCooTJxgFLlIA76
> ejN4eynOC7i6KJPBS0SWXZEnVPaIxtxWhoAn+djRXVacgigBveamtdTNXJCkQPmv
> waP4wAW79mM0HOK9MbFnankhF9tGOFArPqyc7zKopQh4y9ts3oPMPZ99Mt5EOAM=
> =iwU2
> -----END PGP SIGNATURE-----
>
_______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/gatein-dev
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/gatein-dev
8:48 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 01/22/2014 03:42 PM, Julien Viet wrote:
is this change discussed or agreed somewhere ? or are you just
working on a POC ?
As of now, it's just a branch in my own repository, based on a request
we've received via Bugzilla. Once it's done, I'll open a pull request,
but we can discuss it before that, if it's preferable.
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS39paAAoJECKM1e+fkPrXQPQH/2xrmhsWYYeNNxccbtw1gnnW
9i6OnH9zq3jS1t7V+BEM250NZRPQYnHUHDzJLnXNlwJhfWDOt3uJ8HcnYNCXJIqC
yC7sGlEh0eaqk45lp+eAu01L2SbkxpLu8rfoLoLwdstSGObX4PW8OrqniIRbXAEk
Wdg1aSwWFk3ZP6x2bLS7/Pe6v1MGH5W1XRHWIvVK5WgbfPmW7GCVN23UTjkNUG40
M3GLWl+ET/SGx8iI4b0xBDedr8HdXHoJM3zwz+WyMtvbWhiFCE8A8lWm/iP2JvLH
+4wb0G6N8kW61oRHybqQ6pWHJTUqLmFiLWM9X82As2uTrAB1reYekwxFKpEFUDI=
=JhtF
-----END PGP SIGNATURE-----
8:48 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 01/22/2014 03:32 PM, Nicolas Filotto wrote:
If you want to define a new property to a give node type you will
indeed have to do what you pointed out
(http://docs.jboss.org/exojcr/1.15.7-GA/developer/en-US/html_single/#JCR.N...),
it is not done automatically by the JCR as the default update policy
used is IGNORE_IF_EXIST and in your case you need REPLACE_IF_EXISTS
as described in the how to. So you will need do it manually and do
it within the context of the data migration.
Alright, sounds reasonable. Do you remember if/when/where this done in
the past? If so, it would help me a lot to have it as a reference.
Another approach would be to define a mixin type that only defines
your property and add this mixin type on demand to your nodes, this
way the old node type won't be modified
Considering that this would be for a node that is shipped with GateIn
itself, I'm not sure if this approach is desirable or recommended. But
if there's a precedent for this, I would also like to use it as a
reference.
Thanks!
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS39pHAAoJECKM1e+fkPrX+pIH/0vkol4dUoG4kTIZdKWp4s8C
d5pYrE9+lumicvty9kxSRnlQlaVJuauyjgYLh1gAkvi8SXryBd3t8nm6xqXMrm/9
53ErhUghvh0nRb73KJ3otfV43PWbxE8z4FP3IFl9sZllfp9KWtUp9/gU16RmIPxP
srpyy3RWvW9alFOn1lv34SX1sBXbc5WkZvAmD6H61KiX3xRwW2oncjfK18lUlBLF
CXzy3j2DD72QexN/u8FANRlno0eeetL1jJ16gL/ZJA85/pAlOW8OS/5v3+Ht0mlI
9D2sZF22reyCjl0AaFPSWH6B1VNBwjk5fRu/zCht/b3Za8oWyNWeIjL8KK9BDNA=
=XsmJ
-----END PGP SIGNATURE-----
9:21 a.m.
On Wed, Jan 22, 2014 at 2:48 PM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 01/22/2014 03:32 PM, Nicolas Filotto wrote:
> If you want to define a new property to a give node type you will
> indeed have to do what you pointed out
> (
http://docs.jboss.org/exojcr/1.15.7-GA/developer/en-US/html_single/#JCR.N...
),
>
>
it is not done automatically by the JCR as the default update policy
> used is IGNORE_IF_EXIST and in your case you need REPLACE_IF_EXISTS
> as described in the how to. So you will need do it manually and do
> it within the context of the data migration.
Alright, sounds reasonable. Do you remember if/when/where this done in
the past? If so, it would help me a lot to have it as a reference.
In our product PLF, we have an upgrade framework that manages everything
(if/when/where). In gatein, I don't think that you have anything that can
help you, I guess that the gatein team can tell you more.
> Another approach would be to define a mixin type that only defines
> your property and add this mixin type on demand to your nodes, this
> way the old node type won't be modified
Considering that this would be for a node that is shipped with GateIn
itself, I'm not sure if this approach is desirable or recommended. But
if there's a precedent for this, I would also like to use it as a
reference.
I don't get you when you say "be for a node that is shipped with
GateIn", I
don't see the relationship with a mixin type
Thanks!
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS39pHAAoJECKM1e+fkPrX+pIH/0vkol4dUoG4kTIZdKWp4s8C
d5pYrE9+lumicvty9kxSRnlQlaVJuauyjgYLh1gAkvi8SXryBd3t8nm6xqXMrm/9
53ErhUghvh0nRb73KJ3otfV43PWbxE8z4FP3IFl9sZllfp9KWtUp9/gU16RmIPxP
srpyy3RWvW9alFOn1lv34SX1sBXbc5WkZvAmD6H61KiX3xRwW2oncjfK18lUlBLF
CXzy3j2DD72QexN/u8FANRlno0eeetL1jJ16gL/ZJA85/pAlOW8OS/5v3+Ht0mlI
9D2sZF22reyCjl0AaFPSWH6B1VNBwjk5fRu/zCht/b3Za8oWyNWeIjL8KK9BDNA=
=XsmJ
-----END PGP SIGNATURE-----
9:25 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 01/22/2014 04:21 PM, Nicolas Filotto wrote:
> In our product PLF, we have an upgrade framework that manages
> everything (if/when/where). In gatein, I don't think that you
> have anything that can help you, I guess that the gatein team can
> tell you more.
Alright, I'll do some other experiments to see if I can manage a
migration "on-the-fly" for this case.
> Another approach would be to define a mixin type that only
> defines your property and add this mixin type on demand to your
> nodes, this way the old node type won't be modified
Considering that this would be for a node that is shipped with
GateIn itself, I'm not sure if this approach is desirable or
recommended. But if there's a precedent for this, I would also like
to use it as a reference.
> I don't get you when you say "be for a node that is shipped with
> GateIn", I don't see the relationship with a mixin type
I might be wrong, specially as this is the first time I deal with this
part, but I understand that a mixin would be something targeted to
developers hoping to extend GateIn, so that they won't need to deal
with the shipped types. In our case, we are shipping GateIn, so, we
can deal with those :-)
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS3+MCAAoJECKM1e+fkPrXEJ8IAJQGGxt/1FAP5nFbz1EZcFcI
wOzhgPnDuD5/ewolb4HU4mKirhJdpRvhjR9DZfjoIJ6pIA+vMpdK+kW2uLuYa+OY
//G/5BtQD4goHaVbOmj7WTW+QhqZnnkozyp+nEBUC22eYuSmIDOMtft4AoyFaTyW
bsnphYjf33Se5LrHYfKeDjma3gp0usO8pFxxWcKFajZIn/SUrE27MYmkMSAfZ6wO
7tf0NKZI9EpTdW4B0lOvsMUOWw8zXhK9gVlaWApxB1KSNyBhYvPoD1GOPJSOOaOz
5TcT2/xQcxtrzW6s09na273KBk9DOu8dOUjxCUWyNkmVn+Krb9n1YH04txkj+aE=
=XADL
-----END PGP SIGNATURE-----
10:12 a.m.
Hi Juca, this commit of mine used the mixin strategy:
https://github.com/gatein/gatein-portal/commit/0ee52c38823b2e3b6eaab3ee9a...
-- Peter
On 2014-01-22 16:25, Juraci Paixão Kröhling wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 01/22/2014 04:21 PM, Nicolas Filotto wrote:
>> In our product PLF, we have an upgrade framework that manages
>> everything (if/when/where). In gatein, I don't think that you
>> have anything that can help you, I guess that the gatein team can
>> tell you more.
Alright, I'll do some other experiments to see if I can manage a
migration "on-the-fly" for this case.
>> Another approach would be to define a mixin type that only
>> defines your property and add this mixin type on demand to your
>> nodes, this way the old node type won't be modified
>
> Considering that this would be for a node that is shipped with
> GateIn itself, I'm not sure if this approach is desirable or
> recommended. But if there's a precedent for this, I would also like
> to use it as a reference.
>
>> I don't get you when you say "be for a node that is shipped with
>> GateIn", I don't see the relationship with a mixin type
I might be wrong, specially as this is the first time I deal with this
part, but I understand that a mixin would be something targeted to
developers hoping to extend GateIn, so that they won't need to deal
with the shipped types. In our case, we are shipping GateIn, so, we
can deal with those :-)
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS3+MCAAoJECKM1e+fkPrXEJ8IAJQGGxt/1FAP5nFbz1EZcFcI
wOzhgPnDuD5/ewolb4HU4mKirhJdpRvhjR9DZfjoIJ6pIA+vMpdK+kW2uLuYa+OY
//G/5BtQD4goHaVbOmj7WTW+QhqZnnkozyp+nEBUC22eYuSmIDOMtft4AoyFaTyW
bsnphYjf33Se5LrHYfKeDjma3gp0usO8pFxxWcKFajZIn/SUrE27MYmkMSAfZ6wO
7tf0NKZI9EpTdW4B0lOvsMUOWw8zXhK9gVlaWApxB1KSNyBhYvPoD1GOPJSOOaOz
5TcT2/xQcxtrzW6s09na273KBk9DOu8dOUjxCUWyNkmVn+Krb9n1YH04txkj+aE=
=XADL
-----END PGP SIGNATURE-----
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
10 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
@Peter, @Nicolas: thanks for the help and insight, guys! I was able to
implement it and get the old data "migrated" (or, at least,
"accepted").
@Julien: do you want to discuss whether this feature would be accepted
into master? Should I send a PR, or would you prefer to review it on
my repository?
Here's the final diff:
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
Juca.
On 01/22/2014 05:12 PM, Peter Palaga wrote:
Hi Juca, this commit of mine used the mixin strategy:
https://github.com/gatein/gatein-portal/commit/0ee52c38823b2e3b6eaab3ee9a...
- -- Peter
On 01/22/2014 04:21 PM, Nicolas Filotto wrote:
Another approach would be to define a mixin type that only defines
your property and add this mixin type on demand to your nodes, this
way the old node type won't be modified
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS4TyVAAoJECKM1e+fkPrXwjwH/AzQUFi0lMAzfYMgwxxHNsAE
hp2XHRs76jWuRBWUm7IYn9e+XLBkNXHbznT/5sjag3rxqt1BHC08Jb5Bp+SJ5LdE
KqP8Y3Ziv11EcFfGVSrzSeRylxPkYh5iJApYfmC9oUqkHwwmoQ31h9tPXN3cnLpq
JUnFNFXvf+5pwzJ4kQGKJd+WtBNN29lremYr+rppe/YklEZFBzKDBHj31KcrzgGQ
+0XmjYrVXPaj0p3Hka9MPBmr1uoGDYKE49DrJ9kshGSsR8sELdOUbv+5BD+2VTqF
x+KJ5Jl11ze5IpXfTby0fcIhPUTqeyimyV8N4cbKqfW99RinakPJBlJT9Izu61c=
=auC7
-----END PGP SIGNATURE-----
10:27 a.m.
Hi Juca, PR or your branch does not matter to me, but could you please
squash all those commits into one so that reviewers can overview your
changes more easily? -- Peter
On 2014-01-23 17:00, Juraci Paixão Kröhling wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
@Peter, @Nicolas: thanks for the help and insight, guys! I was able to
implement it and get the old data "migrated" (or, at least,
"accepted").
@Julien: do you want to discuss whether this feature would be accepted
into master? Should I send a PR, or would you prefer to review it on
my repository?
Here's the final diff:
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
Juca.
On 01/22/2014 05:12 PM, Peter Palaga wrote:
> Hi Juca, this commit of mine used the mixin strategy:
>
https://github.com/gatein/gatein-portal/commit/0ee52c38823b2e3b6eaab3ee9a...
>
>
- -- Peter
On 01/22/2014 04:21 PM, Nicolas Filotto wrote:
> Another approach would be to define a mixin type that only defines
> your property and add this mixin type on demand to your nodes, this
> way the old node type won't be modified
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS4TyVAAoJECKM1e+fkPrXwjwH/AzQUFi0lMAzfYMgwxxHNsAE
hp2XHRs76jWuRBWUm7IYn9e+XLBkNXHbznT/5sjag3rxqt1BHC08Jb5Bp+SJ5LdE
KqP8Y3Ziv11EcFfGVSrzSeRylxPkYh5iJApYfmC9oUqkHwwmoQ31h9tPXN3cnLpq
JUnFNFXvf+5pwzJ4kQGKJd+WtBNN29lremYr+rppe/YklEZFBzKDBHj31KcrzgGQ
+0XmjYrVXPaj0p3Hka9MPBmr1uoGDYKE49DrJ9kshGSsR8sELdOUbv+5BD+2VTqF
x+KJ5Jl11ze5IpXfTby0fcIhPUTqeyimyV8N4cbKqfW99RinakPJBlJT9Izu61c=
=auC7
-----END PGP SIGNATURE-----
11:11 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 01/23/2014 05:27 PM, Peter Palaga wrote:
Hi Juca, PR or your branch does not matter to me, but could you
please squash all those commits into one so that reviewers can
overview your changes more easily? -- Peter
Sure thing, the squashed commits are now available as one commit, here:
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS4U1HAAoJECKM1e+fkPrXqlcIAJg0iUDyMulienr3r9FF+Tyu
IS9sch3/uEtqaD3jXFQNc5beKoKuegxCs4/x6B/a4W8Jum5SnhctjqIomcAScdR/
1OkX/hAQVNvFToqD9d0ExQ5y80SyH87eATQorT0hBixYIe2/s5qYvs1h/Jlvvtd9
vdfxgRZ3xiK29xZFoPErOjOkneTXETtIOybR79fBEuZfB1C0A9aY8BVO42Oz2DI2
cmmqRN6SiHIgeQbo//C1ke9AIKn5mJliQFuK+Xc4tj2jC69DCM8DCAy87ue9TCPD
h9uRk3pX4BfF0yIxLeO1ZvbhloJTRm7OCMhpH4KJJF5EoVwnctC1KQCwOWAIhCk=
=cnaR
-----END PGP SIGNATURE-----
11:23 a.m.
Is there a reason to use privateTillPublicationDate here but
restrictOutsidePublicationWindow elsewhere?
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
On 2014-01-23 18:11, Juraci Paixão Kröhling wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 01/23/2014 05:27 PM, Peter Palaga wrote:
> Hi Juca, PR or your branch does not matter to me, but could you
> please squash all those commits into one so that reviewers can
> overview your changes more easily? -- Peter
Sure thing, the squashed commits are now available as one commit, here:
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS4U1HAAoJECKM1e+fkPrXqlcIAJg0iUDyMulienr3r9FF+Tyu
IS9sch3/uEtqaD3jXFQNc5beKoKuegxCs4/x6B/a4W8Jum5SnhctjqIomcAScdR/
1OkX/hAQVNvFToqD9d0ExQ5y80SyH87eATQorT0hBixYIe2/s5qYvs1h/Jlvvtd9
vdfxgRZ3xiK29xZFoPErOjOkneTXETtIOybR79fBEuZfB1C0A9aY8BVO42Oz2DI2
cmmqRN6SiHIgeQbo//C1ke9AIKn5mJliQFuK+Xc4tj2jC69DCM8DCAy87ue9TCPD
h9uRk3pX4BfF0yIxLeO1ZvbhloJTRm7OCMhpH4KJJF5EoVwnctC1KQCwOWAIhCk=
=cnaR
-----END PGP SIGNATURE-----
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
11:33 a.m.
Sorry, Juca, I sent the previous message too early. But the point made
there is valid.
Further:
Have you consulted the English text with a native speaker? Jared is
probably the best address.
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
I see nothing else by merely looking at the code. I'll run it as a part
of the merge process.
Best,
Peter
On 2014-01-23 18:23, Peter Palaga wrote:
Is there a reason to use privateTillPublicationDate here but
restrictOutsidePublicationWindow elsewhere?
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
On 2014-01-23 18:11, Juraci Paixão Kröhling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 01/23/2014 05:27 PM, Peter Palaga wrote:
>> Hi Juca, PR or your branch does not matter to me, but could you
>> please squash all those commits into one so that reviewers can
>> overview your changes more easily? -- Peter
>
> Sure thing, the squashed commits are now available as one commit, here:
>
>
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
>
> Juca.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJS4U1HAAoJECKM1e+fkPrXqlcIAJg0iUDyMulienr3r9FF+Tyu
> IS9sch3/uEtqaD3jXFQNc5beKoKuegxCs4/x6B/a4W8Jum5SnhctjqIomcAScdR/
> 1OkX/hAQVNvFToqD9d0ExQ5y80SyH87eATQorT0hBixYIe2/s5qYvs1h/Jlvvtd9
> vdfxgRZ3xiK29xZFoPErOjOkneTXETtIOybR79fBEuZfB1C0A9aY8BVO42Oz2DI2
> cmmqRN6SiHIgeQbo//C1ke9AIKn5mJliQFuK+Xc4tj2jC69DCM8DCAy87ue9TCPD
> h9uRk3pX4BfF0yIxLeO1ZvbhloJTRm7OCMhpH4KJJF5EoVwnctC1KQCwOWAIhCk=
> =cnaR
> -----END PGP SIGNATURE-----
>
_______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
3:44 a.m.
I’m still wondering if/when that was agreed to modify the persistence of gatein.
did I miss something ?
Julien Viet
julienviet.com
On Thursday 23 January 2014 at 18:33, Peter Palaga wrote:
Sorry, Juca, I sent the previous message too early. But the point
made
there is valid.
Further:
Have you consulted the English text with a native speaker? Jared is
probably the best address.
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
I see nothing else by merely looking at the code. I'll run it as a part
of the merge process.
Best,
Peter
On 2014-01-23 18:23, Peter Palaga wrote:
> Is there a reason to use privateTillPublicationDate here but
> restrictOutsidePublicationWindow elsewhere?
>
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
>
> On 2014-01-23 18:11, Juraci Paixão Kröhling wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 01/23/2014 05:27 PM, Peter Palaga wrote:
> > > Hi Juca, PR or your branch does not matter to me, but could you
> > > please squash all those commits into one so that reviewers can
> > > overview your changes more easily? -- Peter
> > >
> >
> >
> > Sure thing, the squashed commits are now available as one commit, here:
> >
> >
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
> >
> > Juca.
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.0.22 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQEcBAEBCgAGBQJS4U1HAAoJECKM1e+fkPrXqlcIAJg0iUDyMulienr3r9FF+Tyu
> > IS9sch3/uEtqaD3jXFQNc5beKoKuegxCs4/x6B/a4W8Jum5SnhctjqIomcAScdR/
> > 1OkX/hAQVNvFToqD9d0ExQ5y80SyH87eATQorT0hBixYIe2/s5qYvs1h/Jlvvtd9
> > vdfxgRZ3xiK29xZFoPErOjOkneTXETtIOybR79fBEuZfB1C0A9aY8BVO42Oz2DI2
> > cmmqRN6SiHIgeQbo//C1ke9AIKn5mJliQFuK+Xc4tj2jC69DCM8DCAy87ue9TCPD
> > h9uRk3pX4BfF0yIxLeO1ZvbhloJTRm7OCMhpH4KJJF5EoVwnctC1KQCwOWAIhCk=
> > =cnaR
> > -----END PGP SIGNATURE-----
> >
_______________________________________________
> > gatein-dev mailing list
> > gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
> > https://lists.jboss.org/mailman/listinfo/gatein-dev
> >
>
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/gatein-dev
4:05 a.m.
Isn't it a purpose of this mailing list? Very recently we shared like 4
different spec or features ideas - before merging. This stuff is also
not merged yet.
We have a feature that we are working on and looking for ways of how to
accomplish it - as far as I understand this is the purpose of this
thread :)
W dniu 24/01/14 10:44, Julien Viet pisze:
I’m still wondering if/when that was agreed to modify the persistence
of
gatein.
did I miss something ?
Julien Viet
julienviet.com
On Thursday 23 January 2014 at 18:33, Peter Palaga wrote:
> Sorry, Juca, I sent the previous message too early. But the point made
> there is valid.
>
> Further:
> Have you consulted the English text with a native speaker? Jared is
> probably the best address.
>
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
>
> I see nothing else by merely looking at the code. I'll run it as a part
> of the merge process.
>
> Best,
>
> Peter
>
> On 2014-01-23 18:23, Peter Palaga wrote:
>> Is there a reason to use privateTillPublicationDate here but
>> restrictOutsidePublicationWindow elsewhere?
>>
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
>>
>> On 2014-01-23 18:11, Juraci Paixão Kröhling wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>>
>>> On 01/23/2014 05:27 PM, Peter Palaga wrote:
>>>> Hi Juca, PR or your branch does not matter to me, but could you
>>>> please squash all those commits into one so that reviewers can
>>>> overview your changes more easily? -- Peter
>>>
>>> Sure thing, the squashed commits are now available as one commit, here:
>>>
>>>
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
>>>
>>> Juca.
>>>
--
Bolesław Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2.0.22 (GNU/Linux)
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>
>>> iQEcBAEBCgAGBQJS4U1HAAoJECKM1e+fkPrXqlcIAJg0iUDyMulienr3r9FF+Tyu
>>> IS9sch3/uEtqaD3jXFQNc5beKoKuegxCs4/x6B/a4W8Jum5SnhctjqIomcAScdR/
>>> 1OkX/hAQVNvFToqD9d0ExQ5y80SyH87eATQorT0hBixYIe2/s5qYvs1h/Jlvvtd9
>>> vdfxgRZ3xiK29xZFoPErOjOkneTXETtIOybR79fBEuZfB1C0A9aY8BVO42Oz2DI2
>>> cmmqRN6SiHIgeQbo//C1ke9AIKn5mJliQFuK+Xc4tj2jC69DCM8DCAy87ue9TCPD
>>> h9uRk3pX4BfF0yIxLeO1ZvbhloJTRm7OCMhpH4KJJF5EoVwnctC1KQCwOWAIhCk=
>>> =cnaR
>>> -----END PGP SIGNATURE-----
>>>
_______________________________________________
>>> gatein-dev mailing list
>>> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/gatein-dev
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
4:26 a.m.
I was more thinking about :
- we have this idea to make this awesome feature
- oh great, what is it ?
- it’s blah blah
- and how would you handle this change in persistence ?
- we don’t know yet but we will likely need to modify the schema or something
- ok I see, we need to think about the best way etc…
instead of :
here is PR XYZ with feature implemented that changes schema, please validate
Julien Viet
julienviet.com
On Friday 24 January 2014 at 11:05, Bolesław Dawidowicz wrote:
Isn't it a purpose of this mailing list? Very recently we shared
like 4
different spec or features ideas - before merging. This stuff is also
not merged yet.
We have a feature that we are working on and looking for ways of how to
accomplish it - as far as I understand this is the purpose of this
thread :)
W dniu 24/01/14 10:44, Julien Viet pisze:
> I’m still wondering if/when that was agreed to modify the persistence of
> gatein.
>
> did I miss something ?
>
> Julien Viet
> julienviet.com (http://julienviet.com)
>
> On Thursday 23 January 2014 at 18:33, Peter Palaga wrote:
>
> > Sorry, Juca, I sent the previous message too early. But the point made
> > there is valid.
> >
> > Further:
> > Have you consulted the English text with a native speaker? Jared is
> > probably the best address.
> >
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
> >
> > I see nothing else by merely looking at the code. I'll run it as a part
> > of the merge process.
> >
> > Best,
> >
> > Peter
> >
> > On 2014-01-23 18:23, Peter Palaga wrote:
> > > Is there a reason to use privateTillPublicationDate here but
> > > restrictOutsidePublicationWindow elsewhere?
> > >
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
> > >
> > > On 2014-01-23 18:11, Juraci Paixão Kröhling wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA512
> > > >
> > > > On 01/23/2014 05:27 PM, Peter Palaga wrote:
> > > > > Hi Juca, PR or your branch does not matter to me, but could you
> > > > > please squash all those commits into one so that reviewers can
> > > > > overview your changes more easily? -- Peter
> > > > >
> > > >
> > > >
> > > > Sure thing, the squashed commits are now available as one commit,
here:
> > > >
> > > >
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
> > > >
> > > > Juca.
> > > >
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG v2.0.22 (GNU/Linux)
> > > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> > > >
> > > > iQEcBAEBCgAGBQJS4U1HAAoJECKM1e+fkPrXqlcIAJg0iUDyMulienr3r9FF+Tyu
> > > > IS9sch3/uEtqaD3jXFQNc5beKoKuegxCs4/x6B/a4W8Jum5SnhctjqIomcAScdR/
> > > > 1OkX/hAQVNvFToqD9d0ExQ5y80SyH87eATQorT0hBixYIe2/s5qYvs1h/Jlvvtd9
> > > > vdfxgRZ3xiK29xZFoPErOjOkneTXETtIOybR79fBEuZfB1C0A9aY8BVO42Oz2DI2
> > > > cmmqRN6SiHIgeQbo//C1ke9AIKn5mJliQFuK+Xc4tj2jC69DCM8DCAy87ue9TCPD
> > > > h9uRk3pX4BfF0yIxLeO1ZvbhloJTRm7OCMhpH4KJJF5EoVwnctC1KQCwOWAIhCk=
> > > > =cnaR
> > > > -----END PGP SIGNATURE-----
> > > >
_______________________________________________
> > > > gatein-dev mailing list
> > > > gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
> > > > https://lists.jboss.org/mailman/listinfo/gatein-dev
> > > >
> > >
> > >
> > > _______________________________________________
> > > gatein-dev mailing list
> > > gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/gatein-dev
> > >
> >
> >
> > _______________________________________________
> > gatein-dev mailing list
> > gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/gatein-dev
> >
>
>
>
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
--
Bolesław Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/gatein-dev
4:31 a.m.
Ok, point taken - it could have been phrased better - sorry for that.
Although this is smaller stuff - Juca was evaluating how it should or
could be done while coding... Not every change deserves a spec. And
sometimes writing a spec involves doing POC. And sometimes doing a POC
equals to actually implementing the feature... which kinda makes the
idea of writing the spec afterwars a bit awkward ...
I guess we could take a step back now and discuss what is wrong with
this change and if there is any other way.
W dniu 24/01/14 11:26, Julien Viet pisze:
I was more thinking about :
- we have this idea to make this awesome feature
- oh great, what is it ?
- it’s blah blah
- and how would you handle this change in persistence ?
- we don’t know yet but we will likely need to modify the schema or
something
- ok I see, we need to think about the best way etc…
instead of :
here is PR XYZ with feature implemented that changes schema, please validate
Julien Viet
julienviet.com
On Friday 24 January 2014 at 11:05, Bolesław Dawidowicz wrote:
> Isn't it a purpose of this mailing list? Very recently we shared like 4
> different spec or features ideas - before merging. This stuff is also
> not merged yet.
>
> We have a feature that we are working on and looking for ways of how to
> accomplish it - as far as I understand this is the purpose of this
> thread :)
>
> W dniu 24/01/14 10:44, Julien Viet pisze:
>> I’m still wondering if/when that was agreed to modify the persistence of
>> gatein.
>>
>> did I miss something ?
>>
>> Julien Viet
>> julienviet.com <http://julienviet.com>
>>
>> On Thursday 23 January 2014 at 18:33, Peter Palaga wrote:
>>
>>> Sorry, Juca, I sent the previous message too early. But the point made
>>> there is valid.
>>>
>>> Further:
>>> Have you consulted the English text with a native speaker? Jared is
>>> probably the best address.
>>>
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
>>>
>>> I see nothing else by merely looking at the code. I'll run it as a part
>>> of the merge process.
>>>
>>> Best,
>>>
>>> Peter
>>>
>>> On 2014-01-23 18:23, Peter Palaga wrote:
>>>> Is there a reason to use privateTillPublicationDate here but
>>>> restrictOutsidePublicationWindow elsewhere?
>>>>
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
>>>>
>>>> On 2014-01-23 18:11, Juraci Paixão Kröhling wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA512
>>>>>
>>>>> On 01/23/2014 05:27 PM, Peter Palaga wrote:
>>>>>> Hi Juca, PR or your branch does not matter to me, but could you
>>>>>> please squash all those commits into one so that reviewers can
>>>>>> overview your changes more easily? -- Peter
>>>>>
>>>>> Sure thing, the squashed commits are now available as one commit,
>>>>> here:
>>>>>
>>>>>
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
>>>>>
>>>>> Juca.
>>>>>
--
Bolesław Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v2.0.22 (GNU/Linux)
>>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>>
>>>>> iQEcBAEBCgAGBQJS4U1HAAoJECKM1e+fkPrXqlcIAJg0iUDyMulienr3r9FF+Tyu
>>>>> IS9sch3/uEtqaD3jXFQNc5beKoKuegxCs4/x6B/a4W8Jum5SnhctjqIomcAScdR/
>>>>> 1OkX/hAQVNvFToqD9d0ExQ5y80SyH87eATQorT0hBixYIe2/s5qYvs1h/Jlvvtd9
>>>>> vdfxgRZ3xiK29xZFoPErOjOkneTXETtIOybR79fBEuZfB1C0A9aY8BVO42Oz2DI2
>>>>> cmmqRN6SiHIgeQbo//C1ke9AIKn5mJliQFuK+Xc4tj2jC69DCM8DCAy87ue9TCPD
>>>>> h9uRk3pX4BfF0yIxLeO1ZvbhloJTRm7OCMhpH4KJJF5EoVwnctC1KQCwOWAIhCk=
>>>>> =cnaR
>>>>> -----END PGP SIGNATURE-----
>>>>>
_______________________________________________
>>>>> gatein-dev mailing list
>>>>> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>>
>>>> _______________________________________________
>>>> gatein-dev mailing list
>>>> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>
>>> _______________________________________________
>>> gatein-dev mailing list
>>> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>
>>
>>
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
>
>
> --
> Bolesław Dawidowicz
> JBoss Portal Platform Architect | GateIn Portal Project Lead
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/gatein-dev
4:32 a.m.
W dniu 23/01/14 17:00, Juraci Paixão Kröhling pisze:
@Julien: do you want to discuss whether this feature would be accepted
into master? Should I send a PR, or would you prefer to review it on
my repository?
Btw :)
--
Bolesław Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead
4:37 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
A little bit of background on this one: this came up as a bug report,
as a not marked as "visible" (checkbox "Visible" on the UI)
doesn't
shows up on the navigation, which effectively makes the node "hidden".
But an user that knows the URL of said node would still be able to see
it and share the URL with other users.
I understand that "fixing" this bug would introduce a change in the
behavior, which might affect people using this as a feature. As in: do
not mark this node as visible, but put a link to it from inside the
content of a page. If we suddenly just restrict access to this page,
this behavior would be broken.
The idea then was to ask the user explicitly if access to the node
should be restricted. For all existing nodes, it defaults to "no". For
new nodes, if the publishing date is set, this field is checked by
default.
Does it makes sense?
Juca.
On 01/24/2014 11:32 AM, Bolesław Dawidowicz wrote:
W dniu 23/01/14 17:00, Juraci Paixão Kröhling pisze:
>
> @Julien: do you want to discuss whether this feature would be
> accepted into master? Should I send a PR, or would you prefer to
> review it on my repository?
>
Btw :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS4kJOAAoJECKM1e+fkPrX/OEH/jzMRaTuDWtPKrB8JtI6sma4
jDvOJK4k9QSFqpZkwouLtB7pdM1Ij+3y99QJNVQaMwUrbqCvXLW3/5qcEjEh1bpN
12T5ahP5HqUIwKGUIhyiXcswMXsqVpKFQyVbJnSXUBbhO43ak35Elxkn+anUkWJA
jM0Yn+V8/LpbQZPeqzxlaPtlsJletpslAz94FMZLHEWQTBHp3e1dhgnZVBhOT1bp
0CBCU9sVO77KbbLxifC06MsGSxGt4f5DDRQuUceQhCdMWomcK8T+tFcixM6F1+zg
jVLJA8J0KX1GTtg0OjRe8RlYuMWPD1dE4obnTzsdaEIZhWAA49vYqKMsQLOS7yw=
=in1C
-----END PGP SIGNATURE-----
7:05 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
All,
I'm wondering if you've given any thoughts on this feature. Is it
desirable to have it? Would the described scenario be a good solution
for it? Any further comments on the PR itself?
Thanks,
Juca.
On 01/24/2014 11:37 AM, Juraci Paixão Kröhling wrote:
A little bit of background on this one: this came up as a bug
report, as a not marked as "visible" (checkbox "Visible" on the UI)
doesn't shows up on the navigation, which effectively makes the
node "hidden". But an user that knows the URL of said node would
still be able to see it and share the URL with other users.
I understand that "fixing" this bug would introduce a change in
the behavior, which might affect people using this as a feature. As
in: do not mark this node as visible, but put a link to it from
inside the content of a page. If we suddenly just restrict access
to this page, this behavior would be broken.
The idea then was to ask the user explicitly if access to the node
should be restricted. For all existing nodes, it defaults to "no".
For new nodes, if the publishing date is set, this field is checked
by default.
Does it makes sense?
Juca.
On 01/24/2014 11:32 AM, Bolesław Dawidowicz wrote:
> W dniu 23/01/14 17:00, Juraci Paixão Kröhling pisze:
>>
>> @Julien: do you want to discuss whether this feature would be
>> accepted into master? Should I send a PR, or would you prefer
>> to review it on my repository?
>>
> Btw :)
_______________________________________________ gatein-dev mailing
list gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS5lmEAAoJECKM1e+fkPrXJsIIAImBqb95CnoR8mLpYIAvI+zc
gIrrlZXYKeui8955MHQVC2dfaE9272Ltdj7Apqtlm4tvOm5W8YVLOd0vXGfaxyFH
k3+3F2+a2dPnVd7wmG8s6eFssD/uc7Ko6Mb3hxWpV1LHAj32mNSqMc2twDVWzZCn
nSxPxLbkfOQhu8I4c8DJWOy5Uq4XPWCnhtq4qCorS3A6kYb2/kNIq3oBQ0Ess/Nk
2295DAEMeYBhJJWw3k87DRZ9DLsjjJ66ej82s9e4z7v0p4hbBl83hZLiwaB8nOM0
K3KAWnDVThcVZr43llt8q8GhBRk5twKcpDCYQ+8k+gFm5uOa1EmoIvJRQQ6DkJY=
=48uM
-----END PGP SIGNATURE-----
1:26 a.m.
to avoid migration issues:
use instead a new mixin node type (let’s call it gtn:visible2) that extends gtn:visible
and adds this new property.
thanks
Julien
Julien Viet
julienviet.com
On Monday 27 January 2014 at 14:05, Juraci Paixão Kröhling wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
All,
I'm wondering if you've given any thoughts on this feature. Is it
desirable to have it? Would the described scenario be a good solution
for it? Any further comments on the PR itself?
Thanks,
Juca.
On 01/24/2014 11:37 AM, Juraci Paixão Kröhling wrote:
> A little bit of background on this one: this came up as a bug
> report, as a not marked as "visible" (checkbox "Visible" on the
UI)
> doesn't shows up on the navigation, which effectively makes the
> node "hidden". But an user that knows the URL of said node would
> still be able to see it and share the URL with other users.
>
> I understand that "fixing" this bug would introduce a change in
> the behavior, which might affect people using this as a feature. As
> in: do not mark this node as visible, but put a link to it from
> inside the content of a page. If we suddenly just restrict access
> to this page, this behavior would be broken.
>
> The idea then was to ask the user explicitly if access to the node
> should be restricted. For all existing nodes, it defaults to "no".
> For new nodes, if the publishing date is set, this field is checked
> by default.
>
> Does it makes sense?
>
> Juca.
>
> On 01/24/2014 11:32 AM, Bolesław Dawidowicz wrote:
> > W dniu 23/01/14 17:00, Juraci Paixão Kröhling pisze:
> > >
> > > @Julien: do you want to discuss whether this feature would be
> > > accepted into master? Should I send a PR, or would you prefer
> > > to review it on my repository?
> > >
> >
> >
>
>
> > Btw :)
>
>
>
>
> _______________________________________________ gatein-dev mailing
> list gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS5lmEAAoJECKM1e+fkPrXJsIIAImBqb95CnoR8mLpYIAvI+zc
gIrrlZXYKeui8955MHQVC2dfaE9272Ltdj7Apqtlm4tvOm5W8YVLOd0vXGfaxyFH
k3+3F2+a2dPnVd7wmG8s6eFssD/uc7Ko6Mb3hxWpV1LHAj32mNSqMc2twDVWzZCn
nSxPxLbkfOQhu8I4c8DJWOy5Uq4XPWCnhtq4qCorS3A6kYb2/kNIq3oBQ0Ess/Nk
2295DAEMeYBhJJWw3k87DRZ9DLsjjJ66ej82s9e4z7v0p4hbBl83hZLiwaB8nOM0
K3KAWnDVThcVZr43llt8q8GhBRk5twKcpDCYQ+8k+gFm5uOa1EmoIvJRQQ6DkJY=
=48uM
-----END PGP SIGNATURE-----
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/gatein-dev
8:47 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Julien,
On 01/29/2014 08:26 AM, Julien Viet wrote:
to avoid migration issues:
use instead a new mixin node type (let’s call it gtn:visible2)
that extends gtn:visible and adds this new property.
Thanks! In fact, I've added a new mixin named "gtn:restrictAccess",
but I'm not sure I understand what you mean by "extends gtn:visible
and adds this new property".
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
Also, I guess that the link to the full diff got lost in the thread,
so, here it is:
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
Based on my tests, there's no migration issues anymore, so, I think
the $subj is now outdated, but I'd still like to get a feedback on
whether the feature (and the proposed code to implement it) would be
considered for merging if/when I send this as a PR.
Thanks!
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS6mXpAAoJECKM1e+fkPrXasoH/jyq1Gu95g+OctGrZSigbxIA
EM0K6TB8YQk1jvDmOxmWN215S7cxmkF0Zj3bdmfzFP3znSAzR13daHuuISCtIDv8
8mu69A5RDCwEuDNJK7TYLkIUmztY13LySluiLFRcvUNecdxsucDsioELX1nch5Tb
KTGxwP15J8Y5Vp9P6nHxvtUafbA17rymCi2Zo3vSQRkxJjRbahs21IrKas3UywsS
DwqcF8rUauKKD10uoBD+8WRSc7zGjoVFopUWyPaSer5uOS8PqUcfsVns7fOLAlvg
ycNQ21329XIrLHzVnkrvkFZZnYjcDIAk1jCs+/49EX7XmvfjN4esGHDoO7TMHQs=
=cgXK
-----END PGP SIGNATURE-----
4:41 a.m.
I looked at it, it looks fine.
However have you tried to make the new mixin extends the gtn:visible mixin ? I think it
would be better as having this mixin would imply to have the visible mixin.
Julien Viet
julienviet.com
On Thursday 30 January 2014 at 15:47, Juraci Paixão Kröhling wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Julien,
On 01/29/2014 08:26 AM, Julien Viet wrote:
> to avoid migration issues:
>
> use instead a new mixin node type (let’s call it gtn:visible2)
> that extends gtn:visible and adds this new property.
>
Thanks! In fact, I've added a new mixin named "gtn:restrictAccess",
but I'm not sure I understand what you mean by "extends gtn:visible
and adds this new property".
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
Also, I guess that the link to the full diff got lost in the thread,
so, here it is:
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
Based on my tests, there's no migration issues anymore, so, I think
the $subj is now outdated, but I'd still like to get a feedback on
whether the feature (and the proposed code to implement it) would be
considered for merging if/when I send this as a PR.
Thanks!
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS6mXpAAoJECKM1e+fkPrXasoH/jyq1Gu95g+OctGrZSigbxIA
EM0K6TB8YQk1jvDmOxmWN215S7cxmkF0Zj3bdmfzFP3znSAzR13daHuuISCtIDv8
8mu69A5RDCwEuDNJK7TYLkIUmztY13LySluiLFRcvUNecdxsucDsioELX1nch5Tb
KTGxwP15J8Y5Vp9P6nHxvtUafbA17rymCi2Zo3vSQRkxJjRbahs21IrKas3UywsS
DwqcF8rUauKKD10uoBD+8WRSc7zGjoVFopUWyPaSer5uOS8PqUcfsVns7fOLAlvg
ycNQ21329XIrLHzVnkrvkFZZnYjcDIAk1jCs+/49EX7XmvfjN4esGHDoO7TMHQs=
=cgXK
-----END PGP SIGNATURE-----
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/gatein-dev
5:11 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 01/31/2014 11:41 AM, Julien Viet wrote:
I looked at it, it looks fine.
Cool, thanks!
However have you tried to make the new mixin extends the
gtn:visible mixin ? I think it would be better as having this mixin
would imply to have the visible mixin.
I was talking with ppalaga about it yesterday, and I'll give it a try
soon.
I'm probably missing something, but it isn't clear to me what would be
the benefits of this approach, other than "it is contextually correct"
(which is in itself a valid reason). I hope to find a possible answer
when I get this implemented, but I couldn't find anything on the
documentation that would explain the difference or perhaps show the
benefits of this approach. Perhaps there's an advantage on how the
data is stored? In data consistency?
In other words, this is how the code looks like in the PR, without the
new mixin inheriting gtn:visible:
// NavigationServiceImpl
Visible visible = sourceNav.adapt(Visible.class);
... // do operations related to Visible.class
if (sourceNav.isAdapted(RestrictAccess.class)) {
... // do operations related to RestrictAccess.class
} else {
chromatticSession.setEmbedded(sourceNav, RestrictAccess.class,
restrictAccess);
}
With the RestrictAccess inheriting Visible, I suppose that the code
would look like this:
if (!sourceNav.isAdapted(RestrictAccess.class)) {
... // it's only Visible, so, probably an old node: replace Visible by
RestrictAccess on the sourceNav
}
// do operations related to Visible.class
// and operations related to RestrictAccess.class
And this is how it currently looks like on NodeData:
if (navigation.isAdapted(Visible.class)) {
... // operations about Visible
}
if (navigation.isAdapted(RestrictAccess.class)) {
... // operations about RestrictAccess.class
}
With the change, the second conditional could be placed inside the
first, saving perhaps an unnecessary check if the *first* renders
false (which, from what I understand, would rarely happen).
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS64TWAAoJECKM1e+fkPrXKEEIAJBgeDiwGy/L9gVwaU2gNv9i
pPoE+T9GZKQOjetsq7SuJnlKmUxkyz3ilVOKmrZbE6+bMWyZL73EGiEGdHlSBG3U
pZ1Qc/glEfnck0Tjg3zjpGfpbIGzo+Y0Jcs9V9QJC8kQVbuw8PTs2RPrK02DprNG
j2Z+bAqm+ntf7qGdm5LdXcrT97jo6AZylY1mqzdCzGpWsve2gWFInxn3s021OUJ4
oMIb/VVkjcAxudkAh2ZI2wBzHwmgpbHw2yQKjD+xTCHgttPEql/tx2jDeaBwY9at
msJkrj8LoWm8w5jc9HDB32LuG/aBl5Lq6lRzvG/oi22oUM2KpjuGOf2R5dS13WQ=
=kYEX
-----END PGP SIGNATURE-----
9:40 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
All,
I've done the proposed changes, and the squashed new branch is
available here:
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
What I'm not sure, however, is whether I need to duplicate the fields
from Visible (will check the JCR spec in the meantime), but it seems
that's indeed a requirement, as I've seen it done in another inherited
type (though, it wasn't a mixin).
I'm specially interested in comments about the code on
NavigationServiceImpl, RestrictAccess and gatein-nodetypes.xml, but a
review on the other parts would be just as awesome :-)
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS+kSLAAoJECKM1e+fkPrXBdsH/1267/Qi9IhpsQx6jX+aDoVo
5RnlKoMi/abCfWK/djXKnnJb1KYDxcwu0r5by64PcuEaAabbbn7YtVSzYiiwzdSj
+PxxPU8xdPqcZfTAOCPZgeCAuzt2mvwRRMUUzqGiCpt3oFlHbwLzPH8/QNSh4Iar
a9xPUZCi7yZzW7va/FzvEosQuSY8UwKAivGA7gn4/eWknmd0i6QfG80ye9m8XtN5
pZ8c97EGwVsUStCaECeCQ4GEI7nLNWSpDk4OwTREmUoKb22S8leEFWHS8nI4L48K
zOIairnTYT/3y4SfUZZf8JQl8MI2hHrodN6iNOBflfZ8tuMVmNtJm8Pw1ukVVbo=
=8Oyv
-----END PGP SIGNATURE-----
3:58 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
All,
We are planning on merging this feature by Monday next week, if there
are no objections. So, please let me know if there's anything else
that would need a change/improvement.
Thanks!
Juca.
On 02/11/2014 04:40 PM, Juraci Paixão Kröhling wrote:
All,
I've done the proposed changes, and the squashed new branch is
available here:
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
What I'm not sure, however, is whether I need to duplicate the
fields from Visible (will check the JCR spec in the meantime), but
it seems that's indeed a requirement, as I've seen it done in
another inherited type (though, it wasn't a mixin).
I'm specially interested in comments about the code on
NavigationServiceImpl, RestrictAccess and gatein-nodetypes.xml, but
a review on the other parts would be just as awesome :-)
Juca. _______________________________________________ gatein-dev
mailing list gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJTAy6uAAoJECKM1e+fkPrXPo4H/2EePwZgNg6DWdiDpIsCfMMR
Z7TQhrtReLiscFuvnZfBRSPboQUOhESSP8VU1ufIJMIKx14FNQ195BFSxaTNRJwP
mGji7NI8p1aw9hpl+9D2dsCKKk3jt7mUVN1YSb0O2x6oE824/wrbFok1b0AX8Xx9
v4qqeT9tmxhKq7zug0nuFBZRSgHekprBCnEMc/j9CrpTgIKBvQp/eKFOI/EveWOk
aKJLtOwcrvl0YZKfQwwmMhnrQUVchnsl+IIASUHBPi/OxDC6OtTiA1+9N3OZtO7g
wpHEIZtBFptnbJy4AURGa513NNy4AW644OYAjz9EW1NDdZweUNjbEW8LJsB6ybI=
=lgYe
-----END PGP SIGNATURE-----
6:56 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Julien, All,
During the merging for this feature, some test failures occurred.
While debugging it, I've found out that on the mixin approach, the
following code renders to false, when it shouldn't:
adapter.isAdapted(Visible.class)
Changing it from Visible.class to RestrictAccess.class (which inherits
from Visible) makes the calling code to work. While this wouldn't be
such a big problem in GateIn itself, as there are only a couple of
places that makes such call, there's still a question on how this
could affect eXo or other Gatein-based products. As this is not part
of the public API, I don't think it would be a big problem, but it
would still be risky.
Another question is whether said code should render "true". My
understanding is that it should indeed render to true, which then
makes me wonder if there's something missing on the implementation or
if there's a bug down there (on isAdapted method, or at the JCR level).
If the current behavior of the Adapter code and JCR are indeed
correct, as well as the implementation (ie: isAdapted should render
"false"), then I'd say that it's better to go back to the previous
approach, having RestrictAccess independent from Visible. This way, we
don't affect current code that calls isAdapted(Visible.class).
Best,
Juca.
On 02/18/2014 10:58 AM, Juraci Paixão Kröhling wrote:
All,
We are planning on merging this feature by Monday next week, if
there are no objections. So, please let me know if there's anything
else that would need a change/improvement.
Thanks! Juca.
On 02/11/2014 04:40 PM, Juraci Paixão Kröhling wrote:
> All,
> I've done the proposed changes, and the squashed new branch is
> available here:
>
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
> What I'm not sure, however, is whether I need to duplicate the
> fields from Visible (will check the JCR spec in the meantime),
> but it seems that's indeed a requirement, as I've seen it done
> in another inherited type (though, it wasn't a mixin).
> I'm specially interested in comments about the code on
> NavigationServiceImpl, RestrictAccess and gatein-nodetypes.xml,
> but a review on the other parts would be just as awesome :-)
> Juca. _______________________________________________ gatein-dev
> mailing list gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
_______________________________________________ gatein-dev mailing
list gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJTDeR8AAoJECKM1e+fkPrXNWcH/1ZUsQVrexcrWvm7KOkiYPrF
OU3nnS/d9c1KPC1/t3ZYG1OM0MuR7EprfBn50/oaex/6TptdAYSnCFXdxbytvilC
ZhutgsBeUkimWEDru3afxVniOFKmw1uHwLpka8wsiWFrgcj5J+dzOJN9MdgrYbom
fiVoj/c4bAt8PGdQWJo4SIP97ccYUuVdf8Ls4E6MyAu9UC5UGUZF2Z8sF8A6dcWR
1GGSRdZUvJfuEgvltERd9HWz9o2SuWpm1iQY+PDLloz1mpAYIhgreKushjXrjjWz
TrqyA0SqPyVyiqEPrZbYi7bdhfUz4z/YFBYZxaQnX/iRHQz+dWI6eolx5PPG7sE=
=wgXm
-----END PGP SIGNATURE-----
2:40 a.m.
I think the question is whether or not having the RestrictedAccess mixin implies to have
the Visible mixin. If that’s a yes, then inheritance should be used and the bug fixed or
workarounded.
Julien Viet
julienviet.com
On Wednesday 26 February 2014 at 13:56, Juraci Paixão Kröhling wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Julien, All,
During the merging for this feature, some test failures occurred.
While debugging it, I've found out that on the mixin approach, the
following code renders to false, when it shouldn't:
adapter.isAdapted(Visible.class)
Changing it from Visible.class to RestrictAccess.class (which inherits
from Visible) makes the calling code to work. While this wouldn't be
such a big problem in GateIn itself, as there are only a couple of
places that makes such call, there's still a question on how this
could affect eXo or other Gatein-based products. As this is not part
of the public API, I don't think it would be a big problem, but it
would still be risky.
Another question is whether said code should render "true". My
understanding is that it should indeed render to true, which then
makes me wonder if there's something missing on the implementation or
if there's a bug down there (on isAdapted method, or at the JCR level).
If the current behavior of the Adapter code and JCR are indeed
correct, as well as the implementation (ie: isAdapted should render
"false"), then I'd say that it's better to go back to the previous
approach, having RestrictAccess independent from Visible. This way, we
don't affect current code that calls isAdapted(Visible.class).
Best,
Juca.
On 02/18/2014 10:58 AM, Juraci Paixão Kröhling wrote:
> All,
>
> We are planning on merging this feature by Monday next week, if
> there are no objections. So, please let me know if there's anything
> else that would need a change/improvement.
>
> Thanks! Juca.
>
> On 02/11/2014 04:40 PM, Juraci Paixão Kröhling wrote:
> > All,
>
>
> > I've done the proposed changes, and the squashed new branch is
> > available here:
> >
https://github.com/jpkrohling/gatein-portal/compare/BZ794359-HidePageIfPu...
> >
>
>
> > What I'm not sure, however, is whether I need to duplicate the
> > fields from Visible (will check the JCR spec in the meantime),
> > but it seems that's indeed a requirement, as I've seen it done
> > in another inherited type (though, it wasn't a mixin).
> >
>
>
> > I'm specially interested in comments about the code on
> > NavigationServiceImpl, RestrictAccess and gatein-nodetypes.xml,
> > but a review on the other parts would be just as awesome :-)
> >
>
>
> > Juca. _______________________________________________ gatein-dev
> > mailing list gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
> > https://lists.jboss.org/mailman/listinfo/gatein-dev
> >
>
>
>
> _______________________________________________ gatein-dev mailing
> list gatein-dev(a)lists.jboss.org (mailto:gatein-dev@lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJTDeR8AAoJECKM1e+fkPrXNWcH/1ZUsQVrexcrWvm7KOkiYPrF
OU3nnS/d9c1KPC1/t3ZYG1OM0MuR7EprfBn50/oaex/6TptdAYSnCFXdxbytvilC
ZhutgsBeUkimWEDru3afxVniOFKmw1uHwLpka8wsiWFrgcj5J+dzOJN9MdgrYbom
fiVoj/c4bAt8PGdQWJo4SIP97ccYUuVdf8Ls4E6MyAu9UC5UGUZF2Z8sF8A6dcWR
1GGSRdZUvJfuEgvltERd9HWz9o2SuWpm1iQY+PDLloz1mpAYIhgreKushjXrjjWz
TrqyA0SqPyVyiqEPrZbYi7bdhfUz4z/YFBYZxaQnX/iRHQz+dWI6eolx5PPG7sE=
=wgXm
-----END PGP SIGNATURE-----
3968
days inactive
4004
days old
27 comments
5 participants
participants (5)
-
Bolesław Dawidowicz -
Julien Viet -
Juraci Paixão Kröhling -
Nicolas Filotto -
Peter Palaga