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");
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
