> |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.
Is this really the case? How about using an Adapter to take the ServiceBean
(with ServiceContext) and wrap something that does not implement the correct
interface.
This allows us to provide a clean way to pass data into the service, and
still support services which don't know anything about the service
interface.
In those cases the adapter could read the path name from the ServiceContext
and pass it on as a property or a call to the object that cares.
Short of force everyone to use resources I can't think of a better way to
handle this (at the moment). I think that there will almost always have to
be some adapter layer between jboss and thirdparty services, we should plan
on that from the start.
> The question is how do they find their files, get with the problem.
I know, that is why I mentioned ServiceContext. It could provide
getProperty() methods or something similar to expose configuration, as well
as future tx attributes and anything else we can think of.
> |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.
So the goal is to provide an architecture, where company x, who knows zero
about JBoss and its design, to drop in a service and except it to work?
That is fine, I was thinking a different route... which could be the same as
the above, it just will have to use an adapter to bridge the gap.
I was thinking of the FileSystem stuff from NetBeans, but never really
looked into it much.
> 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.
Right, so were does the service get that from? Properties? Custom bean
call? Reading a resource, which is a properties file, pulling down from
jndi?
Hrm... that might work. Give each service its own jndi context (like ejb's
do)... but that puts us back into the bag of having that service know about
that JBoss'ism.
I don't think there is a better way than to design in adapter usage from the
start. They will be simple classes, nothing too hard to code.
I could see that one 3rd party service might want a resource, another a
file, another some JNDI url. Why not support them add by abstracting the
parts we care about and let them plug in a class to do the rest?
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
