[Design of EJB 3.0] - Re: EJBTHREE-1607 Update EJB3.0 Tutorials
by jaikiran
What remains on the tutorial part:
1) The "jca_inflow_quartz" tutorial which is being tracked here http://www.jboss.com/index.html?module=bb&op=viewtopic&t=148386 and will be fixed today
2) The "tableperinheritance" tutorial which is broken because of a issue in HSQLDB.
https://jira.jboss.org/jira/browse/EJBTHREE-1657
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2920
I am planning to include this tutorial and add a note to the guide saying its broken on HSQLDB. If someone wants to try to use the tutorial against a different DB, then they could do so. We could have upgraded the tutorial to use some other DB like MySQL, but that would involve listing the steps required to download/install/start the MySQL server. Any opinion?
3) The "thirdpartyjms" tutorial - This one involves downloading/installing/starting a thirdparty JMS server (like OpenJMS). Should we be including this in our tutorials? If yes, then we would have to see how we can integrate this steps in our Mavenized tutorial.
4) The "HTTP_HTTPS" tutorial - This one shows how an EJB can be accessed via HTTP/HTTPS. Involves multiple configuration changes to the JBossAS. If we have to include this tutorial through our Maven process, then will have to think of a way where we can configure the server configuration of JBossAS and restart it with these changes. Any opinions?
For #3 and #4, i guess we also have "reference guide" for EJB3, where the documentation to configure the AS to achieve these functionality can be documented.
What remains on the tutorial guide part:
1) The documentation for most these completed tutorials has already been committed.
2) The Maven plugin which generates this docbook style documentation allows uploading the guide in a "war" format to Maven repositories. A snapshot version of the guide is available at http://snapshots.jboss.org/maven2/org/jboss/ejb3/tutorial/documentation/j...
3) However i was thinking more on the following lines for making available the tutorial and the guide:
* A downloadable version of the tutorial (source code) and the guide - We can make this available on our EJB3 project site download page. This will help the users to run these tutorials offline.
* A (latest/live) version of the tutorial and the guide - The live version of the tutorial can be checked out from SVN. However, for providing a live version of the guide (in html format rather than the war format), i am still looking to see if there are some options available. Anyone has any suggestions?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202787#4202787
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202787
17 years, 2 months
[Design of JBoss Portal] - Re: Design of Portal Deployer
by alesj
"mwringe" wrote :
| I must not understand this part enough. If I have a sar with a nested war, the war is sent to the tomcat deployer last no matter what parentfirst is set in the sar deployer.
| Note that I tested this deploying the sar after the server has been started. If the sar is in the deploy directory as the server starts its behaves differently.
|
| I have been trying it using the dependency deployer, but it doesn't work. If I specify I want the war to be deployed after the sar is done with the real stage, it fails since it can't find the sar dependency. It will work perfectly fine in the war is removed from the sar and is no longer nested.
|
| I would prefer to use the dependency mechanism rather than changing the portal from a sar into something else with its own custom deployer, but I can if necessary.
|
OK, the parentFirst == false was a guess/quick attemp :-), which doesn't work here.
What exactly are you trying to do?
As it sounds weird/wrong. :-)
e.g. .sar is only finished when its children (in this case .war) are finished
but your .war should wait for .sar to finish ... chicken and egg problem ;-)
Although in this case you might even get away with this,
as .war at the end is nothing more than a mbean --> ServiceDeployer.
And if you put proper depends on it, it would have the right order dependencies.
I'm just not sure how easy/hard it is to add dependencies to a .war's mbean representation.
What about if you deploy things separately - with proper jboss-dependency.xml in the top level?
The classloading should work, as long as the flat (non-scoped) model is used.
Or it's part of common/server lib - which I guess is right place so real jbp users can write against your custom jbp api.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202776#4202776
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202776
17 years, 2 months
[Design of EJB 3.0] - Re: EJBTHREE-1670 - Quartz scheduler integration failing on
by jaikiran
The JCA 1.5 spec says:
anonymous wrote : B.2.1 JMS ActivationSpec JavaBean Properties
| The following is a description of the recommended set of JMS ActivationSpec
| JavaBean properties:
|
|
| B.2.1.5 subscriptionDurability
| This property applies only to endpoints (message-driven beans) that receive
| messages published to a JMS Topic. ....
| ....
| Specifying a value for the subscriptionDurability property on the ActivationSpec
| JavaBean is optional. If no value is specified, NonDurable is assumed.
|
So i guess, the default value should be set by the JMS activation spec (which is already being done - see below) instead of the JBossMessageDrivenBeanMetadata. The JMS activation spec already handles defaulting the value to NonDurable:
package org.jboss.resource.adapter.jms.inflow;
| ...
| public class JmsActivationSpec implements ActivationSpec
| {
|
| ...
| /** The subscription durability */
| private boolean subscriptionDurability;
| ...
| /**
| * @return the subscriptionDurability.
| */
| public String getSubscriptionDurability()
| {
| if (subscriptionDurability)
| return "Durable";
| else
| return "NonDurable";
| }
|
| /**
| * @param subscriptionDurability The subscriptionDurability to set.
| */
| public void setSubscriptionDurability(String subscriptionDurability)
| {
| this.subscriptionDurability = "Durable".equals(subscriptionDurability);
| }
| ...
| }
|
So to fix this issue, we have to just remove the default value setting in the JBossMessageDrivenBeanMetadata and MessageDrivenBeanMetadata:
Index: jboss/JBossMessageDrivenBeanMetaData.java
| ===================================================================
| --- jboss/JBossMessageDrivenBeanMetaData.java (revision 82794)
| +++ jboss/JBossMessageDrivenBeanMetaData.java (working copy)
| @@ -76,7 +76,7 @@
| private String acknowledgeMode;
|
| /** The subscription durability */
| - private SubscriptionDurability subscriptionDurability = SubscriptionDurability.NonDurable;
| + private SubscriptionDurability subscriptionDurability;
|
| /** The destination jndi name */
| private String destinationJndiName;
| Index: spec/MessageDrivenBeanMetaData.java
| ===================================================================
| --- spec/MessageDrivenBeanMetaData.java (revision 82794)
| +++ spec/MessageDrivenBeanMetaData.java (working copy)
| @@ -75,7 +75,7 @@
| private String acknowledgeMode;
|
| /** The subscription durability */
| - private SubscriptionDurability subscriptionDurability = SubscriptionDurability.NonDurable;
| + private SubscriptionDurability subscriptionDurability;
|
| /**
| * Create a new MessageDrivenBeanMetaData.
|
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202742#4202742
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202742
17 years, 2 months
[Design of EJB 3.0] - Versioning
by ALRubinger
I propose we drop the qualifier (ie. "-Beta7") from all components that are not directly consumed by some other project.
This currently affects everything except jboss-ejb3-as-int and jboss-ejb3-plugin.
Reason: For CR1 I don't want to spend 1/2 a day re-releasing perfectly good projects just to get a name change, and then watch builds to make sure I didn't make a mistake updating all the dependencies. I'll have to repeat this exercise for GA later this week.
Related to this is our versioning scheme in JIRA; I'd like to implement something along the lines of what I'm doing for jboss-aspects, where valid versions are listed per-component. So we'd have:
core-1.0.0
| core-1.0.1
| build-1.0.0...
This gives a clear indication of which component release a bug fix is actually in. I'm finding it difficult to keep track of questions like: "If fix version is 1.0.0-CR1, what release of Proxy actually contains it? Do I need to re-release Proxy, or has it already been integrated?"
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202737#4202737
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202737
17 years, 2 months