Not saying the use of platform/environemtn specific url protocols is
bad in any way. Just saying that I think it is unreasonable to code in
Hibernate handling for all these protocols. JBoss VFS, for example, is
much better handled using JBoss VirtualFile API. OSGi protocols will
require very special handling as well, though it *seems* like we may be
able to stick to standard OSGi APIs rather than vendor specific APIs
(but I dont know that for sure yet).
On Sun 17 Mar 2013 03:59:15 PM CDT, Steve Ebersole wrote:
Not saying the use of platform/environemtn specific url protocols is
bad in any way. Just saying that I think it is unreasonable to code
in Hibernate handling for all these protocols. JBoss VFS, for
example, is much better handled using JBoss VirtualFile API. OSGi
protocols will require very special handling as well, though it
*seems* like we may be able to stick to standard OSGi APIs rather than
vendor specific APIs (but I dont know that for sure yet).
On Sat 16 Mar 2013 08:29:54 PM CDT, Ales Justin wrote:
>> I should point out this is based on what we saw when Brett initially
>> worked with Karaf, especially in the Enterprise OSGi use cases. The
>> incoming PersistenceUnitInfo contained no urls other than the root
>> url, which happened to be an osgi bundle url (the protocol was
>> "bundle"). To me, interpreting all these goofy url schemes is best
>> left to the environment that defines those schemes. Not much unlike
>> JBoss AS and its VFS-based urls.
>
> Yeah, scanning and funky urls are always a problem.
>
> Well, the funky urls are there for a reason -- we can discuss them
> over beer next time. :-)
> And in most cases they don't represent a problem,
> unfortunately resource scanning is not one of those cases.
>
> But, imo, any decent framework should account for this,
> if nothing else, for optimisation reasons.
>
> e.g. I pushed a patch to DataNucleus, Spring, Drools, Facelets, ...
> just b/c of this
>
> And Emmanuel and me are the culprits behind initial Scanner. :-)
>
> -Ales
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev