You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/12/26 19:48:41 UTC
Name clash, again
http://www.chip.de/artikelbilder/bilder_galerie_8924309.html?show=62
It seems like the next version of the .NET implementation in Microsoft
Longhorn (the next version after XP) is codenamed "avalon"... the
codename is not a problem since they are not normally trademarked or
copyrighted... but will they change all the component names and package
names when they ship the final version?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem w MBean
Posted by Paul Hammant <Pa...@yahoo.com>.
Mateusz,
>I have a one question. Lets imagine we have an WebServer which is a Avalon
>Service managed by Phoenix.
>
>We export
>
>public interface WebMBean{
> void setPort(int port);
> int getPort();
>}
>
>Of course our compoenent implements this bean
>
>Of the other hand we have configuration in which we store the port of the
>server.
>
>Now Server starts. Default port is read from config. We manager server and
>invoke it's setPort().
>
>The port changes. But after we shutdown phoenix. We cannot make this change
>persistent because
>
>Configuration object is not writeable.
>
>How could I workaround this.
>
You'll have to serialize some object that is loaded (if present) after
configure() is processed.
We hae been asked to look at a changable configuration design a few
times before. We might come up with a secure design on year soon.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Problem w MBean
Posted by Mateusz Szczap <ma...@ncdc.pl>.
I have a one question. Lets imagine we have an WebServer which is a Avalon
Service managed by Phoenix.
We export
public interface WebMBean{
void setPort(int port);
int getPort();
}
Of course our compoenent implements this bean
Of the other hand we have configuration in which we store the port of the
server.
Now Server starts. Default port is read from config. We manager server and
invoke it's setPort().
The port changes. But after we shutdown phoenix. We cannot make this change
persistent because
Configuration object is not writeable.
How could I workaround this.
Mateusz Szczap
mati@ncdc.pl
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Name clash, again
Posted by Ulrich Mayring <ul...@denic.de>.
ymikulski@softhome.net wrote:
>
> Avalon is much better than they did.
Which, in my mind, means that Microsoft has *not* heard of Avalon.
Ulrich
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Name clash, again
Posted by ym...@softhome.net.
Berin Loritsch writes:
>
> It's a tough call. We need to make sure our C# version of Avalon is
> not using the [Avalon] module name.... ApacheAvalon or Apache::Avalon
> would work.
>
You can take a look at Microsoft Namespace Naming Guidelines
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/ht
ml/cpconnamespacenamingguidelines.asp
Following their guide our codename is Apache.Avalon
I don't think there will be any problems.
Everything is correct, isn't it?
>
> Oh, the cynical side of me thinks so too. On the other hand,
> are you sure they have even heard of us?
>
I'm sure they know what Avalon is perfectly well.
While .NET was being designed they made analysis of C++, Delphi, Java and
all existing solutions.
Open Source is an inseparable part of Java and so no doubt they analyzed it
too.
I think they would have never created ASP.NET if they hadn't even taken a
look at jakarta-structs for example and so on ...
I don't consider it is a coincidence, just analyzing.
They even tried to create their own Component Model, but I think it is ugly
(just my opinion), Avalon is much better than they did.
Best Regards,
Yauheny Mikulski (Jeff)
"Religion is what the common people see as true,
the wise people see as false, and
the rulers see as useful" - Seneca
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Name clash, again
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Oh, the cynical side of me thinks so too. On the other hand,
> are you sure they have even heard of us?
(a) they probably have if they do any due diligance looking at component
frameworks, (b) they wouldn't consider this project (or most outside of
Microsoft/IBM/other giant) anything more than small potatoes.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Name clash, again
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> > It's a pity precedence doesn't matter to large companies.
>
> What makes you think that they wouldn't pick the name in part
> because it
> does conflict? Color me cynical.
Oh, the cynical side of me thinks so too. On the other hand,
are you sure they have even heard of us?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Name clash, again
Posted by "Noel J. Bergman" <no...@devtech.com>.
> It's a pity precedence doesn't matter to large companies.
What makes you think that they wouldn't pick the name in part because it
does conflict? Color me cynical.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Name clash, again
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> http://www.chip.de/artikelbilder/bilder_galerie_8924309.html?show=62
>
> It seems like the next version of the .NET implementation in
> Microsoft
> Longhorn (the next version after XP) is codenamed "avalon"... the
> codename is not a problem since they are not normally trademarked or
> copyrighted... but will they change all the component names
> and package
> names when they ship the final version?
It's a tough call. We need to make sure our C# version of Avalon is
not using the [Avalon] module name.... ApacheAvalon or Apache::Avalon
would work.
It's a pity precedence doesn't matter to large companies.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>