See the following URL to know about Mirage:
Here is the list of new features in this release:
- Use java.util.logging instead of slf4j / logback to remove them from dependency.
- Simple example and documentation for Google Guice integration.
- It's possible to specify a transient property by transient modifier instead of @Transient annotation.
- Add new method SqlManager#findEntity(Class clazz, Object... id)
- Add new method SqlManager#getCount(String sqlPath[, Object param])
- ValueType interface to add custome value type support
- BLOB support
Mirage is still not enough to use in complex systems. So we would improve it as much as possible soon.
6 件のコメント:
Thank you for the new release :).
Would you please describe what changes have you made to OGNL?
You mention here:
http://amateras.sourceforge.jp/site/mirage/download.html
that Mirage requires a patched OGNL. Is this the same modification that Click does?
http://svn.apache.org/viewvc/click/trunk/click/framework/src/ognl/
Or is it something else?
Thank you,
Adrian.
Hi Adrian,
> that Mirage requires a patched OGNL. Is this the same modification that Click does?
This patched OGNL is provded by S2JDBC. S2JDBC is a O/R mapping framework based on the DI container named Seasar2.
Mirage uses a patched OGNL provided by S2JDBC because a part of source code of Mirage were imported from S2JDBC.
However I think Mirage can work a recent version of OGNL. I will replace and test it. And other idea, Mirage may move to MVEL from OGNL.
> And other idea,
> Mirage may move to MVEL from OGNL.
I'm not sure if this would be a very efficient solution. Click decided against moving to MVEL.
More interesting would be if it would be possible to push those patches to the official OGNL source, so that S2JDBC(and Click too) wouldn't need a modified version of OGNL in first place.
> More interesting would be if it would be possible to push those patches to the official OGNL source
Yes, It's an ideal solution if it's possible.
>>More interesting would be if it
>>would be possible to push those
>>patches to the official OGNL source
>Yes, It's an ideal solution if it's
>possible.
It should be possible. There are not that many active developers of OGNL, and I'm sure they would appreciate any help:
The issue tracker:
http://jira.opensymphony.com/browse/OGNL
Of course, it might be worth checking in first place if the patches make sense anymore (if not those problems are already fixed in these newer versions). If they're not fixed, I don't see why they wouldn't be applied since there are not that many other contributions.
I'd like to see the benchmarks which caused Click to choose OGNL over MVEL. While it's possible to come up with benchmarks that shows OGNL's bytecode compiler to have similar performance to MVEL, I'd highly recommend people fully explore the memory profile of both solutions.
MVEL's JIT is far more advanced, and it has a far more memory-efficient reflection-optimizer which provides a better performance profile for highly scaled systems.
This is why projects like JBoss Drools use MVEL.
コメントを投稿