June 2010 - jboss-user - Jboss List Archives

Re: [jboss-user] [EJB 3.0] - javax.ejb.EJBAccessException: Caller unauthorized when calling EJB3 @Service from client code

by jaikiran pai

jaikiran pai [http://community.jboss.org/people/jaikiran] replied to the discussion "javax.ejb.EJBAccessException: Caller unauthorized when calling EJB3 @Service from client code" To view the discussion, visit: http://community.jboss.org/message/546222#546222 -------------------------------------------------------------- > Dave Bredesen wrote: > > Should I just add ClientLoginModule to the foo stack? > > Yes. That ClientLoginModule is responsible for "propagating" the logged in context. There was a wiki around this. Let me see if I can find it. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546222#546222] Start a new discussion in EJB 3.0 at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-user] [EJB 3.0] - javax.ejb.EJBAccessException: Caller unauthorized when calling EJB3 @Service from client code

by Dave Bredesen

Dave Bredesen [http://community.jboss.org/people/dbredesen] replied to the discussion "javax.ejb.EJBAccessException: Caller unauthorized when calling EJB3 @Service from client code" To view the discussion, visit: http://community.jboss.org/message/546221#546221 -------------------------------------------------------------- Jaikiran, Thanks for you response. No, I don't have ClientLoginModule in the "foo" policy, just DatabaseServerLoginModule. However, I do have ClientLoginModule alone in the "client-login" policy, and I have found I can make some progress if I authenticate on the "client-login" domain on the web app and the "foo" domain on the server side. What is the proper way to set this up? The web client and EJB server are running in the same container and same server, so they share a login-config.xml. Should I just add ClientLoginModule to the foo stack? Thanks for your help. Dave -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546221#546221] Start a new discussion in EJB 3.0 at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-user] [JBoss Web Services] - @WebFault and @XmlType

by R K

R K [http://community.jboss.org/people/rkb76in] replied to the discussion "@WebFault and @XmlType" To view the discussion, visit: http://community.jboss.org/message/546218#546218 -------------------------------------------------------------- If you found a solution, kindly share with me as I am facing exactly same problem. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546218#546218] Start a new discussion in JBoss Web Services at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-user] [JBoss Remoting] - Need help in configuring JMS with JBoss Messaging in JBoss 4.2.3

by Mike Miller

Mike Miller [http://community.jboss.org/people/mikemil] replied to the discussion "Need help in configuring JMS with JBoss Messaging in JBoss 4.2.3" To view the discussion, visit: http://community.jboss.org/message/546215#546215 -------------------------------------------------------------- The reason you couldn't see my reply was because I deleted my response after going back and re-reading the whole thread, which I didn't do before posting a quick response. After reading the thread, I think I saw Ron also suggest the same thing and didn't want to be intruding especially if I was providing the same advice you received previously. Any way, glad to year your hare working now! -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546215#546215] Start a new discussion in JBoss Remoting at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

[jBPM] - jBPM community version download

by Leonardo Vergara

Leonardo Vergara [http://community.jboss.org/people/lvergara.2] created the discussion "jBPM community version download" To view the discussion, visit: http://community.jboss.org/message/546203#546203 -------------------------------------------------------------- Hello I would like to learn about jBPM in order to evaluate if I can use the community version for small projects, but I don't know where to download the community version of jBPM. Can anyone help me? Thanks a lot -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546203#546203] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-user] [JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration

by Flavia Rainone

Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] replied to the discussion "Implementing a non-flat deployment for Weld Integration" To view the discussion, visit: http://community.jboss.org/message/546199#546199 -------------------------------------------------------------- > Flavia Rainone wrote: > Finally, the tests are very poor. I just ported the already existing ones to test the new deployers. So writing real tests is what I'll be doing next, and I'm sure I have quite a few bugs to catch ;-) I stumbled upon some issue here. The problem is located in WeldFilesDeployer: Iterable<VirtualFile> classpaths = getClassPaths(unit); for (VirtualFile cp : classpaths) { VirtualFile wbXml = cp.getChild("META-INF/beans.xml"); if (wbXml.exists()) { // add url wbFiles.add(wbXml); // add classes cpFiles.add(cp); } } This deployer deploys the cpFiles of the current unit only if it has the META-INF/beans.xml file. The problem with this is that this results in an ArchiveInfo without any classes in it if we deploy an ejb-jar without META-INF/beans.xml. In the future, if Weld request for a BDA associated with the ejb-jar by calling Deployment.loadBeanDeploymentArchive, it will get a BDA that has no classes in it. So, I tried to "fix" it: Iterable<VirtualFile> classpaths = getClassPaths(unit); for (VirtualFile cp : classpaths) { VirtualFile wbXml = cp.getChild("META-INF/beans.xml"); if (wbXml.exists()) { // add url wbFiles.add(wbXml); } // add classes cpFiles.add(cp); } This resulted in a series of test failures. All related with the criteria that we use to decide whether to put a class in a BDA. Overall, these are the scenarios that are broken: - if one or more lib jars in an ear happen to not have a META-INF/beans.xml file, the lib classes were not part of the BDA that represents the ear (note that currently I'm creating a BDA for every classLoader. So, for an ear, there is a single BDA that contains all the info regarding lib jars and ejb-jars in it). - if one ore more ejb-jars in an ear happen to not have a META-INF/beans.xml file, the classes of those non-CDI ejb-jars were not part of the resulting BDA - if in a war that contains a WEB-INF/beans.xml we have one ore more lib jars that don't have a META-INF/beans.xml, the classes of those libs are not part of the resulting BDA (we currently create a single BDA for every war; this BDA represents both the classes and the libs of the war) - if, in a war that lacks a WEB-INF/beans.xml, we have one ore more lib jars that have the META-INF/beans.xml, the classes of the war (WEB-INF/classes) are not part of the resulting BDA. In all the scenarios I described, the classes that were not part of the resulting BDA became part of the BDA with my "fix". Notice that, interestingly, in the way things are implemented today, if you pass one of the missing classes as a parameter to a Deployment.loadBeanDeploymentArchive, my implementation will return the requested BDA correctly, but still the BDA wil lack the requested class! So, we clearly have made some mistaken assumption here: - either the classes that were not part of the BDAs in the previously described scenarios were supposed to be in the BDA and I fixed the bug. Now, all I have left to do is fixing the tests as well. - or we should not create a BDA for every ClassLoader. We should be creating a BDA for every classpath entry (i.e., there should be a BDA for the WEB-INF/classes war; and another BDA for every lib in the war; simillarly, there should be a BDA for every distinct jar in the ear archive). As a result, we have one ore more BDAs that can see each other simultaneously because they all happen to belong to the same ClassLoader. Also, in a single AS instace, we will have a larger number of BDAs when compared to my current implementation. Which way should I go now? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546199#546199] Start a new discussion in JBoss Microcontainer Development POJO Server at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-user] [JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration

by Pete Muir

Pete Muir [http://community.jboss.org/people/petemuir] replied to the discussion "Implementing a non-flat deployment for Weld Integration" To view the discussion, visit: http://community.jboss.org/message/546189#546189 -------------------------------------------------------------- > Flavia Rainone wrote: > > > Pete Muir wrote: > > > > > I've been thinking about correctness all this time. If somebody places a jar in lib and expects that the beans are created upfront when AS starts, then this would not work using your approach. > > > > > > > > > > > > Ok, I think we've got crossed wires. You can't deploy a library jar in some "context" outside a deployment. The beans don't get created or anything outside the context of a deployment. > > > > > > > > > > > > > > > > Another way to think of it is that a library in default/lib with a beans.xml in it works just like a library in WEB-INF/lib. > > > > > > > > In that case, why the lazy approach wouldn't work? > > > > From what I can see, if it works just like a library in WEB-INF/lib, it means that we will need to provide a BDA for a lib jar only when Weld requests for one through loadBeanDeploymentArchive, right? > > > > Or, if I'm wrong, do you mean that a BDA for every lib jar with a META-INF/beans.xml should be provided as direct or indirect result of BeanDeploymentArchive.getBeanDeploymentArchives() for every BDA in a Deployment? > > Explaining better, given commos/lib/mylib.jar with the following structure: > > mylib.jar > > |_ > > META-INF/beans.xml > > |_ > > whatever classes in here > > > > Say we create a BDA upfront, let's call it MY_LIB_BDA, and add this BDA to DefalutDomain Classpath. No deployment is created upfront. > > > > Now, say my-ejb.jar with a META-INF/beans.xml file is deployed to deploy dir. We create a Deployment for it, of course, and we create a BDA for it as well. This BDA, called MY_EJB_BDA, belongs to Default Domain Classpath. So, when Weld invokes MY_EJB_BDA.getBDAs(), it should , directly on indirectly (i.e., by walking on the BDA graph structure), reach MY_LIB_BDA? > > > > This is different from the lazy approach because, with this second approach, you are not required to call loadBeanDeploymentArchive in order to obtain MY_LIB_BDA. A simple BeanDeploymentArchive.getBeanDeploymentArchives will get you there. > > > > Is that what Weld requires us to do? Yes. If there is an accessible (i.e. classes can be loaded from it) library jar with META-INF/beans.xml, then Weld expects you to return it as part of the BDA graph of the Deployment. The loadBeanDeploymentArchive method solely exists for the case that someone adds a bean based on a class which isn't present in the BDA graph via a CDI lifecycle listener. For every bean defined in such a way, Weld calls loadBeanDeploymentArchive, expecting the correct BDA to be returned. IOW this is a kinda a two stage process - firstly the BDAs which are defined declaratively (META-INF/beans.xml) are handed to Weld, and then BDAs which are defined programatically are loaded by Weld (via loadBeanDeploymentArchive). > Because the Java EE/CDI specs require it. > > BTW, I've read the spec sometime ago. Of course I don't remember all the details so, if you think rereading some specific part of it might be useful, let me know. I simply meant that the reason we have to load library jars as BDAs is because the spec says so ;-) -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546189#546189] Start a new discussion in JBoss Microcontainer Development POJO Server at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-user] [jBPM] - Access to variable via EL ?

by Jaber C. Mourad

Jaber C. Mourad [http://community.jboss.org/people/newbeewan] replied to the discussion "Access to variable via EL ?" To view the discussion, visit: http://community.jboss.org/message/546188#546188 -------------------------------------------------------------- Hi, After several tests, variables doesn't seem to be accessible into the EL context :( In the doc, there are only static value examples or object examples from the execution context, but not from process variables ! Perhaps I missed something or there is something to configure to have variables accessible into EL... Regards -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546188#546188] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-user] [jBPM] - JBPM4.3: login is not possible in the web console if i use the new username and password

by Wladimir Lavrov

Wladimir Lavrov [http://community.jboss.org/people/wawan_beta] replied to the discussion "JBPM4.3: login is not possible in the web console if i use the new username and password" To view the discussion, visit: http://community.jboss.org/message/546173#546173 -------------------------------------------------------------- thanks for the reply, it is working) Regards Wladimir -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546173#546173] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-user] [JBoss Tools] - Problem with JBoss Tools - New Seam Project and Seam Perspective

by Nessus You

Nessus You [http://community.jboss.org/people/kdhr83] replied to the discussion "Problem with JBoss Tools - New Seam Project and Seam Perspective" To view the discussion, visit: http://community.jboss.org/message/546170#546170 -------------------------------------------------------------- I just finally switched to Eclipse< http://www.eclipse.org/downloads/download.php?file=/technology/epp/downlo... Eclipse IDE for Java EE Developers>, hopefully and seemingly it makes things simpler to begin and more straightforward and understandable to go along with. MyEclipse made the tool to implement our project too complicated. As for Seam/Weld, I think it not easy to design in a Seam/Weld way, especially for me having not too much EE experiences in mind. Would you share some thoughts? I have gone throught almost all the documentations on seamframework.org, but they shows only simple samples and how many and what bricks Seam/Weld provides. Also, does Seam provide Weld and Seam 3 plugins for Eclipse? I found not easy to get development tool ready. It's a bit scary to harness the power and simplicity of a new technology. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546170#546170] Start a new discussion in JBoss Tools at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-user June 2010