Christophe,
I assumed that M3 would have the same issue, so it is reassuring to hear
that it does indeed.
I am not sure how you want to encorporate my modifications. I have a
small fix in the J2 maven plugin and
quite a few patches for the graffito source tree. David seemed to
indicate that we could allow me to commit to the
graffito project, (I am already a J2 committer as you know). Otherwise,
I could send you a few patch files.
I plan on fully integrating Graffito into J2, so perhaps we can just
skip this step alltogether. Your call.
Randy
Christophe Lombart wrote:
Randy,
Same issue on M3. As you explained in your mail,
org.apache.portals.graffito.security.impl.CmsPermissionImpl is not set
into the DB (in SECURITY_PERMISSION). If you replace the wrong value
by this classname, it will be better.
I have more time now. So, I can try to fix this issue. Can give me an
access to your M4 deployment stuff ? Do you plan to add it in the
Graffito project or directly into J2 ?
Thanks,
Christophe
On 9/27/05, Christophe Lombart <[EMAIL PROTECTED]> wrote:
On 9/26/05, Randy Watler <[EMAIL PROTECTED]> wrote:
Christophe Lombart wrote:
Maybe it is a regression. Are you using the subproject
'jetspeed2-deploy' to deploy into J2 ? See in this subproject, there
are some xml file uses to deploy the application.
Yes, I am using this project to deploy, albeit modified for M4.
Let me know if you need help. I don't know if I can access to your
modifications somewhere.
Here is the deal:
The Graffito Browser is adding these objects to the RdbmsPolicy store:
org.apache.portals.graffito.model.pemission.impl.CmsPermissionImpl
While these appear to be correctly specified and stored by the browser,
the Graffito
security implementation is creating permission instances of this class
type and
sending these to the AccessController.checkPermission():
org.apache.portals.graffito.security.impl.CmsPermissionImpl
See
components/src/java/org/apache/portals/graffito/security/impl/GraffitoAction.java.
Unless I am missing something, the new permissions will not be seen by
java security because the class types do not match. Of course, the initial
setup/deploy has permissions granted to /role/admin using the
org.apache.portals.graffito.security.impl.CmsPermissionImpl class and
these work as expected.
Did I miss some configuration that tells the Graffito Browser to use the
security vs. model implementations?
no
Am I missing some nuance of java
security that would allow the model implementations to be read?
No (following my limited knowledge of JAAS)
Tomorow, I will review the code.
What's the behavior with J2 M3 ?
