While MDBs themselves are agnostic to the vendor container, the activation
config properties and their values are not.
Recommend extracting this metadata into a partial XML descriptor, and making
one descriptor per target container. The build may then leave you with
separate artifacts
jcstaff2 wrote : I understand where your caution comes from about the
ClassLoader after reading the spec, but when I read the Javadoc on
getClass().getResource(), it sounds like it too is locating the ClassLoader.
The difference is in your definition of the.
jcstaff2 wrote : When I did some searching, I found that Tom Marrs (Lead
Author, JBoss at Work: A Practical Guide) had the same solution as I did as
late as 2006. http://www.coderanch.com/t/89900/JBoss/reading-properties-file
Respectfully disagree.
Tom Marrs wrote : The EJB specification
Hey Jim:
jcstaff2 wrote : If obtaining the current classloader is
illegal/non-portable, how does one read in a data file from the EJB's
classpath? Is there a legal classloader we can access that will have the file
Resource that can be read in as a stream?
In general, use of File (and other
alesj wrote : Or what does the spec say about what should the TCCL be in this
case?
EJB 3.0 Specification 21.1.2: Programming Restrictions wrote : The enterprise
bean must not attempt to create a class loader; obtain the current class
loader; set the context class loader; set security manager;
Sounds like you'd just want to deploy some MC beans and get the use of @EJB
within them, yes? :)
Check the EJB3 integration testsuite for an example:
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/testsuite/src/test/java/org/jboss/ejb3/test/ejbthree1624/
S,
ALR
View the original
Ran through this a bit today. Came across in the JCA Standalone:
Caused by: java.net.MalformedURLException: unknown protocol: vfsfile
...as Jesper's been encountering.
It's this logic which fully inits VFS:
This results from parsing a bootstrap.xml with hooks to VFS before VFS itself
has been init'd. I've addressed this in jboss-bootstrap-impl-as by a manual
hack:
https://jira.jboss.org/jira/browse/JBBOOT-67
http://fisheye.jboss.org/changelog/JBossAS/?cs=88598
So for users of MCServer who need
jesper.pedersen wrote : anonymous wrote :
| | Looks like the NCDFE is blocking you from doing that. Which is another
issue alltogether. Due to parentchild delegation and leaking of class
references, we've got to be very careful what's on the application CP, URLCL,
etc.
| |
| I only
jesper.pedersen wrote : Another question is if bootstrap/MC should make
assumptions about CLs. I think having to define a DEFAULT_BOOT_LIBRARY_LIST is
something we should think about.
We don't. :) We boot library list is of the AS Main, not bootstrap. It can
be removed from its explicit
jesper.pedersen wrote : My point is here - why do we have to define a
DEFAULT_BOOT_LIBRARY_LIBS in our Main ? Splitting our classloader structure
into multiple layers shouldn't be needed.
|
| Passing the classloader defined in Main to the bootstrap implementation
should be enough.
You've
You should absolutely cache SLSB proxies. Do the lookup once, then you may
pass around and share this instance.
This is because the proxy you lookup may target *any* of the underlying bean
instances in the pool. Assuming you've done a good job to ensure your SLSB has
no *conversational
What's up with the deployment ie. ejb-jar.xml or @Resource annotations? If we
can get a failing case we should either:
1) Throw descriptive deployment exception if caused by invalid metadata
2) Fix this NPE
...but either way the error as-is offers no feedback and should be chansed
down/fixed.
BTW the line in question is:
if(envRef.getType().equals(URL.class.getName()))
S,
ALR
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4229242#4229242
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4229242
Also have a look at our EJB3 tutorials:
http://www.jboss.org/file-access/default/members/jbossejb3/freezone/docs/tutorial/1.0.6/html/index.html
S,
ALR
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4227987#4227987
Reply to the post :
I still think you have classpath setup incorrectly.
Regarding the client CCE on javax.naming.Reference, I suspect jbossall-client
.jar isn't on your client CP.
As to the server boot error, looks like you've changed something about the
installation. After unzip what did you do?
S,
ALR
View
Exception in thread main java.lang.RuntimeException:
java.lang.ClassNotFoundException:
com.acmeco.serverapp.test.fileStuff.FilePackage (no security manager: RMI class
loader disabled)
Is FilePackage not in your JAR/EAR alongside your EJB?
S,
ALR
View the original post :
Definitely give it a spin on AS 5.0.1.GA or 5.1.0.Beta1; we've got integration
tests for this kind of thing. If it turns out you've still got a problem we'll
look into either 1) Fixing your config or 2) Addressing a gap in our test
coverage / possible bug.
S,
ALR
View the original post :
javax.naming.NamingException: Could not dereference object [Root exception is
java.lang.RuntimeException: Could not find InvokerLocator URL at JNDI address
FTPBean/local; looking up local Proxy from Remote JVM?]
To ask the obvious question, is your client (where the JNDI lookup is
performed)
That's a different error :)
EJB Proxies are castable to their business interface types, not to the bean
implementation class. So instead:
(com.acmeco.serverapp.ftp.ejb3.FTPBeanRemote)ref;
S,
ALR
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4223803#4223803
Also, have a look at http://www.jboss.org/jbossejb3/docs/. :)
S,
ALR
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4223807#4223807
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4223807
Emmanuel, I agree; reporting entities is out of scope for Hibernate.
Probably this reporting is best handled by some integration layer in AS, a
central registry that we can expose via an MC bean maybe?
The problem comes when we start talking about this notion of extra scanning
(==time). As
mvpc wrote : java.lang.ClassCastException: javax.naming.Reference cannot be
cast to br.com.original.negocio.email.interfaces.IEmailLocal
This is a common symptom that you don't have the proxy object factories on your
client CP. Typically this is fixed by ensuring you've got
buki79 wrote : seems this helped. Thanks!
Cool.
Would you please open a JIRA under the EJBTHREE project requesting that I
enhance the error message to account for this case? While true that the CLs
didn't match, they wouldn't in this case, and I want to let the user know
they're trying to
ALRubinger wrote : Would you please open a JIRA under the EJBTHREE project
requesting that I enhance the error message to account for this case?
Thanks. :)
https://jira.jboss.org/jira/browse/EJBTHREE-1789
S,
ALR
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp
manemannen wrote : SimpleStatefulBeanRemote o = (SimpleStatefulBeanRemote)
ctx.lookup(simpleserver/ + SimpleStatefulBean.class.getSimpleName() +
/remote);
| |
|
| I have seen many examples of this and it introduces a dependency from the
client to the actual implementation and
Would you please post your packaging structure? Looks like the issue here is
that the Proxy doesn't have the same defining ClassLoader as the CL that loaded
TwitterSessionBeanRemote in your app.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4220410#4220410
Servlet field should be of type TwitterSessionBeanLocal.
S,
ALR
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4220415#4220415
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4220415
ALRubinger wrote : https://jira.jboss.org/jira/browse/EJBTHREE-1773
Done. Relevant unit test showing usage is:
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/core/src/test/java/org/jboss/ejb3/core/test/ejbthree1773/unit/RemoveRequestFromSessionProxyUnitTestCase.java
ALRubinger
I'll implement remove() for us. It'll be dependent upon the new EJB3 release
(due out this week).
Your implementation of JBossEjbReference will not work w/
SessionContext.getInvokedBusinessInterface() because it's looking up a
non-deterministic proxy. Why did you chooe to go for:
On the EJB3 side:
https://jira.jboss.org/jira/browse/EJBTHREE-1773
S,
ALR
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4218048#4218048
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4218048
I recommended adding onto SessionProxy:
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/proxy-spi/src/main/java/org/jboss/ejb3/proxy/spi/intf/SessionProxy.java
...to add a removeTarget() method. Usage becomes:
Object proxy = jndiContext.lookup(MyBean/remote);
| SessionProxy sProxy
web.xml version? Doesn't sound like injection is even getting setup; not a
problem with target resolution.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4216860#4216860
Reply to the post :
@EJB.mappedName is a vendor-specific (non-portable) attribute which in JBoss
EJB3 is used to denote the JNDI target; you're using it as the target EJB name.
@EJB should be sufficient. Likewise you don't need to specify @Stateful.name
(the default is the bean impl class getSimpleName()).
S,
ALRubinger wrote : We could expose this by adding interface support for a
JBossStatefulSessionObject in the proxy, which has some method getId();
I did this in r85648 for https://jira.jboss.org/jira/browse/EJBTHREE-1758.
StatefulSessionProxy statefulProxy = (StatefulSessionProxy)proxy
Just for SFSB I'd imagine?
Our standard M.O. applies I guess; make some SPI to register a callback
listener in wb-as-int and we'll invoke upon it via some EJB3 optional add-on
component.
What contextual information do you need? Session ID?
S,
ALR
View the original post :
pete.m...@jboss.org wrote : What is the best way (that ideally is standard,
otherwise we'll need another SPI for identifying an SFSB) to identify an SFSB
instance?
You mean the ID of a given proxy? ATM we'd be diving into implementation
details by getting the it out of a field in the
But we don't need a full profile3_1 just to get a couple MC Beans installed
into Embeddable.
This can even be done by way of jboss-ejb3. So long as there's some component
that brings in the configs needed...
S,
ALR
View the original post :
pete.m...@jboss.org wrote : ALRubinger wrote : We're currently defining
EjbReferenceResolver in ejb3-deployers-jboss-beans, which resides in ejb3-core.
|
| This one is more urgent, as we have many tests relating to EJB
functionality.
https://jira.jboss.org/jira/browse/EJBTHREE-1736
S
We're currently defining these in ejb3-deployers-jboss-beans, which resides in
ejb3-core.
Lately we've been discussing moving to finer-grained MC Deployable XMLs, to
live in the same component that defines them.
So I could envision a ejb-resolver-jboss-beans.xml, pu-resolver-jboss-beans.xml
-
Ah, you're tackling this from the other end.
ejb3-mc integration as described in the blog post is how I enabled @EJB
injection into MC Beans.
Here you're trying for custom annotation support on EJBs. As EJB bean impl
classes are not installed as MC beans, the annotation plugin is not getting
Jason:
You're right, this has been unscheduled for some time. Our development
priorities have simply not lined up here.
We are, however, aware of the community interest. Basically this feature boils
down to a dev-mode where we line up a new ClassLoader, ditch it when some
scanner detects a
If you're volunteering to get into some dev, we'll get you pointed to some
basic stuff to start out, then point you in the right direction. ;)
S,
ALR
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4210472#4210472
Reply to the post :
Ah, so we're not the only ones currently overloaded. ;)
Unfortunately, I cannot give you an estimate now. We do feature-specific
planning for each EJB3 release (every 2 weeks), and we have a longer-term
roadmap as well. At the moment EJBTHREE-1096 is not on the roadmap (which
mostly involves
Do you have SpringInjectionInterceptor defined under the domain Intercepted
Bean in ejb3-interceptors-aop.xml?
If so, what's your pointcut? Ales, what should the pointcut be do to the
lifecycle injection?
S,
ALR
View the original post :
green804 wrote : I had it under Stateless Bean because that's where it was
in 4.2. Should I move it to Intercepted Bean? Does it matter where?
Aha.
You've got a SFSB, which is tied to domain Stateful Bean. Intercepted Bean
is a top-level parent (@see domain extends=X).
This is the pointcut
ALRubinger wrote : You've got a SFSB
My eyes are lying to me. Sorry, you've clearly got @Stateless on there.
S,
ALR
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4210065#4210065
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode
green804 wrote : I changed my app to use the @Interceptors, and everything is
now working correctly.
You're cheating by workaround. :D
SFSB instances are created by class.newInstance, I'm doing some tests to see if
AOP pointcuts to *-new(..) work this way.
S,
ALR
View the original post :
My tests to intercept newInstance calls via new() show that the pointcut won't
work this way.
Perhaps what's needed is:
http://www.jboss.org/jbossaop/docs/2.0.0.GA/docs/aspect-framework/misc/reflection.html
The way @EJB, @Resource, etc works is that EJB3 looks for these and applies the
logic
Hi Paata:
The EJB3 Plugin installer currently updates AS to the latest EJB3 release,
1.0.0. We don't yet have EJB 3.1 features available, but these are either
scheduled or under development, and we'll be pushing them to the community as
they reach stable/preview state. Check back to the
https://jira.jboss.org/jira/browse/EJBTHREE-1709
S,
ALR
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4206329#4206329
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4206329
___
skajotde wrote : ALRubinger wrote :
| | Would an additional assembly of all the EJB3 component resources in one
place solve this? ie. ejb3-sources-1.0.0.jar, which contains all the sources
from the various component versions that are in the EJB3 1.0.0 distribution?
| |
|
| Yes
skajotde wrote :
| It would be nice release notes
(http://sourceforge.net/project/shownotes.php?release_id=655817group_id=22866)
describe this relation. It is great that EJB3 can be standalone product but
from JEE view is couply integrated with application server so I think version
matrix
wolfc wrote : The feature packs will have a separate release cycle.
As do each of the components that together compose EJB3.
skajotde wrote : At least there is plus that all ejb3 artifacts have common
version number
...but because of the separate release cycles, the components will not have
skajotde wrote : I think it is great that library can be used outside EJB3
and provides model and metatada. But main purposes of this libraries are be
part of EJB3 product so I think it should be versioned in one way with one
version number for releases of all libraries. So change in library-a
skajotde wrote : Yes, there are true arguments but I very prefer treat these
libraries as part of EJB3 Project. So when EJB3 Project change releases new
version there is one number of version.
You can't override logical arguments with preference. :)
skajotde wrote : I'm afraid of versioning
skajotde wrote : Version madnes is my argument and I describe my way to
improve/balance this situation ;) (from experience with work on granular
libraries).
That's fair, but your proposal involves coupling the release schedule of all
EJB3 components. This comes at the cost of the 2 drawbacks
Glad to clear this up.
JBossAS 5.0.0.GA shipped with a composite of the EJB3 components, which
together had a release version of 1.0.0-Beta7. While this was sufficient for
the release criteria of AS, the EJB3 Team had a different set of release
criteria before we were comfortable branding as
Sure, but at the moment, each EJB3 component has its own source artifact:
http://repository.jboss.org/maven2/org/jboss/ejb3/
At time of this writing, each component is at 1.0.0. This is subject to
change. :)
Short answer: all sources are available, but there's no composite JAR with all
of
We're working on the EJB 3.1 features now, but have not yet released a roadmap.
JBoss does provide client-driven asynchronous invocations, take a look at our
Unit Tests (works w/ EJB3 in AS 5.0.0.GA):
Yep.
* @Remote references a business interface (EJB 3.x View)
* is a Remote Component interface (extends EJBObject, an EJB 2.x View)
* business-remote is the XML equivalent to @Remote
* There is no annotation for , we read it in via the return types of @Home
create methods.
S,
ALR
View the
Looks like the forum software chopped off the JIRA issue from your topic.
What was the error? There's nothing wrong with that construct assuming:
* There's no @Local or @Remote annotation on EchoService
* EchoServiceRemote does not also extend from EJBObject
* EchoServiceLocal does not also
kolszew73 wrote : 1. This in not EJB3 compilant, i must use annotation
org.jboss.ejb3.annotation.LocalBinding which is'n standard EJB annotation
Strong words from someone trying to bypass spec scoping by injecting across
unrelated JARs/EARs. ;)
True story though. Looking forward we'll be
kolszew73 wrote : Ok i know, but ... it works fine in JBOSS 4.2.2 !
|
I'm sympathetic to this in practice. So:
[url]https://jira.jboss.org/jira/browse/EJBTHREE-1689[/ur]
S,
ALR
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4202529#4202529
Reply to the
davestar wrote : Thanks Everyone, the JIRA ticket can be closed.
It can't be closed if all we've done is identified a workaround. ;)
First we need a test for @PersistenceContent w/ no unitName placed at the root
of an EAR, checking that the default PU can be resolved.
S,
ALR
View the
JBossAS Version?
davestar wrote : My persistence.xml is in the MET-INF folder in the ear file.
I assume you mean META-INF?
For reference:
EJB 3.0 Persistence Specification 6.2.2 wrote : When referencing a
persistence unit using the unitName annotation element or persis-
| tence-unit-name
pete.m...@jboss.org wrote : 1) Do(es) the org.jboss.ejb3.EjbReferenceResolver
... exist in embedded EJB3.1?
Nope. After I get this release out we can talk about moving support into
Embeddable EJB.
S,
ALR
View the original post :
Might wanna change your packaging as to not bring in your SVN meta into the
EAR. ;)
Sure, let's open a JIRA and attach your EAR. I'll have a look to see if it's
something I'm missing from this post, or a real issue.
EJBTHREE project, component jpa-deployers.
S,
ALR
View the original post :
The reason for this is because starting in the 5.0.0.Beta releases we moved
jbossall-client to a manifest-only JAR. This means that instead of repackaging
all of the classes in the JARs you mention into one uber-JAR, jbossall-client
contains a ClassPath entry in the manifest to point to the
This was an issue also discussed today on Freenode IRC's #jboss. :)
The EJB 3.1 Specification addresses application lifecycle via the @Singleton
bean. Until that support arrives, JBoss has a vendor-specific extension called
the @Service bean, which is a singleton that optionally supports MBean
trustin wrote : Thanks ALR for sharing your code: http://tinyurl.com/7wjv78
|
| I put it out there just hoping you'd find it. :)
|
| Are the callbacks called only when an installed AnnotationPlugin is
described in the same deployment, or are they called regardless of whether the
ALRubinger wrote : The callbacks are added for any deployment under the same
Controller
So beware, you're actually altering MC's behaviour. I believe Ales made some
mention of considering whether these callbacks should be made by default (so
this bit wouldn't be needed)?
S,
ALR
View
Just a note that I've duplicated the issue and am working on a fix for the next
release. Thanks huberth for your detailed explanations.
S,
ALR
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4200028#4200028
Reply to the post :
Might also be a good idea to do some profiling to determine some of the major
bottlenecks first. If you have the means, JProfiler[1] is a great commercial
product.
S,
ALR
[1] http://www.ej-technologies.com/products/jprofiler/overview.html
View the original post :
slimamar wrote : https://jira.jboss.org/jira/browse/EJBTHREE-1650
Thank you for opening this. I've deprioritized it from critical, changed from
bug to feature request, and renamed Need EL-replacement within
@RemoteBinding.clientBindUrl so connect addresses are not hardcoded.
slimamar wrote :
So you're still exhibiting unexpected behaviour?
Does @EJB.name work as expected (ie resolves properly to the ENC name)? I'd be
surprised if it didn't as we're shipping a compliant implementation.
S,
ALR
View the original post :
green_bean_1 wrote : EJB.name does NOT work. it does NOT correctly inject
the specific implementation.. How would I verify the ENC name for each specific
implementation?
You haven't supplied the right ENC name yet, so how can you assert it doesn't
work? :P.
Get the ENC Name using JNDIView in
I have a sneaking suspicion that jndi-name support is lacking.
Jaikiran, mind opening a JIRA w/ some simple integration test for it? I should
look when I'm back next week.
S,
ALR
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4197835#4197835
Reply to the
I think you want 5th Edition. ;)
http://oreilly.com/catalog/9780596009786/?CMP=AFC-ak_bookATT=Enterprise+JavaBeans+3.0
...which covers EJB 3.0.
S,
ALR
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4197819#4197819
Reply to the post :
morphy wrote : no way to inject a remote ejb???
True, the spec does not provide mechanism for injection of remote resources.
In fact, until EJB 3.1 there isn't even a mandate that EJBs are bound into
Global JNDI.
S,
ALR
View the original post :
Please create a JIRA for this as a feature request under EJBTHREE.
S,
ALR
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4197722#4197722
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4197722
@EJB.name is for the JNDI name of the reference within the ENC. Check your
JNDI View, looking under the component (your EJB's deployment) namespace for
the correct value.
If you're like to use the global JNDI name (as you are), use @EJB.mappedName.
Or, designate the target EJB by its name:
green_bean_1 wrote : So, it seems to me like if two impls share the same
interface, JBoss doesn't differentiate them?
If you can provide a use case (unit test) exhibiting this, we can open a JIRA
for resolution. :)
S,
ALR
View the original post :
Judging from those JNDI Names, gotta be at least AS 5 CR2. :)
S,
ALR
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4197506#4197506
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4197506
Nice.
public class AbstractEjbReferenceValueMetadata extends
AbstractDependencyValueMetaData
...and...
/**
| * Used in defining the dependency
| */
|@Override
|public Object getUnderlyingValue()
|{
| return DEPENDS_JNDI_PREFIX +
alesj wrote : Why would we have something like this in MC?
Isn't it MC which knows how to treat that the jndi: prefix defines a
dependency upon a JNDI entry?
Otherwise it's just some magic string?
S,
ALR
View the original post :
I've got a ValueMetaData upon which I need to define a dependency before
getValue() may be called.
Possible? This is so that the target value is available before I inject via an
annotation plugin.
S,
ALR
View the original post :
Try instead mapped-name.
If that works, please open a JBMETA JIRA issue?
S,
ALR
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196425#4196425
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4196425
Your example works well in my initial integration tests. :)
alesj wrote : I expect the blog when I wake up on Monday. ;-)
I'll take some more time to beef up the test coverage, make proper unit tests
(mocking the MC SPIs). But it works as advertised.
S,
ALR
View the original post :
Is there an equivalent of a DeploymentUnitRegistry?
For instance:
CollectionDeploymentUnit deploymentUnits =
DeploymentUnitRegistry.getAllDeploymentUnits();
S,
ALR
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196383#4196383
Reply to the post :
I've got an annotation plugin:
public class EjbReferenceAnnotationPlugin extends FieldAnnotationPluginEJB
| {...}
..which does not run through protected ValueMetaData
createValueMetaData(FieldInfo fieldInfo, EJB annotation) upon encountering
@EJB on a field-level property.
If I change this
EJB 3.0 Persistence Specification, Section 6.2 wrote : A persistence unit is
defined by a persistence.xml file. The jar file or directory whose META-INF
| directory contains the persistence.xml file is termed the root of the
persistence unit. In Java EE, the root of a persistence unit may be
Yes, was hoping for this auto-registration much like is done when installing a
KernelRegistryPlugin (ie. picks up the interface and takes appropriate action).
So the following works:
// Install the BeanAnnotationAdapter w/ callback to add annotation
plugins on install
|
alesj wrote : Either set bean's BeanAccessMode to FIELDS or ALL.
Great, thanks. ;)
A follow-up question:
public class Pojo
| {
|@EJB
|private Object injectedEjb;
|
|public Object getInjectedMember()
|{
| return injectedEjb;
|}
|
| }
I must use
I'm currently adding my annotation plugin like:
// Add our annotation plugin
| BeanAnnotationAdapter beanAnnotationAdapter =
BeanAnnotationAdapterFactory.getInstance()
| .getBeanAnnotationAdapter();
| AbstractBeanAnnotationAdapter abstractAdapter =
The Integration Test is passing:
http://jboss.hudson.alrubinger.com/job/EJB3_Integration_TestSuite_AS5_GA/lastBuild/testReport/org.jboss.ejb3.test.circulardependency.unit/
Please post relevant layout and errors in a new topic (so we don't hijack this
one). ;)
S,
ALR
View the original post :
If you get the TransactionManager from JNDI, then get the Thread's current Tx
from there, that's not sufficient for you? It's some wrapper object and you
need an underlying impl (much like EntityManager.getDelegate() provides)?
S,
ALR
View the original post :
cburnley wrote : which would imply that it is not really a 2.1 view of the
service because it uses ejb3 proxy classes
No, it's a valid EJB 2.1 View, but the ICE is because the 4.2.3 and 4.0.3 Proxy
classes are not compatible. Solution is to ensure that your client has the
correct classes on
JBossAS / EJB3 Version? Stack trace?
Client interceptors, on invocation, must be available on the client's CP.
S,
ALR
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4191782#4191782
Reply to the post :
There's not much we can do about Community AS 4.2.x.
In current trunk I see your problem:
10:47:58,654 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of
incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
|
| *** CONTEXTS MISSING DEPENDENCIES: Name -
1 - 100 of 479 matches
Mail list logo
