You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Andrzej Jan Taramina <an...@chaeron.com> on 2002/12/22 19:52:26 UTC
Suitability of Avalon for embedded environments?
I was wondering how suitable Avalon (and possibly Phoenix) might be for use
on embedded Java processors?
These environments typically have rather severe memory footprint and
processor speed contraints, and may be missing other key functionality (eg.
dynamic classloading can be problematic, without disk storage).
Would it be possible to pare down Avalon and/or Phoenix to run in such
environments? Is there any prior work in this area? Caveats? Effort?
Much appreciate any advice/insight the group can offer on the feasibility of
such a project...
Thanks!
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Suitability of Avalon for embedded environments?
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 27 Dec 2002 04:27, Andrzej Jan Taramina wrote:
> > However the other effort I know of ended up having to remove so much of
> > Phoenix (all threading, the requirement for an xml parser, the way
> > classloading worked etc). In this case it would have been better to just
> > write a custom container using the minimum Avalon/Framework interfaces.
>
> I'm investigating which way to go. It's really not clear yet, but I'm
> leaning towards a new container project, that would just "borrow" bits of
> Phoenix where it made sense to do so.
kool.
> That would be much appreciated.....we're more than happy to discuss our
> goals and details, since this will be an open source project.
great - got a website up ?
--
Cheers,
Peter Donald
--------------------------------
My opinions may have changed,
but not the fact that I am right
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Suitability of Avalon for embedded environments?
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
Peter suggests:
> It depends on how resource constrained the jvm is essentially. I know of
> at least two efforts that have attempted this. The first one managed to
> embedd phoenix with only minor modifications (mainly to remove all notion
> of threading and to hook into their startup process).
See my prior email responding to Berin....in some cases we will be extremely
constrained. That being said, I would prefer to re-purpose as much of the
existing work (eg. Phoenix) as we can. This will be an open source project
BTW.
> However the other effort I know of ended up having to remove so much of
> Phoenix (all threading, the requirement for an xml parser, the way
> classloading worked etc). In this case it would have been better to just
> write a custom container using the minimum Avalon/Framework interfaces.
I'm investigating which way to go. It's really not clear yet, but I'm leaning
towards a new container project, that would just "borrow" bits of Phoenix
where it made sense to do so.
> I don't actually know much about the area but I can ask some people about
> it who have already worked on that sort of thing. However I suspect you
> are going to need to provide more details if you want advice of real
> value.
That would be much appreciated.....we're more than happy to discuss our
goals and details, since this will be an open source project.
> ie What are the limitations of your particular device and how much
> overhead can your application(s) allow.
See my prior email responding to Berin. In some cases, we will be very
constrained (PIC chips), and so it behooves us to keep the container as
lightweight and as modular as possible. The embedded space typically
requires a lot of compromises, but we want to limit these as much as possible
(Moore's law still being in effect, and some of the new hardware like aJile chips
being very powerful JVMs).
Another consideration is that many of these applications (shop floor control,
etc.) may need real-time response....and any container should not
compromise our ability to provide such.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Suitability of Avalon for embedded environments?
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 23 Dec 2002 05:52, Andrzej Jan Taramina wrote:
> I was wondering how suitable Avalon (and possibly Phoenix) might be for use
> on embedded Java processors?
It depends on how resource constrained the jvm is essentially. I know of at
least two efforts that have attempted this. The first one managed to embedd
phoenix with only minor modifications (mainly to remove all notion of
threading and to hook into their startup process).
However the other effort I know of ended up having to remove so much of
Phoenix (all threading, the requirement for an xml parser, the way
classloading worked etc). In this case it would have been better to just
write a custom container using the minimum Avalon/Framework interfaces.
> Would it be possible to pare down Avalon and/or Phoenix to run in such
> environments? Is there any prior work in this area? Caveats? Effort?
>
> Much appreciate any advice/insight the group can offer on the feasibility
> of such a project...
I don't actually know much about the area but I can ask some people about it
who have already worked on that sort of thing. However I suspect you are
going to need to provide more details if you want advice of real value.
ie What are the limitations of your particular device and how much overhead
can your application(s) allow.
--
Cheers,
Peter Donald
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Suitability of Avalon for embedded environments?
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 27 Dec 2002 04:27, Andrzej Jan Taramina wrote:
> Anyway....I'm really keen to hear more details about Avalon 5, since this
> will let me make some decisions as to how to proceed with our embedded
> container project.
A5 is a pipe dream that may come about in a couple of years (or may not). As
none of the current committers have much of a clue about the embedded arena I
would suggest you just do your own thing and keeping us informed ;) We will
gladly set up links from our pages to your project as soon as you got it
started.
I still have to poke a few people who have used Avalon in this area and get
back to you.
--
Cheers,
Peter Donald
Sufficiently advanced science is
indistinguishable from magic"
-- Arthur C. Clarke
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Suitability of Avalon for embedded environments?
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 27 Dec 2002 04:51, Berin Loritsch wrote:
> That is an area that I am looking into. The Configuration
> objects have always meant to represent information that can
> be from a variety of locations. We just never got around to
> writing the LDAP backed configuration reader, or others.
There is an LDAP config builder in excalibur.
--
Cheers,
Peter Donald
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Suitability of Avalon for embedded environments?
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Andrzej Jan Taramina [mailto:andrzej@chaeron.com]
>
> Berin:
>
> > Avalon Framework is very low weight, and it can work in just
> > about any environment. However, most of our more functional
> > containers are not friendly to the Embedded environment.
>
> That's OK.....I have no problem building a new embedded
> container from the
> ground up using the Avalon Framework....
>
> > That said, we have an eye on the embedded arena for Avalon 5.
>
> Can't let a teaser like that go by!
>
> What's planned for A5?
We aren't done planning yet. We are looking at making the process
of developing Avalon components easier, as well as provide a unified
container that scales from very little to very large. It will be
a question of "what features do I need?".
> What features are you targeting towards the embedded arena?
We just want it to work in the embedded arena.
If you have a laundry list of features that you
want to see, please let us know.
> How far along is A5?
We are just starting to seriously talk about it. There
is definitely time for you to inject your comments and
ideas.
> What kind of timeline are you looking at for an A5 release?
Hard to say. Avalon 4.1 is here and will be maintained
in the interim. Having just started, I doubt you will see
anything concrete in the very near future.
> How backwards compatible will 5 be with 4.x?
An Avalon 5 container will provide the tools to work with
Avalon 4.x components. We will have test suites and everything
to help guarantee the fact.
> > As long as the JAR can remain in memory, we can access the classes
> > that way. I think we have a "virtual" file system API somewhere.
>
> Even that is unlikely. We'll be targeting devices based on
> the aJile Java
> chips....say the Systronix JStamp, which in it's base config
> has 512K Flash
> and 512K ram. There is a plus version with 2M Flash ROM. So
> space is at a
> premium of course! We're also looking at even smaller
> devices like PIC chips
> with the impending uVM Java implementation.....
I see. Any pointers you can provide will greatly help us.
> My gut feel is that classloading with be extremely limited
> (to only those classes
> known to be needed ahead of time) or will be done across a network
> connection, if at all.
Would it work if you had a _compiled_ assembly? An assembly in
Phoenix/Merlin speak is a group of components that work together
to provide an application. Currently it is an XML file that is
interpreted at runtime. An embedded device doesn't need the
luxury of dynamic assembly, so providing a way to hardwire it
with a class might help. That would take care of the bulk of
the classloader related issues.
> Some of these platforms (the aJile ones) do have thread
> support...others may
> not. So we'll have to make threading an "optional" part of
> the container
> implementation.
Sounds good.
> Also XML parsing can be problematic.....no way we can load
> something like
> Xerces on an embedded Java chip. There are some very lightweight XML
> parsing libraries out there (kXML, 15kb or so)....but for
> performance reasons,
> we would only use them for external integration communications (eg.
> XML/SOAP over HTTP), and not for internal configuration and
> the like, which
> is so popular server-side. We'll probably have XML-based
> config files, but
> might pre-parse them into condensed binary format or java
> classes (static
> finals work well for this since the java compilers can then
> prune your code of
> unused features automatically) for use on the embedded container.
That is an area that I am looking into. The Configuration
objects have always meant to represent information that can
be from a variety of locations. We just never got around to
writing the LDAP backed configuration reader, or others.
Again, hardwired classes that generate the configuration
would probably work wonders--like for the assembly.
> > We would probably have to start with Tweety (in Excalibur) and
> > add in what you need. In Avalon 5, we will be able to create
> > a container that works in the embedded arena. Most likely, all
> > logging would be turned off, since as you say disk access is an
> > issue and logging is of dubious benefit on a PDA. Using a
> > NullLogger will disable all logging.
>
> We're not talking PDA's...but true embedded controllers
> (think factory
> floor....plant controllers and such). As for logging, there
> is some utility in
> that...we may choose to stream terse logs for critical events
> across a
> network....or maybe out across a JTag connection (parallel
> port interface). But
> definitely logging would have to be optional in many cases in
> the embedded
> world.
Still doable.
> > It is feasible, but it depends on how much funcationality you
> > need.
>
> Probably more accurate to say "how much we can realistically
> do" on such
> small platforms.
Right.
> Anyway....I'm really keen to hear more details about Avalon
> 5, since this will let
> me make some decisions as to how to proceed with our embedded
> container
> project.
There is nothing concrete yet. We have some scribblings on
the Avalon Wiki about some ideas.
http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonProjectPages
The more you can give us about embedded Avalon requirements,
the better we can shape the future.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Suitability of Avalon for embedded environments?
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
Berin:
> Avalon Framework is very low weight, and it can work in just
> about any environment. However, most of our more functional
> containers are not friendly to the Embedded environment.
That's OK.....I have no problem building a new embedded container from the
ground up using the Avalon Framework....
> That said, we have an eye on the embedded arena for Avalon 5.
Can't let a teaser like that go by!
What's planned for A5?
What features are you targeting towards the embedded arena?
How far along is A5?
What kind of timeline are you looking at for an A5 release?
How backwards compatible will 5 be with 4.x?
> As long as the JAR can remain in memory, we can access the classes
> that way. I think we have a "virtual" file system API somewhere.
Even that is unlikely. We'll be targeting devices based on the aJile Java
chips....say the Systronix JStamp, which in it's base config has 512K Flash
and 512K ram. There is a plus version with 2M Flash ROM. So space is at a
premium of course! We're also looking at even smaller devices like PIC chips
with the impending uVM Java implementation.....
My gut feel is that classloading with be extremely limited (to only those classes
known to be needed ahead of time) or will be done across a network
connection, if at all.
Some of these platforms (the aJile ones) do have thread support...others may
not. So we'll have to make threading an "optional" part of the container
implementation.
Also XML parsing can be problematic.....no way we can load something like
Xerces on an embedded Java chip. There are some very lightweight XML
parsing libraries out there (kXML, 15kb or so)....but for performance reasons,
we would only use them for external integration communications (eg.
XML/SOAP over HTTP), and not for internal configuration and the like, which
is so popular server-side. We'll probably have XML-based config files, but
might pre-parse them into condensed binary format or java classes (static
finals work well for this since the java compilers can then prune your code of
unused features automatically) for use on the embedded container.
> We would probably have to start with Tweety (in Excalibur) and
> add in what you need. In Avalon 5, we will be able to create
> a container that works in the embedded arena. Most likely, all
> logging would be turned off, since as you say disk access is an
> issue and logging is of dubious benefit on a PDA. Using a
> NullLogger will disable all logging.
We're not talking PDA's...but true embedded controllers (think factory
floor....plant controllers and such). As for logging, there is some utility in
that...we may choose to stream terse logs for critical events across a
network....or maybe out across a JTag connection (parallel port interface). But
definitely logging would have to be optional in many cases in the embedded
world.
> It is feasible, but it depends on how much funcationality you
> need.
Probably more accurate to say "how much we can realistically do" on such
small platforms.
Anyway....I'm really keen to hear more details about Avalon 5, since this will let
me make some decisions as to how to proceed with our embedded container
project.
Thanks!
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: Suitability of Avalon for embedded environments?
Posted by "Daniel S. Haischt" <si...@gmx.net>.
just a few comments ...
> -----Ursprungliche Nachricht-----
> Von: Berin Loritsch [mailto:bloritsch@citi-us.com]
> Gesendet: Montag, 23. Dezember 2002 15:29
> An: 'Avalon Developers List'; andrzej@chaeron.com
> Betreff: RE: Suitability of Avalon for embedded environments?
>
>
> > From: Andrzej Jan Taramina [mailto:andrzej@chaeron.com]
> >
> > I was wondering how suitable Avalon (and possibly Phoenix)
> > might be for use
> > on embedded Java processors?
>
> Avalon Framework is very low weight, and it can work in just
> about any environment. However, most of our more functional
> containers are not friendly to the Embedded environment.
we should distinguish between ...
- Real embedded environments such as the Xpresso
Java processor (http://www.zucotto.com/home/index.html)
- Small sized PDAs such as the Palm Pilot which only
comes with a VM that implements the MIDP API.
- Cell Phone - same as with the Palm Pilot.
- PocketPCs such as the Compaq iPAQ, the Sharp Zaurus.
those are nearly desktop PCs expect the small display.
but they have enough memory (65 MByte) and you can
equipe them with a 1 GByte CF card or the IBM 1 GByte
microdrive. finally the ship with a jdk1.1.8 compliant
VM. to be picky - the VM implements the PersonalJava
API which includes the collection classes that are missing
in jdk1.1.8.
>
> That said, we have an eye on the embedded arena for Avalon 5.
>
>
>
> > These environments typically have rather severe memory footprint and
> > processor speed contraints, and may be missing other key
> > functionality (eg.
> > dynamic classloading can be problematic, without disk storage).
>
> As long as the JAR can remain in memory, we can access the classes
> that way. I think we have a "virtual" file system API somewhere.
applies to those embedded systems not having a file system (for example
a JavaCard).
>
>
>
> > Would it be possible to pare down Avalon and/or Phoenix to
> > run in such
> > environments? Is there any prior work in this area? Caveats? Effort?
>
> We would probably have to start with Tweety (in Excalibur) and
> add in what you need. In Avalon 5, we will be able to create
> a container that works in the embedded arena. Most likely, all
> logging would be turned off, since as you say disk access is an
> issue and logging is of dubious benefit on a PDA. Using a
> NullLogger will disable all logging.
turned of logging should be configurable, for example those
devices that do support TCP/IP networking, should support
the option to enable a socket logger.
With best regards / Mit freundlichen Gruessen
Daniel S. Haischt IT Consulting
______________________________
[revolutionary and alpha geek]
Daniel S. Haischt
Grabenstrasse 11
D-71083 Herrenberg
G E R M A N Y
FON: +49 -7032-992909
+49 -700-DHAISCHT
FAX: +49 -7032-992910
CELLULAR: +49 -172-7668936
email: daniel.haischt@daniel-s-haischt.biz
web: http://www.daniel-s-haischt.biz
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS dx s:- a- C++ UB++++ P+++ L++++ E W+++ N+++ o-- K- w---
O++ M++ V- PS+ PE++ Y+ PGP++ t+++ 5+ X+++ R+ tv++ b+++ DI+ D+++
G e++ h-- r+ y+++++
------END GEEK CODE BLOCK------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Suitability of Avalon for embedded environments?
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Andrzej Jan Taramina [mailto:andrzej@chaeron.com]
>
> I was wondering how suitable Avalon (and possibly Phoenix)
> might be for use
> on embedded Java processors?
Avalon Framework is very low weight, and it can work in just
about any environment. However, most of our more functional
containers are not friendly to the Embedded environment.
That said, we have an eye on the embedded arena for Avalon 5.
> These environments typically have rather severe memory footprint and
> processor speed contraints, and may be missing other key
> functionality (eg.
> dynamic classloading can be problematic, without disk storage).
As long as the JAR can remain in memory, we can access the classes
that way. I think we have a "virtual" file system API somewhere.
> Would it be possible to pare down Avalon and/or Phoenix to
> run in such
> environments? Is there any prior work in this area? Caveats? Effort?
We would probably have to start with Tweety (in Excalibur) and
add in what you need. In Avalon 5, we will be able to create
a container that works in the embedded arena. Most likely, all
logging would be turned off, since as you say disk access is an
issue and logging is of dubious benefit on a PDA. Using a
NullLogger will disable all logging.
> Much appreciate any advice/insight the group can offer on the
> feasibility of
> such a project...
It is feasible, but it depends on how much funcationality you
need.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>