[Design of EJB 3.0] - [long read] Info/help needed on extending EJB3 container
by Sintel
Hi,
I'm a thesis student and have been given the assignment over the past few months to extend or write a J2EE container to support real time adaptation (changing an implementation of a bean with another one without the clients knowing) on the basis of context information. Before this assignment I had good experience with regular Java but none with J2EE.
After reading up on context management and all kinds of runtime adaptation, I ended up choosing JBoss to do this 'little' college work since it looked to be better documented than glassfish, and because real world developers prefer it.
I've been looking at source code for over a month and trying to write some as well. I first started with the regular EJB container and then switched over to the EJB3 one to try and keep things simple. But frankly, I'm not feeling like I'm making any progress, the amount of code I wrote at the moment is laughable. The thing is that I'm being drowned in all the code and it's very hard to make out what is for what, how it gets used etc. The documentations provided on the site are all very basic and do not tell anything on how the containers are layered, how an invocation travels through the code for every kind of bean (where does it start at the server side, what invocation object, interceptors, the pools, all those context classes, to the beaninstance?) or something like that. Starting a container from scratch to plug into Jboss doesn't seem like a viable idea either.
My work plan would read something like this: At this point I would just like to extend the existing EJB3 container so that it supports multiple bean implementations, but only with the same configuration (so nothing else changes..), and have the possibility to add/remove implementations at run time... Does this sound at all doable in a relatively short time without breaking any interoperability? To do this I thought about putting a class between ejbcontainer and sessioncontainer with necessary overrides and extra methods for the extra functionality to achieve this, but am kinda in the dark on what this exactly entails (what do i need multiple instances of and can I change them safely..).
The next step would then be to route the invocations through a dispatcher which I control from my own developped classes. The dispatchers get held in the extended container and if i ask one to change implementation, it asks a specific implementation to the container and uses that one for every invocation.
To achieve this step I think I need to change the proxies that are sent to the client to contain a reference to the dispatcher instead of whatever it refers to now (seems different for stateful/stateless/...). From what I understood up till now, I will need to have different dispatchers and adapt all the different end-containers for each kind of bean (or just the end containerinterceptor?).
Any thoughts on all this and some light or links on how invocations progress through the app server are greatly appreciated.
As this is work for a thesis, I do not know if any of this is appreciated, since it doesn't involve fixing bugs, completing code, making jboss better for the 'general public'. Any code I write is of course strictly meant for research.
Sorry if this wasn't all that coherent. Hope this is posted in the right subforum.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4017052#4017052
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4017052
19 years, 1 month
[Design of JBoss jBPM] - Re: initial nodes
by thedog
Seems that I stumbled across a similar problem (avoiding signal after process create) but with different solution.
Therefore two questions:
* Is this signal really required? I searched the documents but did not find anything stating that this is necessary
* To me it seems that a node.enter is missing at end of
public ProcessInstance( ProcessDefinition processDefinition ):
Currently:
// fire the process start event
| if (rootToken.getNode()!=null) {
| ExecutionContext executionContext = new ExecutionContext(rootToken);
| processDefinition.fireEvent(Event.EVENTTYPE_PROCESS_START, executionContext);
| }
|
But the node is always unitialised (null) when starting a process
Would that be the right way?
| rootToken.setNode(processDefinition.getStartState())
| ExecutionContext executionContext = new ExecutionContext(rootToken);
| processDefinition.fireEvent(Event.EVENTTYPE_PROCESS_START, executionContext);
|
Could someone point out if I'm going the right direction? Are there problems with sub-processes or other jbpm features when using the code from above?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4017029#4017029
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4017029
19 years, 1 month
[Design of JBoss Build System] - Build System Meeting Agenda for Feb 15
by pgier
Progress Since Previous Meeting
Created generic parent pom called jboss-parent. This name was chosen based on what other maven based projects are using.
Updated the jboss-common pom.xml files to use the new parent, and inherit from their project parent (build/pom.xml).
Updated jboss-microcontainer pom files to use the new inheritance structure.
Created pom.xml for jbossretro - checked in to cvs.
Created pom.xml for jboss-test - checked in to svn. Created pom.xml for javaassist - This was sent to chiba for review
Created a basic jbossretro maven plugin - still needs more testing.
Talked to IT about creating a snapshot repository - Eric said it will take some time before we can deploy to the snapshot repository via scp or sftp For now, we can check into svn similar to the way that we are doing now.
Researched maven antlib for using a shared repository - An easier option might be to add configuration to the maven build scripts that can deploy to both repositories.
Topics to discuss
Snapshot repository - Is the snapshot repository a good idea, and how should it be
implemented?
1. Use scp or sftp to transfer the files to snapshot repository
2. Copy the files to a local folder and commit via cvs/svn
Do we want nightly builds copied to a snapshot repository?
1. We could let developers create snapshots on an as needed basis.
2. Create nightly updates and allow as needed updates.
How do we make the switch to maven?
Set up nightly maven builds.
Deploy these builds to the maven and non-maven repo.
Find out if there are problems with other projects that are dependent on these projects.
Release process with Maven
The current jboss common wiki has a manual step of committing the tag.
The maven release plugin can be used to tag the release and update the pom.xml files.
Can we use the maven release plugin with jboss common?
To Do List By Next Meeting
Set up nightly cruise control builds for common, jboss-test, and micrcontainer.
Finish jboss retro maven plugin and create a profile for building retro jars
Create a roadmap for mavenization of jboss app server
Create a maven plugin to generate the non-maven repository distribution (component-info.xml, etc).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016623#4016623
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016623
19 years, 1 month
[Design of EJB 3.0] - Re: Transient re-injection
by wolfc
That's what I keep saying, all these transient fields are not our problem but the app / bean developers problem. So we could lose the functionality all together.
anonymous wrote : The Bean Provider must assume that the content of transient ?elds may be lost between the PrePassivate and PostActivate noti?cations.
| ...
| The one exception is that containers are not required to reset the value of transient ?elds during activation[11]. Declaring the session bean?s ?elds as transient is, in general, discouraged.
|
In contrary to spec, we are providing a mechanism to help out a bean provider: transient re-injection. Somewhere along the line this has broken down, either TCK or injection refactoring. If we want it fixed we should build it back in, but as a seperate functionality, not hack it into the injection framework.
XPCs, SFSB refs and that kind of stuff is all covered in 4.2.1 and is container (/ our) responsibility, those work fine.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016592#4016592
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016592
19 years, 1 month