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 2001/11/07 21:27:32 UTC
Is everyone happy with Namespace?
I want to clarify if everyone is happy with the Namespace
class. We need to take care of it NOW before it is too
late!
That goes for the new Logging classes as well.
Once we make the release, those APIs are set in stone!
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Peter Donald <do...@apache.org>.
On Sat, 10 Nov 2001 09:48, Berin Loritsch wrote:
> According to the XML Namespace spec, officially the namespace is different
> if the prefix is different.
oops - I thought it was the other way round ;)
> > > The Factory methods (.getNamespace(String)) can be extended to
> > > simply have a boolean to set the policy for the object.
> > >
> > > However you must keep in mind that multiple policies for comparing
> > > Namespace objects has unpredictable results. (actually it will
> > > use the policy of the Namespace object on the left side of the
> > > argument).
> >
> > you probably shouldn't be comparing namespace objects across domains
> > anyway - I would consider that an error in the code.
>
> So does the change to the factory method sound like the way to go?
works for me.
--
Cheers,
Pete
---------------------------------------------------
"If you don't know where you want to go, we'll make
sure you get taken."
Microsoft ad slogan, translated into Japanese.
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Berin Loritsch <bl...@apache.org>.
Jeremias Maerki wrote:
> Hi Vincent
>
> Today, I've taken your collected thoughts and put them to use. They were
> very clear and helpful and I'm quite pleased with the results. Well, I
> haven't done any direct EJB testing, yet. I've expected pitfalls but
> there weren't any until now. I think it would be very helpful if these
> ideas could be integrated into Berin's "Developing with Avalon" at some
> time. I'd gladly help doing it as soon as I've finished those two
> projects I'm currently working on (that will be the beginning of March,
> I think).
We would welcome the donation!
>
> On Sat, 10 Nov 2001 18:04:51 -0000 Vincent Massol wrote:
>
>>Hi,
>>
>>I have just finished reading the excellent "Developing with Avalon" PDF
>>(thanks Berin !) and am very eager to introduce Avalon in my current project
>>: e-business project using J2EE 1.3.
>>
>>Here is how I view the integration. I'd like to have feedback in order to
>>confirm this is the best way to use Avalon in J2EE :
>>
>
> <snip/>
>
>>What do you think ? Am I missing something ? As someone already done this ?
>>
>
> Cheers,
> Jeremias Märki
>
> mailto:jeremias.maerki@outline.ch
>
> OUTLINE AG
> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
> Internet http://www.outline.ch
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> .
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon and J2EE : Best practices
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@zenplex.com]
> Sent: 20 December 2001 21:17
> To: Avalon Developers List
> Subject: Re: Avalon and J2EE : Best practices
>
> On 12/20/01 1:04 PM, "Vincent Massol" <vm...@octo.com> wrote:
>
> > - In order to consistently do logging (with Log4J) and configuration
> > (single system configuration file) in both J2EE component and Avalon
> > components, we have done the following :
> >
> > * Created a Logger component,
> > * Created a Configuration component (that uses properties file - I
will
> > submit it for Excalibur in beginning of January),
> > * Defined an AbstractComponent class that is Composable, retrieve
the
> > Logger and Configuration components from the CM and offers 2 getters
:
>
> Simply as a point of interest, in the course of looking at using
Avalon
> with
> Turbine I did much the same in stratum (which is the refactoring of
all
> the
> tools that have grown in turbine, a turbine commons of sorts) in order
to
> do
> what need to do vis-à-vis logging and configuration.
>
I guess there must have been a hard discussion at the beginning of
Avalon to decide whether to promote logging and configuration as
lifecycle interface rather than components ... ;-)
In the service framework I had written (babel on sourceforge), I had
decided to implement them as component but I had a BaseLog and
BaseConfig classes which was used for all logging and configuration
related to the Component Manager itself (because it is possible it fails
before the logging service is initialized or if there is no logging
service registered - same for the configuration). However, in the
implementation, the logging and configuration components were actually
using the BaseXXX classes.
[snip]
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/20/01 1:04 PM, "Vincent Massol" <vm...@octo.com> wrote:
> - In order to consistently do logging (with Log4J) and configuration
> (single system configuration file) in both J2EE component and Avalon
> components, we have done the following :
>
> * Created a Logger component,
> * Created a Configuration component (that uses properties file - I will
> submit it for Excalibur in beginning of January),
> * Defined an AbstractComponent class that is Composable, retrieve the
> Logger and Configuration components from the CM and offers 2 getters :
Simply as a point of interest, in the course of looking at using Avalon with
Turbine I did much the same in stratum (which is the refactoring of all the
tools that have grown in turbine, a turbine commons of sorts) in order to do
what need to do vis-à-vis logging and configuration.
> getLogger() and getConfiguration()
> * Our Avalon components extends AbstractComponent
> * We have a ComponentUtilities static class for other non EJB and non
> Avalon classes (during the migration phase and before all non EJB
> classes are components or attached to components) :
>
> public final static ComponentManager getComponentManager()
> {
> // Get CM from static variable
> return InitialisationEJB.manager;
> }
>
> public final static Component getComponent(String role)
> {
> final ComponentManager manager = getComponentManager();
> Component component;
> try
> {
> component = manager.lookup(role);
> }
> catch (ComponentException e)
> {
> throw new CriticalException("cannot get component for role [" +
> role + "]", e);
> }
>
> return component;
> }
>
> * We have defined a AbstractEnterpriseBean class that extends
> AbstractComponent. It contains empty EJB lifecycle methods that are
> common to session beans and entity beans. In the default constructor, we
> call :
>
> compose(ComponentUtilities.getComponentManager());
>
> * We also have a AbstractSessionBean and AbstractEntityBean classes that
> extend AbstractEnterpriseBean and simply add the empty EJB lifecycle
> methods related to Session beans and entity beans respectively.
> * We have a EJBUtilities class with static methods to get EJB home and
> bean reference (saved as static variables). We will probably move this
> class to be a single threaded Avalon component in the future.
>
> Thus we are able :
> - to use Avalon Components
> - to use standard java classes (to be migrated to components in the
> future or will act as helper classes of components)
> - to use EJBs
> - All 3 kinds can call each other with no problem
> - All 3 kind use a unified system configuration file
> - All 3 kind use a unified logging service (based on Log4j)
>
>> I think it would be very helpful if these
>> ideas could be integrated into Berin's "Developing with Avalon" at
> some
>> time. I'd gladly help doing it as soon as I've finished those two
>> projects I'm currently working on (that will be the beginning of
> March,
>> I think).
>>
>
> definitely. + a sample j2ee application that shows it all.
>
> -Vincent
>
>> On Sat, 10 Nov 2001 18:04:51 -0000 Vincent Massol wrote:
>>> Hi,
>>>
>>> I have just finished reading the excellent "Developing with Avalon"
> PDF
>>> (thanks Berin !) and am very eager to introduce Avalon in my current
>> project
>>> : e-business project using J2EE 1.3.
>>>
>>> Here is how I view the integration. I'd like to have feedback in
> order
>> to
>>> confirm this is the best way to use Avalon in J2EE :
>>
>> <snip/>
>>
>>> What do you think ? Am I missing something ? As someone already done
>> this ?
>>
>> Cheers,
>> Jeremias Märki
>>
>> mailto:jeremias.maerki@outline.ch
>>
>> OUTLINE AG
>> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
>> Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
>> Internet http://www.outline.ch
>>
>>
>> --
>> To unsubscribe, e-mail: <mailto:avalon-dev-
>> unsubscribe@jakarta.apache.org>
>> For additional commands, e-mail: <mailto:avalon-dev-
>> help@jakarta.apache.org>
>>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon and J2EE : Best practices
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Jeremias Maerki [mailto:jeremias.maerki@outline.ch]
> Sent: 20 December 2001 15:32
> To: Avalon Developers List
> Subject: Re: Avalon and J2EE : Best practices
>
> Hi Vincent
>
> Today, I've taken your collected thoughts and put them to use. They
were
> very clear and helpful and I'm quite pleased with the results. Well, I
> haven't done any direct EJB testing, yet. I've expected pitfalls but
> there weren't any until now.
Thanks Jeremias. We have made progress with our application and have now
completely integrated Avalon and J2EE and it works fine.
Here are some ideas (I will try to find some time later in January to
participate in a chapter on J2EE integration in "Developing With Avalon"
and to package a sample application showing it in real) :
- With WL 6.1, it is not possible to specify that a war should be
deployed before an EJB jar. Thus we had to move the initialization of
Excalibur CM to an EJB that we package in a separate EJB jar. Then, it
is possible with WL 6.1 to explicitely define the deployment order of
EJB jar. We save the CM as a static variable or this initialization EJB.
- In order to consistently do logging (with Log4J) and configuration
(single system configuration file) in both J2EE component and Avalon
components, we have done the following :
* Created a Logger component,
* Created a Configuration component (that uses properties file - I will
submit it for Excalibur in beginning of January),
* Defined an AbstractComponent class that is Composable, retrieve the
Logger and Configuration components from the CM and offers 2 getters :
getLogger() and getConfiguration()
* Our Avalon components extends AbstractComponent
* We have a ComponentUtilities static class for other non EJB and non
Avalon classes (during the migration phase and before all non EJB
classes are components or attached to components) :
public final static ComponentManager getComponentManager()
{
// Get CM from static variable
return InitialisationEJB.manager;
}
public final static Component getComponent(String role)
{
final ComponentManager manager = getComponentManager();
Component component;
try
{
component = manager.lookup(role);
}
catch (ComponentException e)
{
throw new CriticalException("cannot get component for role [" +
role + "]", e);
}
return component;
}
* We have defined a AbstractEnterpriseBean class that extends
AbstractComponent. It contains empty EJB lifecycle methods that are
common to session beans and entity beans. In the default constructor, we
call :
compose(ComponentUtilities.getComponentManager());
* We also have a AbstractSessionBean and AbstractEntityBean classes that
extend AbstractEnterpriseBean and simply add the empty EJB lifecycle
methods related to Session beans and entity beans respectively.
* We have a EJBUtilities class with static methods to get EJB home and
bean reference (saved as static variables). We will probably move this
class to be a single threaded Avalon component in the future.
Thus we are able :
- to use Avalon Components
- to use standard java classes (to be migrated to components in the
future or will act as helper classes of components)
- to use EJBs
- All 3 kinds can call each other with no problem
- All 3 kind use a unified system configuration file
- All 3 kind use a unified logging service (based on Log4j)
> I think it would be very helpful if these
> ideas could be integrated into Berin's "Developing with Avalon" at
some
> time. I'd gladly help doing it as soon as I've finished those two
> projects I'm currently working on (that will be the beginning of
March,
> I think).
>
definitely. + a sample j2ee application that shows it all.
-Vincent
> On Sat, 10 Nov 2001 18:04:51 -0000 Vincent Massol wrote:
> > Hi,
> >
> > I have just finished reading the excellent "Developing with Avalon"
PDF
> > (thanks Berin !) and am very eager to introduce Avalon in my current
> project
> > : e-business project using J2EE 1.3.
> >
> > Here is how I view the integration. I'd like to have feedback in
order
> to
> > confirm this is the best way to use Avalon in J2EE :
>
> <snip/>
>
> > What do you think ? Am I missing something ? As someone already done
> this ?
>
> Cheers,
> Jeremias Märki
>
> mailto:jeremias.maerki@outline.ch
>
> OUTLINE AG
> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
> Internet http://www.outline.ch
>
>
> --
> To unsubscribe, e-mail: <mailto:avalon-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-
> help@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Jeremias Maerki <je...@outline.ch>.
Hi Vincent
Today, I've taken your collected thoughts and put them to use. They were
very clear and helpful and I'm quite pleased with the results. Well, I
haven't done any direct EJB testing, yet. I've expected pitfalls but
there weren't any until now. I think it would be very helpful if these
ideas could be integrated into Berin's "Developing with Avalon" at some
time. I'd gladly help doing it as soon as I've finished those two
projects I'm currently working on (that will be the beginning of March,
I think).
On Sat, 10 Nov 2001 18:04:51 -0000 Vincent Massol wrote:
> Hi,
>
> I have just finished reading the excellent "Developing with Avalon" PDF
> (thanks Berin !) and am very eager to introduce Avalon in my current project
> : e-business project using J2EE 1.3.
>
> Here is how I view the integration. I'd like to have feedback in order to
> confirm this is the best way to use Avalon in J2EE :
<snip/>
> What do you think ? Am I missing something ? As someone already done this ?
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Peter Donald <do...@apache.org>.
On Sun, 11 Nov 2001 21:05, Vincent Massol wrote:
> The most interesting part of Avalon for me is not the services but rather
> the fact that it uses best practice patterns and especially IOC. This is
> sooo important. Because on almost all my projects I have to mentor teams of
> developers who are very juniors and who 1/ have never programmed in java
> and 2/ have no experience with OOP/COP. Using Avalon gives them a
> documented framework that will force them to program properly.
>
> One of the big driver in favor of IOC for me is that it will lead to code
> that can easily be unit tested using Mock Objects (www.mockobjects.com)
> [and of course flexible and without to many dependencies - but that's why I
> can unit test it easily with mocks, i.e. isolate a portion of code from its
> domain (i.e. calling and caller classes)].
Hadn't thought of it in that way. You just convinced me that maybe I should
push to to have avalon/Framework adopted for our EJB stuff ;)
--
Cheers,
Pete
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Vincent Massol <vm...@octo.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Sunday, November 11, 2001 1:40 AM
Subject: Re: Avalon and J2EE : Best practices
> On Sun, 11 Nov 2001 12:15, Vincent Massol wrote:
> > > Anyways I am only just getting into serious EJB work so ... ;)
> >
> > good ... do you plan to use avalon with j2ee ?
>
> With j2ee - yes. A lot of the stuff is already integrated with J2EE APIs.
In
> particular the Framework and Excalibur parts of Avalon is easily used in
> servlets and RMI/CLI/GUI/Other clients. It also works great as an endpoint
of
> JMS messages.
>
> However with EJBs I am not sure. Most of the EJB stuff I have being
playing
> with is relatively standard buisness orientated stuff. Essentially
> manipulation of databases and as such there has never been any demand for
any
> of the Avalon components (excepting Logging).
>
Well, I have been designing and implementing e-business solutions with
J2EE/EJB for the past 3 years and I can tell you that for each project I had
to rewrite the equivalent of Avalon/Excalibur. Probably the main reason was
that my favourite architecture (on the business tier) has been facade
stateless session beans around standard java data access classes (manager
class to manage life cycle of data objects and JDBC service for the
persistence). You also need a consistent way of configuring your application
(you must not use the ejb deployment descriptor as they only convey config
parameter for the ejbs and your application also has standard classes,
servlets, ....). In total here are the services I have used on all projects
:
- jdbc wrapper
- jndi wrapper
- configuration
- logging
- java-xml mapping
- jms wrapper (not on all projects)
I had to use them so frequently, I decided to create an open source project
so that we could have everyone in the company improve it and benefit from it
on all our projects. We also expected to have outside review and help. We
put that framework on sourceforge and called it Babel. It looks very similar
with Avalon/Excalibur (although not as complete). We have now decided to
stop it and use Avalon instead.
> However I suspect in the future where we are going to need some XML
> manipulation utilities that I will be using Avalon components from EJBs.
How
> it gets done I am not sure at this stage.
>
> --
> Cheers,
>
> Pete
>
> -------------------------------------------------
> We should take care not to make the intellect our
> god; it has, of course, powerful muscles, but no
> personality.
> -------------------------------------------------
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Vincent Massol <vm...@octo.com>.
The most interesting part of Avalon for me is not the services but rather
the fact that it uses best practice patterns and especially IOC. This is
sooo important. Because on almost all my projects I have to mentor teams of
developers who are very juniors and who 1/ have never programmed in java and
2/ have no experience with OOP/COP. Using Avalon gives them a documented
framework that will force them to program properly.
One of the big driver in favor of IOC for me is that it will lead to code
that can easily be unit tested using Mock Objects (www.mockobjects.com) [and
of course flexible and without to many dependencies - but that's why I can
unit test it easily with mocks, i.e. isolate a portion of code from its
domain (i.e. calling and caller classes)].
-Vincent
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Sunday, November 11, 2001 1:40 AM
Subject: Re: Avalon and J2EE : Best practices
> On Sun, 11 Nov 2001 12:15, Vincent Massol wrote:
> > > Anyways I am only just getting into serious EJB work so ... ;)
> >
> > good ... do you plan to use avalon with j2ee ?
>
> With j2ee - yes. A lot of the stuff is already integrated with J2EE APIs.
In
> particular the Framework and Excalibur parts of Avalon is easily used in
> servlets and RMI/CLI/GUI/Other clients. It also works great as an endpoint
of
> JMS messages.
>
> However with EJBs I am not sure. Most of the EJB stuff I have being
playing
> with is relatively standard buisness orientated stuff. Essentially
> manipulation of databases and as such there has never been any demand for
any
> of the Avalon components (excepting Logging).
>
> However I suspect in the future where we are going to need some XML
> manipulation utilities that I will be using Avalon components from EJBs.
How
> it gets done I am not sure at this stage.
>
> --
> Cheers,
>
> Pete
>
> -------------------------------------------------
> We should take care not to make the intellect our
> god; it has, of course, powerful muscles, but no
> personality.
> -------------------------------------------------
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Peter Donald <do...@apache.org>.
On Sun, 11 Nov 2001 12:15, Vincent Massol wrote:
> > Anyways I am only just getting into serious EJB work so ... ;)
>
> good ... do you plan to use avalon with j2ee ?
With j2ee - yes. A lot of the stuff is already integrated with J2EE APIs. In
particular the Framework and Excalibur parts of Avalon is easily used in
servlets and RMI/CLI/GUI/Other clients. It also works great as an endpoint of
JMS messages.
However with EJBs I am not sure. Most of the EJB stuff I have being playing
with is relatively standard buisness orientated stuff. Essentially
manipulation of databases and as such there has never been any demand for any
of the Avalon components (excepting Logging).
However I suspect in the future where we are going to need some XML
manipulation utilities that I will be using Avalon components from EJBs. How
it gets done I am not sure at this stage.
--
Cheers,
Pete
-------------------------------------------------
We should take care not to make the intellect our
god; it has, of course, powerful muscles, but no
personality.
-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Vincent Massol <vm...@octo.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Sunday, November 11, 2001 1:07 AM
Subject: Re: Avalon and J2EE : Best practices
> Hi,
>
> Sounds good but I have a few questions.
>
> On Sun, 11 Nov 2001 05:04, Vincent Massol wrote:
> > * In the setEntityContext(), setSessionContext() and
> > setMessageDrivenContext() of the EJBs, we will retrieve the
> > ComponentManager from the JNDI tree and save it as a class variable of
the
> > EJB. Similarly, it will be removed in the unsetXXXContext() (or
ejbRemove()
> > for Session Beans and MessageDriven Beans)
>
> Why use static/class members and not use instance variables. Instance
> variables should work I think and IIRC using static variables will make
your
> EJBs non-compliant and can be non-portable if you want to start doing some
of
> the more fancy clustering stuff.
I probably used the wrong word as I meant instance variable (I used class
variable to mean the same but I did not imagine them static). We agree here.
>
> > * EJBs that need configuration parameters will implement Configurable.
Same
> > as for logging, the initialize() method will need to call a Config
> > component that returns a Configuration object.
>
> Im not sure this is ideal unless the EJB has large number of configurable
> options. I would hope/think that most containers have a simple graphical
> client where you can put config parameters into JNDI space. Would it be
> better to use that ? If there was large numbers of parameters then
probably
> not but if there is only a small number of parameters ?
>
2 things here :
- it depends on the application server and I can tell you it is very far
from being true. Most application server have a very basic read-only JNDI
tree (not persistent), so I you wish to save parameters in JNDI you have to
install a separate LDAP server.
- I would like to have the same configuration mechanism for all my classes
whether they are avalon components or EJB. It doesn't mean that the
configuration component will not retrieve its configuration parameters from
JNDI
> Anyways I am only just getting into serious EJB work so ... ;)
good ... do you plan to use avalon with j2ee ?
cheers,
-Vincent
>
> --
> Cheers,
>
> Pete
>
> -----------------------------------------------
> "You can't depend on your eyes when your
> imagination is out of focus." -Mark Twain
> -----------------------------------------------
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Peter Donald <do...@apache.org>.
Hi,
Sounds good but I have a few questions.
On Sun, 11 Nov 2001 05:04, Vincent Massol wrote:
> * In the setEntityContext(), setSessionContext() and
> setMessageDrivenContext() of the EJBs, we will retrieve the
> ComponentManager from the JNDI tree and save it as a class variable of the
> EJB. Similarly, it will be removed in the unsetXXXContext() (or ejbRemove()
> for Session Beans and MessageDriven Beans)
Why use static/class members and not use instance variables. Instance
variables should work I think and IIRC using static variables will make your
EJBs non-compliant and can be non-portable if you want to start doing some of
the more fancy clustering stuff.
> * EJBs that need configuration parameters will implement Configurable. Same
> as for logging, the initialize() method will need to call a Config
> component that returns a Configuration object.
Im not sure this is ideal unless the EJB has large number of configurable
options. I would hope/think that most containers have a simple graphical
client where you can put config parameters into JNDI space. Would it be
better to use that ? If there was large numbers of parameters then probably
not but if there is only a small number of parameters ?
Anyways I am only just getting into serious EJB work so ... ;)
--
Cheers,
Pete
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Avalon and J2EE : Best practices
Posted by Vincent Massol <vm...@octo.com>.
Hi,
I have just finished reading the excellent "Developing with Avalon" PDF
(thanks Berin !) and am very eager to introduce Avalon in my current project
: e-business project using J2EE 1.3.
Here is how I view the integration. I'd like to have feedback in order to
confirm this is the best way to use Avalon in J2EE :
* I plan to only use Avalon Framework, Avalon Excalibur (and possibly Avalon
Cornerstone - but I have not looked at it yet). I don't see the need for
Phoenix at this point.
* There are 2 kinds of components in the application :
- the J2EE components : MDB, Session Beans and Entity Beans
- Avalon-style components : Logging, Configuration, DataAccess, some
business components that have been implemented as standard java classes
because Entity Beans are not performant enough, ...
* There will be 2 containers in my application :
- the J2EE container from the application server which manages the life
cycle of its components using the J2EE spec
- a ContainerComponent class that manages the life cycle of the Avalon
Components (see page 38 of "Developing with Avalon" for the
ContainerComponent)
* The ContainerComponent will be instanciated and initialized in the init()
method of an InitializationServlet Servlet (which has the load-on-startup
attribute set in web.xml so that the initialisation will be performed on
startup). During this initialization, the ExcaliburComponentManager will be
bound to the application server JNDI tree under a given name.
* In the setEntityContext(), setSessionContext() and
setMessageDrivenContext() of the EJBs, we will retrieve the ComponentManager
from the JNDI tree and save it as a class variable of the EJB. Similarly, it
will be removed in the unsetXXXContext() (or ejbRemove() for Session Beans
and MessageDriven Beans)
* All EJBs will use the ComponentManager to use Avalon Component
* All EJBs that need to use an Avalon component (that will be all of them as
logging will be an avalon component - see below) will have to implement the
Initializable interface.
* All components (EJBs and Avalon Components) will extend AbstractLoggable.
However, for EJBs, as the EJB container will not call setLogger() by
default, we'll have to do it ourselves, in setXXXContext(). We'll retrieve
the Logger to use by looking up an Avalon Logging Component, which will have
a getLogger(String category) method which will return a Logger object. Then,
we'll call setLogger(logger) on the EJB. Example:
public void initialize()
{
[...]
// get the ComponentManager from JNDI (default InitialContext())
// Initialise logging
Logging logging = manager.lookup(Logging.ROLE);
setLogger(logging.getLogger(this.getClass().getName()));
[...]
}
public void setSessionContext(SessionContext context)
{
this.context = context;
initialize();
}
Note: As this will be a typical construct for all EJBs (getting the
component manager from JNDI + initializaing logging), we will create a
static helper class for that.
* EJBs that need configuration parameters will implement Configurable. Same
as for logging, the initialize() method will need to call a Config component
that returns a Configuration object.
* Testing: Avalon components will be very easy to unit tests (using JUnit +
Mock Objects strategy) as they implement the IOC pattern.
* EJB Testing: If the EJB makes use of its EJBContext, we'll have to
subclass the EJB, add a compose(ComponentManager) method and override the
initialize() method so that it does nothing. If the EJB does not make use of
its EJBContext, then we will simply not call setXXXContext() as part of the
test initilisation.
What do you think ? Am I missing something ? As someone already done this ?
Thanks
-Vincent
--
Vincent Massol, vmassol@octo.com
OCTO Technology, www.octo.com
Information System Architecture Consulting
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sat, Nov 10, 2001 at 10:27:23PM +1100, Jeff Turner wrote:
>
> Btw, I think DefaultConfiguration is missing two methods:
>
> public void setNamespace(Namespace ns);
> public void setAttribute(Namespace ns, String name, String value);
>
> Without these, one cannot add namespace-prefixed attributes.
More in the "namespace support isn't integrated" theme,
DefaultConfigurationSerializer doesn't create namespace declarations. So
if I build a Configuration with:
<my-system version="1.3" xmlns:doc="http://myco.com/documentation">
<doc:desc>This is a highly fictitious config file</doc:desc>
<widget name="fooWidget" initOrder="1" threadsafe="true"/>
</my-system>
and then serialize it, I get out:
<my-system version="1.3">
<doc:desc>This is a highly fictitious config file</doc:desc>
<widget name="fooWidget" threadsafe="true" initOrder="1"/>
</my-system>
And yes, I'll stop whinging and start fixing as soon as I figure out how it
works ;)
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Peter Donald <do...@apache.org>.
On Tue, 13 Nov 2001 10:08, Jeff Turner wrote:
> On Mon, Nov 12, 2001 at 08:52:47AM -0500, Berin Loritsch wrote:
> > Jeff Turner wrote:
> > > On Fri, Nov 09, 2001 at 05:56:08PM -0600, Michael McKibben wrote:
> > > > I was under the impression after reading the w3 namespace spec that
> > > > the prefix is only used for selecting the namespace URI. The URI +
> > > > localpart is what determines equality, correct?
> > >
> > > I think so. In that case, m_validatePrefix ought to default to false,
> > > not true.
> > >
> > > Btw, I think DefaultConfiguration is missing two methods:
> > >
> > > public void setNamespace(Namespace ns);
> > > public void setAttribute(Namespace ns, String name, String value);
> > >
> > > Without these, one cannot add namespace-prefixed attributes.
> >
> > We decided that namespace prefixed attributes are not a good pattern for
> > configuration files. The reason is that the namespaced attribute does
> > not belong to the configuration tree in question.
>
> Righto. Though I gather Peter wants to use Configurations to represent Ant2
> build trees, and might need nsprefixed attributes for "aspects":
Pete wants to use nsprefixed attributes in a lot of places ;) However I have
ended up rewriting SAXHandler to provide this functionality.
It is really nice to split information between container and component. ie In
quite a few of my apps there is information that is directly relevent to
components and some that are directives to container to treat component in
specific ways.
Whether this is a desirable feature or not is yet to be seen. EJB descriptors
separate out this information into multiple files or multiple sections in
Config data. Other cases like Ant will integrate it into representation.
If anything I think that namespaces on attributes is probably not a
configuration concern but I haven't made up my mind fully yet ;)
>
> <target name="namespace-test">
>
> <!-- ant and doc are built in namespaces -->
> <echo ant:fail-on-error="true" message="Some random message">
> <doc:description>
> Test case for aspects
> </doc:description>
> <ant:some-element some-attribute="blah"/>
> </echo>
>
> <!-- load facility for blee: namespace -->
> <facility namespace="blee">
> <noop/>
> </facility>
>
> <echo blee:some-param="blah" message="Blee namespace test
> successful!"/>
>
> </target>
>
> (Taken from jakarta-ant/proposal/myrmidon/src/make/sample.ant)
>
> But I don't follow ant-dev closely, and I've likely misunderstood
> something.
Naah that sounds right ;)
--
Cheers,
Pete
---------------------------------------------------
"If you don't know where you want to go, we'll make
sure you get taken."
Microsoft ad slogan, translated into Japanese.
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Jeff Turner <je...@socialchange.net.au>.
On Mon, Nov 12, 2001 at 08:52:47AM -0500, Berin Loritsch wrote:
> Jeff Turner wrote:
> >
> > On Fri, Nov 09, 2001 at 05:56:08PM -0600, Michael McKibben wrote:
> > >
> > > I was under the impression after reading the w3 namespace spec that the
> > > prefix is only used for selecting the namespace URI. The URI + localpart
> > > is what determines equality, correct?
> >
> > I think so. In that case, m_validatePrefix ought to default to false,
> > not true.
> >
> > Btw, I think DefaultConfiguration is missing two methods:
> >
> > public void setNamespace(Namespace ns);
> > public void setAttribute(Namespace ns, String name, String value);
> >
> > Without these, one cannot add namespace-prefixed attributes.
>
> We decided that namespace prefixed attributes are not a good pattern for
> configuration files. The reason is that the namespaced attribute does not
> belong to the configuration tree in question.
Righto. Though I gather Peter wants to use Configurations to represent Ant2
build trees, and might need nsprefixed attributes for "aspects":
<target name="namespace-test">
<!-- ant and doc are built in namespaces -->
<echo ant:fail-on-error="true" message="Some random message">
<doc:description>
Test case for aspects
</doc:description>
<ant:some-element some-attribute="blah"/>
</echo>
<!-- load facility for blee: namespace -->
<facility namespace="blee">
<noop/>
</facility>
<echo blee:some-param="blah" message="Blee namespace test successful!"/>
</target>
(Taken from jakarta-ant/proposal/myrmidon/src/make/sample.ant)
But I don't follow ant-dev closely, and I've likely misunderstood something.
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Berin Loritsch <bl...@apache.org>.
Jeff Turner wrote:
>
> On Fri, Nov 09, 2001 at 05:56:08PM -0600, Michael McKibben wrote:
> >
> > I was under the impression after reading the w3 namespace spec that the
> > prefix is only used for selecting the namespace URI. The URI + localpart
> > is what determines equality, correct?
>
> I think so. In that case, m_validatePrefix ought to default to false,
> not true.
>
> Btw, I think DefaultConfiguration is missing two methods:
>
> public void setNamespace(Namespace ns);
> public void setAttribute(Namespace ns, String name, String value);
>
> Without these, one cannot add namespace-prefixed attributes.
We decided that namespace prefixed attributes are not a good pattern for
configuration files. The reason is that the namespaced attribute does not
belong to the configuration tree in question. That is not clean.
We also don't support semi-structured markup:
ILLEGAL CONFIGURATION:
----------------------
<element>
this is some <em>text</em>.
</element>
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Jeff Turner <je...@socialchange.net.au>.
On Fri, Nov 09, 2001 at 05:56:08PM -0600, Michael McKibben wrote:
>
> I was under the impression after reading the w3 namespace spec that the
> prefix is only used for selecting the namespace URI. The URI + localpart
> is what determines equality, correct?
I think so. In that case, m_validatePrefix ought to default to false,
not true.
Btw, I think DefaultConfiguration is missing two methods:
public void setNamespace(Namespace ns);
public void setAttribute(Namespace ns, String name, String value);
Without these, one cannot add namespace-prefixed attributes.
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Michael McKibben <mi...@hihat.net>.
I was under the impression after reading the w3 namespace spec that the
prefix is only used for selecting the namespace URI. The URI + localpart
is what determines equality, correct? It is legal XML to have two
different element prefixes bound to the same URI. I believe what you are
referring to is section 5.3 (uniqueness of attributes). It is illegal for
an element to contain qualified attribute names bound to the same
namespace uri, i.e.
<parent xmlns:ns1="/uri" xmlns:ns2="/uri">
<bad ns1:attribute="foo" ns2:attribute="foo"/>
</parent>
Regards,
--mike
On Fri, 9 Nov 2001, Berin Loritsch wrote:
> Peter Donald wrote:
> >
> > On Sat, 10 Nov 2001 09:23, Berin Loritsch wrote:
> > > Peter Donald wrote:
> > > > On Sat, 10 Nov 2001 01:23, Sylvain Wallez wrote:
> > > > > Berin Loritsch a �rit :
> > > > > > I want to clarify if everyone is happy with the Namespace
> > > > > > class. We need to take care of it NOW before it is too
> > > > > > late!
> > > > >
> > > > > Namespace info and Configuration names are OK for me, but a few
> > > > > questions about the prefix validation in Namespace.equals() :
> > > >
> > > > what is validation meant to do ? Neither the policy or m_validate_prefix
> > > > seem to be used.
> > >
> > > Hmm.
> > >
> > > Ok the policy is supposed to be a flag to use the prefix during
> > > comparisons of Namespace objects or not.
> > >
> > > I.e.
> > >
> > > pre1:element
> > > pre2:element
> > >
> > > Where pre1 and pre2 are set to "test-uri/namespace"
> > >
> > > With m_validate_prefix set to true, the two namespaces would be
> > > considered different. So .equals() would return false.
> > >
> > > With m_validate_prefix set to false, the two namespaces are
> > > considered the same (the all important URI is the same). So
> > > .equals() would return true.
> >
> > when would you want validate_prefix to be set to true? Doesn't that violate
> > basic principles of XML ? So I can think of a place I would like to use it
> > but then again that case is an ugly hack. Is there any legitimate uses for
> > this? ;)
>
> According to the XML Namespace spec, officially the namespace is different
> if the prefix is different. Of course, I may be applying something only
> meant for attributes to elements.
>
> In the end, I would like them to be treated the same even if the prefix
> is different--but that could have been accomplished by removing the
> Namespace object and ONLY keeping the URI in the configuration.
>
> > > > > - is this good to have a static setting for this policy in a
> > > > > multi-thread/multi-app environment ?
> > > >
> > > > probably not.
> > >
> > > How often do you create new Namespace objects?
> > Every time you create a Config tree ;)
>
> Usually done in one thread at init time.
>
> > > Also, wouldn't you
> > > want the same policy accross the board?
> >
> > no.
> >
> > Example: when ant2 goes live and I finally commit my jobserver,
> > ant2/jobserver will possibly be using a different policy than main
> > phoenix.
>
> I see.
>
> > > The Factory methods (.getNamespace(String)) can be extended to
> > > simply have a boolean to set the policy for the object.
> > >
> > > However you must keep in mind that multiple policies for comparing
> > > Namespace objects has unpredictable results. (actually it will
> > > use the policy of the Namespace object on the left side of the
> > > argument).
> >
> > you probably shouldn't be comparing namespace objects across domains anyway -
> > I would consider that an error in the code.
>
> So does the change to the factory method sound like the way to go?
>
>
>
> --
>
> "Those who would trade liberty for
> temporary security deserve neither"
> - Benjamin Franklin
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> On Sat, 10 Nov 2001 09:23, Berin Loritsch wrote:
> > Peter Donald wrote:
> > > On Sat, 10 Nov 2001 01:23, Sylvain Wallez wrote:
> > > > Berin Loritsch a �rit :
> > > > > I want to clarify if everyone is happy with the Namespace
> > > > > class. We need to take care of it NOW before it is too
> > > > > late!
> > > >
> > > > Namespace info and Configuration names are OK for me, but a few
> > > > questions about the prefix validation in Namespace.equals() :
> > >
> > > what is validation meant to do ? Neither the policy or m_validate_prefix
> > > seem to be used.
> >
> > Hmm.
> >
> > Ok the policy is supposed to be a flag to use the prefix during
> > comparisons of Namespace objects or not.
> >
> > I.e.
> >
> > pre1:element
> > pre2:element
> >
> > Where pre1 and pre2 are set to "test-uri/namespace"
> >
> > With m_validate_prefix set to true, the two namespaces would be
> > considered different. So .equals() would return false.
> >
> > With m_validate_prefix set to false, the two namespaces are
> > considered the same (the all important URI is the same). So
> > .equals() would return true.
>
> when would you want validate_prefix to be set to true? Doesn't that violate
> basic principles of XML ? So I can think of a place I would like to use it
> but then again that case is an ugly hack. Is there any legitimate uses for
> this? ;)
According to the XML Namespace spec, officially the namespace is different
if the prefix is different. Of course, I may be applying something only
meant for attributes to elements.
In the end, I would like them to be treated the same even if the prefix
is different--but that could have been accomplished by removing the
Namespace object and ONLY keeping the URI in the configuration.
> > > > - is this good to have a static setting for this policy in a
> > > > multi-thread/multi-app environment ?
> > >
> > > probably not.
> >
> > How often do you create new Namespace objects?
> Every time you create a Config tree ;)
Usually done in one thread at init time.
> > Also, wouldn't you
> > want the same policy accross the board?
>
> no.
>
> Example: when ant2 goes live and I finally commit my jobserver,
> ant2/jobserver will possibly be using a different policy than main
> phoenix.
I see.
> > The Factory methods (.getNamespace(String)) can be extended to
> > simply have a boolean to set the policy for the object.
> >
> > However you must keep in mind that multiple policies for comparing
> > Namespace objects has unpredictable results. (actually it will
> > use the policy of the Namespace object on the left side of the
> > argument).
>
> you probably shouldn't be comparing namespace objects across domains anyway -
> I would consider that an error in the code.
So does the change to the factory method sound like the way to go?
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Peter Donald <do...@apache.org>.
On Sat, 10 Nov 2001 09:23, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Sat, 10 Nov 2001 01:23, Sylvain Wallez wrote:
> > > Berin Loritsch a �rit :
> > > > I want to clarify if everyone is happy with the Namespace
> > > > class. We need to take care of it NOW before it is too
> > > > late!
> > >
> > > Namespace info and Configuration names are OK for me, but a few
> > > questions about the prefix validation in Namespace.equals() :
> >
> > what is validation meant to do ? Neither the policy or m_validate_prefix
> > seem to be used.
>
> Hmm.
>
> Ok the policy is supposed to be a flag to use the prefix during
> comparisons of Namespace objects or not.
>
> I.e.
>
> pre1:element
> pre2:element
>
> Where pre1 and pre2 are set to "test-uri/namespace"
>
> With m_validate_prefix set to true, the two namespaces would be
> considered different. So .equals() would return false.
>
> With m_validate_prefix set to false, the two namespaces are
> considered the same (the all important URI is the same). So
> .equals() would return true.
when would you want validate_prefix to be set to true? Doesn't that violate
basic principles of XML ? So I can think of a place I would like to use it
but then again that case is an ugly hack. Is there any legitimate uses for
this? ;)
> > > - is this good to have a static setting for this policy in a
> > > multi-thread/multi-app environment ?
> >
> > probably not.
>
> How often do you create new Namespace objects?
Every time you create a Config tree ;)
> Also, wouldn't you
> want the same policy accross the board?
no.
Example: when ant2 goes live and I finally commit my jobserver,
ant2/jobserver will possibly be using a different policy than main
phoenix.
> The Factory methods (.getNamespace(String)) can be extended to
> simply have a boolean to set the policy for the object.
>
> However you must keep in mind that multiple policies for comparing
> Namespace objects has unpredictable results. (actually it will
> use the policy of the Namespace object on the left side of the
> argument).
you probably shouldn't be comparing namespace objects across domains anyway -
I would consider that an error in the code.
--
Cheers,
Pete
*----------------------------------------------*
| The best defense against logic is ignorance. |
*----------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> On Sat, 10 Nov 2001 01:23, Sylvain Wallez wrote:
> > Berin Loritsch a �rit :
> > > I want to clarify if everyone is happy with the Namespace
> > > class. We need to take care of it NOW before it is too
> > > late!
> >
> > Namespace info and Configuration names are OK for me, but a few
> > questions about the prefix validation in Namespace.equals() :
>
> what is validation meant to do ? Neither the policy or m_validate_prefix seem
> to be used.
Hmm.
Ok the policy is supposed to be a flag to use the prefix during
comparisons of Namespace objects or not.
I.e.
pre1:element
pre2:element
Where pre1 and pre2 are set to "test-uri/namespace"
With m_validate_prefix set to true, the two namespaces would be
considered different. So .equals() would return false.
With m_validate_prefix set to false, the two namespaces are
considered the same (the all important URI is the same). So
.equals() would return true.
> > - is this good to have a static setting for this policy in a
> > multi-thread/multi-app environment ?
>
> probably not.
How often do you create new Namespace objects? Also, wouldn't you
want the same policy accross the board?
The Factory methods (.getNamespace(String)) can be extended to
simply have a boolean to set the policy for the object.
However you must keep in mind that multiple policies for comparing
Namespace objects has unpredictable results. (actually it will
use the policy of the Namespace object on the left side of the
argument).
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Peter Donald <do...@apache.org>.
On Sat, 10 Nov 2001 01:23, Sylvain Wallez wrote:
> Berin Loritsch a �rit :
> > I want to clarify if everyone is happy with the Namespace
> > class. We need to take care of it NOW before it is too
> > late!
>
> Namespace info and Configuration names are OK for me, but a few
> questions about the prefix validation in Namespace.equals() :
what is validation meant to do ? Neither the policy or m_validate_prefix seem
to be used.
> - is this good to have a static setting for this policy in a
> multi-thread/multi-app environment ?
probably not.
> Here's also a patch for exception messages : Peter removed ','
> characters from the patch I sent recently, but also removed the closing
> '"' for element names ! This patch adds them, but not the ',' !
oops ;) Applied.
--
Cheers,
Pete
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is everyone happy with Namespace?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch a �crit :
>
> I want to clarify if everyone is happy with the Namespace
> class. We need to take care of it NOW before it is too
> late!
Namespace info and Configuration names are OK for me, but a few
questions about the prefix validation in Namespace.equals() :
- Namespace.m_policy doesn't seem to be used. Shouldn't it be used in
Namespace.getNamespace() ? Otherwise m_validate_prefix is always true.
- is this good to have a static setting for this policy in a
multi-thread/multi-app environment ?
Here's also a patch for exception messages : Peter removed ','
characters from the patch I sent recently, but also removed the closing
'"' for element names ! This patch adds them, but not the ',' !
Thanks,
Sylvain.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com