|A JNDI env for each service along with well known entries for resources
|like JMS and the local filesystem seems like the best approach. I don't see
|locating
|the JBoss server filesystem as any different than locating a JMS queue:
|
|File root = (File) new InitialContext().lookup("jboss/filesystem");
:)
interesting...
marcf
|
|with an org.jboss.naming.Namespace interface for defining the well known
|resource
|paths in JNDI.
|
|public interface Namespace
|{
| public static final String LOCAL_FILESYTEM = "jboss/filesystem";
| public static final String JMS_QUEUE_CONN_FACTORY =
|"ConnectionFactory";
| public static final String JMS_TOPIC_CONN_FACTORY =
|"ConnectionFactory";
| public static final String JMS_QUEUES = "queue";
| ...
|}
|
|----- Original Message -----
|From: "Jason Dillon" <[EMAIL PROTECTED]>
|To: "marc fleury" <[EMAIL PROTECTED]>
|Cc: "Julian Gosnell" <[EMAIL PROTECTED]>;
|<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
|Sent: Monday, September 03, 2001 7:57 PM
|Subject: RE: [JBoss-dev] Jetty and Rabbit Hole
|
|
|> > |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
|>
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
