You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/05/09 17:12:23 UTC
[RT] Avalon Bundles/Distribution Units
I have been giving this some more thought, and after looking at
.NET assemblies, I decided to draft an important concepts list
that we should look at what is best for Avalon to address. In the
Bundle concept and API:
Things that the bundle/DU needs to provide:
1) Meta Info
There are several ways of declaring the contents of the
DU. The .NET approach is to use a Manifest, more descriptive
and informative than the JAR equivalent. The Manifest declares
what is in the DU. Is there other Meta Info we need? Yes.
Next is an example.
2) Versioning
We need to determine the granularity of versioning. Do
we version at the DU level? Do we version at the api/impl level?
or do we go into a deeper granularity? We need to work with the
simplist level of granularity that provides us the best return
on our investment of time/energy.
3) Internationalization/Localization (I18N and L10N)
Each DU will have a set of i18n/l10n entries to help make the
functionality provided by the DU make sense for any locale where
it is used. The important thing is to ensure that the entire
application is operating with the same Locale information. It
would be very confusing if some parts of an application were
in English while others were in Spanish because the DU didn't have
a Spanish translation.
4) Application Specific Compartmentalization
The DU should be flexible enough to allow an application to extend
the Avalon semantics for its own use. The DU would have to be marked
so that it has App specific extensions using the Meta Info, but we
also have to determine if that means the DU can or cannot be used in
a more generic sense.
Things that the API needs to provide:
1) App Domains/Partitioning
A DU will be specific to a partition. In .NET speak this is an
App Domain. A Partition can be either an application, or a part
of an application. We need to define its boundaries.
2) Resource Lookup
From time to time we need to look at obtaining resources from
external DUs. Possible reasons include anything from allowing a DU
to provide a splash screen, new menu items, or other things. We
need to look at differences in strategies to obtain the information.
Active vs. Passive. An Active DU will publish certain resources to
the DU API, to allow the application to look up the resource. A
passive DU will allow the API to inspect the contents to find the
resource. Which one makes the most sense?
Lookup vs. Explicit Knowlege. Avalon kind of requires component
writers to have explicit knowlege of what components can be found,
and it does not allow the component to explore the components that
are available. There are a number of reasons for doing that, however
I think it would be good to carry this forward into the API. The
alternative is to allow the DUs to lookup information, and allow the
DU API to be sort of the "Resource Container" and resolve those
requests by doing the Mac Bundle style resource resolution.
3) DU Loading and Caching
In order to predictably handle DU management, we have to look at
the classloading issues. In fact the API should handle these aspects
for the container. The best solution I can think of would be to have
a unique classloader per partition.
We also need to look at the possibility of having internal JARs in
the DU for separation of Interface and Implementation. The
separation would facilitate the ability to provide different
implementations per partition.
We also need to be able to load and unload the DUs from the system.
4) DU Building
The API should allow us to build a DU at runtime. That will
both help with IDEs and tools, but it will also help with dynamically
generating a DU from an LU (library unit or common JAR).
5) DU Lookup/Remote Resolution
In order to find DUs to satisfy all dependencies for a system,
we need to look at the possibility of working within Apache's
infrastructure and taking advantage of the mirroring that goes
on here. It might be that we use Meta Information to record where
the DU expects to find its dependencies, but it should be there.
Also in any distributed environment, we need to look at security,
and at the *very* least ensuring that the DU we locate is the one
we needed. That can be accomplished by storing the MD5 signature
in the meta info, and validating the downloaded file. That will
protect against JAR corruption or invalid JARs. Signing is another
level of security altogether.
6) Security Management
The Java Security Manager infrastructure is very limited in the
respect that it is global. We might need to extend that security
manger concept by providing a way to set a security manager _per_
_partition_. That would require having a real dumb security manager
that forwards all its permissions requests to the DU API which would
allow the container/application to set a security manager for the
particular partition. Since the partitions would be enforced at this
level, that might be the only way of doing it. On the other hand,
this might be out of scope.
Thoughts, comments?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 19 May 2003 04:00 am, Peter Donald wrote:
> On Sun, 18 May 2003 07:53 am, Niclas Hedhman wrote:
> > One thing I sort of "dislike" in Avalon lookup is the use of ROLE strings
> > instead of Class (interface) lookup. Why was strings chosen, since I
> > still need the interface to be able to access it in any useful manner?
>
> FWIW that was one of our initial designs. The problems is that it makes it
> more difficult for writing isolated containers, or those that support below
> funcitonality or "passive" API modules.
I still prefer the Jini lookup pattern, and its associated Discovery events.
Probably you think it is an overkill, but the fact that you can have multiple
Service interfaces per service, and service attributes runtime assignable,
which I use for the given "stdout" / "stderr" example given by Leo.
Nevertheless, I recommend the Avaloners to take a close look of what patterns
it offers, since I think that there are some nuggets to pick up.
I will probably patch Phoenix to use Jini anyway, but I'm sure you all guys
would do a much greater analytical assessment of what should actually be
done.
Cheers.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Avalon Bundles/Distribution Units
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> > The only thing I can think of would be that I want a particular
> > variant
> > (impl) of the interface, but to me it doesn't validate such
> pattern...
>
> Thats actually a fairly common usage pattern in applications that I
develope.
> ECM/Fortress forces that the lookup key matches the service name but
Phoenix
> doesn't which is why ECM/Fortress requires the whole notion of a
*Selectors.
Actually, it doesn't if you split hairs... The basic idea was that -
suppose you
have two Output services, standard and error (like stdout and stderr),
and you're
going to do lookup on them:
Phoenix style (I think):
Output stdout = (Output) manager.lookup ("stdout");
Output stderr = (Output) manager.lookup ("stderr");
ECM style (what everyone was supposed to be doing):
ComponentSelector selector = (ComponentSelector) manager.lookup
(Output.ROLE);
Output stdout = (Output) selector.select ("std");
Output stderr = (Output) selector.select ("err");
ECM style (what everyone did because the above was too ugly to bear):
Output stdout = (Output) manager.lookup (Output.ROLE + "/stdout");
Output stderr = (Output) manager.lookup (Output.ROLE + "/stderr");
Minor point, but the above is basically what ground has already been
covered.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Donald <pe...@realityforge.org>.
On Sun, 18 May 2003 07:53 am, Niclas Hedhman wrote:
> So, you are proposing that the "Factory" binds the external service to the
> Avalon kernel hashmap?
Nah - the factory just creates the component. Then it is up to the kernel to
grab the created object and associate with a name (or not depending on what
it wants to do).
> One thing I sort of "dislike" in Avalon lookup is the use of ROLE strings
> instead of Class (interface) lookup. Why was strings chosen, since I still
> need the interface to be able to access it in any useful manner?
FWIW that was one of our initial designs. The problems is that it makes it
more difficult for writing isolated containers, or those that support below
funcitonality or "passive" API modules.
> The only thing I can think of would be that I want a particular variant
> (impl) of the interface, but to me it doesn't validate such pattern...
Thats actually a fairly common usage pattern in applications that I develope.
ECM/Fortress forces that the lookup key matches the service name but Phoenix
doesn't which is why ECM/Fortress requires the whole notion of a *Selectors.
--
Cheers,
Peter Donald
-----------------------------------------------------
When a stupid man is doing something he's ashamed of,
he always declares that it is his duty.
George Bernard Shaw
-----------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Thursday 15 May 2003 08:32 pm, Peter Donald wrote:
> Hmmm... Need to think a little bit more about it.
>
> One thing I sort of "dislike" in Avalon lookup is the use of ROLE strings
> instead of Class (interface) lookup. Why was strings chosen, since I still
> need the interface to be able to access it in any useful manner?
> The only thing I can think of would be that I want a particular variant (impl)
> of the interface, but to me it doesn't validate such pattern...
That had a lot more to do with classloader issues than anything else.
Strings allows us to be much more flexible in terms of classloader
heirarchies.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 15 May 2003 08:32 pm, Peter Donald wrote:
> On Sat, 17 May 2003 05:25 am, Niclas Hedhman wrote:
> > > However internally the kernel will use some sort of listing service and
> > > JNDI may be the interface but I assume we could always switch to JINI I
> > > guess or whatever - thats simply a implementation detail.
> >
> > Instead of being an "implementation detail", couldn't it be an assembly
> > or deployment detail? In which case it becomes a design issue now ;o)
>
> Possibly - how do you see it working? I can not ever see a need for more
> than a fancy hashmap in kernel space to be honest. If I wanted to have a
> remote object as part of my application I would probably do something like
> the following.
>
> <assembly version="1.1">
>
> <factory name="rmi-factory" class="com.biz.RMIFactory"/>
> ...
> <block name="myRemoteObject"
> implementationKey="rmi://www.realityforge.org/MyRemoteObject"
> factory="rmi-factory" />
> ...
> </assembly>
So, you are proposing that the "Factory" binds the external service to the
Avalon kernel hashmap?
Hmmm... Need to think a little bit more about it.
One thing I sort of "dislike" in Avalon lookup is the use of ROLE strings
instead of Class (interface) lookup. Why was strings chosen, since I still
need the interface to be able to access it in any useful manner?
The only thing I can think of would be that I want a particular variant (impl)
of the interface, but to me it doesn't validate such pattern...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 17 May 2003 05:25 am, Niclas Hedhman wrote:
> > However internally the kernel will use some sort of listing service and
> > JNDI may be the interface but I assume we could always switch to JINI I
> > guess or whatever - thats simply a implementation detail.
>
> Instead of being an "implementation detail", couldn't it be an assembly or
> deployment detail? In which case it becomes a design issue now ;o)
Possibly - how do you see it working? I can not ever see a need for more than
a fancy hashmap in kernel space to be honest. If I wanted to have a remote
object as part of my application I would probably do something like the
following.
<assembly version="1.1">
<factory name="rmi-factory" class="com.biz.RMIFactory"/>
...
<block name="myRemoteObject"
implementationKey="rmi://www.realityforge.org/MyRemoteObject"
factory="rmi-factory" />
...
</assembly>
Essentially you define the factory you use to create the component in the
SAR-INF/assembly.xml and then when defining the component use
"implementationKey" and "factory" attributes rather than class attribute to
define block.
Thus to enable JINI you simply write your own factory and hook it up as you
want.
FWIW I actually had a fork of Phoenix that already did this and you could link
in SOAP, CORBA, RMI objects. I was also going to add Altrmi and dynamically
generated objects (dynamically generated by BCEL from schemas). It worked
quite well.
The one failing was that you really needed a mechanism to indicate that some
components were "optional" and if they failed to startup it would not cause
application to shutdown.
> If you have ever worked with Jini seriously,
Nah - it looks kool but never had opportunity to play and I was scared off by
licensing ;/
--
Cheers,
Peter Donald
*----------------------------------------------*
| "Always forgive your enemies. Nothing annoys |
| them more." -Oscar Wilde |
*----------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by J Aaron Farr <ja...@yahoo.com>.
On Mon, 2003-05-26 at 19:14, Stephen McConnell wrote:
> J Aaron Farr wrote:
>
> >Even if underneath you're using something like AltRMI, allowing
> >JNDI lookups of arbitrary components opens the system up to a number of design
> >pattern abuses. What's to stop someone from using Merlin or Pheonix as
> >essentially on object broker?
> >
>
> Isolation.
>
[snip]
Very good point. That's exactly the idea I was looking for and didn't
understand. Thanks!
>
> In the servlet environment you cannot do a clean lifecycle model -
> unless you accept to move to a non-standard servlet container. But this
> means your servlet is locked into that container. If you want to
> maintain servlet portability then your options are more limited - and
> you get into the tradeoffs your describing.
>
> Cheers, Steve.
This is the conundrum I've found myself in a couple of times.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 28 May 2003 04:10 am, Niclas Hedhman wrote:
> A distributed app is, for instance, a server application, running on N
> systems, and don't really care where it is executing, can be spawned for
> scalability and system-fault tolerance (by itself very tricky, largely
> depending on application type). With proper modularity (components) scaling
> can occur at bottlenecks, and not at "full-server", level.
>
> There are no solutions avaiable at the generic level available at the
> moment, and _I_ believe it is the "killer framework" awaiting to be
> "invented" in the next couple of years. But what do I know? ;o)
It would require too many abstractions over non-isolateable/transferable
resource (aka Sockets) to do it generically I think. However it would be
cool to have a toolkit that enabled clustering.
In the future with a ldapd server to manage configuration and another server
to manage download of application .sars we should be able to do this sort of
clustering/swarming of applications.
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by J Aaron Farr <ja...@yahoo.com>.
On Tue, 2003-05-27 at 14:10, Niclas Hedhman wrote:
> On Monday 26 May 2003 03:14 pm, Stephen McConnell wrote:
> > When you say "distributed applications" - what sort of distribution are
> > you thinking about? Distinctions I have in mind include "distribution by
> > value" (as in JNLP style) or "distribution client/server" (e.g.
> > IIOP/RMI), or "peer-to-peer" (more fun and typically involve a
> > composition of both of previous style of distribution).
>
> Not sure what Aaron means by distributed applications, but both your Value and
> C/S "style" is not pure "distributed apps", more a communication, location
> and "who is in control" method. Peer-to-Peer is more like it, and YES, they
> often need some of the "Value" and "C/S" methods to be made work.
>
> A distributed app is, for instance, a server application, running on N
> systems, and don't really care where it is executing, can be spawned for
> scalability and system-fault tolerance (by itself very tricky, largely
> depending on application type). With proper modularity (components) scaling
> can occur at bottlenecks, and not at "full-server", level.
I'm currently facing a couple of "distributed" application situations:
1. Classic client/server -- nothing really to elaborate on here
2. Multiple Avalon Containers --
Perhaps this isn't a typical distributed application, but it's
something I'm running into now. In one case I have a standalone
application which uses Fortress. It has a swing front end and is used
essentially as a client. One the other hand I also have a Merlin-based
application running as a service/daemon. So I have two Avalon
containers in separate virtual machines and sometimes they need to use
similar services. I've considered a couple of ways that the Fortress
components could access services provided by the Merlin container, but I
would prefer it if this could be accomplished without the individual
components knowing if the services are hosted in Fortress or Merlin. In
other words, the component looks up it's dependent service via the
ServiceManager just as if it were local. Theoretically, the idea could
be extended to VM's running on separate PC's completely.
3. Distributed Deployment --
In the case of our Fortress and Merlin applications we have something
like 70 clients running these two applications. "Pre-Avalonization"
each client ran identical code but was configured via a local property
file. The jar files were hosted on a public shared directory which
eased our deployment considerably. Just drop the jar files onto the
server and wa-la! all the clients pick up the new updates as soon as
they are restarted.
This solution has a number of advantages and disadvantages. We've
also started using Java WebStart (JNLP) for some deployments, but again,
there are a number of pros and cons. What is needed is a way that
allows for local configuration and caching (for offline use) but a
single point of deployment. JNLP provides most of this, but becomes
tricky when deploying something like a Merlin-based server and many JNLP
clients have performance issues.
The solution I'm looking into now is combining Maven and it's concept
of a remote repository with Merlin's concept of a repository. It would
allow for blocks to be configured locally but downloaded from the remote
Maven repository to the local Merlin repository. Even better it allows
us to take advantage of Maven's build and deployment tools.
This solutions still has some drawbacks from JNLP since currently for
Merlin the block files are local. However, I imagine there might be a
way to have the block files located on a remote server (perhaps in the
Maven repository) and then have some sort of way to tell Merlin to
download, cache and run them. I'm still looking into this part.
> There are no solutions avaiable at the generic level available at the moment,
> and _I_ believe it is the "killer framework" awaiting to be "invented" in the
> next couple of years. But what do I know? ;o)
>
>
> Niclas
+1
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 26 May 2003 03:14 pm, Stephen McConnell wrote:
> When you say "distributed applications" - what sort of distribution are
> you thinking about? Distinctions I have in mind include "distribution by
> value" (as in JNLP style) or "distribution client/server" (e.g.
> IIOP/RMI), or "peer-to-peer" (more fun and typically involve a
> composition of both of previous style of distribution).
Not sure what Aaron means by distributed applications, but both your Value and
C/S "style" is not pure "distributed apps", more a communication, location
and "who is in control" method. Peer-to-Peer is more like it, and YES, they
often need some of the "Value" and "C/S" methods to be made work.
A distributed app is, for instance, a server application, running on N
systems, and don't really care where it is executing, can be spawned for
scalability and system-fault tolerance (by itself very tricky, largely
depending on application type). With proper modularity (components) scaling
can occur at bottlenecks, and not at "full-server", level.
There are no solutions avaiable at the generic level available at the moment,
and _I_ believe it is the "killer framework" awaiting to be "invented" in the
next couple of years. But what do I know? ;o)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Stephen McConnell <mc...@apache.org>.
J Aaron Farr wrote:
>--- Niclas Hedhman <ni...@hedhman.org> wrote:
>
>>On Thursday 15 May 2003 07:30 pm, Peter Donald wrote:
>>
>>>On Sat, 17 May 2003 05:03 am, Niclas Hedhman wrote:
>>>
>>>>I have seen proposals that JNDI is going to be used for "lookup".
>>>>
>>>It is unlikely that JNDI is going to be used from within the components
>>>themselves. We have been though that about a billion times in the past and
>>>basically we either have to compromise on quality and break IOC or make the
>>>components the same "weight" as EJBs which we are loath to do.
>>>
>>Understood, and not what I meant.
>>
>
>However, this has been something on my mind.
>
>If Avalon containers offer components (blocks, services, appliances, what have
>you) up for JNDI lookups to clients, well, then isn't that getting awfully
>close to EJB?
>
More along the lines of awfully compatible!
>Even if underneath you're using something like AltRMI, allowing
>JNDI lookups of arbitrary components opens the system up to a number of design
>pattern abuses. What's to stop someone from using Merlin or Pheonix as
>essentially on object broker?
>
Isolation.
JNDI is a naming and directory service - the naming side provides a
convenient naming scheme that is hierarchical in nature which is
convenient for mapping hierarchical component addresses. As a directory,
JNDI provides mechanisms for searching and location of objects - so
applying this to the Avalon context, JNDI can be viewed as a service
broker - however - this isn't anything to be scared about - providing
there is support for the isolation of the services that are made available.
If you take something like the James system, you could look at that and
assume that the corresponding JNDI view would be the suite of components
that up James (rather a lot). That is undesirable. What is desirable is
a managed disclosure - for example, I may want to expose only the mailet
API through JNDI - but that requires isolation of the components and
services that make up the James implementation from the services that
James exports. With an isolation model things become more manageable and
you simply look at JNDI as a standard mechanisms for container to locate
services from whatever it is that is generating the services (Fortress,
Merlin, Phoenix, Xxxxx). The container is then responsible for
propagating those service references as it sees fit.
Anyway - that's my view on the potential JNDI/Avalon services relationship.
>Having said that, I sorta want an Avalon object broker (kinda like EOB). When
>designing a single standalone application or server, the Avalon framework
>shines. More importantly, the framework almost requires you to use good design
>patterns like IoC. But I'm having real difficulties extending that framework
>over distributed applications (and maybe I'm just not skilled enough yet).
>
When you say "distributed applications" - what sort of distribution are
you thinking about? Distinctions I have in mind include "distribution by
value" (as in JNLP style) or "distribution client/server" (e.g.
IIOP/RMI), or "peer-to-peer" (more fun and typically involve a
composition of both of previous style of distribution).
For the distribution JNLP style - the main issue is to get in place the
repository so we can maintain properly signed jar files. For the
client/server style distribution I've got a implementation of a
"special" appliance that automates the marshalling of incoming client
requests and the forward of these requests to component implementations
(servants). Also, I’m using serializable objects, you can auto deploy
components on the client side - basically you treat the incoming
serialized object and an non-initialized component and deploy in
dynamically as in comes in off the wire. For the peer-to-peer stuff,
what I've done in the past is to combine these two approaches (although
in the past I have not used JNLP). Anyhow, a combination of a broker
(backed by a repository) is a central element to the physical deployment
of the resources to nodes in the distributed environment.
> For
>example, I don't know of an obvious solution to getting a handle on an Avalon
>container or service in a Struts Action or JSP tag. In another situation,
>we're trying to make our rich Swing clients less rich by moving business logic
>to a server. If the client moves to say a Fortress app and the server is
>Merlin or Pheonix, well it seems like there should be a way to access services
>running in another container. One solution, as mentioned, is JNDI lookups
>across the containers, but, well, that just doesn't "feel" right to me.
>
In something like a web application the JNDI approach has the advantage
of eliminating the lock-in to a particular container. The only other
alternatives are to use something like the ServiceManager/Selector
interfaces as a wrapper to a container/kernel - but that feels worse to
me because (a) I don't think it is sufficiently flexible, and (b) it
locks the client into a non-standard API.
In the servlet environment you cannot do a clean lifecycle model -
unless you accept to move to a non-standard servlet container. But this
means your servlet is locked into that container. If you want to
maintain servlet portability then your options are more limited - and
you get into the tradeoffs your describing.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by J Aaron Farr <ja...@yahoo.com>.
--- Niclas Hedhman <ni...@hedhman.org> wrote:
> On Thursday 15 May 2003 07:30 pm, Peter Donald wrote:
> > On Sat, 17 May 2003 05:03 am, Niclas Hedhman wrote:
> > > I have seen proposals that JNDI is going to be used for "lookup".
> >
> > It is unlikely that JNDI is going to be used from within the components
> > themselves. We have been though that about a billion times in the past and
> > basically we either have to compromise on quality and break IOC or make the
> > components the same "weight" as EJBs which we are loath to do.
>
> Understood, and not what I meant.
However, this has been something on my mind.
If Avalon containers offer components (blocks, services, appliances, what have
you) up for JNDI lookups to clients, well, then isn't that getting awfully
close to EJB? Even if underneath you're using something like AltRMI, allowing
JNDI lookups of arbitrary components opens the system up to a number of design
pattern abuses. What's to stop someone from using Merlin or Pheonix as
essentially on object broker?
Having said that, I sorta want an Avalon object broker (kinda like EOB). When
designing a single standalone application or server, the Avalon framework
shines. More importantly, the framework almost requires you to use good design
patterns like IoC. But I'm having real difficulties extending that framework
over distributed applications (and maybe I'm just not skilled enough yet). For
example, I don't know of an obvious solution to getting a handle on an Avalon
container or service in a Struts Action or JSP tag. In another situation,
we're trying to make our rich Swing clients less rich by moving business logic
to a server. If the client moves to say a Fortress app and the server is
Merlin or Pheonix, well it seems like there should be a way to access services
running in another container. One solution, as mentioned, is JNDI lookups
across the containers, but, well, that just doesn't "feel" right to me.
Again, maybe my distributed design pattern skills just aren't strong enough
yet. Perhaps someone would like to enlighten me?
Thanks,
jaaron
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 15 May 2003 07:30 pm, Peter Donald wrote:
> On Sat, 17 May 2003 05:03 am, Niclas Hedhman wrote:
> > I have seen proposals that JNDI is going to be used for "lookup".
>
> It is unlikely that JNDI is going to be used from within the components
> themselves. We have been though that about a billion times in the past and
> basically we either have to compromise on quality and break IOC or make the
> components the same "weight" as EJBs which we are loath to do.
Understood, and not what I meant.
> However internally the kernel will use some sort of listing service and
> JNDI may be the interface but I assume we could always switch to JINI I
> guess or whatever - thats simply a implementation detail.
Instead of being an "implementation detail", couldn't it be an assembly or
deployment detail? In which case it becomes a design issue now ;o)
> However I haven't
> seen anyone seriously talking about distributed network assemblies that
> would require either of those technologies.
And I am not qualified to start, but...
If you have ever worked with Jini seriously, you will probably (I did)
afterwards find that you can't live without the "service life cycle
notification" system, not even in in-process services.
And once you get your head around "service not available" in your app design,
there are "often" fall-back strategies, such as queueing service requests,
alternative routes to accomlish same or similar result, and more.
Also, the asynchronicity of networked services is another aspect of the same
"service not available" and in a Jini development team absolutely natural.
(Not, we have only used Jini for client-server solutions, not for devices as
it was intended.)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 17 May 2003 05:03 am, Niclas Hedhman wrote:
> I have seen proposals that JNDI is going to be used for "lookup".
It is unlikely that JNDI is going to be used from within the components
themselves. We have been though that about a billion times in the past and
basically we either have to compromise on quality and break IOC or make the
components the same "weight" as EJBs which we are loath to do.
However internally the kernel will use some sort of listing service and JNDI
may be the interface but I assume we could always switch to JINI I guess or
whatever - thats simply a implementation detail. However I haven't seen
anyone seriously talking about distributed network assemblies that would
require either of those technologies.
--
Cheers,
Peter Donald
Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary. No such faith comforts the software
engineer.
- Fred Brooks, Jr.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Niclas Hedhman <ni...@hedhman.org>.
I have seen proposals that JNDI is going to be used for "lookup".
I don't like this idea at all.
Could we/you include a mechanism for pluggable "lookup systems"?
Sounds fairly easy, and there could be a couple of implementations available
out of the box;
1. In-process
2. JNDI
3. JINI - my personal favourite, since it deals with "service
availability/notification"
Makes sense?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 16 May 2003 12:00 am, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Thu, 15 May 2003 11:49 pm, Berin Loritsch wrote:
> >>I understand, but did you catch the gist of the problem? Let's say I
> >>deploy my application in Japan. The default Locale is Japan, but unless
> >>we make sure all the bundles in the applicaiton support that locale,
> >>we will have some messages from Japan and some from another locale.
> >
> > Then the application is broken.
>
> No the bundle API is broken.
try telling your customers that.
> If the default locale is Japanese, but the only locale all bundles
> support is English, then the application should use the English
> locale. It's that simple.
I doubt the customers would appreciate this approach.
Besides I don't see what relevence these points have wrt to a generic resource
access API. You can easily model these buisness rules on layer above so why
clutter up the API with it?
> > And nor should you as the component already knows what services it needs
> > and what roles the services play.
>
> Exactly. The question is do we want this for the resource lookup?
> It affects what the API will look like.
Avalon is not a resource management API despite the hacks that have been added
to it so why try to make it one?
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Thu, 15 May 2003 11:49 pm, Berin Loritsch wrote:
>
>>I understand, but did you catch the gist of the problem? Let's say I
>>deploy my application in Japan. The default Locale is Japan, but unless
>>we make sure all the bundles in the applicaiton support that locale,
>>we will have some messages from Japan and some from another locale.
>
>
> Then the application is broken.
No the bundle API is broken. The bundle API should be able to limit the
choice of language based on what the set of bundles are. Let's say I
am using a third party bundle, and it supports more locales than I do.
If my application is used outside its target area (not unlikely for
open source projects), we need to limit the choices to ensure the
application does not appear broken.
If the default locale is Japanese, but the only locale all bundles
support is English, then the application should use the English
locale. It's that simple.
>>are available. I.e. you cannot lookup names.
>
>
> And nor should you as the component already knows what services it needs and
> what roles the services play.
Exactly. The question is do we want this for the resource lookup?
It affects what the API will look like.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 16 May 2003 12:18 am, Berin Loritsch wrote:
> The important thing is that the bundle declare what it supports.
> Or are you against that?
right. But metadata about a resource and the presence of the resource in a
directory are othogonal concepts.
> Yep, so how does the runtime environment determine what is supported,
> and what isn't? I mean we do this to ensure all required services
> are present in our containers don't we?
We check the metadata for a resource.
--
Cheers,
Peter Donald
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: [RT] Avalon Bundles/Distribution Units [LCD l10n wrt resource management API]
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello, Developers!
Personally me, I've been dreaming for years about this kind of
functionality... ...so me too! :-))
PD> I don't see what relevence these points have wrt to a generic resource
PD> access API.
PD> Avalon is not a resource management API despite the hacks that have been added
PD> to it so why try to make it one?
Dunno for sure, but l10n seems to be a concern crosscutting almost
any kind of software, probably will be nice to have some support?
PD> ... what relevence does this have to the API?
PD> This is not an API question but a policy for usage and instantiation of a
PD> resource.
I)
Maybe this can be handled DECLARATIVELY via a POLICY?
Policy examples:
- LCD
- LCD, but JA should be supported by everyone - otherwise complain loudly
- some other policy to complain loudly in some other case
- MIXED (serve mixed locale content)
II)
Semi-orthogonally to this the code that chooses the locale would
benefit from knowing what locales are available (the policy can
affect this: for LCD it would be the intersection, for MIXED -
union).
Dunno if such code should be normal component code (and then
this info may be retrievable via a special API call) or
special-purpose call-back code (bundle or partition scoped),
and then such callback would receive the list via its method
arguments)
BL> What I am proposing is that the bundles be able to *declare* what
BL> locales they support. What to do with it from there on is up to
BL> the user of the API. Whether it is verification, the LCD approach,
BL> or allowing the user to extend the bundle to include the new values,
BL> etc. that's fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 16 May 2003 12:02 am, Peter Royal wrote:
>
>>Lets visualize that bundles are being used as plugins. The default
>>locale is japan.
>>
>>Bundle (plugin) A supports japanese and english
>>Bundle B supports only english.
>>
>>Should the application drop down and switch to english globally
>>(essentially what Berin is proposing I believe, the LCD approach), or
>>should the app display partial english / japanese (what you are
>>proposing I believe) and be broken?
>
>
> Personally I would do the second but what relevence does this have to the API?
> This is not an API question but a policy for usage and instantiation of a
> resource.
What I am proposing is that the bundles be able to *declare* what
locales they support. What to do with it from there on is up to
the user of the API. Whether it is verification, the LCD approach,
or allowing the user to extend the bundle to include the new values,
etc. that's fine.
The important thing is that the bundle declare what it supports.
Or are you against that?
>
>
>>Since bundles will be able to extend other bundles, it should be
>>possible to extend a bundle to add an additional l10n, right?
>
>
> Yep.
>
Yep, so how does the runtime environment determine what is supported,
and what isn't? I mean we do this to ensure all required services
are present in our containers don't we?
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Royal <pr...@apache.org>.
On Thursday, May 15, 2003, at 10:17 AM, Peter Donald wrote:
>> Should the application drop down and switch to english globally
>> (essentially what Berin is proposing I believe, the LCD approach), or
>> should the app display partial english / japanese (what you are
>> proposing I believe) and be broken?
>
> Personally I would do the second but what relevence does this have to
> the API?
> This is not an API question but a policy for usage and instantiation
> of a
> resource.
No direct relevance to the API, just trying to expound upon your views
to help Berin see where you are coming from (policy vs handling in api)
:)
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 16 May 2003 12:02 am, Peter Royal wrote:
> Lets visualize that bundles are being used as plugins. The default
> locale is japan.
>
> Bundle (plugin) A supports japanese and english
> Bundle B supports only english.
>
> Should the application drop down and switch to english globally
> (essentially what Berin is proposing I believe, the LCD approach), or
> should the app display partial english / japanese (what you are
> proposing I believe) and be broken?
Personally I would do the second but what relevence does this have to the API?
This is not an API question but a policy for usage and instantiation of a
resource.
> Since bundles will be able to extend other bundles, it should be
> possible to extend a bundle to add an additional l10n, right?
Yep.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Royal <pr...@apache.org>.
On Thursday, May 15, 2003, at 09:59 AM, Peter Donald wrote:
> On Thu, 15 May 2003 11:49 pm, Berin Loritsch wrote:
>> I understand, but did you catch the gist of the problem? Let's say I
>> deploy my application in Japan. The default Locale is Japan, but
>> unless
>> we make sure all the bundles in the applicaiton support that locale,
>> we will have some messages from Japan and some from another locale.
>
> Then the application is broken.
Well, yes, but how would you propose handling the situation?
Lets visualize that bundles are being used as plugins. The default
locale is japan.
Bundle (plugin) A supports japanese and english
Bundle B supports only english.
Should the application drop down and switch to english globally
(essentially what Berin is proposing I believe, the LCD approach), or
should the app display partial english / japanese (what you are
proposing I believe) and be broken?
The way to handle it may be for an application to say "i support
locales X, Y, Z", and it is up to the application developer to ensure
all bundles that they are using support all required locales...
Since bundles will be able to extend other bundles, it should be
possible to extend a bundle to add an additional l10n, right?
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 15 May 2003 11:49 pm, Berin Loritsch wrote:
> I understand, but did you catch the gist of the problem? Let's say I
> deploy my application in Japan. The default Locale is Japan, but unless
> we make sure all the bundles in the applicaiton support that locale,
> we will have some messages from Japan and some from another locale.
Then the application is broken.
> Right. However the interface doesn't allow you to look up what *roles*
You mean services.
> are available. I.e. you cannot lookup names.
And nor should you as the component already knows what services it needs and
what roles the services play.
--
Cheers,
Peter Donald
----------------------------------------
Whatever you do will be insignificant,
but it is very important that you do it.
--Gandhi
----------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Thu, 15 May 2003 11:18 pm, Berin Loritsch wrote:
>
>>Peter Donald wrote:
>>
>>>On Sat, 10 May 2003 01:12 am, Berin Loritsch wrote:
>>>
>>>>3) Internationalization/Localization (I18N and L10N)
>>>
>>>Why does this need to be specially handled - is it just not another
>>>example of context sensitive resource access?
>>
>>Yes it is context sensitive, however in order to present a unified
>>language to the user, we need to know what languages the bundle supports
>>so that we can choose the best one from the working set.
>
>
> Use the existing architecture to do this. Work from language group to language
> to default locale. ie en_us -> en -> default. To be honest I have never seen
> a case where a user would choose a preference of languages ranging from
> japenese to french to english. Any application that fails to find i18n
> resources in correct locale is generally considered broken in my experience.
I understand, but did you catch the gist of the problem? Let's say I
deploy my application in Japan. The default Locale is Japan, but unless
we make sure all the bundles in the applicaiton support that locale,
we will have some messages from Japan and some from another locale.
>>The question I had in this case was do we want to expose all the
>>resource names so that we can iterate through them and discover
>>what is available, or cary forward the ServiceManager view and require
>>the component writer to explicitly know the name?
>
>
> It is not the component writers concern but an assemblers concern. The
> component writer does not know what components are implementing the roles it
> requires it just declares dependencies on the roles.
Right. However the interface doesn't allow you to look up what *roles*
are available. I.e. you cannot lookup names.
>
> An assembler component may have access to this information but I would
> hesitate to put that in user space and consider it a kernel component and the
> kernel component should definetly have access to resource registry in LU.
>
I agree.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 15 May 2003 11:18 pm, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Sat, 10 May 2003 01:12 am, Berin Loritsch wrote:
> >>3) Internationalization/Localization (I18N and L10N)
> >
> > Why does this need to be specially handled - is it just not another
> > example of context sensitive resource access?
>
> Yes it is context sensitive, however in order to present a unified
> language to the user, we need to know what languages the bundle supports
> so that we can choose the best one from the working set.
Use the existing architecture to do this. Work from language group to language
to default locale. ie en_us -> en -> default. To be honest I have never seen
a case where a user would choose a preference of languages ranging from
japenese to french to english. Any application that fails to find i18n
resources in correct locale is generally considered broken in my experience.
> The question I had in this case was do we want to expose all the
> resource names so that we can iterate through them and discover
> what is available, or cary forward the ServiceManager view and require
> the component writer to explicitly know the name?
It is not the component writers concern but an assemblers concern. The
component writer does not know what components are implementing the roles it
requires it just declares dependencies on the roles.
An assembler component may have access to this information but I would
hesitate to put that in user space and consider it a kernel component and the
kernel component should definetly have access to resource registry in LU.
--
Cheers,
Peter Donald
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Sat, 10 May 2003 01:12 am, Berin Loritsch wrote:
>
>>3) Internationalization/Localization (I18N and L10N)
>
>
> Why does this need to be specially handled - is it just not another example of
> context sensitive resource access?
Yes it is context sensitive, however in order to present a unified
language to the user, we need to know what languages the bundle supports
so that we can choose the best one from the working set.
For example:
Bundle 1 supports en_US, fr, es, jp
Bundle 2 supports en_US, fr, es
Bundle 3 supports en_US, es
If we had an application that had this spread of i18n supported locales,
and we did not account for what the bundle supported, then users would
have Japanese (jp) messages for what was in Bundle 1 but whatever the
secondary language was for the other bundles.
If the user's preferences for i18n are in the order of jp, fr, en_US
then they would have the worst experience (Bundle 1 would be Japanese,
Bundle 2 would be French, and Bundle 3 would be US English).
By allowing the bundles to declare what they support, we can make
a more intelligent solution. We can take into account the fact that
the only two locales that are supported in ALL bundles are en_US and
es. Now we can ensure that the user would be able to have a
consistent user experience. If Bundle 3 were upgraded to include
the fr locale, then our user would be able to see French. If
Bundles 2 and 3 were upgraded to include the jp locale, then
the user could have their first choice.
>>Things that the API needs to provide:
>>
>>1) App Domains/Partitioning
>> A DU will be specific to a partition. In .NET speak this is an
>> App Domain. A Partition can be either an application, or a part
>> of an application. We need to define its boundaries.
>
>
> Nope. App Domains are roughly equivelent to Isolates that will be in the Tiger
> JDK release and are not logical containments but physical isolation domains.
> They could be used to implement the Isolated Partitions that I have discussed
> in the past but thats simply a implementation detail/
Ok. Maybe I got an incorrect impression.
>
>
>>2) Resource Lookup
>> Lookup vs. Explicit Knowlege. Avalon kind of requires component
>> writers to have explicit knowlege of what components can be found,
>
>
> No it does not as I have outlined before. All you need do is declare a
> resource and an associated type. This is still passive but it does require
> some agreement on how to instantiate different types of resources. ie if I
> declare resource "com.biz.MyComponent" of type
> "http://avalon.apache.org/component/1.0". If we assume any resource string of
> type "htpp://avalon.apache.org/component/1.0" indicates classname of
> component in LU then we have a way to construct the component. Each
> indidivudal resource type would have different mechanisms to instantiate
> resources.
>
My point is that no component can query the ServiceManager to see what
is there to look up. In Phoenix and Merlin everything is explicitly
declared so that the container knows the interface (i.e. in this case
resource name) to obtain the component. Where it gets the
implementation is not the component user's concern.
The question I had in this case was do we want to expose all the
resource names so that we can iterate through them and discover
what is available, or cary forward the ServiceManager view and require
the component writer to explicitly know the name?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 10 May 2003 01:12 am, Berin Loritsch wrote:
> 3) Internationalization/Localization (I18N and L10N)
Why does this need to be specially handled - is it just not another example of
context sensitive resource access?
> Things that the API needs to provide:
>
> 1) App Domains/Partitioning
> A DU will be specific to a partition. In .NET speak this is an
> App Domain. A Partition can be either an application, or a part
> of an application. We need to define its boundaries.
Nope. App Domains are roughly equivelent to Isolates that will be in the Tiger
JDK release and are not logical containments but physical isolation domains.
They could be used to implement the Isolated Partitions that I have discussed
in the past but thats simply a implementation detail/
> 2) Resource Lookup
> Lookup vs. Explicit Knowlege. Avalon kind of requires component
> writers to have explicit knowlege of what components can be found,
No it does not as I have outlined before. All you need do is declare a
resource and an associated type. This is still passive but it does require
some agreement on how to instantiate different types of resources. ie if I
declare resource "com.biz.MyComponent" of type
"http://avalon.apache.org/component/1.0". If we assume any resource string of
type "htpp://avalon.apache.org/component/1.0" indicates classname of
component in LU then we have a way to construct the component. Each
indidivudal resource type would have different mechanisms to instantiate
resources.
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> just playing devil's advocate some more.....
>
> Berin Loritsch wrote:
>
>>> why not just use .Net?
>
>
> > [we don't know how to program .Net yet; there is no free version of
> .Net, there is no free .Net support for java; many (free) tools which
> exist for java do not exist for .Net; we might do better than .Net by
> taking concepts from other places as well; in conclusion there is a need
> for a native-java version of this stuff]
>
> fair enough :D. We should just keep in mind that most of these reasons
> will likely no longer exist in a few years time. That might affect some
> decisions :D
We can get this done, or at least workable, in less than "a few year's
time". That is an important consideration.
The good thing about doing it is it makes it easier to apply the same
principles in new languages that haven't even been invented with.
[Spoiler: I am toying with the idea of writing my own language. Nothing
concrete yet, though.]
>
>> One question that also begs to be asked is if this is something that is
>> generic enough to develop in Jakarta Commons, and extend it here.
>
>
> well, yes. OTOH, everything in avalon-framework besides the actual
> XXXble lifecycle interfaces and ServiceManager is generic enough for
> that as well (ie CascadingException, Context, Configuration,
> SAXConfigurationBuilder). Where's the potential community for this stuff
> at?
It is here right now.
>
> Answering this question is trying to strike the balance between doing an
> all-encompassing bloatware and an extremely fragmentized
> doesn't-do-anything 5-levels of abstraction dependency-fragile
> metametametalayer. You never get it perfectly right :D
:)
I am almost positive that there will be more support for distributable
management than for the Avalon classes that despite their usefulness
in other contexts will forever be bound here.
Also, I agree that we need to strike a balance. I don't want any
fragile solutions. I want to keep the dependency list for the bundle
API at a minimum. We need something that works, and works well.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Avalon Bundles/Distribution Units
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> just playing devil's advocate some more.....
By now even the Devil himself would have vanished with a curse
in a puff of smoke. (But feel free to keep fighting.)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Leo Simons <le...@apache.org>.
just playing devil's advocate some more.....
Berin Loritsch wrote:
>> why not just use .Net?
> [we don't know how to program .Net yet; there is no free version of
.Net, there is no free .Net support for java; many (free) tools which
exist for java do not exist for .Net; we might do better than .Net by
taking concepts from other places as well; in conclusion there is a need
for a native-java version of this stuff]
fair enough :D. We should just keep in mind that most of these reasons
will likely no longer exist in a few years time. That might affect some
decisions :D
> One question that also begs to be asked is if this is something that is
> generic enough to develop in Jakarta Commons, and extend it here.
well, yes. OTOH, everything in avalon-framework besides the actual
XXXble lifecycle interfaces and ServiceManager is generic enough for
that as well (ie CascadingException, Context, Configuration,
SAXConfigurationBuilder). Where's the potential community for this stuff at?
Answering this question is trying to strike the balance between doing an
all-encompassing bloatware and an extremely fragmentized
doesn't-do-anything 5-levels of abstraction dependency-fragile
metametametalayer. You never get it perfectly right :D
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Berin Loritsch wrote:
>
>> I have been giving this some more thought, and after looking at
>> ..NET assemblies,
>
>
> <snip/>
>
>> Thoughts, comments?
>
>
> nice SoC, some valuable observations.
>
> I've been looking into .Net internals some more as well. The more I
> think about this, the more I believe what we are basically trying to do
> is add everything from the .Net framework but C# and the class library
> to java.
>
> The obvious thing we should address is "why not just use .Net?"
>
> An answer might be "because we need to do this in an existing java
> environment".
>
> If that is the sole reason, we might still benefit from compatibility
> with at least the concepts of .Net. IOW, Copy the .Net semantics on the
> things you mentioned, 1-to-1, where applicable. Disregarding the shared
> assembly concept for now (which is add-on extra work), we could copy
> over versioning scheme, configuration layout & general format, location,
> tool setup and typical usage, the configuration override and extension
> mechanisms.......dunno.
>
> why not just use .Net?
:) Two reasons:
1) We do not have a core competency in .NET yet.
2) We might want to use concepts from other systems like Mac Bundles or
OSGI active DUs and improve on the core concepts.
We don't have a core competency in .NET because there is no Java.NET
implementation that is free, and the J# crap from M$ still isn't free.
We don't have free access to C# compilers and libraries to be able to
start developing that competency.
We do have a start of the Avalon port to C# in our CVS, but the person
who started developing it hasn't done anything in a long time, and sad
to say I don't have $100 to shell out on C#.NET to play with it.
I *should* be getting a corporate version of it RSN, but that has been
in the pipeline for a couple of weeks now.
Also, by providing these facilities to Java programmers would really
help out a larger group of people.
One question that also begs to be asked is if this is something that is
generic enough to develop in Jakarta Commons, and extend it here.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Berin Loritsch <bl...@apache.org>.
FYI, I posted a query to Jakarta Commons, because this might be
something that we can work on in collaboration with them. It is
a bigger issue than just Avalon, and it can solve many people's
problems.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Avalon Bundles/Distribution Units
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> I've been looking into .Net internals some more as well. The more I
> think about this, the more I believe what we are basically
> trying to do is add everything from the .Net framework but C# and
> the class library to java.
>
> The obvious thing we should address is "why not just use .Net?"
>
> An answer might be "because we need to do this in an existing java
> environment".
Also, because what we're doing is porting language features over to
Java, where we already have the rest of our infrastructure. For example,
is there a Linux CLR available? A *good* *solid* one?
This may be what you meant by "existing java environment", but then I
think you underestimate what your "existing java environment" is:
+ Code, libraries, existing applications etc.
This is small potatoes. I think you can port Java code to .Net/C# quite
easily, if you *really* have to.
+ Programmers skilled in java development.
Consider cost of re-training or replacement. How long until they are as
good
with .Net as they are now with Java? If you bring in new - how long
until they understand the business as well as the ones you are
sacking?
+ Sysadmins.
Maybe you have Linux admins. Throw out. Bring in people skilled in
Windows admin.
And, if you are selling a product that used to run on Linux, well,
revise your business plan so it works on Windows.
I'm sure all the above can be done - a CLR running on Linux (and
*really*
running well, no proof-of-concept BS) would solve much of it, but
really, is this something you want to do?
Switching to .Net isn't just a language switch - it is a whole-business
reorientation.
So the question is: Why use .Net when we can have it all in Java?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Avalon Bundles/Distribution Units
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> I have been giving this some more thought, and after looking at
> ..NET assemblies,
<snip/>
> Thoughts, comments?
nice SoC, some valuable observations.
I've been looking into .Net internals some more as well. The more I
think about this, the more I believe what we are basically trying to do
is add everything from the .Net framework but C# and the class library
to java.
The obvious thing we should address is "why not just use .Net?"
An answer might be "because we need to do this in an existing java
environment".
If that is the sole reason, we might still benefit from compatibility
with at least the concepts of .Net. IOW, Copy the .Net semantics on the
things you mentioned, 1-to-1, where applicable. Disregarding the shared
assembly concept for now (which is add-on extra work), we could copy
over versioning scheme, configuration layout & general format, location,
tool setup and typical usage, the configuration override and extension
mechanisms.......dunno.
why not just use .Net?
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org