New field on node type gtn:visible - how to migrate the data?
by Juraci Paixão Kröhling
-----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-----
11 years
Impersonation in GateIn Portal
by Marek Posolda
Hi all,
We've been requested several times by our users/customers to add
"impersonation" feature.
It may be useful for portal administrator to have possibility to
temporary login as another user without knowing his password. For
example: User /root/ wants to verify that user /mary/ really doesn't
have permission to see page X or portlet Y on page Z.
I've added specification page here
https://community.jboss.org/wiki/ImpersonationInGateInPortal . Feel free
to provide feedback here or in comments of specification.
Have a nice weekend!
Marek
11 years
RFC - Page Composition API
by Juraci Paixão Kröhling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
All,
I'd like to kindly ask for your comments about a task that I'm
starting on GateIn 3.x, to extend the current API to allow portlet
developers to compose pages and add content to it.
I've put my initial thoughts and incorporated a few early feedback
propositions into the following wiki page, and I'd appreciate if you
could take some minutes to go through it and share your thoughts:
https://community.jboss.org/wiki/RFC-APIForComposingPages
I'm greatly interested in checking if my understanding of the current
situation is accurate, as well as getting attention to points that I
might have missed.
I have a few other smaller tasks to work on and I plan to start some
concrete coding by mid next week, so, I'd appreciate if you could
share your feedback by then -- or at least say "don't start, I've
found a fatal flaw, let's discuss first" :-)
Thanks!
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS18HfAAoJECKM1e+fkPrXqG0H/0tyXzBANobSXJHq3puo7RRP
9xt3HSJL75r7gGrTh+aBhJ68rup5gPiiGo2gztZAtU2wv/J2MFyHA1VmAVjNUQEC
xWccWbAowFZQs9b4nTf9sk/iRWnR84Wu9DuDUaXZERDQzE05IhfQ3p/jJORJCL+X
yrCIKu0vm9q7ooR2RcwG5WcD13Ov2yUWyK+0fHR4oGnE436vozpHYbvzDJHJaq3V
WWPAJ5Z6AV26CiTO5Ik2uOptggXKnxcSkBAwiMpChQw3z5vAP0H0hy42QGFntQYv
18S6jTKBuHnbuvoCs/Xd7zVmAOp1rHLjbERp2zdCy2wGTixZET6ptotzyZbOocA=
=R1o0
-----END PGP SIGNATURE-----
11 years
JCR 1.16.0-Alpha4 upgrade
by Julien Viet
Hi,
I am working on integrating JCR 1.16.0-Alpha4 in GateIn master.
For this purpose I will integrate it in MOP first and thus create a branch in this code base for 1.2.x and have master use 1.3.0-Beta01-SNAPSHOT.
Then I will proceed to GateIn upgrade itself.
let me know if that raise any issue.
Julien Viet
julienviet.com
11 years
Request for comment: Custom Navigation Node Properties
by Peter Palaga
Hi *,
I am starting to look at the customer request to provide a way to define
navigation nodes pointing to external URLs. They can accomplish this in
Portal 4.3 using page properties, storing there not only the URL but
also if the link should open in a new window, etc. This data is then
used in a custom navigation portlet.
There is no way known to me how this could be achieved using the present
navigation API. The following wiki page offers a space to discuss the
solution. Please comment!
https://community.jboss.org/wiki/CustomNavigatonNodeProperties
Best,
Peter
11 years, 1 month
Error in POMSessionManager when database is not initialized
by Lucas Ponce
Hello,
We are facing several ERRORs like this at first init when database is empty:
14:32:20,532 ERROR [org.exoplatform.portal.pom.config.POMSessionManager] (MSC service thread 1-1) Unexpected error when clearing pom cache: java.lang.NullPointerException
at org.exoplatform.services.cache.impl.jboss.AbstractExoCache.select(AbstractExoCache.java:343) [exo.kernel.component.ext.cache.impl.jboss.v3-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.exoplatform.portal.pom.config.POMSessionManager.cacheRemove(POMSessionManager.java:125) [exo.portal.component.portal-3.6.4.Final-redhat-1.jar:3.6.4.Final-redhat-1]
at org.exoplatform.portal.pom.config.POMSession.reset(POMSession.java:280) [exo.portal.component.portal-3.6.4.Final-redhat-1.jar:3.6.4.Final-redhat-1]
at org.exoplatform.portal.pom.config.POMSession.access$000(POMSession.java:56) [exo.portal.component.portal-3.6.4.Final-redhat-1.jar:3.6.4.Final-redhat-1]
at org.exoplatform.portal.pom.config.POMSession$1.afterSynchronization(POMSession.java:265) [exo.portal.component.portal-3.6.4.Final-redhat-1.jar:3.6.4.Final-redhat-1]
at org.exoplatform.commons.chromattic.AbstractContext.close(AbstractContext.java:123) [exo.portal.component.common-3.6.4.Final-redhat-1.jar:3.6.4.Final-redhat-1]
at org.exoplatform.commons.chromattic.Synchronization.close(Synchronization.java:99) [exo.portal.component.common-3.6.4.Final-redhat-1.jar:3.6.4.Final-redhat-1]
at org.exoplatform.commons.chromattic.ChromatticManager.endRequest(ChromatticManager.java:113) [exo.portal.component.common-3.6.4.Final-redhat-1.jar:3.6.4.Final-redhat-1]
at org.exoplatform.commons.chromattic.ChromatticManager.endRequest(ChromatticManager.java:126) [exo.portal.component.common-3.6.4.Final-redhat-1.jar:3.6.4.Final-redhat-1]
at org.exoplatform.container.component.RequestLifeCycle.doEnd(RequestLifeCycle.java:71) [exo.kernel.container-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.exoplatform.container.component.RequestLifeCycleStack.end(RequestLifeCycleStack.java:102) [exo.kernel.container-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.exoplatform.container.component.RequestLifeCycle.end(RequestLifeCycle.java:163) [exo.kernel.container-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.exoplatform.portal.config.NewPortalConfigListener.run(NewPortalConfigListener.java:249) [exo.portal.component.portal-3.6.4.Final-redhat-1.jar:3.6.4.Final-redhat-1]
at org.exoplatform.portal.config.UserPortalConfigService.start(UserPortalConfigService.java:507) [exo.portal.component.portal-3.6.4.Final-redhat-1.jar:3.6.4.Final-redhat-1]
at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source) [:1.7.0_25]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
at org.exoplatform.container.LifecycleVisitor.traverse(LifecycleVisitor.java:100) [exo.kernel.container-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.exoplatform.container.LifecycleVisitor.start(LifecycleVisitor.java:170) [exo.kernel.container-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.exoplatform.container.ConcurrentPicoContainer.start(ConcurrentPicoContainer.java:554) [exo.kernel.container-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.exoplatform.container.ExoContainer.start(ExoContainer.java:275) [exo.kernel.container-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.exoplatform.container.PortalContainer.start(PortalContainer.java:683) [exo.kernel.container-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.exoplatform.container.ExoContainer.start(ExoContainer.java:263) [exo.kernel.container-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.exoplatform.container.RootContainer.createPortalContainer(RootContainer.java:681) [exo.kernel.container-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.exoplatform.container.RootContainer.createPortalContainers(RootContainer.java:346) [exo.kernel.container-2.4.6-GA-redhat-1.jar:2.4.6-GA-redhat-1]
at org.gatein.integration.jboss.as7.web.StartupService.start(StartupService.java:45)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Configuration is based on clustering.
Any idea ?
Thanks,
Lucas
11 years, 1 month
Cache-Control - change it to be a per-portal configuration
by Juraci Paixão Kröhling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
All,
We've seen a request to add the possibility for administrators to set
the cache-control to something else than "no-cache". I've drafted a
commit that would allow it to be a portal configuration, and submitted
the PR https://github.com/gatein/gatein-portal/pull/759/files .
I was wondering if anyone knows if there's any reason why this entry
was set to "no-cache" explicitly, and what could be the side effects
of such change.
I've debugged it a bit, and it seems that non-asset requests reaches
this code (as in, code that returns an HTML, not
images/css/javascript), so, I don't think this is related to the assets.
As a side-question, this configuration option named "Cache Control"
might seem a bit cryptic to anyone looking at it without the context,
but I haven't figured out a good way to provide a help tip about it.
Is there a facility that I could use, to explain what this option
does, possibly linking to the RFC that lists all the options?
Thanks!
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJS0ArzAAoJECKM1e+fkPrXfuAH/1LWCfDteoZw6lVEIi2MvtOm
EuiGfqA1yPN1DnHT7uKs1tR/dwY/plgDSTHt0HkdA6Y6UOvLXeeLA/1tlv9NTSRN
AvM152t1WsoMK7XL7Sn2bEQBgDst7yStk7fwdKdf80vyGkNduTHtcYYSL2rKHsLk
zgAmoT0Ib8JBWZI3+yz86e8kN4B56hAf9OLxnVP+HIY5aPVfIjf88ukRpo8Txv2h
py+kz9fl5lTHPnxa3UYiI3iOxcXA5JZno0qmq3q/YLdsMFiBY/cZSE8O3bl1/gqq
zs4tNrLCsFyD4psCrHtsPUHdhbWKHSGWHYmg9LYnj58NTBilDzgD5MZx85Vy8vQ=
=Lium
-----END PGP SIGNATURE-----
11 years, 1 month
Syncing Changes in Resource Bundles
by Peter Palaga
Hi *,
As far as I know there are no explicit rules for situations like
(1) New key added in the master (en) resource bundle (RB).
(2) English text changed for some key.
I can think of two solutions:
(a) The "void" solution:
* When adding to en RB file, do not add anything to other locale's
RB files (except for those which you can reliably translate
yourself)
* When changing a key in en, remove the associated key-value pairs
from all other RBs (except for those which you can reliably
translate yourself)
(b) The "use en" solution:
* When adding to en RB file, add the very same English
value-pair to all other RB files (except for those which you can
reliably translate yourself)
* When changing a key in en, replace all values in the RBs that
you cannot translate yourself with the final English value you
just have changed.
I hope I explained (a) and (b) clearly enough.
Pros and Cons:
(a)
* Less work when adding keys
* Perhaps less error prone (delete the whole key-val is simpler than
replace)
* Probably more suitable to find out automatically (QA!) which keys
in which RBs need to be (re-)translated
(b)
* Easier for translators to see which keys need to be translated
without needing to look into source language file.
I tend to prefer (a).
Please comment!
Thanks,
Peter
11 years, 1 month
