[Beginner's Corner] New message: "Can beans deployed in the server call non-container code"
by Timothy Mowlem
User development,
A new message was posted in the thread "Can beans deployed in the server call non-container code":
http://community.jboss.org/message/521086#521086
Author : Timothy Mowlem
Profile : http://community.jboss.org/people/jvm
Message:
--------------------------------------------------------------
Hello,
I have an API that is NOT in the AS that performs DB access. It is used widely by apps which are 2-tier client server.
I also have an existing app running in the AS (JBoss 4.0.x) that has an entity bean and session beans that talk to the DB. I have the task of getting the AS hosted app to use the newer API that runs outside the AS. The session bean API and external API look well matched so if I can make calls from the session bean to the API then that should be fairly easy.
My question is therefore:
(1) Is it possible to call non container-managed code from inside a J2EE container?
(2) If so are there likely to be security, lifecycle, context or deployment or other issues that I need to be aware of?
(3) Any comments or suggestions on the best approach here would be appreciated.
We don't want to change the external API to run as a bean because that would entail too much work.
Thanks
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521086#521086
16 years, 3 months
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Kabir Khan
User development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/521080#521080
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
After a false start with https://svn.jboss.org/repos/jbossas/projects/kernel/branches/resolver/dep... I now have something working with https://svn.jboss.org/repos/jbossas/projects/kernel/branches/resolver/dep... .
Most tests in the dependency project pass with this, apart from
* BadDependencyTestCase - probably since the calls it checks for now happen differently
* OnDemandDependencyTestCase.testChangeDependencyReinstall() - since the ordering is now slightly different
What I have so far is quite simple. I am still playing around at the moment, and it needs a lot of tidying up, but here is the basic idea:
When calling Controller.install(ControllerContext) the context's dependencies are indexed in the resolver. I put it in a map where the
key is the dependency name, the value is a map where the
key is the dependent state, and the value is list of controller contexts.
Controller.uninstall() removes the context's dependencies from the mentioned map.
AbstractController.resolveContexts(boolean) has been modified to AbstractController.resolveContexts(ControllerContext, boolean) where the context being installed via Controller.install() or Controller.change() is the parameter. This delegates on to the IDR2.resolvePlugins will try to install the context in question as far as it can until it no longer can resolve the dependencies for entering a particular state. Once it cannot go to another state, it simply returns.
I have added a DependencyResolver.stateIncremented(ControllerContext, boolean) callback that is called by the controller once a context has successfully entered the new state. So for example when a context enters the INSTALLED state, this callback is called, and the dependency map is checked for any entries for the context's name and aliases. Then the dependency map is checked for the contexts waiting for that dependency to enter that state. If there were some contexts waiting, we call resolveContexts() on those dependencies.
In addition there is a bit of extra housekeeping for OnDemand contexts.
So far I have not yet looked at scoping, and need to come up with a way to handle implicit dependencies such as supply/demand, contextual injection with qualifiers and so on. Running the kernel project I get 47 failures and 47 errors out of 1575 tests with the new DependencyResolver, which should be fixed once I implement what I have just mentioned.
I'll make which resolver is used configurable via a system property. Once this is more stable we want to run all the tests for any DependencyResolver. For the dependency project I can just create additional sub classes for the different resolvers, but for kernel that will be a big job since there are so many classes, so I'll look at doing profiles instead.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521080#521080
16 years, 3 months
[jBPM] New message: "Re: jBPM on Netbeans and Glassfish/Sailfin"
by Ronald van Kuijk
User development,
A new message was posted in the thread "jBPM on Netbeans and Glassfish/Sailfin":
http://community.jboss.org/message/521065#521065
Author : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
> Do we have same support for netbeans as an IDE for jBPM as we have for Eclipse?
If you mean the graphical design part, no.
> What should be done to get jBPM working on Netbeans IDE
jBPM as a library can be used for developing developing projects within Netbeans without any problems.
> and using Glassfish/Sailfin as app server.
Just try to develop a small demo (e.g. use the test/examples) and see if you get any errors. Most likely there are some depending jar issues, but hopefully nothing major. For the jbpm console I have no clue, but most likely the same issues. Deploy it and see what errors you get.
> Will this integration will be as seamless and stable as jBPM+Eclipse+jBOSS?
Seamles: no, since you most likely have some jar depency issues, but nothing you cannot get around I think (nothing more/less then you could have with other frameworks)
Stable: Well, unless there are issues in e.g. Glassfish transaction management or datasource code, I think it will be as stable.
Eclipse: Has nothing to do with running jBPM.
So personally, I'd say go for it
Ronald
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521065#521065
16 years, 3 months