|> Then how do you reference these files? You mention referencing
|the top of
|
|If there was some sort of ServiceContext, passed into the service bean, on
|init, then it could hold this information.
hmmmm we want the party in front to incorporate as little from us as
possible. That means "no classes" so the current ContextClassLoader
integration is about as much "hoochy" we can take.
|Some legecy services will want files. Some services will only make sence
|when working off of files. I can understand that the boot/loading system
|should not be tied to files, but there is no reason why we should force
|service writters to stop using files.
|
|Right?
The question is how do they find their files, get with the problem.
|> need to introduce a sar.xml that is a collection of the jcml
|information and
|> some self descripting stuff such as the name of the "sar" (in our case
|> "jetty"). hmmmm
|
|remeber long ago when I was talking about using a FileSystem abstraction...
|and remeber the bit about defining local resources required by a service in
|the service deployment descriptor, these go hand in hand. Top it off with
|the ServiceContext, and you have all the means to support this type of
|per-service configuration.
Who provides the "FileSystem" abstraction class? if it is us there is
little chance this will fly. Are we going to ask everyone to not use
"java.io.File" but our stuff instead if they want to integrate with us one
day? That is not realistic.
I think we can package a filesystem in a SAR (I am even willing to rename it
to your original name since it was you who first talked). And expand that
in the host FS but when you want to get a pointer to your file (a
programmatic one) all we need is a root.
marcf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
