[JBoss Web Development] New message: "Simple Application in Jboss with JSF"
by Fahim Awan
JBoss development,
A new message was posted in the thread "Simple Application in Jboss with JSF":
http://community.jboss.org/message/524103#524103
Author : Fahim Awan
Profile : http://community.jboss.org/people/fahimawan83
Message:
--------------------------------------------------------------
Hi every1.
I am new to Jboss, before that i was using Apache Tomcat. My problem is that i have written a simple Dynamic Web Project in eclipse 3.4 in which there are only two JSP pages. on first page some message is written in <h:inputtext/> and on other page the value is displayed. this works fine on apache tomcat. but when i run it on Jboss 4.2.2.GA, then HTTP 404, page not found.
Besides that it does not show any exceptions on console... plz help? what to do.
i have also included following in my web.xml
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
</context-param>
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524103#524103
14 years, 3 months
[EJB 3.0 Development] New message: "Re: Externalizing Scope: Resolving EJB References and Endpoints"
by Andrew Rubinger
JBoss development,
A new message was posted in the thread "Externalizing Scope: Resolving EJB References and Endpoints":
http://community.jboss.org/message/524041#524041
Author : Andrew Rubinger
Profile : http://community.jboss.org/people/ALRubinger
Message:
--------------------------------------------------------------
Some notes from our discussion today:
This cannot work:
//API:
/**
* All EJB3.x SFSBs will have this bound into JNDI
* at default: [appName]/moduleName/beanName/home
*/
interface StatefulSessionHome
{
void remove(StatefulSessionHandle)
boolean exists(StatefulSessionHandle);
<T> T create(T type) throws IllegalArgumentException;
}
//API:
/**
* All SFSB proxies may be cast to this type
* by the client
*/
interface StatefulSessionHandle
{
// Marker only from the client view
}
//SPI:
/**
* This is how the container knows the ID of the session to remove;
* all SFSB proxies will implement this method
*/
interface StatefulSessionHandleProvider extends StatefulSessionHandle
{
Object getId();
}
// Usage:
StatefulSessionHome home = (StatefulSessionHome)context.lookup("beanName/home");
MyBusiness bean = home.create(MyBusiness.class);
home.remove((StatefulSessionHandle)bean);
// Traditional JNDI lookup removal:
MyBusiness bean = context.lookup("beanName/remote");
home.remove((StatefulSessionHandle)bean);
Again, this is because we can't define *any* methods upon a proxy which is for business interfaces; we could introduce conflicts in method names. In the case above, no user code could have "getId();" for example.
An alternative way is to do something like have a Home per EJB Container. Then the home knows how to go into the internals of the proxy handler to extract the ID. Jaikiran wrote up a nice example:
/***************** client (weld-int) *********************/
// user looks up or injects a SFSB (as usual)
UserSFSBInterface proxy = ...//get it as usual
// now get a StatefulSessionHandleProvider (this needs discussion, but let's say it's available in JNDI for each SFSB)
StatefulSessionHandleProvider handleProvider = ctx.lookup("beanName/handleprovider");
StatefulSessionHandle handle = handleProvider.getHandle(proxy);
// do some stuff
handle.destroy();
/***************** SPI*********************/
StatefulSessionHandleProvider
{
StatefulSessionHandle getHandle(Object proxy);
}
StatefulSessionHandle
{
destroy();
}
/***************** SPI implementation (for nointerface view) *********************/
// Individual handle provider impl
JavassistProxyBasedHandleProvider implements StatefulSessionHandleProvider
{
StatefulSessionHandle getHandle(Object proxy)
{
// do some checks on proxy
// and return a handle
new JavassistBasedSFSBHandle(proxy)
}
}
// JavassistBased handle for nointerface view
JavassistBasedSFSBHandle implements StatefulSessionHandle
{
Serializable sessionId;
JavassistBasedSFSBHandle(Object proxy)
{
// this knows the magic to get the session id from proxy
this.sessionId = doSomeMagicOnProxy();
}
destroy()
{
// destroy the session using hte session id
container.destroy(this.sessionId);
}
}
Too bad here we'd need a Home handle (HandleProvider in the example above) per container type.
S,
ALR
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524041#524041
14 years, 3 months
[JBoss Microcontainer Development] New message: "Re: Web beans on top of Microcontainer deployment order"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Web beans on top of Microcontainer deployment order":
http://community.jboss.org/message/523948#523948
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
As I have mentioned on team calls I think there will be some problems with weld-int once we support JSR-330 annotations natively in MC. Here is a chat between me and Ales describing the problem and a half-baked idea for a way around it once I get the chance to look at it again:
[03/02/2010 16:12:03] Kabir Khan: I've had an idea about the Weld/MC/JSR330 stuff
[03/02/2010 16:12:14] Kabir Khan: Not sure if it is viable or not
[03/02/2010 16:12:38] Kabir Khan: but I think the problem is that at the moment ALL JSR 330 injection is deferred to weld
[03/02/2010 16:13:02] Kabir Khan: once we support JSR 330 in MC, the problem I foresee is distiguishing between the two
[03/02/2010 16:13:07] Ales Justin: jsr33 has no injection
[03/02/2010 16:13:12] Ales Justin: it's just a bunch of annotations
[03/02/2010 16:13:29] Kabir Khan: It defines @Inject (or whatever it is called)
[03/02/2010 16:13:37] Ales Justin: yes
[03/02/2010 16:13:45] Kabir Khan: and basically weld-int handles that
[03/02/2010 16:13:53] Kabir Khan: if we want to natively support this in MC
[03/02/2010 16:13:58] Kabir Khan: then we have a problem
[03/02/2010 16:14:07] Ales Justin: even with qualifiers?
[03/02/2010 16:14:18] Kabir Khan: yes, weld takes the whole AnnotatedType
[03/02/2010 16:14:31] Kabir Khan: which is basically all the methods etc.
[03/02/2010 16:14:40] Kabir Khan: and looks for the ones with @Inject in weld
[03/02/2010 16:15:01] Kabir Khan: so there is no clear way to distinguish between the ones from weld and the ones from MC
[03/02/2010 16:15:25] Kabir Khan: However AnnotatedType allows the use of decorators, which I already use to add qualifiers from MDR
[03/02/2010 16:15:31] Kabir Khan: e.g.
[03/02/2010 16:15:34] Kabir Khan: if I have
[03/02/2010 16:15:39] Kabir Khan: class Blah{
[03/02/2010 16:16:03] Kabir Khan: @Inject Other other;
@Inject THing thing;
}
[03/02/2010 16:16:22] Kabir Khan: and Other is not a weld bean weld will throw up
[03/02/2010 16:16:30] Kabir Khan: What I am thinking of is
[03/02/2010 16:16:44] Kabir Khan: it might be possible to fo
[03/02/2010 16:16:45] Kabir Khan: do
[03/02/2010 16:17:19] Kabir Khan: @Inject Other other;
@Inject @Weld Thing thing;
[03/02/2010 16:17:34] Kabir Khan: in an MC bean to specify that thing should come from weld
[03/02/2010 16:17:48] Kabir Khan: and other comes from MC annotations directly
[03/02/2010 16:18:02] Kabir Khan: When passing the annotated type in to weld for injection
[03/02/2010 16:18:20] Kabir Khan: the decorated annotated type could leave out things that don't have @Weld
[03/02/2010 16:18:38] Kabir Khan: Just a vague thought I had right now
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523948#523948
14 years, 3 months
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/523860#523860
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
I've done some work on scoped aliases, and made the dependency resolver matchers not throw errors if things cannot be found when cleaning up the registered dependencies on uninstall (since multiple controllers may be involved). In dependency I still see some failures which I need to dig into, but all the tests in kernel pass with the new resolver. I need to add some tests making sure that everything is cleaned up in the new dependency resolver to make sure we don't leak memory.
As mentioned before I will look into this
"One thing I think we're lacking is "wrong order" tests for contextual injection, at least with qualifiers, so I need to add some. The same might be the case for supply/demand, which I need to check."
I need to revisit how I am handling concurrency when accessing the indexed dependencies in the matchers.
Next I'll look at how to get all the the tests run in all controller modes, I'll probably do this by adding some maven profiles as suggested by Paul
> I'm assuming you are using the surefire plugin, right? You can set up multiple executions of any plugin, including surefire, and these executions can be in the same profile or separate profiles. Just make sure you have a different ID for the two profiles.
>
> It looks something like this:
>
> <plugin>
> <groupId>
> <artifctId>
> <executions>
> <execution>
> <id>test-config-1</id>
> <configuration>
> ...
> </configuration>
> </execution>
> <execution>
> <id>test-setup-2</id>
> <configuration>
> ...
> </configuration>
> </execution>
> </executions>
> </plugin>
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523860#523860
14 years, 3 months