Tony Collen wrote:
Upayavira wrote:
Ideas welcome.
Here's an Idea (or maybe more of a thought):
Wouldn't this make the AbstractMetaModule obsolete?
When would someone want to build a MetaModule instead of just using the
nesting?
Simple. Nesting is to be written every time, while using a meta
Ralph Goers wrote:
map:transform type=i18n
...
If the values in the catalog contain things like jx:out
value=${request:}/ the I18n transformer will replace
{request:} with nothing leaving only the $ as the value. So what
we'd like to know is if there is any way to
Ugo Cei wrote:
Fellow Cocooners,
after having neglected my weblog for a long time, I'm starting to feel
the urge to blog again, but I want to use a better software than the
homegrown thing I was using before. So I started looking into Linotype
again and decided that it is in need of quite a
Torsten Curdt wrote:
Ugo Cei wrote:
1. remove the ad-hoc authentication system and use container-based
authentication;
Hm... you'd have to configure the container
for authentication :-/ don't know
Yes, I already did it. Now I just need to remove all the code dealing
with authentication from
Guido Casper wrote:
Concerning the repository ... I just committed another repository
interface :-) that tries to be a best effort in consolidating all the
different approaches and accommodating all concerns in a flexible way
(by having opional helpers for property management, versoning and
Ugo Cei wrote:
You have to store items in some form or another, even if you can use
XSL-T to transform them to something else later. I'm proposing to use
something standard, again (Atom or RSS) instead of a made-up markup.
the lenya weblog publication is based on atom and has partial atom api
I think a big point (and that may be from never having used JMX) that
is being missed. When I was saying JMX and its style form part of a
good kernel candidate, you have to look at how JMX is used. It uses a
standard reflection mechanism to talk to components. Just to say it
supports an
Yes, I already did it. Now I just need to remove all the code dealing
with authentication from the flowscript. Do you see a problem with that?
I only see benefits:
- less code to maintain
- possibility of using different user repositories (file, JDBC, LDAP,
...) via standard inderfaces
-
Torsten Curdt wrote:
In general I agree but it makes the deployment more
complicated because the authentication differs from
container to container.
The container-specific part of the configuration varies, but it's
usually not that complicated. And everyone who has ever deployed a J2EE
webapp
Just to clarify this. There are three types of MBeans; standard, dynamic,
and open. Only standard MBeans use reflection. Dynamic MBeans register their
methods, operations, etc. OpenMBeans are dynamic MBeans but are restricted
to using OpenType objects (which are ArrayType, CompositeType,
11 matches
Mail list logo
