Not before I know how to do such examples. I am currently a bit busy
understanding limitations of JSF in regards to componentization.
BTW, regarding the mapping from names to FactoryMethod's, which is
application-wide (stored in Init): the situation is quite similar to an
application-wide mappi
Are there any guidelines which classes/interfaces/methods in Seam are API, and
which are an implementation detail and subject to change?
I mean something along the lines of http://dev.eclipse.org/naming.html.
This would help the people that are using, but especially extending Seam to
save their
Aha, found a reply in archives:
http://jboss.org/index.html?module=bb&op=viewtopic&p=3946281.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3947683#3947683
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3947683
--
I am trying to deploy a really simple EAR to JBoss 4.0.4 GA, and I have the
following exception:
org.jboss.deployment.DeploymentException: No META-INF/application.xml found
at org.jboss.deployment.EARDeployer.init(EARDeployer.java:133)
at org.jboss.deployment.MainDeployer.init(Main
Could you provide an estimate of the availability of these examples
demonstrating how to build reusable components in Seam?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3947334#3947334
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting
"[EMAIL PROTECTED]" wrote : Not really correct.
|
| For example, if I call a Seam component via RMI, Seam can set up an event
context and application contect for me. It just cant do a session or
conversation context because RMI can't propagate conversation or session ids.
I am specifically t
I am glad I finally managed to formulate my idea.
"CptnKirk" wrote : On the other hand, somtimes you want global events,
sometimes you want local events.
Why not just say: "the scope for the events you want varies", from
application-wide (the only choice ATM) to a conversation-wide.
"CptnKirk
"CptnKirk" wrote : "abirkmanis" wrote : Also note that in case of eager
injections (the current mechanizm) new ComponentA().doStuff() throws an NPE,
which is hardly better.
| Had getB() actually been abstract rather than "conceptually" abstract, the
compiler wou
Imagine an application with workspace management, which uses 3rd-party
ProductFinder and ProductEditor components (for finding products by some
criteria, and modifying a selected product), the finder outjecting a product,
and the editor injecting the product. The application has multiple
conver
"[EMAIL PROTECTED]" wrote : By the way, it is utterly irrelevant whether it is
"conceptually" or actually abstract. In either case my arguments apply.
Testing is marginally more complex, that's true. But I believe this is
outweighted by the improved runtime guarantees.
And the difference between
"[EMAIL PROTECTED]" wrote : It is difficult to test because
|
| new ComponentA().doStuff() throws an UOE. I have to subclass the class
before I can call its methods.
OTOH, componentAFactory.newInstance().doStuff() works fine.
Also note that in case of eager injections (the current mechanizm)
I stand corrected - Seam does not require JSF.
But all the operation modes I've seen - JSF, servlet, remoting - assume that
the client is HTTP-based.
Is this statement more correct? Will the next version (probably in addition to
SOA layer, and the already existing client technology adapters) expo
An application-wide instance of Init contains a map from event names to
ObserverMethod. While each ObserverMethod certainly has a reference to
component to be notified, this is not the feature I miss.
My problem is that this mapping from event names to observers is
application-wide (read: monol
I might have not stressed that enough in the previous posts, but I meant the
methods to be conceptually abstract, not formally, e.g.:
@Name("a")
public class ComponentA
{
@In("b")
protected IComponentB getB()
{
throw new UnsupportedOperationException();
}
public void doStuff()
{
events.xml feels like going against the grain of Seam, namely having
"drag-and-drop configuration", or "zero configuration".
Am I wrong with this feeling?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3946855#3946855
Reply to the post :
http://www.jboss.com/
But if I understand that correctly, this would introduce an additional layer of
marshalling - first my web service clients go to a SOAP/SeamRemoting bridge,
then it talks to Seam components. What I really need is an ability to execute
Seam-controlled components from a local Java code, POJO-clien
What exactly is a problem? A method that throws an exception? But interceptors
are not obliged to call it, right?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3946845#3946845
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=repl
My impression is that current Lifecycle, Manager, and Component are too
intimately coupled to JSF to easily use Seam in a "headless" (without JSF)
mode. Should we mimic test cases and use mock objects to run Seam under web
services?
View the original post :
http://www.jboss.com/index.html?modu
One idea would be to emulate scopable listeners in application code - by
outjecting/injecting listeners, but this only works for one listener per event
type (i.e., bijection name).
May this be a sign of a feature missing - I mean, some kind of aggregated
outjection, where multiple components con
I might be missing something (again), but would not be it nice to have events
scopable as well?
I mean, currently there is a global (ok, application-wide) map of listeners by
event type, which is not very handy in a big application composed from
components.
Is it feasible to lookup listeners in
Contexts.lookup() is not type safe.
Abstract getters need not be abstract from Java point of view, just
conceptually.
For example, their body can do nothing but throw UnsupportedOperationException.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3946761#394676
First of all, thanks for your suggestions.
As far as I understood, @Unwrap allows substituting some object (not
necessarily an instance of Seam component) when a component was expected, but
it does not change the timing of the instantiation.
I also realize that instantiation of components can be
Another question (or mayb suggestion on advancement of data-flow
synchronization):
currently it looks that Seam performs all injections for a component before
entering any method of the component (provided interception criteria are met),
even if the component is not going to use these values dur
I am trying to understand why @Factory is much less well represented in Seam
examples than @Out (7 vs. 21 in CR2).
On the first glance, factories seem to play the same role as outjections, just
lazy (or call it demand-drivden, pull-like, data flow, etc.). This mode of
operation looks safer than
We are evaluating Seam for use in several projects, and have come up with
several questions.
One of them is the intended affinity of Seam and web services.
Currently, Seam runs in JSF-driven configuration ou of the box; how easy would
it be to configure it to expose web services instead of JSF U
Hello everyone!
Let's examine startApplication(...) in
org.jboss.deployment.J2eeDeployer (Revision 1.20 or
1.21, JBoss 2.2.1 or CVS).
It starts web modules (lines ca. 403), then it starts
EJB modules (lines ca. 423).
I didn't find any documentation that explains
this choice of behaviour. Would
This issue had been risen before, but was never fixed.
The problem is, *HandleImpl classes, such as
StatefulHandleImpl, in their getEJBObject() contain
such a code:
...
ContainerRemote container = (ContainerRemote) new
InitialContext().lookup("invokers/"+name);
...
But wait!
Enterprise JavaBeans
27 matches
Mail list logo
