You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Antonio Fornié <si...@gmail.com> on 2009/11/02 10:47:55 UTC
The need for pooling beans
Hello!
I'd like to know about the real need for pooling SLSB. I think a SLSB is
meant to have not shared data (not instance variables or so), it only has
methods that can be invoked from several clients at a time, right? Whay
can't my clients shared the same object? If there's no problem in more than
one thread using the same method of the same object (SLSB) at the same time,
why to have some SLSBs pooled instead of a singleton?
I find it's necessary in cases where the SLSB has for example a DB
connection as an instance variable, that should not be used by more than one
thread at the same time, but it's only for those kinds of cases?
Thank you very much!
Antonio
--
View this message in context: http://old.nabble.com/The-need-for-pooling-beans-tp26156648s134p26156648.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: The need for pooling beans
Posted by Quintin Beukes <qu...@skywalk.co.za>.
We're missing each other here. What I'm trying to explain is justifications
for why it's there in the first place, and some general ideas behind the
motivations for each - at least from my PoV.
Regarding why pooling is there. Sure it's not needed in all the cases. But
for the design to work for all cases it was placed there. In some situations
concurrent calls are absolutely forbidden, and it's impossible for the
container to know this without adding extra complexity. So they make pools.
An alternative would be to create new instances, but what if creating an
instance is a heavyweight operation? So they pre-create them and add them
into a pool. Now everyone can be served from the same platter.
Assume it would take 500ms to 1000ms to create an instance, and the logic of
the bean is complex with multiple this.calls() and member variables being
used so concurrency isn't possible on an instance, and you're serving many
requests per second. A pool is very useful for such a situation.
In the end there is no harm in a pool. It might just be more optimal without
it for some (or even most) cases.
To try and explain it a bit simpler. Lets say you were designing an
application and a requirement was to pick a one-size-fits-all design. A
given is that it will be used in threaded and non-threaded environments. A
thread safe design will work for both threaded/non threaded scenarios. A non
thread safe design will work only for non threaded scenarios. So which
design would be best, thread-safe or non-thread-safe? Obviously the
thread-safe?
Or a more natural world (though stupid) example. You have to serve food to
group of people and keep everyone happy. You're not sure if some people
might be offended by eating meat. So you make a tasteful green meal, because
"meat eaters" aren't offended by eating greens.
Now, just like you say the pooling is needed in the rarest of cases. It's
true. I've only had a single case ever where multiple SLSB instances were
truly useful/needed. So Singletons were born for the rest of the scenarios,
and they will most probably become the most used EJB (after entities, though
IIUC entities technically aren't EJBs anymore). In my current project I'm
using only 1 SFSB, 1 SLSB and a whole bunch of Singleton beans. Why? Because
I need only one instance of each and concurrency is not an issue.
Regarding why we were so "lucky for having pools". I guess it's because of
the benefits it does have for the more complex scenarios. Remember that EJBs
were designed for solving complex enterprise system problems. So this
statement was probably made keeping in mind those problems.
Quintin Beukes
On Fri, Nov 6, 2009 at 1:07 AM, Antonio Fornié <si...@gmail.com>wrote:
>
> Yes, it does! Thank you! It was not just a question but also an opinion.
>
> Sometimes I need transaction and security (so I need EJB according to Sun),
> but I'd prefer not to have pooling. If I only needed a Singleton I could do
> it by myself but it wouldn't be an EJB, so yes, sometimes I need this new
> Singleton EJB that's about to come.
>
> In fact, I think by and large we don't need pooling so, prior to EJB 3.1,
> is
> it a good idea to use EJB for all my Bussiness Objects or only for a few?
> That's what I'm pointing out. I'm not sure about that general need for
> pooling... even when Sun and App Server vendors are so proud about their
> bean pools, it doesn't mean I need it.
>
>
> On the other hand I don't see why you say:
> >> That's because servlets are unmanaged components.
> As far as I see this has nothing to do. I insist, Spring showed everybody
> we
> can live without pooled beans, and it's even better for the 90% of times.
> Managed or unmanaged components. In fact future Singleton EJBs will be
> manged components too.
>
>
> >>Spring might not have pooling, but this isn't necessary on the client
> side.
> I'm afraid I don't you what you mean. Please, why do you talk about the
> client side? I only say that most of the times we don't have any problem if
> different threads or even different clients are using the same object at a
> time. In a near future we'll have Singleton EJB, but for many years we've
> been told how lucky we were to have pooled beans... for so many years this
> was not the way (except for a few cases). Don't you agree?
>
>
> >>The container manages this for you. This is another example of why SLSBs
> are pooled.
> Yes, this is why they say they pool SLSBs, but the problem is that it's not
> needed. Spring manages for you access to objects (by IoC) and it doesn't
> mean that those objects should have been pooled. Of course it's good to use
> pools in some situations, but when you follow the Sun official path (for
> example, if you want to study for the Sun Certificate Enterprise Architect
> as I'm doing) you are told that for any application big enough not to use
> only Servlets/JSP you need an EJB container. And you read the J2EE Core
> Patterns and you may end up believing you need pooled beans for a Session
> Facade and similar cases... do you think that's true? Thounsands of Spring
> applications use singletons even for DAOs. I may be missing something, but
> as far as I can see it's like using a Ferrari to go to the bathroom. But
> please, I really think there's something I must be missing and I'd like to
> be taught.
>
> Sorry if I talk about Spring, it's because it's the most famous
> alternative.
> Thank you very much!
> --
> View this message in context:
> http://old.nabble.com/The-need-for-pooling-beans-tp26156648s134p26223990.html
> Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
>
>
Re: The need for pooling beans
Posted by Antonio Fornié <si...@gmail.com>.
Yes, it does! Thank you! It was not just a question but also an opinion.
Sometimes I need transaction and security (so I need EJB according to Sun),
but I'd prefer not to have pooling. If I only needed a Singleton I could do
it by myself but it wouldn't be an EJB, so yes, sometimes I need this new
Singleton EJB that's about to come.
In fact, I think by and large we don't need pooling so, prior to EJB 3.1, is
it a good idea to use EJB for all my Bussiness Objects or only for a few?
That's what I'm pointing out. I'm not sure about that general need for
pooling... even when Sun and App Server vendors are so proud about their
bean pools, it doesn't mean I need it.
On the other hand I don't see why you say:
>> That's because servlets are unmanaged components.
As far as I see this has nothing to do. I insist, Spring showed everybody we
can live without pooled beans, and it's even better for the 90% of times.
Managed or unmanaged components. In fact future Singleton EJBs will be
manged components too.
>>Spring might not have pooling, but this isn't necessary on the client
side.
I'm afraid I don't you what you mean. Please, why do you talk about the
client side? I only say that most of the times we don't have any problem if
different threads or even different clients are using the same object at a
time. In a near future we'll have Singleton EJB, but for many years we've
been told how lucky we were to have pooled beans... for so many years this
was not the way (except for a few cases). Don't you agree?
>>The container manages this for you. This is another example of why SLSBs
are pooled.
Yes, this is why they say they pool SLSBs, but the problem is that it's not
needed. Spring manages for you access to objects (by IoC) and it doesn't
mean that those objects should have been pooled. Of course it's good to use
pools in some situations, but when you follow the Sun official path (for
example, if you want to study for the Sun Certificate Enterprise Architect
as I'm doing) you are told that for any application big enough not to use
only Servlets/JSP you need an EJB container. And you read the J2EE Core
Patterns and you may end up believing you need pooled beans for a Session
Facade and similar cases... do you think that's true? Thounsands of Spring
applications use singletons even for DAOs. I may be missing something, but
as far as I can see it's like using a Ferrari to go to the bathroom. But
please, I really think there's something I must be missing and I'd like to
be taught.
Sorry if I talk about Spring, it's because it's the most famous alternative.
Thank you very much!
--
View this message in context: http://old.nabble.com/The-need-for-pooling-beans-tp26156648s134p26223990.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: The need for pooling beans
Posted by Quintin Beukes <qu...@skywalk.co.za>.
I'm not sure I understand your question?
But why to use bean pooling for a Session Facade (implemented with a SLSB)?
> We can't assure that two clients using the same method of a service bean
> will bring problems.
Which is why you're only allowed one bean per request. This way you can rely
on the variables not being changed by another thread.
> In fact, that's the idea behind servlets: only one
> instance per servlet. Clients use the same servlet instance at a time.
That's because servlets are unmanaged components. You have to use the
different servlet contexts to process the request into a response, ex. the
SessionContext. It's a much older spec and designed to be free/flexible.
The EJB spec on the other hand was designed to be managed components. Many
resources can be injected into a bean which are building blocks for JavaEE,
some of which might not allow concurrent calls themselves, you can't know
for sure so it's a general policy to not allow concurrent calls on the same
instance. Pooling the SLSBs ensures that the request can be processed and
it's members won't be accessed concurrently. The container can guarantee
safety for both thread safe and non thread safe resources if it uses this
policy. EJBs also provide managed transactions, which won't be possible if 2
concurrent calls were to use the same injected DB connection. There are many
reasons, all related to concurrency in some way for why SLSBs are pooled.
With a servlets these things are all responsibilities of the developer, ie.
servlets are unmanaged. I guess one reason for this is because servlets were
made for a protocol which is much older, ie. HTTP. So to stay compatible
with and provide all the functionality available to it they left the
developer with this freedom. To ease this burden many people have written
frameworks to follow a chosen design, and effectively making managed
components.out of your webapp components.
Of
> course there will be cases where it's good to ask for a new instance of a
> bean (or create it or whatever), for example, when we know we have
> not-shareable resources, like an instance variable that is a DB connection.
>
The container manages this for you. This is another example of why SLSBs are
pooled. If you want fine grained control over the life cycle of your
components, you can use SFSBs or use an alternative system inside the SLSB,
like Spring beans or an instance manager component which your SLSBs query
for instances of the component.
> But that's not to assume that EVERY SLSB has to be pooled. It may bring
> more
> handicaps than advantages...
>
>
This is true. Many people have simple SLSBs which would work just as well,
if not better when there is only a single instance with no concurrency
control, which is what was addressed EJB3.1 resulting in the Singleton EJB
(annotated with javax.ejb.Singleton).
Does this answer your question?
Q
Re: Help me
Posted by chi runhua <ch...@gmail.com>.
I just update the page[1] in G2.2 doc to make it more clear for users when
they're trying to build a 2.2 server.
[1] http://cwiki.apache.org/GMOxDOC22/building-geronimo-with-maven.html
Thanks Xasima for spotting this out.
Jeff C
On Fri, Nov 6, 2009 at 5:48 PM, Forrest Xia <fo...@gmail.com> wrote:
> Hi Xasima,
> Seems to me you are building geronimo 3.0 from the trunk. If you tend to
> build G 2.2, you are supposed to check out from
> http://svn.apache.org/repos/asf/geronimo/server/branches/2.2/.
>
> Forrest
>
>
Re: Help me
Posted by Forrest Xia <fo...@gmail.com>.
Hi Xasima,
Seems to me you are building geronimo 3.0 from the trunk. If you tend to
build G 2.2, you are supposed to check out from
http://svn.apache.org/repos/asf/geronimo/server/branches/2.2/.
Forrest
Re: Help me
Posted by Xasima <xa...@gmail.com>.
Hello. I have troubles to build geronimo 2.2 from sources as well.
Failed to build for revision 833325 without test. It's seems to be the same
error as noted in
http://old.nabble.com/-BUILD--trunk:-Failed-for-Revision:-831062-td26119050s134.html
-----------------------------------
[root@build-server dist]# uname -a
Linux build-server 2.6.18-164.el5xen #1 SMP Thu Sep 3 04:47:32 EDT 2009 i686
i686 i386 GNU/Linux
[root@build-server dist]# java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)
[root@build-server dist]# mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 17:16:01-0200)
Java version: 1.6.0_16
Java home: /usr/java/jdk1.6.0_16/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.18-164.el5xen" arch: "i386" Family: "unix"
[root@build-server dist]# ant -version
Apache Ant version 1.7.1 compiled on June 27 2008
[root@build-server dist]# bash
[root@build-server dist]# export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=128m"
[root@build-server dist]# echo $MAVEN_OPTS
-Xmx512m -XX:MaxPermSize=128m
[root@build-server dist]# svn co
https://svn.apache.org/repos/asf/geronimo/server/trunk server
.............
Checked out revision 833325.
[root@build-server dist]# mvn clean install -Dtest=false -e
............................
[INFO] Unable to find resource
'org.apache.servicemix.bundles:bundles-pom:pom:4-SNAPSHOT' in repository
apache.snapshots (http://repository.apache.org/snapshots)
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID:
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:bundle:2.1_3_3-SNAPSHOT
Reason: Cannot find parent: org.apache.servicemix.bundles:bundles-pom for
project:
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:bundle:2.1_3_3-SNAPSHOT
for project
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:bundle:2.1_3_3-SNAPSHOT
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Unable to get
dependency information: Unable to read the metadata file for artifact
'org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:jar':
Cannot find parent: org.apache.servicemix.bundles:bundles-pom for project:
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:bundle:2.1_3_3-SNAPSHOT
for project
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:bundle:2.1_3_3-SNAPSHOT
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:jar:2.1_3_3-SNAPSHOT
from the specified remote repositories:
apache.snapshots (http://repository.apache.org/snapshots),
codehaus.snapshots (http://snapshots.repository.codehaus.org),
central (http://repo1.maven.org/maven2)
Path to dependency:
1)
org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:3.0-SNAPSHOT
2) org.apache.geronimo.framework:geronimo-common:jar:3.0-SNAPSHOT
3) org.apache.geronimo.framework:geronimo-kernel:jar:3.0-SNAPSHOT
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.loadPluginFully(DefaultLifecycleExecutor.java:1607)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.findArtifactTypeHandlersInPlugins(DefaultLifecycleExecutor.java:1468)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions(DefaultLifecycleExecutor.java:222)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:178)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException:
Unable to get dependency information: Unable to read the metadata file for
artifact
'org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:jar':
Cannot find parent: org.apache.servicemix.bundles:bundles-pom for project:
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:bundle:2.1_3_3-SNAPSHOT
for project
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:bundle:2.1_3_3-SNAPSHOT
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:jar:2.1_3_3-SNAPSHOT
from the specified remote repositories:
apache.snapshots (http://repository.apache.org/snapshots),
codehaus.snapshots (http://snapshots.repository.codehaus.org),
central (http://repo1.maven.org/maven2)
Path to dependency:
1)
org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:3.0-SNAPSHOT
2) org.apache.geronimo.framework:geronimo-common:jar:3.0-SNAPSHOT
3) org.apache.geronimo.framework:geronimo-kernel:jar:3.0-SNAPSHOT
at
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:430)
at
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:435)
at
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:435)
at
org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:316)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:304)
at
org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:835)
at
org.apache.maven.plugin.DefaultPluginManager.loadPluginFully(DefaultPluginManager.java:1629)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.loadPluginFully(DefaultLifecycleExecutor.java:1582)
... 15 more
Caused by:
org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException:
Unable to read the metadata file for artifact
'org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:jar':
Cannot find parent: org.apache.servicemix.bundles:bundles-pom for project:
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:bundle:2.1_3_3-SNAPSHOT
for project
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:bundle:2.1_3_3-SNAPSHOT
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:200)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedArtifact(MavenMetadataSource.java:94)
at
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:387)
... 23 more
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find
parent: org.apache.servicemix.bundles:bundles-pom for project:
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:bundle:2.1_3_3-SNAPSHOT
for project
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:bundle:2.1_3_3-SNAPSHOT
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1396)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:823)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:255)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:163)
... 25 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM
'org.apache.servicemix.bundles:bundles-pom' not found in repository: Unable
to download the artifact from any repository
org.apache.servicemix.bundles:bundles-pom:pom:4-SNAPSHOT
from the specified remote repositories:
apache.snapshots (http://repository.apache.org/snapshots),
codehaus.snapshots (http://snapshots.repository.codehaus.org),
central (http://repo1.maven.org/maven2)
for project org.apache.servicemix.bundles:bundles-pom
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:605)
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1392)
... 28 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException:
Unable to download the artifact from any repository
org.apache.servicemix.bundles:bundles-pom:pom:4-SNAPSHOT
from the specified remote repositories:
apache.snapshots (http://repository.apache.org/snapshots),
codehaus.snapshots (http://snapshots.repository.codehaus.org),
central (http://repo1.maven.org/maven2)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:228)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90)
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:558)
... 29 more
Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to
download the artifact from any repository
at
org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:404)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:216)
... 31 more
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1 minute 49 seconds
[INFO] Finished at: Fri Nov 06 07:30:49 GMT-02:00 2009
[INFO] Final Memory: 80M/144M
[INFO]
------------------------------------------------------------------------
[root@system-gwa server]#
On Fri, Nov 6, 2009 at 6:20 AM, Forrest Xia <fo...@gmail.com> wrote:
>
>
> On Fri, Nov 6, 2009 at 11:40 AM, Fei LI <FL...@mdacorporation.com> wrote:
>
>> Hi Forrest,
>>
>> Thanks for your help first. Let me build server first the build eclipse
>> plugin second. Because I tried many SVN and no one working. So let me put my
>> question in such way. Tell me if you know, the newest version you know it
>> will be built without error, I have Windows XP and Vista.
>> 1. for server:
>> 1.1 which java version? sun jdk 1.5 latest
>> 1.2 which maven version? 2.2.1
>> 1.3 which SVN source?
>> http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.4/
>> 1.4. which mvn command? mvn clean install -Dtest=false -e
>>
>
> Besides, you need to pay attention to these:
> 1. if using sun jdk, you need to set MAVEN_OPTS as documentation. If using
> ibm jdk, you won't do that
> 2. checkout the source code in a short path name as Donald pointed out
> 3. In your DOS window, change your locale to en_US by executing: chcp 437
> and then start to build server.
>
>
>>
>> 1. for Eclipse plugin:
>> 1.1 which java version?
>> 1.2 which maven version?
>> 1.3 which SVN source?
>> 1.4. which mvn command?
>>
>
> Please try to make server built successfully, then let's see how to build
> GEP.
>
> Good luck!
>
>>
>> I will do whatever you suggest and to see if I luck or not.
>>
>>
>> Thanks
>>
>> Fei Li
>>
>>
>> ------------------------------
>> *From:* Forrest Xia [mailto:forrestxm@gmail.com]
>> *Sent:* Thu 05/11/2009 7:20 PM
>> *To:* user@geronimo.apache.org
>> *Subject:* Re: Help me
>>
>> Before building geronimo eclipse plugin(gep), you need to build geronimo
>> server first.
>>
>> Suggest you start with a released code tree to build gep, not the trunk
>> code. Generally, trunk code is changing and unstable.
>>
>> For a better understanding what you are doing, pls tell:
>> 1. which version of geronimo you are going to work on?
>> 2. what jdk you are using to build gep?
>> 3. Any error when you are building geronimo server?
>>
>> Forrest
>>
>
>
--
Best regards,
~ Xasima ~
RE: Help me
Posted by Fei LI <FL...@mdacorporation.com>.
Hi Forrest,
I tested it again with another OS, Windows XP, the same error.
Can you tell me another version I can try.
Or
Just tell me what is your development environment for the SVN trunk. Do
you work on the trunk? Do you commit in your work from time to time?
Thanks
Fei Li
________________________________
From: Fei LI [mailto:FLI@mdacorporation.com]
Sent: Friday, November 06, 2009 8:12 AM
To: user@geronimo.apache.org; forrestxm@gmail.com
Subject: RE: Help me
Hi Forrest,
I got build error for you. My environment are;
1. Windows Vista
2. Java jsdk1.5.0_22
3. Maven 2.2.1
4. SVN source?
http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.4/
5. mvn command mvn clean install -Dtest=false -e
"
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Internal error in the plugin manager getting plugin
'org.codehaus.mojo.jspc:jspc-maven-plugin': Plugin
'org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-1-20070806' has an
invalid descriptor:
1) Plugin's descriptor contains the wrong version: 2.0-alpha-1-SNAPSHOT
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error
in the plugin manager getting plugin
'org.codehaus.mojo.jspc:jspc-maven-plugin': Plugin
'org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-1-20070806' has an
invalid descriptor:
1) Plugin's descriptor contains the wrong version: 2.0-alpha-1-SNAPSHOT
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Default
LifecycleExecutor.java:1544)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycl
e(DefaultLifecycleExecutor.java:1503)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMa
ppings(DefaultLifecycleExecutor.java:1282)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL
ifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle
Failures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec
ycleExecutor.java:180)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.PluginManagerException: Plugin
'org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-1-20070806' has an
invalid d
escriptor:
1) Plugin's descriptor contains the wrong version: 2.0-alpha-1-SNAPSHOT
at
org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginMana
ger.java:330)
at
org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(Defau
ltPluginManager.java:224)
at
org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginM
anager.java:184)
at
org.apache.maven.plugin.DefaultPluginManager.loadPluginDescriptor(Defaul
tPluginManager.java:1642)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Default
LifecycleExecutor.java:1540)
... 18 more
"
________________________________
From: Forrest Xia [mailto:forrestxm@gmail.com]
Sent: Thu 05/11/2009 8:20 PM
To: user@geronimo.apache.org
Subject: Re: Help me
On Fri, Nov 6, 2009 at 11:40 AM, Fei LI <FL...@mdacorporation.com> wrote:
Hi Forrest,
Thanks for your help first. Let me build server first the build
eclipse plugin second. Because I tried many SVN and no one working. So
let me put my question in such way. Tell me if you know, the newest
version you know it will be built without error, I have Windows XP and
Vista.
1. for server:
1.1 which java version? sun jdk 1.5 latest
1.2 which maven version? 2.2.1
1.3 which SVN source?
http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.4/
1.4. which mvn command? mvn clean install -Dtest=false -e
Besides, you need to pay attention to these:
1. if using sun jdk, you need to set MAVEN_OPTS as documentation. If
using ibm jdk, you won't do that
2. checkout the source code in a short path name as Donald pointed out
3. In your DOS window, change your locale to en_US by executing: chcp
437
and then start to build server.
1. for Eclipse plugin:
1.1 which java version?
1.2 which maven version?
1.3 which SVN source?
1.4. which mvn command?
Please try to make server built successfully, then let's see how to
build GEP.
Good luck!
I will do whatever you suggest and to see if I luck or not.
Thanks
Fei Li
________________________________
From: Forrest Xia [mailto:forrestxm@gmail.com]
Sent: Thu 05/11/2009 7:20 PM
To: user@geronimo.apache.org
Subject: Re: Help me
Before building geronimo eclipse plugin(gep), you need to build
geronimo server first.
Suggest you start with a released code tree to build gep, not
the trunk code. Generally, trunk code is changing and unstable.
For a better understanding what you are doing, pls tell:
1. which version of geronimo you are going to work on?
2. what jdk you are using to build gep?
3. Any error when you are building geronimo server?
Forrest
RE: Help me
Posted by Fei LI <FL...@mdacorporation.com>.
Hi Forrest,
I got build error for you. My environment are;
1. Windows Vista
2. Java jsdk1.5.0_22
3. Maven 2.2.1
4. SVN source? http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.4/
5. mvn command mvn clean install -Dtest=false -e
"
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Internal error in the plugin manager getting plugin 'org.codehaus.mojo.jspc:jspc-maven-plugin': Plugin 'org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-1-20070806' has an invalid descriptor:
1) Plugin's descriptor contains the wrong version: 2.0-alpha-1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager getting plugin 'org.codehaus.mojo.jspc:jspc-maven-plugin': Plugin 'org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-1-20070806' has an invalid descriptor:
1) Plugin's descriptor contains the wrong version: 2.0-alpha-1-SNAPSHOT
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1544)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1503)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1282)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:534)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.PluginManagerException: Plugin 'org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-alpha-1-20070806' has an invalid d
escriptor:
1) Plugin's descriptor contains the wrong version: 2.0-alpha-1-SNAPSHOT
at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:330)
at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:224)
at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:184)
at org.apache.maven.plugin.DefaultPluginManager.loadPluginDescriptor(DefaultPluginManager.java:1642)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1540)
... 18 more
"
________________________________
From: Forrest Xia [mailto:forrestxm@gmail.com]
Sent: Thu 05/11/2009 8:20 PM
To: user@geronimo.apache.org
Subject: Re: Help me
On Fri, Nov 6, 2009 at 11:40 AM, Fei LI <FL...@mdacorporation.com> wrote:
Hi Forrest,
Thanks for your help first. Let me build server first the build eclipse plugin second. Because I tried many SVN and no one working. So let me put my question in such way. Tell me if you know, the newest version you know it will be built without error, I have Windows XP and Vista.
1. for server:
1.1 which java version? sun jdk 1.5 latest
1.2 which maven version? 2.2.1
1.3 which SVN source? http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.4/
1.4. which mvn command? mvn clean install -Dtest=false -e
Besides, you need to pay attention to these:
1. if using sun jdk, you need to set MAVEN_OPTS as documentation. If using ibm jdk, you won't do that
2. checkout the source code in a short path name as Donald pointed out
3. In your DOS window, change your locale to en_US by executing: chcp 437
and then start to build server.
1. for Eclipse plugin:
1.1 which java version?
1.2 which maven version?
1.3 which SVN source?
1.4. which mvn command?
Please try to make server built successfully, then let's see how to build GEP.
Good luck!
I will do whatever you suggest and to see if I luck or not.
Thanks
Fei Li
________________________________
From: Forrest Xia [mailto:forrestxm@gmail.com]
Sent: Thu 05/11/2009 7:20 PM
To: user@geronimo.apache.org
Subject: Re: Help me
Before building geronimo eclipse plugin(gep), you need to build geronimo server first.
Suggest you start with a released code tree to build gep, not the trunk code. Generally, trunk code is changing and unstable.
For a better understanding what you are doing, pls tell:
1. which version of geronimo you are going to work on?
2. what jdk you are using to build gep?
3. Any error when you are building geronimo server?
Forrest
Re: Help me
Posted by Forrest Xia <fo...@gmail.com>.
On Fri, Nov 6, 2009 at 11:40 AM, Fei LI <FL...@mdacorporation.com> wrote:
> Hi Forrest,
>
> Thanks for your help first. Let me build server first the build eclipse
> plugin second. Because I tried many SVN and no one working. So let me put my
> question in such way. Tell me if you know, the newest version you know it
> will be built without error, I have Windows XP and Vista.
> 1. for server:
> 1.1 which java version? sun jdk 1.5 latest
> 1.2 which maven version? 2.2.1
> 1.3 which SVN source?
> http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.4/
> 1.4. which mvn command? mvn clean install -Dtest=false -e
>
Besides, you need to pay attention to these:
1. if using sun jdk, you need to set MAVEN_OPTS as documentation. If using
ibm jdk, you won't do that
2. checkout the source code in a short path name as Donald pointed out
3. In your DOS window, change your locale to en_US by executing: chcp 437
and then start to build server.
>
> 1. for Eclipse plugin:
> 1.1 which java version?
> 1.2 which maven version?
> 1.3 which SVN source?
> 1.4. which mvn command?
>
Please try to make server built successfully, then let's see how to build
GEP.
Good luck!
>
> I will do whatever you suggest and to see if I luck or not.
>
>
> Thanks
>
> Fei Li
>
>
> ------------------------------
> *From:* Forrest Xia [mailto:forrestxm@gmail.com]
> *Sent:* Thu 05/11/2009 7:20 PM
> *To:* user@geronimo.apache.org
> *Subject:* Re: Help me
>
> Before building geronimo eclipse plugin(gep), you need to build geronimo
> server first.
>
> Suggest you start with a released code tree to build gep, not the trunk
> code. Generally, trunk code is changing and unstable.
>
> For a better understanding what you are doing, pls tell:
> 1. which version of geronimo you are going to work on?
> 2. what jdk you are using to build gep?
> 3. Any error when you are building geronimo server?
>
> Forrest
>
RE: Help me
Posted by Fei LI <FL...@mdacorporation.com>.
Hi Forrest,
Thanks for your help first. Let me build server first the build eclipse plugin second. Because I tried many SVN and no one working. So let me put my question in such way. Tell me if you know, the newest version you know it will be built without error, I have Windows XP and Vista.
1. for server:
1.1 which java version?
1.2 which maven version?
1.3 which SVN source?
1.4. which mvn command?
1. for Eclipse plugin:
1.1 which java version?
1.2 which maven version?
1.3 which SVN source?
1.4. which mvn command?
I will do whatever you suggest and to see if I luck or not.
Thanks
Fei Li
________________________________
From: Forrest Xia [mailto:forrestxm@gmail.com]
Sent: Thu 05/11/2009 7:20 PM
To: user@geronimo.apache.org
Subject: Re: Help me
Before building geronimo eclipse plugin(gep), you need to build geronimo server first.
Suggest you start with a released code tree to build gep, not the trunk code. Generally, trunk code is changing and unstable.
For a better understanding what you are doing, pls tell:
1. which version of geronimo you are going to work on?
2. what jdk you are using to build gep?
3. Any error when you are building geronimo server?
Forrest
Re: Help me
Posted by Forrest Xia <fo...@gmail.com>.
Before building geronimo eclipse plugin(gep), you need to build geronimo
server first.
Suggest you start with a released code tree to build gep, not the trunk
code. Generally, trunk code is changing and unstable.
For a better understanding what you are doing, pls tell:
1. which version of geronimo you are going to work on?
2. what jdk you are using to build gep?
3. Any error when you are building geronimo server?
Forrest
Help me
Posted by Fei LI <FL...@mdacorporation.com>.
Hi,
I am 100% new.
I could not find help anywhere. Anybody can tell me where is my help?
Thanks first.
I want to learn geronimo and do some develop for it if possible. I
followed the instruction from apache-geronimo page "How to Build
Geronimo Eclipse Plugin from Source"
1. installed Apache Maven 2.0.9
2.get source code from
http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/trunk
3. set MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=128m
3. run command mvn clean install -Ptestsuite.
I always got error, missing something or run test error.
Thanks
Fei Li
Re: The need for pooling beans
Posted by Antonio Fornié <si...@gmail.com>.
Thank you for your reply. By the way two comments:
Quintin Beukes-2 wrote:
>
> I'm not sure if the same applies to calling different business methods on
> the same
> SLSB, though I don't think it does.
>
It does. It's not possible that two clients are using the same SLSB at a
time, even if they're using different methods. Imagine what would happen if
method B was called inside method A and two clients were using methods A and
B of the same instance.. they could end up in the same method of the same
bean.
Quintin Beukes-2 wrote:
>
> ...if 2 clients request to invoke the same business method on the same
> bean
> at the same time, one will be served first, while the other will block.
> When
> the first one returns the 2nd caller will be released to invoke the
> method.
> The pooling of SLSB is to avoid this, so with a given pool size of X you
> can
> have X concurrent business method invocations for any given bean...
>
Yes, that's true. And I understand this idea in case of, for example, DB
connection pooling: a)Connetions are created before your request them and
you reuse them. b) There will never be two clients trying to use the same
connection. c) There SHOULD never be a client waiting for other clients to
release a connection.
But why to use bean pooling for a Session Facade (implemented with a SLSB)?
We can't assure that two clients using the same method of a service bean
will bring problems. In fact, that's the idea behind servlets: only one
instance per servlet. Clients use the same servlet instance at a time. Of
course there will be cases where it's good to ask for a new instance of a
bean (or create it or whatever), for example, when we know we have
not-shareable resources, like an instance variable that is a DB connection.
But that's not to assume that EVERY SLSB has to be pooled. It may bring more
handicaps than advantages...
--
View this message in context: http://old.nabble.com/The-need-for-pooling-beans-tp26156648s134p26196878.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: The need for pooling beans
Posted by Quintin Beukes <qu...@skywalk.co.za>.
Hey,
IIUC a stateless session bean instance can have only caller at a given time.
So if 2 clients request to invoke the same business method on the same bean
at the same time, one will be served first, while the other will block. When
the first one returns the 2nd caller will be released to invoke the method.
The pooling of SLSB is to avoid this, so with a given pool size of X you can
have X concurrent business method invocations for any given bean. I'm not
sure if the same applies to calling different business methods on the same
SLSB, though I don't think it does.
Spring might not have pooling, but this isn't necessary on the client side.
Spring proxies the actual invocation to the server anyway so the
requests/pooling will be handled by the server. If you are using Spring
inside your SLSBs to do lookups of other beans, you might end up with
problems if Spring is configured to return Singleton instances of that
Spring Bean. If this is what you're doing, rather configure it to return a
unique instance for every Spring Bean lookup, so you could benefit from the
SB pooling of the server, or use a unique ApplicationContext inside every
SLSB instance - though the former is probably a better option.
Quintin Beukes
On Wed, Nov 4, 2009 at 1:19 PM, Antonio Fornié <si...@gmail.com>wrote:
>
> > IIUC ejb 3.1 includes singleton ejbs. I don't know much about them.
>
> Yes, I knew it. It will be very usefull when it arrives. By now we have to
> take other ways :)
>
> > This is wrong. Each client gets a separate copy of the SLSB so that
> > indeed they can have instance variables and separate requests don't
> > interfere with each other. I won't try to comment on how useful
> > instance variables are in an object called exactly once, but that is
> > the design.
>
> I think having variable instances in a SLSB for state values is not a good
> idea, eventhough you can do it by your own risk. I even think in O'Reilly
> Enterprise JavaBeans 3.0 book I read it was contraindicated. If you put a
> value in a variable instance, when next client for this SLSB instance use
> calls a method, the value will be there and the method invoked should
> initialize it again or at least ignore it.
>
> Of course you should have variable instances for other EJBs, DB
> connections,
> configuration parameters and so on... but never a variable meant to be
> changed during the execution of a method. So, in which scenario would it a
> problem to have two threads (and two clients) using the same SLSB instance?
> Or in others words, in which scenario could I have concurrence problems
> inside a SLSB?
>
> What I mean is, Spring doesn't have beans pooled and it doesn't seem to be
> a
> problem. Why is it so important to have SLSB pooled?
>
> Thank you all for your replies!
> --
> View this message in context:
> http://old.nabble.com/The-need-for-pooling-beans-tp26156648s134p26194495.html
> Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
>
>
Re: The need for pooling beans
Posted by Antonio Fornié <si...@gmail.com>.
> IIUC ejb 3.1 includes singleton ejbs. I don't know much about them.
Yes, I knew it. It will be very usefull when it arrives. By now we have to
take other ways :)
> This is wrong. Each client gets a separate copy of the SLSB so that
> indeed they can have instance variables and separate requests don't
> interfere with each other. I won't try to comment on how useful
> instance variables are in an object called exactly once, but that is
> the design.
I think having variable instances in a SLSB for state values is not a good
idea, eventhough you can do it by your own risk. I even think in O'Reilly
Enterprise JavaBeans 3.0 book I read it was contraindicated. If you put a
value in a variable instance, when next client for this SLSB instance use
calls a method, the value will be there and the method invoked should
initialize it again or at least ignore it.
Of course you should have variable instances for other EJBs, DB connections,
configuration parameters and so on... but never a variable meant to be
changed during the execution of a method. So, in which scenario would it a
problem to have two threads (and two clients) using the same SLSB instance?
Or in others words, in which scenario could I have concurrence problems
inside a SLSB?
What I mean is, Spring doesn't have beans pooled and it doesn't seem to be a
problem. Why is it so important to have SLSB pooled?
Thank you all for your replies!
--
View this message in context: http://old.nabble.com/The-need-for-pooling-beans-tp26156648s134p26194495.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: The need for pooling beans
Posted by David Jencks <da...@yahoo.com>.
On Nov 2, 2009, at 1:47 AM, Antonio Fornié wrote:
>
> Hello!
>
> I'd like to know about the real need for pooling SLSB. I think a
> SLSB is
> meant to have not shared data (not instance variables or so), it
> only has
> methods that can be invoked from several clients at a time, right?
This is wrong. Each client gets a separate copy of the SLSB so that
indeed they can have instance variables and separate requests don't
interfere with each other. I won't try to comment on how useful
instance variables are in an object called exactly once, but that is
the design.
> Whay
> can't my clients shared the same object? If there's no problem in
> more than
> one thread using the same method of the same object (SLSB) at the
> same time,
> why to have some SLSBs pooled instead of a singleton?
>
IIUC ejb 3.1 includes singleton ejbs. I don't know much about them.
thanks
david jencks
> I find it's necessary in cases where the SLSB has for example a DB
> connection as an instance variable, that should not be used by more
> than one
> thread at the same time, but it's only for those kinds of cases?
>
> Thank you very much!
>
> Antonio
> --
> View this message in context: http://old.nabble.com/The-need-for-pooling-beans-tp26156648s134p26156648.html
> Sent from the Apache Geronimo - Users mailing list archive at
> Nabble.com.
>